LASSIC Media らしくメディア

LASSIC IT事業部｜元請（プライムベンダー）としてシステム保守・運用を受託

RAG・LLMの精度評価とは——回答品質を測る6つの評価観点

RAG(Retrieval Augmented Generation。外部データベースから関連情報を検索し、その内容をもとにLLMが回答を生成する仕組み)やLLMの精度評価とは、生成された回答の品質をあらかじめ定めた観点ごとに数値化し、継続的に検証する取り組みを指します。評価を観点ごとに分解すると、どこに課題があるのかを具体的に特定しやすくなります。

正確性は回答内容が事実と整合しているかを問う観点です。忠実性(faithfulness)はやや性質が異なり、回答の内容が取得したコンテキストという根拠から導けるかどうかを測ります。Ragasの公式ドキュメントでは、忠実性を回答内の主張(claim)に分解し、各主張が検索されたコンテキストから推論できるかを検証したうえで、支持された主張数を全主張数で割った0〜1のスコアとして定義しています^*1。

関連性は回答が質問の意図にどれだけ沿っているかを、網羅性は回答が期待される情報をどこまでカバーしているかをそれぞれ評価します。有害性はコンプライアンス上不適切な表現がないかを、ハルシネーションは根拠のない情報を生成していないかを確認する観点です。これらは互いに独立した尺度であり、ひとつが高くても別の観点で問題が残っている場合があります。

なお評価は、有害な出力をリアルタイムで遮断するガードレールや、レイテンシ・エラー率を継続的に見張る本番監視とは役割が異なります。評価は主にテストデータセットや抽出サンプルに対して回答品質を測定し、改善のための根拠を作る取り組みという位置づけになります。

RAG特有の評価指標——検索の再現率・適合率とコンテキストの関連性

RAGは検索(Retrieval)と生成(Generation)という2段階のパイプラインで構成されます。RAGの評価を扱った学術研究では、検索システムが関連性の高いコンテキストを特定できているか、生成側がそのコンテキストを忠実に活用できているかという、性質の異なる2つの失敗要因を切り分けて評価する枠組みが提案されています^*4。段階を分けて測定すると、回答が崩れた原因が検索にあるのか生成にあるのかを判断しやすくなります。

検索段階の評価指標としては、Context PrecisionとContext Recallの2つがよく使われます。Ragasの定義によれば、Context Precisionは取得したコンテキストのチャンクのうち、関連性の高いものが上位にランクされているかを評価する指標です^*2。一方のContext Recallは、正解となる情報を裏付けるために必要なコンテキストを、取りこぼしなく取得できているかを測る指標で、参照回答を主張に分解し、各主張が取得済みコンテキストから裏付けられるかを検証する方法などで算出されます^*3。

Microsoft FoundryのRAG評価に関するドキュメントでは、Retrieval評価者が「取得したコンテキストのチャンクが質問にどれだけ関連しているか」をLLM審査によって1〜5のスケールで採点すると説明されています^*6。同ドキュメントは生成段階の評価者についても整理しており、Groundedness(忠実性に相当)は回答が与えられたコンテキストの範囲内に収まっているかという精度の側面を、Response Completenessは期待される回答と比べて重要な情報を欠いていないかという再現性の側面を、それぞれ担うと位置づけています^*6。

指標を整理すると次の通りです。

評価手法の使い分け——人手評価・ゴールデンデータセット・LLM-as-a-judge

評価観点や指標が定まっても、それをどう測定するかで手法は分かれます。もっとも基準になりやすいのは人手評価です。専門知識を持つ担当者が回答を読み、正確性や忠実性を判定します。判断の質は高い一方、件数が増えるほど時間とコストがかかる点が課題になります。

そこで多くの現場では、代表的な質問と期待される回答の組み合わせをまとめたゴールデンデータセット(評価用にあらかじめ用意した基準データ)を整備し、これに対して評価を繰り返す運用がとられます。本番で発生した実際の失敗事例を継続的に追加していくことで、データセットは実態に即した評価基準として育っていきます。

件数が多い評価を人手だけでまかなうのは難しいため、LLM自体を評価者として使うLLM-as-a-judgeという手法が広がっています。Amazon Bedrockのドキュメントでは、この手法には生成モデル(generator model)と評価モデル(evaluator model)という異なる2つのモデルが必要になると説明されています^*5。生成モデルが出したプロンプトへの応答を、評価モデルが選択された指標にもとづいてスコアリングし、スコアと判定理由をあわせて出力する仕組みです^*5。

Microsoft Foundryの評価者も同様の考え方に立っており、Groundedness・Relevance・Coherenceなど、LLMが審査する評価者は1〜5のスケールでスコアを返し、既定のしきい値である3以上を合格ラインとして扱う設計になっています^*6。人手評価を基準にLLM-as-a-judgeの判定精度を定期的に検証し、乖離が大きい場合は評価プロンプトや基準モデルを見直す、という組み合わせ方が実務では取られやすい形です。

自動評価フレームワークの位置づけ——OSSとクラウド管理サービスの役割分担

評価を仕組み化する手段は、大きくOSSの評価フレームワークとクラウド各社の管理型評価サービスに分けられます。OSSの代表例がRagas(Retrieval Augmented Generation Assessment)です。RagasはRAGパイプラインを、正解の人手ラベルに依存しない形で評価することを目的に提案されたフレームワークで、検索システムが関連コンテキストを見つけられているか、生成側がそのコンテキストを忠実に使えているかなど、複数の評価軸を組み合わせて扱えるように設計されています^*4。開発中のプロンプトやチャンク分割の変更をすばやく試したい局面では、こうしたOSSを開発フローに組み込む形が向いています。

