Mistral 發布 Agentic Search：檢索層而不是新模型
法國 AI 公司 Mistral 本週在官方部落格發布 Agentic Search。它不是一個新模型，而是一層檢索基礎設施：官方公告把 Agentic Search 定義為讓 AI 系統能夠在最複雜的文件內「導航、閱讀並驗證資訊」的檢索層，並說明它建在你既有的搜尋索引之上，靠五個工具運作。換句話說，過去開發者把檢索當成「生成答案前的一次查詢」，Mistral 現在把它升級成模型可以反覆操作、自己決定下一步的工作流程。
「驗證」是這個定位裡最值得注意的字。一般 RAG 管線的順序是：文件切塊、向量化、按相似度取回前幾名、直接生成答案——模型拿到什麼就用什麼，沒有回頭檢查的機制。Agentic Search 的設計前提則相反：檢索結果只是素材，模型要自己判斷證據夠不夠，不夠就繼續找，找到了還要核對原文。文件越長、表格越深，這兩種做法的差距就越明顯。
五個工具拆解：search、open、navigate、read、grep
依公告說明，Agentic Search 建在既有搜尋索引上，提供五個工具：search 對索引下查詢、找出候選文件；open 打開其中一份；navigate 在文件內移動位置；read 讀取內容；grep 則是在同一份文件內搜尋精確的字詞或詞組、直接跳到它出現的位置。最後這個工具最能看出設計意圖——官方文件描述，grep 讓模型在同一份文件內以精確字詞定位到特定區域，就像開發者在程式碼庫裡用 grep 找某個函式名稱一樣，是字面層次的定位，不靠語意相似度猜測。
五個工具合起來，等於把「查資料」還原成人的動作：先搜尋找到可能相關的文件，翻開它，跳到大概的位置，逐段讀，讀不到再用關鍵字精確定位。對長文件來說這個差別很實際：一份三百頁的年報，問題只需要第七章的一張表，與其把整份文件塞進上下文，不如 open 之後 navigate 到對的章節、read 那一段，必要時 grep 表格的欄位名稱。差別在於這套動作由模型循環執行，而且每一步都是一次可觀測的工具呼叫，工程團隊可以追蹤模型到底翻了哪些文件、停在哪一頁。
核心機制：答案不在第一個檢索結果時，模型自己繼續挖
官方文件對適用情境的描述很直白：當答案不在第一個取回的區塊裡，傳統做法要不就是硬答，要不就是換句話重複同樣的搜尋。Agentic Search 的解法是讓模型檢視來源、蒐集足夠證據之後才回答——檢索從「一次丟擲」變成「多步工作流」，而每一步都把閱讀範圍收得更窄：先鎖定文件，再鎖定頁，再鎖定段落，最後鎖定那一行數字。
這裡有一個工程直覺上的疑問值得回答：多走好幾步，速度和成本不是應該更差嗎？Mistral 給出的答案相反，理由在於單次檢索的浪費方式不同。單次檢索為了保險，往往一口氣取回大量「可能相關」的區塊，這些內容全部要塞進上下文視窗計費、計算；定向導航讓模型只讀真正需要的部分，重複搜尋變少，token 用量與延遲反而下降。
這也解釋了為什麼公告強調「建在你既有的搜尋索引上」：Agentic Search 不是另一套向量資料庫，而是在你已經建好的檢索基礎上——無論那個索引是百萬筆還是百億筆向量——加一層會自己走路的查詢邏輯。對已經投資向量檢索基礎設施的團隊，這是「加購」而不是「重練」。
數字：FinanceBench 正確率 26.7% 到 86%，p90 延遲最多降 39.6%
公告給出的旗艦數字來自金融文件問答：在 FinanceBench 基準上，正確率從單次檢索的 26.7% 提升到 86%，官方以「3 倍正確率」形容這個差距。效率面同一份公告也有一組數字：對 FinanceBench 與 OfficeQA Pro 兩個基準，Agentic Search 在提升正確率的同時減少輪數、token 用量與延遲，定向導航讓 p90 延遲最多降低 39.6%。兩組數字要合在一起讀：正確率講的是「找得到答案」，延遲與 token 講的是「找到的代價」，代理式檢索同時改善了兩者，這是它與「多想幾步所以更慢」的直覺最大的不同。
26.7% 這個基準值得停下來看。它通常不代表「模型不會算」，而是單次檢索在長財報、多表格、多文件的問題上一開始就取回錯的區塊——模型再強，也回答不出取回範圍之外的數字。86% 表示瓶頸出在檢索這一環，而這一環被補上了。不過要誠實地說：這是 Mistral 自家挑選並公布的基準，情境偏金融文件，辦公文件（OfficeQA Pro）官方同樣列有效率改善，但不同產業的文件結構差異很大，實際效果仍要拿自己的語料驗證。
從單次 RAG 到代理式檢索：產業位置與接入方式
把 Agentic Search 放回產業脈絡，它屬於近兩年「代理式檢索」路線的一部分：與其把檢索能力焊死在訓練裡，不如給模型工具、讓它自己檢索。編碼代理圈很早就把這套做法跑熟——在程式碼庫裡靠字面搜尋、讀檔與目錄導覽定位答案，而不是把整個儲存庫塞進上下文；Mistral 把同樣的思路搬到企業文件，對準財報、合約、技術手冊這類「答案存在但不好找」的長文件。
接入方式上，官方文件說明 Agentic Search 可以作為一組 MCP 工具裝進任何代理框架，也可以單獨使用。這對架構選型有實際意義：檢索層與模型層可以分開決定——檢索工具用 Mistral 的，問答模型維持自家的，兩者用 MCP 這個標準介面接起來。
檢索基礎的起點也有公開程式碼：Mistral 在 GitHub 上提供 search-starter-app 儲存庫，官方將它定位為「建立、管理與改進搜尋引擎」的基礎模板。這代表檢索層的建法本身是可審視、可替換的——團隊可以從公開模板起步自建索引與查詢管線，而不是把文件處理的全部假設都交給單一供應商。
MCP 之所以關鍵，在於它把「工具」變成標準化介面：代理框架這邊不必為每個檢索服務寫專屬接頭，檢索服務那邊也不必綁死單一框架。對企業來說，這代表檢索層可以獨立評估、獨立替換，代理應用的其他部分不受影響——當檢索品質直接決定答案對錯時，這種可替換性正是採購時最該在乎的性質。
對開發者與企業的實際影響
最直接受影響的是三類應用：企業知識庫問答、客服與法遵查證，以及所有「答案在文件裡但文件很長」的場景。其中 grep 工具的價值容易被低估：條款編號、產品代號、會計科目這類精確字串，在嵌入空間裡常因語意相近而互相混淆，字面定位反而可靠——這正是開發者工具把 grep 放進工具箱幾十年的原因，現在它被搬進文件檢索。
想評估的團隊，驗證方法可以很具體：挑自家最難回答的文件問答案例，跑一次現有 RAG 管線與 Agentic Search，對比正確率、輪數與 token 成本，再決定要不要換檢索層。導入成本也因此降低：既然建在既有索引上，資料不必搬家，先在小範圍文件集上試跑，再決定是否擴大。也要記得上限仍在文件品質——掃描件辨識錯誤、表格破碎、索引更新不及時，工具再多也救不了。
限制與值得追蹤的後續
最後誠實面對這次發布的邊界。第一，所有基準數字都是 Mistral 自行公布，AIDM 未獨立實測，第三方覆核也還沒出現。第二，金融文件情境的改善，不一定能線性外推到其他產業的文件結構，中文文件、掃描文件與混合格式文件的表現尤其需要自行驗證。第三，代理式檢索把檢索的不確定性，轉換成代理循環的不確定性——模型可能在錯的文件裡打轉，輪數與 token 上限的控制、每一步的可觀測性，都變成導入時必須設計的工程。
後續值得追蹤三件事：官方是否釋出更完整的評測方法與基線設定、實際定價與用量計費方式，以及它與其他代理框架整合後的第三方實測。在那之前，把 Agentic Search 當成「檢索層多了一個認真做代理式檢索的選項」，會比當成「RAG 的終點」更準確。
