Ragasの評価指標を具体例で理解し、検索と生成のどこが悪いかを切り分ける

RAG を組んで回答させたのに出力がいまいちなとき、原因が検索側なのか生成側なのか分からず、手が止まることがあります。
Ragas は、この「どこを直せばいいのか分からない」を、検索と生成に分けて指標で観測するためのフレームワークです。

この記事では、現行の Ragas が持つ RAG 向けの指標を、具体例とあわせて整理します。
実装やインストール手順、スコアの計算式は公式に譲り、ここでは各指標が何を見て、スコアから何が読めるかに絞ります。

目次

1. RAG の評価が一筋縄でいかない理由
2. 評価に使うデータ
3. 現行の RAG 向け指標
4. 各指標が見ているものと具体例
5. Context Precision
6. Context Recall
7. Context Entities Recall
8. Noise Sensitivity
9. Response Relevancy
10. Faithfulness
11. マルチモーダルの2指標
12. 似ている指標の関係性
13. スコアの組み合わせから読み取れること
14. Ragas でわからないこと
15. 実務での使い方
16. まとめ
17. 参考文献

対象

本記事執筆時点（2026/6/29）の最新版である ragas v0.4.3
https://docs.ragas.io/en/v0.4.3/

記事内容との整合性を取るため、本記事のリンクは v0.4.3 で統一しています。

安定版へのリンクはこちら↓
https://docs.ragas.io/en/stable/

RAG の評価が一筋縄でいかない理由

RAG の回答は、単独の LLM の出力ではありません。
質問を受けてから回答が出るまでに、複数の処理が連なっています。

user_input（ユーザーの質問）
 ↓
Retriever（検索）
 ↓
retrieved contexts（検索で取得したコンテキスト）
 ↓
Generator（LLMによる生成）
 ↓
response（回答）

途中には、チャンク分割、埋め込みモデル、ベクトル検索やキーワード検索、メタデータフィルタ、リランキング、プロンプトといった部品が挟まります。
そのため、回答が悪いという1つの症状の裏に、別々の原因が隠れます。

たとえば、こういう失敗が混ざります。

• 必要な情報をそもそも検索できていない
• 不要な文書を大量に拾ってノイズが増えている
• retrieved_contexts にないことを勝手に答えている
• 質問と回答がズレている

最終回答の正誤だけを見ても、このどれが起きたのかは区別できません。
Ragas は、評価を検索と生成に分解することで、どの段で崩れているかを切り分けやすくします。

評価対象	見ること
検索（Retrieval）	質問に対して適切なコンテキストを取れているか
生成（Generation）	retrieved_contexts に基づいて適切に答えられているか

評価に使うデータ

RAG 評価でよく使う主な項目は以下です。
指標ごとに算出に必要となるデータが異なります。

項目	意味
user_input	ユーザーの質問
response	RAG が生成した回答
retrieved_contexts	Retriever が取得した文書チャンク
reference	期待回答や正解。評価の基準になる。事前の整備が必要
reference_contexts	非 LLM / ID ベース評価で主に使う。事前の整備が必要

reference を用意するには手間がかかります。
後で出てくる Context Recall のように reference が必須の指標もあれば、Faithfulness や Response Relevancy のように reference なしで測れる指標もあります。
評価をどこから始めるかは、この「reference が要るかどうか」で決めると現実的です。

現行の RAG 向け指標

公式ドキュメントの Retrieval Augmented Generation のセクションには、次の8指標が並んでいます。

No.	指標	主な対象	reference	何を見るか
1	Context Precision	検索	基本必要	有用なコンテキストが上位に来ているか
2	Context Recall	検索	必須	必要なコンテキストを取り漏らしていないか
3	Context Entities Recall	検索	必須	必要なエンティティを回収できているか
4	Noise Sensitivity	検索＋生成	必須	ノイズに引っ張られて誤答しないか
5	Response Relevancy	生成	不要	回答が質問に関連しているか
6	Faithfulness	生成	不要	回答が retrieved_contexts に忠実か
-	Multimodal Faithfulness	マルチモーダル生成	不要	画像などを含むコンテキストに忠実か
-	Multimodal Relevance	マルチモーダル生成	不要	マルチモーダル入力に関連しているか

