AI 検索検索品質ガイド
AI Searchの検索品質を向上させるために、影響度が最も高く労力が最も少ないものから、影響度が最も低く労力が最も高いものまで、これらの手法を順番に実行してください。これらの手法は、リアルタイムのRAG、検索、およびマッチングアプリケーションに役立ちます。
前提条件: 評価フレームワークの確立
検索品質を最適化する前に、再現性のある評価システムを持つ必要があります。
評価が実施されていない場合は、ここで中断し、まず設定してください。測定なしに最適化を行うことは、単なる推測に過ぎません。
レイテンシー要件を定義する
ユースケースに基づいて明確なレイテンシ目標を設定します:
- RAGエージェント:初回トークンまでの時間(TTFT)の目標(たとえば、<2秒)
- 検索バー:結果表示までのエンドツーエンドのレイテンシー(たとえば、100ミリ秒未満)
どのような最適化もこれらの要件を満たす必要があります。
自動評価を設定する
次のいずれかの方法を使用してください:
- 既存のゴールデンデータセット :ラベル付きのクエリと回答のペアを使用してください。
- 合成評価セット : Databricks の合成データ生成を使用して、ドキュメントからテストケースを自動生成します。
- グラウンドトゥルースフリー評価 : Databricks エージェント評価ジャッジを使用して、ラベルなしで品質を評価します。
重要なのは、変更を測定する何らかの自動化された方法があることです。ただし、完璧なデータは必要ありません。さまざまな戦略をテストする際は、絶対的なスコアではなく、相対的な改善に注目してください。小規模な合成データセットでも、リランキングによって品質が15%向上するか、またはハイブリッド検索が特定のユースケースに役立つかどうかを判断できます。
品質メトリクスを選択してください
ユースケースに基づいて品質メトリクスを選択してください:
recall が最も重要な場合(すべての関連情報が必要な場合):
- RAG エージェント :重要なコンテキストが不足していると、不正確な回答やハルシネーションにつながります。
- 製薬臨床試験マッチング :対象患者または関連研究を見逃すことはできません。
- 金融コンプライアンス検索 :すべての関連する規制、リスク要因、または判例が必要です。
- 製造根本原因分析 :関連するすべてのインシデントと失敗パターンを特定する必要があります。
- 追跡するメトリクス : Recall@k(例えば、recall@10、recall@50)。
精度が最も重要である場合 (最も関連性の高い結果のみが必要な場合):
- エンティティ解決/ファジーマッチング :システム全体で顧客レコード、サプライヤー名、または製品SKUを照合します。
- 金融サービス重複排除 :重複する取引やアカウントを高い確信度で特定します。
- サプライチェーン部品照合 :カタログ全体で正確な、または互換性のある部品を見つけること
- テクニカルサポートのナレッジベース :エンジニアは、上位の検索結果に最適なソリューションを必要とします。
- 追跡するメトリクス :Precision@k(例えば、precision@3、precision@10)。
バランスの取れたユースケース(良好な精度と再現率が両方必要)
- M&Aデューデリジェンス :リスクを見逃すことはできません (リコール) が、まず関連文書が必要です (精度)。
- 特許先行技術調査 :最も関連性の高い特許を優先した包括的な網羅性。
- Customer 360 マッチング :複数のシステムにわたる顧客データの統合。
ステップ1:ハイブリッド検索を有効にする
キーワードの精度とセマンティックな理解を組み合わせます。
使用する場合 :
- ユーザーは特定の用語(製品コード、技術用語)で検索します。
- 特定のクエリには完全一致が必要です。
- セマンティック検索で明白なキーワードの一致を見逃した場合に、フォールバックが必要です。
メトリクスへのインパクト :
- セマンティックマッチとキーワードマッチの両方を捉えることで、**再現率**が向上します。
- 特定の用語を含むクエリの精度を向上させます。
実装 : AI検索での1行変更。
# Enable hybrid search
results = index.similarity_search(
query_text="error code E404",
query_type="HYBRID" # Combines vector and keyword search
)
詳細については、「AI検索インデックスのクエリ」を参照してください。
ステップ 2: メタデータフィルタリングを実装する
これが検索品質における最大の要素となります。
フィルタリングは検索スペースを劇的に削減し、精度と再現率の両方を改善します。
メトリクスへのインパクト :
- 不要な結果を排除することで、精度を大幅に向上させます。
- フィルターされたサブセット内での**再現率**を改善します。
- 検索スペースを90%以上削減できます。
例
- 技術ドキュメント :製品バージョン、コンポーネント、またはモジュールで絞り込む。
- カーマニュアル : メーカー、モデル、年式で絞り込む。
- 顧客サポート :製品ライン、地域、問題カテゴリ。
実装
# AI 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 AI 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
)
エージェントは自動的に:
- クエリーから関連するエンティティを抽出します。
- 適切なSQLライクなフィルター文字列を生成します。
- セマンティックな理解と正確なフィルタリングの両方を用いて検索を実行します。
影響 :関連性を向上させながら、検索スペースを90%以上削減できます。
ステップ3:リランキングを追加する
一行の変更で約15%の品質改善が見込めます。
Databricks は 組み込みの reranker を提供しており、RAG エージェントに最適です。
メトリクスへのインパクト :
- 少ない候補で高い再現率を実現し、精度を向上させます。
- ハイブリッド検索やフィルタリングなどの手法と組み合わせることで、最も効果的です。
実装
# Python SDK
results = index.similarity_search(
query_text="How to create an AI 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秒のリランキング時間が許容できないアプリケーション。
パフォーマンス : 一般的なワークロードでは、50件の結果を約1.5秒で再ランク付けします。短いチャンクであれば、約250ミリ秒もの速さで実現します。
低レイテンシ/非RAG ユースケース向け
リランキングは、検索バーや高-QPSアプリケーションでも大幅な品質向上をもたらすことができます。必要なのは、より高速なリランカーだけです。100ミリ秒未満の再ランキングのために、軽量な再ランキングモデル(例:cross-encoder/ms-marco-TinyBERT-L-2-v2)を、Databricks Model Serving でカスタムモデルとしてデプロイすることをご検討ください。
ステップ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 のコンテキストウィンドウ内に収まる必要があります。
より効果的な最適化 :チャンクサイズの過度な最適化ではなく、以下に注力します。
- 「メタデータに関する情報抽出」:正確な絞り込みを可能にするため、エンティティ、トピック、カテゴリを抽出します。
- 高品質な解析 :クリーンで構造化されたテキストには、ai_parse_documentを使用します。
- セマンティックメタデータ:ドキュメントの概要とセクションヘッダーをチャンクに追加します。
さらに、以下の高度なアプローチも検討してください。これらの手法はより多くの手間がかかりますが、より大きな影響を与える可能性があります:
セマンティックチャンキング :固定サイズではなく、類似性に基づいて文をグループ化します。
- エンベディングを使用して自然な意味的な境界を見つけます。
- 関連するアイデアをまとめて保持します。
- コンテキスト保持の向上。
- 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"]
}
このアプローチでは、メタデータを活用するためにダウンストリーム処理が必要です。
- セマンティックメタデータの場合: これらの列を考慮するには、
columns_to_rerankパラメーターで再ランキングを使用します。 - キーワードのみのメタデータについては、これらのフィールドと一致させるには、ハイブリッド検索(全文モード)を使用してください。
データクリーニング
- 定型要素(ヘッダー、フッター、ページ番号)を削除
- 文書構造 (見出し、リスト、テーブル) を保持します。
- チャンク化する際は、意味的境界を維持してください。
ステップ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: 適応型取得戦略
リアクト エージェント パターン
検索をインテリジェントに連携できるエージェントを構築します:
- エージェントは取得が必要かどうかを判断します。
- 最初の結果に基づいてクエリを再構成可能です。
- 検索を他のツール(計算ツール、APIs、など)と組み合わせます。
- 変更されたクエリで失敗した取得が再試行されます。
- カスタムエージェントを使用して実装します。
エージェントによる検索の例
# 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とほぼ同じように機能する場合、問題は埋め込みモデルではありません。他の最適化に焦点を合わせてください。
ファインチューニングを行うタイミング
ファインチューニングは最終手段と考えるべきであり、以下の基準が満たされた場合にのみ検討すべきです。
- ステップ1~7をお試しになりました。
- OpenAIはテストでGTEを著しく上回っています。
- ドメイン固有の語彙やユースケースがあります。
ラベル付きトレーニングデータは必要ありません。Databricks の埋め込みファインチューニングブログで示されているように、合成データ生成を使用できます。