Databricks Adaptive Instructed-Retriever、検索を常に打ち切ることなく検索レイテンシを削減

Databricksは、比較対象モデルのレイテンシの半分未満に当たる5.8秒で最先端水準の検索品質を実現するという明確な主張とともに、Adaptive Instructed-Retrieverを発表した。Databricks Adaptive Instructed-Retrieverは、すべての検索を同じ深さで行うわけではない。追加の検索ステップに時間を費やす価値があるかを判断する。

この違いは、データエージェントに関する一般的な前提に疑問を投げかける。より良い結果には、多くの場合、より多くの検索、より大きなモデル、あるいはその両方が必要になる。ステップを追加すれば証拠の網羅性は改善し得るが、エージェントの速度を落とし、運用コストも高める。

Databricksは代わりに、単純なリクエストでは早期に停止し、難しいリクエストでは継続するよう、小型の特化モデルを学習させた。したがって主な競争は、Databricksと特定のモデルベンダーとの対決ではない。各リクエストにほぼ同一の計算処理を与える固定深度検索と、適応的かつ上限付きの検索との比較である。

Databricks Adaptive Instructed-Retrieverが検索予算を変える

中核となる変更は、追加作業が検索結果を改善するとモデルが予測した場合にのみ、より多くの処理を割り当てる上限付き検索ポリシーだ。

Databricksはこのシステムを2026年9月9日に発表した。同社のretriever announcementでは、並列検索と逐次検索を組み合わせるモデルとして説明されている。

並列検索では、複数の検索を同時に送信する。この方法は待機時間の発生回数を抑え、初期リクエストがすでに有用な証拠を指し示している場合に有効だ。

逐次検索は異なる仕組みで動く。1回分の証拠を調べ、検索戦略を洗練させたうえで、次の検索を実行する。このフィードバックループは、複数の文書やソースにまたがる事実を必要とするマルチホップの質問に役立つ。

ただし、逐次検索では新たな各ラウンドが前のラウンドの後に続くことになる。エージェントは、先行する結果から次に何を探すべきかを判断するまで、3回目の検索を開始できない。

Adaptive Instructed-Retrieverは、この2つのアプローチの中間に位置する。Databricksは逐次ステップ数に固定の上限を設け、その範囲内でいつ停止するかをモデルに判断させる。

利用可能な証拠が十分だと判断すれば、モデルは早期に結果を返す。別のクエリが不足情報を見つける可能性が高い場合には継続する。固定上限により、不確実な検索が無制限に拡大することを防ぐ。

この設計は、並列の単一ステップ検索に焦点を当てたDatabricksの先行モデル、Instructed-Retriever-1を拡張するものだ。同モデルは検索を組み立てる際、データスキーマやカスタム指示を取り込めた。

新バージョンはこの高速経路を維持しつつ、制御されたマルチステップ動作を追加している。この機能追加が重要なのは、エンタープライズの質問が同じ難易度に収まることはほとんどないためだ。

既知のノートブックのタイトルを求めるリクエストは単純な場合がある。一方、製品に関連するすべての顧客を見つけるには、より広い探索、エンティティの特定、そして対象を絞った追加検索が必要になることがある。

Databricksはこの技術を、Genie Codeおよび関連するデータエージェントの検索レイヤーとして位置付けている。これらのシステムは、変化し続けるテーブル、ダッシュボード、ノートブック、文書、その他のワークスペース資産のコレクションを検索する。

同社によると、Adaptive Instructed-Retrieverは、未使用の社内・外部ベンチマーク7件で主要な比較対象モデルと同等の結果を示した。これらのテストは複数の領域と難易度を対象としていた。

報告された平均エンドツーエンドレイテンシは5.8秒だった。Databricksは、自社評価においてこの結果がClaude Sonnet 5、GPT-5.6 Luna、DeepSeek-V4-Flashより2倍以上高速だったとしている。

これは重要な主張だが、依然としてベンダー自身が実施したベンチマークである。Databricksはこれらの結果を、エンタープライズワークロード全般における独立再現済みの普遍的な順位付けとして提示してはいない。

