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

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 では、次の機能がサポートされています。

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 リファレンスベクトル検索エンドポイントのクエリを参照してください

類似性検索の計算

類似性検索の計算では、次の式を使用します。

1の逆数+距離の2乗

ここで、 distはクエリーqとインデックスエントリx間のユークリッド距離です。

ユークリッド距離、差の二乗和の平方根

キーワード検索アルゴリズム

関連性スコアは、 Okapi BM25 を使用して計算されます。 ソーステキストの埋め込み列や、テキストまたは文字列形式のメタデータ列など、すべてのテキスト列または文字列列が検索されます。 トークン化機能は、単語の境界で分割し、句読点を削除し、すべてのテキストを小文字に変換します。

類似検索とキーワード検索の組み合わせ

類似検索とキーワード検索の結果は、Reciprocal Rank Fusion(RRF)機能を使用して結合されます。

RRFは、スコアを使用して各メソッドからの各ドキュメントを再スコアリングします。

RRF方程式

上の式では、ランクは0から始まり、各ドキュメントのスコアを合計して、最もスコアの高いドキュメントを返します。

rrf_param 上位ランクのドキュメントと下位ランクのドキュメントの相対的な重要度を制御します。文献に基づいて、 rrf_paramは60に設定されています。

スコアは、以下の式を用いて最高スコアを1、最低スコアを0とするように正規化されます:

正規化

ベクトル埋め込みを提供するためのオプション

Databricksでベクトル検索インデックスを作成するには、まずベクトル埋め込みの提供方法を決定する必要があります。Databricks では、次の 3 つのオプションがサポートされています。

  • オプション1: Databricksによって計算されるエンベディングを用いたDelta同期インデックス テキスト形式のデータを含むソースDelta テーブルを提供します。Databricks は、指定したモデルを使用してエンベディングを計算し、必要に応じて埋め込みを Unity Catalog のテーブルに保存します。 Delta テーブルが更新されても、インデックスは Delta テーブルと同期されたままになります。

    次の図は、このプロセスを示しています。

    1. クエリーの埋め込みを計算します。クエリーにはメタデータフィルターを含めることができます。
    2. 最も関連性の高い文書を特定するために類似検索を実行します。
    3. 最も関連性の高いドキュメントを返し、クエリーに追加します。

    ベクトル検索インデックス、Databricks が埋め込みを計算

  • オプション 2: 自己管理型のエンベディングを使用した Delta同期インデックス 事前に計算されたエンベディングを含むソース Delta テーブルを指定します。 Delta テーブルが更新されても、インデックスは Delta テーブルと同期されたままになります。

    次の図は、このプロセスを示しています。

    1. クエリーはエンベディングで構成され、メタデータフィルターを含めることができます。
    2. 類似性検索を実行して、最も関連性の高いドキュメントを特定します。最も関連性の高いドキュメントを返し、クエリーに追加します。

    ベクトル検索インデックス、事前計算型埋め込み

  • オプション 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 日以降に作成されたエンドポイントでサポートされています。

使用状況とコストの監視

課金利用システムテーブルを使用すると、ベクトル検索インデックスとエンドポイントに関連する使用量とコストを監視することができます。クエリーの例を次に示します。

SQL
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: 予算ポリシーをご覧ください。

請求利用テーブルの内容については、 課金利用 システムテーブルリファレンスを参照してください。 追加のクエリは、次のノートブックの例にあります。

ベクトル検索システムテーブルクエリノートブック

Open notebook in new tab

リソースとデータのサイズ制限

次の表は、ベクトル検索のエンドポイントとインデックスに対するリソースとデータサイズの上限を示しています。

リソース

粒度

上限

ベクトル検索エンドポイント

ワークスペースごと

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を独自に実装することは可能です。

追加のリソース