RAG評価とは？検索と生成を分けて測る指標・Ragasでの実装・運用への組み込み【2026年版】

RAG評価とは、検索で持ってきた文脈と、その文脈をもとに生成した回答を別々に採点し、品質が落ちた原因がどちらの側にあるのかを切り分ける作業です。社内文書を読ませたチャットボットが的外れな回答を返したとき、原因が「必要な文書を引けていない」のか「引けているのに読み違えている」のかで、打つ手はまったく変わります。本記事では定義を押さえたうえで、主要指標が何を計算しているのか、Ragasをはじめとするツールで何を用意すれば回るのか、そして自動採点にどこまで任せてよいのかを実装目線で整理します。

まとめ：RAG評価の要点と、自動化の線引きを先に示す

先に結論を述べます。RAG評価の骨格は4つの指標です。検索側をContext Precision（関連する文脈が上位に来ているか）とContext Recall（必要な文脈を取りこぼしていないか）で測り、生成側をFaithfulness（回答が文脈に裏づけられているか）とResponse Relevancy（質問に答えているか）で測ります。この4つを同時に見ると、故障箇所がほぼ一意に定まりました。

実装面では、2026年7月時点でPyPIの最新版が0.4.3系のRagasが標準的な出発点になります。ただし0.3系から0.4系にかけてクラス名や引数の呼び方が整理されており、ネット上のサンプルコードはそのままでは動かない場合があるため、公式ドキュメントの版を必ず合わせてください。

そして判断です。自動評価は「前回より下がっていないか」を検知する回帰テストとして使ってください。一方、何点なら本番へ出してよいかという合否ラインの決定と、業務上の致命傷（法令解釈の誤りなど）の判定は人手に残すべきです。理由は後段の独自章で条件付きに述べます。

RAG評価とは？検索フェーズと生成フェーズを切り分けて測る考え方

RAG評価の定義と、単一の正答率だけでは改善に踏み出せない理由

RAGは、質問に関連する文書をデータベースから検索し、それを文脈としてLLMへ渡して回答させる構成です。仕組みそのものはRAGとは？仕組みとLLM・ファインチューニングとの違い・企業での導入例を解説で扱っていますので、前提が曖昧な場合は先にそちらをご覧ください。

評価の対象は、この2段構成に対応して2層あります。検索器がどんな文脈を返したかという層と、その文脈からLLMが何を書いたかという層です。ここを分けずに「回答の正答率80%」という1つの数字だけを追うと、次の一手が決まりません。正答率が70%へ落ちたとき、検索器のインデックスを作り直すのか、プロンプトを書き直すのか、根拠なく両方に手を入れることになります。切り分けができていない評価は、数字を出しているようで意思決定を何も助けないのです。

4つの主要指標が診断する、RAGの典型的な故障モードの切り分け

各指標は0から1の範囲で出力され、それぞれ別の故障モードに対応しています。Context Recallが低ければ、答えの根拠になる文書がそもそも検索結果に入っていません。Context Precisionだけが低い場合は、関連文書は入っているものの、ノイズに埋もれて順位が低い状態です。Faithfulnessが低ければ、文脈は正しいのにLLMが文脈にない内容を書き足しています。Response Relevancyが低いなら、内容は正しくても質問の焦点からずれた回答になっているわけです。

検索側の数値が悪いと分かったなら、打ち手は文書の分割方法と検索方式に集約されます。分割の粒度はチャンク分割とは？チャンクとトークンの違いから代表的な手法まで解説で、キーワード検索とベクトル検索の併用はハイブリッド検索とは？RAGでBM25とベクトル検索を統合する仕組み・RRF・実装コードで具体的に扱っている内容です。生成側であれば、AIハルシネーション対策｜プロンプト・RAG・検出APIで誤答を減らす実装手順の方向へ進むことになります。

RAG主要指標の意味と計算式を実装の単位へ分解して読み解く手順

検索側の指標：Context PrecisionとContext Recallの読み方

