エッジでの視覚的な品質検査のためのエンドツーエンドの MLOps パイプラインを構築する – パート 1 | アマゾン ウェブ サービス

エッジでの視覚的な品質検査のためのエンドツーエンドの MLOps パイプラインを構築する – パート 1 | アマゾン ウェブ サービス

タイムスタンプ：2年2023月12日31:XNUMX

実稼働環境での機械学習 (ML) モデルのデプロイを成功させるには、エンドツーエンドの ML パイプラインに大きく依存します。 このようなパイプラインの開発は困難な場合がありますが、問題を扱う場合はさらに複雑になります。 エッジ ML の使用例。 エッジでの機械学習は、ML モデルをローカルで実行する機能をエッジ デバイスにもたらす概念です。 これらのモデルをエッジで展開、監視、保守するには、堅牢な MLOps パイプラインが必要です。 MLOps パイプラインを使用すると、データのラベル付けからモデルのトレーニングとデプロイに至るまで、ML ライフサイクル全体を自動化できます。

エッジに MLOps パイプラインを実装すると、さらに複雑さが生じ、運用オーバーヘッドが増加するため、自動化、統合、メンテナンスのプロセスがより困難になります。 ただし、次のような専用サービスを使用すると、 アマゾンセージメーカー および AWS IoT Greengrass を使用すると、この労力を大幅に削減できます。 このシリーズでは、SageMaker、AWS IoT Greengrass、および AWSクラウド開発キット （AWS CDK）。

この投稿では、MLOps パイプライン アーキテクチャ全体の設計に焦点を当てます。 第2部 および 第3部 このシリーズでは、個々のコンポーネントの実装に焦点を当てます。 付属のサンプル実装を提供しています。 GitHubリポジトリ あなた自身を試してみてください。 AWS のエッジで MLOps を使い始めたばかりの場合は、を参照してください。 Amazon SageMaker Edge Manager と AWS IoT Greengrass を使用したエッジでの MLOps 概要とリファレンス アーキテクチャについては、

使用例: 金属タグの品質検査

ML エンジニアとして、取り組んでいるビジネスケースを理解することが重要です。 MLOps パイプライン アーキテクチャに入る前に、この投稿のサンプル ユースケースを見てみましょう。 カスタマイズされた荷物タグを作成するために金属タグを彫刻するメーカーの生産ラインを想像してください。 未加工の金属タグに傷などの欠陥がないか手動で検査する必要があるため、品質保証プロセスにはコストがかかります。 このプロセスをより効率的にするために、ML を使用してプロセスの早い段階で欠陥のあるタグを検出します。 これは、生産プロセスの後の段階で、コストのかかる欠陥を回避するのに役立ちます。 モデルは、傷などの可能性のある欠陥をほぼリアルタイムで特定し、マークする必要があります。 製造現場の環境では、多くの場合、接続がない場合や帯域幅の制約、遅延の増加に対処する必要があります。 したがって、製造現場でローカルに推論を実行し、接続に関する要件を軽減できる、視覚的な品質検査用のオンエッジ ML ソリューションを実装したいと考えています。 例をわかりやすくするために、検出された傷を境界ボックスでマークするモデルをトレーニングします。 次の画像は、XNUMX つのスクラッチがマークされたデータセットのタグの例です。

金属タグに傷あり

パイプライン アーキテクチャの定義

これで、ユースケースと、エッジでのオブジェクト検出を中心とした、私たちが対処しようとしている特定の ML 問題が明確になりました。 ここで、MLOps パイプラインのアーキテクチャを作成します。 現段階では、まだテクノロジーや特定のサービスには注目していませんが、むしろパイプラインの高レベルのコンポーネントに注目しています。 迅速に再トレーニングしてデプロイするには、データのラベル付けからトレーニング、推論まで、エンドツーエンドのプロセス全体を自動化する必要があります。 ただし、エッジケース向けのパイプラインの設定を特に困難にするいくつかの課題があります。

  • このプロセスのさまざまな部分を構築するには、さまざまなスキルセットが必要です。 たとえば、データのラベル付けとトレーニングにはデータ サイエンスに重点が置かれており、エッジ展開にはモノのインターネット (IoT) の専門家が必要であり、プロセス全体の自動化は通常、DevOps スキル セットを持つ担当者によって行われます。
  • 組織によっては、このプロセス全体が複数のチームによって実装される場合もあります。 私たちのユースケースでは、別々のチームがラベル付け、トレーニング、展開を担当するという想定に基づいて作業しています。
  • 役割とスキルセットが増えると、ツールやプロセスの要件も異なります。 たとえば、データ サイエンティストは、使い慣れたノートブック環境を監視して作業したいと考えるかもしれません。 MLOps エンジニアは、コードとしてのインフラストラクチャ (IaC) ツールを使用して作業することを望んでおり、 AWSマネジメントコンソール.

