RAGの評価方法｜検索・回答・根拠を分ける測定設計

RAGの評価は、最終回答の正誤だけを採点しても改善箇所を特定できません。検索で必要文書を取れたか、取得文書に回答の主張が支えられているか、必要事項を満たしたか、業務で採用できたかを別々に測ります。この記事を読み終えた時点で作る成果物は、変更前後を同じ条件で比べられる「RAG評価票」です。

RAGの評価対象を4層へ分解する

RAGは、質問を受けて検索し、取得した文書をモデルへ渡し、回答を組み立てるシステムです。Lewisらの原著は、モデル内部の知識だけでなく、外部の非パラメトリックな記憶を検索して生成へ利用する構成を示しました^[1]。したがって、検索結果が欠けた失敗と、正しい根拠を受け取った後の生成失敗を一つの点数へ潰すと、修正対象を誤ります。

実務では、評価単位を「質問1件」とし、各質問を検索、根拠、回答、業務の4層で採点します。検索層では正解文書または正解チャンクが上位k件に入ったかを見ます。根拠層では回答中の事実主張を文書の該当箇所へ結び付けます。回答層では必須事項、禁止事項、保留判断を確認します。業務層では、担当者が事実修正なしで採用したか、確認時間が許容範囲かを記録します。

RAGASは、取得文脈の関連性、文脈に対する回答の忠実性、回答品質を異なる次元として扱う評価枠組みを提示しました^[2]。さらにRAGVUEは、検索品質、回答の関連性と完全性、主張単位の忠実性、判定器の校正を診断可能な項目へ分けています^[4]。本稿の4層は、これらの研究を日本企業の運用判定へ落とし込んだ編集上の提案であり、特定製品の標準スコアではありません。

総合点を出す前に、どの層で失点したかを必ず残します。検索が0点なのに回答表現を直す、または根拠違反があるのに検索件数だけ増やす、といった誤修正を防ぐためです。

比較可能なRAG評価データを用意する

評価データには、質問だけでなく、正解文書、根拠箇所、回答に必要な要素、回答してはいけない条件を持たせます。文書の版、公開日、権限区分も固定しなければ、検索設定の差なのか文書更新の差なのか判別できません。1回の評価中は、コーパスのスナップショット、インデックス作成日時、埋め込みモデル、検索パラメータ、再順位付け設定、生成モデル、指示文の版を変更しないことが基本条件です。

OpenAIの現行評価ガイドは、実運用データ、専門家が作った正解、過去ログを組み合わせ、通常例、境界例、敵対的な例を含めるよう勧めています。また自動判定は人のラベルとの一致を確認して校正する必要があると説明しています^[5]。この原則から、質問件数を無作為に増やすより、実際の問い合わせ構成を層別に再現する方が重要です。

初回の想定例として120件を作るなら、通常質問60件、言い換え・略語24件、根拠不足で回答保留すべき質問18件、改訂直後の文書12件、権限外文書を検索してはいけない質問6件とします。この配分は普遍的な推奨値ではありません。自社ログの比率を得た後は置き換えますが、低頻度でも影響が大きい権限違反と古い版の参照は意図的に残します。

正解ラベルは、文書所有者と業務利用者の二者で付けます。検索担当だけが正解を決めると、技術的に近い文書を正解としながら、現場では失効した規程だったというずれが起きます。二者が異なる判定をした質問は第三者が裁定し、裁定前の不一致も保存します。ARESは自動評価へ少量の人手注釈を組み合わせ、判定誤差を抑える設計を報告しています^[3]。自動採点器を採用する場合も、人手評価を完全に外す根拠にはなりません。

学習や調整に使う開発集合と、合否判定に使う保留集合は分離します。例えば120件のうち80件でチャンクや指示文を調整し、40件は最終判定まで内容を見ない方法です。同じ質問を見ながら設定を直し続けると、その質問だけに適合した数字になり、次の問い合わせへ一般化したか確認できません。

