メインコンテンツまでスキップ

ベクトル検索パフォーマンスガイド

Mosaic AI Vector Search は、高速でスケーラブルな検索を実現するために構築されています。検索のパフォーマンスは、 SKU選択、インデックス サイズ、クエリ タイプ、ベクトルの次元、認証方法、アプリケーションによるトラフィックの急増の処理方法など、さまざまな要因によって異なります。 ほとんどのワークロードはそのままでも十分に動作しますが、レイテンシを拡張または最適化する必要がある場合、このガイドでは、最適なベクトル検索パフォーマンスが得られるようにシステムを構成するのに役立つ実用的なヒントと一般的なパターンを紹介します。

パフォーマンスに影響を与える要因​

パフォーマンスは単一の数値ではなく、ワークロードの特性、構成の選択、およびクライアントの実装によって決まる範囲です。このガイドは、Mosaic AI Vector Search を最も効果的に使用できるように、パフォーマンスの仕組みに関する明確なメンタルモデルを構築できるように設計されています。

システムの動作に影響を与える主な要因は次のとおりです。

  • SKU の選択: 標準またはストレージ最適化。
  • インデックス サイズ: 保存されるベクトルの数。
  • 埋め込みサイズ: 通常 384～1536。
  • クエリ タイプ: 近似最近傍 (ANN) またはハイブリッド。
  • 要求された結果の数: 値が大きいほど、検索時間が長くなります。
  • 埋め込みタイプ: 管理型または自己管理型。
  • クエリ負荷: 一定期間にエンドポイントに到達するトラフィックの量。
  • 認証方法: アプリが Databricks に接続する方法。

この記事の残りの部分では、これらの各変数を調整するための実用的なヒントを示し、実際の展開での検索の待ち時間とクエリのスループットにどのように影響するかについて説明します。

適切なSKUを選択する​

Mosaic AI Vector Search には 2 つの SKU があり、それぞれワークロードに応じてレイテンシ、スケーラビリティ、コスト効率のバランスをとるように設計されています。アプリケーションに適した SKU を選択することが、パフォーマンスを調整するための最初の手段となります。

一般的に：

  • レイテンシが重要で、インデックスが 320M ベクトルを大幅に下回る場合は、標準エンドポイントを選択します。
  • 1,000 万以上のベクトルを操作し、ある程度の遅延を許容でき、ベクトルあたりのコスト効率を向上させる必要がある場合（最大 7 倍安価）は、ストレージ最適化エンドポイントを選択してください。

次の表は、予想されるパフォーマンスのガイドラインを示しています。

SKU

レイテンシー

QPS

インデックス容量

人気検索ユニット(VSU)サイズ

Standard

20～50ミリ秒

30～200人以上

3億2000万個のベクター

200万ベクター

ストレージ最適化

300～500ミリ秒

30～50

1Bベクトル

6400万個のベクター

インデックスサイズを理解する​

インデックスが単一のベクトル検索単位内に収まり、追加のクエリ負荷を処理するための余分なスペースがある場合に、パフォーマンスが最高になります。ワークロードが単一のベクトル検索ユニット（つまり、標準の場合は 200 万以上のベクトル、ストレージ最適化の場合は 6400 万以上のベクトル）を超えて拡張されると、レイテンシが増加し、QPS は徐々に減少します。最終的に、QPS は約 30 QPS (ANN) で安定します。

パフォーマンスは、クエリ パターン、フィルター、ベクトルの次元、同時実行性など、各ワークロードに固有の多くの要因によって異なります。以下の数字は参考値です。

SKU

ベクトル

ディメンション

レイテンシー

QPS

月間クエリ

Standard

10K

768

20ミリ秒

200以上

5億人以上

1000万

768

40ミリ秒

30

78M

1億

768

50ミリ秒

30

78M

ストレージ最適化

1000万

768

300ミリ秒

50

1億3000万

1億

768

400ミリ秒

40

1億

1B

768

500ミリ秒

30

78M

埋め込みサイズを最小化する​

ベクトルの次元とは、各ベクトルに含まれる特徴の数を指します。一般的な値は 384、768、1024、または 1536 です。次元が高くなると、より表現力豊かな表現が提供され、品質が向上しますが、コンピュートコストがかかります。 低次元ベクトルでは、検索中に必要な計算量が少なくなり、クエリ時間が短縮され、QPS が高くなります。逆に、高次元ベクトルはコンピュート負荷を増加させ、スループットを減少させます。

一般的なルールとして、ユースケースの検索品質を維持する最小の次元を選択します。