これはパイプライン アーキテクチャにとって何を意味するのでしょうか?

まず、さまざまなチームが独立して作業できるようにするエンドツーエンド システムの主要コンポーネントを明確に定義することが重要です。 次に、コラボレーションの効率を高めるために、チーム間のインターフェースを明確に定義する必要があります。 これらのインターフェイスは、チーム間の混乱を最小限に抑えるのに役立ち、定義されたインターフェイスに従っている限り、必要に応じて内部プロセスを変更できるようになります。 次の図は、これがコンピューター ビジョン パイプラインでどのようになるかを示しています。

MLOps パイプラインの落書き

MLOps パイプラインの全体的なアーキテクチャを詳しく調べてみましょう。

  1. このプロセスは、初期トレーニング データセットを形成するために実稼働環境でエッジ カメラ デバイスを使用してキャプチャされた金属タグの生画像の収集から始まります。
  2. 次のステップでは、これらの画像にラベルを付け、境界ボックスを使用して欠陥をマークします。 ラベル付きデータセットをバージョン管理し、使用されたトレーニング データのトレーサビリティと説明責任を確保することが不可欠です。
  3. ラベル付きデータセットを取得したら、モデルのトレーニング、微調整、評価、バージョン管理を進めることができます。
  4. モデルのパフォーマンスに満足したら、モデルをエッジ デバイスにデプロイし、エッジでライブ推論を実行できます。
  5. モデルが運用環境で動作している間、エッジ カメラ デバイスは、これまでに見たことのない欠陥やエッジ ケースを含む貴重な画像データを生成します。 このデータを使用して、モデルのパフォーマンスをさらに向上させることができます。 これを達成するために、モデルが低い信頼度で予測した画像、または誤った予測を行った画像を保存します。 これらの画像は生のデータセットに再び追加され、プロセス全体が再度開始されます。

生の画像データ、ラベル付きデータセット、トレーニングされたモデルが、個別のパイプライン間の明確に定義されたインターフェイスとして機能することに注意することが重要です。 MLOps エンジニアとデータ サイエンティストは、これらのアーティファクトを一貫して生成する限り、パイプライン内のテクノロジーを柔軟に選択できます。 最も重要なことは、閉じたフィードバック ループを確立したことです。 本番環境で行われた誤った予測または信頼性の低い予測を使用して、データセットを定期的に強化し、モデルを自動的に再トレーニングして強化することができます。

ターゲットアーキテクチャ

高レベルのアーキテクチャが確立されたので、次はさらに XNUMX レベル深く進み、AWS のサービスを使用してこれを構築する方法を検討します。 この投稿で示されているアーキテクチャは、データ サイエンス プロセス全体を完全に制御することを前提としていることに注意してください。 ただし、エッジでの品質検査を始めたばかりの場合は、次のことをお勧めします。 アマゾンルックアウトフォービジョン。 これにより、ML コードを構築、保守、理解することなく、独自の品質検査モデルをトレーニングする方法が提供されます。 詳細については、以下を参照してください。 Amazon Lookout for Visionは、エッジでの製品欠陥の目視検査をサポートするようになりました.

ただし、完全に制御したい場合は、次の図にアーキテクチャがどのようになるかを示します。

MLOps パイプライン アーキテクチャ