RAGの検索指標を計算する

検索層では、取得件数を増やしたこと自体を改善としません。上位k件の中へ必要な文書が入る割合、不要文書の混入、最初の正解が現れる順位を測ります。正解文書が複数ある質問では再現率が重要で、答えの根拠が一つに定まる質問では最初の正解順位が読みやすい指標になります。

Stanfordの情報検索テキストは、Precisionを取得文書のうち関連文書が占める割合、Recallを全関連文書のうち取得できた割合と定義しています^[6]。同テキストはPrecision@kについて、関連文書総数を見積もらずに使える一方、kと質問ごとの関連文書数に左右され、一般的な指標の中でも安定性が低いという限界を示しています^[7]。したがって、RAGでは一つの検索指標だけを合否に使いません。

基本式

Precision@k = 上位k件に含まれる正解チャンク数 ÷ k
Recall@k = 上位k件に含まれる正解チャンク数 ÷ その質問の正解チャンク総数
MRR = (1 ÷ 質問数) × Σ(最初の正解チャンク順位の逆数)
検索失敗率 = 正解チャンクが1件も取得されなかった質問数 ÷ 全質問数 × 100

想定例として、正解チャンクが3件ある質問で上位5件中2件が正解なら、Precision@5は2÷5=0.40、Recall@5は2÷3=0.667です。上位件数を10へ増やして3件すべてを取れたとしても、不要な7件が生成入力を圧迫するなら、Recall@10=1.00だけを見て採用してはいけません。トークン量、応答時間、根拠の混線を同時に比べます。

MRRは最初の正解へ早く到達するかを見る式です。4問の最初の正解順位が1位、2位、4位、正解なしなら、正解なしを0として、(1+0.5+0.25+0)÷4=0.4375になります。ただし最初の一件しか評価しないため、複数根拠を必要とする規程比較には向きません。その場合はRecall@kと、必須文書がすべてそろった質問の割合を併記します。

TrappoliniらのEACL 2026論文も、MRRは最初の関連文書の順位へ焦点を当てる指標だと整理しています。同論文は、従来の順位指標が人の閲覧行動を前提とするのに対し、RAGではLLMが取得文書全体を消費し、関連しそうで無関係な文書が回答を悪化させ得るため、検索指標だけでは最終回答を十分に予測できないと報告しています^[8]。このため本稿では、検索指標の後に主張支持率と回答完全性を必ず測ります。

検索スコアは方式間で直接比較できない場合があります。ベクトル類似度、キーワード検索、再順位付け後のスコアは尺度が異なるからです。閾値を調整する際は、同一方式・同一版の中で適合率と再現率の変化を見ます。方式を変えた比較では、最終順位と正解ラベルで判断し、値の大きさそのものを移植しません。

検索結果には文書IDだけでなく、チャンクIDと親文書IDを残します。同じ段落を重複分割した結果、Precision@kが高く見えることがあるためです。重複チャンクを一つの根拠として数える集計と、実際にモデルへ渡した件数の集計を分けると、索引の重複も検知できます。

根拠への忠実性と回答品質を別々に測る

回答層の評価では、文章全体へ一つの「正しい・誤り」を付けず、検証可能な事実主張へ分割します。例えば「申請期限は契約満了日の30日前で、例外はありません」という文には、期限と例外有無の二つの主張があります。正本が30日前を支えていても例外条項が存在するなら、支持主張は1件、全主張は2件です。

根拠・回答・保留の式

主張支持率 = 根拠箇所で支持できる事実主張数 ÷ 全事実主張数 × 100
引用正確率 = 表示した引用のうち直前の主張を支える引用数 ÷ 全引用数 × 100
必須要素充足率 = 回答に含まれた必須要素数 ÷ 正解票の必須要素総数 × 100
適切保留率 = 根拠不足ケースで断定せず保留した件数 ÷ 根拠不足ケース総数 × 100
事実無修正採用率 = 事実修正なしで業務利用できた回答数 ÷ 評価回答総数 × 100