テキストの RAG なら、まずマルチモーダル2つを除いた6つを押さえれば足ります。
以降は、この6つを中心に見ていきます。

注意点として、最終回答が正解とどれだけ近いかを測る指標は、現行ドキュメントのこの RAG セクションには入っていません。
最終回答の正誤を測りたい場合は、別カテゴリの Factual Correctness や Semantic Similarity、NVIDIA 由来の Answer Accuracy を参考にするか、人間レビューを組み合わせる必要がありそうです。

指標の出自と名前の変遷

Ragas の初版論文（Es et al., arXiv:2309.15217）が定義した指標は、次の3つでした。

初版の指標	見るもの	対象	reference
Faithfulness	回答がコンテキストに基づいているか	生成（Generation）	不要
Answer Relevance	回答が質問に答えているか	生成（Generation）	不要
Context Relevance	retrieved_contexts が質問に絞られているか	検索（Retrieval）	不要

論文の特徴は、reference（人手の正解データ）なしで評価できる設計にあります。
RAGシステムを実務で作るとき、理想的には「質問、正解回答、正しい根拠文書、人間評価」がそろっていると評価しやすいです。
しかし実際には、対象ドメインごとにそのようなデータセットを作るのは重いです。

現行ドキュメントの RAG セクションでは、カテゴリ上は Response Relevancy と表示されていますが、ページ本文やコード例では Answer Relevancy / AnswerRelevancy という名称も使われています。また、初版論文に出てくる Context Relevance は、現行の RAG セクションでは中心指標としては扱われず、Context Precision や Context Recall などで検索品質を見る構成になっています。なお、Context Relevance という名称自体は NVIDIA Metrics 側に残っています。

加えて、API も移行期にあります。
公式ドキュメントによると、従来の（legacy な）メトリクス API は v0.4 で非推奨になり、v1.0 で削除される予定で、collections ベースの新しい API への移行が案内されています。
バージョンによって指標名や使い方が変わるので、記事を読むときは「どの版の話か」を確認すべきです。

各指標が見ているものと具体例

ここからが本題です。
テキスト RAG の6指標を、検索を見るもの、ノイズ耐性を見るもの、生成を見るものの順で、具体例とあわせて説明します。
各指標で、スコアが低いと何を疑うか、改善施策の例もあわせて記載します。

1. Context Precision

Context Precision は、retrieved_contexts のうち、質問に役立つものが上位に並んでいるかを見ます。
単に役立つものが含まれるかではなく、ランキングの良さ、つまり上位ほど有用かを precision@k の平均として測るのが特徴です。

• 対象：Retriever（検索）
• reference：基本必須（reference なしは Context Utilization などを検討）
• LLM-as-a-judge：実装バリエーションあり

具体例

たとえば、次のように取得できたとします。

user_input:
有給休暇は入社何か月後から取得できますか？

reference:
有給休暇は入社6か月後から付与されます。

retrieved_contexts:
1. 当社の年間休日は125日である。（無関係）
2. 有給休暇は入社6か月後から付与される。（有用）
3. 慶弔休暇は別途定められている。（無関係）

この場合、reference に照らすと、有用なコンテキストは2番目の「有給休暇は入社6か月後から付与される。」です。
一方で、1番目のコンテキストは年間休日の説明であり、質問にも reference にも直接関係しません。

Context Precision は、有用なコンテキストが含まれているかだけでなく、それが上位に並んでいるかを見ます。
この例では、有用なコンテキストが2番目に出ており、1番目に無関係なコンテキストが来ているため、上位に有用な情報を出せているとは言えません。
そのため、Context Precision はその分だけ低くなります。

スコアが低いときに疑うべき項目

• 検索クエリの質
• チャンクの粗さや細かさ
• 類似度検索だけで意味を取り切れていないこと
• top-k の取りすぎ
  など

