RAGの評価は「探せたか」と「資料の通りに答えたか」を別々に測る：RAGASと各社の文書で確かめる

この記事は、実際に使って確かめた記録ではありません。この記事は公式の文書や論文を読んでまとめたものです。

先に結論

• 「答えが変だ」と感じたとき、原因は大きく2つあります。必要な資料を取ってこられなかった（探す側の失敗）。資料はあったのに、それを使わず、あるいは資料にないことを書いた（答える側の失敗）。この2つは、直し方がまったく違います。
• RAGASの文書は、この2つを別々の指標に分けています。探す側はContext Precision（取れた資料のうち、関係あるものが上位に並んでいるか）とContext Recall（必要な情報が取れているか）。答える側はFaithfulness（答えが取れた資料で裏づけられるか）とResponse Relevancy（答えが質問に合っているか）です。
• 見立てです。最初の10〜20問は、指標のライブラリを入れる前に、手で「正解の資料はどれか」を決めて、取れたかどうかを数えるのが近道だと思います。指標の自動計算は、その後に人間の判断と合わせて確かめてから使うほうが安全です。

前提：RAGと、評価に出てくる言葉

RAG（検索拡張生成）は、質問に関係する資料をまず探し（検索）、その資料をAIに渡して答えさせる（生成）方式です。長い社内文書をAIに読ませたいときによく使われます。

• チャンクは、資料を一定の長さに区切った断片です。検索の単位になります。
• 適合率（precision）は、「取ってきたもののうち、正しいものの割合」です。
• 再現率（recall）は、「取るべきもののうち、実際に取れた割合」です。
• LLM-as-a-judgeは、AIに採点をさせる方法です（次の記事で詳しく扱います）。

RAGASの論文（arXiv 2309.15217）は、RAGの評価が難しい理由を、見るべき面が複数あるためだと述べています。論文が挙げる面は、取った資料が関係あって絞れているか、LLMがその資料を忠実に使えているか、生成そのものの質です。

2つの段階と、4つの指標

RAGASの公式文書の説明を、表にまとめました。指標は、おおむね0から1の範囲です（NoiseSensitivityだけ、低いほうがよい。Response Relevancyは、文書によると0から1に収まるとは限りません）。

ここで大事な点が3つあります。

1. Faithfulnessは「正しいか」ではなく「資料の通りか」です。 公式の式は、「答えの中の主張のうち、取れた資料から導ける数」÷「答えの中の主張の総数」です。資料自体が古ければ、資料の通りに答えても、現実とは違います。
2. Response Relevancyは、事実の正しさを評価しません。 文書は、質問の意図に合っているか、余計な内容や不足がないかを見ると説明しています。答えから「想定質問」を3つ作り、元の質問との意味の近さ（埋め込みの類似度）を測る方式です。
3. Context Recallは、正解がないと計算できません。 参照回答を主張に分け、各主張が取れた資料の中で裏づけられるかを確認します。したがって、評価用の「正解つきの質問」を作る手間は避けられません。

「探す」だけを測る別の方法

Anthropicの「Contextual Retrieval」の記事は、探す段階の失敗を1 − recall@20で測っています。つまり、上位20件に正解の資料が入らなかった割合です。同じ記事の数字は、埋め込みだけの場合の失敗率が5.7%、文脈をつけた埋め込みとBM25（単語の一致による検索）を組み合わせた場合が2.9%、さらに再順位付け（reranking、取った候補を並べ直す処理）を加えた場合が1.9%でした。これはAnthropicが自分たちのデータで測った数字で、他のデータにそのまま当てはまるとは限りません。

見立てです。この方式の良いところは、AIによる採点を使わないことだと思います。「この質問の正解はこの資料」と決めておけば、取れたかどうかは機械的に数えられます。判定のぶれが入りません。

AIの判定器そのものを作る方法もあります。ARES（NAACL 2024の論文、arXiv 2311.09476）は、資料の関連性、答えの忠実性、答えの関連性を測るために、自分で作った合成データで軽量な判定用モデルを学習させ、少数の人間の注釈で誤りを補正する方式です。論文の抄録によると、人間の注釈は数百件で足りるとされています。ただし、この記事は、実際に使って確かめた記録ではありません。

評価セットの作り方

OpenAIの評価の文書は、資料に対する質問応答（Q&A over docs）の評価設計の例として、次を挙げています。

• データは、実際の利用（ユーザーの満足度）、専門家が作った正解つきの質問、過去のログを混ぜる。
• 指標の例として、「context recallが0.85以上、context precisionが0.7超、肯定的に評価された回答が70%以上」を挙げています。これは「こういう設計もありうる」という例で、推奨値ではありません。
• テストデータには、典型的な例、境界の例、悪意のある入力の例を入れる。

RAGASには、評価用の質問を資料から自動で作る機能（testset generation）があります。公式文書は、1つの資料で答えられる質問（single-hop）と、複数の資料を結びつける必要がある質問（multi-hop）を区別しています。見立てです。自動生成の質問は、最初の足がかりに使い、中身を人間が読んで、正解の資料を確認してから評価に使うのが安全だと思います。

切り分けの表（見立てです）

見立てです。症状から、どちらの段階を疑うかを整理します。

よくあるつまずき

