FM 評価フレームワーク・golden dataset・合成ワークフロー｜基礎を学ぶ

このレッスンで学ぶこと 対応試験ドメイン D5 タスク 5.1.1–5.1.4。Amazon Bedrock Model Evaluation の評価モード・指標・golden dataset の設計方針、LLM による合成データ生成ワークフロー、そして A/B テストとカナリアデプロイを使った段階的モデル切り替えの考え方を理解します。

解説

FM の評価は「感覚的によさそう」では不十分で、定量指標と再現可能なデータセットに基づく体系的な評価フレームワークが必要です。試験では「どのシナリオでどのサービス・手法を選ぶか」という設計判断が問われます。

Amazon Bedrock Model Evaluation

Amazon Bedrock Model Evaluation は、複数の FM を同一条件で比較・スコアリングするマネージドサービスです。評価方式は大きく 3 種類あります。

評価方式	概要	向いているケース
自動評価（Automatic Evaluation）	BERTScore・Accuracy・Robustness など組み込み指標で自動採点	大量プロンプトを低コストでスコアリングしたいとき
人間評価（Human Evaluation）	Amazon SageMaker Ground Truth または AWS Managed Team による人手採点	品質が繊細でルールベース指標では測れないとき
LLM-as-judge（カスタム指標）	審判役の FM が出力を採点する。パイプラインとして設定	人手ほどコストをかけずに細かい品質観点を評価したいとき

Bedrock Model Evaluation は ジョブとして非同期実行され、結果は S3 に JSON で出力されます。複数モデルを同一の入力セットで比較できるため、モデルアップグレードの意思決定に直結します。

Golden Dataset の設計

Golden dataset（または golden test set）とは、期待される入出力ペアを人手でキュレーションした高品質評価セットです。以下の点が試験で問われます。

代表性 ― ユーザーが実際に送る入力分布をカバーしていること。特定カテゴリに偏っていると評価の信頼性が下がります
正解の明確さ ― 答えが一意または限定的な問題群（事実 QA、コード生成など）に向いています。自由回答形式では正解の定義が曖昧になるため、ルーブリックが必要です
サイズ ― 統計的に有意な結果を得るために最低数百サンプルが推奨されます。少なすぎると偶然の揺れが評価を左右します

合成データ生成ワークフロー

実運用データだけでは評価セットが不足する場合、FM 自体を使って合成入力を生成するワークフローが有効です。一般的な構成は次のとおりです。

シードドキュメント（社内 FAQ・仕様書など）を準備する
FM に「このドキュメントを前提にユーザーが質問しそうな Q&A を 50 件生成せよ」と指示する
生成された Q&A を人手でフィルタリングし、golden dataset に追加する
本番ログが蓄積されてきたら、合成データと実データを混合して再評価する

合成データは golden dataset の補完手段であり、完全な代替ではありません。試験では「合成データのみに頼ることのリスク（分布の偏り・表現の単調性）」が問われることがあります。

A/B テストとカナリアデプロイ

モデルを切り替える際は、いきなり全トラフィックを移行するのではなく、段階的な検証が推奨されます。

Python

import boto3

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

# カナリア用に専用キャパシティ（プロビジョンドスループット）を確保するイメージ
# トラフィック比率はこの API では設定できず、アプリ側や ALB のルーティング重みで制御する
response = bedrock.create_provisioned_model_throughput(
    modelUnits=5,
    provisionedModelName="my-model-canary",
    modelId="anthropic.claude-3-5-sonnet-20241022-v2:0",
)
print(response["provisionedModelArn"])

A/B テスト ― 同一ユーザーセグメントを 2 グループに分け、モデル A とモデル B の結果を定量比較します。Bedrock では複数のプロビジョンドエンドポイントを用意し、アプリ側でルーティングを振り分けます
カナリアデプロイ ― 全トラフィックの小割合（例 5 %）から新モデルに流し、エラー率・レイテンシ・品質指標を監視してから段階的に拡大します。Amazon CloudWatch メトリクスでリアルタイム監視し、異常があれば即座に旧モデルへロールバックします

試験で問われるポイント

Bedrock Model Evaluation vs Amazon SageMaker Clarify vs SageMaker Model Monitor は頻出の混同ポイントです。Bedrock Model Evaluation は FM 品質の事前比較評価、Clarify はバイアス検出・説明可能性、Model Monitor は推論後のデータドリフト監視と役割が異なります
自動評価の指標（BERTScore など）は意味的類似度を測るもので、ビジネス価値の高さを直接測るものではありません。試験では「自動評価で高スコアでも人手評価で低評価になる場合があるのはなぜか」という観点が出ます
合成データの過剰依存リスク ― 合成データで評価した場合、生成に使った FM のバイアスを引き継いでしまう可能性があります。人手キュレーションとの組み合わせが正答として問われます

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

やりたいこと	使うもの	混同しやすいもの
複数 FM を同一データで比較・スコアリングしたい	Amazon Bedrock Model Evaluation	SageMaker Clarify（バイアス検出が目的）
推論後の入力データのドリフトを継続監視したい	Amazon SageMaker Model Monitor	Bedrock Model Evaluation（デプロイ前評価が目的）
カナリアデプロイでトラフィックを段階移行したい	Bedrock Provisioned Throughput + CloudWatch	Model Evaluation（オフライン比較が目的）

まとめ

FM 評価の中心は Amazon Bedrock Model Evaluation です。Golden dataset は代表性・正解明確さ・十分なサイズの三要件を満たす必要があり、合成データ生成はその補完手段として位置づけます。モデル移行では A/B テストとカナリアデプロイを組み合わせてリスクを最小化し、CloudWatch で品質指標を継続監視する設計が本番グレードの要件です。

次のステップ

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