ベクター検索検索品質ガイド

このガイドでは、モザイク AI ベクター検索を使用して、リアルタイムの RAG、検索、および照合アプリケーションの取得品質を向上させる体系的なアプローチを提供します。 推奨事項は、影響が最も大きいか、最も低い作業から、影響が最も少ない、または最も高い作業に順序付けられています。

前提条件: 評価フレームワークを確立する

取得品質を最適化する前に、再現可能な評価システムが 必要 です。

待機時間の要件を定義する

ユース ケースに基づいて明確な待機時間のターゲットを確立します。

• RAG エージェント: Time to First Token (TTFT) 目標 (例: <2 秒)
• 検索バー: 結果を表示するエンドツーエンドの待機時間 (例: < 100 ミリ秒)

最適化を試みる場合は、これらの要件を満たす必要があります。

自動評価を設定する

次の 1 つ以上の方法を使用します。

• 既存のゴールデン データセット: ラベル付きのクエリと回答のペアを使用します。
• 合成評価セット: Databricks 合成データ生成 を使用して、ドキュメントからテスト ケースを自動生成します。
• グラウンド・トゥルース・フリー評価: Databricks Agent Evaluation のジャッジを使用して、ラベルなしで品質を評価します。

重要なのは、変更 を測定するための 自動化された方法があることです。完璧なデータは必要ありません。 絶対スコアではなく、さまざまな戦略をテストする際の 相対的な改善 に重点を置きます。 小規模な合成データセットでも、再ランク付けによって品質が 15% 向上するか、ハイブリッド検索が特定のユース ケースに役立つかどうかを確認できます。

品質メトリックを選択する

ユース ケースに基づいて品質メトリックを選択します。

リコールが最も重要な場合 (すべての関連情報が必要):

• RAG エージェント: キー コンテキストが見つからないと、正しくない回答や誤認が生じる可能性があります。
• 医薬品の臨床試験マッチング:対象となる患者または関連する研究を見逃すことはできません。
• 財務コンプライアンス検索: 関連するすべての規制、リスク要因、または優先順位が必要です。
• 製造の根本原因分析: 関連するすべてのインシデントと故障パターンを表示する必要があります。
• 追跡するメトリック: Recall@k (たとえば、recall@10、recall@50)。

精度が最も重要な場合 (最も関連性の高い結果のみが必要):

• エンティティの解決/あいまい一致: システム間での顧客レコード、サプライヤー名、または製品 SKU の照合。
• 金融サービス重複除去: 信頼度の高い重複トランザクションまたはアカウントを識別します。
• サプライ チェーン パーツの一致: カタログ全体で正確または互換性のあるコンポーネントを検索します。
• テクニカル サポートのナレッジ ベース: エンジニアには、上位の結果で正確なソリューションが必要です。
• 追跡するメトリック: Precision@k (precision@3、precision@10など)。

バランスの取れたユース ケース (適切な再現率と精度の両方が必要):

• M&A デュー デリジェンス: リスク (再現率) を見逃すことはできませんが、最初に関連するドキュメント (精度) が必要です。
• 特許先行技術調査: 最も関連性の高い特許を優先し、包括的に取り扱う。
• 顧客 360 照合: 複数のシステム間で顧客データを統合します。

手順 1: ハイブリッド検索を有効にする

キーワードの正確性とセマンティックな理解を組み合わせます。

使用するタイミング:

• ユーザーは特定の用語 (製品コード、技術用語) で検索します。
• 特定のクエリに完全に一致する必要があります。
• セマンティック検索で明確なキーワードの一致が見逃された場合にフォールバックが必要です。

メトリックへの影響:

• セマンティック一致とキーワード一致の両方を捉えることで、再現率 を向上させます。
• 特定の用語を持つクエリの 精度 が向上します。

実装: モザイク AI ベクター検索での 1 行の変更。

# Enable hybrid search
results = index.similarity_search(
    query_text="error code E404",
    query_type="HYBRID"  # Combines vector and keyword search
)