したがって重要なニュースは、1本のレイテンシ棒グラフを超えるものだ。Databricksは検索ステップ数を、固定のパイプライン設定ではなく、学習されたプロダクト上の判断へと変えた。

固定深度のエンタープライズ検索に高まる圧力

単一の検索ポリシーは、簡単な質問に時間を浪費するか、難しい質問を早く切り上げすぎるため、ワークロードの両端で圧力を生む。

従来の検索システムは、しばしば固定のレシピを用いる。あらかじめ定めた数の候補を取得し、フィルターを適用し、場合によっては結果を再ランキングし、選択したコンテキストを言語モデルへ渡す。

この予測可能性は、エンジニアによるインフラ管理には役立つ。しかし、そのレシピがすべてのリクエストに適合することを意味するわけではない。

実質的にルックアップで済む質問もある。ユーザーは、名前の分かっているポリシー、正確なダッシュボード、あるいは既知のフィールドを含むテーブルを尋ねるかもしれない。

別の質問では探索が必要になる。エージェントは、複数の関連エンティティを特定し、文書をまたいで証拠を結び付け、重要な情報が残っていないかを検証する必要があるかもしれない。

すべてのルックアップに拡張された検索プロセスを実行すると、より良い証拠を保証することなく応答時間が増える。すべてのリクエストを1ラウンドに制限すると、より難しい質問では検索が不完全になる危険がある。

この問題はエージェント内で増幅する。検索の遅延が待機時間のすべてになることはまれで、検索の後には推論、ツール実行、回答生成が続くことが多い。

回避可能な検索ラウンドが1回あるだけで、より長い連鎖が延びる可能性がある。不要なラウンドが複数重なると、本来は有能なエージェントでも応答しないように感じられる。

Databricks自身のAI Search documentationは、関連するトレードオフを示している。再ランキングは関連性を改善し得るが、初期検索後に追加のレイテンシをもたらす。

再ランキングは、別のモデルを使って候補文書をリクエストへの関連性順に並べ替える。完全に新しい検索を実行せずに、弱い第1段階の順位付けを修正できる。

適応型マルチステップ検索は、この問題の別の部分に対処する。エージェントが追加の証拠を探すべきか、そして次のクエリをどのように変えるべきかを判断する。

どちらの技術も、品質改善のために計算資源を使う。どちらも無料ではなく、平均的なベンチマークで効果があったからといって、すべてのリクエストに適用すべきものでもない。

このため、検索インフラチームが直接的な圧力の対象となる。クエリごとに処理量を変えられるシステムに対して、静的な設定を正当化する必要が生じるからだ。

汎用言語モデルも、検索レイヤーで圧力に直面する。その幅広い推論能力は反復的な検索を支援できるが、その柔軟性には大きな推論オーバーヘッドが伴う。

小型の特化モデルは、あらゆる知的タスクで大型モデルを上回る必要はない。下流のエージェントに十分な速度で、より良い検索判断を下せばよい。

Databricksの主張は、特化コンポーネントへ向かうより広い流れに合致する。エンタープライズエージェントは、検索計画用、再ランキング用、最終統合用に、それぞれ異なるモデルを利用できる。

この分業はレイテンシを下げ得るが、評価の複雑さも生む。チームは、各コンポーネントが局所的な指標だけでなく、完全なユーザー体験を改善しているかを判断しなければならない。

検索可能なAI knowledge baseを構築する企業にとって、この区別は実用的だ。最終的な言語モデルが正しく推論していても、検索の失敗はしばしば回答の失敗につながる。

したがって求められているのは、単により高速なモデルを購入することではない。エージェントがどこで時間を使い、どの検索が証拠を実質的に変えるのかを測定することだ。

この仕組みは有用な検索を報い、無駄なステップにペナルティを課す

Databricksは、追加の各検索を、より良い結果によって価値を証明しなければならない投資として扱うようretrieverを学習させる。

同社は事前学習済みのベースモデルと、合成的なエンタープライズ検索環境から始める。合成環境は、検索行動を大規模に学習させるため、生成された質問、文書、関連性シグナルを提供する。