想定例で、20回答に合計80の事実主張があり、72件を根拠で支持できた場合、主張支持率は72÷80×100=90%です。しかし支持できなかった8件のうち1件が権限外情報、7件が軽微な日付表記だったなら、同じ不支持として平均化すべきではありません。重大度を「情報漏えい・法務判断へ影響・金額や期限の誤り・その他」に分け、重大な1件は総合点と無関係に停止判定へ送ります。

必須要素充足率は忠実性とは別物です。根拠に反する内容がなくても、質問された申請先を省略すれば業務回答として不完全です。反対に、必須事項をすべて書いても、根拠にない補足を足せば忠実性で不合格になります。「余計な誤りがない」と「必要な情報がそろう」の両方を満たす必要があります。

根拠不足ケースでは、回答しない能力を測ります。正解データに「保留理由」と「追加で必要な情報」を持たせ、単に拒否しただけか、担当者が次へ進める保留かを区別します。適切保留率が高くても、回答可能な通常質問まで保留するなら有用性が落ちるため、通常質問の過剰保留率も計算します。

LLMを採点者にする場合は、主張と根拠を提示し、支持・矛盾・根拠不足の三択で判定させます。長い文章へ自由採点させるより、分類単位を狭くした方が検証しやすくなります。少なくとも保留集合の一部を人が二重採点し、モデル判定との一致率、偽合格、偽不合格を確認します。文字の流暢さを好む判定器が、根拠違反を見逃していないかを点検してください。

記事固有のRAG評価票で合否を決める

評価票は、検索、根拠、回答、業務を同じ行へ記録し、失敗した層をたどれる形にします。全体平均だけを先に出すと、権限外取得のような低頻度・高影響の事故が隠れます。先に必須ゲートを判定し、通過した場合だけ加重点を計算します。

以下は社内規程検索を想定した提案例です。合格値は実績ではなく、試行開始前に責任者が承認する初期値です。業務の損失が大きい場合は主張支持率と適切保留率を上げ、探索用途では再現率を重くします。評価後に合格値を動かすと都合のよい結果になるため、変更は次回の評価版として記録します。

加重点を使う場合の想定式は、検索25点、根拠30点、回答25点、業務20点です。例えば各層の達成率が88%、96%、92%、85%なら、0.88×25+0.96×30+0.92×25+0.85×20=90.8点です。ただし、権限外取得が1件、根拠不足の断定が1件、または重大な引用ずれが1件でもあれば、90.8点を採用根拠にしません。必須ゲートを先に適用します。

評価票には結果だけでなく、評価実行ID、コーパス版、検索構成版、生成モデル識別子、指示文の版、開始・終了時刻、判定者を含めます。再現できないスコアは変更承認に使えません。複数回実行して値が揺れる場合は、平均のほか最小値と標準偏差を記録し、偶然よかった実行だけを選ばないようにします。

RAGの変更後に同じ条件で再試験する

再試験では、直した失敗ケースだけでなく、以前合格していた対照ケースも回します。チャンクを短くして検索漏れを直した結果、規程の例外条件が別チャンクへ分断されることがあるためです。一度に変更する主要因は一つに絞り、変更前後で同じ保留集合を使います。コーパス更新も同時に必要なら、検索設定変更とは別の実行IDに分けます。

1. 失敗を固定する: case_id、取得順位、回答、根拠判定、ログを変更前の証拠として保存します。
2. 仮説を一つ書く: 例として「見出しと本文を別チャンクにしたため、期限の例外を取得できなかった」と記載します。
3. 対象部品だけ変える: 分割規則を変える試験では、モデル、指示文、検索上位件数を固定します。
4. 失敗集合を再実行する: 修正成功率を、合格へ変わった失敗ケース数÷修正対象ケース数で求めます。
5. 対照集合を再実行する: 回帰率を、以前合格して今回不合格になった件数÷以前の合格件数で求めます。
6. 保留集合で判定する: 調整に使っていない質問で必須ゲートと各指標を確定します。

