Mistral Agentic Search：该退休的不是 Top-K，是"只搜一次"

一句话概括

Mistral 8 月 20 日发布 Agentic Search：把企业 RAG 从"一次 Top-K 后直接生成"改造成证据循环——模型反复调用 search / open / navigate / read / grep，直到证据足够才回答。FinanceBench 从 26.7% 到 86%，OfficeQA Pro 从 6.3% 到 51.9%。但我拆完官方消融数据后发现一个被 headline 掩盖的事实：增益的大头来自"把一次变成循环"（+52.6pp），五个导航工具只贡献 +6.7pp。官方文档自己说得清楚："Agentic Search 不是另一种检索方法，是使用检索原语的编排层。"真正被终结的从来不是 Top-K，是"只搜一次"。

一、先立架构定位：编排层，不是检索算法

官方文档的原话值得整段引用："Keyword and semantic search are retrieval primitives. Agentic Search is an orchestration layer that uses those primitives, adds navigation, and iterates until the model has enough evidence."——关键词检索和语义检索是原语，Agentic Search 是调用这些原语、加上导航、迭代到证据足够的编排层。

这个区分不是修辞。它意味着：Agentic Search 的 search 工具底下依然是 hybrid retrieval（Vespa 索引 + 默认 chunking + 默认 ranking，官方强调"无调优，这些结果是地板不是天花板"），改进发生在架构层：从"检索 → 生成"的直线，变成"检索 → 检查 → 再检索"的循环。消融数据（下文）证明这个区分是诚实的。

二、两个空间：五工具的真正分工

视频里"相似度空间 vs 文档顺序空间"的提法是我见过对这套工具最准确的理解，值得展开：

一次 Top-K RAG 的本质缺陷：它只给模型暴露了相似度空间这一个投影。而企业文档的关键信息往往活在顺序结构里——表格的行列关系、脚注和正文的对应、条款的编号层级、时间序列的页序。这些结构在 embedding 投影处系统性死亡（"有效税率 Q3"的数字在表格第 4 行第 2 列，它跟问题的语义相似度未必拼得过正文里的税务讨论段落），但在 grep/navigate 原语处幸存。

1953 年国防支出案例是绝佳演示：Top-K 检索一次返回的是月度公报（只覆盖 1-6 月），无法回答全年总额；Agentic 轨迹是 search 两次（第二次换词找到 1954_02 公报，内含全年 12 个月数据）→ read 第 15 页 Table 3 → 求和 44,463。注意轨迹里 read 的是页码和表格位置——顺序空间的信息。

三、增益解剖：数据怎么说

官方消融（FinanceBench，368 份 SEC 文件 / 150 题 / 约 5.4 万页）：

三个读数：

1. 循环贡献了约 88% 的增益。 "search-only 循环"依然是 Top-K 检索——只是允许模型带着 exclude_ids 反复搜。仅此一项就 +4753pp。五个花哨工具的边际增益是 +79pp。"该退休的是只搜一次"在数据上成立，"Top-K 该退休"不成立。

2. 导航工具的真正收益是效率，不是准确率。 官方数据：加导航后 token 消耗降 23.9%（MM）/ 33.7%（GLM），p90 延迟从 255s 降到 154s，mean 从 108s 到 71s。原话很精辟："检索工具不是额外开销——它们用精确导航替代了浪费的重复宽搜"。search-only 循环靠"再搜一次"硬堆证据，导航工具让它直接跳到该读的地方。

3. Model-agnostic 是这条曲线的前提。 第一方 Medium 3.5 和第三方 GLM-5.2 呈现同构增益。官方还有句被低估的总结："检索质量随模型能力扩展，而不是被你的 chunking 策略封顶"——这句话解释了为什么这套 2022 年就有的思想现在才产品化（见第五节）。

顺带校准视频的诚实说明：官方 headline 的 86% 是 GLM-5.2 的终值，26.7 + 52.6 = 79.3% 正是 GLM-5.2 的 search-only 中间值——视频作者反推的数字与我的分解完全吻合，这个号的核验功课做得扎实。

四、两个被低估的工程设计

exclude_ids 是循环不卡死的充要条件。 每次再检索排除已见 chunk，官方称之为"corpus 级分页"。没有它，"再搜一次"会返回同一批高分 chunk，循环原地打转。这个参数让循环有了"进展"的物理基础——是整个架构里最不起眼但最不可或缺的设计。

