RAG 評価指標チートシート
RAGの指標は、おおむね次の4つの層に分けられます。
Retrieverは見つけられるか
↓
Contextは完全で、ノイズがないか
↓
Generatorは正しく、証拠に基づいて回答できるか
↓
システム全体が安全で、高速かつ経済的か
従来の検索指標は、通常、手作業でラベル付けした関連文書から直接計算でき、LLM Judgeを必要としません。現在のNVIDIAのRetriever評価には、Precision、Recall、nDCG、MAP、Reciprocal Rank、Success@kが含まれています。Ragas、AWS、Databricksは、Context、Groundedness、Correctness、Citationなど、RAG全体を対象とする指標を補っています。
@kは検索結果の先頭k件だけを確認することを表します。たとえばRecall@10は先頭10件だけを見ます。
1. 検索・ランキング指標
| 指標 | なぜ重要か | おおまかな計算方法 |
|---|---|---|
| Hit@k / Success@k | 上位k件の中に少なくとも1つ正しい証拠があるかを確認する。単一の証拠で答えられる質問に向く | Top-kに関連結果が少なくとも1つあれば 1、なければ 0 とし、全質問で平均する |
| Recall@k | 必要な証拠を取りこぼしていないかを確認する。RAG Retrieverの最も重要な基礎指標の1つ | Top-kで見つかった関連証拠数 ÷ 本来見つけるべき関連証拠の総数 |
| Precision@k | 検索結果のうち、本当に役立つものがどれだけあるかを確認し、ノイズ量を把握する | Top-kに含まれる関連結果数 ÷ k |
| MRR | 最初の正しい結果がどれだけ上位に現れるかを確認する。「権威ある答えを1つ見つければよい」質問に向く | 最初の関連結果の順位の逆数を取り、全質問で平均する。2位なら 1/2 |
| MAP@k | 複数の関連結果が見つかっているかと、上位に並んでいるかを同時に確認する | 関連結果が現れるたびにその時点のPrecisionを計算し、それらのPrecisionを全質問で平均する |
| nDCG@k | 関連性の有無だけでなく、「中核証拠、補助証拠、一部関連」を区別できる。Rerankerの評価に特に向く | 結果に異なる関連度のラベルを付け、重要な結果ほど上位で大きく寄与させ、理想的なランキングと比較する |
| All-Evidence@k | マルチホップ質問に必要な証拠チェーンがすべて見つかったかを確認する | 必要な証拠グループがすべてTop-kに入れば 1、どれか1つでも欠ければ 0 |
| Document Recall@k | 正しい文書が見つかったかを確認し、問題が文書レベルかChunkレベルかを切り分ける | Top-kで命中した正しい文書数 ÷ 命中すべき正しい文書数 |
| Evidence/Chunk Recall@k | 正しい文書の内部で、実際に答えを支える段落が見つかったかを確認する | Top-kで命中したGolden Evidence Chunkまたは証拠範囲 ÷ 必要な証拠の総数 |
直感的な理解
Hit@k:
少なくとも1つ見つかったか?
Recall@k:
見つけるべき証拠のうち、どれだけ見つかったか?
Precision@k:
検索結果のうち、本当に役立つものはどれだけか?
nDCG@k:
最も重要な証拠が最上位にあるか?
All-Evidence@k:
証拠チェーンがすべてそろっているか?
All-Evidence@k は実用的なエンジニアリング用カスタム指標ですが、Recall、nDCG、MAPのように統一された標準名称があるわけではありません。設計時には「証拠グループ」を単位にラベル付けし、同じ要件を満たす複数の同等な証拠を許容するとよいでしょう。
2. Contextの品質指標
従来のRetriever指標は、一般に手作業でラベル付けした関連文書に依存します。一方、Context系の指標では、最終的に生成モデルへ渡すContextがクリーンで、完全かつ十分かを、参照回答やLLM Judgeで判定することが多くなっています。
| 指標 | なぜ重要か | おおまかな計算方法 |
|---|---|---|
| Context Precision | 最終Contextのノイズが多すぎないか、関連Chunkが上位に並んでいるかを確認する | 各Chunkが役立つかを判定し、関連Chunkが多く、かつ上位にあるほど高いスコアにする |
| Context Recall | 参照回答に必要な事実がすべてContextから見つかるかを確認する | 参照回答を事実の主張に分解し、そのうちいくつが検索Contextで支えられるかを計算する |
| Context Coverage | Context Recallに近いが、標準回答に必要な情報をContextがカバーしているかを強調する | Contextでカバーされた標準回答の情報 ÷ 標準回答に必要な全情報 |
| Context Relevance | 検索された内容がユーザーの質問と本当に関係しているかを確認する | 通常はLLM Judgeに各Chunkと質問の関連度を採点させ、その平均を取る |
| Context Sufficiency | 現在のContextだけで完全な回答を生成するのに十分かを確認する | expected_facts または標準回答を基に、Contextが完全な回答を支えられるかを二値または段階評価で判定する |
| Context Noise Ratio | 無関係な内容に何tokenが使われているかを確認する。品質、レイテンシ、コストに関係する | 無関係なContextのtoken数 ÷ Context全体のtoken数 |
| Duplicate Context Rate | 同じ情報がモデルに繰り返し渡されていないかを確認し、重複によるバイアスとtokenの浪費を避ける | 重複または高度に類似したChunk数 ÷ 最終ContextのChunk総数 |
Context RecallとRecall@kの違い
Recall@k:
手作業でラベル付けした関連文書または証拠IDに基づいて計算する。
Context Recall:
参照回答に含まれる事実を基に、それらをContextから支えられるかを判定する。
3. 回答生成の品質指標
| 指標 | なぜ重要か | おおまかな計算方法 |
|---|---|---|
| Answer Correctness | 最終回答の事実と結論が正しいかを確認する。最も直接的な結果指標 | 回答を標準回答または expected_facts と比較して正しい事実の割合を計算するか、LLM JudgeにRubricで採点させる |
| Faithfulness / Groundedness | 回答が検索された証拠に忠実かを確認し、ハルシネーションを見つける | 回答を事実の主張に分解し、そのうちいくつがContextで支えられるかを計算する |
| Completeness | 回答自体は正しくても、質問の一部しか答えていない状態を防ぐ | 標準回答が要求する必要な事実のうち、実際の回答がカバーしている割合 |
| Answer Relevance / Response Relevancy | 回答が正しくても的外れにならず、ユーザーの質問に本当に答えているかを確認する | 回答内容とユーザーの意図の関連度を判定し、無関係または重複した内容を減点する |
| Helpfulness | 回答がユーザーのタスク完了に本当に役立つかを確認する | 通常は人間またはLLM Judgeが、有用性、明確さ、実行可能性に基づいて総合評価する |
| Logical Coherence | 回答内部の矛盾、論理の飛躍、前後の不一致を確認する | Rubricに沿って回答の論理が完全かつ一貫しているかを確認する |
| Exact Match | モデル名、日付、数値、enum値など、回答形式が固定された場面に向く | 正規化後のシステム回答が標準回答と完全一致すれば 1、それ以外は 0 |
| Fact-level Accuracy | 段落全体のテキスト類似度よりも、企業RAGに向いている | 回答を複数の事実に分解し、正しい事実数 ÷ 評価対象の事実総数を計算する |
CorrectnessとFaithfulnessは異なる
Correctness:
回答は現実または標準回答に照らして正しいか?
Faithfulness:
回答は検索されたContextから支えられるか?
たとえば、次のような場合があります。
回答は正しいが、Contextによる裏付けがない。
→ モデルが自分の記憶から推測し、たまたま正解した可能性がある。
回答はContextに忠実だが、回答自体は誤っている。
→ ナレッジベースの文書が古いか、もともと誤っている可能性がある。
4. 引用品質の指標
| 指標 | なぜ重要か | おおまかな計算方法 |
|---|---|---|
| Citation Precision | 引用は存在していても、対応する主張を支えられない状態を防ぐ | 対応する主張を正しく支える引用数 ÷ 引用総数 |
| Citation Coverage / Citation Recall | 少数の正しい引用だけを示し、多くの事実に引用がない状態を防ぐ | 有効な引用が付いた事実の主張数 ÷ 引用が必要な主張の総数 |
| Citation Validity | 引用が実在し、リンクやページ番号が有効かを確認する | 有効な引用数 ÷ 引用総数 |
| Citation Entailment | 引用元の本文が回答の結論を本当に導けるかを確認する | 「主張—引用」の組ごとに、支持・非支持・矛盾を判定する |
たとえば、次のようになります。
回答に10個の事実が含まれている。
そのうち2つだけを引用し、その2つの引用はどちらも正しい。
Citation Precision = 高い
Citation Coverage = 低い
5. 拒否・回答可能性の指標
「回答がよいか」だけを評価するのでは不十分です。システムがいつ拒否すべきかを理解しているかも評価する必要があります。
| 指標 | なぜ重要か | おおまかな計算方法 |
|---|---|---|
| Refusal Accuracy | システムが正しい場面で拒否しているかを確認する | 正しい回答または正しい拒否のケース数 ÷ 全ケース数 |
| Unsupported Answer Rate | 文書に証拠がないのに、システムが回答を強行する割合を測る | 回答不能な質問に対してシステムが回答した数 ÷ 回答不能な質問の総数 |
| Over-refusal Rate | 十分な証拠があるのに、システムが拒否する割合を測る | 回答可能な質問のうち、誤って拒否した数 ÷ 回答可能な質問の総数 |
| Clarification Accuracy | 質問が曖昧なときに、システムが正しく確認を求めるかを確認する | 確認が必要なケースのうち、実際に確認を要求した割合 |
理想的な状態は次のとおりです。
証拠がある → 正しく回答する
証拠がない → 拒否する
曖昧さがある → 先に確認する
権限がない → アクセスを拒否する
6. セキュリティ、権限、本番指標
これらは必ずしも統一された学術指標ではありませんが、企業で導入する際には通常、ハードなRelease Gateとして扱うべきです。
| 指標 | なぜ重要か | おおまかな計算方法 |
|---|---|---|
| Unauthorized Retrieval Rate | Retrieverがユーザーに権限のないChunkを取得していないかを確認する | 権限のない結果数 ÷ 検索結果総数 |
| Cross-tenant Leakage Rate | テナントAがテナントBのデータを受け取ることを防ぐ | テナント間の露出が発生したテスト数 ÷ 権限テスト総数 |
| Document Injection Success Rate | 悪意のある文書の指示がモデルを制御できるかを確認する | 文書インジェクションによって操作に成功したケース数 ÷ インジェクションテスト総数 |
| p50 / p95 / p99 Latency | 平均値では一部の非常に遅いリクエストが隠れるため、本番では通常p95を重視する | リクエストのレイテンシを並べ、p95は95%のリクエストがその値を超えないことを表す |
| Cost per Query | 品質の向上が小さいのにtokenとモデルの費用だけが大きく増えることを防ぐ | Retriever、Reranker、Embedding、LLMの総費用 ÷ リクエスト数 |
| Token per Query | Contextが長すぎないか、重複や浪費がないかを確認する | 1リクエストあたりの入力・出力token数の平均またはパーセンタイル |
| Error Rate | タイムアウト、モデルエラー、パース失敗を監視する | 失敗リクエスト数 ÷ リクエスト総数 |
セキュリティ指標は通常、次を要求すべきです。
Unauthorized Retrieval Rate = 0
Cross-tenant Leakage Rate = 0
権限漏えいを、他の品質指標の改善で相殺してはいけません。
7. 最初に推奨する最小限の指標セット
RAGシステムを構築し始めたばかりなら、すべての指標を一度に実装する必要はありません。まずは次のセットから始められます。
| 評価層 | 優先する指標 |
|---|---|
| 検索で取りこぼしていないか | Recall@k |
| ランキングは妥当か | nDCG@k |
| 完全な証拠がそろったか | All-Evidence@k |
| Contextにノイズがないか | Context Precision |
| Contextは十分か | Context Recall または Context Sufficiency |
| 回答は正しいか | Answer Correctness |
| 証拠に忠実か | Faithfulness / Groundedness |
| 情報が抜けていないか | Completeness |
| 引用は信頼できるか | Citation Precision + Citation Coverage |
| 証拠がないのに作り話をしていないか | Unsupported Answer Rate |
| 拒否が多すぎないか | Over-refusal Rate |
| 本番性能 | p95 Latency + Cost per Query |
| 権限の安全性 | Unauthorized Retrieval Rate |
この組み合わせは、次のように覚えられます。
Recall:
すべて見つけられたか?
nDCG:
ランキングはよいか?
All-Evidence:
証拠チェーンはそろっているか?
Context Precision:
ノイズはどれくらいあるか?
Correctness:
回答は正しいか?
Faithfulness:
回答は証拠に基づいているか?
Completeness:
回答に抜けはないか?
Citation:
引用は正確かつ完全か?
Refusal:
証拠がないときに作り話をしないか?
Latency / Cost / ACL:
システムを安全に本番投入できるか?
参考資料
- NVIDIA NeMo Evaluator Retriever Metrics https://docs.nvidia.com/nemo/microservices/latest/evaluator/metrics/retriever.html
- Ragas Context Precision https://docs.ragas.io/en/stable/concepts/metrics/available_metrics/context_precision/
- AWS Bedrock Knowledge Base Evaluation Metrics https://docs.aws.amazon.com/bedrock/latest/userguide/knowledge-base-eval-llm-results.html
- Microsoft RAG Evaluation Guidance https://learn.microsoft.com/en-us/azure/architecture/ai-ml/guide/rag/rag-llm-evaluation-phase