エッジ上でのビジュアル品質検査のためのエンドツーエンドのMLOpsパイプラインの構築-パート1

エッジ上のビジュアル品質検査のためのエンドツーエンドMLOpsパイプラインの構築-パート1

機械学習（ML）モデルを本番環境で成功裏に展開するためには、エンドツーエンドのMLパイプラインに重点を置くことが重要です。このようなパイプラインの開発は困難を伴うことがありますが、エッジMLユースケースを扱う際にはさらに複雑さが増します。エッジでの機械学習は、ローカルでMLモデルを実行できる能力をエッジデバイスにもたらす概念です。エッジでこれらのモデルを展開、監視、および維持するためには、頑健なMLOpsパイプラインが必要です。MLOpsパイプラインを使用すると、データラベリングからモデルのトレーニングと展開まで、全体のMLライフサイクルを自動化することができます。

エッジでのMLOpsパイプラインを実装することにより、自動化、統合、および保守プロセスがより困難になるため、追加の複雑さが導入されます。しかし、Amazon SageMakerやAWS IoT Greengrassなどの特定用途向けのサービスを使用すると、この努力を大幅に削減することができます。このシリーズでは、SageMaker、AWS IoT Greengrass、およびAWS Cloud Development Kit（AWS CDK）を使用して、エッジでのコンピュータビジョンのユースケースに対する統合エンドツーエンドのMLOpsパイプラインの設計と構築プロセスを紹介しています。

このポストでは、全体のMLOpsパイプラインのアーキテクチャ設計に焦点を当てています。このシリーズのPart 2およびPart 3では、個々のコンポーネントの実装に焦点を当てています。自分自身で試してみるためのサンプル実装は、関連するGitHubリポジトリに提供されています。AWS上でのエッジでのMLOpsを始めるには、概要とリファレンスアーキテクチャについてはAmazon SageMaker Edge ManagerおよびAWS IoT GreengrassによるエッジでのMLOpsを参照してください。

ユースケース：金属タグの品質検査

MLエンジニアとして、取り組んでいるビジネスケースを理解することは重要です。したがって、MLOpsパイプラインのアーキテクチャに取り組む前に、このポストのサンプルユースケースを見てみましょう。カスタマイズされた荷物タグを作成するために金属タグを刻印するメーカーの生産ラインを想像してください。品質保証プロセスは、傷などの欠陥のために生の金属タグを手作業で検査する必要があるため、コストがかかります。このプロセスを効率化するために、私たちはMLを使用して早期に不良タグを検出します。これにより、生産プロセスの後の段階での高額な欠陥を回避することができます。モデルは、傷などの可能性のある欠陥をリアルタイムで識別し、それらをマークする必要があります。製造現場では、接続がないか、帯域幅が制約され、レイテンシが増加することがよくあります。したがって、ショップフロア上でローカルに推論を実行し、接続に関する要件を減らすエッジ上のMLソリューションを実装したいと考えています。今回の例では、検出された傷を境界ボックスでマークするモデルをトレーニングします。以下の画像は、データセットからのタグの例で、3つの傷がマークされています。

• ランチェーン101：パート2c PEFT、LORA、およびRLでLLMを微調整する
• 「Azureのコストを最適化するための10の方法」
• 「FinBERTとSOLID原則を活用して感情スコアの正確性を向上させる」

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

ユースケースとアドレスする具体的なMLの問題について明確になりましたので、MLOpsパイプラインのアーキテクチャを考える時が来ました。この段階では、具体的な技術やサービスではなく、パイプラインの高レベルなコンポーネントを見ています。トレーニングと展開を迅速に行うために、データラベリングからトレーニング、推論までのエンドツーエンドのプロセスを自動化する必要があります。ただし、エッジケースのパイプラインを構築することは特に困難な課題がいくつかあります。

• このプロセスの異なる部分を構築するには、異なるスキルセットが必要です。たとえば、データのラベリングとトレーニングにはデータサイエンスの専門知識が必要です。エッジデプロイメントには、インターネットオブシングス（IoT）の専門家が必要であり、プロセス全体の自動化は通常、デブオプスのスキルを持つ人が行います。
• 組織によっては、このプロセス全体を複数のチームで実装する場合もあります。私たちのユースケースでは、ラベリング、トレーニング、デプロイメントのそれぞれに別々のチームが責任を持っていると仮定しています。
• さらに多くの役割とスキルセットは、ツールとプロセスに異なる要件をもたらします。たとえば、データサイエンティストは、なじみのあるノートブック環境でモニタリングや作業をしたいと考えるかもしれません。MLOpsエンジニアは、インフラストラクチャのコード（IaC）ツールを使用して作業したいと考えるかもしれず、AWS Management Consoleにも精通しているかもしれません。

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