詳細については、「 ベクター検索インデックスのクエリ」を参照してください。

手順 2: メタデータ フィルター処理を実装する

これが、取得品質を向上させるための最も重要なアプローチです。

フィルター処理により、検索領域が大幅に削減され、精度と再現率の両方が向上します。

メトリックへの影響:

• 無関係な結果を排除することで 、精度 が大幅に向上します。
• フィルター処理されたサブセット内の 再現率 が向上します。
• 検索領域を90%以上削減できます。

例示

• 技術ドキュメント: 製品のバージョン、コンポーネント、またはモジュールでフィルター処理します。
• 車のマニュアル: メーカー、モデル、年でフィルタリング。
• カスタマー サポート: 製品ライン、地域、問題カテゴリでフィルター処理します。

Implementation

# Vector Search with metadata filtering
results = index.similarity_search(
    query_text="brake system maintenance",
    filters='make = "Toyota" AND model = "Camry" AND year = 2023',
    num_results=10
)

動的フィルターの選択

プログラムによるアプローチ:

# Parse query for filter criteria
def extract_filters(user_query):
    filter_parts = []
    if "Toyota" in user_query:
        filter_parts.append('make = "Toyota"')
    if "2023" in user_query:
        filter_parts.append('year = 2023')
    return " AND ".join(filter_parts) if filter_parts else None

Databricks を使用したエージェント ベースのフィルター処理:

from databricks_ai_bridge.agents.tools.vector_search import VectorSearchTool

# Create the vector search tool
vector_search_tool = VectorSearchTool(
    index_name="catalog.schema.car_manuals_index",
    # Optional: specify columns to return
    columns=["content", "make", "model", "year", "chunk_id"],
    # Optional: set number of results
    num_results=10,
    # Optional: add additional parameters as needed
    additional_parameters={
        "query_type": "HYBRID"  # Enable hybrid search
    }
)

# The tool automatically handles filter generation based on the agent's understanding
# Agent analyzes "brake issues in my 2023 Toyota Camry" and generates appropriate filters

# For LangChain agents:
from langchain.agents import create_react_agent

agent = create_react_agent(
    tools=[vector_search_tool],
    llm=your_llm,
    prompt=your_prompt
)

エージェントは自動的に次の手順を実行します。

1. クエリから関連エンティティを抽出します。
2. 適切な SQL に似たフィルター文字列を生成します。
3. セマンティック理解と正確なフィルター処理の両方を使用して検索を実行します。

影響:関連性を向上させながら、検索領域を 90%+ 削減できます。

手順 3: 再ランク付けを追加する

1 行の変更で約15%の品質向上。

Databricks には、RAG エージェントに最適な 組み込みのリランカー が用意されています。

メトリックへの影響:

• より少ない候補で高いリコールを達成することにより、精度を向上します。
• ハイブリッド検索やフィルター処理などの手法と組み合わせると最適です。

Implementation

# Python SDK
results = index.similarity_search(
    query_text="How to create a Vector Search index",
    num_results=10,
    columns=["id", "text", "parent_doc_summary"],
    reranker={
        "model": "databricks_reranker",
        "parameters": {
            "columns_to_rerank": ["text", "parent_doc_summary"]
        }
    }
)

詳細については、「クエリ結果のリランキング」を参照してください。

いつ使用するか

次の用途に最適です。

• RAG エージェント（レイテンシーは LLM の生成によって左右されます）。
• 品質優先アプリケーション。
• 初期設定で低〜中程度の QPS (最大 5 QPS)。

組み込みのリランカーは適していません：。

• 高い QPS アプリケーション (追加のスケーリングなしで >5 QPS)。
• < 100 ミリ秒の待機時間を必要とするリアルタイム検索バー。
• 1.5 秒の再ランク付け時間が許容できないアプリケーション。