DatabricksはInstructed-Retriever-1の学習データも再利用する。これにより、並列の単一ステップ検索で得た経験を維持しながら、複数ラウンドの恩恵を受けるよう設計された合成質問を追加する。

主要な学習手法はオンライン強化学習だ。この設定では、モデルが検索軌跡を実行し、その品質とコストに基づいて報酬を受け取る。

Databricksは、CISPOと略されるClipped Importance Sampling Policy Optimizationを使用する。この最適化手法は、サンプリングされた軌跡が学習に及ぼす影響の強さを制御しながら、検索ポリシーを更新する。

プロダクトの挙動にとっては、頭字語よりも報酬設計の方が重要だ。高い性能を示す軌跡には正のシグナルが与えられ、不要な検索ステップにはペナルティが課される。

軽いステップペナルティでは、モデルはより長く検索できる。より重いペナルティは、早期停止と低レイテンシを促す。

異なるペナルティ重みで学習することで、チェックポイント群が生成される。各チェックポイントは、検索品質と応答時間の間で異なる動作点を表す。

これにより、設定可能なパレートフロンティアが形成される。このフロンティア上の点では、品質を改善するにはレイテンシを増やす必要があり、レイテンシを削減するには品質を犠牲にする必要がある。

Databricksによると、学習済みのチェックポイントは、同程度またはそれ以下のレイテンシで未学習のベースモデルを上回った。また、得られたフロンティアは、テストした検索予算全体で比較対象モデルを上回ったとしている。

この仕組みは、1つの勝者となるチェックポイントを選ぶ以上に重要だ。プロダクトチームは、特定のワークロードに合ったポリシーを選択できる。

対話型アシスタントでは、より高速なチェックポイントを優先できる。オフラインの調査タスクでは、より広い網羅性が最終レポートを改善する場合、より長い検索を許容できる。

上限付きステップ数は、さらに別の制御層を加える。品質重視のポリシーであっても、設定された最大値を超えて検索を続けることはできない。

この点で、このシステムは制限のないリサーチエージェントとは異なる。Adaptive Instructed-Retrieverは、完全に確信できるまで探索するよう求められているわけではない。

限られた予算を受け取り、その使い方を学ぶ。その結果の挙動は、必要とする入力に対してのみ追加の処理を起動する条件付き計算に似ている。

Databricksはこの挙動について2つの例を示している。1つ目は、名前が明かされていない企業が、2022年度の損益計算書項目としてリストラクチャリング費用を明示的に報告したかどうかを問うものだ。

Databricksによると、そのモデルは2ステップでRecall@10の完全な値に到達した。Recall@10は、関連する項目が検索結果の上位10件に現れるかを測る指標である。

Claude Sonnet 5は、3ステップで同じリコールに到達したとされる。GPT-5.6 Lunaは、同社の比較では4ステップを使用した。

Databricksのシステムは、直接の項目と関連する費用カテゴリーを確認した。その後、否定的な回答を裏付ける十分な証拠を見つけた時点で停止した。

否定的な質問は難しい。存在しないことが都合よく1文で示されることはほとんどないためだ。検索エージェントは、語句が見つからないことを、何かが存在しなかった証拠と混同せずに、可能性の高い箇所を調べなければならない。

2つ目の例は、LiteLLM Proxyを利用している、または利用を検討した顧客はどこかを尋ねる。この質問は、既知の1文書を検証するよりも発見を重視する。

Adaptive Instructed-Retrieverは、2回目のラウンドで特定のアカウント仮説を検索したと報告されている。2ステップで0.75 Recall@10に到達した。

Databricksは、Sonnetでは2ステップで0.50、Lunaでは4ステップで0.62だったと報告している。同社によると、Lunaは類似した引用符付きクエリを繰り返し、Sonnetの一般的な追加検索は関連する顧客を見逃した。

これらの例は、検索を拡張することと同じくらい、クエリの調整が重要になり得ることを示している。最初の戦略を繰り返すだけの追加ラウンドには、ほとんど価値がない。

ここで指示付き検索が登場する。指示によって、生のクエリだけでは表せない、求める証拠、制約、文書特性を指定できる。