Context Precisionは、検索で返ってきた文脈のうち関連するものが上位に置かれている度合いを表します。公式ドキュメントの定義では、順位kごとのPrecision@kに、その順位の文脈が関連しているかを示す0か1の値を掛けて足し合わせ、上位K件に含まれる関連文脈の総数で割ります。順位が効く点が特徴で、無関係な文脈が1位にあるとスコアは大きく削られ、同じものが2位以下にあると影響は小さくなる設計でした。

Context Recallは逆に、答えるために必要だった情報のうち、どれだけが検索結果へ含まれていたかを見ます。こちらは順位を問いません。実務での読み方としては、Recallが低いのにPrecisionが高い状態が最も危険です。検索器が「自信のある少数の文書」だけを返しており、そこに答えがない場合、生成側は文脈に忠実なまま誤った回答を返します。Faithfulnessは高いのに人間が見ると間違い、という現象はほぼこの組み合わせから生じました。

この2つは取得件数（top_k）を通じて綱引きの関係にあります。件数を増やせばRecallは上がる一方、無関係な文書が混ざってPrecisionは下がり、LLMへ渡すトークン量と費用も増えていきます。実装の順序としては、まず件数を多め（20件程度）に取ってRecallの上限を確認し、そこからリランカーで上位を絞り込んでPrecisionを回復させる進め方が扱いやすいでしょう。件数を変えずに埋め込みモデルだけ差し替えて改善を試みると、どちらの指標が動いたのか分からなくなるため、変更は一度に1要素へ限定してください。

生成側の指標：FaithfulnessとResponse Relevancyが測るもの

Faithfulnessは、生成された回答を個々の主張（claim）へ分解し、それぞれが与えられた文脈から導けるかを判定して、導ける主張の割合を返します。文書に書いていない数値や固有名詞を書き足すと、この値が下がる仕組みです。0から1のスケールで運用され、一般には0.85前後を下限の目安に置く現場が多いものの、この閾値は業務のリスク許容度で決めるべき値であり、外部の数字をそのまま持ち込むものではありません。

Response Relevancyは、生成した回答から逆に質問を復元させ、元の質問との意味的な近さを測ります。回答が冗長だったり、聞かれていない前置きが長かったりすると値が落ちる性質があるため、文章量の設計を見直す合図として使えます。なお、こうした採点はいずれもLLMに判定させる方式で、その土台となる考え方はLLM-as-a-Judgeとは何か？AIモデルを評価者にする最新の自動評価手法の概要と仕組みを徹底解説で整理しました。

ノイズ感度と参照なし評価：正解データが揃わない場合の代替手段

Ragasは主要4指標のほかに、Context Entities Recall（固有表現の取りこぼし）やNoise Sensitivity（無関係な文脈に引きずられる度合い）といった補助指標も持ちます。加えて、LLMを使わないBLEUやROUGE、文字列の完全一致や部分一致による比較も同じインターフェースで扱えるため、決まった定型文を返すべき質問だけは非LLM指標で厳密に判定する、という混在運用も組めるのです。

検索と生成を分けて診断するという発想を、専用の枠組みとして実装した例がRAGCheckerとは｜RAGを検索と生成に分けて診断するAmazonの評価フレームワークです。ハルシネーションの有無に絞って測りたい場合は、注釈済みのデータセットを使うRAGTruthとは｜RAGのハルシネーションを検出するACL 2024評価データセットを解説の方式が参考になります。

評価データセットの作り方：件数・分布・正解の粒度をどう決めるか

初回は50〜100問から始め、失敗ログで育てる運用サイクルの設計

評価の質はデータセットで決まります。とはいえ最初から網羅的なものを作る必要はありません。実務では、想定質問を50問から100問ほど用意し、そこへ本番で実際に失敗した質問を毎週足していく形が回りやすいと考えています。件数より分布のほうが効きます。単一文書で答えられる質問、複数文書をまたぐ質問、答えが存在しない質問（「情報がない」と返すべき質問）の3種類を必ず混ぜてください。

3つ目を入れる理由は、RAGの事故の多くが「答えがないのに何か答えてしまう」形で起きるからです。この種の質問を評価セットに入れておかないと、どれだけ指標が高くても本番で同じ失敗を繰り返します。データ整備から本番運用までの流れ全体はRAG構築の手順とは？データ整備から精度向上・本番運用までの進め方で扱っているため、評価を組み込む位置の参考にしてください。