スコアを上げるための施策

• ハイブリッド検索やリランキングの導入
• メタデータでの絞り込み
• チャンク設計やクエリリライトの見直し
  など

2. Context Recall

Context Recall は、正解回答に必要な情報を、retrieved_contexts がどれだけ回収できているかを見ます。
reference を主張（claims）に分解し、その各 claim が retrieved_contexts で支持されるかを数えて、支持された割合を出します。

• 対象：検索
• reference：必須
• LLM-as-a-judge：実装バリエーションあり

具体例

たとえば、次のようなデータで考えます。

user_input:
育児休業の申請期限と必要書類を教えてください。

retrieved_contexts:
育児休業は開始予定日の1か月前までに申請する必要がある。

reference:
育児休業は開始予定日の1か月前までに申請し、育児休業申出書と出生予定日を確認できる書類を提出する。

claims:
- 開始予定日の1か月前までに申請する → ◯
- 育児休業申出書を提出する → ×
- 出生予定日を確認できる書類を提出する → ×

この場合、3つの claim のうち支持されるのは1つだけなので（1/3）、Context Recall は低い値になります。

スコアが低いときに疑うべき項目

• 必要な文書が検索対象に入っていないこと
• top-k 不足
• チャンク分割による情報の分断
• 表記揺れへの未対応
• 権限やフィルタによる必要文書の除外
  など

スコアを上げるための施策

• top-k の拡大
• チャンクサイズやオーバーラップの調整
• 見出しやメタデータのチャンクへの追加
• クエリ拡張
• 検索対象データの拡充

3. Context Entities Recall

Context Entities Recall は、回答に必要なentities（人名、組織名、製品名、制度名、部署名、日付、金額など）を、retrieved_contexts が回収できているかを見ます。
通常の Context Recall が意味内容の回収を見るのに対し、こちらは固有表現の回収に注目します。

• 対象：検索
• reference：必須
• LLM-as-a-judge：LLM

具体例

社内文書の RAG で、問い合わせ先を確認する例です。

user_input:
経費精算システムの問い合わせ先はどこですか？

retrieved_contexts:
経費精算システムは、交通費や出張費などの申請に利用するシステムです。
申請内容は承認者による確認後、経理処理に回されます。

reference:
経費精算システムの問い合わせ先は経理部です。

entities:
- 経費精算システム → ◯
- 経理部 → ×

この場合、retrieved_contexts には「経費精算システム」という対象システム名は含まれています。
しかし、問い合わせ先である「経理部」は含まれていません。

Context Entities Recall は、必要な entities をどれだけ回収できているかを見ます。
この例では、2つの entities のうち回収できたのは1つだけなので、Context Entities Recall は低くなります。

スコアが低いときに疑うべき項目

• 略称と正式名称の不一致
• 重要語がチャンクから落ちていること
• メタデータ化すべき情報が本文に埋もれていること
  など

スコアを上げるための施策

• エンティティ辞書や同義語辞書の整備
• 略称の正規化
• 固有表現抽出の前処理
• メタデータ検索の併用

4. Noise Sensitivity

Noise Sensitivity は、retrieved_contexts にノイズが混じったとき、それに引っ張られて誤答しないかを見ます。
スコアが高いほど良さそうに見えますが、逆で、低いほどノイズに鈍感=強いという意味です。
回答の各主張（claims）のうち、誤っている主張の割合として測られるので、値が大きいほど誤りが多いことになります。

• 対象：検索＋生成
• reference：必須
• LLM-as-a-judge：LLM

RAG の検索結果には、古い規程、廃止された仕様、似ているが別システムの文書、未承認のドラフトなどが混じります。
こうしたノイズに LLM が引っ張られると、回答が崩れます。

具体例

たとえば、正しい情報とノイズが混ざる場合です。

user_input:
リモート勤務日の交通費は支給されますか？

