AIPテスト、検証、トラブルシューティング
あるフィンテック企業が、Amazon Bedrock 上の2つのプロンプトバージョン（v1=既存、v2=Chain-of-Thought強化）を本番トラフィックで比較検証したいと考えています。要件は、①実ユーザーのリクエストを一定割合で各バージョンに振り分ける、
②バージョンごとの回答品質・レイテンシー・トークンコストを統計的に比較する、
③問題があれば即座に全トラフィックを v1 に戻せる、というものです。アプリは API Gateway + Lambda 構成で Bedrock を呼び出しています。この A/B テストを実現する最も適切な構成はどれですか。
ALambda 内でトラフィックを重み付けで v1/v2 に振り分け、各呼び出しのメトリクスを CloudWatch カスタムメトリクスに出力し、Prompt Management のバージョン参照を切り替えてロールバックする
✓ 正解
アプリ層の Lambda で重み付け振り分けし、品質・レイテンシー・コストを CloudWatch カスタムメトリクスで収集、Prompt Management のバージョン参照切替で即時ロールバックでき、3要件すべてを満たす標準的なA/B構成。
BModel Evaluation の自動評価ジョブを本番トラフィックに対してオンラインで常時実行し、その内部で v1/v2 を振り分ける
Model Evaluation はデータセットに対するオフライン/オンデマンド評価ジョブであり、本番リクエストをリアルタイムに重み付け振り分けする基盤ではないため、A/Bトラフィック分割の要件を満たせない。
CBedrock Guardrails のバージョニング機能で v1/v2 を切り替え、ブロック率の差を品質メトリクスとして比較する
Guardrails はコンテンツの安全性フィルタが目的でブロック率は回答品質指標ではない。CoT強化プロンプトの品質比較やトラフィック分割機能もなく、A/Bテスト基盤として不適。
DProvisioned Throughput を v1 と v2 に各1つ購入し、レイテンシー差のみを比較してコストは無視する
Provisioned Throughput はスループット予約用でA/B振り分けの仕組みではなく、コストを無視する前提も品質・コストを統計比較するという要件②に明確に反する。
解説
本番トラフィックの重み付け振り分けはアプリ層（Lambda）で実装するのが定石で、各リクエストの品質・レイテンシー・トークン使用量を CloudWatch カスタムメトリクスとして送れば統計比較が可能です。プロンプトは Bedrock Prompt Management でバージョン管理し、参照バージョンを切り替えるだけで即座に v1 へロールバックできます。3要件すべてを満たします。
選択肢Bの Model Evaluation はオフライン/オンデマンドの評価ジョブで、本番トラフィックのリアルタイム振り分け基盤ではない。
選択肢Cの Guardrails はコンテンツ安全性の機構で、CoT プロンプトの品質比較やトラフィック分割はできない。
選択肢Dは Provisioned Throughput の用途違いで、コストを無視する点が要件②に反する。
ドメイン別正答率・予想スコアでリアルタイムに実力把握
無限ノックでAIPを徹底対策。全問AI生成のオリジナル問題。
無料で演習を始める →