Mistral 把 RAG 改成五工具循环，准确率从 26.7% 跳到 86%：原理解析、实操步骤、常见问题与优化建议

核心洞察

Mistral 这次放出的数据有点吓人：FinanceBench金融文档分析领域的基准测试，用于评估RAG系统在金融报告分析中的性能表现。上准确率从 26.7% 直接干到 86%，而且 token 消耗还降了两三成。我的第一反应是"这数字太漂亮了"，翻了下来源，果然是官方自测、没有第三方复现。不过这套"把检索拆成 search/open/read/grep 几个工具让模型自己转圈"的思路本身不新鲜，新鲜的是它把成本压下来了——这才是真正值得关注的地方。

核心结论

Mistral 于 2026-08-20 发布 Agentic Search智能代理搜索，一种具备自主规划与多步骤执行能力的搜索模式，能够将信息查找与实际操作结合，实现复杂任务的自动化处理。，在 FinanceBench（368 份 SEC 文件、150 题）上，Mistral Medium 3.5Mistral 自家的模型，在 Agentic Search 官方评测中作为测试模型之一。与 GLM-5.2智谱AI发布的第五代大模型版本，强化了长上下文、Agentic Coding和企业级工作流能力。的准确率均从 26.7% 提升至 86%，但该数据为官方自测，尚无第三方独立复现。
该方法将检索拆分为 search、open、navigate、read、grep 五个文件系统式工具，由模型自主决定检索路径并迭代，无需微调，任何具备工具调用能力的模型均可驱动。
多步循环反而降低了成本：相对仅用 search 的循环，token 消耗在 Mistral Medium 3.5 上下降 23.9%、GLM-5.2 上下降 33.7%；FinanceBench p90 延迟从 255 秒降至 154 秒，平均延迟从 108 秒降至 71 秒。
在 OfficeQA Pro基于 696 份扫描版美国财政部公报、约 89,000 页、133 道题的文档问答评测集。（133 题、约 89,000 页扫描版财政部公报）上，GLM-5.2 准确率从 6.3% 提升至 51.9%，提升 45.6 个百分点。
Agentic Search 并非一次性 RAGRetrieval-Augmented Generation - an AI framework that combines information retrieval with language generation to produce more accurate and contextually relevant responses. 的替代品：它适用于长申报文件、法律合同、跨文档对账等密集文档场景，而短文档查找、高吞吐搜索等简单问答仍应使用一次性检索。

一、先看痛点：一次性 RAG 在长文档上为什么翻车

传统 RAG 的流程大家都很熟：把文档切成 chunk、向量化、建索引，查询时做一次 top-k 召回，把命中的片段拼进 prompt，让模型直接作答。这个流程在"答案就藏在某一段里"的简单场景很好用，但遇到复杂文档就暴露三条固定限制：

只查一次：第一次命中什么就是什么，模型不会根据结果回头改检索词再搜一遍；
分块粒度固定：答案跨在两个 chunk 之间、藏在表格里、落在脚注里时，top-k 召回经常漏；
不迭代：没有"打开文档看看，再决定下一步看哪"的机制，模型只能拿碎片硬答。

Mistral 在发布里举了一个很典型的例子：问"1953 年美国全年月度国防开支总和"，一次性检索只能找到覆盖半年的公报，拼出来是个残缺答案；而多步检索第二次搜索就找到了 1954 年 2 月的一份财政部公报（里面含全年 12 个月的数据），读取相关页后算出总和 44,463 百万美元。答案不在第一次命中里，但检索循环能找到它。

二、Agentic Search 的核心：把检索变成模型驱动的循环

Mistral 于 2026-08-20 发布 Agentic Search。它不是替换你的检索索引，而是在索引之上加一层"文件系统式工具"，让模型自己决定：先搜什么、打开哪份文档、翻到哪页、读哪段、在哪份文档里做匹配。每一步工具的结果都喂回模型，模型再决定下一步，直到它认为证据够了才作答。

五个核心工具，全部模仿人在文件浏览器里的操作：

工具	作用	类比
search	在整个语料库做语义/混合检索，返回候选文档	全局搜索
open	打开一份目标文档	双击文件
navigate	跳到文档的某一页、某一节或某一区域	翻目录跳转
read	读取指定位置的具体内容	阅读正文
grep	在已打开的那份文档里做词法匹配	文档内 Ctrl+F

这套机制有两个关键设计。第一，无需微调：任何会调用工具的模型都能驱动这个循环，检索质量跟着模型的推理能力走，而不是被 chunking 策略卡死。第二，按需读取：模型只在需要时才打开、才读取，而不是每次都灌入一大堆 top-k 文本块，所以多步循环反而更省 token（见下面的数据）。

三、公开评测数据（官方自测，未独立验证）

Mistral 用自家 Mistral Medium 3.5 和第三方 Z.ai GLM-5.2 做了测试，测试用的是默认分块、默认排序，没有针对性调优：

FinanceBench（368 份 SEC 申报文件，150 题）：