INSTRUCTIR benchmarkに関する学術研究では、指示追従型の検索が依然として難しい課題であることが示された。著者らはまた、タスク形式の指示チューニングの一部が既存データセットに過適合する可能性も指摘している。

後のMAIR benchmarkでは、評価対象が6分野・126件の検索タスクへと拡大された。この規模は、限定的なタスク群から汎用的な検索能力を推定することがいかに難しいかを物語っている。

Databricksのアプローチは、指示追従に加えて、投入する労力に関する判断を組み込む。モデルは何を探すべきかを理解し、すでに得た情報を評価し、追加の検索に価値があるかどうかを判断しなければならない。

この組み合わせは、小規模な専門モデルがこの役割でより大規模な汎用モデルと競争できる理由を説明する。問題は限定され、繰り返し測定可能で、検索結果と密接に結び付いている。

これは、小規模モデルが一般にフロンティアモデルを置き換えることを示すものではない。明確な運用目標に沿って学習させることで、不要な汎用推論を減らせることを示している。

2倍低レイテンシーという主張が立証していないこと

このベンチマークは有望な設計方向を支持しているが、実際のエンタープライズインデックス、セキュリティルール、トラフィックパターンにおける同等の性能をまだ立証してはいない。

Databricksは、保持された7つの社内・外部ベンチマークにまたがる結果を報告している。この発表では、基礎となるすべてのクエリ、コーパス、関連性判断、提供構成は公開されていない。

このため、外部からの精査には限界がある。読者は現時点では、この投稿の情報だけで5.8秒という完全な結果を再現できない。

「frontier-quality」という表現も、選定されたタスクに依存する。比較では、Databricksの検索環境内の検索エージェントとしてモデルを評価しており、汎用アシスタントとして評価しているわけではない。

ハードウェア、提供ソフトウェア、並行実行数、文書規模、ツールのレイテンシーはいずれもエンドツーエンド測定に影響し得る。異なるデプロイ条件では、相対的な優位性も変わり得る。

ベンチマークの構成も重要である。単純な検索が多く含まれるスイートでは、早期停止が自然と有利になる。

一方、深い調査が中心のスイートでは、モデルは最大ステップ数まで進む可能性がある。その変化により、平均レイテンシーの優位性は縮小する。

合成学習データも、もう一つの未解決の問題を生む。生成されたエンタープライズシナリオは幅広い教師信号を提供できる一方、そのパターンは雑然とした本番ワークスペースと異なる場合がある。

実際のリポジトリには、重複文書、古いダッシュボード、一貫性のない命名、不完全なメタデータ、アクセス制限が存在する。設計者が予期しなかった質問も含まれている。

InfoSearch researchは、別の課題を浮き彫りにしている。真に指示を理解する検索器は、肯定的・否定的な制約を含め、要求された文書属性を考慮しなければならない。

関連性が主にトピックの類似性に従う場合、モデルは強力に見えることがある。しかし、ユーザーが最新、権威的、地域限定、またはポリシー準拠の証拠だけを要求する場合、より厳しい試験に直面する。

セキュリティも検索行動を変え得る。エンタープライズエージェントは、関連性が高そうだからというだけで制限付きの資料を取得すべきではない。

アクセスフィルタリングにより候補プールが縮小したり、最も明白な証拠が除外されたりする場合がある。そのときエージェントは、許可された追加検索に十分な期待値があるかを判断しなければならない。

Databricks AI Searchは、インデックスを同社のデータプラットフォームと統合し、メタデータ、フィルタリング、ハイブリッド検索、リランキングをサポートする。これらの機能はもっともらしいデプロイ経路を生み出すが、統合がすべてのモデル主張を検証するわけではない。

この発表では、比較ごとの運用コストも定量化されていない。低レイテンシーはしばしば低い計算使用量と相関するが、その関係は提供効率とハードウェア利用率に依存する。

すばやく完了する小規模モデルでも、低トラフィック時には非効率的に稼働する可能性がある。大規模な共有サービスはバッチ処理の恩恵を受け、コスト比較を変える場合がある。

チェックポイント群も運用上の選択肢をもたらす。顧客は適切なステップペナルティを特定し、証拠の見落としに対する自らの許容度と照らして評価しなければならない。

