AI検索パフォーマンスガイド
AI Search は、高速でスケーラブルな検索を実現します。AI Searchのパフォーマンスは、SKUの選択、インデックスサイズ、クエリタイプ、ベクトル次元、認証方法、アプリケーションがトラフィックスパイクを処理する方法など、多くの要因によって異なります。ほとんどのワークロードは特別な設定なしに良好に動作しますが、スケーリングやレイテンシーの最適化が必要な状況では、最適なパフォーマンスを実現するためにシステムを構成するのに役立つ実践的なヒントと一般的なパターンを、このガイドでご紹介します。
パフォーマンスに影響を与える要因
パフォーマンスは単一の数値ではなく、ワークロードの特性、構成の選択、クライアントの実装に依存する範囲です。このガイドは、パフォーマンスがどのように機能するかについての明確なメンタルモデルを構築し、AI Searchを最も効果的に使用できるように設計されています。
システムがどのように動作するかに影響を与える主要な要因は以下のとおりです。
- SKU の選択：標準またはストレージ最適化
- インデックスサイズ：保存されているベクトルの数
- 埋め込みサイズ: 通常384～1536です。
- クエリタイプ：近似最近傍（ANN）またはハイブリッド。
- 要求された結果数：値が高いほど、取得時間は長くなります。
- 埋め込みタイプ：マネージド型またはセルフマネージド型
- クエリー負荷：時間の経過とともにエンドポイントにかかるトラフィックの量です。
- 認証方法: アプリがDatabricksに接続する方法。
本記事では、これらの変数のそれぞれを調整するための実用的なヒントを提供し、実際のデプロイメントにおける検索レイテンシーとクエリのスループットにそれらがどのように影響するかを説明します。
適切なSKUを選択する
AI Search は2つの SKU を提供しており、それぞれが、ワークロードに応じて待機時間、スケーラビリティ、およびコスト効率のバランスを取るように設計されています。アプリケーションに合った適切なSKUを選択することが、パフォーマンスチューニングにおける最初の手段となります。
一般に：
- レイテンシーが非常に重要で、インデックスが3億2千万ベクトルをはるかに下回る場合は、標準エンドポイントを選択してください。
- 1000万個以上のベクトルを扱っており、多少の追加レイテンシーを許容でき、ベクトルあたりのコスト効率を向上させる必要がある場合は、ストレージ最適化エンドポイントを選択してください（最大7倍安価です）。
次の表は、いくつかの期待されるパフォーマンスガイドラインを示しています。
SKU | レイテンシー | QPS | エンドポイント容量 | ベクトル検索ユニット(VSU)サイズ |
|---|---|---|---|---|
Standard | 20～50ミリ秒 | 30～200+ | 3億2千万ベクトル | 2 M ベクター |
ストレージ最適化 | 300～500ミリ秒 | 30～50 | 10億ベクトル | 64M ベクトル |
インデックスのサイズを理解する
インデックスが単一のベクトル検索ユニット内に収まり、追加のクエリ負荷に対応できる十分なスペースがある場合に、最高のパフォーマンスが得られます。ワークロードが単一のベクトル検索ユニット（標準で2M以上のベクトル、ストレージ最適化で64M以上に対応）を超えてスケールすると、レイテンシーが増加し、QPSが低下します。最終的に、QPSは約30 QPSで安定します（ANN）。
性能は、クエリパターン、フィルター、ベクトルの次元、同時実行性など、各ワークロードに固有の多くの要因に依存します。次の番号は参照点です。
SKU | ベクトル | ディメンション | レイテンシー | QPS | 月次クエリ |
|---|---|---|---|---|---|
Standard | 10,000 | 768 | 20 ms | 200以上 | 5億以上 |
1000 万ドル | 768 | 40 ms | 30 | 7,800万 | |
1億 | 768 | 50 ms | 30 | 7,800万 | |
ストレージ最適化 | 1000 万ドル | 768 | 300 ms | 50 | 1億3000万 |
1億 | 768 | 400ms | 40 | 1億 | |
1B | 768 | 500 ms | 30 | 7,800万 |
エンベディングサイズを最小化
ベクトル次元は、各ベクトル内の特徴量の数を指します。一般的な値は384、768、1024、または1536です。高次元により、品質の向上につながる、より表現力豊かな表現が可能になりますが、コンピュートコストがかかります。低次元ベクトルは、検索時の計算負荷が軽減されるため、クエリ時間が短縮され、QPSが向上します。逆に、高次元ベクトルはコンピュート負荷を高め、スループットを低下させます。
一般的に、ご自身のユースケースで検索品質を維持できる最小の次元数を選択してください。
たとえば、インデックスのサイズとクエリパターンに応じて、次元を半分（たとえば 768 から 384 に）削減すると、通常、QPS は約 1.5 倍向上し、レイテンシは約 20% 削減されます。これらの効果は、非常に低い次元性でさらに複合的に増加します。例えば、64次元のベクトルを使用すると、表に示されている768次元のベンチマークと比較して、QPSを劇的に向上させ、遅延を大幅に削減できます。そのため、384次元以下は、検索品質が許容範囲内である限り、高スループットでレイテンシが重要なユースケースにとって特に魅力的です。
ANNを効率的に使用し、必要に応じてハイブリッドを使用してください。
可能な限りANNクエリをご利用ください。最もコンピュート効率が高く、最高のQPSをサポートします。
必要に応じてハイブリッド検索を使用してください。特にドメイン固有のキーワードが重要な特定のアプリケーションでは、ハイブリッド検索が再現率を向上させます。ハイブリッド検索は、通常、ANNの約2倍のリソースを使用し、スループットを大幅に低下させる可能性があります。
10～100の結果を使用する
各クエリには、返される検索結果の数であるnum_resultsパラメーターが含まれます。 この値はパフォーマンスに直接影響します。より多くの結果を取得するには、インデックスのより深いスキャンが必要になり、レイテンシが増加し、QPS が減少します。値が大きいほど、効果は大きくなります。たとえば、 num_results 10 倍に増やすと、インデックスのサイズと構成に応じて、クエリのレイテンシが 2 倍になり、QPS 容量が 3 分の 1 に減少する可能性があります。
ベストプラクティスとして、アプリケーションで特にそれ以上が必要な場合を除き、num_resultsは10～100の範囲に保ってください。現実的なクエリを使用してさまざまな num_results の値を試し、ワークロードへの影響を理解してください。
本番運用ではゼロへのスケーリングを避けてください
AIサーチは2種類の埋め込みをサポートしており、それぞれパフォーマンスに異なるトレードオフがあります。
マネージド型埋め込みは最も便利です。管理されたエンべディングにより、Databricks は行とクエリの両方に対して自動的にエンべディングを生成します。クエリー時には、クエリーテキストが埋め込みを生成するためにモデルサービングエンドポイントに渡されます。これにより、レイテンシーが増加します。エンベディングモデルが外部のものである場合、追加のネットワークオーバーヘッドも伴います。
セルフマネージド型埋め込みでは、事前に埋め込みをコンピュートし、クエリ時にベクトルを直接渡すことができます。これにより、ランタイム生成を回避し、最速の検索が可能になります。この記事に含まれるすべてのパフォーマンス数値は、セルフマネージド型埋め込みに基づいています。
現実の本番運用のユースケースでは、ゼロにスケールするモデル エンドポイントを避けてください。 コールド スタートでは、応答が数分間遅れる場合があり、クエリの到着時にエンドポイントが非アクティブな場合は障害が発生することもあります。
クエリー スパイクの計画
このセクションでは、トラフィックの増加に伴い何が起こるか、そしてレイテンシーの急増や429エラー（「要求が多すぎます」）をトリガーする重要な制限を下回るようにする方法について説明します。
負荷が中程度である場合、レイテンシは低く保たれ、最大 QPS 容量に近づくにつれて徐々に増加します。システムが100％のQPS容量に達すると、429エラーを返し始めます。適切なバックオフが設定されていない場合、アプリが応答しなくなる可能性があります。
429 エラーはシステムを保護するための安全機構です。クライアントにバックオフして後で再試行するよう指示し、突然のトラフィック急増時でもエンドポイントが健全で応答性の高い状態を維持できるようにします。
ベストプラクティスとして、バックオフと再試行処理が組み込まれているAI Search Python SDKを使用します。
REST API を使用する場合は、ジッター付きのエクスポネンシャル バックオフを実装してください。
OAuthトークンでサービスプリンシパルを使用する
最高のパフォーマンスを得るには、効率的な認証方法を使用します。Databricksでは、すべての本番運用環境でOAuth備えたサービス プリンシパルを使用することをお勧めします。 OAuthアクセス トークンは、より優れたセキュリティを提供するだけでなく、ネットワークに最適化されたインフラストラクチャを活用してシステムをフル稼働できるようにします。
パーソナルアクセストークン (PAT) の使用は避けてください。PAT を使用すると、ネットワーク オーバーヘッドが発生し、数百ミリ秒の遅延が追加され、エンドポイントが維持できる QPS が大幅に低下します。
Python SDK を使用する
Python SDK の最新バージョンを使用すると、組み込みのパフォーマンスと信頼性の最適化を活用できます。
複数のクエリでインデックスオブジェクトを再利用します。このパターンは不要なレイテンシーを追加するため、各リクエストで「client.get_index(...).similarity_search(...)」を呼び出すことは避けてください。
代わりに、インデックスを一度初期化して再利用してください：
# Initialize once
index = client.get_index(...)
# Then use it for every query
index.similarity_search(...)
これは、MLFlow環境でAI Searchインデックスを使用する際に重要です。エンドポイントの初期化時にインデックスオブジェクトを作成し、その後すべてのクエリでそれを再利用できます。
このガイダンスは、リアルタイムであり、レイテンシーに影響を受けやすいアプリケーションで特に役立ちます。複数のインデックスを使用するRAG設定、またはユーザー代理承認フローにおいて、インデックスの選択や認証情報がクエリ時にのみ利用可能である場合、インデックスオブジェクトを一度初期化することは実現できない場合があります。この最適化は、そのようなシナリオでは必要ありません。
高QPSでのエンドポイントスループットのスケール
プレビュー
この機能は パブリック プレビュー段階です。
デフォルトでは、標準エンドポイントはインデックスのサイズに応じて20～200 QPSをサポートしています。検索バー、レコメンデーションシステム、エンティティマッチングのようなリアルタイムアプリケーションは、多くの場合、100〜1,000以上のQPSを必要とします。標準エンドポイントのみ、ターゲットQPSを設定できます。Databricks は、インデックスが作成または同期される際に、そのスループットレベルに最も適したインフラストラクチャをプロビジョニングします（ベストエフォートであり、保証されません）。
高QPSを使用するのは、次のような場合です：
- お客様のアプリケーションには、50 QPSを超える持続的なスループットが必要です。
- 通常の負荷時に429 (リクエストが多すぎます) エラーが発生します。
- トラフィックが増加すると、平均利用率が低く見える場合でも、レイテンシは低下します。
Databricks UI、SDK、またはREST APIを使用して、ターゲットQPSを設定できます。高QPSによるエンドポイントスループットのスケールを参照してください。
エンドポイント間での並列化
ワークスペースで高QPSが利用できない場合、または単一のエンドポイントでは対応しきれないほど非常に高いスループットが必要な場合、Databricks は以下の戦略を推奨しています。
- エンドポイント間でインデックスを分割します。 複数のインデックスがあり、それぞれがかなりのトラフィックを受信する場合、より高い合計帯域幅を実現するために、それらを別々のエンドポイントでホストしてください。
- インデックスをエンドポイント間で複製する。 ほとんどのトラフィックが単一のインデックスに集中する場合、複数のエンドポイントに複製し、クライアントレベルでトラフィックを均等に分割することで、QPSの線形的な向上を実現します。
負荷テストを使用して、エンドポイントが正しくサイズ設定されていることを確認してください。
負荷テストは、さまざまなトラフィックレベルでのAI Searchエンドポイントのパフォーマンスを測定し、実際の使用状況をシミュレートすることで、本番運用の要件を満たすようにエンドポイントを適切にサイズ設定するのに役立ちます。負荷テストを作成して実行する方法の詳細については、「AI Search エンドポイントの負荷テストを構成する」を参照してください。