RAG 品質評価手法まとめ
評価の2軸
RAGの品質評価は「検索」と「生成」の2段階に分けて考える。
質問 → [検索] → 関連チャンク → [LLM] → 回答
↑評価① ↑評価②
① 検索品質の評価
Precision@K / Recall@K
-
Precision@K: 上位K件の検索結果のうち、正解チャンクが何件含まれるか
-
Recall@K: 正解チャンクのうち、上位K件に何件含まれるか
-
必要なもの: 各質問に対する「正解チャンク」のラベル（人手で作成）
Precision@3 = 正解チャンク数 / 3
Recall@3 = 取得できた正解チャンク数 / 全正解チャンク数
|
内容 |
| メリット |
検索層だけを単独で評価でき、LLMの影響を受けない |
| デメリット |
「正解チャンク」のラベル付けに業務知識が必要。実務者の協力が不可欠 |
MRR（Mean Reciprocal Rank）
- 最初に正解チャンクが出てくる順位の逆数の平均
- 例: 1位に正解→1.0、2位に正解→0.5、3位に正解→0.33
|
内容 |
| メリット |
「どの順位に正解が出るか」を一数値で表せる |
| デメリット |
こちらもラベル付きデータが必要 |
② 回答品質の評価
人手評価（ゴールドスタンダード）
正解回答を事前に用意し、LLMの回答と照合する。
-
評価項目の例:
- 正確性（Faithfulness）: 資料に基づいているか
- 網羅性（Completeness）: 必要な情報が含まれているか
- 簡潔性（Conciseness）: 余計な情報がないか
|
内容 |
| メリット |
最も信頼性が高い。実務者の「現場感覚」をそのまま反映できる |
| デメリット |
作成・更新にコストがかかる。資料改訂のたびに正解も見直しが必要 |
LLM-as-Judge
別のLLM（ClaudeやGPT-4など）に回答を採点させる。
以下の質問・資料・回答を評価してください。
- 忠実性（1〜5）: 回答が資料の内容に忠実か
- 関連性（1〜5）: 質問に対して適切に答えているか
質問: {query}
資料: {context}
回答: {answer}
|
内容 |
| メリット |
正解データ不要。実装が簡単で自動化しやすい。大量評価に向く |
| デメリット |
LLM自身の判断に依存するため、採点基準がブレる。後述のリスクあり |
LLM-as-Judgeのリスク
| リスク |
内容 |
| 自己贔屓（Self-preference） |
ClaudeがClaudeの回答を高く評価しやすい傾向がある |
| 冗長さへの高評価 |
長くて丁寧な回答を正確な回答より高く採点する傾向がある |
| 幻覚の見逃し |
LLMが自信ありげな誤回答を見抜けないことがある |
| 基準のドリフト |
同じ質問でも実行タイミングによってスコアがばらつく |
| 業務適合性の評価不可 |
「法的に正確か」「現場で使えるか」はLLMには判断できない |
RAGAS（RAG評価フレームワーク）
RAG専用のPythonライブラリ（pip install ragas）。
| 指標 |
内容 |
| Faithfulness |
回答が検索結果に忠実か（幻覚の検出） |
| Answer Relevancy |
回答が質問に関連しているか |
| Context Precision |
検索結果に正解情報が含まれるか |
| Context Recall |
正解情報を検索で取りこぼしていないか |
from ragas import evaluate
from ragas.metrics import faithfulness, answer_relevancy
results = evaluate(dataset, metrics=[faithfulness, answer_relevancy])
|
内容 |
| メリット |
4指標を自動計算。手法間の定量比較がしやすい |
| デメリット |
内部でLLMを使うためLLM-as-Judgeと同様のリスクを抱える。API料金もかかる |
③ エンドツーエンド評価
Q&Aデータセットによるベンチマーク
質問・正解ペアのデータセットを用意し、手法ごとにスコアを比較する。
質問リスト → 各手法でask() → 回答リスト → LLM採点 → スコア集計
|
内容 |
| メリット |
手法比較の共通基準になる。一度作れば繰り返し使える |
| デメリット |
質問・正解の作成に業務知識が必要。網羅性の担保が難しい |
キーワード一致率（Exact Match）
回答に特定のキーワード・数値が含まれるかをチェックする。
- 例: 「67%」「180日」「13%」などが回答に含まれているか
|
内容 |
| メリット |
実装が簡単。LLM不要で完全自動化できる |
| デメリット |
表現の揺れ（「67%」「67パーセント」）に対応できない。意味的な正しさは評価できない |
PoCにおける実務者・プログラマー分業時の推奨アプローチ
実務者がデータを準備できる場合 → 人手評価ベース
実務者: 質問20〜30問 + 正解回答を作成（Excelでも可）
↓
プログラマー: スクリプトで各手法に流して回答を生成
↓
実務者: 回答を確認し ○/△/× で評価
↓
プログラマー: スコア集計・手法比較
メリット: 現場の基準で評価できる。「業務上使えるか」を直接確認できる
注意点: 実務者の評価時間を確保する必要がある。評価基準を事前にすり合わせておく
実務者がデータを準備できない場合 → LLM-as-Judgeで代替
プログラマー: 代表的な質問を10〜20問自力で作成
↓
各手法で回答を生成
↓
Claudeに採点させる（忠実性・関連性を1〜5点）
↓
スコアで手法を比較
メリット: 実務者の工数ゼロで評価を自動化できる
リスク（再掲）: 業務適合性は評価できない。採点基準がブレる。最終的な判断は必ず実務者が確認すること
推奨: LLM-as-Judgeで絞り込んだ上位1〜2手法を実務者に確認してもらうのが現実的。全手法を実務者に見せるより負担が減る。
評価手法の選択マトリクス
| 手法 |
正解データ |
実装難易度 |
信頼性 |
自動化 |
| 人手評価 |
必要 |
低 |
◎ |
× |
| LLM-as-Judge |
不要 |
低 |
△ |
◎ |
| RAGAS |
一部必要 |
中 |
○ |
○ |
| キーワード一致率 |
必要 |
低 |
△ |
◎ |
| Precision@K |
必要 |
中 |
○ |
○ |
参考