まず第一に、さまざまなチームが独立して作業できるエンドツーエンドシステムの主要なコンポーネントを明確に定義することが重要です。第二に、チーム間の明確なインターフェースを定義することで、協力効率を向上させる必要があります。これらのインターフェースは、チーム間の中断を最小限に抑え、定義されたインターフェースに準拠する限り、内部のプロセスを必要に応じて変更することができるようにします。次のダイアグラムは、コンピュータービジョンのパイプラインにおいてこれがどのように見えるかを示しています。

次に、MLOpsパイプライン全体のアーキテクチャを詳しく調べてみましょう：

1. プロセスは、製造環境でエッジカメラデバイスを使用して取得される金属タグの生の画像の収集から始まり、初期のトレーニングデータセットを形成します。
2. 次のステップは、これらの画像をラベリングし、バウンディングボックスを使用して欠陥をマークすることです。ラベル付けされたデータセットにバージョンを付け、利用されたトレーニングデータのトレース性と責任を確保することが重要です。
3. ラベル付けされたデータセットがある場合、モデルのトレーニング、微調整、評価、バージョン管理を進めることができます。
4. モデルのパフォーマンスに満足したら、モデルをエッジデバイスにデプロイし、エッジでのライブ推論を実行することができます。
5. モデルが本番環境で稼働する間、エッジカメラデバイスは以前に見たことのない欠陥やエッジケースを含む貴重な画像データを生成します。予測の信頼性が低いか誤った予測をするモデルによって生成される画像を保存し、これらの画像を元のデータセットに追加することで、再びプロセスを開始することができます。

重要なことは、生の画像データ、ラベル付きデータセット、トレーニング済みモデルが異なるパイプライン間の明確に定義されたインターフェースとなるということです。MLOpsエンジニアとデータサイエンティストは、これらのアーティファクトを一貫して生成する限り、自分たちのパイプライン内で技術を選ぶ柔軟性があります。最も重要なことは、閉じられたフィードバックループを確立していることです。本番環境で行なわれる誤った予測や信頼性の低い予測は、データセットを定期的に拡張し、モデルを自動的に再トレーニングして改善するために使用することができます。

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

高レベルのアーキテクチャが確立されたので、さらに一歩深く進んで、AWSサービスを使用してこれを構築する方法を見てみましょう。ただし、この記事で示されているアーキテクチャは、データサイエンスプロセス全体を完全に制御したい場合を想定しています。ただし、エッジでの品質検査を始めたばかりの場合は、Amazon Lookout for Visionをおすすめします。これにより、MLコードを構築、保守、理解する必要なく、独自の品質検査モデルのトレーニングが可能です。詳細については、「Amazon Lookout for Vision now supports visual inspection of product defects at the edge」を参照してください。

ただし、完全な制御をしたい場合、次の図はアーキテクチャの一例です。

前回と同様に、ワークフローをステップバイステップで進め、要件に合うAWSサービスを特定しましょう：

1. Amazon Simple Storage Service（Amazon S3）は、低コストなストレージソリューションを提供するため、生の画像データの保存に使用されます。
2. ラベリングワークフローは、AWS Step Functionsを使用してオーケストレーションされます。これは、ラベリングワークフローの手順を簡単に組み合わせることができるサーバーレスのワークフローエンジンです。このワークフローの一環として、Amazon SageMaker Ground Truthを使用して、ラベリングジョブと管理されたヒューマンワークフォースを使ってラベリングを自動化します。AWS Lambdaはデータの準備、ラベリングジョブの開始、およびラベルのAmazon SageMaker Feature Storeへの保存に使用されます。
3. SageMaker Feature Storeはラベルを保存します。フィーチャーを一元的に管理し共有することができ、パイプラインを堅牢にするためのデータのバージョニング機能も組み込まれています。
4. モデルの構築とトレーニングパイプラインは、Amazon SageMaker Pipelinesを使用してオーケストレーションされます。これにより、他のSageMakerの機能が組み込まれたステップとして統合されます。SageMaker Training jobsはモデルのトレーニングを自動化し、SageMaker Processing jobsはデータの準備やモデルのパフォーマンス評価に使用されます。この例では、Ultralytics YOLOv8 Pythonパッケージとモデルアーキテクチャを使用して、オブジェクト検出モデルをトレーニングし、ONNX MLモデル形式でエクスポートします。
5. パフォーマンスが許容範囲内であれば、トレーニングされたモデルはインクリメンタルバージョン番号が付いてAmazon SageMaker Model Registryに登録されます。これはモデルトレーニングとエッジデプロイメントの手順の間のインターフェースとなります。ここではモデルの承認状態も管理します。他の使用されるサービスと同様に、完全に管理されているため、独自のインフラストラクチャを実行する必要はありません。
6. エッジデプロイメントワークフローは、ラベリングワークフローと同様にStep Functionsを使用して自動化されます。Step FunctionsのAPI統合を使用すると、AWS IoT Greengrassなどの必要なAWSサービスAPIを簡単に呼び出すことができます。これにより、新しいモデルコンポーネントを作成し、その後コンポーネントをエッジデバイスにデプロイすることができます。
7. AWS IoT Greengrassはエッジデバイスのランタイム環境として使用されます。エッジでのモデルと推論コンポーネントのデプロイライフサイクルを管理します。シンプルなAPI呼び出しを使用して、モデルや推論コンポーネントの新しいバージョンを簡単にデプロイすることができます。さらに、エッジのMLモデルは通常独立して実行されないため、AWS IoT GreengrassのさまざまなAWSおよびコミュニティ提供のコンポーネントを使用して他のサービスに接続することができます。

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

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

