1.2 GraphRAG知识图谱增强检索

1.2 GraphRAG知识图谱增强检索

本节摘要：GraphRAG 把知识图谱引入 RAG，把非结构化文档转成实体-关系网络，让检索从"算相似度"升级为"沿关系遍历"。本节讲清它的三步构建流程——实体抽取、关系抽取、图嵌入，对比它和向量 RAG 在多跳推理、实体查询上的差异，并诚实说明它的构建和维护成本，帮你判断什么场景值得上 GraphRAG。

你能学到什么

阅读完本节，你应当能够：

1. 说清 GraphRAG 相对向量 RAG 的三个核心提升点
2. 描述从原始文档到知识图谱的三步构建流程
3. 解释图嵌入如何把离散的图结构变成可检索的向量
4. 判断一个业务场景是否值得承担 GraphRAG 的构建成本

一、问题与直觉

上一节我们看到，向量 RAG 在多跳推理上栽跟头，根因是它把整个问题当一个向量去匹配，没法沿着实体的关系一步步走。打个比方：向量检索像是在图书馆里按书名关键词找书，你能找到"和主题沾边"的书，但找不到"A 书里引用的 B 书的作者还写过 C 书"这种链条。

GraphRAG 的思路是：既然关系这么重要，那就别让模型去文本里猜关系，直接把关系显式地存下来。具体说，就是把文档里的实体（人、产品、服务、公司）和它们之间的关系（收购、依赖、隶属）抽出来，建成一张知识图谱。检索的时候，不仅能算语义相似，还能沿着图上的边做几跳遍历，把分散在不同文档里的信息串起来。

这么做的好处显而易见：多跳推理变成了图上的路径查找，实体关系变成了边的遍历，这些恰好是向量检索最弱的地方。代价也很明显——你得先花力气把图谱建出来，而且文档一更新，图谱也得跟着更新。

二、核心原理

2.1 GraphRAG 的构建三步走

GraphRAG 的核心难点不在检索，而在建图。从原始文档到可用的知识图谱，要走三步。

第一步是实体抽取（也叫命名实体识别，NER）。用模型从文本里识别出人名、产品名、服务名、公司名这些实体。这一步的质量直接决定图谱的可用性——实体识别不全或识别错，后面的关系全是空中楼阁。

第二步是关系抽取。对识别出的实体对，判断它们之间有什么关系。比如"马斯克"和"Twitter"之间是"收购"关系，"服务A"和"服务B"之间是"依赖"关系。关系抽取通常用一个分类模型，输入是包含两个实体的句子，输出是关系类型。

第三步是图嵌入（可选但常用）。把图里的节点和边转成向量，这样既能做图遍历，也能做向量相似度检索。常见的有基于随机游走的方法和基于图神经网络的方法。

2.2 检索：向量加图遍历的混合

建好图之后，GraphRAG 的检索是"向量检索定位起点实体，图遍历扩展相关实体"的混合模式。

class GraphRAGRetriever:
    def retrieve(self, query):
        # 1. 从问题里识别关键实体（实体链接）
        entities = self.entity_linker.link(query)
        # 2. 向量检索补充语义相关的实体
        extra = self.vector_store.search(self.embed(query), top_k=5)
        # 3. 从命中实体出发，沿图遍历N跳内的相关节点
        related = self.graph.traverse(
            start_nodes=entities, max_hops=2
        )
        # 4. 把图遍历和向量检索的结果融合
        return self.fuse(entities, extra, related)
​

关键在第三步的图遍历。回到上一节那个"收购某平台的人的公司市值"的例子，GraphRAG 能这么走：先定位"某平台"这个实体节点，沿"被收购"边找到收购方，再沿"创立"边找到公司，最后查"市值"属性。每一步都有明确的边可以走，不需要模型去猜。

2.3 GraphRAG vs 向量 RAG 的能力对比

把两者的差异列成表，差距一目了然：

注意延迟和成本这两栏。GraphRAG 检索延迟通常比纯向量高出一截（图遍历比向量比对慢），索引构建时间也更长。这意味着 GraphRAG 不是"更好"的 RAG，而是"在特定问题上更准"的 RAG——它的优势集中在复杂推理和关系查询，对简单事实问答反而是杀鸡用牛刀。

2.4 什么时候该上 GraphRAG

判断要不要上 GraphRAG，关键是看你的问题里有没有"多跳"和"关系"。下面这些信号说明值得考虑：

• 用户经常问"A 的上级是谁""这个功能依赖哪些模块""从X到Y要经过哪些步骤"这类关系型问题
• 答案经常需要跨多个文档串联信息
• 业务里存在天然的实体网络（组织架构、产品依赖、供应链）
• 对答案的可解释性有要求，需要能展示推理路径

反过来，如果你的问答主要是"这个产品的价格""怎么退款"这种单点事实查询，向量 RAG 加好的切分和重排就够，上 GraphRAG 是过度工程。

三、工程实践要点

3.1 实体抽取的质量是地基

