MLエンジニアがSageMaker Pipelinesで自動モデル再学習パイプラインを構築しています。パイプラインの要件として「新しくトレーニングしたモデルのAUC（Area Under the ROC Curve：モデ

Question

MLエンジニアがSageMaker Pipelinesで自動モデル再学習パイプラインを構築しています。パイプラインの要件として「新しくトレーニングしたモデルのAUC（Area Under the ROC Curve：モデルの分類性能を示す指標）が0.85以上の場合のみSageMaker Model Registryに『Approved』ステータスで登録して本番エンドポイントを更新し、0.85未満の場合はパイプラインをその時点で終了する」という条件分岐の実装が必要です。SageMaker Pipelinesのネイティブ機能を使ってパイプライン内部でこの条件分岐を実装する最も適切な方法はどれですか？

Accepted Answer

正解: ConditionStepとConditionGreaterThanOrEqualToを使い、条件真のif_stepsでModelStep→EndpointConfigStep→EndpointStep、偽のelse_stepsを空に設定する。SageMaker PipelinesのConditionStepは、パイプラインプロパティ（前のProcessingStepやEvaluationStepが出力したJSONファイルの値など）を条件式で評価し、if_steps（条件真）とelse_steps（条件偽）で後続ステップを分岐させる機能です。ConditionGreaterThanOrEqualToなどの条件クラスをネイティブに使えるため、外部サービスへの依存なくパイプライン内で完結した条件分岐が実装できます。

選択肢AのProcessingStepで評価スコアを計算してSNSトピックに通知を送り、SNSにトリガーされたLambda関数が条件を判断する方法は実装可能ですが外部依存が増えます。

選択肢CのSageMaker Experimentsでトラッキングした評価メトリクスをCloudWatchアラームで監視し、アラームがEventBridgeをトリガーする方法は実装可能ですが外部依存が増え、パイプラインのDAG（有向非巡回グラフ）としての可視化・管理が難しくなります。

選択肢DのTrainingStepの直後にLambdaStepを追加し、Lambda関数内でモデル評価・条件判断・Model Registry登録API・エンドポイント更新APIの呼び出しをすべて実装する方法も実装可能ですが外部依存が増え、パイプラインのDAG としての可視化・管理が難しくなります。

Answer

ProcessingStepで評価スコアを計算してSNSトピックに通知を送り、SNSにトリガーされたLambda関数が条件を判断して後続のRegistrationStepを起動するかどうかを制御する — ProcessingStepで評価スコアを計算してSNSトピックに通知を送り、SNSにトリガーされたLambda関数が条件を判断する方法は実装可能ですが外部依存が増えます。

Answer

SageMaker Experimentsでトラッキングした評価メトリクスをCloudWatchアラームで監視し、アラームがEventBridgeをトリガーして後続のデプロイパイプラインを別途起動する — SageMaker Experimentsでトラッキングした評価メトリクスをCloudWatchアラームで監視し、アラームがEventBridgeをトリガーする方法は実装可能ですが外部依存が増え、パイプラインのDAG（有向非巡回グラフ）としての可視化・管理が難しくなります。

Answer

TrainingStepの直後にLambdaStepを追加し、Lambda関数内でモデル評価・条件判断・Model Registry登録API・エンドポイント更新APIの呼び出しをすべて実装する — TrainingStepの直後にLambdaStepを追加し、Lambda関数内でモデル評価・条件判断・Model Registry登録API・エンドポイント更新APIの呼び出しをすべて実装する方法も実装可能ですが外部依存が増え、パイプラインのDAG としての可視化・管理が難しくなります。

解説

解説