正解文の有無で変わる指標の変種と、選び分けの実務上の判断基準

Context Precisionには複数の実装が用意されており、手元にあるデータで選び分けます。正解文（reference）が用意できるならLLMContextPrecisionWithReference、正解文がなく生成された回答しかない場合はLLMContextPrecisionWithoutReference、正解となる文脈そのものが手元にあるなら文字列類似度で判定するNonLLMContextPrecisionWithReferenceという整理です。

最後の非LLM版は判定コストがほぼゼロで再現性も高く、大量の回帰テストへ向きます。逆にLLM判定版は柔軟ですが、判定側モデルの版が変わるとスコアも動くため、比較したい実験の間は判定モデルを固定しておく運用が前提になるでしょう。

正解文の粒度も決めておく項目です。1文で言い切れる短い正解文にすると採点は安定する反面、実際の回答が持つべき網羅性を測れません。逆に長い模範解答を置くと、表現の違いで不当に減点されがちです。運用しやすいのは、正解文を「回答へ必ず含まれるべき事実の箇条書き」として持つ形で、これならFaithfulnessの主張分解とも粒度が揃い、レビュー担当者が増えても判断がぶれにくくなります。

評価ツールの選び分け：Ragas・DeepEval・マネージド評価の比較

Ragasで最小構成の評価を回すときの入力データと実行の流れ

Ragasに渡すのは、質問・検索された文脈のリスト・生成された回答・（あれば）正解文という4項目です。つまり評価を始める前に、既存のRAGパイプラインから「実際に検索された文脈」をログとして取り出せるようにしておく必要があります。ここが未実装のまま評価だけ導入しようとして止まる案件が少なくありません。

from ragas import evaluate
from ragas.metrics import Faithfulness, LLMContextRecall

result = evaluate(dataset, metrics=[Faithfulness(), LLMContextRecall()])
print(result)

クラウド事業者のマネージド評価を選ぶ条件と、自前実装との境目

AWSのAmazon Bedrockには評価ジョブの仕組みがあり、検索のみを対象とする「retrieve only」と、検索から回答生成までを対象とする「retrieve and generate」の2種類を選べます。評価者となるモデルを一覧から指定し、組み込み指標に加えてカスタム指標も定義できる構成です。自社の知識ベースがすでにその基盤上にあるなら、評価用のコードを書かずに済む分だけ導入は速くなります。

DeepEvalはPyPI上で4.1系が配布されており、テストコードとして評価を書く思想が特徴です。指標の呼び名はRagasと重なる部分が多いものの実装は別系統のため、両者のスコアを直接比べないよう気をつけてください。

どこまで自動評価へ委ね、どこに人手を残すかの判断基準を言い切る

ここが本記事の主張です。自動評価を採用すべき条件は3つあります。第1に、検索の設定変更やモデル差し替えを月に何度も行う運用であること。第2に、検索された文脈をログとして保存できていること。第3に、失敗の判定基準が「文脈に書いてあるかどうか」で説明できる領域であること。この3つが揃うなら、評価を自動化した投資は回収できます。

逆に見送るべき場面も明確です。質問の種類が10通り程度に固定されている社内ツールでは、評価基盤を組むより担当者が毎回目視するほうが速く、指標のチューニングに費やす時間のほうが高くつきます。また、医療・法務・税務のように「文脈に忠実でも解釈が誤りなら事故」という領域では、Faithfulnessが1.0でも安全性の証明になりません。この場合の自動評価は、人手レビューへ回す候補を絞り込む前段としてのみ機能します。

実務上の折衷案として推奨するのは、二段構えです。全件を自動評価にかけ、Faithfulnessや検索側の指標が閾値を下回った回答だけを人手レビューへ送ります。全件目視から「下位20%の目視」へ縮められれば、レビュー工数は現実的な水準へ収まるはずです。合否ラインそのものは、事故が起きたときの損害の大きさから逆算して決めてください。指標は判断材料であり、判断そのものではありません。

