RAGの評価方法とは？必要な指標・フレームワーク・Ragasでの実践検証を解説

RAGを業務で使うなら、もっともらしい回答だけで判断してはいけません。必要な文書を取得できているか、回答が検索結果に根拠づけられているかを分けて確認することが重要です。

本記事では、RAG評価の指標と方法、代表的なフレームワークを解説します。後半では、架空の社内サポート文書を使ったRagasの検証結果を紹介します。社内RAGのPoC設計を検討する際に役立ててください。

【監修者】田村 洋樹

株式会社WEEL代表取締役 / 累計25社以上のAIアドバイザリーを担当 / 企業向けセミナー・大学講義でのべ10,000人超に登壇 / 日本HP・インテルなど、大手企業主催カンファレンスへの登壇実績多数。AI導入支援・生成AIを活用した業務改革のプロとして、アドバイザリー・PM・講演者など多面的な立場から企業を支援中。

そもそもRAGとは

RAG（Retrieval-Augmented Generation）は、質問に関連する外部情報を検索し、その内容をLLMへ渡して回答を生成する仕組みです。LangChainのRetrieval公式ドキュメントでも、検索によって実行時に外部知識を取得し、生成と組み合わせる構成がRAGの基礎として説明されています。

社内規程、製品マニュアル、FAQなどを回答の根拠にできる一方で、検索対象の文書が古い、または検索結果がずれている場合は、回答も不正確になり得ます。導入時から評価用の質問と正解を準備しておくことが大切です。

LLM・ファインチューニングとの違い

LLMは文章を生成するモデル、ファインチューニングはタスクに合わせて追加学習でモデルの振る舞いを調整する方法、RAGは外部情報を検索して回答時に参照させる方法です。社内ルールの更新を反映したい場合、RAGでは検索対象の文書を更新する運用を取りやすい点が特徴です。

ただし、RAGは回答品質を自動的に保証する技術ではありません。文書の更新管理、検索設定、回答の根拠表示、人による確認まで含めて設計する必要があります。

RAGの基本的な仕組みや導入時の注意点を確認したい方は、次の記事も参考にしてください。

WEEL

生成AIの自社データ活用で重要なRAGとは？メリットと注意点、導入事例を徹底解説 | WEEL 近年、多くの企業が業務効率化のために生成AIを導入していますが、一般的な情報だけでは自社特有の業務や規則に対応できない場合が多くあります。 そこで注目されているの…

RAGに評価が必要な理由

RAGでは、もっともらしい回答でも、必要な根拠を取り逃していたり、関係のない文書を混ぜていたりすることがあります。利用者の満足度だけを見ると、どこに問題があるのか分かりません。

たとえば、回答が誤っている原因は、文書の登録漏れ、チャンク分割、検索クエリ、検索件数、プロンプト、LLMの推論などにあります。原因ごとに評価軸を分けると、改善対象を一つに絞れます。

また、モデルや検索方式を変更するたびに同じ評価セットで比較すれば、変更が本当に改善につながったかを確認できます。PoCでは少数の代表質問でも構いませんが、運用に進むほど、問い合わせ傾向や失敗例を反映した評価セットを増やす必要があります。

RAG評価は参照・検索・生成それぞれで行う

RAGの評価は、回答だけでなく、回答に至るまでの流れを追うことが重要です。特に業務利用では、「正しい文書を取れたか」と「取れた文書だけで答えたか」を分けて確認します。

Ragasの指標一覧には、RAG向けのContext Precision、Context Recall、Response Relevancy、Faithfulnessなどが掲載されています。指標を増やすことが目的ではなく、業務で避けたい失敗に合うものを選ぶことが重要です。

RAGの評価方法の種類

RAG評価は、部品ごとの性能を測るコンポーネント評価と、利用者の質問から最終回答までを通して測るパイプライン評価に大別できます。部品と全体の両方を測ることで、問題の発生箇所を特定しやすくなります。

コンポーネント評価

コンポーネント評価では、文書の前処理、チャンク分割、Embedding、Retriever、回答生成などを個別に確認します。検索が悪いのか、検索後の回答生成が悪いのかを切り分けやすいため、改善作業の起点になります。

たとえば、正解文書IDを付けた質問セットがあれば、RetrieverがそのIDを取得できた割合を測れます。検索の失敗を先に直すことで、プロンプトだけを調整し続ける遠回りを避けられます。

パイプライン評価

