查份合同要翻半天？Mistral 新方案让 AI 准确率翻三倍

计算机魔术师 2026-08-21 0 阅读13分钟

你让 AI 查一份 200 页的招股说明书，它大概率会给你编一个看起来合理的答案。这不是模型不够聪明，是检索方式出了问题。

为什么传统检索在复杂文档前失灵

单次查询的致命缺陷

传统 RAG 系统的流程是线性的：用户提问 → 向量检索 → 返回 Top-K 片段 → 模型生成答案。这个流程在简单问答场景下表现尚可，但面对复杂文档时暴露出三个致命问题。

第一，单次检索无法处理多跳推理。当问题需要跨多个章节、多份文件交叉验证时，一次向量相似度搜索只能返回局部最相关的片段，丢失了全局上下文。比如询问「某公司近三年关联交易披露是否完整」，需要同时定位关联交易章节、财务附注、董事会决议等多个位置，传统检索只能命中其中一个。

第二，检索结果缺乏验证机制。模型拿到检索片段后直接生成答案，无法回溯验证信息来源的可靠性。当检索结果存在矛盾或模糊表述时，模型倾向于选择看起来最合理的答案，而非最准确的答案。这正是「幻觉」高发的根源。

第三，固定 Top-K 策略与问题复杂度脱节。简单问题可能只需要 3 个片段，复杂问题可能需要 20 个片段甚至更多。传统 RAG 无法动态调整检索深度，要么信息不足，要么上下文窗口被无关内容淹没。

从「找文档」到「找答案」的范式转变

Mistral 在 2026 年 8 月 20 日发布的 Agentic Search 试图解决上述问题。其核心思路是：让 AI 不再被动接收检索结果，而是主动规划检索路径、动态调整搜索策略、验证信息来源。

这套方案在 FinanceBench 基准测试中表现突出。该测试包含 368 份 SEC 文件、约 53,900 页内容、150 个复杂问题。使用 Mistral Medium 3.5 模型，传统单次检索 RAG 准确率为 26.7%，而 Agentic Search 提升至 86%，提升幅度超过 47 个百分点。

准确率跃升的背后，是检索范式的根本转变。传统 RAG 将检索视为「找文档」，目标是返回与查询最相关的文本片段。Agentic Search 将检索视为「找答案」，目标是构建完整的证据链，确保每个结论都有可追溯的来源。

这种转变的代价是延迟。完整导航循环的平均延迟为 71 秒，p90 延迟达 154 秒。对于追求实时响应的应用，这个延迟不可接受。但对于需要高准确率的金融合规、法律尽调等场景，数分钟的等待是合理的交换。

##为什么传统检索在复杂文档前失

Mistral 的五步循环是怎么工作的

search → open → navigate → read → grep

Agentic Search 的核心是一个多步检索循环，模型在每次调用工具后都能基于返回结果决定下一步动作。Mistral 为此提供了五个工具：search 负责在向量索引中执行语义检索，返回候选文档片段；open 用于打开完整文档，获取上下文；navigate 允许模型在文档内部跳转，比如从目录跳到具体章节；read 读取指定页码或段落的内容；grep 则执行关键词匹配，用于定位特定条款或数字。

这五个工具不是串行执行的，而是由模型在每次推理时自主决定调用顺序和次数。一个典型的查询流程可能是：先用 search 找到相关段落，再用 open 打开完整文档，接着用 navigate 跳转到目标章节，然后用 read 读取具体内容，最后用 grep 验证关键数字。模型在每一步都会评估当前信息是否足够回答问题，如果不够，就继续调用工具。

多步验证如何把准确率拉到 86%

FinanceBench 测试包含 368 份 SEC 文件，约 53,900 页内容，以及 150 个需要多跳推理的问题。传统单次检索 RAG 的准确率为 26.7%，而 Agentic Search 在仅使用搜索循环时将准确率提升了 47 至 53 个百分点，启用完整导航循环后最高可提升 59 个百分点，最终达到 86%。

准确率提升的关键在于验证机制。传统 RAG 只检索一次，模型基于返回的片段直接生成答案，容易受到检索噪声的影响。Agentic Search 则允许模型在检索后继续追问：如果返回的片段不够明确，模型可以打开完整文档重新定位；如果某个数字存疑，模型可以用 grep 重新搜索验证。这种多步验证减少了幻觉，也提高了对复杂问题的处理能力。

Token 节省与延迟代价的权衡

Mistral 官方数据显示，完整导航循环相比仅搜索循环，Token 用量最多降低约三分之一。这是因为多步验证让模型能够精确定位到所需信息，而不是检索大量无关片段。然而，延迟是明显的代价：完整循环的平均延迟为 71 秒，p90 延迟达 154 秒。相比之下，传统 RAG 的响应时间通常在 1–2 秒内。

