RAG 搜索漂移：从漏证据到证据充分性校验

什么是搜索漂移

在基于检索增强生成的多跳问答系统中，Agent 需要依次完成多个子问题才能得到最终答案。例如，问“某份报纸的出版者与谁结婚”，系统要先查出出版者是谁，再查这个人的配偶。搜索漂移指的是：语料库中确实存在回答问题所需的证据，原始检索器也具备检索到这些证据的能力，但 Agent 在中间步骤追错了实体、遗漏了未完成的子问题，或者被看似相关的内容带偏了方向，导致关键证据没有进入最终的生成上下文。

这个概念的核心价值在于，它把“没搜到证据”和“没去搜该搜的东西”区分开来。前者是检索系统的能力边界问题，后者是搜索策略与任务追踪问题。如果混淆两者，开发者很容易错误地更换 Embedding 模型、调整向量库参数或重构索引，而实际需要修复的是 Agent 的搜索引导机制。

为什么搜索漂移容易被误判为检索失败

日志里缺少某段关键证据时，存在两种完全不同的原因：

• 不可达：在固定语料和固定检索器条件下，无论 Agent 怎么换查询，都无法获得那段证据。这属于真正的检索失败。
• 没问到：存在能够取得该证据的查询方式，但 Agent 没有发出这样的查询。这属于搜索漂移。

只看最终缺少哪段文字，无法区分这两种故障。于是一个搜索过程的问题，很容易被误判为“向量检索不行”。这种误判的代价很高：团队可能投入大量精力优化 Embedding、调整分块策略或微调检索模型，却完全没有触及真正的问题根源。

以一个具体场景为例。Agent 需要先确定某份报纸的出版者，再查该出版者的配偶。假设 Agent 在检索过程中被另一位与报纸相关的人吸引，认为这个人才是后续查询的主语，于是持续搜索这个错误实体的婚姻信息。从检索结果看，每一步返回的段落都高度相关——它们确实在讨论报纸、相关人物和婚姻关系。检索器没有出错，但搜索方向已经偏离了正确路径。

子问题登记表：把搜索进度从隐式变显式

解决搜索漂移的关键思路，是将搜索进度从自由文本中提取出来，维护成一份持续更新的结构化清单。每条记录包含四个要素：子问题描述、当前状态、简短证据笔记、支撑段落。状态只有四种：

• pending：知道需要查，但还没轮到。
• active：当前正在执行检索的子问题。
• resolved：模型判断已有充分证据回答该子问题。
• retired：该子问题被撤销，并有明确理由说明为什么不再需要回答。

这份登记表的作用不是提升检索器的召回能力，而是约束 Agent 的搜索行为。在每个检索步骤之前，Agent 需要对照登记表确认当前 active 的子问题是什么，并确保发出的查询直接服务于这个子问题。当一个子问题被标记为 resolved 时，必须同时记录支撑它的证据段落，而不是只记一个“已解决”的状态标签。

这种设计的实质，是把“搜索什么”和“为什么搜这个”变成可审计的状态转换。排查故障时，开发者可以沿着登记表的状态变化回溯，看到 Agent 在哪一步将某个子问题设为 resolved、依据是什么、有没有子问题被错误地 retired、有没有 pending 项在整个过程中从未被激活。

一个克制的验证方法

评估搜索漂移的影响时，有一种做法值得借鉴：固定检索器，只改搜索引导。如果新的引导方式让某段标准证据被成功找回，至少说明这段证据原本就可达，之前的问题出在查询策略而非检索能力。反过来，新方法仍然没找到，也不能直接证明证据不可达。

这里有一个容易被忽略的统计陷阱：两套系统可能在不同的题目上失败，汇总数量的下降不能直接换算成“所有检索失败中有多少比例是搜索漂移”。不同题目的证据分布、实体歧义程度、子问题链条长度各不相同，聚合指标会掩盖个例层面的因果差异。要确认某一道题的具体原因，仍然需要回到它的查询序列和证据轨迹逐条分析。

这种验证思路的价值在于它足够克制。它不假设检索器是完美的，也不假设所有失败都能归因于搜索漂移，而是提供了一种可操作的方式来判断“换检索器”是否真的必要。

搜到了证据，不等于答案正确

实践中一个值得注意的发现是：通过子问题登记表约束搜索过程后，漏证据的失败明显减少，但答案正确率的改善幅度却小得多。这说明搜索漂移只是整个失败链条中的一环。

当 Agent 完成了所有子问题的检索，并且每个子问题都有对应的证据段落后，仍然可能出现以下几种情况：

