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 CoverageContext 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 RateRetrieverがユーザーに権限のない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 QueryContextが長すぎないか、重複や浪費がないかを確認する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:
システムを安全に本番投入できるか?

参考資料