DEV Community

Tutty
Tutty

Posted on

RAGAS: Automated Evaluation of Retrieval Augmented Generation

#rag

エグゼクティブサマリ

RAGASは、RAGシステムを「検索が必要な文脈を取れているか」と「生成が文脈に忠実で質問に答えているか」に分けて評価するフレームワークである。参照回答なしでも始められ、faithfulness、response relevancy、context precision、context recallなどの指標で失敗原因を切り分けられる。

実務では、本番品質の最終判定というより、検索設定、チャンク設計、リランキング、プロンプト変更を比較するための診断ツールとして有用である。ただし、検索性能を厳密に評価するには、少量でも参照回答や正解コンテキストを人手で用意する必要がある。

対象論文

要約

【社会課題】
企業や組織でRAGを使ったQAシステムの導入が進む一方、誤った回答、根拠のない回答、質問に答えていない回答を本番環境でどう検出・改善するかが課題になっている。特に、人手で正解回答や評価ラベルを大量に作ることはコストが高い。

【技術課題】
RAGの失敗原因は、検索器が必要な文脈を取れない問題、不要な文脈を混ぜる問題、生成器が取得文脈に反する回答を作る問題に分かれる。最終回答だけを採点しても、検索と生成のどちらを直すべきか判断しにくい。

【提案】
RAGASは、RAGパイプラインを自動評価するために、faithfulness、answer relevance、context relevanceなどの指標を提案する。LLM-as-a-judgeを用いることで、参照回答がない状況でも検索側と生成側の品質を分けて評価できる。

【効果】
論文のWikiEval実験では、RAGASは単純なGPTスコアリングやランキングより人間判断に近い評価を示した。実務上は、検索設定、チャンク設計、リランキング、プロンプト変更の比較に使える診断ツールとして有用である。

背景

RAGは、LLMのパラメトリック知識だけに依存せず、外部コーパスから関連文書を検索し、その文脈を入力に加えて回答を生成する枠組みである。代表的な基盤研究として、Lewis et al. (2020) の Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks がある。この研究は、seq2seqモデルのパラメトリックメモリと、Wikipediaインデックスに基づく非パラメトリックメモリを組み合わせ、知識集約型タスクで有効性を示した。

しかし、RAGシステムの評価は単純な最終回答の正誤だけでは足りない。検索器、チャンク設計、top-k、リランキング、プロンプト、生成モデルが互いに影響し、同じ「回答が悪い」でも原因が異なるためである。また、実運用では人手の参照回答や正解アノテーションを大量に用意しづらい。RAGASはこの問題に対して、LLM-as-a-judgeを用いて、参照回答なしでも改善サイクルに使える診断的な指標を提供する。

RAGASが測る品質軸

指標 主に見る対象 入力 人手作成が必要なデータ 何が低いと問題か
Faithfulness 生成 質問、回答、取得文脈 原則不要。質問は実ログまたは評価用質問セットが必要。 回答中の主張が取得文脈から支持されていない。幻覚や根拠なしの断定が疑われる。
Answer/Response Relevancy 生成 質問、回答 原則不要。質問は実ログまたは評価用質問セットが必要。 回答が質問に直接答えていない。不完全、冗長、論点ずれの可能性がある。
Context Relevance 検索 質問、取得文脈 原則不要。質問は実ログまたは評価用質問セットが必要。 取得文脈に不要情報が多い。長い文脈によるコスト増、生成品質低下につながる。
Context Precision 検索・ランキング 質問、取得文脈、参照回答または参照コンテキスト 厳密な検索評価では、参照回答、参照コンテキスト、または正解コンテキストIDが必要。 関連チャンクが上位に来ていない。検索やリランキングの調整が必要。
Context Recall 検索・網羅性 質問、取得文脈、参照回答または参照コンテキスト 参照回答または正解根拠となるコンテキストが必要。 回答に必要な情報を取得できていない。top-k、チャンク、埋め込みモデル、クエリ変換が疑わしい。
Context Entities Recall 検索・エンティティ網羅性 文脈、参照情報 重要エンティティを含む参照情報が必要。 重要エンティティの取りこぼしがある。固有名詞中心のQAで有用。
Noise Sensitivity 頑健性 質問、回答、取得文脈、参照情報 参照回答または正解根拠が必要。 ノイズ文脈の混入により回答が崩れやすい。

論文時点では、reference-freeな評価としてfaithfulness、answer relevance、context relevanceの3軸を強調している。一方、現在の実装ではcontext precisionやcontext recallのように、参照回答や参照文脈を使うとより診断しやすい指標も整理されている。RAGASは参照回答なしで始められるが、検索性能を厳密に比較する場合は、少量でも参照回答や正解コンテキストを人手で用意する必要がある。

指標の計算方法

Faithfulness

回答を短い主張に分解し、それぞれの主張が取得文脈から推論可能かをLLMで判定する。スコアは、支持された主張数を全主張数で割った値として定義される。

