9月11日、Techstrong.AIが「Databricks Adaptive Search Model Addresses AI Agent Costs」と題した記事を公開した。AIエージェントが「すでに答えは出ているのに検索をやめられない」という現場レベルの問題に、Databricksが専用モデルで正面から応えた。発表されたのはAdaptive Instructed-Retriever——質問の難易度をリアルタイムに判断し、必要な分だけ検索して止まれる適応型検索モデルだ。
AIエージェントの「検索しすぎ」問題
AIエージェントをプロダクションで運用する際、見落とされがちなコスト要因がある。それは「検索の繰り返し」だ。
エージェントは複数のソースから情報を収集し、ある発見を次の検索に活かしながら、「十分な根拠が集まったか」を判断する必要がある。問題は、すでに十分な回答が得られているにもかかわらず、エージェントが検索を続けてしまうケースだ。追加の検索ステップはコンピューティングリソースを消費するが、回答品質に貢献しない。スケールで動かすと、この無駄な繰り返しがコストの予測を難しくする。
Databricksが今回発表したAdaptive Instructed-Retrieverは、この問題に正面から取り組んだモデルだ。
「難しい質問には多く、簡単な質問には少なく」
従来のRAG（Retrieval-Augmented Generation）は、すべてのリクエストに同量の処理を割り当てる。RAGとは、LLMが回答を生成する前に外部ドキュメントや社内データベースを検索して関連情報を取得する手法で、ファクト精度の向上やハルシネーション抑制に広く使われている。Adaptive Instructed-Retrieverはこの設計に一歩踏み込んだアプローチを取る。
- 単純な質問：素早く完了させる
- 複数段階の調査が必要な質問：順次検索（Sequential Retrieval）を実行する
開発者は最大検索ステップ数の上限を設定できる。これにより、モデルが際限なく検索を続けるリスクを抑えられる。
同モデルは、今年初めにリリースされたInstructed-Retriever-1をベースに構築されている。Instructed-Retriever-1は1ステップで並列検索を実行し、エンタープライズのデータスキーマやユーザー指示を活用して検索精度を高めるモデルだ。DatabricksはこのモデルについてRAGを70%以上上回る性能をエンタープライズQAテストで達成したと主張していた。
強化学習で「検索の価値」を学習
Adaptive版のトレーニングには、Instructed-Retriever-1のデータに加え、合成エンタープライズ環境とマルチホップ質問のデータが組み合わされた。マルチホップ質問とは、「AについてのドキュメントからBを特定し、BについてさらにCを調べる」といった、複数ステップの推論・検索を連鎖させなければ正しい答えにたどり着けない質問形式を指す。単一の検索では解決できないため、エージェントの「検索をいつ止めるか」判断が特に難しくなる。
さらにオンライン強化学習を適用した。強化学習とは、モデルが試行錯誤の結果に対して報酬またはペナルティを受け取り、より良い行動を自律的に学習する手法だ。今回の適用では、有益な検索パスには報酬を、追加ステップが十分な改善をもたらさなかった場合はペナルティを与えることで、「必要なときだけ検索する」挙動を学習させている。
この仕組みから生まれるのがチェックポイントによる運用の柔軟性だ。チェックポイントとは、強化学習の途中で保存されたモデルの重みのスナップショットを指す。ペナルティの大小が異なるタイミングで保存されたチェックポイントを選ぶことで、同一モデルの「スピード重視版」と「品質重視版」を使い分けられる。
| 設定 | 特性 | 用途例 |
|---|---|---|
| 追加検索へのペナルティが大きい | スピード重視 | インタラクティブアプリ |
| ペナルティが小さい | 検索品質重視 | バッチ処理、調査系ワークロード |
ベンチマーク結果と独立検証について
Databricksの評価によれば、Adaptive Instructed-Retrieverは平均5.8秒でリクエストを完了し、GPT-5.6 Luna、Claude Sonnet 5、DeepSeek-V4-Flash（※いずれも元記事に記載のモデル名）と同等以上の検索品質を達成したとされる。評価には7つの内部・外部ベンチマークが含まれ、異なるドメインや検索難易度をカバーしている。
ただし、記事中でも明記されているとおり、この結果は独立した第三者による検証を受けていない。元記事もこの点を注記しており、自社評価のみである点は念頭に置く必要がある。
本モデルの核心にあるのは、「検索を続けるかどうかの判断をモデル内部に移す」という設計思想だ。従来はエージェントのオーケストレーション層——つまり開発者が書くロジック側——が「何回検索するか」を制御していた。Adaptive Instructed-Retrieverはその判断をモデル自身が担うことで、オーケストレーション実装の複雑さを下げることを狙っている。コスト配分の最適化と開発負荷の軽減、両面での効果を主張するモデルと言える。
※編集部の考察：ベンチマーク結果がプロダクション環境でも再現されるかどうかが採用判断の分岐点になる。検索継続判断をモデル側に委ねるアーキテクチャは、エージェントフレームワーク設計の今後の方向性にも影響しうる視点として注目しておきたい。
詳細はDatabricks Adaptive Search Model Addresses AI Agent Costsを参照していただきたい。