• AIの判定をそのまま信じる。 RAGAS論文のWikiEval（50のWikipediaページから作った評価用データ）では、人間の判断との一致率（2つの答えの比較で、どちらがよいか）が、忠実性0.95、答えの関連性0.78、取った資料の関連性0.70でした。論文は、資料の関連性を評価するのが最も難しい、と述べています。判定用のAIや条件が変われば、この数字も変わる可能性があります。
• 平均点だけを見る。 平均が上がっても、特定の質問の型（日付、表、複数資料にまたがる質問）で下がっていることがあります。質問を型で分けて集計してください。
• 評価セットが実際の質問に似ていない。 OpenAIの文書は、実際の利用の分布を再現しないデータで評価を作るのを、アンチパターンとして挙げています。
• 採点の方法を最初から重くする。 Anthropicの文書は、採点方法を選ぶとき、最も速く、確実で、拡大しやすいものを選ぶよう勧めています。文書は、コードによる判定（完全一致や文字列の一致）は最も速く確実、人間による判定は柔軟だが遅く高価で「できれば避ける」、AIによる判定は速く柔軟だが先に信頼性を確かめてから広げる、と説明しています。取れた資料の確認は、まずコードで足ります。
• 正解の資料を決めずに指標だけを回す。 正解がないと、Context Recallなどは計算できません。
• 資料の区切りを変えたのに、正解の資料の指定を直さない。 区切りが変わると、同じ質問の「正解の断片」が変わります。断片の番号ではなく、元の文書の位置や見出しで正解を決めておくと、区切りを変えても使えます（見立てです）。

気をつけること

• この記事は、実際に使って確かめた記録ではありません。式と説明は、公式文書に書かれたものの紹介です。
• RAGASのライブラリのバージョンは、PyPIで最新が0.4.3（2026年1月13日公開）でした（10月22日も同じ）。指標のページには、旧い書き方（legacy API）について「0.4で非推奨、1.0で削除」とあり、新しい書き方（collections）が推奨されています。Response Relevancyは、旧い書き方ではResponseRelevancy、新しい書き方ではAnswerRelevancyという名前だと、ページに書かれていました。記事の指標名は文書のページ名に合わせています。使うバージョンで書き方を確かめてください。
• 指標の値は、判定に使うAIのモデルやプロンプトで変わります。モデルを替えたら、同じ質問での点を比べ直してください。
• RAGAS論文の数字（0.95、0.78、0.70）は、2023年当時の評価で、50ページ分の英語のデータでの結果です。日本語や最近のモデルでの結果は、確認できていません。
• Anthropicの失敗率（5.7%など）は、同社が選んだデータでの数字です。
• 評価の文書にあるしきい値（0.85など）は、例です。自分の業務に必要な水準は、自分で決める必要があります。
• 出典のうち、Noise Sensitivityのページ、RAGASの論文、ARESの論文は、10月22日に取り直していません。確認日は10月8日のままです。
• 個人情報や機密を含む資料で評価する場合、判定用のAIに資料を送ることになります。送ってよいかは、契約や社内規則で確認してください。

出典

• Available Metrics（Ragas Documentation、Ragas、2026年10月22日確認）
• Faithfulness（Ragas Documentation、Ragas、2026年10月22日確認）
• Context Precision（Ragas Documentation、Ragas、2026年10月22日確認）
• Context Recall（Ragas Documentation、Ragas、2026年10月22日確認）
• Response Relevancy（Ragas Documentation、Ragas、2026年10月22日確認）
• Noise Sensitivity（Ragas Documentation、Ragas、2026年10月8日確認）
• Testset Generation for RAG（Ragas Documentation、Ragas、2026年10月22日確認）
• Ragas: Automated Evaluation of Retrieval Augmented Generation（arXiv 2309.15217、2026年10月8日確認）
• ARES: An Automated Evaluation Framework for Retrieval-Augmented Generation Systems（arXiv 2311.09476、2026年10月8日確認）
• ragas（PyPI、2026年10月22日確認）
• Introducing Contextual Retrieval（Anthropic、2026年10月22日確認）
• Evaluation best practices（OpenAI API、OpenAI、2026年10月22日確認）
• Define success criteria and build evaluations（Claude Platform Docs、Anthropic、2026年10月22日確認）

更新履歴

• 2026年10月25日 書き方を直しました。

  • 前：運営者が使っていないと読める書き方 → いま：「この記事は、実際に使って確かめた記録ではありません」。公式の資料を読んでまとめた記事で、使い心地は書いていない、という意味に直した

• 2026年10月22日 公式の資料を読み直して、次の点を直しました。

  • 前：RAGASの指標はどれも0から1の範囲 → いま：おおむね0から1。Response Relevancyは0から1に収まるとは限らない
  • 前：Faithfulnessは正解（reference）が不要 → いま：文書の例では正解を使っていない
  • 前：採点方法はコード、AI、人間の順に勧められる → いま：人間は柔軟だが遅く高価で「できれば避ける」、AIは先に信頼性を確かめてから広げる
  • 前：RAGASの書き方は新旧が混在している → いま：旧い書き方は0.4で非推奨、1.0で削除。新しい書き方が推奨されている
  • 前：（名前の違いの記載なし） → いま：Response Relevancyは旧い書き方でResponseRelevancy、新しい書き方でAnswerRelevancy