这套方案适合 SEC 文件、合同、扫描件等需要高精度回答的场景，但不适合追求实时响应的应用。如果你的业务场景允许用户等待数分钟，Agentic Search 是一个值得考虑的选择；如果需要秒级响应，传统 RAG 或缓存策略可能更合适。

##Mistral的五步循环是怎

适用场景与边界在哪

SEC 文件、合同、扫描件：Agentic Search 的主场

Agentic Search 的设计目标非常明确：处理那些「答案藏在细节里」的文档。FinanceBench 测试用了 368 份 SEC 文件，平均每份约 147 页，问题涉及财务条款、风险披露、管理层讨论等需要跨段落推理的内容。这类文档的共同特征是：关键信息分散、表述复杂、需要交叉验证。

合同场景同理。一份 50 页的采购合同，违约责任条款可能在第 3 章，赔偿上限在第 8 章，而定义条款在第 1 章。传统 RAG 把整份合同切成 chunk 后检索，往往只能命中局部片段，模型拿到的是碎片，自然容易「幻觉」出看似合理的答案。

扫描件更是重灾区。OCR 后的文本质量参差不齐，页码混乱，表格结构丢失。单次检索几乎不可能定位到准确位置，而 Agentic Search 的 navigate 和 grep 工具可以逐页扫描、按关键词精确定位，再配合 read 工具提取上下文，形成完整的证据链。

Mistral 官方在公告中明确列出了适用场景：监管申报文件、合同、扫描版 PDF。这三类文档的共同点是「准确率比速度更重要」——你宁愿等 71 秒拿到一个可信的答案，也不想要 2 秒内得到一个可能出错的结果。

实时性要求高的场景：别用

延迟是这套方案最明显的代价。FinanceBench 测试中，完整导航循环的平均延迟是 71 秒，p90 达到 154 秒。相比之下，单次检索 RAG 的延迟通常在 1–3 秒。

这意味着什么？如果你的应用场景是客服问答、实时对话、或者任何用户需要「即时反馈」的场景，Agentic Search 不合适。用户不会愿意等两分钟等一个答案，哪怕这个答案更准确。

更准确地说，延迟不是固定值。它取决于文档数量、问题复杂度、以及循环次数。简单问题可能只走 search → read 两步，几秒内返回；复杂问题可能需要多轮 navigate 和 grep，耗时数分钟。这种不确定性本身也是工程上的风险——你无法为 SLA 提供稳定的承诺。

Token 消耗也是考量因素。虽然 Mistral 声称完整循环比仅搜索循环节省约 24%–34% 的 Token，但绝对值仍然远高于单次检索。如果你的成本模型对 Token 敏感，需要仔细评估 ROI。

与 Naive RAG、File Search 的选择逻辑

选择检索方案不是二选一，而是根据问题复杂度分层。

Naive RAG 适合简单的事实查询：「某条款的定义是什么」「某页提到了哪个数字」。这类问题答案集中在局部，单次检索就能命中，延迟低、成本低，是默认选项。

File Search 适合中小规模文档库的探索性查询：「这份合同里有没有关于知识产权的约定」。它比 Naive RAG 多了一步语义索引，但仍然是一次性检索，适合答案相对集中的场景。

Agentic Search 适合复杂的多跳推理：「如果对方违约，赔偿上限是多少，是否受不可抗力条款影响，引用具体条款原文」。这类问题需要跨段落、跨章节、甚至跨文档的推理，单次检索无法覆盖。

业内常见的做法是构建一个复杂度分类器：在用户提问后，先用轻量模型判断问题属于简单、中等还是复杂，然后路由到不同的检索管道。简单问题走 Naive RAG，中等问题走 File Search，复杂问题才启用 Agentic Search。这样既控制了成本，又保证了准确率。

Mistral 的 Search Toolkit 提供了这种分层能力。你可以在 Studio 或 Vibe 中配置不同的检索策略，根据场景动态切换。官方文档建议：「如果你的文档库规模在 1000 份以下，问题以事实查询为主，优先使用 File Search；如果文档规模超过 1000 份，或者问题涉及多跳推理，再考虑 Agentic Search。」

选择的核心逻辑是：准确率需求与延迟容忍度的权衡。当准确率是硬约束、延迟可以接受时，Agentic Search 是合适的选择；当速度优先、准确率可以妥协时，Naive RAG 或 File Search 更经济。

这套方案的真正价值不在于替代现有检索，而在于填补了「复杂文档理解」这一空白地带。它让 AI 从「快速给出一个答案」转向「认真找到一个答案」，代价是时间和 Token。在合同审查、合规检查、财务尽调等场景，这个代价是值得的。