想定例として、失敗20件のうち16件が合格へ変われば修正成功率は80%です。一方、以前合格していた80件のうち4件が不合格になれば回帰率は5%です。「16件改善した」という報告だけでは、4件の新しい失敗を隠します。重大な回帰が含まれる場合は件数が少なくても差し戻します。

評価実行ID: rag-regression-2026-07-30-b
変更仮説: 見出しを親情報として各チャンクへ付与すれば規程名の検索漏れが減る
固定条件: corpus_2026-07-15 / top_k=5 / reranker_v3 / prompt_12
変更条件: chunker_7 から chunker_8
修正成功率: 16 / 20 = 80%
回帰率: 4 / 80 = 5%
必須ゲート: 権限外取得0件、重大な根拠矛盾0件
判定: 回帰4件の原因を直して再試験

本番へ出す前は、同じ設定で少なくとも複数回実行し、非決定性による振れを見ます。本番後は実問い合わせから新しい失敗を評価集合へ追加しますが、過去の固定集合を削らず、追加した版を残します。これにより、直近の問題へ適応しながら以前の能力を維持できたかを確認できます。

RAG評価を停止・保留し専門担当へ引き継ぐ条件

評価を続けても意味がない条件と、運用を直ちに止める条件は分けます。正解文書の版が不明、質問に対応する根拠箇所を専門家が決められない、実行途中でコーパスが更新された場合は「評価無効」として保留します。数値を出せても比較条件が崩れているため、設定の良し悪しを結論にしません。

点数に関係なく停止する条件

• 評価利用者の権限外にある文書IDまたは本文が一件でも取得された。
• 法務、金額、契約期限、安全に関する主張が根拠と矛盾した。
• 根拠不足ケースで、存在しない資料名や条項を生成して断定した。
• 検索ログと回答ログを同じcase_idで結べず、事故経路を追跡できない。
• 個人情報または機密情報を匿名化していない評価データが外部環境へ送られた。

権限外取得は検索基盤と情報セキュリティへ、正本文書の判断不能は文書所有者へ、法的解釈の不一致は法務へ引き継ぎます。引継ぎ票には評価実行ID、case_id、再現手順、取得文書ID、画面へ表示された範囲、発見時刻、暫定措置を記載します。回答文だけを渡すと、検索フィルタ、キャッシュ、生成工程のどこで問題が起きたか再現できません。

この評価方法が向かないのは、正解を定義できない創作支援、探索範囲そのものを広げることが目的の調査、利用者ごとに正解が変わる相談です。その場合は、正解一致率より、多様性、人の比較選好、発見した論点の有用性など別の評価設計が必要です。また、母集団が数件しかなく正解文書も頻繁に変わる段階では、精密な百分率よりケースレビューを優先します。

停止後の再開条件も明示します。権限フィルタを直しただけでは足りず、停止ケース、同じ権限階層の横展開ケース、過去に合格した対照ケースを再試験し、権限外取得0件を確認します。重大事故では情報セキュリティ責任者が再開を承認し、評価担当だけで本番へ戻さない運用にします。

RAG評価の数値から改善箇所を選ぶ

数値を集めた後は、最も低い指標を機械的に直すのではなく、失敗の組み合わせから担当層を選びます。Recall@5が低く主張支持率も低い場合、生成側だけを調整する前に検索漏れを直します。Recall@5は高いのに主張支持率が低い場合、取得文書の並べ方、指示文、引用対応、モデル出力を調べます。

優先順位は、重大度、発生件数、修正の確からしさで決めます。想定式として「優先度=重大度1〜5×発生件数×原因確度0〜1」を使えます。例えば期限誤りが重大度5、6件、原因確度0.8なら24です。表記不足が重大度1、30件、原因確度0.9なら27ですが、必須ゲートへ関わる期限誤りを先に扱うという上位規則を設けます。

