RAG評価の設計ガイド｜KPIから逆算する指標・データセット・運用手順

RAG評価で失敗する理由は「指標の前に目的がない」

RAG評価がうまく機能しない原因は、多くの場合、評価の前提となる目的が定義されていないことにあります。

何のために測るのか。その結果を、どのように意思決定に使うのか。どの水準を超えれば「合格」とみなされるのか。ここが曖昧なまま指標を導入すると、スコアは出ても判断が止まります。評価はあるが、改善にはつながらない状態です。

RAG評価は、数値を出す作業ではありません。業務上の判断を支えるための設計です。目的が先にあり、指標は後に決まります。

評価スコアが上がっても、ユーザーが満足しないケースが起きる

評価指標の数値が改善しているにもかかわらず、業務側の評価が変わらないことがあります。理由は単純で、多くの評価指標は「モデルの挙動」を測っていますが、業務側が見ているのは「成果への影響」です。

検索精度が向上しても、回答の形式が業務フローに合っていなければ使われません。正確性が高くても、必要な情報にたどり着くまで時間がかかれば効率は上がりません。

評価設計が業務の利用場面と結びついていない場合、スコアの改善はそのまま価値の改善にはなりません。どの数値が、どの業務成果を代理しているのかを説明できない評価は、最終的に意思決定に使われなくなります。

RAGは「検索」と「生成」を分けて評価しないと原因が特定できない

RAGは、検索と生成という異なる処理を組み合わせた構造です。にもかかわらず、最終回答だけを評価対象にしてしまうケースが多々あります。

回答が不十分な場合、原因は一つではありません。適切な文書を取得できていない可能性もあれば、取得した文書を生成段階で十分に活用できていない可能性もあります。プロンプト設計や前処理の整形ロジックに問題があることもあります。

これらを区別せずにE2Eのスコアだけを見ても、どこを修正すべきかは判断できません。結果として、モデルを変える、パラメータを調整する、といった影響範囲の大きい変更に頼ることになります。

検索段階の品質と、生成段階の品質は本来別の論点です。どちらが弱いのかを切り分け、それぞれの責任範囲を整理してはじめて、評価結果は具体的な改善アクションに結びつきます。

PoCの評価と、本番の評価は目的が違う

PoCでは、まず技術的に成立するかを確認します。一定水準の正答率が出るか、重大な誤回答が頻発しないか。関心は「この構成で実装可能か」にあります。

本番運用では視点が変わります。誤回答が業務リスクになっていないか、利用が継続しているか、品質が時間とともに劣化していないか。ここで求められるのは安定性と影響管理です。

PoC用の評価設計をそのまま本番に適用すると、運用上の変化を捉えきれません。検証データでは問題が出なくても、実際の利用では想定外の質問が現れます。PoCは成立性の確認、本番は品質維持と監視。目的を切り替えない限り、評価は形式的なチェックにとどまります。

最初に決めるのはKPI

RAG評価の設計で最初にやるべきことは、業務として何を改善したいのかを定義することです。

精度を上げたい、という言い方では足りません。何の精度か。それが改善すると、どの業務指標が動くのか。そこまで落とさなければ、評価は設計できません。

評価指標はKPIを支えるための手段です。順番を逆にすると、スコアは出ても意思決定には使えません。

業務KPIの例

RAG導入の目的は、技術検証ではなく業務改善です。そのため、まず業務側のKPIを明確にします。

たとえば、どれを重視するかで、評価の重点は変わります。

• 問い合わせ件数を減らしたい。
• 一次回答で解決する割合を高めたい。
• 回答までの時間を短縮したい。
• 顧客満足度を上げたい。
• 誤回答による監査リスクを下げたい。

問い合わせ削減が目的であれば、利用率や自己解決率が重要になります。監査リスク低減が目的であれば、Faithfulnessや安全性評価の比重が高くなります。

KPIが違えば、評価設計も変わります。ここを曖昧にしたまま評価を始めると、後から軸がぶれます。

KPIを評価指標へ落とす対応表

KPIはそのままでは測定できません。抽象的な業務目標を、測定可能な評価指標に変換する必要があります。

たとえば、

• 一次回答率向上 → 回答の正確性・質問適合性
• 解決時間短縮 → 回答の簡潔性・必要情報への到達時間
• 監査リスク低減 → 根拠整合性・安全性評価
• 利用率向上 → 再質問率・離脱率

