エージェントが検索スタックを代替できるか？

あなたの職場では検索はどのように実装されていますか？おそらく、取得機能の上に構築された複雑な能力のセットとしてでしょう。私たちの検索 API はクエリを理解し、バックエンドの検索システムを呼び出し、最後に結果を再ランク付けします。 しかし、ループ内にエージェントがあれば、それらすべてが必要でしょうか？検索バックエンドをエージェントに置き換えることはできるのでしょうか？結局のところ、エージェントはユーザーのリクエストを理解し、取得ツールを呼び出し、関連性を自ら評価します。ChatGPT はこれを常に行っていますが、なぜ私たちの検索バーではできないのでしょうか。 つまり、基本的な BM25 バックエンドをエージェントに与えれば、それは検索 API の仕事を引き継ぐことができるでしょうか？ ## シンプルなツール使用で驚くほど良い結果 実は、[初期の発見を測定しました](https://github.com/softwaredoug/search-experiments)（[過去よりも少し深く分析しています](https://softwaredoug.com/blog/2025/10/06/how-much-does-reasoning-improve-search-quality)）。エージェントに基本的な検索ツールを与え、ポップコーンを用意して観察しました。 Amazon ESCI では、わずかに優れた取得機能と LLM（大規模言語モデル）を組み合わせた場合、性能が向上する様子が見られます。 まず、bm25+[e5_embedding](https://huggingface.co/intfloat/e5-base-v2) のベースラインから始めます。それぞれ 0.289 と 0.314 の NDCG を達成します。 次に、3 つのエージェント実験を測定しました。それぞれ GPT-5-mini が異なる検索ツールの組み合わせを駆動しています。e5 埋め込みを使用するエージェントは 0.359、BM25 を使用するのは 0.385 のスコアを出しました。両方を使用すると 0.410 になります。 GPT-5 が両方のツールを使用した場合は NDCG が 0.453 になりました。 ![image](https://softwaredoug.com/assets/media/search-apis-replaced-by-agents/image.png) これが素晴らしいのは、私がほとんど手を動かしていないからです。単に標準的な大規模言語モデル（LLM）にいくつかの検索ツールを設定しただけです。ここに私のデータに合わせて調整された要素は一つもありません。品質が 0.289 から 0.453 に向上したのは、モデルの質と単純な検索エンジン（retrievers）の結果に過ぎません。 もしエージェントが十分に高速であれば、API を使わずにエージェントで検索を構築する未来があるのでしょうか？ユーザーに対して最適な結果を示すためにクエリについて推論を行うエージェントの世界が実現されるでしょうか？ ## しかし、エージェントは検索を約 1 回しか呼び出さない これらのエージェントはどのような巧妙な戦略を採用しているのでしょうか。実は大部分の場合、各検索ツールを約 1 回だけ呼び出しています： ![image](https://softwaredoug.com/assets/media/search-apis-replaced-by-agents/image%201.png) 推論の追跡（reasoning traces）を見ると、エージェントが検索結果を解釈し、単一のクエリを発行し、最大 20 件までの結果を取得し、それらをランク付けしている様子がわかります。 ごく稀に、BM25 のみを使用する場合に、2 つの並列検索が行われることがあります。例えば、「PVC coupler」の場合、まず「pvc coupler」で BM25 検索を行い、エージェントがその結果に失望してフォローアップクエリ（PVC pipe coupler）を発行するといったケースです： Calling search_bm25 with args keywords='pvc coupler' top_k=20 **PVC カップラーの検索** 検索結果をみると、主にネットワークケーブル用の RJ45 カップラーが返されており、ユーザーが意図した内容とは異なるようです。おそらく彼らが求めているのは、配管で使用される PVC パイプ用カップラーでしょう。現在の検索ツールでは、PVC パイプ用カップラーに特化したエントリは得られていません。説明の中に PVC という単語の言及は見受けられますが、より明確な結果を得るためには、より広範なキーワードを使用する方が良いでしょう。「PVC pipe coupler」や「PVC coupling」といった用語に焦点を当てて検索を絞り込む必要があるため、次はそのように試してみます。 Calling search_bm25 with args keywords='PVC pipe coupler' top_k=20 また、エージェントが BM25 を使用して、結果の不一致を見越して同時に 2 つのクエリを発行するケースも確認できます: Calling search_bm25 with args keywords='AN10 oil catch can no filter' top_k=20 Calling search_bm25 with args keywords='AN10 oil catch can without breather filter' top_k=20 どうやらキーワード検索には、エージェントにより多くのクエリを試させるような何らかの特性があるようです。エージェントは結果を解釈し、なぜ一致しなかったのかを理解し、次のステップを実行できます。キーワード検索には原因と結果（キーワードがマッチした／しなかった）があり、エージェントはその反応を通じて改善を図ることができます。 ## 探索を促すことでさらに向上する エージェントによる探索を例外ではなく、標準的な運用にしたいと考えています。 ハネス自体に変更を加えたわけではありません。エージェントがより効果的に検索できるよう誘導することは可能です。設定にいくつかの小さな変更を加えた場合、どのようなことが起こるでしょうか： - より多くのツール呼び出しを要求する - エージェントに対して、必要な数のツール呼び出し（例：4 回）を行わなかった場合は継続して試すよう指示します。その際、「素晴らしいですが、もっとできるはずです！」といった励ましのようなメッセージを発します。 - エージェントに多様な検索クエリを使用させる - エージェントが本当に探索を行うことを保証するため、エージェントが過去のこの検索で発行したクエリとあまりにも類似しているクエリは拒否します。 GPT-5-mini の例では [段階的な改善](https://github.com/softwaredoug/search-experiments#esci---forcing-more-tool-calls) が確認できます。 **戦略** **モデル** **平均** **中央値** [2 つのツール](https://github.com/softwaredoug/search-experiments/blob/main/configs/ecom_base/agentic_ecom_2tools_e5_gpt5_mini.yml) gpt-5-mini 0.4101 0.3743 [4 回の呼び出しを要求し、重複を禁止](https://github.com/softwaredoug/search-experiments/blob/main/configs/ecom_mincalls/agentic_ecom_2tools_4calls_repeat_gpt5_mini.yml) gpt-5-mini 0.4290 0.3948 [4 回の呼び出しを要求し、過去のクエリとの類似度が 0.9 を超えるものを禁止](https://github.com/softwaredoug/search-experiments/blob/main/configs/ecom_mincalls/agentic_ecom_2tools_4calls_sim0p9_gpt5_mini.yml) gpt-5-mini 0.4308 0.4258 これは素晴らしい結果です。より小さなモデルでありながら、以前の GPT-5 ベンチマークに近づいています。ただし、ツール呼び出しの回数は増えています。 私がまだ試していないのは、メタデータの断片 [bits of metadata](https://softwaredoug.com/blog/2026/04/21/metadata-the-3rd-kind-of-retrieval) を豊富に備え、コーパスの重要な部分に焦点を当てやすくする検索ツールです。カテゴリフィルターや最新情報のための検索ツールなどがあります。 ## エージェント型検索モデル（SID-1 など）はどうでしょうか？ 新たな可能性として、エージェント型検索モデルが挙げられます。[SID](http://sid.ai/) などのチームは、RAG スタックの [drop-in replacements](https://www.sid.ai/research/sid-1) として機能するモデルを訓練しています。いくつかの検索ツールを設定すれば、SID-1 といったモデルが関連結果をどのように提示するかを判断します。 なぜ専用エージェント型検索モデルが必要なのでしょうか？最先端ラボの LLM は「検索」をウェブ検索と捉えています。そのため、一度クエリを発行して結果を信頼し、次に進みます。これはユーザーの問題について推論しているため（検索の関連性については推論していない）価値があります。 しかし、SID-1 といったモデルは、関連性について現実的に推論します。私たちの企業が構築する検索機能はそれほど洗練されていません。SID-1 はそのことを知っています。そのため、慎重に探索し、結果について推論し、再試行を行います。検索要件を満たす結果の取得にのみ集中した自己ホスト型のサブエージェントとして動作する SID-1 は、メインの LLM がユーザーのタスクに集中できるようにします。 小さく、速く、かつ良質であるためには、焦点を絞る必要があります。ドメインごとに特化したエージェント型検索 LLM が登場するのでしょうか？e コースに優れたもの、求人検索に優れたもの、文書検索に優れたものなどです。あるいは、各ドメイン向けにエージェント型検索モデルをファインチューニングする検索チームが現れるのでしょうか。 トレードオフは埋め込みモデルのそれと似ています：トレーニングデータがモデルの適正領域を決定します。そこから大きく外れれば、突然最適ではない結果が得られるようになります。 ## 「ものを探すこと」と「ディープ・リサーチ」の違い このエージェント型検索の理想郷はどこで崩壊するのでしょうか？これまでに私たちは***もの***（製品、求人など）を見つけることに焦点を当ててきました。しかし、エージェントが持っていない***情報***についてはどうでしょうか？それは根本的に異なる問題です。 MSMarco パッセージデータセットに変更すると、エージェントにツール操作を任せても改善は見られません。埋め込みモデルには勝てません。 ![image](https://softwaredoug.com/assets/media/minimarco_mrr.png) この埋め込みモデルはトレーニングセットに MSMarco を含んでいます。つまり**検索担当者が最もよく知っています**。LLM は自分が知らないものを評価できません。もし正しい情報が何であるかを知っていれば、検索など不要です！ これがエージェント型検索における二つの世界の違いです。一つはエージェントが私たちを助けてものを見つける世界、もう一つはエージェントが学ぶために私たちの助けを必要とする世界です。後者のケースこそが、従来の検索スタックが依然として繁栄している領域です。 私はこの最後のアプローチを「ディープ・リサーチ」と呼び、私がこれまで行ってきたものを「エージェント型検索」と呼んでいます。現在、LLM には知識のギャップが存在しており、私がこれまでに述べたどの方法も、LLM の知識不足を補うものとしては適切ではありません。 エージェントを検索に活用し、より優れた RAG（Retrieval-Augmented Generation）を構築し、クエリ理解において LLM を使用する技術を学ぶために、[Cheat at Search with Agents](https://maven.com/softwaredoug/cheat-at-search) で私と一緒に参加してください。

エージェントが検索スタックを代替できるか？

背景や根拠まで確認しますか？

関連記事

調べる

選ぶ

サイト