RAG 評価・Agent 評価・タスク完了率・レポーティング｜基礎を学ぶ

このレッスンで学ぶこと 対応試験ドメイン D5 タスク 5.1.5–5.1.9。RAG の忠実性・文脈精度・応答適合性を定量化する観点、Bedrock Agents のタスク完了率を計測する方法、LLM-as-judge パターンの正しい位置づけ、そして評価結果のレポーティング設計を理解します。

解説

RAG（Retrieval-Augmented Generation）と Agents は生成部分だけでなく検索・実行ステップも含む複合パイプラインです。単一の精度指標では全体の品質を捉えられないため、段階ごとに異なる指標を組み合わせる評価フレームワークが必要になります。試験では「どのシナリオでどの指標・サービスを選ぶか」の設計判断が問われます。

RAG 評価の主要観点（RAGAS 観点）

RAGAS は OSS の評価フレームワーク（パターン）であり、AWS マネージドサービスではありません。ただし AWS の試験ガイドでは RAGAS が定義する観点を評価軸として参照しています。主要観点は次のとおりです。

観点	問いかける内容	計測のヒント
忠実性（Faithfulness）	回答が検索チャンク内の情報だけに基づいているか	回答文と参照チャンクの矛盾検出（LLM-as-judge）
文脈精度（Context Precision）	上位 K 件の検索結果がどれだけ関連しているか	正解文書の順位・Recall@K
文脈再現性（Context Recall）	正解に必要な情報が検索結果に含まれているか	golden dataset との照合
応答適合性（Answer Relevancy）	回答がユーザーの質問に正しく答えているか	埋め込みコサイン類似度 / LLM-as-judge

試験で「RAG の回答が幻覚を含む場合に最初に診断すべき指標は何か」と問われた場合、忠実性が最初の診断ターゲットです。

LLM-as-judge パターン

LLM-as-judge とは、別の FM（審判モデル）が生成された回答を採点するパターンです。Amazon Bedrock Model Evaluation のカスタム評価（LLM Evaluation）としても実装できます。設計上の注意点は以下のとおりです。

審判モデルと評価対象モデルを同一にすると採点が甘くなります（自己評価バイアス）。異なるモデルを審判に使うことが推奨されます
採点基準（ルーブリック）をプロンプトに明示しないと審判の判断が一貫しません
審判自体も幻覚を起こす可能性があるため、高リスク用途では人手との二重確認が必要です

Python

import boto3, json

client = boto3.client("bedrock-runtime", region_name="us-east-1")

# 審判プロンプト例（忠実性チェック）
judge_prompt = """
以下の「参照テキスト」と「モデル回答」を確認してください。
モデル回答が参照テキストに含まれない情報を主張している場合は FAIL、
そうでなければ PASS と答えてください。理由も一言で述べてください。

参照テキスト:
{context}

モデル回答:
{answer}
"""

resp = client.converse(
    modelId="anthropic.claude-3-5-sonnet-20241022-v2:0",
    messages=[{"role": "user", "content": [{"text": judge_prompt}]}],
)
print(resp["output"]["message"]["content"][0]["text"])

Bedrock Agents のタスク完了率

Bedrock Agents のようなマルチステップエージェントを評価する場合、単一の出力精度だけでは不十分です。タスク完了率（Task Completion Rate）は「ユーザーの最終目標が達成されたか」を測る指標です。

計測の考え方は次のとおりです。

テストシナリオを設計する（例: 「商品を注文してキャンセルするまでの一連のフロー」）
エージェントが正しいツールを呼び出したか、正しい順序で呼び出したか、最終的に正解の状態に到達したかを確認する
ステップ単位の成功率とエンドツーエンドの完了率を分けて記録する

Amazon Bedrock Agents の実行トレース（invoke_agent の trace オプション）を有効にすると、各ステップの入出力が記録されます。これを CloudWatch Logs に送り、Logs Insights で集計することでタスク完了率を算出できます。

評価レポートの設計

評価結果は単なる数値一覧ではなく、意思決定につながる形で構造化する必要があります。実務・試験ともに重要な観点は以下のとおりです。

ベースラインとの差分比較 ― 現バージョンと前バージョンのスコアを並べ、回帰が起きていないことを確認します
カテゴリ別の内訳 ― 全体の平均スコアだけでなく、質問カテゴリ・難易度別に内訳を示します
信頼区間の提示 ― サンプル数が少ないと偶然の揺れが大きいため、信頼区間とサンプルサイズを明記します
失敗例のカタログ ― 低スコア例を具体的に列挙することで、次の改善仮説を立てやすくします

試験で問われるポイント

RAGAS は AWS マネージドサービスではない点が頻出のひっかけです。試験で「RAGAS で評価する」と書かれていたら、それは評価の観点・フレームワークを指しており、AWS コンソールから直接呼べるサービスではありません。AWS での実装は Bedrock Model Evaluation またはカスタムスクリプトになります
LLM-as-judge の自己評価バイアス ― 同一モデルを審判に使う設計は誤りです。審判と評価対象は別モデルにすることが正しい設計として問われます
タスク完了率 vs 応答精度 ― 単一ターン回答の精度指標（例 BERTScore）とエージェントのエンドツーエンド完了率は別物です。「マルチステップエージェントの品質を測るには何が適切か」と問われたら、タスク完了率と実行トレース分析が正答になります

サービスの使い分け早見表

やりたいこと	使うもの	混同しやすいもの
RAG の忠実性を定量評価したい	Bedrock Model Evaluation（LLM Judge モード） + RAGAS 観点	SageMaker Model Monitor（推論後ドリフト監視が目的）
エージェントの実行ステップを可視化したい	Bedrock Agents の実行トレース + CloudWatch Logs Insights	X-Ray（サービス間の分散トレースが目的）
評価データが少ないので合成 Q&A を補いたい	Bedrock（FM）による合成データ生成 → 人手フィルタリング	全量を合成データに置き換えること（試験では誤り）

まとめ

RAG 評価では忠実性・文脈精度・文脈再現性・応答適合性の 4 観点（RAGAS 観点）を組み合わせます。LLM-as-judge は有力な手法ですが審判モデルの独立性とルーブリックの明示が前提です。Bedrock Agents のタスク完了率は実行トレースを CloudWatch Logs に集計して測定します。評価レポートはベースライン比較・カテゴリ内訳・失敗例カタログを含む形で設計します。

次のステップ

次のクイズレッスンで、本番形式のシナリオ問題に挑戦して理解度を確認しましょう。