Mistral 发布 Agentic Search，把文档检索从一次性召回改成多步操作。系统给模型五个工具：search、open、navigate、read、grep。模型可以先搜一轮，打开命中的文件看看，翻到某一节，读完发现不对再改关键词重搜，确认之后才回答。
这套做法在两个基准上的提升幅度不小。FinanceBench 用的是美国上市公司的 SEC 文件，准确率从 26.7% 提到 86%，翻了三倍多。OfficeQA Pro 用美国财政部公报做题，从 6.3% 提到 51.9%，涨了 45.6 个百分点。
一次性检索卡在哪
标准 RAG 的流程是把文档切块、算向量、按问题召回最相似的几块、拼进上下文让模型作答。这条流水线对”公司某年的营收是多少”这类问题够用，对”把过去三年的自由现金流列出来并说明口径变化”就开始失灵。
失灵的原因在切块那一步就埋下了。财报里的一个数字，往往要靠三样东西才能读对：表格里的数值、表下的脚注、以及前面某一节对会计口径的说明。这三样很可能落在相隔几十页的位置，向量召回按语义相似度排序，脚注和口径说明的相似度通常排不进前几。模型拿到一个孤零零的数字，只能照着念，念错了也不知道。
多步检索把这个过程还原成人翻文件的样子。先定位，再展开，遇到”详见附注 12”就跳过去看，看完回来。grep 这个工具的存在尤其说明问题：向量搜索擅长语义模糊匹配，遇到 Note 12 这种精确字符串反而不如老式全文匹配可靠，两种检索方式在同一套工具里各管一段。
这里还藏着一个容易被忽略的收益。一次性检索的答案没法追溯，模型说营收是某个数，用户想知道它从哪一页拿到的，只能自己回去翻。多步检索的每一步都是显式的工具调用，打开了哪个文件、跳到了哪一节、匹配了哪个字符串，全都留在轨迹里。对金融和法务场景来说，这条链路本身就是交付物的一部分，答对了还要能证明为什么对。
多跑几轮反而更省
多步操作按常理会带来更多轮次、更多 token、更长等待。Mistral 给的数字反过来：token 用量最多降 33.7%，P90 延迟降 39.6%，FinanceBench 上从 255 秒压到 154 秒。
这组数字成立的前提是对比对象。一次性 RAG 为了保证召回，倾向于把召回块数开大，二十块八十块地往上下文里塞，其中大部分和问题无关。多步检索每轮只读需要的那一段，轮次多了，但每轮的输入很短，总量算下来省了。
延迟那一项更依赖工程实现。P90 降下来，说明尾部那些”检索失败、模型硬编、答案离谱、需要重跑”的长尾案例变少了。一次性检索的失败是静默的，模型不知道自己没拿到脚注；多步检索里模型能发现自己没找到，于是再搜一次，尾部反而被收窄。
中文场景要过的两关
Mistral 提供的方式是 Search Toolkit 和 Libraries，已经集成进 Studio 和 Vibe，支持云端和本地部署。本地部署这一条对金融、医疗、政务这类不能把文档外发的行业是硬需求，Mistral 一直把它当成对美国厂商的差异点。
这套东西搬到中文文档上会遇到两个新麻烦。一是 grep 在中文里没有词边界，精确匹配的收益比英文小，粗算下来命中噪音要高出一截；二是国内的招股书、年报、政策文件大量使用扫描件和非标准表格，read 这一步能不能把表格结构还原出来，直接决定后面几步是在读还是在猜。
另一个要留意的口径是基准本身。FinanceBench 和 OfficeQA Pro 都是公开题库，题目和文档早已在网上流传，任何一家厂商拿自家系统去刷，都存在被训练数据污染的可能。26.7% 这个起点低得有些扎眼，它对应的是哪种 RAG 配置、召回块数开到多少、用的是哪个基座模型，官方公告里没有拆开写。提升的方向可信，倍数得打个折扣看。
定价还没有公布。对企业采购来说这一项分量很重：多步检索的每次问答会产生多轮模型调用，如果按调用计费，86% 的准确率要用几倍的单价去换，账要重新算一遍。
参考来源：Mistral 官方公告、CocoLoop；FinanceBench 与 OfficeQA Pro 两组准确率、token 降幅与 P90 延迟数值逐项核对。