第十六章：GraphRAG 与图检索

16.1 向量检索的结构性局限

先看一个具体的失败案例。

问题：「A 公司的最大供应商的主要竞争对手是谁？」

这个问题需要三步：

查出 A 公司的最大供应商是 B 公司；
查出 B 公司的主要竞争对手是 C 公司；
回答 C。

单次向量检索的困难：它通常把 Query 编码为一个向量，返回最相似的片段；若没有片段同时提到 A、B、C，单次召回未必能给出完整关系链。这个限制不等于向量方法“做不到”多跳：查询分解、多轮检索、实体扩展、后期交互或 Agent 都可以组合多个证据，只是需要额外的控制逻辑与验证。

flowchart LR
    subgraph 向量检索
        Q1[整个问题一个向量] --> M1[找最相似的片段]
        M1 --> F1[找不到
因为没有片段同时包含三者]
    end
    subgraph 图检索
        Q2[识别实体 A] --> N1[节点 A]
        N1 -->|供应关系| N2[节点 B]
        N2 -->|竞争关系| N3[节点 C]
    end

标准的单轮向量召回不显式表示图拓扑，也不会自行沿关系边遍历。 对关系链问题，它更适合作为找到证据入口的一环，而非完整推理器。

加大 Top-K、换模型或 rerank 有时能改善证据覆盖，但不能替代显式的多步检索、关系建模和答案验证；是否需要这些能力必须在任务集上验证。

另一类单轮局部检索较难覆盖的问题：全局性、主题性的问题。

「这一千份客户反馈的主要抱怨集中在哪几类？」——这需要综合整个语料，而不是找出最相关的几个片段。

16.2 GraphRAG 的思路

GraphRAG 的做法，是把非结构化文本转成结构化的知识图谱，再在图上做检索。

16.2.1 构建阶段

flowchart TB
    D[文档] --> C[切分]
    C --> E[LLM 抽取实体与关系]
    E --> G[构建知识图谱]
    G --> COM[社区检测
把强关联节点聚成社区]
    COM --> SUM[为每个社区生成摘要]
    SUM --> IDX[(图 + 社区摘要索引)]

关键在于社区摘要这一步：把图划分成若干个紧密关联的子图（社区），为每个社区生成一段摘要。这些摘要就是回答全局性问题的素材。

16.2.2 检索阶段

检索模式	做法	适合
局部检索	定位问题涉及的实体节点，沿关系边扩展邻居，收集相关文本	具体实体的多跳问题
全局检索	用社区摘要作为素材，逐层汇总回答	主题性、全局性问题

局部检索的典型流程是「向量定位入口 + 图遍历接力」：先用向量检索找到问题涉及的实体节点，再沿着关系边走 1–3 跳收集关联信息。

这个混合思路很重要：向量负责「从文本世界跳进图世界」，图负责「在结构化世界里走关系」。

16.3 必须诚实说明的代价

只讲 GraphRAG 的优点而不谈代价，往往不足以支撑实际选型。

16.3.1 事实查找未必值得使用

微软的原始研究和官方文档都明确指出：

对具体事实查找，基础 RAG 往往已经足够，GraphRAG 的额外抽取和上下文可能不划算。

原因不难理解：事实查找只需要找到那一个包含答案的片段，而图检索绕了一大圈的实体和关系，反而引入了噪音。

这是任务与实现相关的经验结论，不应泛化为所有 GraphRAG 都一定更差；应以同一数据集、预算和时延约束下的对照实验决定。

16.3.2 索引成本很高

构建阶段需要对每个 chunk 调用 LLM 抽取实体和关系，再对每个社区生成摘要。

参考量级：百万 Token 规模的语料，索引成本在几十到几百美元，且随语料规模线性增长。

对比一下：普通向量索引的成本是几美分。这是两三个数量级的差距。

16.3.3 更新极其困难

新增一份文档，可能改变实体之间的关系，进而改变社区划分，进而使大量社区摘要失效。

原始的 GraphRAG 方案基本上需要重建。后续的一些改进方案（如 LightRAG）专门针对这一点做了增量更新支持，在动态语料上更实用。

16.3.4 抽取质量决定一切

实体和关系是用 LLM 抽出来的，这意味着：

实体消歧问题：「张三」「张总」「张经理」可能是同一个人，也可能不是；
关系抽取错误会被固化进图里，且比文本错误更难发现——文本错了还能人工看出来，图里的一条错误的边是隐形的；
抽取的一致性差：同样的关系在不同文档里可能被抽成不同的关系类型。

