GraphRAG 是在 RAG 基础上加了一层知识图谱的检索方案。普通 RAG 把文档切成片段、转成向量，提问时找语义最接近的几段丢给模型。GraphRAG 多做一步：先用模型把文档里的实体（人、公司、产品、概念）和关系（收购了、依赖于、隶属于）抽出来，构建成一张图，检索时可以沿着关系一跳一跳地走。
它解决的是普通 RAG 的一类具体失败：答案不在任何单一片段里，而是散在好几篇文档中，需要串起来才成立。
先用一句话抓住它
普通 RAG 找的是「和问题最像的几段话」，GraphRAG 找的是「和问题相关的那张关系网」。
打个比方。普通 RAG 像用关键词在一堆资料里搜，翻出最贴题的几页。GraphRAG 更像先给这堆资料画了一张人物关系图和事件时间线，然后问「张三和这次项目延期有什么关系」时，它能顺着「张三 → 负责模块 A → 模块 A 依赖供应商 B → 供应商 B 交付延迟」这条链走过去——哪怕这四件事分别写在四份文档里，没有任何一段同时提到张三和延期。
它是怎么建起来的
建图阶段是离线的，也是最贵的一步：要让模型把每个片段读一遍，抽出实体和关系，再做实体消歧（把「苹果公司」「Apple」「AAPL」合并成同一个节点）。文档量大时，这一步的 Token 成本相当可观。
社区摘要是微软那版 GraphRAG 的关键设计。建好图后做社区检测，把联系紧密的节点分成一组组主题簇，再给每个簇生成一份摘要。这样面对「这批文档的主要争议是什么」这类没法靠检索几个片段回答的全局问题时，就可以自底向上汇总社区摘要来作答。
查询阶段通常分两种模式：局部查询先定位问题涉及的实体，再沿边扩展一到两跳，把相关节点和原文片段一起给模型；全局查询走社区摘要路线，回答概括类问题。
它比普通 RAG 强在哪、弱在哪
强在多跳与全局。 需要跨文档串联的问题（「A 公司的哪些供应商同时也是 B 公司的客户」）、以及需要整体概括的问题（「这五百份工单反映的共性问题是什么」），普通 RAG 结构上就答不好——前者没有一个片段包含完整链路，后者靠取前 K 段永远只能看到局部。
弱在成本与时效。 建图要跑大量模型调用，文档更新时增量维护也麻烦。抽取环节本身也会出错：实体消歧错了、关系抽反了，图里就留下了错误的事实，而且这种错误比检索到无关片段更隐蔽——模型会当作已确认的结构化事实来用。
混合方案通常最实用。 实践中效果较好的做法是把向量检索、关键词检索（BM25）和图遍历结合起来，按问题类型分配权重，而不是纯粹依赖某一种。有些实现还在检索阶段完全不调用模型，只做索引和遍历，把延迟压下来。
和相邻概念的区别
和知识图谱的区别：知识图谱是数据结构本身，可以人工构建也可以自动抽取，用途不限于问答。GraphRAG 是「用知识图谱来做检索增强生成」的一种应用方式，图是手段不是目的。
和 RAG 的关系：GraphRAG 是 RAG 的一个变体，不是替代品。绝大多数场景里，做好切片策略、混合检索和重排序带来的收益，比直接上图更大也更便宜。
和智能体记忆的关系：带时间信息的图式记忆本质上是同一套技术用在了另一个问题上——记忆关心「这条事实什么时候有效」，GraphRAG 关心「这些实体怎么连在一起」。两者的实现经常共用一个图数据库。
容易误解的地方
「上了图谱就不会幻觉」——不会消失。图能提供更完整的证据链，但抽取阶段的错误会变成图里的错误事实，模型照样会基于错误前提生成流畅的答案。评估和溯源展示仍然必须做。
「所有 RAG 都该升级成 GraphRAG」——大部分不该。如果你的问题都是「文档里怎么说 X」这种单跳事实查询，图带来的收益接近于零，成本却翻了好几倍。先确认你真的有多跳或全局概括的需求。
「图建一次就好」——文档在变，图就要跟着变。增量更新、实体合并、过期关系清理，这些运维工作量常被低估，是很多 GraphRAG 项目上线后停滞的原因。
什么时候值得上
三个信号同时出现时比较划算：问题需要跨文档串联（多跳）；语料里实体和关系密集（人物、机构、产品、事件之间有真实的结构）；文档更新频率不高（否则维护成本吃掉收益）。
典型适配场景是尽调材料、案件卷宗、故障工单库、科研文献综述、企业内部的组织与系统依赖关系。典型不适配的是 FAQ 库、产品手册、政策条文这类查一段就能答的语料——那些场景把基础 RAG 的切片和重排做扎实，效果通常更好。