パイプライン評価では、質問、検索結果、最終回答を一連の体験として確認します。利用者が期待する質問に答えられたか、回答の根拠を追えるか、回答すべきでない質問で適切に保留できたかを評価します。

コンポーネント単体が良くても、複数の処理をつないだ際に文脈が欠けたり、不要な文書が回答を乱したりすることがあります。リリース判断には、実際の利用場面に近いパイプライン評価が欠かせません。

具体的なRAGの評価方法

RAG評価は、人が内容を読む人手評価と、同じ条件を繰り返し測る自動評価を組み合わせる方法が現実的です。自動スコアと業務上の確認を分けるために、人が確認すべきリスクを明確にしましょう。

人手評価

人手評価では、業務に詳しい担当者が質問、取得文書、回答を見比べます。正誤だけでなく、回答に必要な前提が抜けていないか、言い切るべきでない場面で保留できているか、出典を追えるかを確認できます。

はじめは、頻出問い合わせ、誤答時の影響が大きい問い合わせ、表現が似ていて取り違えやすい問い合わせを選びます。評価基準を事前に文章化し、複数人で判断が割れた例を残すと、後の自動評価にも使えます。

自動評価

自動評価は、正解文書IDや参照回答を付けた評価データを用意し、検索・回答の変化を同条件で比較する方法です。検索にはPrecisionやRecall、回答には根拠との整合性や関連性を使います。

RagasのContext Precisionの説明では、関連チャンクを検索順位の上位に置けているかを評価します。Context Recallの説明では、必要な情報を取り逃していないかを確認します。自動評価は比較の物差しであり、業務判断の代替ではありません。

RAG評価における代表的なフレームワーク

フレームワークとは、評価データの形式、指標の計算、記録や可視化などを一定の手順で扱うための基盤です。ゼロから採点ロジックを作るよりも、評価を継続しやすくなります。

ただし、フレームワークを導入しても、正解データや合格基準がなければ業務に合う品質は判断できません。自社の失敗例を評価セットへ反映する運用が前提になります。

Ragas

Ragasは、RAGやエージェント型ワークフロー向けの指標を提供する評価フレームワークです。Ragas公式の指標一覧には、Context Precision、Context Recall、Faithfulness、Response Relevancyなどが整理されています。

検索結果と正解文書IDがある場合は、IDベースのPrecisionとRecallでRetrieverを評価できます。参照回答や生成回答もある場合は、LLMを用いた指標を追加できます。まずは評価対象を検索だけに限定しても、改善の手掛かりは得られます。

TruLens

TruLensは、LLMアプリケーションの実行結果に対し、フィードバック関数で評価を組み立てるフレームワークです。TruLensのFeedback Functions公式ガイドでは、正解データが少ない場合でも、フィードバック関数でアプリケーションの実行を評価する考え方が説明されています。

RAG向けテンプレートには、Groundedness、Context Relevance、Answer Relevanceなどが含まれます。評価の理由を実行ログと照らし合わせたい場合や、ランタイムでのガードレールも検討したい場合に選択肢になります。

ARES

ARESは、RAGのContext Relevance、Answer Faithfulness、Answer Relevanceを対象にするフレームワークです。合成データ、分類器、Prediction-Powered Inference（PPI）を組み合わせて評価します。ARES公式GitHubリポジトリでは、人手ラベル付きの検証セット、few-shot例、より大きい未ラベルの評価セットを用いる構成が示されています。

比較的多くの評価データを扱う場面に向きますが、準備するデータや運用の設計も必要です。小規模PoCでは、評価セットを先に整え、必要に応じて高度な自動評価へ広げるほうが進めやすいでしょう。

評価結果をどのようにRAG改善に活用するべきか

スコアが低かったときは、モデルをすぐに変えるのではなく、失敗した質問、取得文書、期待する根拠、実際の回答を一件ずつ確認します。数値と失敗ログをセットで見ることが、RAG改善の基本です。

1. 合格条件を決める

業務ごとに、検索漏れを避けるのか、不要な文書を減らすのか、根拠のない回答を防ぐのかを決めます。高リスクの手続きでは、スコアだけでなく人の確認を必須にします。

2. 失敗を分類する

文書が存在しない、正解文書を検索できない、不要文書が上位に出る、文書は取れたのに回答が外れる、といった形で記録します。

3. 変更は一度に一つにする

チャンクサイズ、メタデータフィルター、検索件数、リランキング、プロンプトを同時に変えると、改善理由が分かりません。一つずつ変更し、評価セットで再測定します。

4. 評価セットを育てる