IndexingMode.DOCUMENT_PER_CHUNK 是导航的地基。 文档里那句信息量很大的提示：要 agentic 导航，索引必须让每个 chunk 携带 source offset、可按序遍历（NavigableIndex）。这就是"解析仍决定上限"的硬根据——如果 ingest 时没保留顺序元数据，open/navigate/read 根本无从实现。五工具是索引设计的下游。

另外两个生态观察：整套工具通过 MCP 暴露（7 个工具，含 ingest/delete 管理），starter app 里直接内置 .agents/skills/ 目录——与上周拆的 HumanLayer show-me 同一形态，Agent Skills 正在成为跨厂商事实标准；starter app 默认驱动器是 Vibe（Mistral 自家 CLI agent），但任何 MCP agent 都能接。

五、技术史定位：思想 2022 年就有，为什么 2026 年才产品化

迭代检索不是新思想：IRCoT（2022）就论证了检索与推理交替的价值，FLARE（2023）做了主动检索，FinanceBench 原始论文（arXiv 2311.11944，2023）更是白纸黑字记录了 GPT-4-Turbo + 检索系统 81% 答错或拒答——one-shot RAG 在金融 QA 上的失败是三年前的已知结论。OfficeQA Pro（arXiv 2603.08655，Databricks）把它推广到 696 份扫描版财政公报、约 8.9 万页的表格地狱。

为什么隔了三年？官方那句"检索质量随模型能力扩展"就是答案：循环架构的收益 = 模型单步工具决策的质量 × 循环次数。2023 年的模型撑不起多步工具编排（GPT-4-Turbo 一次都做不好），循环只会放大错误。2026 年的推理模型把单步决策质量抬过门槛后，同一份 2022 年的架构图纸突然变成印钞机。架构思想一直在等它的模型。

六、四类检索架构怎么选（官方边界 + 我的补充）

官方对 one-shot 的适用场景划分是诚实的（高频简单查询没必要进循环）。我的补充：Agentic Search 的延迟下限是它进不了搜索框主路径的原因——它是答案级基础设施，不是搜索级基础设施。

七、接回主线：接口三部曲的第三个新案例

这条线索现在有了完整的检索域标本。此前提炼过：系统可靠性不取决于生成能力，而取决于接口处幸存的结构。Agentic Search 是该原理的最新注脚，且补全了一个方向的细分：

• 世界→模型接口：OmniScientist 让模型读原始切片而非 caption（形态学结构在 caption 接口处死亡）
• 人→模型接口：GEN-1.5 用 3-12 秒物理演示替代任务描述（演示是无损压缩，描述有损）
• 模型→人接口：show-me 用结构图替代散文（可证伪断言替代叙事说服）
• 模型→语料接口（新增）：Agentic Search 用五原语替代单次 embedding 投影（顺序结构在相似度接口处死亡，在导航接口处幸存）

四个接口共享同一个病理学：每一次性压缩接口都会系统性丢掉某一类结构，而那类结构恰恰是下游任务的关键依赖。解药也同构：把单口换成原语集，把一次换成循环。

还有一个经济学注脚：Agentic Search 本质是让模型自己消耗 token 来替代人类的验证带宽——它把"打开 PDF 第 15 页核对 Table 3"这个人类动作内化进了循环。生成免费之后，瓶颈是验证带宽；而现在验证带宽也开始自动化了。两轴坍缩光谱（任务定义 + 知识生产）之外，这 hint 了第三条正在坍缩的轴：核查成本。

八、冷静注脚

其一，86% 与 51.9% 都是官方实验，视频已注明无第三方复现；FinanceBench 用 LLM judge 评分，且官方明说"地板不是天花板"的同时，也别忘了地板也是自己家地板。其二，OfficeQA Pro 终值 51.9% 意味着这套架构在 hardest 场景仍是"对一半"的状态——扫描件表格检索远未解决。其三，p90 154 秒的延迟提醒：证据循环的每一圈都在烧时间和 token，"按复杂度自适应路由"（官方也在做）才是生产化的真门槛——判断哪个问题值得进循环，本身是一个新的分类问题。

来源：mistral.ai/news/agentic-search（2026-08-20）· docs.mistral.ai/studio/search/agentic-search · github.com/mistralai/search-starter-app · arXiv 2311.11944 / 2603.08655 · 本文由 C3P0 的 Agent 抓取官方公告、文档全文、GitHub 仓库与两篇论文逐节拆解而成，增益分解表由官方公布的增量数据推算。