パフォーマンス: 一般的なワークロードでは約1.5秒で50件の結果を再ランク付けします。 短いチャンクでは250ミリ秒ほどの速さで処理可能です。

低待機時間/RAG 以外のユース ケースの場合

Reranking は、検索バーや高 QPS アプリケーションの品質を大幅に向上させることができます。必要なのは、より高速な再ランカーだけです。 100 ミリ秒未満の再ランク付けのために cross-encoder/ms-marco-TinyBERT-L-2-v2として軽量の再ランク付けモデル ( など) をデプロイすることを検討してください。

手順 4: データ準備を改善する

このセクションでは、チャンク、解析、セマンティック コンテキストの追加、データのクリーニングなど、データの準備を改善するために使用できるいくつかの手法について説明します。

チャンク戦略

チャンク サイズの最適化は、引き続き調査のアクティブな領域です。 DeepMind (LIMIT) の最近の作業では、埋め込みでは長いコンテキストで基本情報をキャプチャできない可能性が示されており、これは微妙な決定になります。

実験の開始点:

# Common configurations to test
small_chunks = 256   # Better for precise fact retrieval
medium_chunks = 512  # Balanced approach
large_chunks = 1024  # More context per chunk

考慮すべき主なトレードオフ:

• 小さいチャンク: 特定の情報のローカライズが向上しますが、コンテキストが失われる可能性があります。
• 大きなチャンク: より多くのコンテキストが保持されますが、関連情報を特定するのが困難です。
• コンテキストの制限: 複数のチャンクを取得する場合は、LLM コンテキスト ウィンドウ内に収まる必要があります。

より影響の大きい最適化: チャンク サイズを過剰に最適化する代わりに、次の点に重点を置きます。

1. メタデータの情報抽出: エンティティ、トピック、カテゴリを抽出して、正確なフィルター処理を有効にします。
2. 高品質の解析: クリーンで構造化されたテキストに ai_parse_document を使用します。
3. セマンティック メタデータ: ドキュメントの概要とセクション ヘッダーをチャンクに追加します。

また、次の高度なアプローチも検討してください。 これらの手法にはより多くの労力が必要ですが、大きな影響を与える可能性があります。

セマンティック チャンク: 固定サイズではなく類似性によって文をグループ化します。

• 埋め込みを使用して、自然なセマンティック境界を見つけます。
• 関連するアイデアを一緒に保持します。
• コンテキストの保持の向上。
• RAG アプリケーションのチャンク戦略の究極のガイドを参照してください。

親子チャンク処理 (小から大への取得)

# Record child and parent chunks in your source table
for parent_chunk in create_chunks(doc, size=2048):  # Large for context
    for child_chunk in create_chunks(parent_chunk, size=512):  # Small for precision
        source_table.append({"text": child_chunk, "parent_text": parent_chunk})

# Search children, return parents
results = index.similarity_search(
    query_text="Is attention all you need?",
    num_results=10,
    columns=["text", "parent_text"]
)

LangChain の親ドキュメント取得に関するドキュメントを参照してください。

ドキュメント解析

PDF と複雑なドキュメントの場合、Databricks では、高品質の解析 にai_parse_document を使用することをお勧めします。 不適切な解析 (テーブルの不足、書式設定の破損) は、取得の品質に直接影響します。

セマンティック メタデータを使用してエンリッチする

セマンティック コンテキストを追加して取得を改善します。

これが機能する理由:

• モデルを埋め込むための追加のセマンティック シグナルを提供します。
• リランカーにスコアリングのためのより多くのコンテキストを提供します。
• ドキュメント レベルの概念を参照するクエリに役立ちます。

オプション 1: メタデータをチャンクに含める

# Prepend document summary to each chunk
chunk_with_context = f"""
Document: {doc_title}
Summary: {doc_summary}
Section: {section_name}
{chunk_content}
"""

オプション 2: 個別のメタデータ列として格納する

