AWS認定資格 WEB問題集&徹底解説
機械学習エンジニア–アソシエイト
問題文と選択肢
- 期間を定めてAWS Lambda関数を通じて定期的に新旧モデルを切り替え、各期間の運用結果を比較して評価する。
- 新モデルがフラグした取引の一部を、専門家が手動で詳細にレビューし、モデルの精度と誤検知率を事前に検証する。
- A/Bテストを用いて、トラフィックの一部を新モデルにルーティングし、リアルタイムでの顧客反応と検出メトリクスを比較する。
- シャドウデプロイメントを実施し、新モデルからの予測結果は本番システムに適用せず、ログとして記録・分析する。
A. 期間を定めてAWS Lambda関数を通じて定期的に新旧モデルを切り替え、各期間の運用結果を比較して評価する。
期間を区切って新旧モデルを入れ替える方式は、その期間中は本番トラフィックの全量が新モデルの判定を受けることを意味します。新モデルの偽陽性が多ければ、その期間の顧客に不必要なアラートが直撃するため「最も安全」とは言えません。
さらに、期間を分けた比較は不正のトレンドや季節変動が交絡するため、新旧の検出性能を公平に比較できないという評価手法上の欠陥もあります。
B. 新モデルがフラグした取引の一部を、専門家が手動で詳細にレビューし、モデルの精度と誤検知率を事前に検証する。
専門家によるレビューはモデルの誤検知の傾向を深く理解するのに有用で、実際にシャドウテストのログを分析する際にも併用されます。しかしこれ単体では本番トラフィック全体に対する挙動を評価できず、金融機関の膨大な取引量に対してスケールしません。
また「新モデルがフラグした取引」を得るには結局どこかで新モデルを本番データに対して動かす必要があり、評価の仕組みそのものを説明していない点でも不十分です。
C. A/Bテストを用いて、トラフィックの一部を新モデルにルーティングし、リアルタイムでの顧客反応と検出メトリクスを比較する。
A/B テストは本番トラフィックの一部を新モデルにルーティングするため、その一部の顧客には新モデルの判定がそのまま適用されます。新モデルの偽陽性が多ければ実際に不必要なアラートが顧客へ飛び、「顧客への不必要なアラートを最小限に抑える」という要件に真っ向から反します。
A/B テストは有効な手法ですが、シャドウで安全性を確認した後の段階で使うものであり、「デプロイ前の最も安全な評価」としては順序が違います。
D. シャドウデプロイメントを実施し、新モデルからの予測結果は本番システムに適用せず、ログとして記録・分析する。
シャドウデプロイメントは、本番トラフィックを複製して新モデルにも流し、その推論結果は本番システムに一切適用せずログとして記録する手法です。顧客に届く判定はあくまで既存モデルのものなので、顧客影響はゼロのまま評価できます。
同一のリクエストを新旧両モデルが処理するため、検出率と偽陽性率を同じ条件で公平に比較でき、レイテンシーやエラー率といった運用面のリスクも本番同等の負荷で確認できます。Amazon SageMaker にもシャドウテスト機能が用意されており、要件に最も合致する正解です。
構成図
本番の取引リクエスト ├──▶ 既存モデル(本番) ──判定を返す──▶ 顧客へのアラート └┈┈▶ 新モデル(シャドウ) ┈結果は破棄┈▶ ログ / メトリクス(偽陽性率を比較)
「本番データで試したいが、顧客には当てたくない」=シャドウ。A/B・カナリアは顧客に当たる。
正解への思考ルート
問題文から要件を抽出し、選択肢の適否を判断するのがポイントです。| 要件 | 判断ポイント |
|---|---|
| 本番デプロイ前に「実データ」で効果とリスクを評価したい | 過去データのサンプルを人手で見るだけでは本番トラフィックでの挙動・負荷を再現できない →選択肢(B)を消す |
| 顧客への不必要なアラート(偽陽性)を最小限に抑える | 新モデルの判定が顧客に届く方式は不可。トラフィックのルーティングも期間ごとの切り替えも顧客に当たる →選択肢(A・C)を消す |
| 既存モデルと比較して検出性能が向上しているかを見たい | 同一トラフィックを新旧両方に流して突き合わせるのが最も公平。期間で分けると不正トレンドの変動が交絡する →選択肢(A)を消す |
| 最も安全で効果的なアプローチ | トラフィックを複製し、推論結果は破棄してログだけ取るシャドウデプロイなら、顧客影響ゼロで本番同等の評価ができる →選択肢(D)が正解 |
ひっかけポイント
- 選択肢 C の「トラフィックの一部」は影響が小さそうに見えるが、その一部の顧客には偽陽性のアラートが実際に飛ぶ。「一部だから安全」ではない
- A/B テストとシャドウテストの違いは「推論結果を顧客に返すか否か」。どちらも本番トラフィックを使う点は同じなので、そこで区別しようとすると間違える
- 選択肢 A は「Lambda で切り替える」という実装の話に目を引かれるが、本質は「切り替えた期間は全顧客が新モデルの判定を受ける」こと。デプロイ手段ではなく誰が判定結果を浴びるかで判断する
- 選択肢 B の手動レビューは「慎重=安全」に見えるが、スケールせず、評価の仕組み自体を示していない。シャドウのログを人がレビューする形なら有効で、単体では不十分
出題バリエーション
同じ知識が本番では条件を変えて出題されます。| 問題文がこう変わったら | 正解はこう変わる |
|---|---|
| 「新モデルの品質は確認済み。段階的に本番トラフィックを移行し、問題があれば即座に切り戻したい」 | カナリアリリース / 線形トラフィックシフト(SageMaker エンドポイントのデプロイガードレール)が正解軸に。 |
| 「2 つのモデルのビジネス指標(成約率など)への影響を実測して優劣を判定したい」 | 顧客に結果を返す必要があるため A/B テストが正解に。 |
| 「本番稼働後、時間経過で入力データの分布がずれていないかを継続監視したい」 | SageMaker Model Monitor(データドリフト / モデル品質の監視)が正解軸に。 |
| 「新旧モデルを1 つのエンドポイントに配置してコストを抑えつつトラフィック配分を制御したい」 | 単一エンドポイントの複数プロダクションバリアント+重み付けが正解軸に。 |
- 期間を定めてAWS Lambda関数を通じて定期的に新旧モデルを切り替え、各期間の運用結果を比較して評価する。
- 新モデルがフラグした取引の一部を、専門家が手動で詳細にレビューし、モデルの精度と誤検知率を事前に検証する。
- A/Bテストを用いて、トラフィックの一部を新モデルにルーティングし、リアルタイムでの顧客反応と検出メトリクスを比較する。
- シャドウデプロイメントを実施し、新モデルからの予測結果は本番システムに適用せず、ログとして記録・分析する。