图的质量上限，等于 LLM 抽取的质量上限。 而这一层通常没有任何校验。

16.4 相关方案对比

方案	特点	适合
GraphRAG（微软）	社区检测 + 分层摘要，全局问题能力强	主题分析、全局综合
LightRAG	更轻量，支持增量更新	语料频繁变化的场景
HippoRAG	借鉴海马体索引理论，用个性化 PageRank 做图遍历	多跳问答
PathRAG	关注图上的关键路径，减少冗余信息	路径推理类问题

原始 GraphRAG 更新困难，而 LightRAG 专门补这一点；这也是两者最值得区分的地方之一。

16.5 什么时候值得用

flowchart TB
    S{问题类型} -->|具体事实查找| NO[先以基础 RAG 为基线
再做对照评测]
    S -->|需要多跳关系推理| M{关系是否
本身就重要?}
    S -->|需要全局主题综合| G{语料规模与
预算允许吗?}
    M -->|是| YES1[考虑图检索]
    M -->|否| ALT[先试 Agentic RAG
多轮检索也能做多跳]
    G -->|是| YES2[考虑 GraphRAG]
    G -->|否| ALT2[考虑 RAPTOR
成本更低]

值得用的信号：

领域本身就是关系密集的：组织架构、供应链、知识产权、金融关联、代码依赖；
大量真实问题是多跳的；
需要全局主题分析，且预算允许；
语料相对稳定，更新不频繁。

不值得用的信号：

问题以事实查找为主；
语料高频更新；
预算敏感；
基础 RAG 还没调好。

一个重要的替代方案：多跳问题也可以用 Agentic RAG 做——让 Agent 分多轮检索，第一轮查出 B，第二轮查 B 的竞争对手。

对比	GraphRAG	Agentic 多轮检索
索引成本	很高	与普通 RAG 相同
查询成本	中	高（多轮 LLM 调用）
更新成本	很高	与普通 RAG 相同
全局问题能力	强	弱
多跳能力	强	强

结论：多跳不自动意味着需要 GraphRAG。 先比较查询分解/Agentic 多轮检索、显式关系表与图检索的质量、成本、延迟和更新代价；社区摘要在全局综合中可能有价值，但也不是唯一选择。

16.6 一个务实的中间方案

不一定非要上完整的知识图谱。很多多跳需求可以用更轻的手段满足：

在元数据里存实体标签，检索时按实体做过滤和关联；
建立文档之间的显式引用关系（「本条参见第 X 条」），检索时自动带出被引用内容；
对结构化程度高的部分单独建关系表，用 SQL 查询，与向量检索结果合并。

这类方案的成本远低于完整 GraphRAG，却能覆盖相当一部分需求。 在多跳需求不重、语料更新频繁时，这类折中方案往往更容易落地。

16.7 常见错误

16.7.1 只讲 GraphRAG 的优点

如果省略事实查找的对照结果、索引成本和更新困难，就很难完成实际选型。

16.7.2 把向量检索绝对化为“做不到多跳”

单轮向量召回不显式遍历关系，但查询分解、多轮检索、实体扩展和 Agent 能组合证据。关键是比较这些路径与图检索是否满足任务要求。

16.7.3 忽略抽取质量的风险

图里的错误边是隐形的，比文本错误更难发现。

16.7.4 不知道 GraphRAG 更新困难

这在动态语料场景里是决定性的劣势。

16.7.5 认为 GraphRAG 是通用升级

它针对特定问题类型；对事实查找应先以基础 RAG 为基线比较成本与质量。

16.7.6 不知道多跳还有更便宜的做法

Agentic 多轮检索、元数据实体关联都能覆盖部分需求。

16.8 本章总结

单轮向量召回不显式遍历关系图：对多跳问题常需查询分解、多轮检索、实体扩展或图结构；它不是“绝对做不到”；
较难覆盖的任务：多跳关系推理、全局主题综合；是否需要图取决于实测；
GraphRAG 的思路：LLM 抽取实体关系构图 → 社区检测 → 社区摘要；检索分局部（向量定位 + 图遍历）和全局（社区摘要汇总）；
必须说明的四个代价：事实查找可能不如基础 RAG 划算、索引成本高、更新困难、抽取质量会限制上限且错误隐形；这些都要用对照实验确认；
相关方案：LightRAG 支持增量更新，HippoRAG 专长多跳，PathRAG 关注关键路径；
只需要多跳时，应比较 Agentic 多轮检索、结构化查询与图检索；全局综合也应以任务评测而非“不可替代”判断；
务实的中间方案：元数据实体标签、显式引用关系、结构化部分单独建表。