GraphRAG 效果好不好，七成取决于实体抽取准不准。实体抽不全，图是残缺的；实体抽错，图是错的。一个常见问题是同一实体有多种叫法——"iPhone 15""iPhone15""苹果15代"指的是同一个东西，如果不做实体消歧，图上会出现三个孤立节点。

工程上要做实体链接（entity linking）：把不同写法的实体归并到一个标准节点。这通常靠一个别名表加上向量相似度辅助判断。

⚠️ 常见坑：实体抽取用通用模型时，在垂直领域（医疗、法律、金融）的召回率往往很差。"主动脉瓣狭窄"这种术语，通用 NER 模型很可能识别不出来。垂直领域务必用领域微调的 NER 模型或大模型 few-shot 抽取。

3.2 增量更新是个真问题

文档会变，图谱也要跟着变。一篇文档改了，相关的实体和关系可能要增删。这件事比向量库的更新麻烦得多——向量库只要重新切块向量化就行，但知识图谱要判断哪些实体和边受影响、怎么改、改了之后图结构是否还自洽。

一个务实的做法是：把图谱的更新做成离线批处理，每天或每小时跑一次增量构建，而不是实时更新。实时增量构建的复杂度太高，多数业务撑不住。

3.3 图遍历的深度控制

图遍历跳数（max_hops）是个要小心调的参数。跳太少（1 跳）覆盖不够，跳太多（4 跳以上）会引入大量噪声，甚至把整个连通分量都拉进来。

我的建议是从 2 跳起步，根据召回率和噪声情况微调。配合实体相关性打分，过滤掉低权重的边，能有效压住噪声。

💡 关键直觉：GraphRAG 的图遍历不是"走得越远越好"，而是"走得够用就好"。多跳的价值在于把分散的信息串起来，但每多一跳，引入的无关信息也在指数级增长。宁可少走一跳靠模型补，也别多走一跳引入噪音。

3.4 和向量检索融合

实际系统里，GraphRAG 很少单独用，通常是"向量检索加图遍历"的融合。向量检索负责语义相关的兜底（有些问题查不出明确实体，但语义相关），图遍历负责关系链路的精准串联。两路结果做加权融合或重排，兼顾覆盖和精度。

3.5 GraphRAG 的落地成本账

很多团队对 GraphRAG 心动，但低估了它的落地成本。把账算清楚，能帮你判断要不要投入。GraphRAG 的成本分三块：建图成本、维护成本、查询成本。

建图成本是最重的一块。从原始文档到知识图谱，要跑实体抽取、关系抽取、实体消歧、图嵌入，每个环节都要算力。一个中等规模的知识库（几万篇文档）建一次图，可能要跑几天、花几百到几千块的算力。这还不算人工——实体消歧的别名表、关系类型的定义，都需要领域专家介入。所以 GraphRAG 的初始投入明显高于向量 RAG（后者基本就是切分加向量化，几乎全自动）。

维护成本是持续性的。文档会更新，图谱要跟着增量更新。前面说过这件事比向量库更新复杂得多，通常做成离线批处理。每次大批量文档更新，都要跑一轮增量建图，这又是算力和时间。如果文档更新频繁（比如新闻、工单这种每天新增的），维护成本会持续累积。

查询成本是每次问答时的开销。图遍历比向量比对慢，GraphRAG 的查询延迟通常比纯向量 RAG 高出一截。对延迟敏感的在线服务，这个差距要算进 SLA 里。

💡 关键直觉：GraphRAG 是"重资产"方案——前期建图投入大、后期维护持续花钱。它值得投入的前提是：你的查询里"多跳和关系"占比足够高，高到这些查询带来的业务价值能覆盖建图和维护成本。如果只有 10% 的查询涉及多跳，为这 10% 上整套 GraphRAG 不划算，不如对这 10% 用查询改写这种轻量方案兜底。

四、分层练习

入门：用大模型对一段产品文档做实体和关系抽取（直接用提示词让模型输出"实体-关系-实体"三元组），把结果画成一张小图，体会建图的过程。

进阶：针对上一节你构造的多跳问题，手动画一张能回答它的知识图谱，对比向量 RAG 和图遍历两种检索路径的差异。

挑战：思考你的业务文档更新频率，设计一个增量更新图的方案——哪些情况下要全量重建，哪些可以增量，怎么检测冲突。

本节速览

• GraphRAG 用知识图谱补足向量检索在多跳推理和实体关系查询上的短板，把"猜关系"变成"走边"。
• 建图三步是实体抽取、关系抽取、图嵌入，实体抽取的质量决定整个图谱的地基。
• 检索是向量加图遍历的混合，先定位实体再沿边扩展，兼顾语义和相关关系。
• GraphRAG 不是更好的 RAG，是特定问题上更准的 RAG，简单事实查询上它不如向量 RAG 划算。
• 增量更新是工程难点，文档变化要重新抽取并合并，通常做成离线批处理而非实时。
• 图遍历深度要克制，2 跳是稳妥起点，盲目加深会引入指数级噪声。

下一节我们从检索算法回到存储层，看向量数据库到底怎么选——无论你用向量 RAG 还是 GraphRAG，底层都得有一个能扛住规模的向量库。