##适用场景与边界在哪###SE

传统检索的致命缺陷

单次查询的 RAG 系统，本质上是把问题丢进向量库，取回 Top-K 片段，再让模型基于这些片段作答。问题在于，复杂文档的答案往往分散在多个章节，甚至需要跨文档交叉验证。模型拿到的是碎片，却要被要求给出完整结论。幻觉不是模型的问题，是检索策略的缺陷。

Mistral 五步循环机制

Agentic Search 的核心是一个五步循环：search 定位候选文档，open 读取全文结构，navigate 跳转到相关章节，read 提取具体段落，grep 验证关键数据。模型在每一步都可以决定下一步动作，而不是被动接受检索结果。

FinanceBench 测试覆盖 368 份 SEC 文件、约 5.4 万页内容、150 个问题。启用完整导航循环后，准确率从 26.7% 跃升至 86%，提升 59 个百分点。更意外的是，Token 用量反而减少了约三分之一——因为模型不再需要读取大量无关片段，而是精准定位到答案所在。

##Mistral五步循环机制A

适用场景与边界

Agentic Search 的主场是 SEC 文件、合同、扫描件这类结构复杂、答案分散的文档。它不适合实时性要求高的场景，比如客服问答或即时搜索。与 Naive RAG 相比，它在复杂文档上优势明显；与 File Search 相比，它在多跳推理上更胜一筹。

企业落地的现实考量

延迟 71 秒意味着什么

平均 71 秒、p90 达 154 秒。这意味着用户提问后需要等待近两分钟才能得到答案。对于内部研究工具、合规审查、法律尽调这类场景，这个延迟可以接受。对于面向用户的实时应用，这是不可接受的。

延迟的来源是多步循环：每次 search、open、navigate、read、grep 都是独立的 API 调用，模型需要在每一步做出决策。循环次数越多，延迟越长。FinanceBench 上的平均循环次数约为 8 到 12 步。

成本与收益的量化

准确率从 26.7% 提升到 86%，意味着原本需要人工复核的答案，现在可以直接采用。对于法律、金融、合规这类错误成本极高的场景，这个提升是质的变化。

Token 用量减少约三分之一，意味着单次查询成本下降。但延迟增加意味着单位时间内的查询吞吐量下降。如果团队原本每天处理 1000 次查询，现在可能只能处理 100 次左右。成本结构从「按 Token 计费」转向「按时间计费」。

从试点到生产的路径建议

第一步，选一个错误成本高的场景做试点。合规审查、合同条款提取、SEC 文件分析都是合适选择。不要从客服问答开始，那里的延迟不可接受。

第二步，建立人工复核机制。即使准确率提升到 86%，剩余的 14% 错误也可能是致命错误。试点阶段保留人工复核，记录错误类型，用于优化检索策略。

第三步，评估延迟影响。让目标用户实际使用，记录等待时间、放弃率、满意度。如果用户愿意等待两分钟换取准确答案，就可以进入生产。

第四步，设计降级策略。当延迟超过阈值或循环次数过多时，自动降级为单次检索，返回部分答案并标注置信度。这比返回一个错误答案更好。

准确率从 26% 跳到 86%，差的不是模型，是检索策略。多步检索不是让 AI 读得更快，而是让 AI 读得更认真。企业在引入这套方案时，需要明确自己的场景是否匹配：答案分散、错误成本高、延迟可接受。如果不满足这三个条件，Naive RAG 或 File Search 可能是更务实的选择。

##企业落地的现实考量###延迟

你让AI查一份200页的招股说明

你让AI查一份200页的招股说明

参考文献

[1] Mistral 推出Agentic Search：多步检索提升复杂文档查询准确率. omnitools.ai/news/news_m… [2] Mistral 推出Agentic Search：多步检索提升AI 系统复杂文档查询准确率 .... bbs.znt.group/moments/rss… [3] Mistral推出Agentic Search，多步检索将复杂文档准确率提升至86%. article.9466.com/news/BKNn2X… [4] Mistral Agentic Search 是什么？实测数据说明了什么. aireiter.com/zh/blog/mis… [5] Agentic Search. More accurate and efficient results from your AI systems.. mistral.ai/news/agenti… [6] Mistral Agentic Search: 3x más precisión en documentos complejos – El Ecosistema Startup. ecosistemastartup.com/mistral-age… [7] Introducing Search Toolkit | Mistral AI. mistral.ai/news/search… [8] Mistral AI 发布 Agents API，内置代码执行、网络搜索等工具 - OSCHINA - 中文开源技术交流社区. www.oschina.net/news/[REDAC…