こうした対応関係をあらかじめ整理しておくことで、評価結果の読み方が変わります。スコアが上下したときに、それがどのKPIに影響するのかを説明できる状態になります。

KPIが決まらない場合の現実的な決め方

実際には、最初から明確なKPIが定まっていないこともあります。その場合でも、完璧な定義がそろうまで評価を止める必要はありません。

まずは暫定のKPIを置きます。たとえば「問い合わせのうち20％をRAGで自己解決できるようにする」「誤回答率を一定以下に抑える」といった水準です。粒度は粗くてもかまいません。

重要なのは、評価結果がどの方向に動けば成功とみなすのかを事前に言語化しておくことです。基準がなければ、数値が出ても判断できません。

PoC段階では仮のKPIでも問題ありません。本番に移行する前に、業務責任者と合意し、必要に応じて見直します。KPIは固定的なものではありません。ただし、何も定めないまま評価を始めることだけは避けるべきです。

評価は3層で設計する

RAG評価を一つの枠組みでまとめようとすると、どこかが曖昧になります。改善のための評価と、本番監視のための評価では役割が違います。安全性や説明責任まで含めると、求められる視点はもう一段増えます。

評価が混線するのは、この役割の違いを整理しないまま設計してしまうからです。そこで、評価を三つの層に分けて考えます。

①オフライン評価（改善のための検証）

オフライン評価は、改善のために行います。テストデータや既存ログを使い、検索と生成の挙動を検証します。

目的は、問題の所在を特定することです。検索が適切な文書を取得できているのか、生成が根拠を正しく使えているのか、特定の質問タイプで精度が落ちていないか。改善施策を入れた場合、その効果が本当に出ているのかも確認します。

この層では、実験と検証が中心です。本番の安定性よりも、どこを直すべきかを明らかにすることに価値があります。

②オンライン評価（本番の品質監視）

オンライン評価は、本番環境で品質を維持するための仕組みです。

利用率が急に下がっていないか、再質問が増えていないか、特定のパターンで誤回答が集中していないか。ここでは完璧な精度よりも、変化を検知できることが重要になります。

オフライン評価が改善のための検証だとすれば、オンライン評価は監視です。数値の上下を眺めるのではなく、どの変化を異常とみなすのかをあらかじめ決めておきます。劣化を早期に察知できなければ、評価は意味を持ちません。

③ガバナンス評価（安全性・逸脱・説明責任）

RAGを業務に組み込む以上、安全性と説明責任の観点は避けられません。機密情報が不適切に出力されていないか、根拠のない断定が含まれていないか、社内ポリシーや法規制に反する回答をしていないか。これらは精度とは別の軸です。

アマゾンウェブサービス（AWS）環境では、こうした観点をAmazon Bedrock Guardrailsの適用や監視設計とあわせて考えるのが現実的です。正答率が高くても、安全性や統制の面で問題があれば運用は継続できません。ガバナンス評価は後付けではなく、設計段階から監視対象として組み込む必要があります。

オフライン評価の型｜「どこが悪いか」を切り分ける

オフライン評価の役割は、どこが悪いのかを特定することです。RAGは複数の処理を組み合わせた構造です。そのため、評価も一枚岩では機能しません。検索と生成を分けて見る視点と、最終回答全体を見る視点の両方が必要になります。改善につなげるための評価は、必ず切り分けを前提に設計します。

コンポーネント別（検索／生成）とE2E（最終回答）の両方を持つ

最終回答だけを評価しても、品質が悪いという結果しか分かりません。原因が検索にあるのか、生成にあるのか、それとも接続部分なのかは見えません。この区別ができなければ、改善は勘に頼ることになります。

RAGは検索と生成を組み合わせた構造です。検索では適切な文書を取得できているかを確認し、生成では取得情報を根拠に基づいて統合できているかを確認します。

ただし、コンポーネント別評価だけでは足りません。ユーザーが受け取るのは一つの回答です。最終回答として実用に耐えるかを確認するために、E2E評価も併せて持ちます。

原因特定のための分解評価と、全体品質を見るE2E評価。この二つを併設することが、改善に直結する設計です。

検索評価の基本

