Databricksのプロトタイプが本番運用へ、高QPSには依然として計画が必要

Databricksは、プロトタイプから本番環境への移行で生じる隔たりを、単一の設定で埋めようとしている。標準のAI Searchエンドポイントで、毎秒数千件のクエリを処理できるようになった。新たな高QPS機能は2026年7月28日に一般提供を開始した。これにより、チームは元のインデックスを中心とした検索インフラを作り直すことなく、Databricksのプロトタイプを本番へ移行できる。

ただし、この約束には重要な条件がある。チームは依然として目標値を選び、トラフィック急増に備え、検索品質をテストし、レイテンシーを監視しなければならない。Databricksはキャパシティをプロビジョニングするが、信頼できる検索体験を左右するエンジニアリング上の判断まで不要にするわけではない。

この動きにより、Databricksは専用検索プラットフォームやクラウド管理型ベクトルサービスとの競争により直接的に踏み込むことにもなる。Googleはすでに、大規模かつ低レイテンシーのワークロード向けにVertex AI Vector Searchを提供している。特化型データベースも、スループット、フィルタリング、運用の容易さで競っている。

Databricksは、より重要なのはプラットフォームの継続性だと見込んでいる。同じガバナンス下のデータ、インデックス、同期経路を、トラフィックの増加に合わせて維持できる。すでに同社のレイクハウス環境で開発しているチームにとっては、導入作業を短縮できる可能性がある。

これは単なる検索高速化の発表ではない。分離された検索スタックを用意せずとも、ガバナンスの効いたエンタープライズデータ基盤でインタラクティブなアプリケーションを支えようとする試みだ。本当の試練は、そうしたアプリケーションが予測不能な本番トラフィックに直面したときに始まる。

Databricksのプロトタイプに本番向け設定が加わる

Databricksは、既存のインデックスとガバナンスモデルを維持したまま、複雑なキャパシティ設計を宣言型のQPS目標へと簡素化した。

QPSはqueries per second、つまりエンドポイントが1秒間に処理する検索リクエスト数を意味する。すべてのページビュー、キーストローク、レコメンデーションパネルがリクエストを生む場合、この指標は重要になる。

Databricksによると、標準のAI Searchエンドポイントは現在、数千QPSまで拡張できる。開発者はエンドポイント作成時にtarget_qpsを設定するか、インターフェース、SDK、REST APIを介して既存のエンドポイントを更新する。

その後、サービス側が必要なインフラを計算してプロビジョニングする。同社の高QPSに関する発表によれば、開発者がレプリカ数、ノードサイズ、外部ロードバランサーを管理する必要はない。

これが中心的な変更点だ。このリリース以前は、Databricksのプロトタイプが成功しても、利用者が増えると新たな問題が生じることがあった。検索体験は機能していても、配信アーキテクチャには追加のキャパシティ計画とトラフィック分散が必要だった。

一部のチームは、重複したエンドポイントを作成してこの移行に対処していた。また、クライアント側のルーティングを追加したり、別の配信レイヤーを構築したりするチームもあった。こうした回避策は運用作業を増やし、設定の乖離が起きる箇所も増やした。

新たな設定は、その特定の境界を対象としている。既存の標準エンドポイントは、次回インデックスが作成または同期される際に追加キャパシティを受け取れる。Unity CatalogによるガバナンスとDelta Syncは、引き続きデプロイメントの一部となる。

Unity Catalogは、データとAI資産に対するDatabricksのガバナンスレイヤーだ。Delta SyncはAI Searchインデックスをソーステーブルと整合させる。両者を維持することは重要である。移行では、パフォーマンスの問題と並行して、しばしば第2のガバナンス問題も生じるためだ。

エンドポイントでは、scaling_infoフィールドを通じてスケーリングの進捗も確認できる。チームは状態がSCALING_CHANGE_IN_PROGRESSからSCALING_CHANGE_APPLIEDへ移行する様子を確認できる。

Databricksは、リクエストレート、レイテンシー、健全性をエンドポイント単位で可視化する機能を追加した。これらのシグナルはAI Searchインターフェースで利用でき、運用担当者は計画したキャパシティと実際の挙動を比較できる。

この発表は標準エンドポイントを対象とし、オプトイン手続きなしで一般提供されている。チームは新規エンドポイントに目標値を適用することも、すでにアプリケーションを提供しているエンドポイントを更新することもできる。