retrieved_contexts:
- 2024年4月以降、リモート勤務日の交通費は支給しない。（正しい）
- （古い規程）在宅勤務でも交通費は一律で支給する。（ノイズ）

reference:
2024年4月以降、リモート勤務日の交通費は支給されません。

response:
リモート勤務でも交通費は一律で支給されます。

claims:
- リモート勤務日でも交通費が一律支給される → ×（reference と矛盾）

この場合、response が古い規程（ノイズ）に引っ張られ、唯一の claim が誤っています（誤り 1/1）。
誤りの割合が高いため、Noise Sensitivity は高い値になります（高いほど悪い）。

スコアが高い（悪い）ときに疑うべき項目

• retrieved_contexts の順位の悪さ
• 古い文書を除外できていないこと
• 正本とドラフトの区別ができていないこと
• 複数の retrieved_contexts の矛盾を LLM が処理できていないこと
  など

スコアを下げるための施策

• 文書の鮮度や正本フラグのメタデータ化
• ドラフトや廃止文書の除外
• リランキングの導入
• 矛盾時に断定しないプロンプト

5. Response Relevancy

Response Relevancy は、生成された回答が質問に関連しているかを見ます。
ここで大事なのは、この指標は回答の正確性を測らないことです。
回答から逆向きに質問を生成し直し、その質問が元の質問とどれだけ近いか、つまり埋め込みの cosine 類似度で測ります。
不完全な回答や余計な情報を含む回答は、減点されます。

• 対象：生成
• reference：不要
• LLM-as-a-judge：LLM + 埋め込みモデル

具体例

たとえば、次のような回答が返ってきたとします。

user_input:
パスワードの有効期限は何日ですか？

response:
パスワードは英数字をそれぞれ1文字以上含める必要があります。

generated_questions（response から逆生成）:
- パスワードに必要な文字種は？

この場合、response はパスワードの話ではありますが、聞かれた「有効期限」には答えていません。
逆生成された質問が元の user_input とズレるため、Response Relevancy は低い値になります。
なお、この指標は retrieved_contexts を使わず、user_input と response だけで測れます。

スコアが低いときに疑うべき項目

• 質問意図の取り違え
• 一般論への逃げ
• 回答形式をプロンプトで制御できていないこと
• 複合質問を分解できていないこと
• ユーザーの制約条件の取りこぼし
  など

スコアを上げるための施策

• 質問に直接答えてから補足する形式
• 回答テンプレートの利用
• 複合質問の分解

6. Faithfulness

Faithfulness は、生成された回答が retrieved_contexts に忠実か、つまり回答内の主張が retrieved_contexts で支持されているかを見ます。
回答を主張（claims）に分解し、各 claim が retrieved_contexts で裏付けられるかを判定して、支持された割合をスコアにします。
retrieved_contexts にない作り話、いわゆるハルシネーションを捉えるための指標です。

• 対象：生成
• reference：不要
• LLM-as-a-judge：LLM

具体例

たとえば、次のような回答が返ってきたとします。

user_input:
福利厚生に住宅手当はありますか？

retrieved_contexts:
当社では通勤手当、資格取得補助、育児支援制度を提供している。

response:
住宅手当は月3万円支給されます。

claims:
- 住宅手当が支給される → ×
- 支給額は月3万円 → ×

この場合、2つの claim がどちらも支持されないため（0/2）、Faithfulness は低い値になります。

スコアが低いときに疑うべき項目

• LLM が根拠なしに補完していること
• retrieved_contexts の不足
• プロンプトの制約の弱さ
• 一般知識の混入
  など

スコアを上げるための施策

• retrieved_contexts に基づく回答だけを許可
• 根拠がなければ「不明」と回答
• 引用の必須化
• 生成後の grounding check

マルチモーダルの2指標

MultiModalFaithfulness と MultiModalRelevance が提供されています。

似ている指標の関係性

Response Relevancy と Faithfulness の違い

この2つは混同しやすいですが、見ているものが違います。

指標	reference	見ること	低いとき
Response Relevancy	不要	質問に答えているか	回答が質問からズレている
Faithfulness	不要	コンテキストに忠実か	根拠にないことを言っている