前と同様に、ワークフローを段階的に説明し、どの AWS サービスが要件に適合するかを特定してみましょう。

  1. Amazon シンプル ストレージ サービス (Amazon S3) は、低コストのストレージ ソリューションを提供するため、生の画像データを保存するために使用されます。
  2. ラベル付けワークフローは、次を使用して調整されます。 AWSステップ関数は、ラベル付けワークフローのステップを簡単に調整できるサーバーレス ワークフロー エンジンです。 このワークフローの一部として、 Amazon SageMakerグラウンドトゥルース ラベル付けジョブと管理された人間の労働力を使用して、ラベル付けを完全に自動化します。 AWSラムダ データを準備し、ラベル付けジョブを開始し、ラベルを保存するために使用されます。 Amazon SageMaker フィーチャーストア.
  3. SageMaker Feature Store はラベルを保存します。 これにより、機能を一元管理して共有できるようになり、組み込みのデータ バージョン管理機能が提供されるため、パイプラインがより堅牢になります。
  4. を使用してモデルの構築とトレーニング パイプラインを調整します。 AmazonSageMakerパイプライン。 組み込みのステップを介して必要な他の SageMaker 機能と統合されます。 SageMaker トレーニング ジョブ モデルのトレーニングを自動化するために使用されます。 SageMaker処理ジョブ データを準備し、モデルのパフォーマンスを評価するために使用されます。 この例では、 ウルトラリティクス YOLOv8 物体検出モデルをトレーニングしてエクスポートするための Python パッケージとモデル アーキテクチャ ONNX 移植性を考慮した ML モデル形式。
  5. パフォーマンスが許容できる場合、トレーニングされたモデルは次の場所に登録されます。 Amazon SageMaker モデルレジストリ 増分バージョン番号が付加されます。 これは、モデルのトレーニングとエッジ展開のステップの間のインターフェイスとして機能します。 モデルの承認状況もここで管理します。 使用されている他のサービスと同様に、フルマネージドであるため、独自のインフラストラクチャの実行に注意を払う必要はありません。
  6. エッジ展開ワークフローは、ラベル付けワークフローと同様に、Step Functions を使用して自動化されます。 Step Functions の API 統合を使用すると、AWS IoT Greengrass などのさまざまな必要な AWS サービス API を簡単に呼び出して、新しいモデル コンポーネントを作成し、その後コンポーネントをエッジ デバイスにデプロイできます。
  7. AWS IoT Greengrass はエッジデバイスのランタイム環境として使用されます。 これは、エッジでのモデルと推論コンポーネントの展開ライフサイクルを管理します。 これにより、単純な API 呼び出しを使用して、モデルと推論コンポーネントの新しいバージョンを簡単にデプロイできるようになります。 さらに、エッジの ML モデルは通常、単独では実行されません。 さまざまなものを使用できます AWS および コミュニティ 他のサービスに接続するための AWS IoT Greengrass のコンポーネントを提供しました。

ここで説明したアーキテクチャは、前に示した高レベルのアーキテクチャに似ています。 Amazon S3、SageMaker Feature Store、および SageMaker Model Registry は、異なるパイプライン間のインターフェイスとして機能します。 ソリューションの実行と運用にかかる労力を最小限に抑えるために、可能な限りマネージド サービスとサーバーレス サービスを使用します。

堅牢な CI/CD システムへの統合

データのラベル付け、モデルのトレーニング、エッジ展開の手順は、当社のソリューションの中核です。 そのため、これらの部分の基礎となるコードまたはデータに関連する変更は、オーケストレーション プロセス全体の新たな実行をトリガーする必要があります。 これを実現するには、このパイプラインを CI/CD システムに統合する必要があります。これにより、バージョン管理されたコード リポジトリから実稼働環境にコードとインフラストラクチャの変更を自動的にデプロイできるようになります。 前のアーキテクチャと同様に、ここでもチームの自律性が重要な側面です。 次の図は、AWS のサービスを使用するとこれがどのようになるかを示しています。

CI / CDパイプライン