そのため、Databricksのプロトタイプに関するストーリーは非常に直接的だ。小売業者はガバナンス下のカタログデータを使って商品発見機能を開発し、そのカタログを別の検索システムへコピーすることなく配信キャパシティを増やせる。

ストリーミングサービスも、コンテンツ推薦で同じ道筋をたどれる。エンタープライズアプリケーションでは、各受信レコードを既存カタログと照合する必要があるエンティティマッチングに利用できる。

この変更によって、ノートブック上の実験が完成済みのコンシューマー向けアプリケーションへ変わるわけではない。実験とそのアプリケーションの間にしばしば現れる、あるインフラ移行を取り除くものだ。

したがってDatabricksが売り込んでいるのは、単なる速度ではなく継続性である。テストクエリに応答したエンドポイントを、そのまま本番トラフィックを支えるエンドポイントとして維持できる。この価値は、そうでなければガバナンス、同期、配信が別々のシステムに属する場合に大きくなる。

この継続性は期待値も高める。インフラのスケーリングが設定項目になると、アプリケーションチームは、検索が遅い、あるいは信頼できないことの説明としてインフラを挙げにくくなる。クエリ設計とワークロードテストが、より中心的な位置を占める。

高QPSは検索を収益に直結する経路へ置く

この機能が重要なのは、インタラクティブな検索トラフィックが突発的でユーザー向けであり、多くの場合、取引やレコメンデーションに直接結び付くためだ。

従来型の分析クエリは、場合によっては待てる。商品検索ボックスは待てない。ユーザーは、遅延した入力補完結果、不完全なレコメンデーション、検索完了待ちで止まるページに気付く。

入力補完検索は、1回のユーザー操作から複数のリクエストが生まれるため、特有の負荷を生む。アプリケーションが入力をデバウンスまたはバッチ処理しない限り、新しい文字ごとに別のクエリが発生しうる。

レコメンデーションシステムにも似たパターンがある。ホームページでは、1回の訪問中に複数のパーソナライズされた結果セットを要求する場合がある。トラフィックはリリース、販促、ライブイベント、地域ごとの視聴時間帯に集中する。

エンティティ解決はユーザー体験こそ異なるが、運用上の要求は同じだ。別の業務プロセスが回答を待つ間に、システムはレコード、アカウント、製品、アイデンティティを照合しなければならない。

これらのアプリケーションでは、後続の処理が検索の応答まで続行できないため、検索がクリティカルパス上に置かれる。したがって、過負荷のエンドポイントは顧客向けワークフロー全体を遅らせる可能性がある。

Databricksは3つの警告サインを挙げている。HTTP 429エラー、P95レイテンシーの上昇、重複エンドポイントを使う回避策だ。P95レイテンシーは、リクエストの95%がその時間以内に応答する、またはそれより速く応答する時間を指す。

平均値は不十分な体験を隠し得るため、テールレイテンシーは重要だ。大半のクエリは高速に返っても、トラフィックが増加する間に無視できない一部が遅くなる可能性がある。

平均利用率が中程度に見える場合でも、チームは問題に直面しうる。短時間の急増によって、時間単位または日次の平均が問題を示す前に、利用可能なキャパシティが尽きることがある。

ここで宣言型の目標値が役立つ。チームは予想されるリクエストレートに合わせてサイジングし、既知のピークに備えた余裕を追加できる。その後、可観測性によって、その前提が現実と一致しているかを確認できる。

ただし、目標値はその背後にあるトラフィックモデルほどにしか有用ではない。週平均はローンチ日の急増を表さない。単一ユーザーのテストでは、数千の同時セッションを再現できない。

検索バーはまた、ベクトル検索が現在、確立されたキーワード検索と競合する理由を示している。埋め込みベースの検索はアイテムを数値ベクトルとして表現し、意味的に関連するコンテンツを取得できるようにする。

この手法では、ユーザーが異なる表現を使っても、関連する製品や文書を見つけられる可能性がある。しかし、正確な名称、製品コード、珍しい用語では、依然としてキーワードマッチングが有利なことが多い。

ハイブリッド検索は、セマンティック検索とキーワード検索を組み合わせる。Databricksはこれを有用な一般的出発点として推奨しているが、同社のパフォーマンスガイダンスでは、ハイブリッドリクエストは通常、近似最近傍クエリの約2倍のリソースを消費するとしている。