最終報告には、総合点より先に「どの層が、どの条件で、何件失敗したか」を書きます。その後に修正仮説、担当者、再試験対象、停止条件を続ければ、開発者と業務責任者が同じ証拠で判断できます。049の読後行動は、この形式で自社の評価票を一版作り、変更前のベースラインを採ることです。

RAG評価を始める次の行動

実問い合わせから通常、言い換え、根拠不足、更新、権限の5区分を抽出し、まず20件で評価票の記入可否を試してください。正解文書と根拠箇所を二者で確定できたら件数を増やし、検索・根拠・回答・業務のベースラインを保存します。20件の内訳は、通常8件、言い換え4件、根拠不足3件、更新3件、権限2件という想定から始められますが、実際の問い合わせ構成と重大リスクに合わせて変更します。

最初の実行ではシステムを採点する前に、評価票そのものを点検します。二人の判定者が同じ5件を独立に採点し、主張の切り方、正解文書、保留理由が一致しない箇所を洗い出します。一致件数÷二重採点件数で単純一致率を求め、5件中4件なら80%です。この値をシステム精度と混同せず、判定基準を直す材料にします。

評価票が埋まらないケースは無理に0点にせず、「正解未確定」「ログ不足」「権限条件不明」に分けて保留します。20件すべてでcase_idから検索ログ、取得チャンク、回答、採点理由まで追跡でき、二者が正解を説明できた時点をデータ準備の完了とします。その後に固定集合を80件、保留集合を40件へ拡張し、変更前の値を正式な比較基準として版管理します。

評価の初版では、平均値だけでなく分母の偏りも確認します。特定部署の問い合わせが80件中60件を占めるなら、全体点が改善しても少数部署の失敗を隠すおそれがあります。部署、文書種別、権限、質問難度ごとに件数と合格率を併記し、10件未満の区分は参考値として扱います。母数を満たせない区分は追加収集へ回し、運用開始の判断材料から外すことで、偶然の数件を品質保証と誤認しません。

初回報告には、総合点ではなく、各層の母数、式、未採点数、重大失敗、利用した構成版を記載します。次の改善を一つ選び、失敗集合と対照集合の再試験日を決めれば、測定が一度きりの採点ではなく継続的な品質管理として動き始めます。

参考文献・出典

1. Patrick Lewis et al. 原著論文「Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks」NeurIPS 2020（公開年: 2020年、参照日: 2026年7月30日）
2. Shahul Es et al.「RAGAs: Automated Evaluation of Retrieval Augmented Generation」EACL 2024 System Demonstrations, pp.150-158（公開: 2024年3月、参照日: 2026年7月30日）
3. Jon Saad-Falcon et al.「ARES: An Automated Evaluation Framework for Retrieval-Augmented Generation Systems」NAACL 2024, pp.338-354（公開: 2024年6月、参照日: 2026年7月30日）
4. Keerthana Murugaraj et al.「RAGVUE: A Diagnostic View for Explainable and Automated Evaluation of Retrieval-Augmented Generation」EACL 2026 System Demonstrations（公開年: 2026年、参照日: 2026年7月30日）
5. OpenAI「Evaluation best practices」（継続更新ページ、版表記なし。2026年7月30日時点の内容を参照）
6. Christopher D. Manning, Prabhakar Raghavan, Hinrich Schütze「Evaluation of unranked retrieval sets」Introduction to Information Retrievalオンライン版（Cambridge University Press、2009年、2026年8月4日参照）
7. Christopher D. Manning, Prabhakar Raghavan, Hinrich Schütze「Evaluation of ranked retrieval results」Introduction to Information Retrievalオンライン版（Cambridge University Press、2009年、2026年8月4日参照）
8. Giovanni Trappolini et al.「Redefining Retrieval Evaluation in the Era of LLMs」EACL 2026 Long Papers, pp.8359-8375（2026年3月公開、2026年8月4日参照）