この記事では、モザイク AI ベクター検索の概要と、そのしくみについて説明します。
Mosaic AI ベクトル検索とは
モザイク AI ベクター検索は、Databricks データ インテリジェンス プラットフォームに組み込まれており、そのガバナンスおよび生産性ツールと統合されたベクター検索ソリューションです。 ベクター検索は、埋め込みを取得するために最適化された検索の一種です。 埋め込みとは、データ (通常はテキストまたは画像データ) のセマンティック コンテンツの数学的表現です。 埋め込みは大規模な言語モデルによって生成され、互いに似たドキュメントや画像の検索に依存する多くの生成 AI アプリケーションの重要なコンポーネントです。 たとえば、RAG システム、レコメンダー システム、画像およびビデオ認識などがあります。
モザイク AI ベクター検索では、Delta テーブルからベクター検索インデックスを作成します。 そのインデックスには、メタデータを含む埋め込みデータが含まれます。 それから、REST API を使用してそのインデックスにクエリを実行し、最も類似したベクトルを特定して、関連付けられているドキュメントを返すことができます。 基になる Delta テーブルが更新されたときに自動的に同期するようにインデックスを構成できます。
モザイク AI ベクター検索では、次の機能がサポートされます。
- ハイブリッドキーワード類似性検索。
- フィルター処理。
- ベクター検索エンドポイントを管理するためのアクセス制御リスト (ACL)。
- 選択した列のみを同期します。
- 生成された埋め込みを保存して同期します。
モザイク AI ベクター検索のしくみ
Mosaic AI ベクトル検索では、近似ニアレストネイバー探索に Hierarchical Navigable Small World (HNSW) アルゴリズムを使用し、埋め込みベクトルの類似性を測定するために L2 距離による距離メトリックを使用します。 コサイン類似度を使用したい場合は、データポイント埋め込みをベクトル検索にフィードする前に正規化する必要があります。 データ ポイントが正規化されると、L2 距離によって生成されるランク付けは、コサイン類似度によって生成されるランク付けと同じになります。
Mosaic AI ベクトル検索では、ベクトルベースの埋め込み検索と従来のキーワードベースの検索手法を組み合わせたハイブリッド キーワード類似性検索もサポートされています。 この手法は、クエリ内の正確な単語と一致させると同時に、ベクトルベースの類似性検索を使用して、クエリのセマンティック リレーションシップとコンテキストをキャプチャします。
ハイブリッド キーワード類似性検索では、これら 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 カタログのテーブルに埋め込みを保存します。 Delta テーブルが更新されると、インデックスは Delta テーブルと同期されます。
次の図にこのプロセスを示します。
- クエリの埋め込みを計算してください。 クエリにはメタデータ フィルターを含めることができます。
- 類似性検索を実行して、最も関連性の高いドキュメントを特定してください。
- 最も関連性の高いドキュメントを返し、それをクエリに追加してください。
オプション 2: 自己管理埋め込みによる差分同期インデックス 事前計算された埋め込みを含むソース Delta テーブルを提供します。 Delta テーブルが更新されると、インデックスは Delta テーブルと同期されます。
次の図にこのプロセスを示します。
- クエリは埋め込みで構成され、メタデータ フィルターを含めることができます。
- 類似性検索を実行して、最も関連性の高いドキュメントを特定してください。 最も関連性の高いドキュメントを返し、それをクエリに追加してください。
オプション 3: 直接ベクター アクセス インデックス 埋め込みテーブルが変更された場合は、REST API を使用してインデックスを手動で更新する必要があります。
次の図にこのプロセスを示します。
エンドポイント オプション
モザイク AI ベクター検索には次のオプションが用意されているため、アプリケーションのニーズを満たすエンドポイント構成を選択できます。
注
ストレージ最適化エンドポイントは パブリック プレビュー 段階にあり、 eastus
、 eastus2
、 westus
、 westus2
、 westeurope
の各リージョンで利用できます。
- 標準 エンドポイントの容量は、ディメンション 768 で 3 億 2,000 万ベクトルです。
- ストレージ最適化 エンドポイントの容量は大きく (ディメンション 768 で 10 億ベクトルを超えています)、インデックス作成が 10 ~ 20 倍高速化されます。 ストレージ最適化エンドポイントに対するクエリの待機時間は、約 250 ミリ秒で若干増加します。 このオプションの価格は、ベクターの数が多い場合に最適化されています。 価格の詳細については、 ベクター検索の価格に関するページを参照してください。 ベクター検索コストの管理については、「 モザイク AI ベクター検索: コスト管理ガイド」を参照してください。
エンドポイントの種類は、エンドポイントの作成時に指定します。
ストレージ最適化エンドポイントの制限事項も参照してください。
モザイク AI ベクター検索を設定する方法
Mosaic AI ベクトル検索を使用するには、以下のものを作成する必要があります。
ベクトル検索エンドポイント。 このエンドポイントは、ベクトル検索インデックスを提供します。 REST API または SDK を使用して、エンドポイントのクエリと更新を行うことができます。 手順については 、「ベクター検索エンドポイントの作成 」を参照してください。
エンドポイントは、インデックスのサイズや同時要求の数をサポートするように、自動的にスケールアップされます。 ストレージ最適化エンドポイントは、インデックスが削除されると自動的にスケールダウンされます。 標準エンドポイントは自動的にスケールダウンされません。
ベクトル検索インデックス。 ベクター検索インデックスは Delta テーブルから作成され、リアルタイムの近似近隣検索を提供するように最適化されています。 検索の目的は、クエリと類似したドキュメントを特定することです。 ベクター検索インデックスは Unity カタログに表示され、管理されます。 手順については 、ベクター検索インデックスの作成 を参照してください。
さらに、Databricks で埋め込みを計算することを選択した場合、事前に構成された Foundation Model API エンドポイントを使用するか、モデル提供エンドポイントを作成して、任意の埋め込みモデルを提供できます。 手順については、トークンごとの支払い基盤モデル API またはエンドポイントを提供する基盤モデルの作成に関する記事を参照してください。
そのモデル サービング エンドポイントに対してクエリを実行するには、REST API または Python SDK を使用します。 クエリでは、Delta テーブル内の任意の列に基づいてフィルターを定義できます。 詳細については、クエリ、API リファレンス、または Python SDK リファレンスに対するフィルターの使用に関するページを参照してください。
要件
- Unity Catalog 対応ワークスペース。
- サーバーレス コンピューティングが有効になっている。 手順については、「 サーバーレス コンピューティングへの接続」を参照してください。
- 標準エンドポイントの場合、ソース テーブルで Change Data Feed が有効になっている必要があります。 「Azure Databricks で Delta Lake 変更データ フィードを使用する」を参照してください。
- ベクター検索インデックスを作成するには、インデックスが作成されるカタログ スキーマに対する CREATE TABLE 権限が必要です。
ベクター検索エンドポイントを作成および管理するためのアクセス許可は、アクセス制御リストを使用して構成されます。 ベクター検索エンドポイント ACL を参照してください。
データ保護と認証
Databricks では、データを保護するために次のセキュリティ制御が実装されています。
- Mosaic AI ベクトル検索に対するすべての顧客要求は、論理的に分離、認証、認可されます。
- Mosaic AI ベクトル検索では、すべての保存データ (AES-256) と転送中のデータ (TLS 1.2 以降) が暗号化されます。
Mosaic AI Vector Search では、サービス プリンシパルと個人用アクセス トークン (AT) の 2 つの認証モードがサポートされています。 運用アプリケーションの場合、Databricks では、個人アクセス トークンに対して最大 100 ミリ秒のクエリごとのパフォーマンスを実現できるサービス プリンシパルを使用することをお勧めします。
サービス プリンシパル トークン。 管理者はサービス プリンシパル トークンを生成し、それを SDK または API に渡すことができます。 「サービス プリンシパルの使用」を参照してください。 運用環境のユース ケースの場合、Databricks ではサービス プリンシパル トークンを使用することをお勧めしています。
# Pass in a service principal vsc = VectorSearchClient(workspace_url="...", service_principal_client_id="...", service_principal_client_secret="..." )
個人用アクセス トークン。 個人用アクセス トークンを使用して、モザイク AI ベクター検索で認証できます。 個人用アクセス認証トークンを参照してください。 ノートブック環境で SDK を使用する場合、SDK によって認証用の PAT トークンが自動的に生成されます。
# 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
予算ポリシーで使用状況を照会することもできます。 モザイク AI ベクター検索: 予算ポリシーを参照してください。
課金の使用状況テーブルの内容の詳細については、 課金対象の使用状況システム テーブルのリファレンスを参照してください。 追加のクエリは、次のノートブック例にあります。
ベクター検索システム テーブルクエリノートブック
リソースとデータ サイズの制限
次の表は、ベクター検索エンドポイントとインデックスのリソースとデータ サイズの制限をまとめたものです。
リソース | 細分性 | 極限 |
---|---|---|
ベクトル検索エンドポイント | ワークスペースごと | 100 |
埋め込み | エンドポイントあたり | 約320,000,000、埋め込み次元768で 1536次元の埋め込みにおいて、約1億6千万 埋め込み寸法が 3072 の場合、約 80,000,000 になります (ほぼ直線的に拡大縮小) |
埋め込みディメンション | インデックスごと | 4096 |
インデックス | エンドポイントあたり | 50 |
列 | インデックスごと | 50 |
列 | サポートされている型: Bytes、short、integer、long、float、double、boolean、string、timestamp、date | |
メタデータ フィールド | インデックスごと | 50 |
インデックス名 | インデックスごと | 128 文字 |
ベクター検索インデックスの作成と更新には、次の制限が適用されます。
リソース | 細分性 | 極限 |
---|---|---|
差分同期インデックスの行サイズ | インデックスごと | 100 KB |
差分同期インデックスの埋め込みソース列のサイズ | インデックスごと | 32764 バイト |
Direct Vector インデックスにおける一括アップサート要求のサイズ制限 | インデックスごと | 10 MB |
直接ベクター インデックスの一括削除要求サイズの制限 | インデックスごと | 10 MB |
クエリ API には、次の制限が適用されます。
リソース | 細分性 | 極限 |
---|---|---|
クエリ テキストの長さ | クエリごと | 32764 バイト |
返される結果の最大数 (近似最近隣検索) | クエリごと | 1万 |
返される結果の最大数 (ハイブリッド キーワード類似性検索) | クエリごと | 200 |
制限事項
- 列名
_id
は予約されています。 ソース テーブルに_id
という名前の列がある場合は、ベクター検索インデックスを作成する前に名前を変更します。 - 行レベルと列レベルのアクセス許可はサポートされていません。 ただし、フィルター API を使用して独自のアプリケーション レベルの ACL を実装できます。
ストレージ最適化エンドポイントの制限事項
このセクションの制限は、 ストレージ最適化エンドポイントにのみ適用されます。 ストレージ最適化エンドポイントは パブリック プレビュー段階です。
- 継続的同期モードはサポートされていません。
- 同期する列はサポートされていません。
- 埋め込みディメンションは 16 で割り切れる必要があります。
- 増分更新はサポートされていません。 すべての同期によって、ベクター検索インデックスが完全に再構築されます。
- 標準エンドポイントと比較して、同期に必要な時間の大幅なエンドツーエンドの短縮を予測する必要があります。 10 億個の埋め込みがあるデータセットは、8 時間以内に同期を完了する必要があります。 データセットが小さいほど、同期にかかる時間が短くなります。
- HIPAA、PCI、FedRAMP 準拠のワークスペースはサポートされていません。
- カスタマー マネージド キー (CMK) はサポートされていません。
- ストレージ最適化エンドポイントは、最大 10 億個の 768 次元のベクター埋め込みをサポートします。 大規模なユース ケースがある場合は、アカウント チームにお問い合わせください。