近似最近傍検索、すなわちANNは、すべてのアイテムを総当たりで比較せずに近いベクトルを見つける。制御された近似を受け入れることで、配信効率を高める。

この選択は、関連性とキャパシティの両方に影響する。単純なANNリクエストでサイジングしたワークロードは、チームがハイブリッド検索、フィルタリング、リランキングを有効にした後では異なる挙動を示す可能性がある。

リランキングは、検索後に別のモデルを適用して候補を並べ替える。精度を向上させる可能性がある一方、Databricksによると、クロスエンコーダーのリランカーはクエリごとに、通常は1秒未満ではあるものの追加レイテンシーを生じさせる可能性がある。

その遅延は社内のリサーチツールなら許容できるかもしれない。しかし、キーストロークごとに更新される商品検索ボックスでは、はるかに長く感じられる可能性がある。

したがって本番環境で問うべきなのは、単に「エンドポイントは数千件のリクエストを処理できるか」ではない。「必要なレイテンシー内で、この正確なクエリ構成を処理できるか」だ。

この違いは、アプリケーションオーナー、プラットフォームエンジニア、データチームに同時に負荷をかける。アプリケーションオーナーは体験を定義し、プラットフォームチームはキャパシティを管理し、データチームは鮮度と検索品質を守る。

社内文書を扱うチームでは、検索の挙動は情報がどれほど一貫して収集・整理されているかにも左右される。検索可能なナレッジベースはアクセスを改善できるが、配信速度で欠落した文脈を補うことはできない。

高QPSは、インデックスにアクセスできるユーザー数を増やす。インデックスに適切な情報が含まれていることや、正しい結果が返ることまで保証するわけではない。

Databricksのプロトタイプが分離型検索スタックに挑む

Databricksは、本番の情報検索はデータプラットフォームを離れ、専用の配信インフラへ移さなければならないという前提に挑戦している。

一般的なアーキテクチャでは、データ準備とアプリケーション検索を分離する。チームは1つのプラットフォームでデータを変換・ガバナンスし、その後、レコードや埋め込みをオンライン検索向けに構築された別のシステムへエクスポートする。

この分離には利点がある。専用検索製品は、特化したインデックス制御、使い慣れた関連性ツール、特定ワークロードで実証済みのパフォーマンスを提供できる。

一方で、同期とガバナンスの作業も生じる。チームは更新をどれだけ早く移すか、どの権限を引き継ぐか、システム間の障害をどう整合させるかを決めなければならない。

Databricksは、顧客にその引き渡しを避けてもらいたい考えだ。AI Searchは、ソースデータ、同期プロセス、ガバナンス制御、クエリエンドポイントを、同じ広範なプラットフォーム内に保持する。

高QPSスケーリングは、インタラクティブなアプリケーションにとってこの主張をより説得力のあるものにする。十分なスループットがなければ、プラットフォームの統合性は実ユーザーが到来するまでしか魅力的ではない。

したがって主な競合相手は、特定の名前を持つ1つのデータベースではない。それを取り巻くレプリケーション、ルーティング、運用レイヤーを含む、分離された配信スタックである。

Vertex AI Vector Searchもキャパシティをマネージドサービスの課題として扱っており、Googleは有用な比較対象となる。Googleはオートスケーリング、複数レプリカ、再現率とレイテンシーのためのチューニング制御を文書化している。

Googleは、公開データセット全体で数千QPSに達したベクトル検索ベンチマークを報告している。これらの数値は特定のデータセット、次元数、レプリカ数、再現率目標を用いたものであり、Databricksとの直接比較ではない。

この注意書きは不可欠だ。ベンダーのスループット数値は、普遍的な性能ではなく、テスト済みの構成を示している。インデックスサイズ、ベクトル次元数、フィルター、結果件数、クエリタイプ、同時実行性はいずれも結果を変えうる。

Databricksは、単一の見出しとなるベンチマークではなく、参考レンジを公開している。同社の性能ガイドでは、標準エンドポイントのレイテンシーはおよそ20〜50ミリ秒、ベースラインのスループットは30〜200 QPS超とされている。

これらの数値は、新たにプロビジョニングされた高QPS容量ではなく、通常の構成を示すものだ。同社によれば、新しい設定では、対象の背後にインフラを追加することで、標準エンドポイントを数千QPS規模まで引き上げられる。

インデックスサイズも引き続き重要である。Databricksによると、標準的なベクトル検索ユニットは約200万ベクトルを保持し、標準エンドポイントは最大3億2,000万ベクトルをサポートする。

