AWSはSageMaker SDK v3で異常検知と欠陥分類を並行学習する例を示しました。品質条件を通過したモデルをNeoで機器向けに最適化します。 工場全体への拡大ではカメラごとの履歴と学習の同時実行数が焦点です。サンプルの計算費用と実際の配信・運用費を区別する必要があります。 一台の実証から多数のカメラの更新へ AWSは10月26日、SageMaker Python SDK v3で画像検査モデルのライフサイクルを管理する技術記事を公開しました。一台のカメラで動くモデルでも、角度、反射、周囲の明るさが違う多数の機器へ広げると、同じ精度を維持できない場合があります。記事はカメラごとにモデルを調整し、その学習、評価、版管理を自動化する構成です。以前の構成で使われたSageMaker Edge Managerに代わり、SageMaker Neoによる機器向けの最適化を組み込んでいます。SDK v3への移行に合わせ、学習処理だけでなく展開時の依存関係も扱う内容です。 異常検知と分類の両方に品質の関門を置く パイプラインはカメラを指定して実行し、異常検知モデルと欠陥分類モデルを学習します。ONNXに書き出した結果を保留データで評価し、品質条件を通過したものをNeoでコンパイルして登録します。カメラの識別子で以前の承認モデルを探すため、別のカメラの履歴と混ぜずに再学習できます。工場の検査を担当するチームには、学習が完了したかと現場へ届けられる品質かを分ける構成が参考になります。Step FunctionsとDynamoDBによる同時実行の制御で、要求が集中しても一斉に学習を始めない設計です。出力は版管理された成果物であり、実際に機器へ配る仕組みは現場の方式に合わせる必要があります。モデルの登録だけで更新工程が全て完了するわけではありません。 二段階の展開と現場での確認を計画する SDK v3はパイプライン定義時に実際のIAMロールを検証するため、記事の構成は先にロールなどを作る二段階の展開を使います。権限を絞った設定が検証に影響する点も説明されています。導入側ではサンプルが要求する権限と、自社の配布・実行条件を照合することが論点です。合成データによる一回の実行は計算費用が約0.07ドルと示されますが、多数の機器を継続管理する総費用ではありません。学習データの収集、保管、機器の検証、配信、障害対応は別に見積もる必要があると見られます。カメラごとの改善を測る場合も、新旧モデルを同じ条件で比較し、失敗時に戻す版を残すことが重要です。クラウド上の品質条件と、実際の設備で許容する誤検知をつなぐ運用が次の判断点になります。 成果物の登録から機器の稼働までを追う 記事は機器向けの成果物を作るところまでを扱っています。現場では対象の装置へ正しい版が届き、意図した設定で動くかの確認が残ります。モデルとカメラの対応を追える台帳を保ち、停止中の機器や古い版を使う機器を把握することが論点です。学習の同時実行を制限する設計は、更新が終わるまでの時間にも関係します。急ぎの再学習と通常の更新をどう扱うかを決めることで、クラウドの実行枠と現場の必要性を整合させやすくなると考えられます。