クラウド各社は、これと似た評価の考え方をマネージドサービスとして提供しています。Amazon BedrockはLLM-as-a-judgeによるモデル評価ジョブを提供し、生成モデルと評価モデルの組み合わせをコンソールまたはAPIから指定できます^*5。Microsoft Foundryは前述のGroundedness・Relevance・Retrieval・Response Completenessなどの評価者をSDK経由で呼び出せる形で用意しています^*6。Google CloudのVertex AIも、モデルの出力を審査モデル(judge model)で評価する仕組みを含むGen AI評価サービスを提供しており、案件ごとに基準を調整するルーブリックベースの評価方法もあわせて用意されています^*7。

どちらか一方を選ぶというより、開発中の検証にはOSSで素早く回し、本番運用の継続評価や社内のガバナンス要件に合わせて記録を残す段階ではクラウドの管理サービスに寄せる、という役割分担で組み合わせるケースが増えています。

オフライン評価とオンライン評価——リリース前検証と本番モニタリングの両輪

評価の運用は、リリース前に行うオフライン評価と、本番稼働後に行うオンライン評価の両輪で考えると設計しやすくなります。オフライン評価は、ゴールデンデータセットに対して一定の指標を機械的に走らせ、変更前後でスコアが下がっていないかを確認する回帰テストという位置づけです。プロンプトの修正やモデルのバージョン変更、チャンク分割ロジックの調整など、回答品質に影響しうる変更があった際に、このテストを通してから反映する運用にすると、気づかないうちに品質が落ちる事態を防ぎやすくなります。

一方のオンライン評価は、本番トラフィックの一部を継続的に抽出し、LLM-as-a-judgeなどの手法で採点を続けるものです。ゴールデンデータセットは過去に把握できた失敗パターンをカバーするものであり、想定していなかった質問や利用のされ方は含まれていません。本番データを継続的に観測することで、データセットではカバーしきれていない失敗の兆候を見つけやすくなります。

オフラインとオンラインは代替関係ではなく補完関係にあります。オフライン評価で品質のベースラインを守りながら、オンライン評価で見つかった新しい失敗パターンをゴールデンデータセットへ反映していくと、評価の網羅性は運用を重ねるごとに高まっていきます。

評価データセット整備と外注の勘所——何を確認して依頼するか

評価の質を左右する要素は、指標の選び方以上にデータセットの中身です。想定される質問の種類、業務特有の専門用語、回答が難しいエッジケースなどをバランスよく含め、本番で見つかった失敗事例を継続的に取り込んで更新していく運用が土台になります。データセットはバージョン管理し、どの時点の基準でどのスコアが出たのかをたどれる状態にしておくと、評価結果の比較がしやすくなります。

この一連の作業を外部のパートナーに委託する場合は、依頼範囲の明確化が判断材料になります。評価観点(正確性・忠実性・関連性・網羅性・有害性・ハルシネーションなど)のうちどこまでを対象とするか、RAG特有の検索段階の指標まで含めるか、使用する評価フレームワークや審査モデルの選定根拠を示してもらえるかがポイントです。加えて、ゴールデンデータセットの著作権や利用権をどちらが保持するのか、評価結果のレポート形式や再評価の頻度についても、契約前にすり合わせておくと運用開始後の認識のずれを抑えやすくなります。

。評価対象のユースケース数や求める指標の広さによって、必要な工数や体制は変わってきます。現状のデータセット整備状況を確認したうえで、内製と外注の分担を検討することが実務的な進め方になります。

まとめ：RAG・LLM評価で押さえる3つの軸

本稿ではRAG・LLMの精度評価について、評価観点・評価手法・運用の両輪という3つの軸で整理しました。第一に、正確性や忠実性(faithfulness)、関連性、網羅性、有害性、ハルシネーションといった複数の観点に分解して測ることで、改善点を具体的に見つけやすくなります^*1。第二に、RAGは検索と生成の2段階からなるため、Context PrecisionやContext Recallなど段階別の指標を組み合わせて原因を切り分ける考え方が有効です^*2*3*4。第三に、人手評価・ゴールデンデータセット・LLM-as-a-judgeを組み合わせ、オフラインの回帰テストとオンラインのモニタリングを両輪で回す運用が、評価の網羅性を継続的に高めていきます^*5*6*7。

よくある質問

著者：テレリモ総研編集部　鈴木 亮佑

ご不明な点はお問い合わせフォームからもご連絡いただけます。

1. *1　出典：Ragas「Faithfulness」（Ragas Documentation）（https://docs.ragas.io/en/stable/concepts/metrics/available_metrics/faithfulness/）
2. *2　出典：Ragas「Context Precision」（Ragas Documentation）（https://docs.ragas.io/en/stable/concepts/metrics/available_metrics/context_precision/）
3. *3　出典：Ragas「Context Recall」（Ragas Documentation）（https://docs.ragas.io/en/stable/concepts/metrics/available_metrics/context_recall/）
4. *4　出典：Es, S. et al.「RAGAs: Automated Evaluation of Retrieval Augmented Generation」（arXiv:2309.15217）（https://arxiv.org/abs/2309.15217）
5. *5　出典：AWS「Evaluate model performance using another LLM as a judge」（Amazon Bedrock User Guide）（https://docs.aws.amazon.com/bedrock/latest/userguide/evaluation-judge.html）
6. *6　出典：Microsoft「Retrieval-Augmented Generation (RAG) Evaluators for Generative AI」（Microsoft Foundry Learn）（https://learn.microsoft.com/en-us/azure/ai-foundry/concepts/evaluation-evaluators/rag-evaluators?view=foundry-classic）
7. *7　出典：Google Cloud「Run an evaluation」（Generative AI on Vertex AI Documentation）（https://docs.cloud.google.com/vertex-ai/generative-ai/docs/models/run-evaluation）

Tweet