通常の検索やRAGと何が違う？ Mistralの「Agentic Search」は文書を巡回して裏取りする

社内文書QAやチャットボットで使われる「RAG」は、質問文に近い文章のかたまり（チャンク）をベクトル検索で数個引っ張ってきて、それをLLMに読ませて答えさせる仕組みだ。手軽で強力だが、弱点もはっきりしている。関連しそうな断片を一発で取ってくるだけなので、「表とその注釈が別ページにある」「複数の資料を突き合わせないと答えが出ない」といった質問には途端に弱くなる。取ってきたチャンクが的外れでも、モデルはそのまま答えを作ってしまう。

8月20日、Mistralが発表したAgentic Searchは、この「一発検索」の限界に対する回答だ。ひとことで言えば、検索を一回のクエリで終わらせず、AIエージェント自身が文書のなかを巡回し、読み、裏取りしながら答えにたどり着く検索レイヤーである。

「探して、開いて、確かめる」を繰り返す

Agentic Searchが従来のRAGと決定的に違うのは、検索が一往復で終わらない点にある。エージェントに5つの道具が与えられる。search（検索）、open（開く）、navigate（移動）、read（読む）、grep（文字列で絞り込む）だ。

人間が調べ物をするときの動きを思い浮かべると分かりやすい。まず検索でアタリをつけ、めぼしい文書を開き、目次や章を移動し、該当箇所を読み、必要なら特定のキーワードで文書内を絞り込む。Agentic Searchはこの一連の動作をエージェントにやらせる。「見つける→調べる→検証する」というループを回すことで、単なる類似チャンク検索では届かなかった情報にたどり着く、という設計思想だ。

しかも既存の検索インデックスの上に載せられる。ゼロから作り直すのではなく、いま持っている検索基盤に巡回・検証のレイヤーを足すイメージになる。

公式が示す数字と、その受け止め方

Mistralはいくつかのベンチマーク結果を出している。財務書類を対象にしたFinanceBenchでは正答率が26.7%から86%へと約3倍に。表が多く複数文書をまたぐOfficeQA Proでは6.3%から51.9%へと+45.6ポイントの改善を示したという。速度・コスト面でも、狙い撃ちの巡回によってp90レイテンシを最大39.6%削減、繰り返し検索が減ることでトークン消費を最大3分の1削減したとしている。

数字だけ見れば派手だ。ただ、ここは冷静に見ておきたい。これらはいずれもMistral自身が自社の条件で測った公式主張であり、第三者による再現検証を経たものではない。FinanceBenchの元の26.7%という低さは、平均147ページに及ぶSECの複雑な提出書類という、素のRAGが最も苦手とする土俵で測られている。得意な相手に強い、というのは割り引いて読むべきだろう。実運用でどこまで効くかは、自分たちのデータで試すまで分からない。

もうひとつ個人的に気になるのは日本語だ。英語の財務・オフィス文書での性能は示されたが、日本語の契約書や社内Wikiでgrepや巡回がどこまで賢く効くのかは未知数。ここは実際に触ってみないと評価できない部分だ。

どこで効くのか、どう位置づくのか

刺さりそうな用途は具体的だ。分厚い契約書や仕様書からの条項の横断確認、複数の論文やレポートを突き合わせる調査、社内規程や監査資料のQA——要は「一箇所を読めば済まない」種類の質問である。エージェントに組み込めば、調べ物を人間の代わりに何往復も回してくれるので、リサーチ系のワークフローと相性がいい。

競合との違いも見えてくる。PerplexityやOpenAIの検索はどちらかというとWeb全体を対象にした「調べ物AI」寄りだが、Agentic Searchは自社が持つ文書インデックスの内部を深く掘る方向に振っている。Web検索の置き換えというより、社内ナレッジや専門文書に対する精密な検索レイヤーという立ち位置だ。

提供形態は2通り。カスタム構築向けにはSearch Toolkitから利用でき、手早く使いたい場合はMistralのStudioやVibeに組み込まれたLibrariesとして呼び出せる。以前解説したSearch Toolkitの延長線上にある機能で、Mistralが「検索」を自社スタックの軸のひとつに据えようとしている流れがよく分かる。

RAGの次の一手として、方向性そのものは正しいと思う。あとは公式ベンチの外側、つまり自分の泥臭い文書で試したときにどれだけ粘れるか。そこが本当の評価ポイントになる。