AIシリーズ面接問題11：RAGのチューニング方法は？

RAGのチューニングは単一の工程ではなく、全リンク最適化のプロセスです。以下ではデータ索引側、検索側、生成側、評価側の4つの次元から、体系的なチューニング戦略と面接で使える実践経験を紹介します。

一、データ索引側のチューニング（「知識ベース」の品質向上）

最も見落とされがちですが、効果が最も早く現れる箇所です。

チューニングポイント	問題現象	具体的な方法	効果指標
ドキュメント解析	PDF内の表やフローチャートが無視されたり、文字化けや順序の乱れが発生。	より優れた解析ライブラリ（例：`unstructured`、`pypdf`のレイアウト保持モード）に変更。表は`pandas`で抽出後、Markdownに変換。	再現率 +5〜15%
テキスト分割サイズ	チャンクが小さすぎて文脈が失われる（例：「今年の売上は増加した」の「それ」の指示対象が不明）。チャンクが大きすぎると検索ノイズが増加。	異なるチャンクサイズ（256/512/768トークン）を実験し、オーバーラップを10〜20%に設定。長文書では、意味境界（段落/見出し）で分割し、固定長は避ける。	ヒット率 / 忠実性
メタデータ付加	関連する段落が見つかっても、出典や時間を遡れない、またはドメインでフィルタリングしたい。	各チャンクにメタデータ（`source`（ファイル名/URL）、`timestamp`、`page_num`、`doc_type`）を追加。検索時にフィルター（例：`doc_type == 'legal'`）を使用。	フィルタリング精度
埋め込みモデル選択	汎用埋め込みが垂直領域（医療、コード、法律）で性能が低い。	ドメイン特化の微調整モデル（BGE-large-zh、GTE-Qwen2-7B-instruct）を使用。または自身で埋め込みモデルを微調整（トリプレットロス）。	検索MRR@10 +10〜20%

二、検索側のチューニング（「本をめくる」精度向上）

検索はLLMに与える「参考資料」の品質を決定します。

チューニングポイント	問題現象	具体的な方法	効果
ハイブリッド検索	ベクトル検索では正確な用語（製品型番 `ABC-123`）にマッチできず、キーワード検索では同義語を理解できない。	ベクトル検索（意味）とBM25（キーワード）を同時に使用し、重み付け（例：0.7ベクトル + 0.3BM25）またはrerankで融合。	再現率 +10〜25%
再ランク付け（Rerank）	ベクトル検索の上位結果が必ずしも最も関連性が高くなく、10番目が最良の場合がある。	クロスエンコーダモデル（例：`BGE-reranker-v2`、Cohere Rerank）で候補セット（例：上位20件）を再スコアリングし、top-Kを取得。	ヒット率が大幅に向上（特にtop-1）
クエリ書き換え	ユーザーの質問が曖昧、またはマルチターン会話で指示語が不明瞭（「その価格は？」）。	LLMを使用して元の質問を検索に適した形式に書き換える（例：「iPhone 15の価格はいくらですか？」）。または会話履歴を利用して補完。	再現率 +5〜15%
HyDE	ユーザーの質問が短すぎる、または抽象的（例：「光合成について説明してください」）で直接検索の効果が低い。	まずLLMに仮説的な回答を生成させ、その回答を使用してドキュメントを検索。	オープンドメインに適するが、事実に基づく正確なQAには不向き
検索数Top-K調整	Kが小さすぎると重要な情報を見逃し、大きすぎるとトークン消費とノイズが増加。	K=3/5/10で実験し、再現率と回答忠実性のバランスを観察。	効率と効果のトレードオフ

三、生成側のチューニング（LLMが参考資料をうまく活用させる）

検索が正確でも、プロンプトが悪いかモデルが不十分なら無意味です。

チューニングポイント	問題現象	具体的な方法	効果
プロンプトエンジニアリング	LLMが検索内容を無視したり、でっち上げたりする。	明確な指示：「以下の提供された参考資料のみに基づいて質問に答えてください。資料が不十分または関連性がない場合は、「十分な情報がありません」と答えてください。」 few-shot examplesを追加して、出典の引用方法を示す。	忠実性 +20〜40%
コンテキスト圧縮	検索されたコンテンツが長すぎる（モデルのコンテキストウィンドウ超過）、または大部分がノイズ。	`LLMLingua`や`選択的コンテキスト`圧縮を使用し、最も関連性の高い文のみを保持してLLMに渡す。	情報損失リスクの低減
LLMモデルアップグレード	小規模モデル（7B）は複雑な推論ができない、または長いコンテキストを記憶できない。	より強力なモデル（GPT-4o、Claude 3.5 Sonnet、Qwen2.5-72B）に切り替え。	推論精度が大幅に向上
ストリーミングと引用	ユーザーが回答の信頼性を検証できない。	生成時にLLMに`[citation:1]`を出力させ、検索ドキュメントの番号に対応させる。バックエンドで原文リンクを添付。	ユーザーの信頼 + デバッグ容易性
回答拒否の調整	モデルが答えるべきでないときにでっち上げたり、答えるべきときに「わからない」と言ったりする。	類似度しきい値を設定：検索されたtop-1チャンクと質問のコサイン類似度が0.7未満の場合、LLMに「資料は関連性がありません」と促す。	ハルシネーション率の低下

四、評価と反復の側（どこを調整すべきか知る）

測定なしに最適化はできません。

チューニングポイント	方法	指標
評価セットの構築	100〜300件の実際のユーザー質問 + 正解 + 正しい検索ドキュメントIDを準備。	異なる難易度、異なる意図をカバー。
自動評価	RAGAS（Faithfulness, Answer Relevance, Context Recall）または TruLens を使用。	三つのコア指標：忠実性、回答関連性、コンテキスト再現率。
手動評価	毎週20件のbad caseをサンプリングし、エラータイプ（検索失敗/生成エラー/知識ベース欠落）を分析。	改善優先順位の決定。
A/Bテスト	本番環境で異なる検索戦略（例：BM25対ハイブリッド検索）をバケットテスト。	オンライン指標：ユーザー満足度、無回答率。

五、面接で使える「実践経験」（加点ポイント）

「私が担当したRAGプロジェクトでは、初期のベースラインヒット率は67％でした。私は3つのことを行いました：
1. チャンクを固定1024から動的意味分割（見出し+段落）に変更し、ヒット率が74％に向上。
2. ハイブリッド検索（ベクトル+BM25）と小型rerankモデルを導入し、ヒット率が83％に上昇。
3. プロンプトを最適化し、[関連情報が見つかりません]を強制し、ハルシネーション率が22％から5％以下に低下。

また、継続的な評価パイプラインを構築し、変更のたびに200の質問でRAGASスコアを実行し、退化がないことを確認しました。」

最後にまとめ：完全なRAGチューニングロードマップ

データ層 ─→ ドキュメントクリーニング、チャンク最適化、メタデータ拡張、ドメイン特化埋め込み
検索層 ─→ ハイブリッド検索、rerank、クエリ書き換え、HyDE、Top-Kチューニング
生成層 ─→ プロンプト強化、指示要求、圧縮、引用、拒否しきい値
評価層 ─→ 評価セット、RAGAS、手動分析、A/B実験