GraphRAG：当问题不再只是找相似文本，而是要看懂知识之间的关系
介绍 GraphRAG 如何把实体、关系和社区结构引入检索链路，处理普通向量 RAG 不擅长的复杂问题。
GraphRAG：当问题不再只是找相似文本，而是要看懂知识之间的关系
前面几篇文章里，我们一直在围绕普通 RAG 的主线往前走：把资料整理成证据，建好索引，处理查询，整理候选，并用评估确认关键证据没有漏掉。
这条链路已经能解决很多问题。
比如用户问：
上海普通员工酒店每天最多能报多少？系统只要找回“上海住宿标准”那几段文本，再交给大模型生成答案，通常就够了。
但真实业务里，用户不会永远只问这种“某个字段是多少”的问题。
他们会问：
今年差旅政策相比去年主要变化在哪里？
哪些部门的补充规定和公司统一制度可能冲突？
销售、研发、外包员工在出差审批链路上有什么共同点和差异？
如果一个员工从北京去上海参会，报销限制会同时受哪些制度影响？这类问题麻烦的地方不在于“有没有相关文本”，而在于：
答案分散在很多文本里，真正重要的是文本背后的实体、关系、层级和冲突。
普通向量检索更擅长回答：
哪几段文本和这个问题语义最像？但 GraphRAG 想进一步回答：
这些文本里有哪些关键对象？
它们之间是什么关系？
哪些对象属于同一类问题？
整个资料库里有哪些社区、主题和结构？所以这篇文章不把 GraphRAG 写成“高级名词”，而是从一个很朴素的问题开始：
当答案不在某一段文本里，而藏在很多文本之间的关系里，RAG 该怎么办？
还是沿用公司制度问答助手，不过这一次，资料里不只有报销标准，还包括部门补充说明、历史通知和审批权限矩阵。
一、故事要从普通 RAG 的一个盲区开始
普通 RAG 的工作方式，大体是这样：
用户问题
-> 把问题向量化
-> 去向量数据库找相似文本块
-> 把 top_k 文本块放进 prompt
-> 让大模型生成答案这个方式的前提是：
能回答问题的证据，最好就在少数几个文本块里。
比如这个问题：
上海普通员工酒店每天最多能报多少？只要检索到差旅标准表里的对应片段，答案就比较直接。
但换一个问题：
哪些制度会共同影响“销售员工去上海参加客户会议”的报销？这时答案可能分散在很多地方：
差旅制度：定义城市级别和住宿上限
报销制度：定义发票、审批和付款规则
销售部门补充说明：定义客户拜访场景
会议管理制度：定义参会审批
员工手册：定义员工类型和岗位级别
历史通知：说明某些规则已被新版替代如果只靠向量相似度，系统可能召回几段看起来相关的文本，但它未必知道：
- “销售员工”是员工类型还是部门归属；
- “客户会议”同时关联会议管理和客户拜访；
- “上海”先要映射到城市级别；
- “报销”不是一个规则，而是一组费用、审批、发票、额度限制；
- 某个历史通知已经被新版制度覆盖；
- 部门补充说明和公司统一制度可能存在优先级关系。
直白地说，普通 RAG 找到的是“片段”，但复杂问题需要的是“结构”。
这就是 GraphRAG 出现的入口。
二、GraphRAG 为什么会出现
GraphRAG 不是为了替代普通 RAG。
它更像是在普通 RAG 旁边加了一层“关系理解能力”：
普通 RAG：把资料看成一堆文本块
GraphRAG：把资料进一步整理成实体、关系、社区和摘要这里的 Graph，可以先粗略理解成一张关系网。
在公司制度例子里，图里的节点可能是：
销售部门
普通员工
上海
一类城市
酒店住宿
高铁二等座
客户会议
出差审批
部门负责人
财务复核
2026 版差旅制度节点之间的边可能是：
上海 -> 属于 -> 一类城市
普通员工 -> 适用 -> 住宿标准 A
销售部门 -> 有补充规则 -> 客户拜访报销说明
客户会议 -> 需要 -> 会议审批
出差报销 -> 需要 -> 发票
2026 版差旅制度 -> 替代 -> 2024 版差旅通知这样一来，系统不只是保存了“原文片段”，还保存了“片段背后的对象和关系”。
当用户问复杂问题时，GraphRAG 可以先在这张关系网上找到相关实体，再沿着关系扩展，最后把相关文本、关系和摘要一起交给大模型。
直白地说：
普通 RAG 像是在资料堆里找几页纸；GraphRAG 像是先画出资料里的关系地图，再沿着地图找证据。
三、不要把 GraphRAG 简化成“接一个图数据库”
谈到 GraphRAG，最容易先想到的是：
是不是把 Neo4j 接到 RAG 里？这只说对了一部分。
图数据库可以是 GraphRAG 的存储或查询组件，但 GraphRAG 的核心不是“用了哪种数据库”，而是：
在 RAG 链路里显式建模实体和关系，并让检索不再只依赖文本相似度。
一个 GraphRAG 系统通常至少会多出几类东西：
| 层次 | 普通 RAG 更关注 | GraphRAG 额外关注 |
|---|---|---|
| 数据单元 | 文本块 chunk | 实体 entity、关系 relationship、声明 claim |
| 索引形态 | 向量索引、关键词索引 | 图结构、社区、层级摘要 |
| 检索方式 | 相似度召回 | 实体定位、关系扩展、社区摘要、路径查询 |
| 适合问题 | 局部事实问答 | 多跳关系、全局总结、主题归纳、冲突分析 |
| 主要风险 | 召回漏证据、噪声多 | 图构建错误、实体合并错误、成本高 |
所以 GraphRAG 不是一个单一工具，而是一类增强 RAG 的方法。
不同实现可以长得很不一样：
- 有的偏知识图谱：先抽实体关系，再用图数据库查询；
- 有的偏语义图：把文本块、实体、主题和摘要连起来；
- 有的偏全局摘要：先做社区发现，再围绕社区报告回答宏观问题；
- 有的和普通向量检索混合使用：局部问题仍走向量，复杂问题再走图。
Microsoft 的 GraphRAG 论文和开源项目就是一个很典型的实现：它会从文本中抽取实体和关系，构建知识图谱，再用社区检测生成不同层级的社区报告，用来支持普通向量 RAG 不擅长的全局性问题。
四、GraphRAG 的离线链路：先把资料编译成关系地图
普通 RAG 的离线链路通常是：
加载文档
-> 清洗
-> 分块
-> 向量化
-> 写入向量数据库GraphRAG 也需要这些基础步骤，但它会继续往下做。
可以把它理解成：
加载文档
-> 分块
-> 抽取实体
-> 抽取关系
-> 合并同名或相似实体
-> 构建图
-> 做社区发现
-> 为社区生成摘要报告
-> 保存文本、实体、关系、社区和摘要放回公司制度例子，系统可能会从原文里抽出这些结构：
实体：
- 上海
- 一类城市
- 普通员工
- 销售部门
- 客户会议
- 住宿费
- 交通费
- 部门负责人
- 财务部
关系：
- 上海 属于 一类城市
- 普通员工 适用 基础差旅标准
- 销售部门 制定 销售拜访补充规则
- 客户会议 触发 会议审批
- 报销单 需要 财务复核然后系统还会发现一些更大的主题社区：
差旅费用社区：城市级别、住宿、交通、餐补
审批链路社区：直属主管、部门负责人、财务复核
销售场景社区：客户拜访、客户会议、招待限制
制度版本社区：历史通知、新版制度、替代关系这些社区不是为了好看。
它们解决的是一个普通 RAG 很难处理的问题：
当用户问的是“整体上有什么变化、有什么风险、有哪些共同点”时，答案往往需要跨越大量文本块。
如果每次都临时从几千个 chunk 里找 top_k，模型看到的上下文很可能碎片化。
但如果离线阶段已经把文档群整理成社区和摘要，在线回答时就可以先用这些“预整理过的结构”缩小范围。
这有点像读一本大部头资料：
普通 RAG 是直接翻目录和关键词，找到几页相似内容。
GraphRAG 则先让人做一份人物关系表、主题地图和章节摘要。真正提问时，不是从零开始翻书，而是先看地图，再回到原文找证据。
五、GraphRAG 的在线链路：问题来了以后怎么查
GraphRAG 的在线查询不一定只有一种模式。
常见可以分成三类。
1. Local Search：从具体实体出发
如果用户问的是比较具体的问题：
销售员工去上海参加客户会议，报销会受哪些规则影响？系统可以先识别关键实体：
销售员工
上海
客户会议
报销然后在图里找相关邻居：
上海 -> 一类城市 -> 住宿标准
销售员工 -> 销售部门 -> 补充报销规则
客户会议 -> 会议审批
报销 -> 发票要求 -> 财务复核最后把这些实体、关系、相关原文片段一起放进上下文。
这种方式适合回答：
- 某个实体受哪些规则影响；
- 两个对象之间有什么关系；
- 一个场景需要哪些条件共同成立；
- 一个答案需要多跳证据组合。
它解决的是普通 RAG 的一个痛点：
不是所有关键证据都和原始问题长得很像。
比如“上海”和“住宿标准”之间的桥梁是“一类城市”。如果资料里没有一段话同时出现“上海、住宿、普通员工、客户会议”，普通向量检索就可能漏掉中间证据。
图结构能把这个中间关系补出来。
2. Global Search：从整体主题出发
如果用户问的是更宏观的问题：
今年差旅制度相比去年主要变化在哪里？这时很难靠几个 top_k 文本块回答。
因为“主要变化”可能散落在很多地方：
城市级别调整
住宿标准变化
审批权限变化
销售拜访规则变化
历史通知废止Microsoft GraphRAG 论文特别强调这种场景：普通 RAG 更适合局部信息检索，但在面向整个数据集的全局性问题、查询聚焦摘要时容易不够用。
GraphRAG 的做法是：离线阶段先把图分成社区，并为每个社区生成摘要报告；在线阶段回答全局问题时，不是直接从原文 chunk 里硬搜，而是先检索、汇总这些社区报告，再综合生成答案。
放回我们的例子，它可能先看：
差旅费用社区报告
审批链路社区报告
制度版本社区报告
部门补充规则社区报告然后再回答：
主要变化集中在三类：
1. 城市级别和住宿标准被重新划分；
2. 审批链路从直属主管升级为部门负责人 + 财务复核；
3. 部门补充规则需要服从公司统一制度，历史通知被新版制度替代。这类问题的关键不是“找某一段最像的文本”，而是“跨很多资料做主题聚合”。
这就是 Global Search 的价值。
3. Hybrid / DRIFT：局部和全局结合
现实问题经常介于两者之间。
用户可能先问一个具体实体：
销售员工去上海参会怎么报销？但回答时又需要理解整个制度结构：
员工类型
城市级别
会议审批
客户拜访规则
费用类别
制度版本所以很多 GraphRAG 实现会和普通向量检索、关键词检索、局部图查询、全局社区摘要混合使用。
Microsoft GraphRAG 文档里也把查询能力拆成 Global Search、Local Search 和 DRIFT Search 等模式。可以先不用记工具名，先记住背后的差别：
Local：从具体实体和邻近关系找答案
Global：从社区摘要和全局主题找答案
Hybrid：根据问题，把局部证据和全局结构结合起来六、GraphRAG 到底解决了什么
GraphRAG 最值得关注的不是“图”这个形式，而是它改变了 RAG 的检索对象。
普通 RAG 的检索对象主要是：
文本块GraphRAG 的检索对象变成：
文本块
实体
关系
路径
社区
摘要报告这会带来几类能力提升。
1. 更适合多跳问题
多跳问题不是一步能答出来的问题。
比如：
普通员工去上海参加客户会议，住宿费和审批分别按什么规则走？系统至少要跳几步：
上海 -> 一类城市 -> 住宿标准
普通员工 -> 员工级别 -> 普通员工住宿上限
客户会议 -> 会议审批 -> 部门负责人审批
销售员工 -> 销售部门 -> 客户拜访补充规则普通向量检索可能召回其中一两段，但 GraphRAG 可以显式沿着关系扩展。
2. 更适合全局总结
普通 RAG 对“找某个事实”比较自然，对“总结整个资料库的主要主题”就比较吃力。
比如：
这个公司的差旅制度主要围绕哪些风险控制？答案不是某一段原文，而是多个制度共同体现出的结构：
预算控制
审批控制
票据控制
城市级别控制
岗位级别控制
历史版本控制GraphRAG 的社区摘要能提前把这些主题整理出来。
3. 更适合关系和冲突分析
企业知识库里经常有这种问题：
部门补充说明和公司统一制度冲突时，以哪个为准？这不是简单相似度问题，而是关系问题：
制度 A 约束 制度 B
新版制度 替代 旧版通知
公司统一制度 优先于 部门补充说明
特殊审批 可以覆盖 默认规则如果这些关系没有被显式建模，模型就很容易在一堆片段里“看语气猜优先级”。
GraphRAG 至少让系统有机会把这些优先级关系作为证据交给模型。
七、GraphRAG 不是万能药
GraphRAG 听起来很强，但它不是免费升级。
它的复杂度比普通 RAG 高很多。
1. 图构建本身会出错
实体抽取和关系抽取通常会用大模型或信息抽取模型。
这一步可能出现很多问题：
把同一个实体拆成多个名字
把不同实体错误合并
抽错关系方向
漏掉隐含关系
把不重要的词也抽成实体
把临时描述当成稳定事实比如：
“销售部”
“销售部门”
“客户增长团队”它们到底是不是同一个组织？
再比如：
“2024 年通知仍可参考”
“2026 年制度正式替代 2024 年通知”这里到底是参考关系、继承关系，还是替代关系？
如果图构建错了，后面的图检索会把错误放大。
2. 成本更高
普通 RAG 主要花钱在：
文档解析
embedding
向量存储
在线检索和生成GraphRAG 还要额外做：
实体抽取
关系抽取
实体消歧
社区发现
社区摘要生成
图存储
图查询
更多评估尤其是大规模文档，离线索引成本和更新时间都会明显增加。
如果你的问题主要是：
查一个产品参数
查一条制度金额
查某个 API 怎么用那普通 RAG 加上好的分块、混合检索、rerank 和评估，可能已经足够。
不要为了“高级”而上 GraphRAG。
3. 评估更难
普通 RAG 评估可以先看：
gold evidence 有没有被召回
Recall@K 怎么样
Context Precision 怎么样
答案是否忠实于上下文GraphRAG 还要问：
实体抽取得准不准？
关系方向对不对？
社区划分有没有意义？
社区摘要有没有丢掉关键约束？
图路径是否真的支持答案？
局部证据和全局摘要冲突时听谁的？这也是为什么 GraphRAG 更适合那些“关系价值”真的很高的场景。
如果只是为了问答系统看起来更复杂，它会很快变成维护负担。
八、什么时候应该考虑 GraphRAG
可以用一张简单清单判断。
如果你的 RAG 系统经常遇到这些问题，GraphRAG 值得考虑：
- 用户问题经常需要跨多个文档组合答案；
- 答案依赖实体之间的关系，而不只是某一段文本；
- 业务里有明显的层级、归属、版本、替代、因果、依赖关系；
- 用户经常问“整体有什么变化”“主要风险是什么”“哪些对象相关”；
- 普通向量检索能找相似片段，但经常漏掉中间关系；
- 你需要解释答案为什么成立，而不是只给一段生成文本；
- 知识库里有很多同名、别名、上下级、版本冲突问题。
如果你的系统主要是这些问题，先别急：
- FAQ 问答；
- 单文档局部事实查询；
- API 文档片段检索；
- 简单客服知识库；
- 小规模资料库；
- 还没有做好基础 RAG 评估。
这类场景先把普通 RAG 打磨好更划算。
一个很实用的判断方式是：
如果答案主要来自“某几段文本”，普通 RAG 优先。
如果答案主要来自“很多对象之间的关系”，再考虑 GraphRAG。九、把 GraphRAG 放回 RAG 演化链
现在把 GraphRAG 放回前面几篇的演化链里看：普通 RAG 先解决“让模型看到外部资料”，数据导入、分块、索引、检索前后处理和评估，则是在解决“怎么稳定找到关键证据”。
而 GraphRAG 接着处理的是另一个问题：
即使每个 chunk 都处理得很好，知识之间的关系仍然可能没有被检索系统看见。所以 GraphRAG 把知识从“文本块集合”进一步升级成：
实体
关系
路径
社区
全局摘要
局部证据这就是它在 RAG 演化链里的位置。
十、初学者最容易混淆的几个点
1. GraphRAG 等于知识图谱吗？
不完全等于。
知识图谱是一种知识表示方式，强调实体和关系。
GraphRAG 则关心：怎样把这种图结构接入 RAG 的检索和生成链路。
你可以说 GraphRAG 经常使用知识图谱思想，但不能把它简单等同于“建一个知识图谱”。
2. GraphRAG 一定要用图数据库吗？
不一定。
图数据库很适合存储和查询复杂关系，但 GraphRAG 的重点是索引和检索逻辑。
小规模系统可以用普通数据库、文件、内存图结构，甚至搜索引擎里的结构化字段来保存实体关系。
关键不在工具，而在于你是否真的建模了关系，并在检索时使用这些关系。
3. GraphRAG 会替代向量检索吗？
通常不会。
GraphRAG 更常见的形态是和向量检索一起用。
向量检索擅长找语义相似文本，图检索擅长沿关系扩展和聚合结构。
两者不是谁消灭谁，而是解决不同层次的问题。
4. GraphRAG 能消灭幻觉吗？
不能。
GraphRAG 可以提供更结构化的证据，让模型更有机会基于关系回答。
但如果图抽错了、摘要写错了、检索路径不对、prompt 没约束好，模型仍然会生成不可靠答案。
它降低的是某些复杂关系问题里的失误概率，不是给答案正确性上保险。
十一、用一句话记住 GraphRAG
如果只记一句话，可以这样记：
GraphRAG 不是把 RAG 换成图数据库，而是让 RAG 从“找相似文本”升级为“沿着实体、关系和主题结构找证据”。
普通 RAG 更像：
问题来了，去资料库里找几段最像的文本。GraphRAG 更像：
问题来了，先看它涉及哪些对象，
再看这些对象之间有什么关系，
再结合相关原文和全局摘要生成答案。它最适合的场景，不是简单事实问答，而是：
多实体
多文档
多跳推理
全局总结
关系分析
版本冲突
制度依赖所以从工程角度看，GraphRAG 的核心价值不是“更酷”，而是让 RAG 面对复杂知识库时，不再只看见一堆碎片，而能看见碎片之间的连接。
下一篇继续往前走时，我们就可以从“知识怎么组织”进入另一个更工程化的问题：
当 RAG 不只是检索链路，而要变成可运行、可评估、可观测、可迭代的应用系统时，
整体架构应该怎么设计？