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

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

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

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

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

• SKU の選択: 標準またはストレージ最適化。
• インデックスサイズ:格納されているベクトルの数。
• 埋め込みサイズ:通常384〜1536。
• クエリの種類: 近似最近傍 (ANN) またはハイブリッド。
• 要求された結果の数: 値が大きいほど、取得時間が長くなります。
• 埋め込みタイプ: マネージドまたはセルフマネージド。
• クエリの負荷: 時間の経過とともにエンドポイントに到達するトラフィックの量。
• 認証方法: アプリが Databricks に接続する方法。

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

適切なSKUを選択する

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

原則として：

• レイテンシーが重要で、インデックスが 320M ベクトルをはるかに下回っている場合は、標準エンドポイントを選択します。
• 10M+ ベクトルを扱い、余分なレイテンシーを許容でき、ベクトルあたりのコスト効率の向上 (最大 7 倍安) が必要な場合は、ストレージに最適化されたエンドポイントを選択します。

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

SKU	レイテンシー	QPS	インデックス容量	ベクトル検索ユニット(VSU)サイズ
Standard	20〜50ミリ秒	30–200+	320Mベクトル	2Mベクトル
ストレージ最適化	300〜500ミリ秒	30–50	1Bベクトル	64Mベクトル

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

インデックスが 1 つのベクトル検索ユニット内に収まり、追加のクエリ負荷を処理するための余分な領域がある場合に、パフォーマンスが最も高くなります。ワークロードが単一のベクトル検索ユニット(つまり、標準の場合は2M+ベクトル、ストレージ最適化の場合は64M+ベクトル)を超えて拡張されると、レイテンシーが増加し、QPSは徐々に低下します。最終的に、QPS は約 30 QPS (ANN) で頭打ちになります。

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

SKU	ベクトル	ディメンション	レイテンシー	QPS	毎月のクエリ
Standard	10K	768	20ミリ秒	200+	500メートル+
	10分	768	40ミリ秒	30	78分
	100メートル	768	50ミリ秒	30	78分
ストレージ最適化	10分	768	300ミリ秒	50	130メートル
	100メートル	768	400ミリ秒	40	100メートル
	1B	768	500ミリ秒	30	78分

埋め込みサイズの最小化

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

原則として、ユースケースの取得品質を維持する最小の次元を選択します。

たとえば、次元を 2 倍に減らすと (たとえば、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 倍に削減されます。

ベストプラクティスとして、アプリケーションで特にそれ以上を必要としない限り、 num_results を 10 から 100 の範囲に保ちます。現実的なクエリを使用してさまざまな num_results 値を試し、ワークロードへの影響を理解します。

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

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

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

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

の場合 リアルタイム 本番運用 ユースケースでは、ゼロにスケーリングするモデルエンドポイントは避けてください。 コールドスタートは、応答を数分遅らせたり、クエリの到着時にエンドポイントが非アクティブである場合に障害を引き起こしたりする可能性があります。

クエリのスパイクを計画する

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

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

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

ベストプラクティスとして、組み込みバックオフと再試行処理を含む ベクトル検索 Python SDKを使用します。

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

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

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

個人用アクセス トークン (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 を増やすために、次の戦略を検討することをお勧めします。

• エンドポイント間でインデックスを分割します。トラフィックのかなりの部分を受信する複数のインデックスがある場合は、それらを別々のエンドポイントでホストして、合計帯域幅を増やします。
• エンドポイント間でインデックスをレプリケートします。ほとんどのトラフィックが 1 つのインデックスにヒットする場合は、複数のエンドポイントにまたがって複製します。クライアントレベルでトラフィックを均等に分割して、線形の QPS ゲインを実現します。