• 证据冲突：不同段落给出了相互矛盾的信息，Agent 没有能力判断哪一条更可靠。
• 证据不完整：每个子问题都搜到了相关内容，但段落中没有直接回答该子问题所需的事实，模型自行推断时出错。
• 证据过载：检索返回了大量高度相关但不关键的内容，关键事实被淹没，生成时没有被有效利用。
• 推理链断裂：证据之间的逻辑关系没有被正确串联，Agent 把正确的段落用错误的推理组合在一起。

这意味着，在搜索漂移被控制住之后，下一个需要回答的问题是：作答前怎样确认依据已经充分。这不是“有没有搜到”的问题，而是“搜到的内容是否足以支撑正确推理”的问题。判断证据充分性比判断证据可达性更困难，因为它需要对证据的逻辑覆盖度进行评估，而不仅仅是检查是否存在某些段落。

agent-">排查 Agent 搜索问题的两个检查点

对于正在开发或维护多轮检索、跨文档问答系统的团队，可以从以下两个维度检查搜索策略是否健康。

第一个检查点：搜索是否始终追着未完成的子问题。 具体来说，需要确认在整个搜索过程中，每个检索查询是否都能追溯到登记表中的一个 active 子问题。如果 Agent 发出了无法对应的查询，或者某个子问题从 pending 直接跳到 resolved 而没有经历 active 状态，就需要警惕搜索漂移。另一个信号是实体漂移——查询中反复出现与原始任务无关但“看似相关”的实体名。

第二个检查点：作答前如何确认依据已经充分。 当所有子问题都标记为 resolved 时，并不意味着可以生成答案。需要检查每个 resolved 状态背后是否关联了真正包含答案素材的段落，而不是只有摘要式笔记。笔记本身可能是模型概括时产生的失真。更严格的做法是，在生成最终答案前，让系统显式列出每个子问题对应的证据要点，并判断这些要点是否在逻辑上覆盖了回答问题所需的所有前提。

与其他相关概念的区别

搜索漂移需要与几个相邻概念区分开：

• 检索失败：证据在语料中确实不存在，或者检索器无法通过任何查询命中。搜索漂移则意味着证据存在且可达，只是查询没发对。
• 幻觉：生成阶段编造了语料中不存在的信息。搜索漂移发生在检索阶段，生成阶段可能完全忠实于给定的上下文，但上下文本身就是错的。
• 上下文长度不足：证据被检索到但被截断或丢弃。搜索漂移的特征是证据从未进入候选集，而不是进入后被裁掉。
• 查询表达失败：Agent 知道要搜什么，但构造的查询词与语料中的表达方式不匹配。搜索漂移更偏向于“不知道要搜什么”，而非“不知道怎么表达”。

这些概念的边界在实际系统中可能模糊，但区分它们对故障定位有直接指导意义。不同的根因对应完全不同的修复手段：检索失败指向索引和 Embedding，幻觉指向生成模型的约束策略，上下文长度问题指向分块和排序策略，而搜索漂移指向 Agent 的任务追踪与查询规划能力。

使用注意事项

引入子问题登记表这类机制时，有几个实践层面需要注意：

• 状态转换的判定标准要明确。resolved 不能仅凭模型感觉，应当要求模型同时输出支撑段落，并允许后续步骤推翻前序判断。如果状态一旦设为 resolved 就不可修改，系统会失去自我纠正能力。
• retired 需要显式理由。什么时候一个子问题不再需要回答，这本身就是一个推理决策。没有理由的撤销会掩盖搜索策略中的错误。
• 登记表本身也会出错。子问题的拆解质量直接影响搜索质量。如果登记表一开始就分解出了错误的子问题，约束再严格也无济于事。
• 证据笔记不等于证据段落。笔记是模型对段落的概括，概括过程可能丢失关键细节，甚至引入错误。在最终作答阶段应尽量回顾原始段落而非仅依赖笔记。
• 额外开销主要在于推理而非检索。维护登记表不会改变检索器的调用方式，但会增加每一步的推理量，需要权衡延迟与准确率之间的关系。

总结

搜索漂移是多跳 RAG 系统中一种容易被误判为检索失败的故障模式。它的核心特征是：证据在库里、检索器能找到、但 Agent 没有发出正确的查询。识别它的关键在于区分“不可达”与“没问到”。通过维护结构化的子问题登记表，把搜索进度从隐式变成显式，可以有效减少漏证据的情况。但搜到证据只是必要不充分条件——证据是否足以支撑正确推理，是搜索漂移被控制住之后必须独立面对的第二个问题。