GraphRAG 落地实践：向量检索在多跳推理上的局限与突破
你的 RAG 流水线返回了措辞自信、格式规整的答案。Embedding 已经过调优，分块大小也经过优化，检索评分看起来很漂亮。然后，用户突然问道："哪些受港口罢工影响的供应商，今季合同也即将到期？"系统却返回了关于港口物流和合同管理的零散片段——各自独立，从未将它们关联起来。这就是多跳推理的鸿沟，也是向量检索悄然失效之处。
这不是调参问题，而是架构层面的缺陷。向量相似度能找到看起来像查询的文档，却无法穿越散落在不同文档中的实体关系。GraphRAG——以知识图谱为后盾的检索增强生成——通过将实体关系提升为一等检索对象来解决这个问题。但将其真正推向生产环境，远比演示视频展示的更加复杂。
Embedding 为何会触及天花板
向量检索的原理是将文本转化为高 维空间中的点，再寻找最近邻。这种方法在语义相似性上表现出色："如何重置密码？"能匹配"修改登录凭证的步骤"，尽管两者没有任何词语重叠。对于单跳事实性检索，它往往已经足够。
当一个问题的回答需要从多份文档中连接不同事实时，问题就来了。设想一个合规性查询："我们哪些欧洲供应商在过去一年的安全审计中未通过，且正在处理个人可识别信息（PII）？"要回答这个问题，需要：
- 识别被标注为欧洲供应商的实体
- 将这些实体与安全审计结果相关联
- 与数据处理协议进行交叉核对
没有任何单一文档块包含这个完整答案。相关信息分散在供应商档案、审计报告和合同之中。向量相似度会分别检索出讨论欧洲供应商、安全审计或 PII 处理的文档块——但它没有机制来求这些集合的交集。
基准测试数据证实了这一差距。在 MultiHop-RAG 数据集上，GraphRAG 的准确率达到 71.17%，而标准 RAG 仅为 65.77%。在 HotpotQA 上，基于图的检索比纯向量方法精确度提升了高达 35%。问题所需的推理跳数越多，这一差距就越悬殊。
GraphRAG 的工作原理
GraphRAG 在文档与大语言模型之间加入了一个知识图谱层。整个流水线分为三个阶段：抽取、索引和检索。
抽取是最耗资源的环节。LLM 逐块读取文档，抽取其中的实体（人物、机构、概念、产品）以及实体间的关系。"Acme Corp 与 Globex 签署了一份为期三年的云基础设施合同"会生成实体（Acme Corp、Globex、云基础设施）和关系（signed_contract、contract_duration: 3 years）。这一步在索引阶段执行，而非查询阶段——但这也意味着每份文档都需经过 LLM 处理，而不仅仅是 Embedding 模型。
索引阶段构建图结构。抽取出的实体经过去重（实体消歧），关系被规范化处理，图结构存入支持遍历查询的数据库。部分实现——尤其是微软的 GraphRAG——更进一步，在图内检测社区结构，并为紧密相关的实体群生成摘要。
检索阶段是收获成果之时。查询到来后，系统从问题中抽取实体，在图中定位这些实体，再通过关系遍历收集相关上下文。它返回的不是相似度最高的 top-k 文档块，而是一个子图：与查询相关的实体、它们的关系，以及建立这些关系的源文档。
这意味着，对于"哪些受港口罢工影响的供应商，今季合同也即将到期？"这个查询，系统可以沿着图中的边，从受罢工影响的供应商追溯到其合同实体，按到期日期过滤，最终返回一个任何单一文档块都无法提供的完整答案。
没人预先警告你的实体消歧难题
构建生产级 GraphRAG 系统最难的部分，并不是选择图数据库或编写遍历查询，而是实体消歧——确保"IBM"、"国际商业机器"、"IBM Corp"和"Big Blue"都指向同一个节点。
基于 LLM 的实体抽取天然存在不一致性。同一实体在不同文档中以不同的名称、缩写和描述出现。如果没有积极的去重处理，你的图会被近重复节点填满，导致关系碎片化。一个关于 IBM 合同的查询，可能因为部分合同归档于"国际商业机器"名下而遗漏掉一半的相关数据。
生产系统通常将多种策略叠加使用来解决这一问题：
- 基于哈希的去重：对规范化后的实体名称进行精确匹配
- Embedding 相似度：对实体描述之间的语义重复进行捕捉
- 基于 LLM 的合并：处理模糊情形，由模型判断两个实体描述是否指向同一现实对象
- 领域特定规则：由数据团队维护的标准名称映射
每一层都会给索引流水线带来额外的延迟和成本。仅 LLM 合并这一步，就可能使抽取成本翻倍。跳过这一步的团队无一例外地追悔莫及——实体碎片化的知识图谱比没有知识图谱更糟糕，因为它制造了一种虚假的完整感。
改变架构决策的成本账
GraphRAG 的构建成本是房间里的大象，谁都能看到，但没人愿意率先提起。系统性基准测试给出了清晰的数字：
- 索引构建时间：在相同规模的语料上，GraphRAG 需要 5,500–7,700 秒，而标准 RAG 仅需 135 秒，慢了 40–57 倍。
- 单次查询延迟：基于知识图谱的 GraphRAG 因 LLM 实体扩展，平均每次查询耗时 14,434 毫秒；向量 RAG 仅需 1,724 毫秒。基于社区摘要的 GraphRAG 表现稍好，约为 1,249 毫秒。
- Token 消耗：一次在标准 RAG 中只需约 100 个 token 的检索，在朴素 GraphRAG 实现中可能需要 610,000 个以上。
这些数字让原生 GraphRAG 在大多数生产工作负载下都难以为继。这正是 LightRAG 受到关注的原因——它用轻量级图结构的双层检索取代了昂贵的社区聚类，在精度相当的情况下，Token 消耗减少了 99%，处理同样文档的成本约为 0.15 美元，而完整 GraphRAG 需要 4–7 美元。LightRAG 荣获 EMNLP 2025 最佳论文奖，实至名归。
实践决策框架如下：
- 使用向量 RAG：当查询为单跳、文档自包含，且延迟比推理深度更重要时
- 使用 GraphRAG：当查询需要跨文档连接实体、领域内实体关系丰富，且能够承受索引成本时
- 使用 LightRAG 或混合方案：当需要多跳推理但无法承受完整 GraphRAG 的计算预算时——这是大多数团队的现实情况
构建查询路由器
生产级 GraphRAG 系统很少对每次查询都执行图检索。大多数问题并不需要它，而延迟代价使其得不偿失。解决方案是构建一个查询路由器，对输入问题进行分类并选择相应的检索策略。
一种实用的路由方案使用三个信号：
实体密度：解析查询中的命名实体。包含多个独立实体的查询（"展示所有经安全团队审核的 Alpha 项目交付物"）是图检索的候选。单实体或概念性查询（"我们的退款政策是什么？"）则走向量检索。
跳转检测：寻找关系型语言——"关联到"、"相关的"、"同时"、"哪些 X 也是 Y"——这些词暗示 着需要图遍历。要求跨实体类型求属性交集的问题，几乎总是需要图检索。
带升级的回退机制：先用向量检索。如果答案置信度较低或响应未通过连贯性检查，再路由到图检索。这会为复杂查询增加延迟，但避免了简单查询的图检索开销。
混合集成策略——同时运行向量检索和图检索，用倒数排名融合合并结果——在多跳基准测试上带来了 6.4% 的准确率提升。但代价是 Token 消耗翻倍（平均检索 13,401 个 token，而纯向量方法仅需 3,631 个）。仅在准确率能证明其成本合理的场景下，才值得使用此策略。
让图谱保持鲜活
一个不更新的知识图谱是一种负债。向量索引可以增量添加新的 Embedding，而图的更新则会引发级联复杂性。一份新文档可能引入一个应与现有节点合并的实体，或更新一段会使下游社区摘要失效的关系。
生产环境的维护需要：
- 增量抽取：只处理新增或修改的文档，而非全量重处理。LightRAG 的架构原生支持这一特性，更新速度比完整重建索引快约 50%。
- 冲突解决：当新信息与现有图关系产生矛盾时（供应商状态从"活跃"变为"暂停"），系统需要规则来决定哪个来源优先。
- 过时检测：关系具有时效性。两年前的"当前供应商"关系可能早已失效。图的边需要时间戳和过期逻辑。
- 覆盖率监控：追踪查询实体在图中的存在比例。研究表明，在已构建的图中，通常只有 65.8% 的答 案实体存在——这意味着三分之一的查询会碰壁。持续监控这一指标，并以此为优先级，推进对索引不足文档集合的抽取工作。
何时启动，何时等待
Gradient Flow 对生产 GraphRAG 部署的分析给出了一个清醒的评估："我们几乎找不到任何真正在生产环境中创造实际商业价值的落地案例。"大多数实现仍处于实验阶段。
这并不意味着 GraphRAG 是空中楼阁，而是说这项技术正处于一个需要审慎、循序渐进地采用的阶段：
- 先把向量 RAG 做好。 如果你基础检索流水线的文档分块质量差、Embedding 效果不佳、提示词粗糙，GraphRAG 不会解决这些问题，只会放大它们。
- 识别你的多跳查询。 审计你的查询日志。如果需要跨文档推理的问题不足 10%，这项工程投入很可能还不值得。
- 从一个窄领域的图谱起步。 不要试图对整个文档库建图。选择一个高价值的子集——合同、合规文件、产品规格——这些领域的实体关系密集且定义清晰。
- 进行大量基准测试。 构建一个包含多跳问题及标准答案的评估集。如果 GraphRAG 在这些特定问题上没有显著超越你的向量基准，说明它还没准备好处理你的数据。
在生产环境中成功落地 GraphRAG 的团队，都是把它视为向量检索的增强而非替代的团队。图谱处理那 15%–20% 向量检索在结构上无法回答的查询，向量索引处理其余一切，路由器负责决策。这才是真正能上线的架构。