検索評価では、取得された文書が業務上妥当かどうかを確認します。代表的な指標にはPrecision@K、Recall@K、MRR、nDCGなどがありますが、指標の種類を増やすこと自体が目的ではありません。

重要なのは、業務上必要な文書が上位に来ているかどうかです。上位K件の中に正解文書が含まれていなければ、その後の生成がどれだけ優れていても補えません。検索が不十分であれば、生成段階での改善余地は限定的です。

検索評価は、生成の前提条件を確認する工程だと整理すると分かりやすくなります。

生成評価の基本

生成評価では、回答が業務上妥当な形で構成されているかを確認します。根拠と整合しているか、質問に直接答えているか、不要な情報を混ぜていないか。こうした観点を指標化したものが、根拠整合性（Faithfulness）や回答適合性（Answer Relevance）です。

ただし、生成評価は検索結果に強く依存します。検索が不十分であれば、生成のスコアも安定しません。生成だけを独立して改善しようとすると、原因を誤認することがあります。

生成評価は単独で読むものではなく、検索評価とセットで解釈します。

Ragasで最低限押さえるメトリクスと読み方

Ragasを使う場合でも、すべてのメトリクスを追う必要はありません。最低限押さえる軸としては、Faithfulness、Answer Relevance、Context Precision、Context Recallが基本になります。

一方で、AWS環境ではAmazon Bedrock Evaluationsを使って、Correctness、Completeness、Helpfulness、Citation precision、Citation coverage、安全性に関わる観点まで含めて評価することも可能です。Ragasは原因切り分けの補助として有効ですが、実運用ではマネージド評価機能と併用する設計が現実的です。

RAGCheckerの使い所

RAGCheckerは、回答を主張単位で分解し、それぞれがどの文書に基づいているかを評価するアプローチを取ります。回答の中に根拠が欠落した主張がないかを確認できます。

E2Eスコアでは見えにくい細かな不整合を可視化できる点が特徴です。複数の事実を統合する質問や長文回答が多いケースでは有効です。

ただし、すべての評価に適用する必要はありません。どの粒度で問題を特定したいのかを明確にし、その目的に応じてRagasとRAGCheckerを使い分けます。

評価データセットの作り方

RAG評価で重要なのは、評価データの設計です。目的は模範解答を整えることではなく、改善判断に使える基準を用意することにあります。

この回答に最低限含まれているべき要素は何か。どこが欠けると業務上問題になるのか。どの差異を許容するのか。これらを明文化しておかなければ、評価は安定しません。評価データセットは「理想解」を作る作業ではなく、判断基準の粒度を揃える設計です。

テストケースの分類

テストケースは質問をタイプごとに分類して設計します。質問の性質が違えば、評価観点も変わるためです。

• FAQ型
  • 結論に端的に到達できているかを評価します。冗長でも正しければよい、という基準にはしません。
• 手順型
  • 工程の抜けや順序の誤りがないかを確認します。一部が正しくても、順番が崩れていれば実務では使えません。
• 規程・法務型
  • 表現の正確性と根拠提示を重視します。解釈の余地が残る回答はリスクになります。
• 数値参照型
  • 数値と単位の一致が前提です。意味が合っていても、数字が違えば不合格です。
• 要約統合型
  • 複数文書の整合性が保たれているかを評価します。一部だけ正しくても、全体として矛盾があれば評価は下がります。

分類せずに平均スコアだけを見ると、どのタイプで弱いのか分かりません。

期待値（ゴールド）をどう用意するか：模範回答／根拠文書／許容幅

ゴールド設計の目的は、評価判断の基準を定義することです。回答に最低限含まれるべき要素を定め、参照すべき根拠文書を明示し、そのうえでどの差異を許容するのかを決めます。

文章表現の違いを許容するのか、数値は完全一致とするのか、要点が含まれていれば合格とするのか、特定語句を必須とするのか。こうした許容幅を事前に定義しておかなければ、同じ回答でも評価者によって判断が分かれます。

評価が安定しない原因は、モデルの性能よりも基準の曖昧さにあることが多いです。

運用ログから育てる

評価データセットは固定ではありません。本番ログを取り込んで更新します。

誤回答が発生した質問、再質問が多いケース、エスカレーションに至った事例は、そのまま改善対象になります。これらをテストケースとして整理し、改善前後で比較できる形にします。

