GraphRAG 与知识图谱检索 GraphRAG & Knowledge Graph Retrieval

所属：01-fundamentals / 03-rag
面试权重：★★
来源：通用领域知识（B站「RAG 面试」合集高频）；未做一手考证

一句话#

Flat chunk 检索能回答「某处写了什么」，但答不了「整个语料在讲什么」—— 因为全局性答案（主题、趋势、跨文档的关联）不落在任何一个 chunk 里；GraphRAG 用 LLM 抽出实体与关系构成知识图谱，再把图聚类成社区并逐层生成摘要，把「全局问题」变成「对社区摘要做 map-reduce」，代价是索引阶段大量的 LLM 调用与高昂的重建成本。

为什么重要（面试角度）#

GraphRAG 是 RAG 话题里最容易被问出边界感的一题。面试官想区分两种回答：

• 一种是「GraphRAG = 把知识抽成图，检索更准」—— 等于没答，因为没说清它到底解决哪一类问题。
• 另一种是能给出清晰的适用边界：它在全局/聚合/跨文档关联问题上明显优于 flat RAG，但在简单事实查找上不仅没优势、还比 flat RAG 更贵更慢。面试官想听到的正是这个「不该用的时候不要用」的判断。

面试官常问：

• 「你的语料有几千页，用户会问『这批文档的主要风险点是什么』，flat RAG 答不好，你怎么做？」
• 「GraphRAG 的索引成本大概是怎么构成的？」
• 「为什么社区摘要能回答全局问题，而检索原始 chunk 不能？」

核心内容#

Flat RAG 的盲点：全局问题#

考虑问题：「这批客服工单里反复出现的主要问题有哪些？」

• flat RAG 会去检索和「主要问题」语义最接近的若干 chunk —— 但没有任何一个 chunk 里写着"主要问题是……"。这个答案需要遍历并聚合整个语料才能得出。
• 增大 top-k 只会把更多碎片塞进上下文，模型要靠自己在 prompt 里做聚类归纳 —— 语料一大就崩，且极不稳定。
• 多跳问题同理：「A 公司通过哪条供应链间接影响了 B 地区的价格」—— 答案藏在多个文档的实体连线上，单 chunk 检索需要多轮摸索。

结论：flat RAG 的能力边界是「局部、可定位」的信息；全局、聚合、需要连线的信息是它的盲区。

GraphRAG 的索引流程#

原始文档
  → 切 text units（chunk，同普通 RAG）
  → LLM 抽取实体(entity)与关系(relation)（通常多遍/gleaning 提高召回）
  → 实体消解(entity resolution)：合并同一实体的不同别名/指称
  → 构建知识图谱：节点=实体，边=关系（边可带描述、权重、来源 chunk）
  → 社区检测(community detection)：把图聚成层次化社区（常用 Leiden 这类算法）
  → 逐层 LLM 生成社区摘要(community summary)：叶子社区 → 上级社区，形成金字塔
  → 落库：图 + 社区摘要 + 向量索引（实体/关系/摘要都可向量化）

每个环节都有可讨论的工程点：抽取的多遍策略、实体消解（「张三」「Zhang San」「张先生」是不是同一个节点 —— 这是图谱质量的最大变量之一）、社区层级数、摘要的粒度与 prompt。

查询模式：local 与 global#

GraphRAG 路线通常区分两种查询（具体实现与命名随版本/框架变化）：

Global search 是 GraphRAG 的独门能力，也是它最贵的地方：它用「预先算好的社区摘要」把「读全语料」变成了「读若干条摘要」，从而在可接受的成本内回答全局问题 —— 但社区摘要的数量随语料规模增长，查询仍要 map 一遍，所以延迟明显高于 flat RAG。

什么时候图检索真的赢#

总结成一句话：图检索赢在「答案需要跨 chunk 聚合或需要沿实体连线推理」的时候，输在「答案就写在某一个 chunk 里」的时候。

成本：GraphRAG 最现实的劝退点#

• 索引期 LLM 调用量巨大：每个 chunk 都要跑抽取（还常常多遍），再加上实体消解、社区摘要生成。成本大致与语料规模 × 抽取遍数成正比，小语料尚可，大规模语料是硬成本。
• 重建的痛苦：文档更新往往牵动实体、关系、社区划分 —— 社区是全图聚类的产物，改一个局部可能影响整体，所以增量更新比 flat RAG 难得多，实践中常被迫整批重建。
• 图谱质量依赖 LLM：抽取遗漏、关系方向搞错、实体消解失败（同一实体被拆成多个节点 / 不同实体被并成一个）都会污染下游摘要，而这类错误很难被肉眼发现。
• 查询期成本：global search 的 map-reduce 遍历大量摘要，延迟与 token 成本都高。
• 社区摘要可能幻觉：摘要是 LLM 写的，可能引入原文没有的概括，且由于是"聚合"结果，更难溯源核对。