インデックスが追加のユニットにまたがるにつれ、ベースラインQPSは低下し、ANNクエリでは最終的に30 QPS前後で頭打ちになる可能性がある。高QPS容量は配信需要に対応するが、チームは依然としてインデックスの構成を理解する必要がある。

ストレージ最適化エンドポイントは別の特性を持つ。Databricksは、最大10億ベクトルの容量を文書化しているが、標準エンドポイントと比べてレイテンシーは高く、ベースラインスループットは低い。

これらのエンドポイントは2026年5月に一般提供となった。Databricksは、標準エンドポイントより10〜20倍速くデータをインデックス化でき、はるかに大規模なコレクションをサポートするとしている。

ただし、7月の高QPSリリースはまだストレージ最適化エンドポイントには拡張されていない。Databricksは、2026年後半にサポートを予定しているとしている。

この制約が、現在の競争上の境界を定めている。低レイテンシーの標準配信と、非常に大規模なストレージ最適化インデックスのどちらを選ぶにしても、新しいスケーリングモデルが同じように適用されるとは想定できない。

Googleのサービスは、異なる種類の制御を提供している。開発者はレプリカ数、マシンタイプ、検索割合、近傍数を調整できる。この柔軟性は、経験豊富なチームが性能を細かくチューニングするうえで役立つ場合がある。

Databricksは、この機能ではより宣言的なアプローチを取っている。開発者が希望するリクエストレートを指定し、プラットフォームが容量を計算する。

このトレードオフは、マネージドインフラ全体でよく知られている。抽象化を増やせば日常的な作業は減るが、特殊な最適化やコスト調査に必要な仕組みが見えにくくなることもある。

Databricksは、適用されたスケーリング状態とエンドポイントメトリクスを公開している。それでも、同サービスのAPIは target_qps を絶対的な保証ではなく、ベストエフォートの目標として説明している。

これはプラットフォーム選定時に重要となる。目標値はプロビジョニングを簡素化するが、本番のサービスレベル目標は依然としてアプリケーションチームの責任である。

Databricks内にとどまる最も強い根拠は、生データ取得の速度と同じくらいデータガバナンスと鮮度が重要な場合にある。コピーをもう1つ避けることで、運用面とセキュリティ面の複雑さを減らせる可能性がある。

一方、別スタックを採用する最も強い根拠は、ワークロードの専門性である。チームによっては、データプラットフォームが提供していない検索機能、クエリ言語、リージョントポロジー、またはチューニング制御を必要とする場合がある。

高QPSはその判断を狭める。だが、なくすわけではない。

構成パラメータだけでは負荷テストに代われない

Databricksは容量プロビジョニングを自動化するが、本番環境の信頼性は依然として代表的なテストと規律あるクエリ設計に依存する。

Databricks自身も、顧客にエンドポイントの負荷テストを勧めている。有用なテストでは、実際のトラフィック量、同時実行数、フィルター、クエリタイプ、結果サイズを再現する。

クリーンなANNクエリだけをテストすると、誤った安心感を招きかねない。本番アプリケーションでは、最初のプロトタイプが成功した後に、メタデータフィルター、ハイブリッド検索、リランキングが追加されることが多い。

選択肢ごとに消費するリソースは異なる。Databricksによると、ハイブリッド検索はANNのおよそ2倍のリソースを使用することがあり、より多くの結果を返すことでもスキャン処理は増加する。

同社のガイダンスでは、要求する結果件数を10倍に増やすと、レイテンシーが2倍になり、QPS容量が3分の1に低下する可能性があるとしている。正確な影響は、インデックスと構成に左右される。

ベクトル次元も別の変数となる。埋め込み次元とは、アイテムを表現するために使用される数値的特徴の数である。

より大きな埋め込みはより多くの情報を保持できるが、より多くの計算を必要とする。Databricksによると、次元数を768から384に減らすと、通常はQPSが約1.5倍向上し、レイテンシーは約20％削減される。

だからといって、すべての埋め込みを縮小すべきというわけではない。アプリケーションにとって重要な情報が表現から失われれば、検索品質は低下しうる。

チームは速度と並行して関連性も測定しなければならない。スループットのグラフが健全に見えても、弱い候補しか返さない高速なエンドポイントは本番運用の準備ができていない。