机上で想定した質問だけでは、実運用の揺れを再現できません。本番ログを評価資産として取り込む設計にしておくことが、継続的な精度向上につながります。

日本語で詰まりやすい点

日本語RAGでは、言語特性が精度に直接影響します。全角と半角の混在、略称と正式名称の使い分け、同義語の揺れ。こうした表記差は検索段階で影響します。「できるだけ早く」「原則として」といった曖昧語は、生成段階で解釈のぶれを生みます。数字と単位の不一致は、そのまま誤回答になります。

評価設計時に、どこまでを同一とみなすのかを定義します。ここを曖昧にしたままでは、検索の問題なのか生成の問題なのか切り分けができません。

日本語特有の揺れを前提に基準を設計することが、安定した評価の条件です。

オンライン評価の型｜本番で「劣化」と「事故」を見逃さない

オンライン評価の目的は、本番環境での劣化や事故を早期に検知することです。オフライン評価が改善のための検証であるのに対し、オンライン評価は品質を維持するための監視に位置づけられます。

すべてを詳細に測定しようとすると運用が続きません。常時確認すべき指標を絞り、変化を捉える設計にします。

オンライン評価で見るべき最小セット

常に追う指標は絞ります。最低限、次の三つです。

• ユーザーフィードバック
  • 回答に対する主観評価です。満足度そのものより、評価分布の変化を見ます。
• 再質問率
  • 一度の回答で解決できていない兆候です。回答内容が不十分か、期待する形式に合っていない可能性があります。
• エスカレーション率
  • 人手対応へ戻る割合です。品質だけでなく、業務上の信頼性や運用負荷にも直結します。

重要なのは絶対値より推移です。ある時点から再質問率が上がったなら、モデル更新、データ更新、検索品質の低下、利用者層の変化など、何かが変わっています。オンライン評価は、こうした変化を早く捉えるための仕組みです。

LLM-as-a-Judgeを入れるときの注意

LLM-as-a-Judgeをオンライン評価に組み込むケースもあります。ただし、万能ではありません。

まず判定のブレがあります。同じ回答でも、プロンプトや温度設定によって評価が揺れます。評価基準を固定し、判定プロンプトを変更しない設計が前提です。

次にコストです。すべての回答を判定対象にすると、トークンコストが増加します。サンプリング設計が必要になります。

LLM-as-a-Judgeは人手レビューを代替するものではなく、優先順位付けのためのフィルターとして使う位置づけが現実的です。

LangSmith等を使う場合の考え方

LangSmithのようなツールを使う場合は、トレース、評価、レビューを分離して設計します。

• トレース
  • 検索結果、プロンプト、最終出力を可視化します。
• 評価
  • 定義した指標に基づき自動スコアリングを行います。
• 人手レビュー
  • 重大事象や判定困難なケースを確認します。

この三つを混ぜると運用が重くなります。役割を分けることで、監視の負荷を抑えながら精度を維持できます。

Amazon Bedrockで寄せられる部分

AWS環境で構成している場合、Amazon Bedrockの機能を使って評価と監視の一部をマネージドに寄せることができます。たとえば、評価自体はAmazon Bedrock Evaluationsで実施し、モデル入出力の取得はModel invocation logging、Knowledge Basesの取り込み状況の確認はKnowledge base logging、API操作の監査はCloudTrailで担う、という形です。

ただし、Amazon Bedrockが評価方針そのものを決めてくれるわけではありません。何を異常とみなすか、どの指標を継続監視するかは利用者側で設計する必要があります。

スコアが悪いときの「診断チャート」

評価スコアが下がったとき、いきなりモデルを変更するのは得策ではありません。まず確認すべきなのは、どの層で劣化しているのかです。検索か、生成か、それとも接続部分か。診断の順番を決めておかないと、修正は場当たり的になります。

検索が弱いとき

検索評価の指標が低い場合は、取得精度を疑います。最初に見るのはチャンキングです。分割が粗すぎれば文脈が欠け、細かすぎればノイズが増えます。

次に埋め込みモデルと検索基盤を確認します。Amazon Bedrockのナレッジベース（Knowledge Bases）でも、AWS OpenSearch Serverless、Amazon Aurora PostgreSQL Serverless、Amazon Neptune Analytics、Amazon S3 Vectorsなど、構成に応じた選択肢があります。固有名詞や数値が多い場合は、ベクトル検索だけでなくハイブリッド検索やリランキングも検討します。取得精度が不安定なまま生成を調整しても改善は限定的です。まず検索を安定させます。

