GraphRAG 与知识图谱检索

普通 RAG 擅长「局部事实问答」，但面对「总结整个知识库的主题」「梳理实体间的关系链」这类全局性、关系性问题就答不好——因为它只能召回零散的文本块。GraphRAG 用知识图谱重构检索，是微软 2024 年提出后迅速走热的方向。基础对比见 RAG 进阶。

一、普通 RAG 答不好什么？

问题类型               普通向量 RAG
"X 的定义是什么"        ✅ 召回相关段落即可
"列出所有与 X 相关的人"  ⚠️ 信息散在多处，召回不全
"总结这批文档的主题"     ❌ 没有任何单一 chunk 含答案
"A 和 B 是怎么联系的"    ❌ 关系跨越多个文档，向量检索抓不到

根因：向量检索是「找最像问题的几个文本块」，它不理解实体之间的关系，也没有全局视角。

二、GraphRAG 的核心思路

把「检索文本块」换成「检索知识图谱」：

索引期（离线，贵）：
  文档 → LLM 抽取实体 + 关系 → 构建知识图谱 → 社区检测(聚类) → LLM 为每个社区生成摘要

查询期：
  局部问题 → 定位相关实体 → 图遍历取邻域子图 → 生成
  全局问题 → 各社区摘要分别回答 → 汇总成最终答案（map-reduce）

两个关键构造：

知识图谱：节点是实体（人、组织、概念），边是关系（「任职于」「导致」）。用 LLM 从文本里抽取，比传统 NER 更灵活。
社区摘要（Community Summaries）：用社区检测算法（如 Leiden）把图聚成层次化的「社区」，再让 LLM 给每个社区写摘要。这是 GraphRAG 能回答全局问题的关键——全局问题被分解成「对各社区摘要分别提问再汇总」。

三、局部检索 vs 全局检索

	Local Search（局部）	Global Search（全局）
适合	具体实体相关的问题	跨整库的总结/主题问题
做法	找到实体 → 取其邻域子图 + 相关文本	遍历所有社区摘要 → map-reduce 汇总
例子	「张三在哪些项目里出现」	「这批合同的主要风险类型有哪些」
成本	较低	高（要过所有社区摘要）

四、GraphRAG 家族与演进

微软 GraphRAG：开创者，全量 LLM 抽取 + 社区摘要，效果好但索引成本高昂（每个文档都要过 LLM 抽实体关系）。
LightRAG：简化图结构 + 增量更新，大幅降低构建和更新成本，支持新文档增量入图。
而后的混合路线：图检索 + 向量检索结合（图管关系/全局，向量管语义/局部），是落地常见形态。
HippoRAG：借鉴海马体记忆机制，用个性化 PageRank 在知识图谱上做多跳检索。

五、GraphRAG vs 向量 RAG：怎么选

维度	向量 RAG	GraphRAG
局部事实问答	✅ 强且便宜	可以但杀鸡用牛刀
全局总结/多跳关系	❌ 弱	✅ 强
索引成本	低（只需 embedding）	高（LLM 抽取 + 社区摘要）
增量更新	容易	较难（图要重算社区，LightRAG 缓解）
可解释性	弱（一堆文本块）	强（实体关系路径可视化）

务实结论：大多数业务用「向量 RAG + 混合检索 + rerank」就够；只有当关系推理和全局理解确实是核心需求（如尽调、文献综述、复杂知识管理、反欺诈关系网）且能承担索引成本时，GraphRAG 才值得上。常见做法是混合：默认走向量，关系/全局类问题路由到图检索。

六、工程落地挑战

抽取质量：LLM 抽实体关系会有噪声和不一致（同一实体多种叫法 → 需要实体消歧/对齐），图质量直接决定上限。
成本：全量 LLM 抽取对大库是真金白银，要评估值不值；可先抽高价值文档。
增量更新：文档变了，图和社区摘要要不要重算？这是 GraphRAG 落地最大的工程痛点，选 LightRAG 等支持增量的方案缓解。
评估：全局问题没有标准答案，评估更难，常需 LLM-as-a-judge + 人评（见 RAG 评估）。

高频追问

Q：GraphRAG 解决了普通 RAG 的什么问题？ 普通向量 RAG 只能召回零散文本块，答不好「全局总结」和「跨文档关系推理」这两类问题。GraphRAG 把文档变成实体-关系知识图谱 + 社区摘要，用图遍历做关系推理、用社区摘要的 map-reduce 做全局总结。

Q：GraphRAG 的索引为什么贵？ 要用 LLM 把每个文档里的实体和关系都抽取出来构图，再对图做社区检测并为每个社区生成摘要——这些都是大量 LLM 调用。大知识库的构建成本可能是纯向量方案的几十倍，这是它最大的落地门槛。

Q：Local search 和 Global search 区别？ Local 针对具体实体：定位实体→取邻域子图+相关文本→生成，便宜；Global 针对全局问题：遍历所有社区摘要→map-reduce 汇总，贵。系统按问题类型路由到对应模式。

Q：什么时候该用 GraphRAG，什么时候不该？ 该用：关系推理/全局总结是核心需求，且能承担索引成本（尽调、文献综述、知识管理、关系网分析）。不该用：以局部事实问答为主、延迟成本敏感——这种场景向量 RAG + rerank 更划算。实践常做混合 + 路由。

Q：GraphRAG 和普通 RAG 能结合吗？ 能，且是主流落地方式：向量检索管语义/局部问答，图检索管关系/全局问答，用一个路由层按问题类型分发；或在同一次检索里融合图结构信号和向量相似度。

Q：构建知识图谱时实体重复/歧义怎么办？ 需要实体消歧与对齐（entity resolution）：把「微软」「Microsoft」「MSFT」归并为同一节点。常用规则 + embedding 相似度 + LLM 判断结合。图质量取决于此，做不好会导致关系断裂、检索失效。

GraphRAG 与知识图谱检索 ​

一、普通 RAG 答不好什么？ ​

二、GraphRAG 的核心思路 ​

三、局部检索 vs 全局检索 ​

四、GraphRAG 家族与演进 ​

五、GraphRAG vs 向量 RAG：怎么选 ​

六、工程落地挑战 ​

高频追问 ​