高速なポリシーはレイテンシー目標を満たしつつ、まれだが価値の高い要求の品質を低下させる可能性がある。積極的なポリシーは検索品質を守れる一方、約束された応答性を損なう可能性がある。

平均指標はそうした裾野を隠し得る。エンタープライズチームには、パーセンタイルレイテンシー、失敗カテゴリ、クエリ難易度別に分けた品質結果が必要だ。

また、誤った停止も検証する必要がある。この失敗は、別の検索で決定的な文書が見つかったはずなのに、モデルが十分な証拠を得たと判断した場合に起こる。

過剰検索は、ユーザーの待ち時間が長くなるため見つけやすい。早すぎる停止は、評価セットに信頼できる関連性ラベルが含まれていない限り、見えないままになり得る。

したがって、適応型ポリシーには監視の責務が伴う。チームはモデルが何を取得したかだけでなく、なぜ停止したのか、追加ステップが結果を変えたかどうかも測定しなければならない。

Databricksは結果を適切に自社評価として提示している。独立した検証が現れるまで、購入側はこの2倍という数値を特定ベンチマークの結果として扱うべきだ。

この慎重さは結果を否定するものではない。それが裏付けられる範囲を定義するものである。適応型のステップ配分は、固定深度検索と比較して本番テストに値する。

適応型検索はモデルサイズを購入判断の近道として使いにくくする

検索に投じる労力が学習可能で上限を持つようになれば、購入側はモデルサイズだけで製品を順位付けするのではなく、完全な検索ポリシーを比較しなければならない。

エンタープライズAIの調達は、多くの場合、馴染み深いモデルリーダーボードから始まる。この手法は汎用的な言語タスクには理にかなっているが、検索システムを誤って表現する可能性がある。

検索エージェントは、クエリ定式化、インデックスへのアクセス、候補選択、停止行動、そして場合によってはリランキングを組み合わせる。最終的な回答は、これらの要素がどう相互作用するかに依存する。

Databricksの比較は、特化型検索器がこの定義されたループ内でより大規模なモデルに匹敵し得ることを示唆している。その優位性は、単にトークンを速く生成することではなく、作業を配分することから生じる。

このため競争は、システムレベルの評価へと移行する。Anthropic、OpenAI、DeepSeekなどのモデルプロバイダーは、それに応じてツール利用、推論効率、検索ポリシーを改善できる。

検索ベンダーも、Databricksの正確な学習レシピを再現せずに同じ原則を追求できる。要求を難易度別にルーティングし、予算を設定し、軽量な計画モデルを学習させることができる。

従来のハイブリッド検索も引き続き重要である。キーワード検索は正確な識別子を見つけられ、ベクトル検索は意味的な類似性を捉える。

その後、リランカーが統合された候補を並べ替えられる。適応型の逐次検索は、最初のパスに未解決の不足が残る場合に、さらに別の選択肢を加える。

これらの技術は、すべての要求で全段階が自動的に実行されるスタックになるべきではない。それでは、より複雑なアーキテクチャの下でレイテンシー問題を再現することになる。

より強固な設計原則は、条件付きのエスカレーションである。信頼して回答できる最も低コストな経路から始め、証拠がそれを正当化するときにだけ追加のリソースを費やす。

この原則は評価も変える。システムは、証拠が十分な場合にのみ早期停止の評価を得るべきである。

次のステップが有用なカバレッジを高める場合にのみ、継続したことが評価されるべきだ。結果を測らずにステップ数を数えると、浅い最適化を促してしまう。

この結果は、Databricksの顧客以外にも重要である。ナレッジエージェントは、際限のない調査を待たせることなく、増え続ける非公開コレクションから正確な回答を提供したいという同じ基本的制約に直面している。

実用的なエージェントは、指定されたファイルに対してローカル文書を一度だけ検索するかもしれない。プロジェクト横断の意思決定履歴を組み立てる場合には、複数の的を絞った検索を行うかもしれない。

これらの要求を同じように扱えば、時間または情報のいずれかを浪費する。Adaptive Instructed-Retrieverは、この不一致を明示的なモデル学習問題にする。

