今回の論文
今回取り上げるのは、Shahul Es、Jithin James、Luis Espinosa-Anke、Steven Schockaertによる論文「RAGAs: Automated Evaluation of Retrieval Augmented Generation」です。2024年3月にEACL 2024 System Demonstrationsで発表されました。公開元はAssociation for Computational Linguistics（ACL Anthology）、URLは https://aclanthology.org/2024.eacl-demo.16/ 、DOIは https://doi.org/10.18653/v1/2024.eacl-demo.16 です。研究分野はRAG、LLM評価、情報検索です。
この論文を選んだ理由は、RAGを作る際に最も起きやすい「回答が悪いが、検索・プロンプト・生成モデルのどれを直すべきか分からない」という問題を、評価の設計から解こうとしているためです。正解QAを大量に用意できない社内検索でも、改善の仮説を速く回すための基礎になります。
どんな技術か
RAGASは、RAG（Retrieval-Augmented Generation）の出力を、正解回答や人手ラベルがなくても自動評価するためのフレームワークです。RAGの品質を一つの総合点にせず、取得した文脈が質問に絞れているか、回答の主張が文脈で裏付けられるか、回答が質問にきちんと答えているか、という3つに分けます。
具体的にはLLMを評価者として使います。回答を原子的な主張へ分解して根拠文脈で検証することでfaithfulness（根拠性）を、回答から想定質問を逆生成して元の質問との埋め込み類似度を測ることでanswer relevance（回答適合性）を測ります。単にLLMへ「0〜10点で採点してください」と尋ねるより、評価作業を小さく定義した手順に分解することが重要な工夫です。
課題
RAGでは、ベクトルDB、埋め込みモデル、チャンクサイズ、top-k、再ランキング、プロンプト、生成LLMが連鎖します。最終回答だけを眺めて失敗を判断すると、検索が悪いのか、良い資料を渡したのにモデルが無視したのか、質問に対して冗長なのかを切り分けられません。
既存の自動評価には、正解回答との一致を見る指標や、言語モデルのperplexityを見る方法があります。しかし実務の社内文書では正解QAを十分に作るコストが高く、API経由の閉じたLLMではトークン確率も取得できないことがあります。また、正解と語句が違っても正しい回答はあり得るため、文字列類似だけでは利用者体験を捉えにくいです。
さらに、コンテキストを多く渡せば検索漏れは減るように見えますが、不要な文が増えると入力費用が増え、モデルが重要箇所を見失います。実際のFAQ、規程検索、顧客サポートでは、根拠のない断定だけでなく「正しいが質問に答えていない」「根拠はあるが検索結果が冗長」という失敗も問題になります。RAGASは、この複数の失敗を別々に可視化するための技術です。
用語解説
- RAG
- 質問に関連する文書を検索し、その文書を入力に添えてLLMに回答させる構成です。RAGASは、検索器と生成器を一体のブラックボックスとして採点せず、両者の接続で起こる失敗を調べます。
- 参照不要評価（reference-free evaluation）
- 人手で作った正解回答や正解文書を採点時に必須としない評価です。論文の中心であり、評価セットが未整備な独自コーパスでも改善ループを始められる理由になります。
- LLM-as-a-Judge
- LLMに採点基準に沿った判断をさせる方法です。RAGASでは曖昧な総合採点ではなく、主張抽出・根拠判定・文抽出など、検査可能な小タスクへ分解して使います。
- Faithfulness（根拠性）
- 回答中の主張が、取得済みコンテキストから推論できる割合です。事実そのものの絶対的な正しさではなく、「このRAGが渡した根拠に支えられているか」を測る点が重要です。
- 埋め込みとコサイン類似度
- テキストをベクトルに変換し、向きの近さで意味の近さを測る方法です。RAGASは回答から逆生成した質問と元の質問を比べ、回答が問いに向いているかを評価します。
技術の仕組み
RAGASの入力は、質問q、検索されたコンテキストc(q)、RAGの回答a(q)です。論文の版では、この3つだけで計算できる3指標を提示しています。評価器に使うLLMは、論文実験ではgpt-3.5-turbo-16k、質問の埋め込みにはtext-embedding-ada-002を使いました。これは当時の実装であり、現在は同じ考え方を別のモデルに置き換えて検証する必要があります。
Faithfulness：回答を主張単位にして検証する
まず評価LLMに、回答の各文を一つ以上の短い主張集合S(a(q))へ分解させます。たとえば「Aは2021年にBを開発し、現在はCに所属する」は、年、開発、所属という別々の検証対象になります。次に各主張がコンテキストから支持されるかをLLMにYes/Noで判定させます。
根拠性スコアは、支持された主張数を全主張数で割った値です。F = |V| / |S|で、Vは支持された主張の集合です。長い回答を丸ごと採点するより、どの断定が根拠なしだったかをログに残しやすく、引用表示や回答抑制の改善にもつなげられます。
Answer relevance：回答から質問を復元する
回答適合性では、まずLLMに回答だけを見せて、答えられるはずの質問を複数個生成させます。次に元の質問と各逆生成質問を埋め込み化し、コサイン類似度の平均を取ります。概念的にはAR = (1/n) Σ cos(embed(q), embed(q_i))です。
回答が元の問いを直接扱っていれば、そこから復元される質問も近くなります。反対に、もっともらしいが別の話題へ脱線した回答や、必要な条件を答えない不完全な回答では低くなることを狙います。この指標は真偽を確認しないため、faithfulnessと必ず組み合わせます。
Context relevance：必要な文の密度を測る
コンテキスト適合性では、質問に答えるために役立つ文だけを、LLMに原文のまま抽出させます。抽出文数をコンテキストの総文数で割ったものがスコアです。CR = 必要文数 / 総文数となります。
これは、検索結果に不要な文が混ざるほど低くなります。高い値は「短く絞れている」ことを示しますが、必要情報を取り逃していないことまでは保証しません。そのため実装では、低いCRを見たらチャンク・top-k・再ランキングを疑い、低いFを見たら根拠提示や生成プロンプトを疑う、という診断に使います。
再現性のための構造化出力
論文は同一のLLM評価でも実行間の揺れがある点を指摘します。そこで判定結果をJSON形式にさせ、後段で安定して読み取れるようにしました。JSON化そのものが判断を完全に固定するわけではありませんが、自由文の解釈・パース失敗を減らし、連続実行したスコアの一貫性を高めたと報告されています。
実験と結果
論文は、提案した指標が人間の評価にどの程度一致するかを検証するため、WikiEvalというデータセットを作成しました。2022年以降に起きた出来事を扱うWikipedia 50ページから質問・文脈・回答を作り、faithfulness、answer relevance、context relevanceの各観点で、人間が二つの候補のどちらを良いと選ぶかを注釈しています。
評価設計
各インスタンスでRAGAS、LLMに0〜10点を直接付けさせるGPT Score、二候補を直接順位付けさせるGPT Rankingを比較しました。指標が人間と同じ候補を選べた割合をaccuracyとして計測しています。人手注釈者間の一致はfaithfulnessとcontext relevanceで約95%、answer relevanceで約90%でした。
人手判断との一致
RAGASの一致率はfaithfulnessで0.95、answer relevanceで0.78、context relevanceで0.70でした。GPT Scoreは順に0.72、0.52、0.63、GPT Rankingは0.54、0.40、0.52です。特に根拠性では、主張分解と個別検証を行うRAGASが直接採点を大きく上回りました。
一方、context relevanceは3指標の中で最も難しい結果でした。長い文脈から「質問に必須な文だけ」を選ぶことを評価LLMが苦手としたためです。この結果は、スコアを万能な正解判定にせず、失敗例を人が読むための優先順位付けとして使うべきことも示しています。
何に使える？
RAGASの価値は、RAGの改善を「感覚的な回答レビュー」から、部品ごとの計測と実験へ移せることです。特に正解データをまだ十分に持たないプロダクトで有効です。
社内ナレッジ検索の検索設定比較
同じ質問群に対して、チャンク長、オーバーラップ、embedding、top-k、rerankerの候補を走らせ、CR・F・ARを並べます。たとえばtop-kを増やしてFが上がらずCRだけ下がるなら、文書を増やすより再ランキングや検索クエリ改善を試す判断ができます。
根拠付き回答の回帰テスト
プロンプトやモデルを更新する前後で、代表質問に対するFを比較します。平均点だけでなく、支持されなかった主張と元コンテキストを保存すれば、「更新後にどの種類の断定が増えたか」を追えます。引用リンクを出すRAGなら、引用と主張の対応確認にも発展させやすいです。
問い合わせ自動化の安全な段階導入
人事規程、契約、製品仕様のように誤答コストが高い領域では、Fが閾値未満の回答を自動送信せず、根拠不足として検索結果の提示や人へのエスカレーションへ回せます。ただしスコアだけで安全性を保証するものではないため、実際の運用規則と人手監査を併用します。
開発や事業へのヒント
この論文から得られる大きなヒントは、LLMアプリの評価を「一問一答の正答率」だけで終わらせず、システムの因果関係に沿って分解することです。RAGの実験速度は、良いモデルを見つけること以上に、悪い原因を速く捨てられるかで決まります。
小さな評価セットでも変更を止めない
まず実ユーザーの質問や想定FAQから30〜100件程度を抽出し、質問、取得文書、回答、各スコア、評価器の理由を記録します。完全なゴールドデータを待たずに比較実験を始め、スコアが悪い上位ケースを人手レビューします。人手レビュー済みケースは、後から高品質な回帰セットとして蓄積できます。
指標と担当する改善レバーを対応させる
CRが悪ければ検索器・チャンク・top-k、Fが悪ければ回答プロンプト・引用制約・コンテキスト構成、ARが悪ければ質問理解・回答テンプレートを優先して調べます。この対応表をダッシュボードや実験ノートに持つと、「モデルを替えたら全て良くなる」という曖昧な最適化を避けられます。
評価コストをプロダクト設計に含める
LLM評価は推論呼び出しを増やすため、全リクエストを本番同期で採点する必要はありません。開発時は全件、運用時はサンプリング・新規文書・低信頼回答だけを非同期評価するなど、コストと監視粒度を分ける設計が現実的です。評価器のモデル、プロンプト、バージョンも生成系と同様に固定・記録します。
限界
RAGASは評価LLMの能力と偏りに依存します。評価器が文脈を誤読したり、専門領域の含意を理解できなかったりすれば、スコアも誤ります。論文の実験も主にWikipedia由来のWikiEvalであり、法務、医療、社内固有語などへの一般化は別途確認が必要です。
faithfulnessは「渡したコンテキストに支えられるか」であり、コンテキスト自体が古い・誤っている場合の真実性を保証しません。またcontext relevanceは不要文の少なさを重視するため、必要な根拠の網羅性を単独では測れません。高スコアでも重要な例外規定を落としている可能性があります。
計算コストと再現性も注意点です。主張分解、各主張の検証、質問逆生成をLLMへ依頼するため、評価対象が増えるほど料金と時間が増えます。同一設定でもAPIやモデルの更新、サンプリングの揺れで値が変動し得ます。固定した評価器、構造化出力、複数回実行、少量の人手監査を組み合わせ、スコアの小さな差だけで採否を決めないことが重要です。
よくある質問
Q. RAGASの高いfaithfulnessは、回答が事実として正しいことを意味しますか？
A. いいえ。高いfaithfulnessは、回答の主張がその時に渡された検索コンテキストで支持されることを示します。文書が古い、誤っている、重要な文書を検索できていない場合は別の問題なので、情報源の管理と検索網羅性の評価も必要です。
Q. 正解QAがある場合もRAGASは使うべきですか？
A. 使う価値があります。正解QAとの比較は最終的なタスク達成を測れますが、RAGASは「なぜ失敗したか」を検索・根拠・回答適合性へ分けて示します。ゴールド評価と参照不要評価を併用すると、改善箇所を特定しやすくなります。
Q. context relevanceが低ければtop-kを減らせばよいですか？
A. すぐに減らすべきとは限りません。top-kを減らすと必要な根拠まで落ちる可能性があります。まず不要文がどの検索段階で入ったかを確認し、reranker、チャンク分割、メタデータフィルタ、クエリ書き換えと比較してください。
Q. LLMを評価器にすると、評価結果はどれくらい信用できますか？
A. 論文では特に根拠性で人手判断との高い一致を示しましたが、万能ではありません。専門領域と自社の失敗パターンで、人手注釈した少数セットとの一致を先に測ってください。重大な自動判断では、評価スコアを人手確認を促すシグナルとして使うのが安全です。
Q. 本番リクエストをすべて評価すると高コストではありませんか？
A. はい。開発・CIでは固定セットを網羅評価し、本番では低信頼回答、新しいデータソース、ランダムサンプルを非同期で評価する設計が現実的です。主張数が多い回答ほどfaithfulness評価の呼び出しも増えるため、回答長の上限もコスト管理に効きます。
今日の学び
この論文は、正解回答が乏しいRAGで、品質低下の原因を特定しにくい課題を扱いました。RAGASは、回答の主張を根拠で検証するfaithfulness、回答から質問を逆算するanswer relevance、必要文の密度を見るcontext relevanceに分解して、LLMで自動評価します。
得られるヒントは、RAGを改善するときは総合スコアだけを追わず、検索・根拠付け・回答設計のどこが壊れたかを測ることです。少数の実務質問からでも評価ログを蓄積し、人手レビューと組み合わせれば、RAGの変更をより速く、説明可能に進められます。