Mistral Agentic Searchは、モデルが組織の最も複雑なデータや文書を検索・ナビゲートできるようにすることで、企業がAIシステムからより良い結果を得られるようにします。 AIシステムが複雑な文書の内部でもナビゲートし、読み、情報を検証できるようにする検索レイヤー(retrieval layer)です。 Mistral Search Toolkitを通じて利用でき、StudioとVibeの両方のLibrariesに組み込まれています。また、Agentic SearchはMistral Search ToolkitとLibrariesを通じて利用可能です。
Mistral Agentic Searchは、機密性の高いドメイン固有データに対応します。Mistralのポータブルでオープンなツールにより、クラウドやオンプレミスの分離境界(isolation boundaries)を越えることなく、データから価値を引き出すことが可能です。
競争優位は、データ、プロセス、およびドメインの専門知識といった、長年の実世界の運用の上に築かれます。独自の知識は成功に不可欠であると同時に極めて機密性が高いため、分離境界、分割されたデプロイ、およびセルフホスト型プラットフォームの背後に存在します。こうした独自の知識は、金融の提出書類(financial filings)、法的契約書、社内リソース、および政府記録などに蓄積されます。これらは長く密度の高い文書であり、従来の検索手法では効果的にnavigateできません。
Mistral Agentic Searchは、データソースの保存場所を問わず、情報を見つけ、調べ、検証するマルチステップの検索ループ(multi-step retrieval loop)を導入します。モデルは取得したチャンクにとどまらず、長く密度の高い文書の内部や複数のソースにまたがってデータを検索・ナビゲートできます。インデックスは情報源になりそうなものを特定し、Agentic Search(エージェント型検索)は、その情報源の中と情報源どうしの間で何を調べるかを決める仕組みです。
継続的に学習し改善するエージェントは、競争優位を複利的に高める助けになり得ますが、こうしたエージェントはセキュリティ上の理由から、機密データや独自の知識から切り離されていることが多くあります。 AIで実際の効果を得るには、最先端の推論(reasoning)と、最も機微な素材に安全に到達できる検索ツール(retrieval tools)を組み合わせる必要があります。
ワンショットRAGの限界
従来のワンショットRAG(one-shot RAG)は、固定されたテキストチャンク(chunk)の集合を取得し、モデルに1回のパスで回答させます。答えが上位の検索結果のいずれかに含まれる場合には機能しますが、モデルが長いレポートをたどる、参照を追う、複数文書を比較する、あるいは根拠となる証拠を検証する必要がある場合には不安定になります。ワンショットRAGベースの検索は、フロンティアAIの能力を十分に活かせず、信頼できる回答を提供できません。その理由は3つあり、理由の一つは「推論なき検索(Retrieval without reasoning)」です。 「推論なき検索」では、モデルが最初の検索で選ばれた断片が不完全または無関係であってもそれに基づいて答えなければならず、回答前に別のドキュメントや別のセクション、あるいはより多くの文脈が必要だと判断できないため、モデルの推論の効果が制限されます。
ワンショットRAG(one-shot RAG)の限界は、密度が高く複雑なデータや文書でより顕著になります。質問に答えるために必要な情報が複数の文書にまたがっていたり、特定の表・脚注・条項の中に埋もれていたりすることがあるためです。例えば、「その企業の第3四半期の有効税率はいくらでしたか?」と尋ねられた場合、インデックス(index)は正しいドキュメントを見つけられても、それを `open` したり、表まで `navigate` したり、周辺のコンテキストを `read` したり、答えを検証したりすることはできません。
多くの質問は、正解にたどり着くのに複数回の検索(retrieval)を要します。モデルは、検索の絞り込み(refine)、有望なドキュメントの確認、参照の追跡、複数ソースの比較、見たものの記録、そして最初の結果が不十分な場合の新しい経路の試行を必要とすることがありますが、ワンショットRAG(one-shot RAG)にはこうした次の段階へ進む手段がありません。
5つのツールとモデル非依存の設計
エージェント型検索(agentic search)は、既存の検索インデックス(search index)を土台に構築され、`search`、`open`、`navigate`、`read`、`grep`の5つのツールで構成されます。エージェント型検索は、第1者(first-party)のモデルと第3者(third-party)のモデルのどちらでも同じ性能パターンが観察されるため、モデル非依存(model-agnostic)であり、新しいモデルが出れば検索品質は向上するはずだと、Mistralは述べています。
ベンチマーク結果と適した用途
FinanceBenchを用いた検証では、Mistral Agentic Searchは金融の提出書類に対する正答率を26.7%から86%へ、約3倍に高めます。SEC提出書類368件（10-K/10-Q/8-K、1件あたり平均約147ページ、合計約53,900ページ）を対象としたFinanceBenchでは、ワンショットRAG(one-shot RAG)から検索のみのループ(search-only loop)に移すと、精度はMM 3.5で+47.3pp、GLM-5.2で+52.6pp上がり、両モデルとも約3倍の改善となり、このエージェント型ループ(agentic loop)が品質面での最大の要因(lever)でした。検索のみのループは、モデルが反復的に検索できるため、最初の弱い結果から回復し、クエリを洗練し、インデックスを能動的なツールとして使えることが理由です。さらにFinanceBenchにおいて、検索のみのループに`open`、`navigate`、`read`、`grep`を加えると精度がさらに上がり、MM 3.5で+8.7pp、GLM-5.2で+6.7pp向上しました。Islamらによる2023年の研究であるFinanceBenchでは、SEC提出書類368件（10-K/10-Q/8-K、1件あたり平均約147ページ、合計約53,900ページ）を対象に金融質問応答のテストが行われています。これは、複雑な文書では、的を絞って掘り下げる検索が、広い検索の繰り返しに勝つということです。
例として、1953年の個々の暦月の報告値のみを使い、米国の国防および関連活動の支出(名目ドル、百万ドル単位)の合計はいくらかという質問があります。ツール呼び出し1回(searchのみ)の例では、`search("national defense expenditures monthly 1953")` が10件のヒットを返しました。それらは月次の速報(Table 3)が散在したもので、いずれも会計年度(fiscal-year)の枠組みで、1953年の一部しかカバーしていませんでした。このツール呼び出し1回の例では、モデルは1953年1月〜6月のデータは見つけたものの、答えを計算するには7月〜12月の月次値が必要だと判断しました。
ツール呼び出し3回(search 2回→read)の例では、2回の `search` の後に `read(treasury_bulletin_1954_02.pdf, p.15)` を実行し、1953年の全12か月分を載せた Table 3 の全体を取得します。Table 3の1953年の月次値(百万ドル)は、1月3,632、2月3,501、3月3,789、4月3,891、5月3,746、6月4,056、7月3,890、8月3,519、9月3,787、10月3,647、11月3,540、12月3,465で、1953年の12か月分の月次値の合計(Sum)は44,463です。
OfficeQA Proの表が多く複数文書にまたがる質問では、Mistralの測定では、Agentic Searchの正答率が6.3%から51.9%へ+45.6ポイント向上しました。Mistral Agentic Searchは、的を絞ったナビゲーション(targeted navigation)によって、p90レイテンシ(latency)を最大39.6%削減できます。繰り返しの検索が減ることで、トークン消費も最大で3分の1削減されます。検索ツールは追加のオーバーヘッドではなく、無駄な検索のやり直しを的確なナビゲーションに置き換えます。一般に、検索のみのループは広い検索を繰り返し行うのに対し、ナビゲーションはモデルが根拠をより速く特定するのに役立ちます。
エージェント型検索は、Mistral Search Toolkitで作ったインデックスの上に構築され、モデルにファイルシステム操作に似た5つのツールを与えます。モデルは最初のtop-*k*の結果だけで回答するのではなく、見つけたものを調べ、検索を絞り込み、関連ドキュメントを`open`し、特定のセクションへ移動し、回答する前に元の資料を`read`することができます。
Mistral Agentic Searchは既存の検索インデックスの上に構築され、`search`、`open`、`navigate`、`read`、`grep` の5つのツールを使います。エージェント型検索のツールには、ファインチューニング(fine-tuning)やモデル固有の訓練は不要です。モデルの推論とツール使用が向上するにつれて、インフラを変更しなくても検索の質は向上します。検索の質はチャンク分割戦略(chunking strategy)で上限が決まるのではなく、モデルの能力に応じて伸びます。`search`は既存のインデックスを使ってコーパス全体から関連文書を見つけ、`open`は特定の文書を開き、`navigate`はその中のページ・セクション・領域へ移動します。`read`はその位置の内容を取得し、`grep`は開いた文書の中でパターンを見つけます。
インデックス検索(indexed retrieval)は、直接的な検索(direct lookups)の出発点として適しています。短くて整った文書で、答えが最初に取得されるチャンクのいずれかに現れそうな場合が該当します。また、大量の検索(high-volume search)の出発点としても適しており、キーワード検索やセマンティック検索で、関連する箇所を、それらを推論したりたどったりせずに返す必要がある場合に該当します。さらに、単純で予測可能な質問の出発点としても適しています。答えがありそうな情報源と場所があらかじめ分かっており、追加の検索ステップで結果が改善しそうにないユースケースが該当します。直接的な検索、大量の検索、単純で予測可能な質問といった検索には、ワンショットRAG(one-shot RAG)で十分なことが多いです。質問で、モデルが最初の結果を超えて元の資料を調べる必要がある場合に、エージェント型検索を追加します。どちらの場合も、適切に構成されたインデックスが正しい土台であり続けます。
エージェント型検索は長い文書に向いています。提出書類、契約書、マニュアル、技術仕様書、報告書などで、答えが特定のページや、特定の表・条項・図・脚注にある場合が該当します。また、複数の情報源にまたがる質問にも向いています。モデルが答えにたどり着く前に、複数の文書から根拠を見つけ、比較し、または突き合わせて整合させる必要があるリサーチが該当します。さらに、検証が必要な回答にも適しています。財務数値、法的条項、規制の参照、運用データなどで、回答を文書内の安定した特定の位置として参照できる場合が該当します。表や構造化文書にも向いています。財務諸表、政府記録、スキャンされたPDFなどで、意味が物語的なテキストだけでなく、行・列・ページ上の位置・周辺の文脈に依存する場合が該当します。
エージェント型検索は、2つの業界標準の評価において、すぐに使える状態のMistral Search Toolkitスタックを用いてベンチマークされました。このテストでは、デフォルトのチャンク分割(chunking)、デフォルトのランキング、およびチューニングなしという構成が使用されています。ベンチマークの結果は下限を示すものであり、ユースケースに特化したチューニングを行うことで、結果の質をさらに改善することが可能です。
このベンチマークでは、Mistral Search Toolkitを使用して2つのモデルがテストされました。小さいモデルであるMistral Medium 3.5(MM 3.5)と、大きいモデルであるZ.ai GLM-5.2(GLM-5.2)のそれぞれの性能が示されています。
OfficeQA Proは、表の多いスキャンされた政府財政のPDFからなる696文書・約89,000ページのコーパス(corpus)を用いたベンチマークで、133問の「pro」サブセットについて初回の結果(first pass)が報告されています。
FinanceBench全体で、ナビゲーション用の検索ツールを加えるとレイテンシが改善しました。p90は255秒から154秒に、平均レイテンシは108秒から71秒に下がりました。ナビゲーションを含むフルのエージェント型ループは、検索のみのループより少ないトークンで、より多くの質問に正しく答えることができました。MM 3.5ではトークン使用量が-23.9%、GLM-5.2では-33.7%となりました。ベンチマーク結果は一貫しており、エージェント型ループは品質を実質的に改善し、ナビゲーションツールは無駄なトークン、ターン数、レイテンシを減らしつつ精度を高めます。
Mistral Search Toolkitは、重要で複雑なデータを取り込み(ingest)、埋め込み(embedding)し、インデックス化するためのオープンなモジュールを提供します。このツールキットはクラウドでもオンプレミスでも使えます。また、エージェント型検索を自分のエージェント、ワークフロー、顧客向けデプロイに組み込むためのものです。 もう一つの選択肢であるLibrariesを使うと、検索システムを自分で構築せずに、StudioとVibeでAgentic Searchをそのまま使えます。
OfficeQA Proは、米国財務省の過去の財務省報告(Treasury Bulletins)を対象にした検証可能な数値ベンチマークであり、スキャンされた表の多い政府財政PDFで、696文書・約89,000ページのコーパスからなります。数値の答え、スキャンPDF、深い表の参照を伴う、より難しいベンチマークでもあります。 OfficeQA Proにおいて、フルのエージェント型ループはワンショットRAGから精度を大きく引き上げ、GLM-5.2で51.9%(+45.6pp)に達し、MM 3.5では+27.1pp上がりました。ナビゲーションを加えたフルのループ（エージェント型ループ + ナビゲーション）を使用すると、トークン消費を減らしつつ精度が最大35.6%向上し（MM 3.5で+7.5pp、GLM-5.2で+8.3pp・19.0%）、ターン数は最大7.0%(MM 3.5)、2.3%(GLM-5.2)減少しました。ベンチマークが難しいほど、検索ループは重要になります。ワンショットRAGはほとんど前に進めない一方、エージェント型ループではモデルが反復的に検索し、根拠を確認して、精度を大きく改善できます。
OfficeQA ProにおけるZ.ai GLM-5.2(GLM-5.2)のスコアは、Kimiの調査によると、Claude Codeハーネス(harness)で41.4%でした。これに対し、Mistralのハーネスでは51.9%でした。同じ基盤モデルを使用した場合でも、Mistralハーネスの方が+10.5pp高い結果となっており、ツーリングスタックはドキュメントインテリジェンス(document intelligence)と検索性能に大きな影響を与えます。
自分のユースケース向けに設定する段階では、取り込み(ingestion)を設定し、データとファイル形式に合わせてパーサー、チャンク分割戦略、埋め込みモデル、エクストラクターを選べます。また、インデックス作成とランキングをチューニングし、Vespaスキーマ、インデックス作成の挙動、関連度プロファイルを管理できます。さらに、検索を拡張して、検索パイプラインにクエリ書き換え、リランキング、ハイブリッド検索を追加することも可能です。Search Toolkitを試す最速の方法はSearch Starter Appです。デフォルト設定で自分のコーパス用のローカルインデックスを作成するため、検索の専門家でなくてもエージェント型検索を試せます。