把检索做成一个工具

标准 RAG 的隐含前提是：问题一次说清，检索一次到位。用户问一句，系统检索一轮，模型据此作答。这条流水线在客服问答里很好用，但遇到复杂问题就开始露馅。

"对比一下我们和 A 公司、B 公司两份合同的违约条款，哪份对我们更有利"——这不是一次检索能回答的。它要先找到两份合同，再分别定位违约条款，再比较。任何一步的前提没满足，后面都白搭。

1. 一次检索搞不定的三类问题

多子问题。 一个问题里套着两三个独立查询，一次检索只能覆盖其中一部分。表现是答案"只答了一半"。

有依赖的查询。 第二步查什么，取决于第一步查到什么。比如先查"这个订单属于哪个仓库"，再按仓库查"该仓库的截单时间"。这种问题无法预先构造查询。

第一次没查到。 检索结果为空或明显不相关时，固定管线只能硬着头皮生成——于是模型开始编。它不会说"我没查到"，因为提示词通常写着"请回答用户问题"。

这三类的共同点是：检索策略本身需要被决策，而固定管线里没有人做这个决策。

Agentic RAG 的改动很小，但性质变了：把 search(query) 注册成模型可调用的工具，由模型决定什么时候调、用什么查询词、调几次。

于是循环变成了：模型判断信息够不够 → 不够就构造查询 → 检索 → 看结果 → 再判断。这与《工具调用的四段循环》是同一个循环，只是工具换成了检索。

图：检索成为工具之后，查询策略由模型在循环里决定

把决定权交给模型，第一件要补的就是"什么时候必须停"。没有出口的循环会一直检索下去——用户看到的是一直转圈，账上是一直在花。

最大轮数。 通常 3–5 轮足够。超过 5 轮还查不到，多半是知识库里根本没有，再查也是浪费。

最大预算。 按 token 或调用次数算，和轮数分开计——一轮里可能有并行检索。

充分性判据。 让模型在每次检索后输出一个结构化判断：sufficient: true/false，以及"还缺什么"。没有这个字段，"够不够"只是一个模糊感觉，模型很容易在信息不足时硬答。

还缺什么：A 公司合同的违约金比例
是否足够作答：否
下一轮查询：A公司 合同 违约金 比例

这段结构化输出同时是可观测性数据：你能看到它在第几轮、因为缺什么而继续查。排查"为什么答错了"时，这条轨迹比最终答案有用得多。

固定管线是 1 次检索 + 1 次生成。Agentic 是 N 次检索 + N+1 次生成，N 平均在 2–3。也就是说成本和延迟大致翻倍到三倍。

值不值，取决于问题类型：

控本的四条：

按问题复杂度路由。 先用一个便宜的分类器或规则判断"这题需不需要多轮"，简单的直接走固定管线。这比所有请求都上 Agentic 省得多。

检索结果去重与压缩。 多轮检索很容易重复召回同一批切片，进上下文前要去重，只保留新增部分。

缓存中间结论。 同一会话里已经确认过的事实，写进上下文摘要，不要每轮重查。

早停。 第一次检索的 top-1 分数很高、且问题很短时，直接作答，别进循环。

Agentic 不是"更先进"，它换来的是适应性，付出的是可预测性。

实践里常见的是混合：默认走固定管线，加一个"置信度不足则升级"的开关。检索分数低、或问题里出现多个实体/比较词时，升级到 Agentic。这样大多数请求还是便宜的，少数难题才付出额外成本。

Agentic 的失败模式比固定管线多：查错方向、重复查同一件事、查到却不用、该停不停。这些在最终答案上可能看不出来（碰巧答对了），但下一次就崩。

所以要记三样东西：

把这三样做成看板，比看答案准确率更能发现问题。轨迹级评测的搭法，思路和《评测集怎么变成门禁》一致，只是样本从"问题 + 答案"变成"问题 + 期望的检索路径"。

最后提醒一句：Agentic RAG 把"检索质量"问题变成了"检索策略"问题，但它没有解决知识库本身的问题。切片烂、权限乱、文档过期，多查几轮只会更快地撞上这些墙。