该不该上：一个判断清单#

• ✅ 语料是文档集合（报告、工单、论文、新闻），且用户会问全局/主题/聚合类问题。
• ✅ 存在跨文档的实体关联是核心价值（风控、情报、供应链、医疗关系）。
• ✅ 能接受高昂的索引成本与较慢的更新周期。
• ❌ 用户主要问单点事实（FAQ、查参数、查流程）→ flat RAG 更划算。
• ❌ 语料小、更新频繁、延迟敏感、预算有限 → 别上。
• ⚠️ 折中路线：hybrid 架构 —— flat RAG 处理局部问题，图谱只在检测到全局/多跳意图时启用；或先做便宜的改进（更好的 chunking、hybrid 检索、reranker）看能不能解决，再考虑图谱。也有若干轻量化变体（在图上直接做检索而非全量社区摘要 map-reduce），代价与效果与传统 GraphRAG 不同，选型要按自家评测定。

常见面试问法#

Q：GraphRAG 解决 flat RAG 的什么问题？ A：全局/聚合/跨文档关联类问题。flat RAG 的能力边界是"局部可定位"的信息 —— 「这批文档的主要风险点是什么」这类答案不在任何一个 chunk 里，加大 top-k 也只能把碎片堆给模型自己归纳。GraphRAG 先把实体关系抽成图、聚成社区、逐层生成摘要，用 global search 对社区摘要做 map-reduce 来回答全局问题；对多跳关联问题，图上的路径本身就是答案的骨架。

Q：GraphRAG 的索引贵在哪？ A：主要贵在 LLM 调用：每个 chunk 的实体关系抽取（常做多遍）、实体消解、以及逐层社区摘要生成，成本大致与语料规模成正比，规模一大就是硬成本。此外图谱更新困难 —— 社区是全图聚类的产物，局部改动可能影响整体划分，实践中常需批量重建，这是比索引费更麻烦的长期成本。

Q：local search 和 global search 有什么区别？ A：local search 面向实体/话题相关的局部问题：从 query 命中实体，取其邻域（关系、相关原文 chunk、社区摘要）组装上下文，成本与 flat RAG 同量级。global search 面向全局问题：对全部（或某层级的）社区摘要做 map-reduce 聚合，这是 GraphRAG 的独门能力，但查询时要遍历大量摘要，延迟与 token 成本显著更高。

Q：什么情况下你不会用 GraphRAG？ A：用户主要问单点事实（FAQ、查参数、查流程），答案就写在某一个 chunk 里；或者语料小、更新频繁、延迟敏感、预算有限。这些场景 flat RAG（配好 chunking + hybrid + reranker）更划算。GraphRAG 的价值只在"答案需要跨 chunk 聚合或沿实体连线推理"时才兑现，否则是为不需要的能力付高昂的索引成本。

Q：GraphRAG 里最容易出问题的一环是什么？ A：实体消解（entity resolution）。同一实体以不同别名/指称出现（「张三」「Zhang San」「张先生」）会被拆成多个节点，或不同实体被误并成一个 —— 这会同时破坏图的连通性与社区摘要的正确性，而且错误很隐蔽、难以人工核对。其次是 LLM 抽取的遗漏与关系方向错误，以及社区摘要本身可能引入原文没有的概括（更难溯源）。

易错点#

• ❌ 说「GraphRAG 就是更准的 RAG」—— 没说清它只赢在全局/多跳这类特定问题上。
• ❌ 忽略索引成本与更新困难这两个最实际的劝退因素。
• ❌ 对单点事实型查询也上 GraphRAG，付出远高于收益的成本。
• ❌ 把社区摘要当"事实来源"而不核查 —— 它是 LLM 生成的聚合内容，可能幻觉且难溯源。
• ❌ 忽略实体消解这一质量瓶颈。
• ❌ 把 local / global search 混为一谈，或声称 global search 延迟与 flat RAG 相当。
• ❌ 断言某个 GraphRAG 实现的具体参数（社区层级、算法默认值）为行业标准（版本与框架相关）。

自测#

1. 为什么「这批文档的主要议题是什么」这类问题，flat RAG 加大 top-k 也答不好？

2. GraphRAG 的索引成本由哪些部分组成？为什么它的增量更新特别难？

3. local search 与 global search 各自的成本特征是什么？

4. 什么信号会让你判断「这个系统不该上 GraphRAG」？

5. 如果一定要做 GraphRAG，你会怎么降低它的成本和风险？