RAGの試行環境を動かすと、「悪くはないが、ときどき妙な答えを返す」という状態でしばらく止まることがあります。ここから先へ進むには、妙な答えの原因が検索にあるのか、生成にあるのか、そもそも根拠になる文書が社内に無いのかを、分けて言えなければなりません。この記事では、回答品質を何で測り、検索と生成のどこが悪いかをどう切り分けるかを、Microsoft・AWS・Google の各評価機能が実際にどう作られているかに沿って整理します。
対象は、RAGの試行環境をすでに動かしていて、次に直す箇所を決めたい担当者です。RAGそのものの解説、文書のクリーニング作業、どこでも通じるチャンク設定、特定クラウドの操作手順、唯一の合格ラインの提示は扱いません。RAGの仕組みはRAGとは何か、導入前の文書整備はRAG導入前の社内文書整備で扱っています。
本記事が挙げる指標名、既定値、プレビュー状態は、いずれも各社の公式ドキュメントを確認日（2026年8月15日）時点で参照したものです。これらは各社の製品仕様であって業界標準ではなく、名称も既定値も提供状態も変わりえます。
1. 良い回答だけでは、失敗箇所を特定できない
RAGの回答は、文書を取り出す工程と、それをもとに文章を作る工程の二段構えで生まれます。最終回答だけを採点すると、この二つが一つの数字に混ざります。検索が的外れでもモデルの一般知識で当たり障りのない答えが組み上がることがあり、逆に文書は取れていたのに生成が条件節を落とすこともあります。前者は検索設定や文書側、後者はプロンプトやモデル側と、打ち手が違います。
Microsoft Foundry のドキュメント『Retrieval-Augmented Generation (RAG) Evaluators for Generative AI』は、この二工程を分けて扱う構成になっています。最終回答の品質を見るものを system evaluation、検索工程の品質を見るものを process evaluation と呼び分けています。この呼び分けは同社ドキュメント内の用語であって、業界共通の用語ではありません。同ドキュメントは、検索がRAGの上流にあるため検索品質が重要であり、検索品質が低く回答にコーパス固有の知識を要する場合には、言語モデルが満足のいく回答を返す見込みは下がる、とも述べています。
2. 測る前に、条件を固定する
評価結果が動いたとき、手を入れた箇所の効果なのか別の要因かを言えなければ、改善の判断はできません。測定の前に条件を書き出して固定します。
Google Cloud の Agent Search のドキュメント『Evaluate search quality』は、同じサンプルクエリセットを使うことが一貫性があり再現可能な測定の前提になるとし、検索の挙動は定期的に更新されるため評価を定期実行できるとも述べています。測る対象そのものが動くという前提です。なお同機能はプレビュー（Preview）と表示され、一般提供前の製品・機能は現状有姿で提供されサポートが限定される場合があるとされています。
質問側を固定する考え方を、環境側にも広げます。以下の一覧は本記事による整理であり、参照した各社のドキュメントが固定項目の一覧を定めているわけではありません。
- 対象コーパスと、その時点：文書が増減しただけで数値は動きます
- 権限（誰として実行するか）：管理者権限だけで測ると、権限の狭い利用者から見た結果が分かりません
- 検索設定：検索方式、取得件数、分割の大きさ。比較したい変更以外は動かしません
- プロンプト・生成モデル・評価者モデル：いずれも結果を動かす変数です
- 実施日：対象システムの挙動は時間とともに変わります
3. 代表質問に「期待する根拠」を結びつける
抜けやすいのは、質問ごとに「何が返れば成功か」を先に書くことです。出てきた答えを見てから決めると、判定が甘くなります。
Google の『Evaluate search quality』は、サンプルクエリセットを Queries（質問）と Targets（期待される文書の URI）の組で持ちます。ページ番号を含めればページ単位で比較されますが、その照合には extractive answers の有効化が必要とされています。質問は多様な質問群が推奨されていますが、参照した各社のドキュメントに適切な件数の推奨は見当たりませんでした。
| 結びつける項目 | 何を書くか | 製品側の対応 |
|---|---|---|
| 期待する根拠文書 | どの文書のどの箇所が根拠として出てほしいか | Google のサンプルクエリセットは期待文書の URI を持つ。Microsoft Foundry の Document Retrieval は文書ごとの人手ラベルを要求する |
| 期待する要点 | 回答に必ず含まれてほしい情報 | Amazon Bedrock の Context coverage は ground truth の指定を必須とする。Microsoft Foundry の Response Completeness（プレビュー）も ground truth との比較を前提とする |
| 権限 | どの利用者の権限で投げる質問か | 各社ドキュメントに記述なし（本記事の整理） |
| 鮮度 | いつ時点の情報が答えとして正しいか | 各社ドキュメントに記述なし（本記事の整理） |
| 失敗条件 | この質問で何が起きたら失敗とみなすか | 各社ドキュメントに記述なし（本記事の整理） |
下3行は本記事が実務上必要と考えて置いた欄です。
4. 検索だけを取り出して評価する
Amazon Bedrock のドキュメント『Evaluate the performance of RAG sources using Amazon Bedrock evaluations』は、RAG評価ジョブを Retrieve only（検索のみ）と Retrieve and generate（検索と生成）に分けています。Retrieve only は Knowledge Base か外部RAGソースの持ち込みを、Retrieve and generate は Knowledge Base と応答生成モデルの組み合わせか持ち込みを選べるとされ、自社構成のRAGでも評価側だけ使えます。同社の『Use metrics to understand RAG system performance』は、Retrieve only 用の組み込み指標として Context relevance と Context coverage（取得テキストが ground truth の情報をどれだけ覆っているか）の2つを挙げています（別途カスタム指標も定義できるとされています）。
Microsoft Foundry は検索評価をさらに2種類に分けています。Retrieval は関連度を LLM judge で測り正解ラベルを要しません。Document Retrieval は人手ラベル付きの正解と突き合わせるもので、同ドキュメントはこちらを「最も精密な測定」と位置づけています。その指標群には Holes（正解ラベルが欠けている文書の数）が含まれ、評価データ側の欠損そのものを測る指標が組み込まれています。Google の『Evaluate search quality』（プレビュー）は docRecall、docPrecision、docNdcg などをカットオフ別に返します。
3社を並べて分かるのは、正解ラベルを用意するかどうかで使える指標が変わるという構造です。
5. 回答側を分けて見る──根拠性、関連性、網羅性、引用
以下の区分は本記事が置いたものです。「RAG評価はこれらを測るのが標準」という業界の合意はありません。
根拠性。 Microsoft Foundry の Groundedness は、回答が与えられた文脈にどれだけ沿い、内容を捏造していないかを測ります。Amazon Bedrock の Faithfulness は、取得したテキストに照らして hallucination をどれだけ避けられているかを測るとされています。Google Agent Search の check grounding API は、回答候補が与えられた事実とどれだけ一致するかを 0 から 1 の support score で返します。3つに共通するのは、いずれも「与えた材料に照らして」の測定だという点です。材料の外側での真偽、つまり社内文書そのものが間違っている場合は、これらの指標では捉えられません。なお Microsoft の Groundedness Pro はプレビュー表記で、数値ではなく True/False を返します。
関連性。 Microsoft Foundry の Relevance は、回答の正確さ・網羅性・直接的な関連性を測るとされています。定義文自体に網羅性が含まれる点に注意が要ります。
網羅性。 Response Completeness（プレビュー）は、期待される情報を回答がどれだけ覆っているかを ground truth と比べて測ります。同ドキュメントは Groundedness を precision 側、Response Completeness を recall 側として対比しています。
引用。 Amazon Bedrock は Citation precision と Citation coverage を組み込み指標として持っています。Google の check grounding API は、回答候補の各主張に対して裏付けとなる事実への citation を返し、citation threshold（0〜1、未設定時の既定値は 0.6）で確信度を制御します。この 0.6 は合否ラインではなく、引用を出すか出さないかの確信度の既定値です。
「根拠が無いときに答えない」を直接測る指標は見当たりませんでした。
Amazon Bedrock には Refusal という組み込み指標がありますが、これは 「how evasive the responses are」（回答がどれだけはぐらかされているか）を測るものであり、「適切に断れたか」を測るものではありません。Google の check grounding API は主張ごとに groundingCheckRequired という真偽値を返し、「Here is what I found.」のようにそれ自体が事実ではない文を根拠確認の対象外にします。根拠が要る文と要らない文を分ける発想は実在しますが、答えないほうが正しい場面で答えなかったかを測る指標は、参照した3社のドキュメントには見当たりませんでした。この観点を持つなら、自動評価ではなく人が見る項目として置くことになります。
6. 失敗を4層に切り分ける
以下の4層への切り分けは本記事による整理です。
| 層 | 先に確かめること |
|---|---|
| source （根拠が存在しない） | 期待した文書がそもそもコーパスに入っているか。最新版か |
| retrieval （取り出せていない） | 取得結果に期待文書が含まれるか。含まれるなら何位か |
| generation （材料はあるのに外す） | 根拠性・網羅性・引用の指標が落ちているか |
| permission （各社ドキュメントに評価方法の記述なし／本記事の整理） | 誰の権限で実行したか。権限の異なる利用者で同じ質問を投げたときの差分 |
症状と変更の当たり先は上の図にまとめています。source を先に確かめないと、retrieval の調整が空振りしやすくなります。 検索指標の数値だけでは見分けが付きません。数値が低いという事実は同じで、原因だけが違うためです。permission は他の3層と直交します。
この4層の分け方、とくに permission を独立した層として置くこと、および「期待した文書がコーパスに存在するかを先に確かめる」という切り分け手順は、本記事の整理です。参照した3社のドキュメントは、権限に起因する失敗の評価方法を扱っていません。本記事が参照した評価機能の範囲では permission を直接測れないため、別の評価が必要になります。
自動評価と人の確認、それぞれの限界
自動評価はどこまで信じてよいのか、という問いには、各社のドキュメント自身がかなり率直に答えています。
Google の check grounding API は、support score について 「It loosely approximates the fraction of claims in the answer candidate that were found to be grounded in one or more of the given facts.」（回答候補の主張のうち、与えられた事実の1つ以上に接地していると判定された割合を、おおまかに近似する）と説明しています。製品自身が「おおまかな近似」と書いているわけです。判定の単位についても、このバージョンのAPIでは1文を1つの主張として扱うとし、部分的にしか含意されない主張は接地しているとみなさないと述べています。文の切り方が変われば結果も変わりうる、ということです。
判定を行うモデルも変数です。Microsoft Foundry の Retrieval は LLM judge を使い、Amazon Bedrock では利用者が選んだ evaluator model が指標を算出します。評価者モデルも節2の固定対象に入ります。人手にも限界があり、Document Retrieval が要求する人手ラベルについては、同じ指標群に Holes（正解ラベルが欠けている文書の数）が含まれています。人手ラベルは欠落しうるものとして設計に織り込まれている、と読めます。
提供状態は機能単位で違います。本記事の参照範囲では、Microsoft Foundry の Groundedness Pro と Response Completeness にプレビュー表記があり、同社の他の evaluator にはありません。そのうえで、数値に現れにくい失敗（意味の通り、社内規程や法令との整合、出してはいけない情報の混入）は人の確認で補う必要があります。これを確認項目として明示的に持つことは本記事の整理です。
7. 合格点を作るのではなく、重大な失敗と変更前後を見る
参照した範囲で既定の合否しきい値に相当するものは、Microsoft Foundry の1〜5で返す evaluator の「既定の合格しきい値は3」1件だけです。これはその製品の既定値であって、推奨基準でも業界の合格ラインでもありません。各社の数値は尺度が異なり（Microsoft Foundry は1〜5、Google は0〜1）、測っている対象も違うため、製品をまたいでそのまま直接比較・換算はできません。
単一の数字にまとめることの危うさは、Microsoft Foundry のドキュメントに載っている出力例からも読み取れます。同じ Document Retrieval の出力のなかで、ndcg@3 が 0.646 で pass、fidelity が 0.019 で fail と示されています。同じ評価の同じ検索結果に対して、指標ごとに合否が割れているわけです。順位の付き方は悪くないが、既知の良い文書をほとんど拾えていない、という状態がありうるということです。総合点にまとめれば、この情報は消えます。
そこで、本記事は次の2つを見ることを提案します。この整理と分類は本記事によるものです。
- 重大な失敗の有無：権限外の文書が根拠に出た、廃止済み文書が根拠になった、材料に無い数値が回答に書かれた、といった事象。平均値ではなく、件数がゼロかどうかで見ます。何を重大とみなすかは組織ごとに違うため、質問票の失敗条件（節3）とそろえて先に定義します
- 変更前後の差：しきい値との比較ではなく、直前の測定との比較で見ます。Google の『Evaluate search quality』（プレビュー）も、検索構成の変更の影響を理解するために過去の評価結果を比較する、という使い方を挙げています
変更したら測り直す
Google の『Evaluate search quality』（プレビュー）は、検索構成やチューニングを変えた場面を評価の使いどころとして挙げ、変更していなくても検索の挙動が定期的に更新されるため定期実行できるとも述べています。
Microsoft Foundry のドキュメントは、検索アルゴリズム、top_k、チャンクサイズごとに取得結果を生成し、Document Retrieval で最も品質の高い設定を見つける使い方を示しています。分割の大きさや検索方式は、決め打ちせず振って比べる対象として扱われています。
一方、文書を差し替えたとき、プロンプトを書き換えたとき、生成モデルを更新したときに再評価する、という運用は、参照した3社のドキュメントには明記がありません。本記事による整理です。ただし節2で見たとおり、これらはいずれも結果を動かす変数として各社の仕組みのなかに現れています。変数である以上、動かしたら測り直す、と考えるのが自然だと思われます。
Google の『Evaluate search quality』には、クエリ件数や1日あたりの評価リクエスト数などのクオータが記載されています。これは Google の製品制約であって一般則ではありません。上限件数を推奨件数と読み替えないでください。 実務上は変更を1つずつ分けて試すことです。同時に変えれば、数値が動いても原因は特定できません。
8. 評価記録に何を残すか──まとめ
1回の評価で残す項目です。この一覧は本記事の整理であり、各社のドキュメントが定めているものではありません。
- 実施日と、対象コーパスの時点
- 誰の権限で実行したか
- 検索設定（方式、取得件数、分割）、プロンプト、生成モデル、評価者モデル
- 使用した質問セットとその版
- 指標ごとの結果（総合点にまとめない）と、前回測定との差
- 重大な失敗の有無と、あった場合の内容
- 人が確認した項目と、確認者
- この結果を受けて次に変える1点
RAGの品質評価で最初に効くのは、指標を増やすことではなく、検索と生成を分けて測れる状態を作ることです。そのうえで、期待した文書が出ているかを先に見て、出ているのに答えが外れるときだけ生成側を触る。この順序で進めると、打ち手と結果を対応づけやすくなります。本記事が参照した Microsoft・AWS・Google の評価機能は、いずれも各社製品の仕様であって、共通の評価基準ではありません。
まずは代表質問を書き出し、それぞれに期待する根拠文書を1つ結びつけた表を作ってください。件数は目的ではありません。その表ができた時点で、検索だけを取り出したテストが走らせられる状態になります。
引用元・参考文献
- Microsoft Learn『Retrieval-Augmented Generation (RAG) Evaluators for Generative AI』（Microsoft Foundry／確認日：2026年8月15日）：system evaluation と process evaluation の分離、Retrieval / Document Retrieval、Groundedness / Relevance / Response Completeness、検索品質指標、既定のしきい値、パラメータ探索：原文
- Amazon Web Services『Evaluate the performance of RAG sources using Amazon Bedrock evaluations』（Amazon Bedrock User Guide／確認日：2026年8月15日）：retrieve only と retrieve and generate の2種類の評価ジョブ：原文
- Amazon Web Services『Use metrics to understand RAG system performance』（Amazon Bedrock User Guide／確認日：2026年8月15日）：ジョブ種別ごとの組み込み指標：原文
- Google Cloud『Check grounding with RAG』（Agent Search／確認日：2026年8月15日）：support score、citation、claim 単位の判定、citation threshold：原文
- Google Cloud『Evaluate search quality』（Agent Search、プレビュー／確認日：2026年8月15日）：サンプルクエリセット、検索品質指標、過去結果の比較、クオータ：原文
上記5件はいずれも各社の製品ドキュメントであり、業界標準を定めるものではありません。指標名、定義、既定値、プレビュー／一般提供の状態は変更されることがあります。本記事は上記資料を確認日（2026年8月15日）時点で参照しています。