CI/CD アーキテクチャを見てみましょう。

  1. AWS コードコミット Git リポジトリとして機能します。 わかりやすくするために、提供されたサンプルでは、​​単一の git リポジトリ内のサブフォルダーを介して個別の部分 (ラベル付け、モデル トレーニング、エッジ デプロイメント) を分離しました。 実際のシナリオでは、各チームがパーツごとに異なるリポジトリを使用する可能性があります。
  2. インフラストラクチャのデプロイは AWS CDK を使用して自動化され、各部分 (ラベル付け、トレーニング、エッジ) が独自の AWS CDK アプリを取得して、独立したデプロイが可能になります。
  3. AWS CDK パイプライン機能では、 AWS コードパイプライン インフラストラクチャとコードのデプロイメントを自動化します。
  4. AWS CDK は、ステップごとに XNUMX つのコード パイプライン (アセット パイプラインとワークフロー パイプライン) をデプロイします。 アセットに変更がない場合 (トレーニングに使用できる新しいイメージがある場合など) に備えて、ワークフローをアセットのデプロイメントから分離し、ワークフローを個別に開始できるようにしました。
    • アセット コード パイプラインは、ワークフローが正常に実行されるために必要なすべてのインフラストラクチャをデプロイします。 AWS IDおよびアクセス管理 (IAM) ロール、Lambda 関数、トレーニング中に使用されるコンテナー イメージ。
    • ワークフロー コード パイプラインは、実際のラベル付け、トレーニング、またはエッジ デプロイメントのワークフローを実行します。
  5. アセット パイプラインは、前のワークフロー パイプラインが完了したときだけでなく、コミット時にも自動的にトリガーされます。
  6. プロセス全体は、 アマゾンイベントブリッジ 定期的な再トレーニングのルール。

CI/CD の統合により、エンドツーエンドのチェーン全体が完全に自動化されました。 パイプラインは、Git リポジトリ内のコードが変更されるたびに、またデータ変更に対応するスケジュールに従ってトリガーされます。

先に考えます

説明されているソリューション アーキテクチャは、エッジでエンドツーエンドの MLOps パイプラインを構築するための基本コンポーネントを表しています。 ただし、要件によっては、追加機能の追加を検討する場合があります。 以下にいくつかの例を示します。

まとめ

この投稿では、AWS のサービスを使用してエッジで視覚的な品質検査を行うためのエンドツーエンドの MLOps パイプラインを構築するためのアーキテクチャの概要を説明しました。 このアーキテクチャは、データのラベル付け、モデル開発、エッジ展開を含むプロセス全体を合理化し、モデルの新しいバージョンを迅速かつ確実にトレーニングして実装できるようにします。 サーバーレスおよびマネージド サービスを使用すると、インフラストラクチャの管理ではなく、ビジネス価値の提供に重点を置くことができます。

In 第2部 このシリーズでは、さらに XNUMX レベル深く掘り下げて、このアーキテクチャの実装、特にラベル付けとモデル構築を詳しく見ていきます。 コードに直接ジャンプしたい場合は、付属のコードをチェックしてください。 GitHubレポ.

著者について

マイケル・ロートマイケル・ロート AWS のシニア ソリューション アーキテクトとして、ドイツの製造業の顧客が AWS テクノロジーを通じてビジネス上の課題を解決できるようサポートしています。 仕事と家族のほかに、スポーツカーに興味があり、イタリアン コーヒーを楽しんでいます。

イェルク・ヴェールレイェルク・ヴェールレ AWS のソリューションアーキテクトとして、ドイツの製造業の顧客と協力しています。 Joerg は自動化に情熱を持っており、AWS 入社以前はソフトウェア開発者、DevOps エンジニア、サイト信頼性エンジニアとして働いてきました。 雲を超えて、彼は野心的なランナーであり、家族と充実した時間を楽しんでいます。 DevOps に挑戦したい場合、またはランニングに行きたい場合は、彼に知らせてください。

ヨハネス・ランガーヨハネス・ランガー AWS のシニア ソリューション アーキテクトで、ドイツの企業顧客と協力しています。 Johannes は、実際のビジネス上の問題を解決するために機械学習を適用することに情熱を持っています。 私生活では、ヨハネスは家の改善プロジェクトに取り組み、家族と屋外で時間を過ごすことを楽しんでいます。

タイムスタンプ：

より多くの AWS機械学習