実運用で出た質問やレビューで判明した失敗例を追加します。問い合わせの傾向が変われば、評価対象も更新します。

【実践】RagasでRAG評価を検証してみた

ここでは、架空の社内サポート文書8件と質問3件を使い、RAGの検索から回答生成、Ragasによる評価までをローカルで実行しました。各質問には参照回答を用意し、個人情報や顧客データは使用していません。

検索では文字n-gramで上位3件を取得し、gpt-5.4-miniで検索結果だけを根拠に回答を生成しました。続いて、gpt-4.1-miniを評価モデルとして使い、回答が検索結果に裏付けられているか、検索結果が参照回答に役立つか、必要な情報を検索できているかを確認します。

検証用スクリプトは、ragas_full_rag_evaluation.pyに保存しています。OpenAIのAPIキーは実行環境の環境変数としてだけ設定し、コード、出力JSON、画像には含めていません。

コード

from langchain_openai import ChatOpenAI
from openai import AsyncOpenAI
from ragas.llms.base import llm_factory
from ragas.metrics.collections import (
    ContextRecall,
    ContextPrecisionWithReference,
    Faithfulness,
)

generation_model = ChatOpenAI(model="gpt-5.4-mini", temperature=0)
evaluator_llm = llm_factory("gpt-4.1-mini", client=AsyncOpenAI())

faithfulness = Faithfulness(llm=evaluator_llm)
context_precision = ContextPrecisionWithReference(llm=evaluator_llm)
context_recall = ContextRecall(llm=evaluator_llm)

async def evaluate_case(question, context, reference, retrieved_contexts):
    response = await (PROMPT | generation_model).ainvoke(
        {"context": context, "question": question}
    )
    faithfulness_score = await faithfulness.ascore(
        user_input=question,
        response=str(response.content),
        retrieved_contexts=retrieved_contexts,
    )
    precision_score = await context_precision.ascore(
        user_input=question,
        reference=reference,
        retrieved_contexts=retrieved_contexts,
    )
    recall_score = await context_recall.ascore(
        user_input=question,
        reference=reference,
        retrieved_contexts=retrieved_contexts,
    )
    return faithfulness_score.value, precision_score.value, recall_score.value

記事内のコードは、回答生成と評価指標の初期化・計算部分を抜粋しています。実行用ファイルでは3件の質問を繰り返し評価し、各質問の生成回答とスコア、平均スコアを表示したうえでJSONファイルへ保存します。

実行結果は次のとおりです。今回の評価セットでは、Context PrecisionとContext Recallは全3件で1.000でした。取得した文脈は、参照回答に対して有用であり、必要な情報を含むと評価されました。

一方で、ソフトウェア購入の質問ではFaithfulnessが0.750でした。スコアが下がったケースは回答と検索結果を確認し、質問、参照回答、検索対象文書のどこに改善余地があるかを切り分けます。

なお、LLMを評価者に使う指標は、評価モデルやプロンプトで結果が変わることがあります。スコアだけで合否を決めず、失敗例の目視確認と同じ評価セットでの変更前後比較を組み合わせることが大切です。この3件だけで、本番品質を判断することはできません。実際の業務で想定される質問、正解文書、失敗時の影響を評価セットに加えたうえで、リリース判断の材料にします。

よくある質問

RAGの評価方法を運用に組み込み、回答品質を高めよう

RAGの評価方法では、参照データ、検索、生成を切り分け、どの工程で失敗したかを確認します。小さな評価セットを継続して回すことが、改善を続ける近道です。最初から大量のデータや複雑な指標を用意する必要はありません。

検索結果を正しく取れても、最終回答の根拠との整合性や、業務上の判断に使えるかは別に確認する必要があります。RAGの評価設計、社内データの整理、PoCの進め方に迷う場合は、WEELの無料相談をご活用ください。自社の業務とリスクに合う評価範囲から、導入方針を整理できます。

最後に

いかがだったでしょうか？

RAGの評価設計や社内データの整理、PoCから運用までの進め方に迷ったら、WEELの無料相談へお気軽にご相談ください。自社の業務やリスクに合わせて、評価範囲や導入方針を一緒に整理します。

生成AIを社内で活用していきたい方へ

「生成AIを社内で活用したい」「生成AIの事業をやっていきたい」という方に向けて、通勤時間に読めるメルマガを配信しています。

最新のAI情報を日本最速で受け取りたい方は、以下からご登録ください。

また、弊社紹介資料もご用意しておりますので、併せてご確認ください。

メルマガに登録する

資料をダウンロードする