RAG評価はリトリーバルから始めるべきです。正しい証拠がモデルに届かなければ、プロンプトの調整やモデルのアップグレードは、間違ったコンテキストをより説得力のあるものにするだけです。リトリーバル、生成、オペレーションを別々のステージとしてテストしてください。どのステージが悪化しても失敗する小さなバージョン管理された回帰セットを保持してください。
Reader level: 中級。このガイドは、リトリーバー増強生成(RAG)が、言語モデルに回答を求める前に文書を見つけることを知っていることを前提としています。
このガイドでは
RAG評価には三つの別々の失敗面があります
RAGアプリケーションはパイプラインです。最終的な回答のスコアは、どのコンポーネントが作業を必要としているかを隠します。
| 層 | 答えるべき質問 | 有用な出発点のメトリック |
|---|---|---|
| --- | --- | --- |
| リトリーバル | システムは質問に必要な証拠を見つけてランク付けしましたか? | ヒット率またはリコール@k、精度@k、MRRまたはNDCG |
| 生成 | モデルはその証拠を正しく使用しましたか? | グラウンディング、完全性、関連性、アブステンション |
| オペレーション | パイプラインは実際の制約の下で機能しましたか? | p95レイテンシ、コスト、エラーレート、新鮮さ、アクセス制御の失敗 |
順序は重要です。リトリーバルは上流です。ジェネレーターは、そのコンテキストに入らなかったポリシーの段落を引用することはできず、流暢な回答はリトリーバーが機能したことを証明するものではありません。
マイクロソフトの現在の RAG評価者ドキュメント は、実装用語で同じ分離を行っています。これは、ランク付けされた証拠のための文書リトリーバルメジャーを提供し、その後、回答層でグラウンディング、関連性、および応答の完全性を評価します。文書リトリーバル評価者には、忠実度、NDCG、XDCG、最大関連性、および欠落した関連性の判断が含まれています。

