人気検索検索品質ガイド
このガイドでは、Mosaic AI Vector Search を使用して、リアルタイム RAG、検索、マッチング アプリケーションの検索品質を向上させる体系的なアプローチについて説明します。推奨事項は、影響が最も大きく労力が最も少ないものから、影響が最も小さく労力が最も多いものの順に並べられています。
前提条件: 評価フレームワークを確立する
検索品質を最適化する前に、再現可能な評価システムが 必要です 。
評価がまだ実施されていない場合は、ここで停止してまず評価を設定してください。測定なしの最適化は推測に過ぎません。
レイテンシ要件を定義する
ユースケースに基づいて明確なレイテンシ目標を設定します。
- RAG エージェント : 最初のトークンまでの時間 (TTFT) の目標 (例: <2 秒)
- 検索バー : 結果を表示するまでのエンドツーエンドの遅延 (例: <100 ミリ秒)
試みる最適化はすべてこれらの要件を満たす必要があります。
自動評価を設定する
次の 1 つ以上のアプローチを使用します。
- 既存のゴールデン データセット : ラベル付けされたクエリと回答のペアを使用します。
- 合成評価セット : Databricks 合成データ生成を使用して、ドキュメントからテスト ケースを自動生成します。
- グラウンドトゥルースフリー評価 : Databricks エージェント評価審査員を使用して、ラベルなしで品質を評価します。
重要なのは、変化を測定するための自動化された 方法 を持つことです。完璧なデータは必要ありません。さまざまな戦略をテストするときは、絶対的なスコアではなく、 相対的な改善 に焦点を当てます。小さな合成データセットでも、再ランク付けによって品質が 15% 向上するかどうかや、ハイブリッド検索が特定のユースケースに役立つかどうかがわかります。
高品質のメトリクスを選択してください
ユースケースに基づいて高品質のメトリクスを選択してください。
リコールが最も重要である場合 (関連するすべての情報が必要):
- RAG エージェント : 重要なコンテキストが欠落していると、誤った回答や幻覚が発生します。
- 製薬臨床試験のマッチング : 適格な患者または関連する研究を見逃すことはできません。
- 財務コンプライアンスの検索 : 関連するすべての規制、リスク要因、または前例が必要です。
- 製造の根本原因分析 : 関連するすべてのインシデントと障害パターンを明らかにする必要があります。
- 追跡するメトリクス : Recall@k (たとえば、recall@10、recall@50)。
精度が最も重要である場合 (最も関連性の高い結果のみが必要な場合):
- エンティティ解決/あいまい一致 : システム間で顧客レコード、サプライヤー名、または製品 SKU を一致させます。
- 金融サービスの重複排除 : 重複する取引またはアカウントを高い信頼性で識別します。
- サプライ チェーン部品のマッチング : カタログ全体で正確なコンポーネントまたは互換性のあるコンポーネントを見つけます。
- テクニカル サポート ナレッジ ベース : エンジニアは、上位の結果で正確なソリューションを必要としています。
- 追跡するメトリクス : Precision@k (たとえば、precision@3、precision@10)。
バランスの取れたユースケース (優れた再現率と精度の両方が必要):
- M&A デューデリジェンス : リスクを見逃すことはできません (リコール) が、まずは関連するドキュメントが必要です (精度)。
- 特許先行技術検索 : 最も関連性の高い特許を優先して包括的にカバーします。
- 顧客 360 マッチング : 複数のシステムにわたる顧客データを統合します。
ステップ 1: ハイブリッド検索を有効にする
キーワードの精度と意味の理解を組み合わせます。
使用する場合 :
- ユーザーは特定の用語(製品コード、技術用語)で検索します。
- 特定のクエリに対して完全一致が必要です。
- セマンティック検索で明らかなキーワードの一致が見つからない場合にフォールバックが必要です。
メトリクスへの影響 :
- 意味的一致とキーワード一致の両方をキャッチすることで リコールを 向上します。
- 特定の用語を含むクエリの 精度 が向上します。
実装 : Mosaic AI Vector Search の 1 行の変更。
# Enable hybrid search
results = index.similarity_search(
query_text="error code E404",
query_type="HYBRID" # Combines vector and keyword search
)
詳細については、 「一斉検索インデックスのクエリ」を参照してください。
ステップ 2: メタデータ フィルタリングを実装する
これは検索品質を左右する最大の要素です。
フィルタリングにより、検索スペースが大幅に削減され、精度と再現性の両方が向上します。
メトリクスへの影響 :
- 無関係な結果を除外することで 精度 が大幅に向上します。
- フィルタリングされたサブセット内の 再現率 が向上します。
- 検索スペースを 90% 以上削減できます。
例
- 技術ドキュメント : 製品バージョン、コンポーネント、またはモジュール別にフィルタリングします。
- 車のマニュアル : メーカー、モデル、年式でフィルタリングします。
- カスタマーサポート : 製品ライン、地域、問題カテゴリでフィルタリングします。
実装
# 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
)
エージェントは自動的に次の操作を実行します。
- クエリから関連するエンティティを抽出します。
- 適切な SQL のようなフィルター文字列を生成します。
- 意味理解と正確なフィルタリングの両方を使用して検索を実行します。
影響 : 関連性を向上させながら、検索スペースを 90% 以上削減できます。
ステップ 3: 再ランキングを追加する
1 行の変更で品質が約 15% 向上します。
Databricks は、RAG エージェントに最適な組み込みの再ランク付け機能を提供します。
メトリクスへの影響 :
- より少ない候補で高い再現率を達成することで精度を向上させます。
- ハイブリッド検索やフィルタリングなどの手法と組み合わせると最適に機能します。
実装
# 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ユースケース向け
再ランク付けにより、検索バーや高 QPS アプリケーションの品質を大幅に向上させることができます。必要なのは、より高速な再ランク付けだけです。100 ミリ秒未満の再ランキング用に、軽量の再ランキング モデル (例: cross-encoder/ms-marco-TinyBERT-L-2-v2 ) をDatabricksモデルビングサーのカスタム モデルとしてデプロイすることを検討してください。
ステップ 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で利用可能) などの自動プロンプト最適化手法を使用して、データ準備、クエリ書き換え、または検索システムのあらゆる場所で使用されるプロンプトを改善します。Agent Bricks には GEPA が組み込まれており、低コストでパフォーマンスを大幅に向上させることができます。自動プロンプト最適化により最先端のエンタープライズエージェントを 90 倍安価に構築する方法をご覧ください。
詳細については、 「Reflective Prompt Evolution with GEPA」を参照してください。
ステップ 7: 適応型検索戦略
Reactエージェントパターン
検索をインテリジェントに調整できるエージェントを構築します。
- エージェントは取得が必要かどうかを検討します。
- 最初の結果に基づいてクエリを再作成できます。
- 検索を他のツール (計算機、 APIsなど) と組み合わせます。
- クエリを変更して失敗した取得を再試行します。
- 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とほぼ同じである場合、問題は埋め込みモデルではありません。他の最適化に焦点を当てます。
微調整するタイミング
ファインチューニングは最後の手段と考えるべきであり、以下の基準が満たされた場合にのみ検討すべきです。
- ステップ 1 ~ 7 を試しました。
- OpenAI はテストにおいて GTE を大幅に上回ります。
- ドメイン固有の語彙またはユースケースがあります。
ラベル付きトレーニング データは必要ありません。Databricks Databricks埋め込みファインチューニング ブログに示されているように、合成データ生成を使用できます。