ひとことで言うと
モデルとナレッジベースの出来を、非同期のジョブとして採点してレポートを S3 に残す仕組みです。採点者を ①統計指標 ②判定用の別 LLM ③人間ワーカー の3種類から選べ、RAG については検索だけと検索＋生成を別のジョブ種別として分けて測れます。
要するに、答案の採点方式を選べる採点場です。選択式なら機械採点（自動評価）、記述式なら別の採点者に読ませる（LLM-as-a-judge）、志望動機のような主観の塊なら人間の面接官（人間評価）。「良し悪しの基準を誰が持つか」を先に決める道具であって、良くしてくれる道具ではありません。
なぜ生まれたか
生成の品質は、従来の ML の精度指標では測れません。正解文字列との一致で採点できないうえ、同じ出力が用途によって合格にも不合格にもなるからです。
| 測りたいもの | 従来の指標が効かない理由 | ここでの答え |
|---|---|---|
| 事実として正しいか | 表現が違えば文字列一致は取れない | 参照回答（ground truth）があれば加味する Correctness を判定 LLM が採点 |
| 根拠から離れていないか（ハルシネーション） | 文章として自然なので、流暢さの指標では素通りする | 与えた文脈に無い情報が混ざっていないかを見る Faithfulness |
| RAG のどこが悪いのか | 最終回答だけ見ても、検索が外したのか生成が外したのか分からない | retrieve only と retrieve and generate をジョブ種別として分ける |
| ブランドトーン・受け入れられ方 | そもそも自動で定義できない | 人間ワーカーの評価、またはカスタム指標 |
| 有害性・偏り | 自社データだけでは網羅できない | 公開ベンチマークの組み込みデータセットを使う自動評価 |
公開日付を年表にできる記述が公式ドキュメント側に無いため、経緯の構造だけ置きます。「採点者を差し替えられるように作った」——これが設計の中心で、指標の一覧はその帰結です。
何に使うか
| ジョブ種別 | 何を測るか | 覚えておく固有の点 | 関連ドメイン |
|---|---|---|---|
| 自動（プログラム的）評価 | タスク型ごとの統計指標 | タスク型は一般テキスト生成 / 要約 / 質問応答 / テキスト分類の4つ。組み込みデータセット（TREX・BOLD・RealToxicityPrompts・Gigaword・BoolQ・NaturalQuestions・TriviaQA 等）が使える | D5.1 |
| LLM-as-a-judge | 判定モデルが応答を採点し、採点理由の説明も返す | 生成モデルと評価モデルの2つを指定する。組み込み指標のほかカスタム指標も定義できる | D3.4 / D5.1 |
| 人間評価 | 人が主観で評価・比較する | 推論ソースは最大2つまで。カスタムプロンプトは最大1000件。1プロンプトあたりのワーカー数を指定する | D3.4 / D5.1 |
| RAG 評価（retrieve only） | 検索そのものの質 | 指標は Context relevance と Context coverage の2つだけ | D5.1 |
| RAG 評価（retrieve and generate） | 検索＋生成の最終品質 | Citation precision / Citation coverage など、引用の正しさを見る指標がここにしかない | D5.1 |
評価対象は Bedrock の基盤モデルに限りません。Bedrock Marketplace のモデル・カスタマイズしたモデル・インポートしたモデル・プロンプトルーター・プロビジョンドスループットを買ったモデルが対象で、さらに自分で推論結果を持ち込めば Bedrock 外のモデルや外部の RAG も採点できます（この場合 Bedrock は呼び出しを飛ばして採点だけを行います）。
試験でどう問われるか
D5（11%）の主役で、D3.4「責任あるAI」にも顔を出します。「品質が落ちた」「良し悪しをどう測るか」というシナリオでは、まずここが疑われます。指標の名前と、その指標が retrieve only 側か retrieve and generate 側かの対応が、そのまま得点になります。
| 問われ方 | 正解に寄る条件 | 引っかけの選択肢 |
|---|---|---|
| 「回答が根拠文書に無いことを言う」 | Faithfulness（与えられた文脈に無い情報が混ざっていないかを見る） | Correctness（正しさは測るが、根拠からの逸脱そのものを見ていない）／Relevance |
| 「RAG の精度が悪い。検索と生成のどちらが原因か」 | retrieve only ジョブを回して Context relevance を見る。検索を切り離して測るのが目的 | いきなり retrieve and generate の Correctness を見て、生成モデルを差し替える案 |
| 「検索が必要な情報を取りこぼしていないか」 | Context coverage。この指標だけは ground truth（期待される取得テキスト）が必須 | Context relevance（取ってきたものが関連しているかは見るが、取りこぼしは見ない） |
| 「回答に付いた引用が正しいか確かめたい」 | Citation precision / Citation coverage。retrieve and generate ジョブにしかない | retrieve only ジョブでこれを測ろうとする案 |
| 「毒性・ステレオタイプをベンチマークで測りたい」 | 組み込みデータセットを使う自動評価（RealToxicityPrompts / BOLD など）。加えて判定 LLM 側にも Harmfulness / Stereotyping / Refusal がある | Guardrails で測る（Guardrails は実行時に止めるもので、評価レポートは出さない） |
| 「ブランドトーンへの適合を評価したい」 | 人間評価、または LLM-as-a-judge のカスタム指標（組み込みには Professional style and tone がある） | 自動評価のタスク型から選ぼうとする（4つのタスク型に該当しない） |
| 「Bedrock 以外のモデルを同じ土俵で比べたい」 | プロンプトデータセットに自分の推論結果を持ち込む（bring your own inference responses） | 「Bedrock のモデルしか評価できないので SageMaker 側で行う」 |
| 「エージェントのゴール達成率・ツール呼び出しの正確さを測りたい」 | これは Bedrock Model Evaluations の守備範囲外。エージェントの評価は Amazon Bedrock AgentCore 側の Evaluations | Model Evaluations の LLM-as-a-judge で測る案 |
| 「デプロイのたびに品質を機械的にゲートしたい」 | 評価ジョブ＋ゴールデンデータセットで回帰テストを組む（D4.3 / D5.1） | CloudWatch のエラー率だけで品質ゲートを作る案 |
指標名が両方に出てくるものに注意します。Correctness / Completeness / Helpfulness / Faithfulness / Harmfulness / Stereotyping / Refusal は、LLM-as-a-judge のモデル評価にも、retrieve and generate の RAG 評価にも出ます。逆に Context relevance / Context coverage は RAG の retrieve only 専用、Citation precision / Citation coverage は retrieve and generate 専用です。「どの指標か」だけでなく「どのジョブ種別で選べるか」が問われます。
実務でどう使うか
- 判定モデルにもモデルアクセスの許可が要ります。 評価対象のモデルを有効化しただけでは動きません。組み込み指標で使える判定モデルとカスタム指標で使える判定モデルはリストが違うので、カスタム指標を前提に設計するときは先に確認します
- 人間評価を API から作るなら、先に SageMaker AI のフロー定義が要ります。
CreateFlowDefinitionでAwsManagedHumanLoopRequestSourceにAWS/Bedrock/Evaluationを指定し、HumanTaskUiArnは AWS 所有の ARN をリージョンだけ書き換えて使います。コンソールから作る場合はこの手順が隠れているので、API に移した瞬間に詰まります - 評価方式（
ratingMethod）はカスタム指標ごとに選びます。 Thumbs up/down・Likert scale（個別／比較）・Choice buttons・Ordinal ranking があり、評価手順書（instructions）に「1と5が何を意味するか」を書くのは作成者の仕事です。書かないとワーカーごとに基準がずれます - ワーカーには有害・不快な出力が表示される可能性があると公式が明記しています。 事前の説明と、タスクを辞退・中断できる運用を用意します
- 人間評価のワークチームは Amazon Cognito で管理されます。 コンソールから作る場合、IAM に Bedrock・SageMaker AI・Cognito・S3 の権限がまとめて要ります
- レポートの実体は S3 です。 コンソールの指標カードはスコアの分布と最初の数件の説明しか見せません。全件は指定した S3 バケットに出るので、回帰比較をするならそちらを機械で読みます。コンソールで結果を見るには S3 バケット側の CORS 設定が要ります
- 評価ジョブの管理イベントは CloudTrail に出ます。 「誰がいつどのモデルを評価したか」はここで追えます
評価は「回した瞬間」の写真でしかありません。ジョブは非同期で、走らせた時点のモデル・ナレッジベース・プロンプトの組み合わせを採点します。ナレッジベースを同期し直せば Context relevance は変わり、プロンプトの版を上げれば Faithfulness は変わります。数字を比べるときは、何を固定して何を動かしたかを先に決めておかないと、前回のレポートと比較する意味がなくなります。
取り違えやすいもの
| 迷う相手 | 切り分けの一言 |
|---|---|
| Amazon Bedrock Guardrails | Guardrails は実行時に止める。Model Evaluations は事後に採点して記録を残す。「ブロックしたい」か「測りたい」かで割れる |
| Amazon Bedrock AgentCore の Evaluations | エージェントのゴール達成・ツール呼び出し・本番トラフィックの継続監視はそちら。Model Evaluations が見るのはモデルとナレッジベース |
| SageMaker Clarify | Clarify は学習データとモデルのバイアス・説明可能性。こちらは生成された応答の質。見ている対象が入力側か出力側かで違う |
| SageMaker Model Monitor | Model Monitor はデプロイ済みエンドポイントのドリフト監視（継続）。Model Evaluations はジョブ単位の採点（点） |
| Amazon A2I（Augmented AI） | A2I は本番の推論に人間レビューを差し込む仕組み。人間評価はあくまで評価ジョブで、本番のリクエストには関与しない |
| Prompt management の Compare variants | あちらは人が見比べて1つ選ぶ場。こちらは指標で採点してレポートを残す場。回帰テスト・品質ゲートに使えるのは後者だけ |
想起チェック
Q1. RAG の「検索が悪いのか生成が悪いのか」を切り分けるには、どのジョブ種別と指標を使いますか。
retrieve only ジョブを回し、Context relevance（取ってきた文脈が質問に関連しているか）と Context coverage（ground truth の情報を取りこぼしていないか）を見ます。生成を挟まないので、検索の質だけが残ります。
Q2. ground truth（参照回答）が必須の指標を1つ挙げてください。
Context coverage です。取得テキストが ground truth の情報をどれだけ覆っているかを測るため、参照が無いと成立しません。Correctness や Completeness は ground truth があれば採点に加味されますが、必須ではありません。
Q3. 「エージェントのツール呼び出しが正しいかを継続的に測りたい」。Bedrock Model Evaluations で対応できますか。
できません。 エージェントの評価は Amazon Bedrock AgentCore の Evaluations 側の機能です。Model Evaluations が対象にするのはモデルとナレッジベース（および外部の RAG ソース）です。
Q4. Bedrock に載っていない自社ホスティングのモデルを、同じ指標で比較できますか。
できます。 プロンプトデータセットに自分の推論結果を持ち込むと、Bedrock はモデル呼び出しを飛ばして採点だけを行います。人間評価では、この形で最大2つの推論ソースを並べて比較できます。