無限ノック › MLA 練習問題一覧 › 問題
MLAMLワークフローのデプロイとオーケストレーション

MLエンジニアがSageMaker Pipelinesを使用して自動再トレーニングパイプラインを構築しています。トレーニングジョブ完了後にモデルを評価し、テストデータに対するAUC-ROC(受信者動作特性曲線の曲線下面積:分類モデルの識別性能を示す指標、1.0が最良)スコアが0.85以上の場合のみSageMaker Model Registryに新バージョンとして登録し、それ以下の場合はパイプラインを失敗扱いとして既存の本番モデルを維持したい。このロジックをSageMaker Pipelines内で実装する最も適切な方法はどれですか?

A
SageMaker Pipelines の ConditionStep を使用し、評価メトリクスに基づいてModelStepまたはFailStepへの分岐を実装する
✓ 正解
SageMaker PipelinesのConditionStepはパイプライン定義内でネイティブな条件分岐を宣言的に実現します。PropertyFileで取得したメトリクスをConditionGreaterThanOrEqualToなどで評価し、ModelStepまたはFailStepへ分岐できます。
B
SageMaker Processing Job のカスタムスクリプト内でboto3(AWS Python SDK)を使用してモデル評価とModel Registryへの登録を直接制御する
Processing Job内でのboto3による直接制御は技術的に実現可能ですが、パイプラインの可視性・追跡可能性が低下し、管理性が悪化します。
C
Amazon EventBridgeルールでトレーニングジョブ完了イベントを検知し、AWS Lambda関数でメトリクス評価と条件付き登録を実行する
Lambda関数での実装も技術的に可能ですが、SageMaker Pipelines機能を活用しない冗長設計であり、パイプラインの一体管理ができなくなります。
D
AWS Step Functionsを使用してChoiceステートでメトリクスを評価し、SageMaker SDKでModel Registryへの登録を制御する
Step Functionsでも実現可能ですが、SageMaker Pipelinesネイティブのを使わない冗長設計です。パイプラインの可視化・管理性が低下します。

解説

SageMaker PipelinesのConditionStepはパイプライン定義内でネイティブな条件分岐を実現するコンポーネントです。PropertyFileやJsonGetで取得した評価メトリクスをConditionGreaterThanOrEqualToなどの条件演算子で評価し、ModelStepまたはFailStepへ分岐できます。 選択肢Bは、Processing Jobのカスタムスクリプト内でboto3を用いてモデル登録を制御する方法は技術的には可能ですが、条件分岐ロジックがコード内に隠蔽され、SageMaker Pipelinesの可視化・追跡機能が活用できません。 選択肢Cは、EventBridge + Lambdaによる制御はパイプライン外部での処理となり、SageMaker Pipelinesの実行管理・再現性・追跡可能性が損なわれ、システムが複雑化します。 選択肢Dは、Step FunctionsのChoiceステートは汎用的なワークフローエンジンであり、SageMaker Pipelinesとは別システムとなるため管理コストが増加し、パイプラインの一元管理が困難になります。

ドメイン別正答率・予想スコアでリアルタイムに実力把握

無限ノックでMLAを徹底対策。全問AI生成のオリジナル問題。

無料で演習を始める →
← MLA の問題一覧に戻る