_有用なRAGスコアカードは、リトリーバル、生成、およびオペレーショナルチェックを別々の層として可視化します。_
なぜ一つのエンドツーエンドスコアが弱いデバッグ証拠を提供するのか
いくつかの研究フレームワークは、異なる方向から同じ実用的な結論に達しています。
RAGChecker は、リトリーバーとジェネレーターの動作を別々に評価します。その著者たちは、10のドメインにわたって8つのRAGシステムを比較しました。彼らのメトリックには、リトリーバルのための主張リコールとコンテキスト精度、生成のためのコンテキスト利用、ノイズ感度、幻覚、忠実度が含まれます。280ペアのメタ評価において、RAGCheckerの全体評価スコアは人間の好みとのスピアマン相関が0.609でした。二人の人間のアノテーターは0.689に達しました。自動評価は有用でしたが、人間のギャップを取り除くことはできませんでした。
Ragas は、忠実度、回答の関連性、およびコンテキストの関連性のための参照なしのメジャーを提案しました。そのWikiEval比較では、忠実度については人間の好みとの一致が0.95、回答の関連性については0.78、コンテキストの関連性については0.70でした。著者たちは、コンテキストの関連性を判断するのが最も難しいと感じました。それらの数字は、その研究からの結果として扱い、すべての評価者、データセット、またはドメインに対する普遍的な精度率ではありません。
新しいフレームワークであるRAGeは、コンポーネント選択とハードウェアテレメトリを追加します。これは、チャンク化、埋め込み、リトリーバル、ストレージ、生成にわたるパイプライン構成を評価し、レイテンシまたはVRAM制限を超える組み合わせを剪定します。この論文は、デフォルトでNatural Questions、NewsQA、およびTriviaQAを使用し、カスタムCSVまたはJSONデータセットをサポートします。その主な貢献は、リソース制約と品質を比較する方法であり、ドメイン全体で勝つ構成を確立するものではありません。
これらの論文は、診断アプローチを支持します。特定のメトリックやライブラリが生産に十分であることを証明するものではありません。
メトリックを選ぶ前にテストセットを構築する
提供するドメインから40〜60の質問を始めてください。その範囲は、統計的な法則ではなく実用的な出発点です。いくつかの失敗タイプを露呈するには十分大きく、すべての重要な変更の後に人間がレビューするには十分小さいです。
少なくとも5つのクエリクラスを含めてください:
生産ログは質問を示唆することがありますが、評価セットに例を追加する前に個人データや秘密を削除してください。最近の 生産RAG評価に関する実務者の議論 も、固定クエリ、バージョン管理された構成、および別々のリトリーバルと生成チェックを強調しています。その議論はワークフローペインに関する逸話的証拠であり、すべてのシステムでアプローチが機能する証拠ではありません。
安定した文書IDに対する判断を、コピーされたテキストと一緒に保存してください。スプリッターを調整するとチャンク境界が変わります。標準的なソースIDを使用すると、同じテストがその変更を生き残ることができます。
{ "query_id": "refund-window-01", "query": "未開封のアイテムを返品するための顧客の期間はどのくらいですか?", "relevant_document_ids": ["returns-policy-v4"], "required_claims": ["未開封のアイテムは30日以内に返品できます。"], "must_abstain": false, "allowed_roles": ["customer", "support"], "as_of": "2026-07-01" }
回答不能なケースの場合、`relevant_document_ids`を空のリストに設定し、`must_abstain`を`true`に設定します。制限されたケースの場合、同じクエリを2つの役割で実行します。認可されたユーザーは文書を取得するべきであり、認可されていないユーザーはその文書の内容を知るべきではありません。
独自のコーパスとアプリケーション層を構築しているチームは、テストセットとともにコンテンツ契約のバージョン管理を行うべきです。同じルールが、Next.jsとAIを使用して構築されたカスタムデータシステムにも適用されます:スキーマやコンテンツの変更は、プロンプトに触れずにリトリーバルを変更する可能性があります。
ステップ1:回答を生成せずにリトリーバルを評価する
各クエリをリトリーバーに通し、ランク付けされた結果のID、スコア、タイムスタンプ、およびアクセス決定を保存します。まだ言語モデルを呼び出さないでください。
証拠の形状に合ったメトリックを選択する
正しい文書が1つあれば十分な場合は、ヒット率@kを使用します。これは、最初の`k`結果に関連するソースが少なくとも1つ現れるかどうかを尋ねます。
回答に複数のソースが必要な場合は、リコール@kを使用します。これは、最初の`k`に現れた既知の関連文書の数を測定します。
無関係なコンテキストが高価または気を散らす場合は、精度@kを使用します。高いリコールと低い精度は、ジェネレーターをノイズで溢れさせる可能性があります。
最初の関連結果が最も重要な場合は、MRRを使用します。いくつかのグレード付き結果が有用な順序で表示されるべき場合は、NDCGを使用します。マイクロソフトは、評価者においてNDCGおよび関連するランク付けリトリーバルメジャーを文書化しており、RAGCheckerは、取得した証拠を回答に必要な主張に結びつけるために主張リコールとコンテキスト精度を使用しています。
デフォルトで全てのメトリックを収集しないでください。1つのカバレッジメジャーと1つのランク付けまたはノイズメジャーを選択してください。決定を変更する場合にのみメトリックを追加します。
モデルを変更する前にミスを分類する
リトリーバルの失敗は通常、小さなセットに分類されます:
各失敗には異なるオーナーがいます。再埋め込みは欠落した文書を修復できません。より大きな言語モデルは権限フィルターを修復できません。証拠が存在するが順序が悪い場合、再ランク付けが役立つかもしれません。
ツール接続アプリケーションの場合、リトリーバルリクエスト、フィルター、結果ID、およびツールの応答をトレースに保存します。これは、MCP開発者ワークフローで説明されている広範な制御パターンに適合します:契約、状態遷移、最終的な文章を検査します。
ステップ2:固定された証拠に対する生成を評価する
リトリーバルがその閾値を満たしたら、取得したコンテキストを固定し、ジェネレーターに対して再生します。これにより、プロンプトやモデルの変更をインデックスの変更から隔離します。
四つの動作を測定します:
参照回答は完全性に役立つことがあります。それは、いくつかの言い回しが正しい可能性があるため、唯一の真実のソースとしてはあまり有用ではありません。可能な限り、必要な主張とサポートする文書IDを保存してください。
意図的に不完全なコンテキストで二回目の生成テストを実行します。信頼できるシステムは、不確実性を露呈するべきであり、モデルメモリからギャップを埋めるべきではありません。これは、コーパスがプライベートで変化するか、ドメイン固有の事実を含む場合に重要です。
モデルの選択は依然として回答の品質、レイテンシ、およびコストに影響しますが、それはリトリーバル証拠の後に来ます。同じ固定コンテキストがジェネレーター間で失敗する場合は、モデルとAPIのトレードオフを比較してください。コンテキスト自体が間違っている場合、ジェネレーターを変更することは無駄な動きです。
セキュリティと対立ケースをリトリーバルスイートに追加する
通常の関連性テストは、敵対的または矛盾する証拠を見逃します。
2026年7月の論文 RAGにおける多形シビルポイズニング は、同じ攻撃者が選択した回答を支持する語彙的に異なるパッセージのグループをテストしました。この論文の強制露出設定の下で、多形パッセージは22.8%のハイジャック率を生成し、繰り返しの単形パッセージは4.0%でした。トークンオーバーラップフィルタリングは、すべての単形クラスターをキャッチし、どの多形クラスターもキャッチしませんでした。
この結果は、この攻撃が生産でどれほど成功するかを測定するものではありません。著者たちは、リーダーの行動を孤立させるために、取得したミックスを6つの攻撃パッセージ、2つのゴールドパッセージ、および2つのフィラーで固定しました。また、1つの攻撃クラス、データセットの汚染リスク、500の質問のアブレーション、およびLLMベースの検証に関する制限も報告しています。
有用な評価の教訓は狭いです:「正しい」と「攻撃者のターゲット」以上の分類を行います。この論文は4つの結果を追跡します:
対立ケースを自分のセットに追加してください。異なる言い回しの重複した主張、現在のポリシーと矛盾する古いソース、権威あるソースと矛盾する低信頼のソースを含めます。システムが回答するか、アブステインするか、ドリフトするかを記録します。
LLMの評価者をキャリブレーションする前に彼らのスコアを信頼しない
LLMの評価者は、特にグラウンディングと主張のカバレッジに対する回帰テストを安価にします。彼らは、プロンプト、モデルバージョン、パース動作、および既知の盲点を持つソフトウェア依存関係のままです。
4つのコントロールを使用します:
RagasとRAGCheckerの研究は、キャリブレーションが重要である理由を示しています。合意は次元によって異なり、自動相関は人間の合意を下回ります。数値スコアは検査を引き起こすべきであり、終わらせるべきではありません。
現在のオープンソースリリースも、評価者に関する積極的な作業を示しています。DeepEval 4.1.3は、2026年7月12日にリリースされ、エージェントループとツールの権限に対する決定論的チェックを追加し、Ragas統合を修正しました。TruLens 2.9.0は、2026年7月23日にリリースされ、評価者のアンサンブル、A/B基準テスト、スコア分布分析、およびゴールデンセット生成を追加しました。リリース活動は、維持されたエンジニアリング作業の証拠であり、どちらのライブラリがあなたのスタックに適しているかの証拠ではありません。
最小限のRAG回帰ワークフロー
すべての重要なパイプライン変更に対して同じシーケンスを使用します:
コンパクトな結果記録は次のようになります:
{ "run_id": "rag-2026-07-26-b", "test_set": "support-v7", "corpus_snapshot": "2026-07-25T22:00:00Z", "retrieval": { "recall_at_5": 0.91, "ndcg_at_5": 0.84, "unauthorized_hits": 0 }, "generation": { "grounded_pass_rate": 0.94, "complete_pass_rate": 0.87, "abstention_pass_rate": 0.90 }, "operations": { "p95_ms": 1380, "cost_per_query_usd": 0.0042 } }
これらの数字は例示的です。リスク、ベースライン、およびエラーコストから閾値を設定してください。医療知識アシスタントと製品検索ヘルパーは、同じリリースゲートを共有すべきではありません。
失敗した層から修正を決定する
| 症状 | 検査する証拠 | 最初の行動の可能性 |
|---|---|---|
| --- | --- | --- |
| 関連文書が欠如 | 取り込み状況、標準ID、フィルター | 取り込みまたはメタデータを修復する |
| 関連文書が低くランク付けされている | ランクトレース、クエリ用語、スコア | クエリの書き換え、ハイブリッドリトリーバル、または再ランクをテストする |
| 正しい証拠とサポートされていない主張 | 主張とコンテキストのマッピング | 生成指示またはグラウンディングゲートを厳しくする |
| 正しいが不完全な回答 | 必要な主張のカバレッジ | コンテキストの組み立てまたは回答プロンプトを修正する |
| 証拠が欠如しているときに回答する | ネガティブテストとアブステンショントレース | 証拠の十分性ゲートを追加する |
| 良好な品質だが遅い | ステージのタイミングとリソーステレメトリ | 測定されたボトルネックを最適化する |
| 無許可のソースが取得された | 身元、フィルター、結果ID | リリースをブロックし、認可を修復する |
この表がRAG評価のポイントです:失敗したスコアは次の実験を特定するべきです。それができない場合、そのメトリックは変更が必要なコンポーネントから遠すぎます。
証拠が支持するもの
これらの論文は特定のシステムとデータセットを測定しました。RAGCheckerは、モジュールメトリックが人間の好みと相関し、リトリーバーとジェネレーターのトレードオフを露呈できることを発見しました。Ragasは、評価者の合意が忠実度、回答の関連性、およびコンテキストの関連性にわたって異なることを発見しました。RAGeは、品質メトリックをレイテンシとメモリ制約と組み合わせるフレームワークを示しました。ポイズニングベンチマークは、制約された攻撃設定が明確なハイジャック、アブステンション、およびドリフトパターンを生成することを示しました。
証拠は普遍的な閾値、普遍的に最良の評価者、または生産攻撃の普及を確立するものではありません。私の実用的な解釈は、ステージを分け、人間キャリブレーションされたスライスを保持し、各メトリックがエンジニアリングアクションを指し示すことを要求することです。
主張チェック
| 主張 | 支持する証拠 | チェックされた境界 |
|---|---|---|
| --- | --- | --- |
| リトリーバルは回答の品質とは別に測定されるべきである | マイクロソフトRAG評価者;RAGChecker | アーキテクチャのガイダンス、普遍的な保証ではない |
| RAGCheckerは10のドメインにわたって8つのシステムを比較した | RAGChecker論文 | 結果はそのベンチマークとメトリック設定に依存します |
| Ragasは三つの次元で0.95、0.78、0.70の人間の合意を報告した | Ragas論文、表1 | 研究特有のペアワイズ精度 |
| RAGeはハードウェアテレメトリと構成剪定を含む | RAGe論文 | フレームワークの貢献、最良の構成の証明ではない |
| 多形パッセージは論文のアブレーションで22.8%のハイジャックを生成し、単形パッセージは4.0%であった | シビルポイズニング論文 | 強制的な6:2:2露出;生産の普及ではない |
| DeepEvalとTruLensは最近の評価機能を出荷した | 公式GitHubリリースノート | メンテナンスの信号、採用または品質の証明ではない |
