RAGの基礎を超えて：高度な検索戦略

RAGの現実確認

Retrieval-Augmented Generation（RAG）は、プライベートデータにアクセスする必要があるAIアプリケーションを構築するための定番パターンになりました。基本的な設定はシンプルです。ドキュメントを埋め込み、ベクターデータベースに保存し、関連するチャンクを取得して、LLMに渡します。

しかし、基本的なRAGはすぐに壁に当たります。ユーザーが複数のドキュメントにまたがる質問をします。コンテキストウィンドウが無関係なチャンクで埋まります。「似ているが十分ではない」ために取得できなかった重要な情報が回答から抜け落ちます。

実際に機能するRAGシステムを構築する方法をご紹介します。

検索の失敗モードを理解する

最適化する前に、検索が失敗する理由を理解してください：

セマンティックミスマッチ — ユーザーのクエリがドキュメントと異なる用語を使用している。「払い戻しを受けるにはどうすればいいですか？」vs「経費申請」について書かれたドキュメント。

コンテキストの断片化 — 関連情報が、まとめて取得されない複数のチャンクに散在している。

時系列の盲点 — ベクターの類似性は時間を理解しません。最も関連性の高い回答は最新のものかもしれませんが、最も類似したものではない場合があります。

特異性の問題 — 一般的な質問は一般的なコンテンツを取得し、詳細なドキュメントに埋もれた具体的な回答を見逃します。

マルチステージ検索

単一ステップの検索は複雑なクエリにはほとんど機能しません。私たちはマルチステージアプローチを使用します：

ステージ1：広範な検索

網を広く張ります。最終的に使うより多くのドキュメントを取得します（上位5〜10件ではなく上位50〜100件）。

ステージ2：リランキング

クロスエンコーダーリランカーを使用して、各候補をクエリに対してスコアリングします。これは遅くなりますが、埋め込み類似性単独よりもはるかに正確です。

ステージ3：コンテキストフィルタリング

ビジネスロジックフィルターを適用します：

• 新鮮さ（より新しいドキュメントを優先）
• 情報源の権威性（コメントより公式ドキュメントを優先）
• アクセス制御（ユーザー権限）

ステージ4：コンテキストの組み立て

チャンクを単純に連結しないでください。コンテキストを知的に構成します：

• ソースドキュメントでグループ化する
• ドキュメントの階層を維持する
• メタデータ（日付、著者、ドキュメントタイプ）を含める

クエリの変換

ユーザーのクエリは、検索にとって最良のクエリではないことが多いです。変換しましょう：

クエリの拡張 — 同じ質問の複数の言い方を生成します。それぞれで検索して結果をマージします。

仮説的ドキュメント埋め込み（HyDE） — LLMに仮説的な回答を生成させ、それを使って検索します。質問を直接使った検索より効果的なことが多いです。

分解 — 複雑な質問をより単純なサブ質問に分解します。それぞれで検索して結果を統合します。

チャンク戦略

デフォルトのチャンキング（トークンや文字での分割）は最適とは言えません。

セマンティックチャンキング — 任意のトークン数ではなく、自然な区切り（段落、セクション）で分割します。

階層的チャンキング — 複数のチャンクサイズを作成します。各クエリに適切な粒度で検索します。

オーバーラップチャンク — 連続性を保つために隣接するチャンクのコンテキストを含めます。

メタデータの付加 — より良いコンテキストのために、各チャンクにドキュメント構造（ヘッダー、セクションタイトル）を付加します。

ハイブリッド検索

ベクター検索単独では限界があります。アプローチを組み合わせましょう：

BM25 + ベクター — 従来のキーワード検索は、セマンティック検索が見逃す完全一致を捉えます。両方の結果を統合します。

構造化 + 非構造化 — ドキュメントに構造化メタデータ（日付、カテゴリ、著者）がある場合、ベクター検索と並行してSQLスタイルのフィルタリングを使用します。

ナレッジグラフ + ベクター — 複雑なドメインでは、エンティティと関係性をナレッジグラフに抽出します。グラフトラバーサルで関連概念を見つけ、その部分空間内でベクター検索を行います。

評価と反復

計測できなければ改善できません。RAGパイプラインに評価を組み込みましょう：

検索メトリクス：

• Precision@K：取得したドキュメントは関連性があるか？
• Recall@K：すべての関連ドキュメントが取得されているか？
• Mean Reciprocal Rank：最良のドキュメントが最初にランクされているか？

エンドツーエンドメトリクス：

• 回答の正確性（利用可能な場合はグラウンドトゥルースとの比較）
• 回答のグラウンドネス（回答は取得したコンテキストに基づいているか？）
• ユーザー満足度（フォローアップ質問などの暗黙のシグナル）

テストセットを作成してください。 既知の良回答を持つ代表的なクエリ50〜100件。リグレッションを検出するために定期的に実行します。

本番環境での考慮事項

キャッシング — 埋め込みをキャッシュし、一般的なクエリの検索結果をキャッシュし、適切な場合はLLMレスポンスをキャッシュします。

レイテンシ — 知覚パフォーマンスを最適化します。取得したソースを表示しながらLLMレスポンスをストリーミングします。

コスト — 検索は安価ですが、LLM呼び出しは高価です。コンテキスト長を最適化します。単純なクエリには小規模なモデルを検討します。

モニタリング — クエリ、取得ドキュメント、生成された回答をログに記録します。継続的な改善のためのフィードバックループを構築します。

RAGの未来

RAGは急速に進化しています：

• エージェンティックRAG — 反復的に検索して推論するエージェント
• グラフRAG — ナレッジグラフと検索の組み合わせ
• マルチモーダルRAG — 画像、テーブル、テキストを横断した検索と推論

基礎が最も重要です。検索を正しく行えば、残りはついてきます。