Mosaic AI Vector Search
この記事では、Mosaic AI Vector Searchの概要について、その概要や仕組みなどについて説明します。
Mosaic AI Vector Searchとは?
Mosaic AI Vector Searchは、Databricks Data Intelligence Platformに組み込まれ、そのガバナンスおよび生産性ツールと統合されているベクトル検索ソリューションです。ベクトル検索は、埋め込みを取得するために最適化された検索の一種です。埋め込みは、データ (通常はテキストまたは画像データ) の意味内容を数学的に表現したものです。埋め込みは大規模言語モデルによって生成され、互いに類似したドキュメントや画像の検索に依存する多くの生成AI アプリケーションの主要なコンポーネントです。 例としては、RAGシステム、レコメンダーシステム、画像およびビデオ認識などがあります。
Mosaic AI Vector Searchを使用すると、Deltaテーブルからベクトル検索インデックスを作成できます。インデックスにはメタデータを含むエンベディングデータが含まれます。その後、REST APIを使用してインデックスをクエリーし、最も類似したベクトルを特定し、関連するドキュメントを返すことができます。基礎となるDeltaテーブルが更新されると、自動的に同期するようにインデックスを構成することができます。
Mosaic AI Vector Search では、次の機能がサポートされています。
- ハイブリッドキーワード類似性検索。
- フィルタリング。
- ベクトル検索エンドポイントを管理するためのアクセス制御リスト (ACL)。
- 選択した列のみを同期します。
- 生成された埋め込みを保存して同期します。
Mosaic AI Vector Searchはどのように機能しますか?
Mosaic AI Vector Searchは、近似最近傍探索にHNSW(Hierarchical Navigable Small World)アルゴリズムを使用し、埋め込みベクトルの類似度を測定するためにL2距離メトリクスを使用します。コサイン類似度を使用する場合は、データポイントの埋め込みを正規化してからベクトル検索に入力する必要があります。データポイントが正規化されると、L2距離によって生成されるランキングは、余弦類似度によって生成されるランキングと同じになります。
Mosaic AI Vector Searchは、ベクトルベースの埋め込み検索と従来のキーワードベースの検索技術を組み合わせた、ハイブリッドキーワード類似検索もサポートしています。このアプローチでは、クエリー内の単語を正確に一致させると同時に、ベクトルベースの類似性検索を使用してクエリーのセマンティック関係とコンテキストを取得します。
これら2つの技術を統合することで、ハイブリッドキーワード類似検索は、正確なキーワードだけでなく、概念的に類似したキーワードを含むドキュメントも検索し、より包括的で関連性の高い検索結果を提供します。このメソッドは、ソースデータにSKUや識別子のような一意のキーワードがあり、純粋な類似検索に適していないRAGアプリケーションで特に有効です。
API の詳細については、 Python SDK リファレンス と ベクトル検索エンドポイントのクエリを参照してください。
類似性検索の計算
類似性検索の計算では、次の式を使用します。
ここで、 dist
はクエリーq
とインデックスエントリx
間のユークリッド距離です。
キーワード検索アルゴリズム
関連性スコアは、 Okapi BM25 を使用して計算されます。 ソーステキストの埋め込み列や、テキストまたは文字列形式のメタデータ列など、すべてのテキスト列または文字列列が検索されます。 トークン化機能は、単語の境界で分割し、句読点を削除し、すべてのテキストを小文字に変換します。
類似検索とキーワード検索の組み合わせ
類似検索とキーワード検索の結果は、Reciprocal Rank Fusion(RRF)機能を使用して結合されます。
RRFは、スコアを使用して各メソッドからの各ドキュメントを再スコアリングします。
上の式では、ランクは0から始まり、各ドキュメントのスコアを合計して、最もスコアの高いドキュメントを返します。
rrf_param
上位ランクのドキュメントと下位ランクのドキュメントの相対的な重要度を制御します。文献に基づいて、 rrf_param
は60に設定されています。
スコアは、以下の式を用いて最高スコアを1、最低スコアを0とするように正規化されます:
ベクトル埋め込みを提供するためのオプション
Databricksでベクトル検索インデックスを作成するには、まずベクトル埋め込みの提供方法を決定する必要があります。Databricks では、次の 3 つのオプションがサポートされています。
-
オプション1: Databricksによって計算されるエンベディングを用いたDelta同期インデックス テキスト形式のデータを含むソースDelta テーブルを提供します。Databricks は、指定したモデルを使用してエンベディングを計算し、必要に応じて埋め込みを Unity Catalog のテーブルに保存します。 Delta テーブルが更新されても、インデックスは Delta テーブルと同期されたままになります。
次の図は、このプロセスを示しています。
- クエリーの埋め込みを計算します。クエリーにはメタデータフィルターを含めることができます。
- 最も関連性の高い文書を特定するために類似検索を実行します。
- 最も関連性の高いドキュメントを返し、クエリーに追加します。
-
オプション 2: 自己管理型のエンベディングを使用した Delta同期インデックス 事前に計算されたエンベディングを含むソース Delta テーブルを指定します。 Delta テーブルが更新されても、インデックスは Delta テーブルと同期されたままになります。
次の図は、このプロセスを示しています。
- クエリーはエンベディングで構成され、メタデータフィルターを含めることができます。
- 類似性検索を実行して、最も関連性の高いドキュメントを特定します。最も関連性の高いドキュメントを返し、クエリーに追加します。
-
オプション 3: Direct Vector Access Index エンベディングテーブルが変更された場合は、REST API を使用してインデックスを手動で更新する必要があります。
次の図は、このプロセスを示しています。
Mosaic AI Vector Searchの設定方法
Mosaic AI Vector Searchを使用するには、以下を作成する必要があります。
-
ベクトル検索エンドポイント。 このエンドポイントは、ベクトル検索インデックスを提供します。 エンドポイントのクエリと更新は、REST API または SDK を使用して行うことができます。 手順については 、ベクトル検索エンドポイントの作成 を参照してください。
エンドポイントは、インデックスのサイズまたは並列要求の数をサポートするために自動的にスケールアップします。 エンドポイントは自動的にスケールダウンされません。
-
ベクトル検索インデックス。 ベクトル検索インデックスは Delta テーブルから作成され、リアルタイムの近似近傍検索を提供するように最適化されています。 検索の目的は、クエリに類似したドキュメントを特定することです。 ベクトル検索インデックスは、Unity Catalog に表示され、Unity Catalog によって管理されます。 手順については、ベクトル検索インデックスの作成 を参照してください。
さらに、エンベディングをDatabricksに計算させることを選択した場合は、事前に構成された基盤モデル API エンドポイントを使用するか、モデルサービング エンドポイントを作成して、選択したエンベディングモデルを提供できます。 手順については、トークン単位の従量課金 基盤モデル API または 基盤モデルをサービングするエンドポイントの作成を参照してください。
モデルサービング エンドポイントをクエリするには、 REST API または Python SDKを使用します。 クエリでは、Delta テーブル内の任意の列に基づいてフィルターを定義できます。 詳細については、 クエリでフィルターを使用する、API リファレンス、または Python SDK リファレンスを参照してください。
必要条件
- Unity Catalog対応ワークスペースであること。
- サーバレス コンピュートが有効化されていること。手順については、 サーバレス コンピュートへの接続を参照してください。
- ソース テーブルでは、チェンジデータフィードが有効になっている必要があります。 手順については、DatabricksでのDelta Lakeチェンジデータフィードの使用 を参照してください。
- ベクトル検索インデックスを作成するには、インデックスが作成されるカタログスキーマに対する CREATE TABLE 権限が必要です。
ベクトル検索エンドポイントを作成および管理するためのアクセス許可は、アクセス制御リストを使用して構成されます。 ベクトル検索エンドポイント ACLを参照してください。
データ保護と認証
Databricksでは、データを保護するために次のセキュリティ制御機能を実装しています。
- Mosaic AI Vector Searchに対するすべての顧客のリクエストは、論理的に分離され、認証され、承認されます。
- Mosaic AI Vector Searchは、保存中(AES-256)と転送中(TLS 1.2+)のすべてのデータを暗号化します。
Mosaic AI Vector Search では、サービスプリンシパルと個人用アクセス トークン (PAT) の 2 つの認証モードがサポートされています。 本番運用アプリケーションの場合、 Databricks では、パーソナル・アクセス・トークンに比べてクエリーごとのパフォーマンスが最大 100 ミリ秒高速になるサービスプリンシパルを使用することをお勧めします。
-
サービスプリンシパル トークン. 管理者は、サービスプリンシパル トークンを生成し、それを SDK または APIに渡すことができます。 サービスプリンシパルを使用するを参照してください。本番運用のユースケースでは、 Databricks はサービスプリンシパル トークンを使用することをお勧めします。
Python# Pass in a service principal
vsc = VectorSearchClient(workspace_url="...",
service_principal_client_id="...",
service_principal_client_secret="..."
) -
個人用アクセストークン。 個人用アクセス トークンを使用して、 Mosaic AI Vector Searchで認証できます。 パーソナルアクセス認証トークンを参照してください。ノートブック環境で SDK を使用する場合、SDK は認証用の PAT トークンを自動的に生成します。
Python# Pass in the PAT token
client = VectorSearchClient(workspace_url="...", personal_access_token="...")
顧客管理キー (CMK) は、2024 年 5 月 8 日以降に作成されたエンドポイントでサポートされています。
使用状況とコストの監視
課金利用システムテーブルを使用すると、ベクトル検索インデックスとエンドポイントに関連する使用量とコストを監視することができます。クエリーの例を次に示します。
WITH all_vector_search_usage (
SELECT *,
CASE WHEN usage_metadata.endpoint_name IS NULL THEN 'ingest'
WHEN usage_type = "STORAGE_SPACE" THEN 'storage'
ELSE 'serving'
END as workload_type
FROM system.billing.usage
WHERE billing_origin_product = 'VECTOR_SEARCH'
),
daily_dbus AS (
SELECT workspace_id,
cloud,
usage_date,
workload_type,
usage_metadata.endpoint_name as vector_search_endpoint,
CASE WHEN workload_type = 'serving' THEN SUM(usage_quantity)
WHEN workload_type = 'ingest' THEN SUM(usage_quantity)
ELSE null
END as dbus,
CASE WHEN workload_type = 'storage' THEN SUM(usage_quantity)
ELSE null
END as dsus
FROM all_vector_search_usage
GROUP BY all
ORDER BY 1,2,3,4,5 DESC
)
SELECT * FROM daily_dbus
予算ポリシーごとに使用量をクエリすることもできます。Mosaic AI Vector Search: 予算ポリシーをご覧ください。
請求利用テーブルの内容については、 課金利用 システムテーブルリファレンスを参照してください。 追加のクエリは、次のノートブックの例にあります。
ベクトル検索システムテーブルクエリノートブック
リソースとデータのサイズ制限
次の表は、ベクトル検索のエンドポイントとインデックスに対するリソースとデータサイズの上限を示しています。
リソース | 粒度 | 上限 |
---|---|---|
ベクトル検索エンドポイント | ワークスペースごと | 100 |
Embeddings | エンドポイントごと | 320,000,000 |
エンベディングの次元 | インデックスごと | 4096 |
インデックス | エンドポイントごと | 50 |
列 | インデックスごと | 50 |
列 | サポートされているタイプ:バイト、short、integer、long、float、double、boolean、文字列、タイムスタンプ、日付 | |
メタデータフィールド | インデックスごと | 50 |
インデックス名 | インデックスごと | 128文字 |
ベクトル検索のインデックスの作成と更新には、次の上限が適用されます。
リソース | 粒度 | 上限 |
---|---|---|
Delta Syncインデックスの行サイズ | インデックスごと | 100KB |
Delta Syncインデックスの埋め込みソース列サイズ | インデックスごと | 32764バイト |
Direct Vectorインデックスの一括アップサートリクエストのサイズ | インデックスごと | 10MB |
Direct Vectorインデックスの一括削除リクエストのサイズ | インデックスごと | 10MB |
クエリーAPIには、次の制限が適用されます。
リソース | 粒度 | 上限 |
---|---|---|
クエリテキストの長さ | クエリごと | 32764バイト |
返される結果の最大数 (近似最近隣検索) | クエリごと | 10,000 |
返される結果の最大数 (ハイブリッド キーワード類似検索) | クエリごと | 200 |
制限
- 列名
_id
は予約されています。ソース・テーブルに_id
という名前のカラムがある場合は、ベクトル検索インデックスを作成する前に名前を変更します。 - 行および列レベルの権限はサポートされていません。ただし、フィルターAPI 使用してアプリケーションレベルのACLを独自に実装することは可能です。