目次 › 第3章 › 3-3

第3章 アプリケーション開発 / 想定学習時間:30〜40分 / 最終確認:2026年8月

3-3. Databricks AI Search(旧 Vector Search)による検索パイプライン構築

1. AI Search の構成要素:エンドポイントとインデックス

Databricks AI Search(旧 Vector Search)は、Databricks が提供するマネージドなベクトル検索サービスです。かつては「Vector Search」という名称でしたが、現在は「AI Search」に改名されており、エンドポイント+インデックスという構成や主要機能はそのまま引き継がれています(本書では以降「AI Search」と表記します)。3-2 で埋め込んだチャンクを格納し、クエリベクトルとの類似検索を高速に実行します。構成要素は2つに分かれており、この区別が試験でも問われます。

インデックスが Unity Catalog 配下にあることで、テーブルと同じように権限管理・監査ができます(ガバナンスは第6章で詳述)。

2. インデックスの2タイプ:Delta Sync と Direct Vector Access

インデックスへのデータの入れ方には2方式あります。

2-1. Delta Sync Index:Delta テーブルから自動同期

ソースとなる Delta テーブルを指定すると、その内容がインデックスへ自動的に同期される方式です。ソーステーブルには Change Data Feed(CDF)の有効化が必要で、テーブルへの追加・更新・削除が差分としてインデックスに反映されます。さらに、埋め込みの計算を誰が行うかで2通りに分かれます。

マネージド埋め込みは、3-2 で学んだ「インデックスとクエリで同じモデルを使う」原則を仕組みとして保証してくれる点が大きな利点です。

2-2. Direct Vector Access Index:API で直接書き込む

ソーステーブルを持たず、API 経由でベクトルとメタデータを直接 upsert / delete する方式です。自動同期はなく、データの更新管理はすべてアプリケーション側の責任になります。既存のパイプラインで埋め込みを管理していて、書き込みタイミングを完全に制御したい場合に使います。

2-3. 同期モード:Triggered / Continuous

Delta Sync Index の同期タイミングは2モードから選びます。

• Triggered:手動またはパイプラインからの起動時に同期する。更新頻度が低いデータ向けで、計算コストを抑えられる
• Continuous:ソースの変更を継続的に取り込み、低遅延で反映する。常時稼働の計算資源を使うためコストは高い。鮮度要件が厳しい場合に選ぶ

3. インデックス作成のコード例

# 新SDK:databricks-ai-search パッケージ(import は databricks.ai_search 配下)
from databricks.ai_search.client import AISearchClient
# 旧: from databricks.vector_search.client import VectorSearchClient
#    (旧パッケージ databricks-vectorsearch は非推奨のシムとして残り、
#     DeprecationWarning を出しつつ同じ機能を提供する)

client = AISearchClient()

index = client.create_delta_sync_index(
    endpoint_name="my_vs_endpoint",
    index_name="main.rag.docs_index",           # UC配下の3階層名
    source_table_name="main.rag.docs_chunks",   # CDF有効のDeltaテーブル
    pipeline_type="TRIGGERED",                  # または CONTINUOUS
    primary_key="chunk_id",
    embedding_source_column="chunk_text",       # テキスト列
    embedding_model_endpoint_name="databricks-gte-large-en",
)

4. 検索の実行:similarity_search

作成したインデックスに対しては、similarity_search で検索します。

results = index.similarity_search(
    query_text="返品の手続きを教えて",       # マネージド埋め込みならテキストでOK
    columns=["chunk_id", "chunk_text", "source"],  # 返してほしい列
    num_results=5,                                 # 上位k件
    filters={"category": "customer_support"},      # メタデータで絞り込み
)

• query_text — マネージド埋め込みでは質問テキストをそのまま渡せる(埋め込みは自動計算)。自己管理埋め込みでは自分でクエリをベクトル化して query_vector で渡す
• columns — 結果として返すメタデータ列。3-4 で出典表示に使うため、ソース名などを含めておく
• num_results — 取得する上位 k 件。top-k の調整は 3-4・3-5 で扱う
• filters — メタデータによる事前絞り込み。2-6 で設計したメタデータがここで効く(例:部署・年度・言語で絞る)

また、ベクトル類似検索にキーワード一致の要素を組み合わせるハイブリッド検索もサポートされています。製品型番や固有名詞のように「字面の一致が重要」なクエリでは、純粋なベクトル検索よりもハイブリッド検索が有効な場面があります。

ここまでの部品を組み合わせると、RAG の検索パイプラインは次の流れになります。

5. LangChain から使う:retriever としての接続

3-1 の RAG チェーンに AI Search を組み込むには、databricks-langchain の DatabricksVectorSearch を使います。

from databricks_langchain import DatabricksVectorSearch

vector_store = DatabricksVectorSearch(
    index_name="main.rag.docs_index",
    columns=["chunk_text", "source"],
)
retriever = vector_store.as_retriever(search_kwargs={"k": 5})

# 3-1 で学んだ RAG チェーンの骨格にそのまま差し込める
# rag_chain = {"context": retriever, "question": RunnablePassthrough()} | prompt | llm | parser

as_retriever() で LangChain 標準の retriever インターフェースになるため、チェーンの他の部分を変えずに検索段だけを AI Search に差し替えられます。検索結果をどうプロンプトに組み込むかは、次の 3-4 のテーマです。

練習問題