GraphRAG 实战：当普通 RAG 答不了「跨文档」的问题

问普通 RAG 一个需要跨多份文档串联的问题：“A 公司的收购方，和 B 项目的负责人是同一个人吗？“它往往召回一堆孤立的片段，拼不出答案。因为向量检索擅长找”相似”，不擅长找”关系”。这正是 GraphRAG 要补的短板。

一、普通 RAG 的天花板

向量检索把文档切成块，各自转向量。问题在于：

• 一个实体的信息散落在几十个块里，谁也没完整答案。
• 需要”多跳”的问题（甲→乙→丙）无法靠单次相似度完成。
• 全局性问题（“这批文档的主要主题有哪些”）根本没有对应片段可召。

二、GraphRAG 的思路：先建图，再检索

核心是把语料变成实体-关系图：

1. 抽取：用模型从每块文本里抽出实体、实体间关系。
2. 消歧归并：把指代同一实体的写法合并成一个节点。
3. 建图：节点是实体，边是关系，附来源引用。
4. 分层摘要：把图按社区聚类，为每个社区生成摘要，形成”全局视图”。

查询时，检索在图上做，能顺着边多跳游走，把散落信息串起来。

三、两种查询模式

• 局部查询：从一个实体出发，沿关系扩展邻居，回答”关于 X 的细节”。
• 全局查询：基于社区摘要，回答”这批资料整体在讲什么”。

两者结合，才覆盖住普通 RAG 既答不了细节串联、也答不了全局概览的两类硬骨头。

四、代价要认清

GraphRAG 不是免费的午餐：

• 建图成本高：抽取要消耗大量模型调用，索引时间和费用远超普通 RAG。
• 维护更难：语料一变，图要增量更新，否则关系过时。
• 抽取质量决定上限：实体抽取错了，后面全错。

五、什么时候值得上

值得：

• 语料是高度关联的人物、公司、事件网络。
• 问题经常需要跨文档、多跳推理。
• 需要回答全局性、概览性问题。

不值得：

• 语料小、问题简单、单块可答。
• 知识高频变动、预算紧张。
• 团队没有维护图谱的精力。

六、落地建议

1. 先做普通 RAG，用真实问题测出”答不了”的比例。
2. 若跨文档问题占比高，再引入图谱层。
3. 混合检索：向量 + 图 + 关键词一起用，各取所长。
4. 从局部查询起步，全局摘要按需再补。

GraphRAG 是把”检索”升级为”推理基础设施”。它贵、它重，但面对真正的关系型难题，是目前唯一解。