さきほどの住宅手当の例で「住宅手当は月3万円あります」と答えると、質問には直接答えているので Response Relevancy は高くなりえます。
しかし retrieved_contexts にその根拠がなければ Faithfulness は低いままです。
逆に「当社では通勤手当、資格取得補助、育児支援制度を提供しています」と答えると、コンテキストには忠実なので Faithfulness は高いものの、住宅手当の有無に答えていないので Response Relevancy は低くなります。
質問に答えることと、コンテキストに忠実であることは、イコールではないのです。

Context Precision と Context Recall のトレードオフ

検索側のこの2つは、片方を上げるともう片方が下がりやすい関係です。

調整	Context Recall	Context Precision	補足
top-k を増やす	上がりやすい	下がりやすい	必要情報を拾いやすくなる一方、ノイズも混ざりやすい
top-k を減らす	下がりやすい	上がりやすい	ノイズは減りやすいが、必要情報を取り漏らす可能性がある
リランキングを入れる	基本は維持、構成次第で改善	上がりやすい	取得済み候補の並び替えが主効果。広めに取得してからリランキングすると効果が出やすい
メタデータフィルタを適切に使う	上がることもある	上がりやすい	不要範囲を除外できれば両方改善する可能性がある
メタデータフィルタを強めすぎる	下がりやすい	上がることがある	条件が厳しすぎると、正解チャンク自体を除外してしまう

片方だけを追うと失敗します。
Context Precision だけ高くても必要情報を取り漏らせば答えられませんし、Context Recall だけ高くてもノイズが多ければ LLM が誤ったコンテキストに引っ張られます。

スコアの組み合わせから読み取れること

指標の値は、単体でも原因のあたりをつける手がかりになります。

症状	疑わしい原因
Context Recall が低い	必要情報を検索できていない
Context Precision が低い	ノイズ文書が多い、順位が悪い
Context Entities Recall が低い	固有名詞や制度名を取り漏らしている
Noise Sensitivity が高い	ノイズに引っ張られている
Response Relevancy が低い	質問に対して回答がズレている
Faithfulness が低い	retrieved_contexts にないことを答えている

組み合わせて見ると、もう一段絞れます。

状況	解釈
Context Recall 低 ＋ Faithfulness 低	材料不足で LLM が補完している可能性が高い
Context Recall 高 ＋ Faithfulness 低	必要情報は取れているのに、根拠に忠実に答えていない
Context Precision 低 ＋ Noise Sensitivity 高	ノイズに引っ張られている
Faithfulness 高 ＋ Response Relevancy 低	コンテキストには忠実だが、質問に直接答えていない

スコアそのものより、こうやって失敗ケースを分類できることに価値があります。

Ragas でわからないこと

Ragas は便利ですが、万能ではありません。
特に、次のことはスコアだけでは保証できません。

• 業務的に正しいか
• 参照した文書が最新か
• 正本とドラフトを区別できているか
• 権限的に見せてよい情報か
• ユーザーにとって読みやすく、使えるか
• 本番運用で問い合わせ削減などの価値が出ているか

分かりやすい落とし穴が、古い規程の例です。
廃止済みの古い規程を取得し、その内容に忠実に答えた場合、Faithfulness は高くなりえます。
retrieved_contexts には忠実だからです。
それでも業務的には誤回答です。

つまり Ragas は、RAG の出力品質を観測するメーターであって、業務品質を保証する仕組みではありません。
特に LLM-as-a-judge 系の指標は、評価用 LLM の性能やプロンプトに依存するので、評価自体の相対比較を行う場合は、評価用 LLM、プロンプト、temperature、埋め込みモデル、Ragas のバージョン、評価データセットは固定しておいたほうがよいです。

実務での使い方

いきなり全社文書に対して回すより、小さな評価セットから始めるほうが現実的です。
小さく始めるなら30〜100件程度の小さな評価セットから始めると良さそうです。

