多跳问题该用图谱

有一个失败很典型：问"我们和某某公司的合同里，违约金的审批人是谁"，答案散在三份文档里——合同写了违约金条款编号，审批办法写了该编号对应哪一级审批，组织架构图写了那一级是谁。三段内容各自都能被检索到，但没有任何一段包含完整答案。

切片检索在这里不是"效果差一点"，而是结构上不可能：它每次只返回若干互不相关的片段，指望模型自己在上下文里把三段接起来。接得上的时候是运气，接不上才是常态。

1. 切片检索的隐含假设

整套向量检索建立在一个假设上：答案在一个切片里。所以它优化的是"这个切片和问题像不像"，而不是"这些切片能不能拼出答案"。

这个假设在单跳问题上成立得很好——问"退款要几个工作日"，答案就在那一段里。一旦问题需要经过中间实体（人 → 部门 → 制度 → 条款），假设就破了。表现是：召回率看起来不低（每段都召回了），但答案就是不对。

这也是为什么有些团队反复调切片大小和 top-K 却毫无进展——他们调的是"局部命中率"，而问题在"关系"。关系不在任何单个切片里，它在切片之间。

图：同样的三段内容，切片检索拿到三段文本，图谱检索拿到三段关系

GraphRAG 的做法可以拆成四步，每一步都有成本：

抽取 —— 用模型从切片里抽实体与关系（谁、是什么类型、和谁、什么关系），连同来源切片一起存。这一步是 LLM 逐片调用，成本随语料线性增长，也是整个流程里最贵的一环。

消歧与合并 —— "张总""张三""zhangsan"要合并成同一个节点，"苹果"是水果还是公司要靠上下文判断。不做这一步，图会碎成一地同义节点，多跳照样接不上。

社区检测 —— 把连接紧密的子图聚成"社区"，再为每个社区生成一段摘要。这是微软 GraphRAG 的关键设计：它让"这份语料整体在讲什么"这类全局问题也能被回答，而不用逐片检索。

分层检索 —— 局部问题走实体邻域（从命中的实体出发，按边扩散 1–2 跳）；全局问题走社区摘要。两种模式分别对应"问细节"和"问全貌"。

关键差别在于：关系是一等公民。你可以在图上做两跳查询、找共同邻居、按路径过滤，这些都是向量检索做不到的——向量检索只能回答"哪段文本最像"。

抽取成本与质量互相拉扯。 用便宜模型抽，实体和关系会漏、会错；用贵模型抽，一本手册就能烧掉不少预算。实践上按文档价值分级：核心制度、合同、技术规范用强模型；公告、日志这类只做向量检索。

图会过期。 文档更新要触发对应的边更新，而"哪条边来自哪个切片"这个映射必须存好。没有来源映射的图谱是不可维护的——你看到一条可疑的边，却不知道它是从哪句话抽出来的。

schema 不能太自由。 完全让模型自由抽关系，会得到几百种同义谓词（"负责""由…负责""责任人"），图查不动。给定一个不大的关系类型表（10–20 种），抽取质量会明显提升。

四类情况，直接否掉：

判断方法很朴素：拿 50 条真实问题，数一数有多少条需要经过两个以上中间实体。低于两成，图谱的收益覆盖不了建图成本。

生产上很少"只上图谱"。更常见的是三条路组合：

图谱当路由器。 先用实体识别判断问题涉及哪些实体，用图找到相关文档 ID，再去向量库里取原文。图负责"找对文档"，向量负责"取对段落"。

双路召回后融合。 图谱路径给一组候选，向量路径给一组候选，用 RRF 合并（见《混合检索与 RRF 融合》）。两边各有盲区，融合后覆盖率明显好于单路。

图谱只做校验。 答案生成后用图核一遍关键关系（"这个审批人真的属于这个岗位吗"），不通过就降级或标注不确定。这是成本最低的用法，也最容易先上线。

轻量方案也值得看：LightRAG 这类实现把"图 + 向量"做成双层检索，去掉了社区摘要那一层，建图成本低不少，适合中等规模语料。代价是全局性问题的表现弱于完整 GraphRAG。

多跳问题必须单独建一套评测集，否则图谱的收益会被平均分掩盖——单跳题上图谱和向量检索打平，多跳题上差距可能很大，混在一起算总分就看不出来。

三个指标够用：

第三条最容易被忽略，但它决定了图谱能不能维护。评测集的搭法见《评测集怎么变成门禁》，多跳样本要专门标注"需要哪几段"。

最后一句：图谱不是"更高级的 RAG"，它是为关系型问题付的额外成本。先确认你的问题真的需要关系，再谈建图。