認証もボトルネックになりうる。Databricksは、本番アプリケーションでは個人用アクセストークンではなく、OAuthを利用するサービスプリンシパルを推奨している。

サービスプリンシパルは、ソフトウェアが使用する非人間のIDである。アプリケーションのアクセスを特定の従業員の認証情報に結び付けずに、管理された権限をサポートする。

Databricksによると、サービスプリンシパルのトラフィックは性能最適化されたネットワーク経路を使用する。同社のクエリドキュメントでは、このアプローチにより、ほかのルーティングと比べてリクエストあたり最大100ミリ秒を短縮できるとしている。

同社はまた、個人用アクセストークンのトラフィックは数十QPS程度に制限されるとしている。そのため、この認証経路を使用するプロトタイプは、エンドポイントが計画された容量に達する前に失敗する可能性がある。

チームは実際のアプリケーション環境からテストすべきだ。同じワークスペース内のノートブックでは、パブリックネットワーク経路、トークン生成、アプリケーションのリトライ、リージョン間の距離を再現できない。

リトライの挙動には特に注意が必要である。アプリケーションが429レスポンスを受け取った際、即時にリトライすると元のトラフィックスパイクを増幅する可能性がある。

バックオフとジッターは、リトライを時間的に分散させる。これらがなければ、一時的な容量問題が自己持続的なリクエストストームに発展しかねない。

目標値そのものにも余裕が必要である。平均トラフィックと同じ値に設定すると、急増、同期したクライアント、特別イベントに対する保護はほとんど残らない。

予想需要を大きく上回る設定には、別の懸念がある。Databricksは、目標値が設定されると追加容量には追加コストが発生すると指摘している。

この発表では、普遍的なコスト比較は示されていない。必要な容量はインデックス、クエリワークロード、性能目標によって異なるため、購入者は自ら測定する必要がある。

自動スケーリングは今回のリリースには含まれない。チームは、システムが手動サイジングなしで継続的に反応するのを待つのではなく、トラフィック到来前に容量を宣言する。

これにより、計画されたスケールと弾力的なスケールの間には運用上の違いが生じる。計画された目標値は既知のローンチには対応できるが、想定外の急増は当初の見積もりを超える可能性がある。

Databricksは、トラフィックスパイクへの自動応答を2026年後半に予定しているとしている。それまでは、可観測性と目標値の更新がサービス運用の一部となる。

APIも、この目標値をベストエフォートと表現している。この文言は、開発者が target_qps をあらゆるクエリ構成に対する契約上の保証として解釈すべきではないことを意味する。

大規模インデックスには別のリスクがある。Databricksのストレージ最適化エンドポイントはより大きな容量を提供するが、高QPSターゲティングは現在、標準エンドポイントにしか適用されない。

標準エンドポイントの上限に近づくチームは、アーキテクチャ上の選択を迫られる可能性がある。データを分割する、インデックスを複製する、またはストレージ最適化オプションへの高QPSサポートを待つことになる。

Databricksは、1つのエンドポイントで極端なスループットを満たせない場合、並列エンドポイントを推奨している。チームは別々のインデックスをエンドポイント間で分割するか、人気のインデックスを複製してトラフィックを分散できる。

これらの推奨は、このリリースが削減を目指すインフラ作業とよく似ている。構成モデルには実用上の境界があることを示している。

この機能は、サポート対象ワークロードにおける日常的なレプリカサイジングを不要にする。分散システムの制約をなくすものではない。

信頼できるデプロイメント計画では、通常トラフィック、予想されるピーク、障害起因のリトライ急増という3つの条件をテストすべきだ。また、各条件でレイテンシーと関連性の両方を記録すべきである。

チームは、負荷時のインデックス同期も評価すべきだ。新鮮なデータは検索品質の一部であり、古い情報から高速に応答するエンドポイントも、ユーザーに害を及ぼす可能性がある。

Databricksのプロトタイプが本番対応となるのは、これらのテストを通過してからである。新しい設定はその道のりを短縮するが、根拠はワークロードから得なければならない。

高QPSが本番検索を変えるかを示す3つのシグナル

次の段階は、弾力的なスケーリング、ストレージ最適化のサポート、そして顧客による独立したワークロード証拠にかかっている。

最初のシグナルは、トラフィックスパイクに対する自動スケーリングである。Databricksは、手動による容量計画やサイジングを必要としないこの機能を、2026年後半に予定しているとしている。

