RAG 为什么一做多跳检索就开始证据链断裂：从 Query Decomposition 到 Path Reranking 的工程实战

🚨 单跳召回看起来很高，为什么复杂问题一上来就答偏了

很多团队把RAG从FAQ升级到制度问答、投研分析或运维排障后，最先遇到的不是召回为零，而是多跳问题开始“像答对了一半”。⚠️ 第一跳能找到产品手册，第二跳却接不上版本约束、权限说明或时间条件，模型最终给出一段语言流畅但证据残缺的回答。📉

这类故障难排，在于离线topk_recall往往并不难看。🧩 查询改写、向量检索、重排器甚至都能各自过线，可一旦问题需要“先定位实体，再追一层关系”，系统就会把多跳推理误做成多段并行搜词。📌 最后进入 prompt 的不是一条证据链，而是几块互不担保顺序的相似片段。

🔍 真正断掉的，不是向量库，而是问题拆分、hop 预算和路径打分

真正让证据链断掉的，通常有三层。🔍 第一层是query decomposition过粗，把“谁在什么版本下受到什么限制”拆成几个孤立关键词；第二层是 hop 预算失控，系统没有限制二跳、三跳扩散范围，结果时延上去了，关键证据反而被噪声淹没；第三层是重排仍按 chunk 独立打分，没把“前一跳是否为后一跳提供锚点”算进去。🧠

一组企业知识库灰度数据里，单次 dense 检索的grounded_answer_rate只有61%；加了问题拆分后，首跳命中升到79%，但如果不做路径重排，最终答案稳定度只到68%。✅ 当系统改成“拆分约束化 + hop budget + path rerank”后，grounded_answer_rate能到84%，而P95只比基线多320 ms。🚦 这说明多跳收益兑现的前提，不是扩更多 hop，而是让每一跳都服务最终答案。

🛠️ 更稳的工程做法，是先收紧拆分边界，再按路径重排证据

更稳的做法，不是盲目把topk拉高，而是让每一跳都带着约束继续往下走。🛠️ 第一跳先产出候选实体和证据锚点，第二跳只能围绕这些锚点补关系、版本和时序条件；如果二跳没有补出新约束，就应尽快停止扩散，而不是继续放大上下文。🔒 这样做的核心，是把“更多召回”改成“更短的有效路径”。

真正关键的一步，是把 path rerank 放到回答前，而不是只在召回阶段排一次分。🔁 重排器需要联合看entity_overlap、temporal_consistency、source_authority和hop_coverage，优先保留能自洽闭环的证据路径。📎 否则生成层会把局部高分片段误判成全局充分证据。一旦路径得分低于门槛，就直接回退到单跳保守回答或要求补充问题，别让模型拿半条链路硬凑结论。

defretrieve_multihop(query,retriever,reranker,hop_limit=2):seed=decompose_query(query,max_hops=hop_limit)paths=[]forhopinseed.hops:docs=retriever.search(hop.text,filters={"entity":hop.entity,"version":hop.version},topk=6,)paths.extend(attach_anchor(hop.anchor,docs))ranked=reranker.sort(paths,features=["entity_overlap","temporal_consistency","hop_coverage"],)returnpick_grounded_path(ranked,min_score=0.72)

📈 接下来 3 到 6 个月，多跳 RAG 的分水岭会从“召回更多”转向“证据链可治理”

接下来3到6个月，多跳RAG的竞争点不会只是“谁能扩更多 hop”，而是谁能把 hop 当成可预算、可观察、可回退的运行时合同。📈 团队至少要持续盯住path_complete_rate、evidence_anchor_keep_rate、grounded_answer_rate和latency_per_hop。📊 尤其在跨文档、跨版本知识库里，只要这些指标反向漂移，就说明系统已经从“多跳检索”滑向“多段堆料”。

笔者认为，成熟的RAG平台最终会更像一台证据编排器，而不是向量库外面再包一层问答壳。💡 真正能上线放量的，不是首跳命中率最高的方案，而是知道什么时候该继续追证、什么时候该及时止损的方案。🙂 你们线上更常见的，是拆分失真，还是路径重排缺位？欢迎交流。