# Store semantic metadata for reranker to use
metadata = {
    "doc_summary": "Technical manual for brake system maintenance",
    "section": "Emergency brake adjustment procedures",
    "keywords": ["brake", "safety", "adjustment"]
}

データのクリーニング

• 定型句 (ヘッダー、フッター、ページ番号) を削除します。
• ドキュメント構造 (見出し、リスト、テーブル) を保持します。
• チャンク時にセマンティック境界を維持する。

手順 5: クエリの最適化

クエリの拡張

複数のクエリ バリエーションを生成して、再現率を向上させます。 LangChain ガイドを参照してください。

影響: 異なる用語を持つドキュメントを見つけることで再現率が向上します。

# Use LLM to expand query with synonyms and related terms
def expand_query(user_query):
    prompt = f"""Generate 3 variations of this search query including synonyms:
    Query: {user_query}
    Return only the variations, one per line."""

    variations = llm.generate(prompt).split('\n')

    # Search with original + variations
    all_results = []
    for query in [user_query] + variations:
        results = index.similarity_search(query_text=query, num_results=10)
        all_results.extend(results)

    # Deduplicate and return
    return deduplicate_results(all_results)

例: "自動車メンテナンス" では、"自動車修理"、"車両サービス"、"自動メンテナンス" も検索されます

その他の手法については、以下を参照してください。

• 高度なクエリ拡張手法
• マルチクエリ取得機能の実装

クエリの再フォーマット

複雑なクエリの場合は、分割または言い換えしてください。 OpenAI RAG 戦略を参照してください。

• マルチホップの質問→シーケンシャル検索
• 複数の特定の検索→あいまいなクエリ
• 分解の手法を参照してください

手順 6: 高度なプロンプト手法

プロンプトの最適化

MIPROv2 や GEPA ( DSPy で使用可能) などの自動プロンプト最適化手法を使用して、データの準備、クエリの書き換え、または取得システム内の任意の場所で使用されるプロンプトを改善します。 ナレッジ アシスタント と スーパーバイザ エージェント には、低コストで大規模なパフォーマンス向上のために GEPA が組み込まれています。 自動化されたプロンプトの最適化により、最新のエンタープライズ エージェントを 90 倍安く構築する方法を参照してください。

詳細については、「 GEPA を使用した反射プロンプトの進化」を参照してください。

手順 7: 順応的検索戦略

React エージェント パターン

取得をインテリジェントに調整できるエージェントを構築します。

• エージェントが取得の必要性について判断する。
• 最初の結果に基づいてクエリを再フォーマットできます。
• 取得を他のツール (電卓、API など) と組み合わせます。
• 変更されたクエリを使用して、失敗した取得を再試行します。
• Databricks Mosaic AI Agent Framework を使用して実装します。

エージェンティックな検索の例

# Agent decides when to search and what filters to apply
# Based on conversation context and user intent
agent = create_agent(
    tools=[vector_search_tool, calculator, web_search],
    instructions="Retrieve relevant docs only when needed, apply appropriate filters"
)

手順 8: 埋め込みモデルを微調整する

まず、埋め込み問題があるかどうかを診断する

クイック テスト: Databricks で GTE と OpenAI 埋め込みを比較します。

# Test with both embedding models
# Databricks native: gte-large-en-v1.5
gte_results = gte_index.similarity_search(query)

# OpenAI: text-embedding-3-large (3072 dims)
openai_results = openai_index.similarity_search(query)

# If OpenAI text-embedding-3-large significantly outperforms GTE:
# - Fine-tuning a smaller model could match or exceed OpenAI quality
# - You have an embedding model problem, not a data problem

解釈:

• text-embedding-3-largeのパフォーマンスがgte-large-enよりもはるかに優れている場合は、微調整を検討してください。 小さいモデルでも同様の品質を実現できます。
• text-embedding-3-largeがgte-large-enとほぼ同じパフォーマンスを発揮する場合、問題は埋め込みモデルではありません。 その他の最適化に重点を置きます。

微調整するタイミング