データラベリング、モデルトレーニング、エッジデプロイメントの手順は、ソリューションの中核です。したがって、これらの部分に関連するコードまたはデータの変更は、全体のオーケストレーションプロセスの新しい実行をトリガーする必要があります。これを実現するには、バージョン管理されたコードリポジトリからコードとインフラストラクチャの変更を自動的に本番環境にデプロイできるCI/CDシステムにこのパイプラインを統合する必要があります。前のアーキテクチャと同様に、チームの自律性は重要な要素です。以下の図は、AWSサービスを使用してこのように見える可能性があることを示しています。

CI/CDアーキテクチャを進めていきましょう：

1. AWS CodeCommitは、Gitリポジトリとして機能します。単純化のために、提供されたサンプルでは、ラベリング、モデルトレーニング、エッジデプロイメントといった異なる部分を単一のGitリポジトリ内のサブフォルダに分けています。実際のシナリオでは、各チームがそれぞれの部分に異なるリポジトリを使用することもあります。
2. インフラストラクチャの展開は、AWS CDKを使用して自動化され、各部分（ラベリング、トレーニング、エッジ）には独立したAWS CDKアプリが用意されます。
3. AWS CDKパイプライン機能は、AWS CodePipelineを使用してインフラストラクチャとコードの展開を自動化します。
4. AWS CDKは、各ステップごとに2つのコードパイプラインを展開します：アセットパイプラインとワークフローパイプライン。ワークフローをアセットデプロイメントから分離しておくことで、アセットの変更がない場合にはワークフローを個別に開始することができます（たとえば、トレーニング用の新しい画像がある場合など）
   • アセットコードパイプラインは、トレーニング中に使用されるAWS Identity and Access Management（IAM）ロール、Lambda関数、およびコンテナイメージなど、ワークフローの正常な実行に必要なすべてのインフラストラクチャを展開します。
   • ワークフローコードパイプラインは、実際のラベリング、トレーニング、またはエッジデプロイメントのワークフローを実行します。
5. アセットパイプラインは、コミット時および前のワークフローパイプラインの完了時に自動的にトリガーされます。
6. 全体のプロセスは、定期的な再トレーニングのためにAmazon EventBridgeルールを使用してスケジュールでトリガーされます。

CI/CDの統合により、エンドツーエンドの連鎖が完全に自動化されました。パイプラインは、Gitリポジトリでコードが変更された場合やデータの変更に対応するためのスケジュールに基づいてトリガーされます。

先を見据えて

述べたソリューションアーキテクチャは、エッジにおけるエンドツーエンドのMLOpsパイプラインを構築するための基本的なコンポーネントを表しています。ただし、要件に応じて、追加の機能を追加することを検討するかもしれません。以下にいくつかの例を示します：

• セキュリティポストゥアを向上させるために、マルチアカウント設定を導入します。詳細については、MLOps at the edge with Amazon SageMaker Edge Manager and AWS IoT Greengrassを参照してください。
• アーキテクチャをブループリントに組み込んで、他のチームが再利用できるようにします。たとえば、SageMaker Projectsを使用することで、詳細についてはBuild Custom SageMaker Project Templates – Best Practicesを参照してください。

結論

この記事では、AWSサービスを使用してエッジでの視覚品質検査のためのエンドツーエンドのMLOpsパイプラインを構築するためのアーキテクチャを概説しました。このアーキテクチャにより、データのラベリング、モデル開発、エッジ展開といったプロセス全体が効率化され、新しいモデルのバージョンを迅速かつ信頼性をもってトレーニング・実装することができます。サーバーレスおよび管理されたサービスを利用することで、インフラストラクチャの管理ではなく、ビジネス価値の提供に注力することができます。

このシリーズの第2部では、このアーキテクチャの実装について詳しく見ていき、具体的にはラベリングとモデルビルディングについて説明します。コードに直接アクセスしたい場合は、関連するGitHubリポジトリをチェックしてください。

We will continue to update VoAGI; if you have any questions or suggestions, please contact us!