RAG 图检索&多跳推理：有些答案需要“顺藤摸瓜”

《AI 知识卡片》第 14 期 · 有些答案不在任何一段资料里，而在资料与资料的关系里

  刷短视频时，你一定遇到过给你推------"你可能认识的人"。

  为什么推的这么准？最朴素的一条线索就是共同好友 ：你 → 你关注的人 → 他们关注的人，走两步，谁和你重合得多就先推谁。当然背后的算法肯定没有这么简单，可能还跟通讯录、地理位置等有关。

  举这个例的核心关键：库里存的只有"谁关注了谁 "这一种关系，压根没有"你可能认识 TA"这条记录 。这个结论不写在任何一行数据里，它是沿着关系推理出来的。

  知识库查询也存在这类场景：答案不在任何一段资料里，而藏在资料与资料的关系里，得沿着关系连走几步才摸得到。这种关系查询，也叫多跳（multi-hop）。这类场景恰好是普通 RAG 的软肋。

为什么向量检索走不了第二步？

  向量检索的动作，本质上是一次性的 ：把你的问题变成一个向量，在库里找几个最像的块。它很擅长"找像的 "，但它没有"接着往下走"这个概念。

  核心问题是没有"关系"这个概念，没法靠关联关系做第二步查询。比如：文档里写着"支付网关由老王负责"，切块存进去之后，向量记住的是这句话整体的语义，而不是"支付网关→负责人→老王"这种结构。

  所以，你没法反过来问它"老王手上还有哪些模块"------这就是图检索需要解决的问题。

图检索是怎么走的？

  前面「RAG 建库」里面就讲过第二种存法：知识图谱不存文本块，存节点 （实体）和边（关系），而且关系本身可以被查询。

  图检索就建立在这个基础上。比如，我建了个菜谱知识库，它只存了三样东西：菜谱节点、食材节点，边的话就是"菜谱需要这种食材"。

  例 1："哪些菜用到了虾？"

MATCH (r:Recipe)-[:REQUIRES]->(i:Ingredient)
WHERE i.name CONTAINS '虾'
RETURN r.name, i.name

  查询结果：

小龙虾         → 小龙虾
干煎阿根廷红虾  → 阿根廷红虾
油焖大虾       → 黑虎虾/明虾
白灼虾         → 虾
芥末黄油罗氏虾  → 罗氏虾
蒜蓉虾         → 海虾
黄油煎虾       → 鲜虾

  例 1 说明：这是最简单的关系查询场景，只需要走一步，但在图检索里它不需要"猜哪个词像"，只要沿着 REQUIRES 这条边走一步，关系摆在那儿，走过去就能得到结果。

  例 2："鸡肉常和什么蔬菜搭配？"

MATCH (r:Recipe)-[:REQUIRES]->(chicken:Ingredient)
WHERE chicken.name CONTAINS '鸡'
MATCH (r)-[:REQUIRES]->(veg:Ingredient)
WHERE veg.category = '蔬菜'
RETURN veg.name, count(DISTINCT r) ORDER BY count(DISTINCT r) DESC

  查询结果：

葱     17
姜     15      
小葱   10      
蒜     9
香菜   9
香葱   8

  例 2 说明：关键在那两个 MATCH 穿过同一个菜谱节点 r，第一步从"鸡"走到用它的菜谱，第二步再从这些菜谱走到它们用的蔬菜。

  留意一件事：原始数据里压根没有"鸡肉和某种蔬菜有关"这条边。这个结论是沿着关系路径推出来的，两步走完，隐含的搭配关系自己推出来了------这正是向量检索给不了的东西。

图检索的代价

  读到这里，你可能会有疑问，上面的 例 2 跑出来的数据是一张葱姜蒜榜。查询上完全正确，但是没有实用价值。另一个问题："葱、小葱、香葱"本质上是同一样东西。这两个毛病，恰好是图检索最真实的两道坎。

  在图检索里面，高频项会主导结果。 比如：葱姜蒜出现在几乎每道菜里，按共现次数排序它们必然霸榜------越普遍的东西越没有区分度，得给它降权或直接排除，才能让真正有信息量的搭配露出来。

  实体没归一，图就是散的。 "葱 / 小葱 / 香葱 / 大葱"被存成四个独立节点，共现次数被摊薄了四份。所以说图谱节点是不区分语义的，那谁能理解语义？------还得是向量检索。

  而且图检索成本更高，不是代码难写，而是数据得先治理干净。 抽实体、对齐别名、去重、校验------这些活儿在向量检索里几乎不存在（切块嵌入就完事），但在图检索里是成本大头。

  所以，多跳推理能力不是免费的，它是用建库时的复杂度换来的。

实践里的用法：图给事实，向量给原文

  需要注意的是图检索返回的不是原文 。Cypher 查回来的是节点属性和统计数字------"蔬菜名 + 共现菜谱数"、一条路径、一个子图。这些是结构化事实，不是能直接喂给大模型。

  所以实践里最稳的做法是两路检索并用，各干各擅长的：

检索通道	返回什么	强在哪
图检索	实体、关系、路径、统计	关系推理、多跳、可追溯
向量检索	完整原文段落	语义理解、细节描述

  先判断问题里有没有"搭配""替代"这类关系词，需要就走图检索拿关系事实，同时走向量检索把相关菜谱的完整正文捞回来，最后把"图谱分析"和"资料原文"一起拼进提示词交给大模型。

  其中，图检索独有的好处------答案可以追溯路径。向量检索只能告诉你"这几段最像"，如果出了问题，你知道是哪一步错的，也是其价值所在。

一句话总结

  向量检索擅长"找像的"，但它走不了第二步------因为它只会比相似，不懂关系。

  图检索的本事是沿着边一步步走下去 ，把没被任何一句话写下来的结论推出来。代价是你得先把那张网织好：多跳推理不贵在查询，贵在建库。