IoT Edge での MLOps の仕組み
MLOps を採用することで、データ科学者は DevOps の環境から次の機能を使用できます。
- ソース管理
- 再現可能なトレーニング パイプライン
- モデルのストレージとバージョン管理
- モデルのパッケージ
- モデルの検証とデプロイ
- 運用環境でのモデルの監視
- モデルの再トレーニング
これらの機能は個別に使用できますが、MLOps ではそれらがシームレスに統合され、データ サイエンティスト、開発者、ML エンジニアが効率的に共同作業できるようになります。
このユニットでは、個々のコンポーネントの役割について説明します。
ソース管理: ソース管理は、他のデータ サイエンティストや開発者と共同作業できるようにするために必要です。 ML モデルの生成に使用されるすべての成果物 (トレーニング コードや入力データなど) は、ソース管理を通じてキャプチャされます。 多くの場合、モデルは再トレーニングして再展開する必要があります。 ソース管理システムですべての成果物をキャプチャすることにより、再現性と追跡可能性が保証されます。
再現可能なトレーニング パイプライン: 再現可能なトレーニング パイプラインは、反復的なタスクを自動化することで、モデルの開発を効率化するために必要です。 トレーニング パイプラインを自動化することで、新しいモデルの生成速度が上がります。
モデルのストレージとバージョン管理: モデルのストレージとバージョン管理により、検出、共有、コラボレーションが容易になります。 また、個々の成果物に対するアクセスを監査および管理することもできます。
モデルのパッケージ化: ターゲット推論環境でモデルを実行するために必要な依存関係をキャプチャします。 モデルのパッケージ化は、コンテナーによって実装されます。 コンテナーは、クラウドとインテリジェント エッジの両方にまたがります。 Open Neural Network Exchange (ONNX) などの再利用可能な形式を使用して、モデルを実装できます。
モデルの検証: モデルの検証は、トレーニング コードの基本単体テスト、以前のバージョンのモデルに対する A/B 比較、エンド ツー エンドの機能とパフォーマンスのテスト スイートなど、さまざまな種類の方法で実行できます。
展開: IoT Edge など、さまざまな種類のプラットフォームに新しいモデルを展開できます。 ターゲット プラットフォームに固有の特性を理解して使用することが目的です。
監視: 運用環境でモデルを監視する機能が必要です。 モデルのパフォーマンスを理解し、向上させることができます。 また、トレーニング データセットと推論データの間のデータ ドリフトを監視して、モデルの再トレーニングが必要な時期を把握することもできます。
再トレーニング: 監視条件に基づいて、モデルを再トレーニングできます。
IoT に関する考慮事項: 上記に加えて、IoT の展開に関する特別な考慮事項が必要です。 MLOps の観点からは、IoT Edge は別の展開プラットフォームです。 ただし、IoT Edge にモデルを展開する場合は、いくつかの追加の考慮事項に対応する必要があります。 IoT Edge を対象とする MLOps モデルは、オフラインで実行できる必要があります。 IoT モデルは、データの量が多いため、データ ドリフトの影響を受けやすくなります。 IoT 機械学習モデルは、さまざまなターゲット プラットフォームに展開する必要があり、これらのプラットフォームの機能を適用する必要があります。
プロファイル、モデルの最適化、コンテナーとしてモデルを展開する機能など、MLOps の他の機能も、IoT Edge 環境に適用されます。 Web サービスまたは IoT Edge デバイスとしてモデルを使用する場合は、次の項目を指定します。
- 実際に展開されるモデル。
- 要求を受け入れ、モデルを使用してデータをスコア付けし、応答を返すエントリ スクリプト。
- モデルで必要な pip と Conda の依存関係が記述されている Azure Machine Learning 環境。
- エントリ スクリプトと、モデルとエントリ スクリプトで必要になる、テキストやデータなど、その他のアセット。
また、ターゲット展開プラットフォームの構成も指定します。 イメージが作成されるときに、Azure Machine Learning で必要なコンポーネントも追加されます。 たとえば、Web サービスを実行し、IoT Edge とやりとりするために必要な資産などです。
シナリオを再検討する
前に説明した石油ガス業界のシナリオをもう一度考えてみましょう。 あなたが遠隔地や海外で動作している何千基もの石油ガス ポンプを管理する担当者であることを思い出してください。 チームは現場の障害を迅速に特定し、修正する必要があります。 センサーからキャプチャされたデータを使用して、最新の機械学習モデルを作成する、ポンプ用の予測メンテナンス システムを構築して展開したいと考えています。 モデルは、データの現在の状態を反映している必要があります。 つまり、モデルはデータ ドリフトに関して古くなってはなりません。 最後に、IoT Edge のシナリオを使用しているため、モデルはエッジ デバイスで実行できる必要があります (必要な場合はオフライン モードで)。
Edge デバイス向けの MLOps を使用してこのシナリオに対処するには、3 つのパイプラインを検討できます。
構築してトレーニングする (ステップ 1)
パッケージ化して展開する (ステップ 2)
監視して再トレーニングする (ステップ 3)
ステップ 1 - 構築とトレーニング: このステップでは、再現可能なモデルと再利用可能なトレーニング パイプラインを作成します。 コードがチェックインされるたびに CI パイプラインがトリガーされます。 コードをビルドしてテスト スイートを実行した後、更新された Azure Machine Learning パイプラインを発行します。 ビルド パイプラインには、多数の単体テストとコード品質テストが含まれます。
ステップ 2 - パッケージ化と展開: このステップでは、モデルのパッケージ化、検証、展開を行います。 このパイプラインでは、スコアリング イメージを運用化し、異なる環境に安全にプロモートします。 パイプラインは、新しい成果物が使用可能になるたびにトリガーされます。 登録されたモデルは、スコアリング スクリプトおよび Python の依存関係 (Conda YAML ファイル) と共に、運用化 Docker イメージにパッケージ化されます。 イメージは、Azure Container Registry によって自動的にバージョン管理されます。 スコアリング イメージは、テスト可能なコンテナー インスタンスに展開されます。 成功した場合、スコアリング イメージは、運用環境に Web サービスとして展開されます。
手順 3 - 監視と再トレーニング: モデルの動作を説明して観察し、再トレーニング プロセスを自動化します。 機械学習パイプラインにより、モデルの再トレーニング プロセスが非同期に調整されます。 再トレーニングは、スケジュールに基づいてトリガーすることも、新しいデータが利用可能になったときに、前のステップで公開されているパイプライン REST エンドポイントを呼び出すことによってトリガーすることもできます。 このステージでは、モデルの再トレーニング、評価、登録を行います。
全体的なフローは次のとおりです。
。