あるEC企業が、商品レビュー要約機能のプロンプトを現行版（v1）から改良版（v2）へ移行するにあたり、本番ユーザーへの影響を抑えつつv2が統計的に有意に優れているかを検証したいと考えています。トラフィックは日次で数万リク

Question

あるEC企業が、商品レビュー要約機能のプロンプトを現行版（v1）から改良版（v2）へ移行するにあたり、本番ユーザーへの影響を抑えつつv2が統計的に有意に優れているかを検証したいと考えています。トラフィックは日次で数万リクエストあり、要約品質の主指標は人手ラベル済みの比較データではなく、本番上でのユーザーの「役立った/役立たなかった」フィードバック率です。マネージドな仕組みで、両バージョンへトラフィックを分割し、安全に効果測定できる構成として最も適切なものはどれですか。

Accepted Answer

正解: Bedrock Prompt Managementで各プロンプトをバージョン管理し、アプリ側でトラフィックを一定比率でv1/v2に振り分け、フィードバック率をCloudWatchカスタムメトリクスで比較する。A/Bテストの要件は「両バージョンへのトラフィック分割」と「本番上のユーザーフィードバック率での効果測定」であり、Prompt Managementでバージョン管理しつつ比率配分し、フィードバック率をCloudWatchで比較する構成が最も適切。

Bedrock Prompt Managementはプロンプトを版管理・参照でき、アプリ側で各版を呼び分けることで安全な段階的トラフィック分割が可能。本番指標（フィードバック率）をカスタムメトリクス化すれば統計的比較ができる。

選択肢BのヒューマンEvaluationは本番ユーザーフィードバックではなく社内採点であり、要件の「本番上のフィードバック率」と評価対象が異なる。
選択肢Cの全切り替えはトラフィック分割をしないため安全な比較ができず、A/Bテストにならない。
選択肢Dの「長い要約を採用」は品質指標と無関係なヒューリスティックで、効果測定にもならない。

Answer

Bedrock Model Evaluationのヒューマン評価ジョブにv1とv2を登録し、社内レビュアーが両出力を比較採点した結果でv2採用を判断する — ヒューマン評価ジョブは社内レビュアーの比較採点であり、要件である本番ユーザーの『役立った』フィードバック率での測定とは評価対象が異なるため、実運用上の効果測定にならない。

Answer

Provisioned Throughputをv2専用に購入して全トラフィックをv2へ即時切り替え、品質低下が観測されればv1にロールバックする — 全トラフィックを即時v2へ切り替える構成はトラフィック分割を行わず、v1との同時比較ができないためA/Bテストが成立せず、Provisioned Throughputの先行購入もコスト面で過大となる。

Answer

Bedrock Flowsでv1とv2を直列に接続し、両方の出力を生成して長い方の要約を自動採用するパイプラインを構築する — 2版を直列実行して長い要約を採用する構成は、要約の長さという品質と無関係な基準で選ぶうえ両版を毎回実行してコストも倍増し、フィードバック率による効果測定の要件を満たさない。

解説

解説