なお、評価の設計をRAG構築と切り離して後から足すと、ログ取得の改修が発生して手戻りになります。設計段階から評価まで含めて相談したい場合はRAG構築支援でご相談ください。

運用への組み込み：CIでの回帰検知と本番モニタリングの設計指針

評価は一度回して終わりではありません。プロンプトを1行変えただけで別の質問群のスコアが落ちる、という現象が日常的に起きます。そこで、評価セットに対する実行をCIへ組み込み、主要指標が前回比で一定以上下がったらマージを止める形にしておきます。LLM判定は実行時間と費用がかかるため、全件は日次バッチ、プルリクエスト時は非LLM指標と少数のサンプルのみ、といった二層構成が現実的でしょう。

費用の見積もりも設計に含めてください。LLM判定の指標は、1件の採点で判定用モデルへ複数回の推論を投げます。主張の分解と検証を分けて行うFaithfulnessは特に回数が増えやすく、100問の評価セットに対して4指標を回すだけでも数百回規模の呼び出しになる計算です。ここを把握しないままCIの全プルリクエストへ組み込むと、開発が進むほど評価費用が膨らむ構造ができあがります。日次バッチと差分実行を分ける設計は、精度のためではなく費用の制御のために必要な措置でした。

本番側では、正解文が存在しないため参照なしの指標を使います。検索された文脈と生成された回答だけで計算できるFaithfulnessやResponse Relevancyを、全リクエストではなくサンプリングして測り、日ごとの推移を監視します。文書が追加・更新された直後にContext Precisionが落ちる、といった因果は推移グラフでしか見えません。評価の値そのものより、いつ何を変えたかという変更履歴と並べて読むことに意味があります。

よくある質問

RAG評価の指標は何点あれば合格ですか？

業種と用途で変わるため、絶対的な合格ラインはありません。目安としてFaithfulnessは0.85前後を下限に置く例が多いものの、これは参考値です。自社で決める際は、まず現行の運用でスコアを測り、その値を基準線として「下げない」ことから始めるほうが実務に合います。

評価用のLLMは回答生成に使うモデルと同じで構いませんか？

同じモデルでも動きますが、自分の出力を自分で採点する形になるため甘い評価へ傾きやすくなります。可能であれば判定側は別系統のモデルを指定してください。少なくとも、判定モデルの版は実験期間中に変えないことが比較の前提になります。

正解データを作る工数が確保できません。始められますか？

参照なしの指標だけなら開始できます。FaithfulnessとResponse Relevancy、参照なし版のContext Precisionは、質問・文脈・回答の3点があれば計算できるためです。まずこの3指標で推移を見ながら、失敗した質問に対してだけ正解文を後追いで整備していく順序を推奨します。

Context RecallとContext Precisionはどちらを先に見るべきですか？

Context Recallが先です。必要な文脈が検索結果に入っていなければ、順位を整えても回答は改善しません。Recallを引き上げてからPrecisionの改善へ移る順序が、手戻りの少ない進め方になります。

評価はどのくらいの頻度で回すのが妥当ですか？

変更のたび、が原則です。プロンプト・検索設定・モデル・文書のいずれかを触ったら回します。加えて、何も変えていなくても週次で回しておくと、外部APIのモデル更新による静かな劣化を検知できます。

関連記事

• RAGとは？仕組みとLLM・ファインチューニングとの違い・企業での導入例を解説
• RAG構築の手順とは？データ整備から精度向上・本番運用までの進め方
• RAGCheckerとは｜RAGを検索と生成に分けて診断するAmazonの評価フレームワーク
• RAGTruthとは｜RAGのハルシネーションを検出するACL 2024評価データセットを解説
• LLM-as-a-Judgeとは何か？AIモデルを評価者にする最新の自動評価手法の概要と仕組みを徹底解説
• ハイブリッド検索とは？RAGでBM25とベクトル検索を統合する仕組み・RRF・実装コード
• チャンク分割とは？チャンクとトークンの違いから代表的な手法まで解説
• AIハルシネーション対策｜プロンプト・RAG・検出APIで誤答を減らす実装手順