生成が弱いとき

検索評価は安定しているのに生成スコアが低い場合、最初に疑うのはプロンプト設計です。根拠の利用方法を明示しているか、引用や参照形式を指定しているか。ここが曖昧だと、モデルは取得情報を十分に使いません。

次に確認するのは回答フォーマットです。短く答えるべき質問に長文で返していないか。手順型なのに段落でまとめていないか。評価低下の原因が「構造」であるケースは少なくありません。

そのうえで拒否設計を見ます。根拠が不足している場合に無理に回答させる構成では、根拠整合性が下がります。回答不能時の挙動を定義していない設計は、スコアを不安定にします。

生成が弱いときにいきなりモデルを変更する必要はありません。多くの場合、プロンプトと制約設計の整理で改善します。

E2Eだけ悪いとき

検索評価も生成評価も一定水準なのに、E2Eスコアだけが低い場合があります。この場合は、接続部分を疑います。

• 取得した文書がプロンプトに正しく渡っているか。
• 整形処理で不要な削除や改変が起きていないか。
• トークン制限で重要情報が切り落とされていないか。

個別評価では見えない問題が、パイプラインの接続で発生していることがあります。E2Eだけが悪い場合は、構成全体を確認します。

改善の優先順位

改善は、影響範囲の小さい部分から始めます。

まずはプロンプトやフォーマットの調整など、設定変更で対応できる箇所を見ます。次にチャンキングやリランキングなど、構造変更を伴う調整に進みます。埋め込みモデルや基盤モデルの変更は最後です。

破壊的変更を先に行うと、原因の切り分けができなくなります。変更は一つずつ実施し、評価で確認します。診断の順番と改善の優先順位を決めておくことが、安定したRAG運用につながります。

RAG評価は「指標」ではなく「運用設計」で決まる

RAG評価が形骸化する原因は、評価結果を誰がどう使うのかが決まっていないことです。スコアは可視化され、ダッシュボードも整備されている。それでも改善につながらないケースは珍しくありません。

評価が意思決定のプロセスに組み込まれていないからです。どの指標が下がったら誰が判断し、どの変更を行うのか。その流れまで設計して初めて、評価は機能します。

評価が回るチーム体制

評価を継続させるには、責任の分界を明確にします。

• 業務側：回答が業務要件を満たしているかを判断する。KPIの妥当性を定義する。
• 開発側：検索・生成構成、モデル設定、パイプラインの改善を行う。
• 運用側：オンライン指標の監視、異常検知、ログ管理を担当する。

この役割が曖昧だと、スコアが悪化しても動きません。評価は組織設計とセットで考えます。

PoCで終わらせないための最短ステップ

PoCが単発で終わるのは、評価が継続設計になっていないためです。最小単位で回す場合、2週間単位で設計します。

• 1週目
  • 評価データセット整理、現状スコアの可視化
  • 改善仮説を一つに絞り、修正を実施
• 2週目
  • 再評価、差分確認
  • 結果を業務側と共有し、次の仮説を決定

変更は一度に複数加えず、一つずつ実施してその影響を評価で確認します。

評価設計から運用監視までを一気通貫で考える

評価はPoCで完結しません。本番監視まで含めて設計します。

• オフライン評価：改善のための検証
• オンライン評価：劣化検知
• ガバナンス評価：安全性・逸脱管理

この流れをあらかじめ設計しておくことで、属人化を防ぎます。評価指標を並べるだけでは不十分です。評価結果がどの判断につながるのかまで設計して、初めて運用に組み込まれます。

まとめ

RAG評価は、スコアを並べる作業ではありません。どこが悪いのかを切り分け、どの変更を入れるのかを判断するための仕組みです。

検索と生成を分けて見ること。オフラインとオンラインを分けて設計すること。評価データセットに判断基準を持たせること。これらが揃って初めて、改善は再現可能になります。

PoCの段階では成立性を確認し、本番では劣化と事故を監視します。評価はフェーズごとに役割が違います。指標を増やすよりも、誰がどの結果を見て何を決めるのかを明確にすることが重要です。

RAG評価は技術論で完結しません。運用設計として組み込めるかどうかで、成果が決まります。