多跳问答漏检：何时该给 RAG 加图谱

企业 RAG 能搜到相关材料，却未必能答对跨文档的依赖问题。关键不在于材料是否「相关」，而在于连接它们的中间事实有没有被找出来。原文用芯片、整车和合同的关系链说明了这个缺口。

作者提出用知识图谱补充向量检索，但没有主张直接上图谱：先用约 20 道多跳问题测试，再试查询拆解和迭代检索，最后才判断图谱是否值得引入。这是一套架构建议，没有效果实测数据。

搜到了头尾，为什么还是答不对

向量检索常用的余弦相似度（cosine similarity），衡量的是文本在主题上有多接近。查询退货政策这类单文档问题时，它通常够用；但主题相近，不等于能沿着业务关系找到下一条证据。

原文给了三个分散在不同文本块中的事实：

• CHIP-402 被装配进 Engine-B。
• Engine-B 被安装到 Titan-EV。
• Titan-EV 被纳入合同 LON-FLEET-26 的履约承诺。

如果问题是「这颗芯片会如何影响合同罚款」，top-k 检索可能找到芯片信息和合同条款，却漏掉连接两者的中间关系。缺少这一步，模型只能自行补齐链路，甚至把真实存在的实体连接成一段虚构关系。

检索到了相关实体，不代表检索到了它们之间的证据链。

这里必须保留作者自己的限定：这是需要测试的失败模式，作者没有测量它实际发生的频率。例子说明了风险，不能据此断言所有向量检索都会失败。

图谱补上关系，也带来了维护成本

作者提出的是混合检索：保留向量搜索，同时在数据摄入阶段提取实体和关系，写入属性图（property graph）。可以把它理解为：除了保存文本，还显式保存「谁依赖谁」「谁属于谁」。

遇到依赖问题时，系统先定位起始实体，再沿关系做有界遍历，把找到的路径和相关合同条款一起放进提示词。模型负责解释给定路径，减少从零散片段中猜关系的需要。

但路径能否可信，取决于前面的数据处理。

首先，关系抽取要覆盖整个语料库。其次，实体消歧要判断「Bavaria AutoPart GmbH」与「BAP Logistics」是否应归为同一实体，同时避免误合并不同对象。原文提出了这个要求，没有交代具体识别方法。

关系密集时，还需要硬性跳数上限，例如 2 或 3 跳，控制遍历范围。抽取错误和过期记录同样会进入路径；图谱也只能返回已经存入的关系。

图谱让链路更明确，但不会自动让链路更正确。

我的判断

我赞同作者把评测放在架构升级前面。先准备约 20 道需要两份或更多文档才能回答的问题，再与单事实问题并排评分。如果单事实表现不错、多跳表现较差，就有理由检查检索结构。

不过，这只是诊断线索。作者也明确说，它不是证明。文章没有提供评分标准、召回结果，也没有给出图谱与其他方案的对照数据，因此目前更适合作为排查思路，不能当作采用图谱的收益承诺。

更值得先试的是查询拆解和迭代检索：先查芯片涉及哪些车辆，再查这些车辆对应哪些合同。有些多跳问题无需图谱就能解决。两条路线的差别在于，前者在查询过程中逐步寻找中间事实，图谱则提前抽取并保存关系。

只有当依赖关系密集、业务风险较高，而且较轻的方案仍然不够时，作者才建议在一个领域试点有界图谱。这个取舍合理，但文章没有给出成本、延迟或准确率数据，仍需要团队自行验证。

能拿来做什么

• 给现有知识库准备约 20 道跨文档问题，与单事实问题分开评分，先确认薄弱点是否集中在多跳任务。
• 在日常 AI 问答中，遇到依赖链问题时先拆成连续子问题，让前一步查到的实体成为下一步查询的输入，并检查中间证据是否齐全。
• 如果已有检索服务，先试查询拆解或迭代检索；仍无法满足需求时，再选一个高风险、依赖密集的领域试点图谱，并设置 2 或 3 跳的硬上限。