このアプローチは、インフラチームにより明確な制御面も提供する。単一の固定深度を設定する代わりに、異なる品質とレイテンシーの優先順位を表すチェックポイントを選択できる。

ただし、この利便性はワークロードの違いを覆い隠す可能性がある。1つのチェックポイントが、対話型サポート、コンプライアンス調査、オフライン分析に等しく適するとは限らない。

したがって、エンタープライズはユースケース別に評価を分けるべきだ。一般的な検索、曖昧な要求、否定的な質問、網羅的な発見、複数文書の統合を含めるべきである。

選定するベンチマークも、実際のインデックスを反映しなければならない。クリーンな公開コーパスは、古く相反する資産を含む権限管理済みワークスペースの代替にはならない。

成功は、検索だけでなく回答のレベルでも測定すべきである。下流のエージェントが証拠を忠実に用いる場合にのみ、より高いRecall@10には意味がある。

Databricks Adaptive Instructed-Retrieverは最終的に、速度をポリシーの結果として再定義する。より速い検索は、常に浅い検索を意味する必要はない。

それは、深掘りが報われなくなった時点を認識することを意味し得る。すべての要求に最大の推論予算を負担させるよりも、こちらの方が有用な方向性である。

適応型検索が有効かを示す3つのシグナル

次の試験は、Databricksが制御されたベンチマーク結果を、顧客データ、困難なクエリ、本番トラフィック全体で再現可能な改善へと転換できるかどうかである。

第1のシグナルは、再現可能な評価資料である。Databricksは保持された7つのベンチマークカテゴリを特定し、具体例も提示しているが、外部チームにはより完全なテスト詳細が必要だ。

公開評価パッケージがあれば、コーパス構成、採点、提供条件、クエリ難易度が明確になる。報告された5.8秒という結果に近い独立再現は、レイテンシーの主張を強化するだろう。

独立した結果とDatabricksの数値に大きな差があれば、その主張は弱まる。完全なモデルアクセスがなくても、比較可能な評価プロトコルがあればベンダー比較はより有意義になる。

第2のシグナルは、Genie Code、Genie One、またはGenie Agents内での本番導入である。Databricksはこの検索器を、これらの製品と変化するワークスペースデータに明確に結び付けている。

有用な証拠には、実際のデプロイから得られるパーセンタイルレイテンシー、検索成功率、検索ステップ分布が含まれる。1ステップで終了するケースが集中していれば、モデルが真の高速経路を維持していることが示される。

マルチホップ要求における一貫した品質向上は、より深い約束を裏付けるだろう。最大深度までの検索が頻発すれば、本番の質問がベンチマーク構成より難しいことを示唆する。

第3のシグナルは競合他社の反応である。モデルプロバイダーとエンタープライズ検索プラットフォームには今、具体的な目標がある。すべてのクエリに同じ労力を割り当てずに検索品質を一致させることだ。

新たな適応型停止制御、特化型検索器、レイテンシーを意識したエージェント評価が登場すれば、Databricksの枠組みを裏付けることになる。同等の品質と速度を実現する強力な固定深度システムが現れれば、学習済みステップ配分の必要性に疑問を投げかける。

チームは、この競争を待たずに根底にある考え方をテストできる。自らの要求にラベルを付けたサンプルで、1ステップ検索と上限付きマルチステップ検索を比較すればよい。

評価では、単純、曖昧、否定的、網羅的なクエリを分けるべきである。検索品質、エンドツーエンドレイテンシー、検索回数、下流回答の根拠付けを記録すべきだ。

このプロセスにより、見出しの主張はローカルな証拠に基づく判断へと変わる。また、適応型チェックポイントが賢く停止しているのか、単に早く停止しているだけなのかも明らかになる。

Databricksは、無駄な検索を減らすための信頼できる仕組みを提示した。未解決なのは、その仕組みが想定された環境以外でもどこまで確実に機能するかという点だ。

開発者と企業の購買担当者が次に取るべき行動は明確だ。実際の文書と最も厳しいレイテンシ目標を用いて、適応型検索を試験することだ。検索ステップを追加すれば証拠の質は向上するのか。それとも待ち時間が延びるだけなのか。