あるMLチームは、本番環境で稼働している需要予測モデルのエンドポイントに対してSageMaker Model Monitorを設定しています。モデルは週次でバッチ入力データを受け取りますが、最近入力特徴量の分布が徐々に変

Question

あるMLチームは、本番環境で稼働している需要予測モデルのエンドポイントに対してSageMaker Model Monitorを設定しています。モデルは週次でバッチ入力データを受け取りますが、最近入力特徴量の分布が徐々に変化していることが疑われます。この状況で、データドリフト（入力データの統計的特性の変化）を最小の運用コストで検出するための構成として最も適切なものはどれですか？

Accepted Answer

正解: モデルエンドポイントにデータキャプチャを有効化し、ベースラインとなるトレーニングデータの統計情報をSageMaker Model Monitor Schedulingで週次スケジュールとして実行。違反検出時にCloudWatch Alarmで通知する。選択肢AのSageMaker Model Monitorはデータキャプチャ機能でリクエスト/レスポンスをS3に記録し、ベースライン統計との比較を自動スケジュール実行します。CloudWatch Alarmsと連携して違反時のアラートも容易に設定でき、マネージドサービスを最大活用した最小運用コストの構成です。

選択肢BのLambda関数による毎時起動とカスタムPythonスクリプトはフルカスタム実装で運用負荷が高く、追加コストも発生します。

選択肢CのSageMaker ExperimentsはMLトレーニング実験追跡が主目的であり、Kinesis Data Streamsとの組み合わせはModel Monitorの設計思想に合わない非効率な構成です。

選択肢Dの推論リクエストごとにProcessing Jobを起動する構成は大量のジョブが発生し、コストと遅延が著しく増大するため適切ではありません。

Answer

Lambda関数を毎時起動してエンドポイントのリクエスト/レスポンスをS3に保存し、カスタムPythonスクリプトで統計比較を実行する — Lambda関数の毎時起動とカスタムPythonスクリプトによる統計比較はフルカスタム実装となり、実装・保守コストが高くなります。また週次バッチに対して毎時実行は過剰であり、コスト効率も悪いため適切ではありません。

Answer

SageMaker Experimentsでキャプチャしたデータをリアルタイムで分析し、Kinesis Data Streamsに送信してダッシュボードを構築する — SageMaker ExperimentsはMLトレーニング実験の追跡が主目的であり、Kinesis Data Streamsはリアルタイムストリーミング基盤です。データドリフト検出を目的とした構成としては設計思想が合わず、運用コストも増大します。

Answer

推論リクエストごとにSageMaker Processing Jobを起動し、入力特徴量の統計をベースラインと比較してSlack通知を送る — 推論リクエストごとにProcessing Jobを起動すると極めて大量のジョブが発生し、コストと遅延が著しく増大します。SageMaker Model Monitorのスケジューリング機能でバッチ単位の定期評価を行うのが適切な設計です。

解説

解説