Ragas の評価データセットは、サンプル（SingleTurnSample）を集めたもの（EvaluationDataset）です。
公式ドキュメントは、評価データセットを次の3要素で整理しています。

構成要素（公式の区分）	必須/任意	対応するフィールド
入力（Inputs）	必須	user_input（質問）。RAG を動かして retrieved_contexts と response も格納する
期待出力（Expected outputs）	任意	reference（期待回答や正解）
メタデータ（Metadata）	任意	文書 ID、難易度、カテゴリなど

実務では、先に user_input と reference を人手で用意し、response と retrieved_contexts は RAG システムを動かして埋めるのが定番です。

この reference の扱いが、指標選びと直結します。
データセット上の reference は任意ですが、Context Recall、Context Entities Recall、Noise Sensitivity を使うなら必須です。
逆に Faithfulness と Response Relevancy は、reference なしでも評価できます。検索結果の有用性を reference なしで見たい場合は、ContextUtilization などを検討します。
どの指標を見たいかを先に決めると、reference を用意すべきかが決まります。

データセットは、代表的な質問を選び、難易度を偏らせず、量より質を優先し、メタデータを添えておくと、後で分析しやすくなります。

指標は、最初から全部を追わなくてかまいません。
公式の howto は、用途に直結する指標から始め、改善は一度に1つだけ変えて同じデータセットで測り直すよう勧めています。

評価の流れは、おおむね次のようになります。

1. 評価用の質問（user_input）と期待回答（reference）を用意する
2. RAG システムに回答させる
3. user_input / response / retrieved_contexts / reference を保存する
4. Ragas で評価する
5. スコアが低いケースを人間が確認する
6. 失敗原因を分類する
7. チャンク、検索、プロンプト、データ整備のどれか一つだけを直す
8. 再評価する

このとき、評価ごとに次の情報も残しておくと、後で原因を追えます。
プロンプトのバージョン、Retriever のバージョン、埋め込みモデル、生成 LLM、Ragas のバージョン、タイムスタンプです。
これらがないと、スコアが動いても何の変更が効いたのか分からなくなります。

また、Ragas だけで完結させず、評価を層に分けて考えると整理できます。

レイヤー	評価内容	Ragas の出番
自動評価	Ragas、検索スコア、遅延、コスト	強い
人間レビュー	業務正確性、根拠の妥当性、リスク	代替できない
運用評価	満足度、再質問率、問い合わせ削減	代替できない

Ragas が強いのは自動評価の層です。
日本語の業務文書は、社内用語や例外条件、表形式データ、暗黙の前提が多く、自動評価だけだと取りこぼします。
重要なケースは人間レビューを併用するのが現実的です。

まとめ

Ragas は、RAG の品質を検索と生成に分解して観測するためのフレームワークです。
テキスト RAG で中心になる6指標は、次のように一言でまとめられます。

No.	指標	reference	一言でいうと
1	Context Precision	基本必要	余計な文書を上位に出していないか
2	Context Recall	必須	必要な文書を取り漏らしていないか
3	Context Entities Recall	必須	必要な固有名詞や重要語を取れているか
4	Noise Sensitivity	必須	ノイズに引っ張られていないか（低いほど良い）
5	Response Relevancy	不要	質問に対してズレていないか
6	Faithfulness	不要	retrieved_contexts にないことを言っていないか

これらを使うと、検索が悪いのか生成が悪いのか、必要コンテキストを取り漏らしているのか、ノイズに引っ張られているのか、といった切り分けができます。
一方で、業務的に正しいか、文書が最新か、正本を参照しているかは、スコアだけでは分かりません。
Ragas を自動診断のメーターとして使いつつ、人間レビューや文書管理、業務 KPI と組み合わせて運用するのが、現実的な落としどころだと思います。

参考文献

• Ragas 公式サイト

• 評価データセットの考え方

• RAG の評価と改善（howto）

• Ragas 初版論文：Es et al., "Ragas: Automated Evaluation of Retrieval Augmented Generation", arXiv:2309.15217