powered by TechFeed
表示モード
主要ニュース

DatabricksがRAG専用の検索モデルを発表 — 主要LLMと同等以上の精度を主張しつつ、検索コストに「上限」を設定できる

9月9日、InfoWorldが「Databricks unveils adaptive AI retrieval model to cut search costs and latency」と題した記事を公開した。Databricksがエージェント型AIのRAG検索コストとレイテンシを抑制するための専用モデル「Adaptive Instructed-Retriever」を発表したという内容だ。「コストに上限を設けながら、主要汎用モデルと同等以上の検索品質を実現する」というクレームは、RAGをプロダクション規模で運用するエンジニアにとって見逃せない。

9月9日、InfoWorldが「Databricks unveils adaptive AI retrieval model to cut search costs and latency」と題した記事を公開した。Databricksがエージェント型AIのRAG検索コストとレイテンシを抑制するための専用モデル「Adaptive Instructed-Retriever」を発表したという内容だ。「コストに上限を設けながら、主要汎用モデルと同等以上の検索品質を実現する」というクレームは、RAGをプロダクション規模で運用するエンジニアにとって見逃せない。


RAGの「コスト問題」に正面から向き合う

RAG(Retrieval-Augmented Generation)をプロダクション規模で運用する際、最大の悩みの一つがコストと遅延の予測困難性だ。エージェント型AIは検索を繰り返し実行するため、コストが複利的に膨らみやすく、財務部門から敬遠されやすい。特にマルチエージェント構成や複数テナントが並走する環境では、1リクエストあたりの検索回数が制御しにくく、従量課金コストが想定を大幅に上回るケースが報告されている。

Databricksが発表したAdaptive Instructed-Retrieverは、この問題に直接対処することを目的とした専用モデルだ。Databricksのエンジニアリング担当VP、Chaturvedi氏は同社の発表において次のように述べている。

「エージェント型AIをスケールで運用する際の問題は、消費量の予測が難しいこと、エージェントが繰り返し検索することでコストとレイテンシが予測不能に累積すること、そして財務チームがこれらの変動費用を嫌うことだ。エージェントが定義された上限の中で検索することが保証され、ワークロードごとにその上限を設定できることが、エージェント型検索をスケールで安全に運用できる理由だ。」

つまり「検索品質を維持しつつ、コストに上限を設けられる」という設計思想が核心にある。従来のRAGアーキテクチャでは、ベクトルDB(pgvectorやPineconeなど)への問い合わせと汎用LLMの呼び出しを組み合わせる構成が一般的だが、検索フェーズのコスト最適化は後回しにされがちだった。Adaptive Instructed-Retrieverはそこに特化したアプローチとして位置づけられる。


主要汎用モデルと同等以上の性能を主張

同社の発表によれば、Adaptive Instructed-Retrieverは以下のモデルと同等以上のリトリーバル品質を達成したとしている。あくまでDatabricks自身による内部評価であり、第三者による検証結果ではない点に留意が必要だ。

  • Claude Sonnet 5
  • GPT-5.6 Luna
  • DeepSeek-V4-Flash

そして最も目を引く数字が、リクエスト完了時間5.8秒という値だ。同社の評価では、これらの汎用モデルと比較して2倍以上高速だという。

Chaturvedi氏は、専用モデルが大規模な汎用モデルと同等のリトリーバル品質を低レイテンシで実現できれば、コスト面での優位性はさらに高まると付け加えている。リトリーバル専用タスクに特化したモデルが汎用LLMと肩を並べるという主張は、「モデルの大きさ=品質」という従来の前提を崩すものとして、業界内での議論を呼ぶ可能性がある。


「Instructed-Retriever」とは何か

「Instructed-Retriever(指示付きリトリーバー)」という名称は、単純なベクトル類似度検索にとどまらず、自然言語の指示や検索意図をモデルが解釈した上でドキュメントの取得戦略を調整する仕組みを指す。従来のRAGでは、クエリのembeddingとドキュメントのembeddingのコサイン類似度によって候補を絞り込む手法が主流だが、Instructed-Retrieverは「どの情報をどの粒度で取ってくるか」という判断自体をモデルが担う点が異なる。

そこに「Adaptive(適応型)」という修飾が加わることで、ワークロードの特性に応じて検索の深さや範囲を動的に調整する設計になっているとされる。固定コストではなく、ワークロードごとに上限を設定できるという点は、マルチテナント環境や複数エージェントが並走するシステムにおいて特に実務的な意味を持つ。


エンジニアが注目すべきポイント

現在、RAG基盤の構築においてはベクトル検索とLLMの呼び出しコストが主な支出となっている。Adaptive Instructed-Retrieverのように検索フェーズ専用に最適化された小型モデルで品質を担保しつつコストを抑える方向性は、OpenAIやAnthropicが提供するフルスタックの汎用モデルに依存しない代替アーキテクチャとして機能しうる。

Databricksはここ数年、Unity CatalogによるデータガバナンスやMLflowによるML実験管理など、LLMアプリケーションの「基盤レイヤー」を強化する戦略を一貫して取ってきた。Adaptive Instructed-Retrieverはその延長線上に位置づけられ、推論コストの可視化・制御という課題をプラットフォーム側で解決する取り組みとして読み解くことができる。

エンタープライズ向けRAGのコスト管理に課題を抱えるチームにとって、このモデルの技術詳細と実際のベンチマーク条件は精査に値する。同社が今後どのような評価手法を公開するかも注目点だ。

※編集部の考察:「Instructed-Retriever」アプローチが実用環境で汎用LLMと同等の検索品質を安定して発揮できるかどうかは、ドメイン特化データでの再現性に大きく依存する。内部ベンチマークの詳細(評価データセット・メトリクスの定義)が公開されるかどうかが、今後の採用判断の分岐点となるだろう。


詳細はDatabricks unveils adaptive AI retrieval model to cut search costs and latencyを参照していただきたい。