ベクター検索のパフォーマンス ガイド

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

パフォーマンスに影響を与える係数

パフォーマンスは単一の数値ではなく、ワークロードの特性、構成の選択、クライアントの実装に依存する範囲です。 このガイドは、モザイク AI ベクター検索を最も効果的に使用できるように、パフォーマンスのしくみの明確なメンタル モデルを構築するのに役立ちます。

システムの動作に影響を与える主な要因を次に示します。

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

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

適切な SKU を選択する

Mosaic AI Vector Search には 2 つの SKU が用意されており、それぞれがワークロードに応じて待機時間、スケーラビリティ、コスト効率のバランスを取るために設計されています。 パフォーマンスをチューニングするための最初のレバーは、アプリケーションに適した SKU を選択することです。

一般:

• 待機時間が重要で、インデックスが 320M ベクトル未満の場合は、標準エンドポイントを選択します。
• 10M 以上のベクトルを使用する場合は、ストレージ最適化エンドポイントを選択します。余分な待機時間を許容でき、ベクターあたりのコスト効率を向上させる必要があります (最大 7 倍安く)。

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

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

インデックスが 1 つのベクター検索ユニット内に収まり、追加のクエリ読み込みを処理するための余分な領域がある場合、パフォーマンスが最も高くなります。 ワークロードが 1 つのベクター検索ユニット (つまり、標準では 2M 以上、ストレージ最適化の場合は 64M 以上) を超えてスケーリングされるにつれて、待機時間が増加し、QPS は先細りになります。 最終的に、QPS は約 30 QPS (ANN) で台頭します。

パフォーマンスは、クエリ パターン、フィルター、ベクター次元、コンカレンシーなど、各ワークロードに固有の多くの要因に依存します。 次の数値は参照ポイントです。

埋め込みサイズを最小限に抑える

ベクター次元は、各ベクター内の特徴の数を指します。 一般的な値は、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 値を試して、ワークロードへの影響を理解します。

運用環境ではゼロへのスケールを回避する

Vector Search では、パフォーマンスのトレードオフが異なる 2 種類の埋め込みをサポートしています。

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

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

リアルタイム運用のユース ケースでは、ゼロにスケーリングするモデル エンドポイントは避けてください。 コールド スタートでは、応答が数分遅れる場合や、クエリが到着したときにエンドポイントが非アクティブな場合にエラーが発生する可能性があります。

クエリスパイクの計画

このセクションでは、トラフィックの増加に伴う想定事項と、待機時間の急増や 429 エラー (要求が多すぎます) を引き起こす重大な制限を下回る方法について説明します。

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

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

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

REST API を使用する場合は、ジッターを使用して指数バックオフを実装します。 Azure のアンチパターンを参照してください。

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

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

ネットワーク オーバーヘッドが発生し、数百ミリ秒の待機時間が増加し、エンドポイントが維持できる QPS を大幅に削減するため、個人用アクセス トークン (IOPS) の使用は避けてください。

Python SDK の使用

最新バージョンの Python SDK を使用して、組み込みのパフォーマンスと信頼性の最適化を活用します。

クエリ間でインデックス オブジェクトを再利用します。 このパターンでは不要な待機時間が増えるので、すべての要求で client.get_index(...).similarity_search(...) を呼び出さないようにします。

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

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

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

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

このガイダンスは、待機時間の影響を受けやすいリアルタイム アプリケーションで特に役立ちます。 複数のインデックスまたは ユーザーの代理承認 フローを使用する RAG セットアップでは、インデックスの選択または資格情報はクエリ時にのみ使用できるため、インデックス オブジェクトを 1 回初期化できない可能性があります。 このようなシナリオでは、この最適化は必要ありません。

エンドポイント間で並列化する

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

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

ロード テストを使用してエンドポイントのサイズが正しいことを確認する

ロード テストは、さまざまなレベルのトラフィックでベクター検索エンドポイントのパフォーマンスを測定し、実際の使用状況をシミュレートし、運用環境の要件を満たすようにエンドポイントのサイズを正しく設定するのに役立ちます。 ロード テストを作成して実行する方法の詳細については、 ベクター検索エンドポイント のロード テストの構成に関するページを参照してください。