これが実現し、安定したテールレイテンシーを維持できれば、同社の本番環境向けの主張はより強くなる。チームは容量を構成する前に、すべてのピークを見積もる必要がなくなる。

自動スケーリングの応答が遅すぎる場合、顧客は依然として大きな余裕をプロビジョニングするかもしれない。そうなれば、プラットフォームが配信運用の大半を取り除いたという主張は弱まる。

規制対象の環境にとっては、タイミングも重要である。Databricksによると、同社のコンプライアンスセキュリティプロファイルを使用するワークスペースでは、高QPSが2026年8月下旬にデフォルトで利用可能になる見込みだ。

この拡張は、別個の運用経路を作らずに、この機能が通常のデプロイメントを超えて展開できるかを示すことになる。エンタープライズの購入者は、性能とコンプライアンス制御の両立を求めることが多い。

2つ目のシグナルは、ストレージ最適化エンドポイントのサポートである。これらのエンドポイントははるかに大規模なインデックスに対応するが、現在はレイテンシーが高く、新しい高QPS構成も利用できない。

この機能の追加は、製品ストーリーの2つの要素、すなわち10億規模の容量と高いリクエストスループットをつなぐことになる。それまでは、顧客はエンドポイントプロファイルを慎重に選ぶ必要がある。

成功すれば、大規模カタログでも同じ宣言型の配信モデルを採用できることになる。遅延や厳しい制限があれば、専門化されたベクトルデータベースやクラウドサービスの余地は残る。

3つ目のシグナルは顧客の証拠である。Databricksは容量メカニズムを発表したが、多様なワークロードにわたる性能を定義するのに十分な独立した本番結果はまだ公開していない。

有用な証拠には、インデックスサイズ、ベクトル次元、クエリ構成、フィルター、要求結果数、同時実行数、P95レイテンシー、達成QPSを含めるべきだ。こうした詳細のない見出し数字は、ほとんど指針にならない。

顧客レポートでは、運用作業についても説明すべきである。最も重要な問いは、Databricksが単に容量を追加したかではなく、チームがインフラを取り除けたかどうかだ。

重複インデックスとクライアント側ルーティングを廃止した小売事業者は、プラットフォーム継続性という論点を支持するだろう。安全のためにこれらのレイヤーを維持するチームがあれば、その主張には留保が付く。

開発者は、同期中のサービス挙動にも注目すべきだ。新しい容量はインデックスの作成または同期後に有効になるため、緊急のスケーリング変更のタイミングに影響する可能性がある。

この挙動は、計画されたイベントには合理的かもしれない。しかし、エンドポイントがすでに十分な余裕を持っていない限り、突発的で予測不能な需要にはあまり適していない。

競合の対応も注目に値する。マネージドベクトルサービスはすでに自動スケーリングやレプリカ制御を提供しており、専用システムもハイブリッド検索とフィルタリングを継続的に改善している。

Databricksはすべてのベンチマークで勝つ必要はない。ガバナンスされたレイクハウスデータをすでに利用している十分な数の顧客にとって、別個の配信プラットフォームを不要にすればよい。

この価値提案は製品検索にとどまらない。エンタープライズAIアシスタントも、文書、記録、権限にまたがる高速な検索に依存している。

チームがこうしたシステムを設計する際には、配信容量と信頼できる情報レイヤーの両方が必要となる。パーソナルナレッジシステムは個人のコンテキストに対応し、エンタープライズ検索はガバナンスと共有規模の要件を追加する。

7月のリリースは、後者に向けたより明確な本番導入の道筋を示した。これまで追加インフラを招いていた問題に対して、エンジニアリングチームへシンプルな制御手段を提供する。

それでも、この発表は万能の性能保証ではなく、運用モデルの変更として捉えるべきです。Databricks は、定義されたエンドポイントの範囲内で容量計算を自動化します。

次の最善のステップは具体的です。既存の Databricks プロトタイプで、本番環境のクエリ構成を完全に再現し、通常時とピークトラフィック時の両方で計測してください。

P95 レイテンシ、エラー率、関連性、同期動作、容量コストを追跡します。実際のアプリケーション環境から、サービスプリンシパル認証とリトライ動作をテストしてください。

そして決定的な問いを投げかけます。target_qps はサービングレイヤーを不要にしたのか、それともその計画を新しい設定項目へ移しただけなのか。この答えが、Databricks AI Search があなたのワークロードにおける本番運用の隔たりを埋めたかどうかを左右します。