この指標は「回答が正しいか」ではなく「与えられた文脈に忠実か」を見る。したがって、文脈自体が誤っていれば、誤った文脈に忠実な回答でも高くなる可能性がある。RAGの評価では、faithfulnessをcontext recallや人手確認と組み合わせる必要がある。

Answer Relevance

生成回答からLLMに質問を逆生成させ、その逆生成質問と元の質問の埋め込み類似度を測る。回答が質問にきちんと対応していれば、回答から復元される質問も元の質問に近くなる、という仮定に基づく。

この設計は、事実性ではなく応答の焦点を測る。論文の実験でもanswer relevanceはfaithfulnessより人間判断との一致が低く、候補回答間の差が微妙なケースで難しいと報告されている。

Context Relevance

取得文脈から、質問に答えるために必要な文だけをLLMに抽出させ、抽出文数を文脈全体の文数で割る。余計な情報が少ないほど高いスコアになる。

これは、検索器が「答えに必要な情報を含むか」だけでなく、「不要な情報をどれだけ混ぜないか」を評価する。長い文脈の中央に重要情報が埋もれるとLLMが利用しにくいことは、Liu et al. (2023) の Lost in the Middle とも整合する。

実験

論文では、RAGASを評価するためにWikiEvalというデータセットを作成している。これは、2022年以降の出来事に関するWikipediaページを選び、ChatGPTで質問と回答を生成し、人間アノテータがfaithfulness、answer relevance、context relevanceの観点で比較判断を付けたものである。

主な実験結果は、人間判断との一致率で評価されている。

手法 Faithfulness Answer Relevance Context Relevance
RAGAS 0.95 0.78 0.70
GPT Score 0.72 0.52 0.63
GPT Ranking 0.54 0.40 0.52

RAGASは、単純にChatGPTへスコア付けやランキングを依頼するベースラインより、人間判断に近い結果を示した。特にfaithfulnessの一致率が高い。一方、context relevanceは最も難しい軸であり、長い文脈から本当に必要な文だけを選ぶタスクでLLMが苦戦することが示唆されている。

関連研究との位置づけ

研究 位置づけ RAGASとの関係
Lewis et al. (2020), RAG 検索拡張生成の代表的枠組み RAGASが評価対象にするRAGパイプラインの基礎。
SelfCheckGPT (Manakul et al., 2023) ブラックボックスLLMの幻覚検出 複数サンプル間の一貫性で事実性を推定する。RAGASは取得文脈への支持を直接見る点が異なる。
GPTScore (Fu et al., 2023) LLMを使った生成評価 汎用的なLLM評価。RAGASはRAG固有の失敗分解に寄せている。
Lost in the Middle (Liu et al., 2023) 長文脈中の位置バイアス分析 不要・長大な取得文脈を避けるcontext relevanceの重要性を補強する。
BERTScore / MoverScore / ROUGEなど 参照回答との類似度評価 RAGASは参照回答がない状況でも使える診断指標を重視する。

強み

  • RAGの失敗原因を検索側と生成側に分けて診断できる。
  • 参照回答がない段階でも評価サイクルを回しやすい。
  • LLM APIだけで使えるため、閉じた商用モデルにも適用しやすい。
  • LangChainやLlamaIndexなどのRAG開発フレームワークに組み込みやすい。
  • 単純な総合スコアではなく、faithfulness、relevancy、precision、recallなどの軸別スコアで改善箇所を絞れる。

限界

  • LLM-as-a-judgeに依存するため、評価モデルの能力、プロンプト、出力形式、API更新でスコアが揺れる。
  • faithfulnessは「取得文脈に支持されるか」を見るため、取得文脈自体が誤っている場合の真偽は保証しない。また、検索文脈が不足している場合、文脈内の情報だけに忠実な回答でもユーザの問いに必要な情報を落としている可能性がある。
  • answer relevanceやcontext relevanceは、候補間の差が微妙な場合や長文脈の場合に不安定になりやすい。
  • スコアは絶対値として過信しにくい。評価モデル、プロンプト、データセットを固定し、相対比較や時系列トレンドとして使うのが現実的である。
  • ドメイン特化の判断基準、法務・医療・金融などの高リスク領域では、人間評価セットによる較正が必要である。

実務での使い方

RAGASは、RAGアプリケーションの改善ループに組み込むのが最も有効である。

  1. 評価データを作る。実際のユーザ質問、代表的な業務質問、失敗ログを混ぜる。
  2. まずfaithfulnessとresponse relevancyで生成側の問題を確認する。
  3. context precisionとcontext recallで検索側の問題を分ける。faithfulnessが高いだけでは十分ではないため、最低限でもfaithfulness、response relevancy、context precision、context recallを併用する。
  4. 検索器、chunk size、chunk overlap、top-k、リランキング、クエリ変換、プロンプトを1つずつ変えて比較する。
  5. 評価モデルとRAGASバージョンを固定し、CIや定期評価で回帰を検知する。
  6. 小さな人手ラベル付きセットを用意し、RAGASスコアが自分のドメインの人間判断とずれていないか確認する。

参考文献

Top comments (0)