RAGを本番で使い始めると、「回答が的外れ」「根拠のない断言が混ざる」「固有名詞を取りこぼす」といった不満が出てくる。
チャンクサイズやモデルをいきなり変えても、何が悪いのか分からないままだと改善が当てずっぽうになりやすい。
この記事では、RAGの精度改善を評価から始める考え方と、初心者が陥りがちな失敗パターンを整理する。
結論：改善は「検索」と「生成」を分けて測る
| 観点 | 内容 |
|---|---|
| 最初にやること | 代表クエリセット（20〜50件）を用意し、現状のベースラインを記録する |
| 分けて測る理由 | 検索ミスと生成ミスは原因も対策も異なる |
| 検索の評価軸 | 正しいチャンクが Top-K に入っているか（Recall@K、MRR など） |
| 生成の評価軸 | 回答が根拠に忠実か、質問に答えているか（Faithfulness、Answer Relevance） |
| 改善の順番 | ①検索の取りこぼしを潰す → ②プロンプトと生成設定を調整 → ③全体を再評価 |
| 覚え方 | 「図書館で本が見つからないのか、見つけたのに説明が下手なのか」を先に切り分ける |
ポイント：体感で「なんとなく悪い」と言うより、どの段階で失敗しているかをラベル付けした評価セットがあると、次の一手が明確になる。
なぜ「評価なしの改善」が失敗しやすいか
RAGの精度は、取り込み・チャンキング・埋め込み・検索・リランキング・プロンプト・LLM設定など、複数のノードの積で決まる。
1つだけ変えて「良くなった気がする」と判断すると、別のクエリでは悪化しているケースを見逃しやすい。
典型的な落とし穴は次の3つだ。
| 落とし穴 | 何が起きるか | 対策の方向 |
|---|---|---|
| 全体スコアだけ見る | 検索は直ったが生成が悪化、など相殺される | 検索指標と生成指標を別々に記録する |
| テスト件数が少ない | たまたま当たったクエリだけで判断する | 最低20件、できればカテゴリ別に分散させる |
| 本番ログを評価に使わない | 開発時の想定質問と実際の質問がズレる | 匿名化した本番クエリを定期的にサンプリングする |
評価セットは一度作って終わりではなく、新しい失敗事例が出るたびに1件追加していく運用が現実的だ。
評価セットの作り方
1. クエリの種類を意識的に混ぜる
| カテゴリ | 例 | なぜ入れるか |
|---|---|---|
| 事実確認 | 「〇〇のデフォルト値は？」 | 検索の Recall を見る |
| 手順・How-to | 「△△の設定手順は？」 | 複数チャンクの統合が必要かを見る |
| 固有名詞・コード | エラーコード、API名、型番 | キーワード検索の必要性を見る |
| 言い換え | 同じ意図の別表現 | 埋め込みの頑健性を見る |
| 答えがない | ドキュメントに無い質問 | ハルシネーション抑制を見る |
2. 正解データ（ゴールド）の粒度
初心者向けには、次の2段階で十分なことが多い。
- 検索ゴールド：この質問には「チャンクID（または該当段落）」が正解、と1件以上指定する
- 回答ゴールド：期待する回答の要点を3行以内で書く（完全一致は求めない）
完璧な正解文を用意するより、**「この情報が含まれていれば合格」**というチェックリスト形式の方が運用しやすい。
3. 記録する最低限の列
スプレッドシートやCSVで、次の列を持つと改善サイクルが回る。
query_id | 質問文 | 期待チャンク | 取得チャンク(Top5) | 検索OK? | 回答要点 | 生成OK? | メモ
「検索OK?」「生成OK?」は Yes/No/部分 でよい。まずは人力ラベルで回し、件数が増えたら LLM-as-a-Judge や RAGAS などの自動評価を検討する。
検索（Retrieval）の評価指標
検索段階では、正しい根拠が候補に入っているかが主戦場だ。
| 指標 | 意味 | 初心者向けの解釈 |
|---|---|---|
| Recall@K | 正解チャンクが Top-K に含まれる割合 | 「答えの本が、上位K冊に入っている率」 |
| MRR | 正解が何位に来たかの平均 | 「正解が何番目に並ぶか」 |
| Hit Rate | 1件でも正解が取れたクエリの割合 | 「少なくとも1冊は当たった質問の割合」 |
数値の絶対値より、変更前後の差分を見る。例えば Recall@5 が 0.55 → 0.72 に上がれば、チャンクサイズ変更やハイブリッド検索追加の効果が読み取れる。
検索でよくある失敗と対策
| 失敗パターン | 症状 | まず試す対策 |
|---|---|---|
| チャンクが大きすぎる | 関連段落の周辺ノイズが多い | サイズを小さくし、オーバーラップを入れる |
| チャンクが小さすぎる | 文脈が切れて意味が欠ける | 見出し単位でまとめる、親子チャンクを検討 |
| 埋め込みモデルとドメインのミスマッチ | 専門用語の検索が弱い | ドメイン向けモデルへ変更、またはハイブリッド検索 |
| Top-K が小さすぎる | 正解が圏外 | K を一時的に増やし、リランカーで絞る |
| メタデータ未活用 | 版・製品・部署で絞れない | フィルタ条件をクエリから推定する |
検索の Recall が低いまま生成プロンプトだけ磨いても、LLMに渡る材料が足りないので効果は限定的だ。
生成（Generation）の評価指標
検索がそこそこ良くても、回答品質は別問題になる。
| 指標 | 意味 | 見るポイント |
|---|---|---|
| Faithfulness（忠実性） | 回答が取得チャンクに基づいているか | 根拠にない断言がないか |
| Answer Relevance | 質問に答えているか | 話題は近いが質問を外していないか |
| Context Precision | 渡したコンテキストのノイズ量 | 無関係な段落が混ざっていないか |
人力評価では、次の3択が実務的だ。
- 合格：根拠どおりで質問に答えている
- 部分合格：要点は合うが抜け・冗長がある
- 不合格：ハルシネーション、質問と無関係、根拠と矛盾
生成でよくある失敗と対策
| 失敗パターン | 症状 | まず試す対策 |
|---|---|---|
| コンテキスト過多 | 長いが的外れな回答 | Top-K を減らす、リランキングを強化 |
| 出典指示の不足 | どの文書から来たか不明 | 「根拠が無い場合は分からないと答える」を明示 |
| 温度が高すぎる | 創作が混ざる | temperature を下げる（0〜0.3 目安） |
| 質問と無関係な一般論 | それっぽいが役に立たない | システムプロンプトで「コンテキスト外は答えない」を強調 |
| 多言語・表記ゆれ | 用語の表記がドキュメントと違う | 用語集チャンクを別途インデックス |
改善サイクルの回し方
評価セットができたら、次のループを1週間単位で回すのが現実的だ。
1. ベースライン計測（検索・生成を別スコアで記録）
↓
2. 失敗クエリを「検索」「生成」「両方」に分類
↓
3. 一番多い失敗タイプに対して1変更だけ入れる
↓
4. 同じ評価セットで再計測
↓
5. 改善したらマージ、悪化したらロールバック
一度に複数パラメータを変えないのが鉄則だ。チャンクサイズと埋め込みモデルとプロンプトを同時に変えると、何が効いたか分からなくなる。
変更の優先順位（初心者向け）
| 優先度 | 対象 | 理由 |
|---|---|---|
| 高 | 取り込み・前処理の品質 | 表崩れ・ノイズは後段では直せない |
| 高 | 検索の Recall@K | 材料が無ければ生成は上がらない |
| 中 | ハイブリッド検索・リランキング | 固有名詞・略語の取りこぼし対策 |
| 中 | プロンプト（出典・拒否条件） | 忠実性とハルシネーション抑制 |
| 低 | LLMモデルの変更 | コスト増の割に検索問題は解決しない |
実装チェックリスト
- 評価用クエリを20件以上、カテゴリ別に用意した
- 各クエリに「期待チャンク」または「期待する回答要点」を書いた
- 検索（Recall@K など）と生成（忠実性・関連性）を別列で記録している
- ベースラインを1回計測し、数値を保存した
- 失敗クエリを検索/生成/両方にラベル付けした
- 1回の変更は1パラメータに絞っている
- 「根拠が無い場合は分からない」とプロンプトに明記した
- 本番ログから匿名化サンプルを定期的に評価セットへ追加する運用を決めた
失敗パターン
パターン1：デモ用の5問だけで「精度90%」と報告する → 対策：カテゴリ分散した評価セットと、変更前後の差分表を必ず残す。
パターン2：検索が悪いのにプロンプトだけ100回試す → 対策：まず Recall@K を測り、取りこぼしが多いならチャンキング・ハイブリッド検索から手を入れる。
パターン3：自動評価スコアだけ信じて本番で崩れる → 対策：LLM-as-a-Judge は参考指標。最終的には人力サンプルと本番フィードバックで補正する。
パターン4：正解データの更新を忘れる → 対策：ドキュメント改訂時に評価セットの期待値も更新するルールを決める。
パターン5：改善と同時に機能追加（エージェント化など） → 対策：RAG単体のベースラインが安定してから、次の機能を載せる。
参考リンク
- RAGAS — Evaluation framework for RAG
- LangChain — Evaluation
- LlamaIndex — Evaluation
- Pinecone — RAG evaluation
- OpenAI — Cookbook: How to evaluate LLMs
この記事を書いた人✏️@YushiYamamoto
ITPRODX.com代表 / AIアーキテクト
Next.js / TypeScript / n8nを活用した自律型アーキテクチャ設計を専門としています。
日々の自動化の検証結果や、ビジネス側の視点（ROI等）に関するより深い考察は、以下の公式サイトおよびnoteで発信しています。