Mistral Medium 3.5：26.7% → 86%；其中仅 search 循环就贡献 +47.3 个百分点，open/navigate/read/grep 再贡献 +8.7 个百分点；
GLM-5.2：26.7% → 86%；search 贡献 +52.6 个百分点，导航类工具再 +6.7 个百分点。

OfficeQA Pro（133 题，696 份扫描版美国财政部公报，约 89,000 页）：

GLM-5.2：6.3% → 51.9%，提升 45.6 个百分点。

成本与延迟（相对"只用 search 的循环"）：

token 使用：Mistral Medium 3.5 下降 23.9%，GLM-5.2 下降 33.7%；
FinanceBench p90 延迟从 255 秒降到 154 秒，平均延迟从 108 秒降到 71 秒。

注意：这些数字是 Mistral 自测口径，第三方尚未独立复现。学习者拿去写文章没问题，但落地前务必用自己数据集压一遍。

四、最小循环代码示意（非官方 API）

Agentic Search 的产品形态是 Mistral Search Toolkit SDK（含 QueryEngine、VectorRetriever 等组件），并提供了一个 MCPModel Context Protocol - a protocol that enables AI models to access external tools, data sources, and services to enhance their capabilities and context awareness. server，让任何智能体都能调用同样的五个工具。下面这个骨架只表达"多步检索循环"的通用结构，不是官方 SDK 的调用方式：

# agentic_search_loop.py —— 多步检索循环的最小骨架（示意代码，非官方 API）
def agentic_search_loop(query, tools, model, max_steps=8):
    messages = [{"role": "user", "content": query}]
    for _ in range(max_steps):          # 必须设上限，防止检索空转
        reply = model.chat(messages)    # 模型决定下一步动作
        if reply.finished:              # 模型认为证据足够，停止
            return reply.answer
        observation = tools.execute(reply.tool_call)  # 路由到 search/open/read 等
        messages.append({"role": "tool", "content": observation})  # 观测回填
    return "timeout"                    # 超上限后兜底返回

代码里几个关键点：

messages：完整的对话历史。每次工具结果必须作为 tool 角色的消息追加回去，模型才能"看到上一步的结果再决策"，这是循环能收敛的前提；
tools.execute(tool_call)：把模型发出的工具调用路由到 search/open/navigate/read/grep 之一，返回结构化观测文本；
max_steps：检索循环必须有步数上限，否则模型可能在文档之间反复横跳、白烧 token；
reply.finished：模型给出"证据够了"的信号（或等价地，直接输出最终答案），循环在此终止。

五、什么时候该用，什么时候别用

Mistral 的定位说得很明确，Agentic Search 不是一次性检索的替代品：

该用：长申报文件、法律合同、技术规格这类密集文档；需要跨多份文档对比、对账的问题；答案必须能溯源到具体文档位置的场景；表格和扫描件这类"版式即含义"的内容。
别用：短文档直接查找、高吞吐的关键词/语义搜索、答案位置已知的简单问答。这些场景一次性 RAG 更快、更省。

索引仍然是地基：多步循环只是让模型在"已经命中的候选集"里继续挖掘，索引质量差，循环再聪明也没用。

六、对 AI Agent 学习者的三点启示

这是 RAG 向 Agentic Retrieval 演进的标志：检索从一条固定管道变成一组模型可调用的工具，方向值得跟踪。你也可以在自己熟悉的框架里复刻这套模式，比如用 LangGraph 或 OpenAI Agents 注册 search/open/read/grep 四个工具，跑一个同样的循环。
工具分发正在走向 MCP：Mistral 把检索能力打包成 MCP server，意味着任何遵循 MCP 的智能体都能接入。学习 Agent 开发时，把"MCP 化"当作工具设计的默认姿势会更省力。
评测口径要留个心眼：官方自测数据通常没有独立验证，选型对比时看别人的复现结果，别只盯着宣传数字。

一次性检索是把"答案在哪"赌在第一次召回上；多步检索是把"怎么找"的决策权交给模型。对学习者来说，与其继续堆更细的分块和更强的 embedding，不如先学会让模型边查边想——这可能是 RAG 类应用下一步最重要的能力。

常见问题（FAQ）

Agentic Search 和传统 RAG 到底有什么区别？

传统 RAG 只做一次 top-k 召回就作答，分块粒度固定、不迭代。Agentic Search 在索引上加 search、open、navigate、read、grep 五个工具，由模型自己决定搜什么、读哪段，循环到证据足够再回答。

Agentic Search 真的能省钱吗？token 和延迟怎么样？

官方自测显示，相对只用 search 的循环，Mistral Medium 3.5 的 token 下降 23.9%，GLM-5.2 下降 33.7%；FinanceBench 平均延迟从 108 秒降到 71 秒。原因是按需读取，不再一次性灌入大量文本块。

什么场景适合用 Agentic Search，什么场景别用？

适合长申报文件、法律合同、技术规格等密集文档，以及需要跨文档对比、答案要溯源、含表格和扫描件的场景。短文档查找、高吞吐搜索、答案位置已知的简单问答，用一次性 RAG 更快更省。

AI Summary (BLUF)