GraphRAG 是什么？与传统 RAG 有什么区别，什么时候值得用？

知识点详解：图怎样帮我们找到分散的证据？

先看普通检索容易漏在哪里

假设咱们有一个供应商资料库。合同里写着甲公司的付款周期，审计报告记录了乙公司的现金流问题，另一份公告又提到：甲和乙都依赖同一家物流公司。

用户问“甲公司的付款周期是多少”，检索合同相关片段，然后根据条款回答，就很直接。

但如果用户问“物流公司停运，哪些供应商会受影响”，最相似的几个片段未必包含完整名单。某份资料只写了物流公司的简称，另一份只提到某条运输线路。把相似片段排在前面，并不能保证这些关系都被串起来。

这不代表传统 RAG 不能处理关联问题。改写查询、混合检索、多轮搜索都可能改善效果。GraphRAG 提供的是另一种办法：提前整理关系，让查询时有结构可用。

从原文到图，中间需要做什么？

开发者可以从资料中整理出“甲公司”“乙公司”“物流公司”这些实体，再记录“使用物流服务”这样的关系。

图里的节点表示对象，边表示对象之间的联系。于是，从物流公司出发，就能沿着关系找到甲和乙。

这里不能只保存一条“甲依赖物流公司”的边。它还应该带着来源、时间和适用条件。例如，原文说的是某个项目使用这家物流公司，不等于甲公司的所有业务都依赖它。

同一个公司在不同文档中有不同名字，也要做实体合并。反过来，名字相同的两家公司不能随便合成一个节点。实体识别错了，后面的关系推理就会跟着错。

因此，图更像一份可追溯的关系索引，不能把它当成模型替我们确认过的事实库。

局部查询和全局查询，不是同一条路

“物流公司停运会影响谁”仍然是围绕具体对象展开的问题。局部查询可以先定位物流公司，再取关联实体、关系和对应原文，让模型在这些证据上回答。

而“整个资料库里最常见的供应链风险是什么”，需要看更大的范围。只找最相似的五个片段，可能漏掉其他区域的大量材料。

微软 GraphRAG 会把关联较紧密的实体组织成社区，为社区生成报告。全局查询可以先处理多个社区报告，再汇总相关内容。这样能覆盖更广的材料，但摘要也可能丢细节，生成与汇总还会增加费用。微软的局部查询说明与全局查询说明分别介绍了这两条路径。

它们不是“简单题查向量、复杂题查全图”的固定分工。具体实现可以混合检索，关键是查询需要什么证据、覆盖多大范围。

怎样确认建图真的有收益？

准备三组问题就比较容易看出来：直接找条款的问题、需要连接多份材料的问题、需要概括整个资料库的问题。

对照普通检索和 GraphRAG 时，使用相同的资料、模型和回答要求。除了答案是否正确，还要检查有没有漏掉关键关系、每个判断能不能追溯到原文，以及文档更新以后旧关系有没有被撤销。

如果只是关联题变好了，却让大量简单问题更慢、更贵，可以只在关联查询中启用图。没有必要为了统一架构，把所有请求都送进同一条复杂链路。

面试官继续追问

GraphRAG 一定需要图数据库吗？

不一定。图是数据组织方式，图数据库只是存储和查询它的一种选择。

资料规模较小、查询方式固定时，关系表或文件也能保存节点和边。需要复杂遍历、关系约束和较大规模查询时，再考虑专门的图数据库。不能把“安装了图数据库”当成完成 GraphRAG。

文档删除以后，删掉对应向量就够了吗？

不够。还要检查由这份文档抽出的实体关系、社区摘要以及回答缓存。

某条关系可能有多个来源，删除其中一份资料不一定要删除整条关系，但必须撤掉这份来源的支持。如果摘要使用了被删除的内容，也需要重新生成或标记失效。

图能避免模型幻觉吗？

不能。关系抽取会出错，回答阶段也会把“有关联”说成“有因果”。

例如，共用物流公司只能说明存在共同依赖，不能直接推出两家公司的经营风险相同。输出时仍然需要原文证据，不确定的关系要保留条件，不能把图上连着一条边当成结论。

面试速记卡

• 传统检索：擅长从问题定位相关片段，不保证关系完整。
• GraphRAG：利用实体、关系及其他图结构组织证据。
• 查询范围：局部关联与全库概括，需要不同的证据组织。
• 事实边界：关系要带来源、时间和条件，图也可能出错。
• 采用依据：对照关联问题的质量收益与建图、更新、查询成本。