たとえば、次元数を 2 分の 1 (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値を試し、ワークロードへの影響を理解します。

本番運用ではゼロへのスケールを避ける​

ベクトル検索は、パフォーマンスのトレードオフが異なる 2 種類の埋め込みをサポートします。

管理された埋め込みが最も便利です。管理された埋め込みを使用すると、Databricks は行とクエリの両方の埋め込みを自動的に生成します。クエリ時に、クエリ テキストがモデルビング サー エンドポイントに渡されて埋め込みが生成されるため、レイテンシが追加されます。 埋め込みモデルが外部にある場合、追加のネットワーク オーバーヘッドも発生します。

自己管理型の埋め込みを使用すると、埋め込みを事前にコンピュートし、クエリ時にベクトルを直接渡すことができます。 これにより、ランタイム生成が回避され、最速の取得が可能になります。この記事に含まれるパフォーマンス数値はすべて、自己管理型の埋め込みに基づいています。

後期本番運用のユースケースでは、ゼロにスケールするモデル エンドポイントを避けてください。 コールド スタートでは、応答が数分間遅れる場合があり、クエリの到着時にエンドポイントが非アクティブな場合は障害が発生することもあります。

クエリの急増に備える​

このセクションでは、トラフィックが増加した場合に何が予想されるか、またレイテンシの急増や 429 エラー (リクエストが多すぎる) を引き起こす重大な制限を下回るようにする方法について説明します。

負荷が中程度のときはレイテンシは低いままですが、最大 QPS 容量に近づくにつれてレイテンシは徐々に増加します。システムが 100% の QPS 容量に達すると、429 エラーを返し始めます。適切なバックオフを設定していない場合、アプリが応答しなくなる可能性があります。

429 エラーはシステムを保護するための安全メカニズムとして機能します。突然のトラフィックの急増があってもエンドポイントが正常かつ応答性を維持できるように、クライアントにバックオフして後で再試行するように指示します。

ベスト プラクティスとして、バックオフと再試行処理が組み込まれている高速検索Python SDK使用します。

REST API を使用する場合は、ジッター付きの指数バックオフを実装します。こちらのAWS ブログ投稿をご覧ください。

OAuthでサービスプリンシパルを使用する​

最高のパフォーマンスを得るには、効率的な認証方法を使用します。Databricksでは、すべての本番運用環境でOAuth備えたサービス プリンシパルを使用することをお勧めします。 OAuthアクセス ウイルスは、より優れたセキュリティを提供するだけでなく、ネットワークに最適化されたインフラストラクチャを活用してシステムをフル稼働できるようにします。

個人アクセスウイルス (PAT) の使用は避けてください。PAT を使用すると、ネットワーク オーバーヘッドが発生し、数百ミリ秒の遅延が追加され、エンドポイントが維持できる QPS が大幅に低下します。

Python SDKを使用する​

最新バージョンの Python SDK を使用すると、組み込みのパフォーマンスと信頼性の最適化のメリットを享受できます。

クエリ間でインデックス オブジェクトを再利用します。このパターンは不要な遅延を発生させるため、すべてのリクエストでclient.get_index(...).similarity_search(...)を呼び出すことは避けてください。

代わりに、インデックスを一度初期化して再利用します。

Python
# Initialize once
index = client.get_index(...)

# Then use it for every query
index.similarity_search(...)

これは、エンドポイントの初期化時にインデックス オブジェクトを作成し、それをすべてのクエリで再利用できる MLFlow 環境で検索インデックスを使用する場合に重要です。

このガイダンスは、リアルタイムでレイテンシに敏感なアプリケーションに特に役立ちます。複数のインデックスまたはユーザーに代わっての承認フローを備えた RAG セットアップでは、インデックスの選択または資格情報がクエリ時にのみ使用できるため、インデックス オブジェクトを 1 回初期化することは実行できない可能性があります。これらのシナリオではこの最適化は必要ありません。

エンドポイント間で並列化​

Databricks では、システム内の合計 QPS を増やすために、次の戦略を検討することを推奨しています。

  • エンドポイント間でインデックスを分割します。複数のインデックスがあり、それぞれがトラフィックの大部分を受信する場合は、それらを別々のエンドポイントでホストして、合計帯域幅を高めます。
  • エンドポイント間でインデックスを複製します。ほとんどのトラフィックが単一のインデックスにヒットする場合は、それを複数のエンドポイントに複製します。トラフィックをクライアント レベルで均等に分割し、QPS を線形に向上させます。
に最終更新