Créer un pipeline MLOps de bout en bout pour l'inspection visuelle de la qualité en périphérie – Partie 1 | Services Web Amazon

Un déploiement réussi d'un modèle d'apprentissage automatique (ML) dans un environnement de production repose en grande partie sur un pipeline ML de bout en bout. Même si le développement d'un tel pipeline peut s'avérer difficile, cela devient encore plus complexe lorsqu'il s'agit d'un Cas d'utilisation de Edge ML. L'apprentissage automatique à la périphérie est un concept qui apporte la possibilité d'exécuter des modèles ML localement sur des appareils périphériques. Afin de déployer, surveiller et maintenir ces modèles à la périphérie, un pipeline MLOps robuste est nécessaire. Un pipeline MLOps permet d'automatiser le cycle de vie complet du ML, depuis l'étiquetage des données jusqu'à la formation et le déploiement du modèle.

La mise en œuvre d'un pipeline MLOps à la périphérie introduit des complexités supplémentaires qui rendent les processus d'automatisation, d'intégration et de maintenance plus difficiles en raison de la surcharge opérationnelle accrue impliquée. Cependant, en utilisant des services spécialement conçus comme Amazon Sage Maker et les AWS IoT Greengrass vous permet de réduire considérablement cet effort. Dans cette série, nous vous guidons à travers le processus d'architecture et de création d'un pipeline MLOps intégré de bout en bout pour un cas d'utilisation de vision par ordinateur à la périphérie à l'aide de SageMaker, AWS IoT Greengrass et du Kit de développement AWS Cloud (AWSCDK).

Cet article se concentre sur la conception de l'architecture globale du pipeline MLOps ; Partie 2 et les Partie 3 de cette série se concentrent sur la mise en œuvre des composants individuels. Nous avons fourni un exemple d'implémentation dans le document ci-joint. GitHub référentiel à vous d'essayer. Si vous débutez avec MLOps en périphérie sur AWS, reportez-vous à MLOps à la périphérie avec Amazon SageMaker Edge Manager et AWS IoT Greengrass pour une vue d’ensemble et une architecture de référence.

Cas d'utilisation : Inspection de la qualité des étiquettes métalliques

En tant qu'ingénieur ML, il est important de comprendre l'analyse de rentabilisation sur laquelle vous travaillez. Donc, avant de plonger dans l'architecture du pipeline MLOps, examinons l'exemple de cas d'utilisation pour cet article. Imaginez une ligne de production d'un fabricant qui grave des étiquettes métalliques pour créer des étiquettes de bagages personnalisées. Le processus d'assurance qualité est coûteux car les étiquettes en métal brut doivent être inspectées manuellement pour détecter des défauts tels que des rayures. Pour rendre ce processus plus efficace, nous utilisons le ML pour détecter les balises défectueuses dès le début du processus. Cela permet d’éviter des défauts coûteux aux étapes ultérieures du processus de production. Le modèle doit identifier les défauts possibles comme les rayures en temps quasi réel et les marquer. Dans les environnements d’atelier de fabrication, vous devez souvent faire face à une absence de connectivité, à une bande passante limitée et à une latence accrue. Par conséquent, nous souhaitons mettre en œuvre une solution ML de pointe pour l'inspection visuelle de la qualité, capable d'exécuter des inférences localement dans l'atelier et de réduire les exigences en matière de connectivité. Pour que notre exemple reste simple, nous entraînons un modèle qui marque les rayures détectées avec des cadres de délimitation. L'image suivante est un exemple de balise de notre ensemble de données avec trois rayures marquées.

Définir l'architecture du pipeline

Nous avons maintenant gagné en clarté sur notre cas d'utilisation et sur le problème spécifique de ML que nous souhaitons résoudre, qui tourne autour de la détection d'objets en périphérie. Il est maintenant temps de rédiger une architecture pour notre pipeline MLOps. À ce stade, nous ne nous penchons pas encore sur des technologies ou des services spécifiques, mais plutôt sur les composants de haut niveau de notre pipeline. Afin de nous recycler et de déployer rapidement, nous devons automatiser l'ensemble du processus de bout en bout : de l'étiquetage des données à la formation et à l'inférence. Cependant, il existe quelques défis qui rendent la mise en place d'un pipeline pour un cas limite particulièrement difficile :

• Construire différentes parties de ce processus nécessite différents ensembles de compétences. Par exemple, l'étiquetage et la formation des données sont fortement axés sur la science des données, le déploiement en périphérie nécessite un spécialiste de l'Internet des objets (IoT) et l'automatisation de l'ensemble du processus est généralement effectuée par une personne possédant des compétences DevOps.
• Selon votre organisation, l'ensemble de ce processus peut même être mis en œuvre par plusieurs équipes. Pour notre cas d'utilisation, nous partons du principe que des équipes distinctes sont responsables de l'étiquetage, de la formation et du déploiement.
• Un plus grand nombre de rôles et de compétences signifie des exigences différentes en matière d'outils et de processus. Par exemple, les data scientists voudront peut-être surveiller et travailler avec leur environnement de notebook familier. Les ingénieurs MLOps souhaitent travailler à l'aide d'outils d'infrastructure en tant que code (IaC) et sont peut-être plus familiers avec le Console de gestion AWS.

Qu'est-ce que cela signifie pour notre architecture de pipeline ?

Premièrement, il est crucial de définir clairement les principaux composants du système de bout en bout qui permet aux différentes équipes de travailler de manière indépendante. Deuxièmement, des interfaces bien définies entre les équipes doivent être définies pour améliorer l'efficacité de la collaboration. Ces interfaces permettent de minimiser les perturbations entre les équipes, leur permettant de modifier leurs processus internes selon leurs besoins à condition de respecter les interfaces définies. Le diagramme suivant illustre à quoi cela pourrait ressembler pour notre pipeline de vision par ordinateur.

Examinons en détail l'architecture globale du pipeline MLOps :

1. Le processus commence par une collection d'images brutes d'étiquettes métalliques, qui sont capturées à l'aide d'une caméra périphérique dans l'environnement de production pour former un ensemble de données de formation initial.
2. L'étape suivante consiste à étiqueter ces images et à marquer les défauts à l'aide de cadres de délimitation. Il est essentiel de versionner l'ensemble de données étiqueté, garantissant la traçabilité et la responsabilité des données de formation utilisées.
3. Une fois que nous disposons d'un ensemble de données étiqueté, nous pouvons procéder à la formation, au réglage fin, à l'évaluation et à la gestion des versions de notre modèle.
4. Lorsque nous sommes satisfaits des performances de notre modèle, nous pouvons déployer le modèle sur un appareil périphérique et exécuter des inférences en direct à la périphérie.
5. Pendant que le modèle fonctionne en production, la caméra périphérique génère des données d'image précieuses contenant des défauts et des cas limites inédits. Nous pouvons utiliser ces données pour améliorer encore les performances de notre modèle. Pour ce faire, nous enregistrons les images pour lesquelles le modèle prédit avec un faible niveau de confiance ou fait des prédictions erronées. Ces images sont ensuite ajoutées à notre ensemble de données brutes, relançant ainsi l'ensemble du processus.

Il est important de noter que les données d'image brutes, l'ensemble de données étiqueté et le modèle entraîné servent d'interfaces bien définies entre les pipelines distincts. Les ingénieurs MLOps et les data scientists ont la flexibilité de choisir les technologies au sein de leurs pipelines à condition qu'ils produisent systématiquement ces artefacts. Plus important encore, nous avons établi une boucle de rétroaction fermée. Les prédictions erronées ou peu fiables effectuées en production peuvent être utilisées pour augmenter régulièrement notre ensemble de données et recycler et améliorer automatiquement le modèle.

Architecture cible

Maintenant que l'architecture de haut niveau est établie, il est temps d'aller plus loin et de voir comment nous pourrions la construire avec les services AWS. Notez que l'architecture présentée dans cet article suppose que vous souhaitiez prendre le contrôle total de l'ensemble du processus de science des données. Toutefois, si vous débutez tout juste dans l'inspection de la qualité en périphérie, nous vous recommandons Amazon Lookout pour Vision. Il offre un moyen de former votre propre modèle d'inspection qualité sans avoir à créer, maintenir ou comprendre le code ML. Pour plus d'informations, reportez-vous à Amazon Lookout for Vision prend désormais en charge l'inspection visuelle des défauts du produit à la périphérie.

Cependant, si vous souhaitez prendre le contrôle total, le schéma suivant montre à quoi pourrait ressembler une architecture.

Comme précédemment, parcourons le flux de travail étape par étape et identifions les services AWS qui répondent à nos besoins :

1. Service de stockage simple Amazon (Amazon S3) est utilisé pour stocker des données d'image brutes car il nous offre une solution de stockage à faible coût.
2. Le flux de travail d'étiquetage est orchestré à l'aide Fonctions d'étape AWS, un moteur de workflow sans serveur qui facilite l'orchestration des étapes du workflow d'étiquetage. Dans le cadre de ce flux de travail, nous utilisons Vérité au sol Amazon SageMaker pour automatiser entièrement l'étiquetage à l'aide de tâches d'étiquetage et d'une main-d'œuvre humaine gérée. AWS Lambda est utilisé pour préparer les données, démarrer les tâches d'étiquetage et stocker les étiquettes dans Magasin de fonctionnalités Amazon SageMaker.
3. SageMaker Feature Store stocke les étiquettes. Il nous permet de gérer et de partager nos fonctionnalités de manière centralisée et nous fournit des capacités intégrées de gestion des versions de données, ce qui rend notre pipeline plus robuste.
4. Nous orchestrons la création de modèles et le pipeline de formation à l'aide Pipelines Amazon SageMaker. Il s'intègre aux autres fonctionnalités de SageMaker requises via des étapes intégrées. Emplois Formation SageMaker sont utilisés pour automatiser la formation du modèle, et Emplois de traitement SageMaker sont utilisés pour préparer les données et évaluer les performances du modèle. Dans cet exemple, nous utilisons le Ultralytiques YOLOv8 Package Python et architecture de modèle pour entraîner et exporter un modèle de détection d'objets vers le ONNX Format de modèle ML pour la portabilité.
5. Si les performances sont acceptables, le modèle entraîné est enregistré dans Registre de modèles Amazon SageMaker avec un numéro de version incrémentiel attaché. Il agit comme notre interface entre les étapes de formation du modèle et de déploiement en périphérie. Nous gérons également ici l’état d’approbation des modèles. Comme les autres services utilisés, il est entièrement géré, nous n'avons donc pas à nous occuper de gérer notre propre infrastructure.
6. Le flux de travail de déploiement Edge est automatisé à l'aide de Step Functions, similaire au flux de travail d'étiquetage. Nous pouvons utiliser les intégrations d'API de Step Functions pour appeler facilement les différentes API de service AWS requises comme AWS IoT Greengrass afin de créer de nouveaux composants de modèle et ensuite déployer les composants sur le périphérique périphérique.
7. AWS IoT Greengrass est utilisé comme environnement d'exécution des appareils périphériques. Il gère le cycle de vie de déploiement de nos composants de modèle et d'inférence à la périphérie. Cela nous permet de déployer facilement de nouvelles versions de nos composants de modèle et d'inférence à l'aide de simples appels API. De plus, les modèles ML en périphérie ne s'exécutent généralement pas de manière isolée ; nous pouvons utiliser les différents AWS et les Communautés fourni des composants d'AWS IoT Greengrass pour se connecter à d'autres services.

L'architecture décrite ressemble à notre architecture de haut niveau présentée précédemment. Amazon S3, SageMaker Feature Store et SageMaker Model Registry servent d'interfaces entre les différents pipelines. Pour minimiser les efforts d'exécution et d'exploitation de la solution, nous utilisons autant que possible des services gérés et sans serveur.

Fusionner dans un système CI/CD robuste

Les étapes d'étiquetage des données, de formation des modèles et de déploiement en périphérie sont au cœur de notre solution. En tant que tel, toute modification liée au code ou aux données sous-jacentes dans l’une de ces parties devrait déclencher une nouvelle exécution de l’ensemble du processus d’orchestration. Pour y parvenir, nous devons intégrer ce pipeline dans un système CI/CD qui nous permet de déployer automatiquement les modifications de code et d'infrastructure depuis un référentiel de code versionné vers la production. Semblable à l’architecture précédente, l’autonomie des équipes est ici un aspect important. Le diagramme suivant montre à quoi cela pourrait ressembler en utilisant les services AWS.

Passons en revue l'architecture CI/CD :

1. Code AWSCommit agit comme notre référentiel Git. Par souci de simplicité, dans notre exemple fourni, nous avons séparé les parties distinctes (étiquetage, formation du modèle, déploiement Edge) via des sous-dossiers dans un seul référentiel git. Dans un scénario réel, chaque équipe peut utiliser des référentiels différents pour chaque pièce.
2. Le déploiement de l'infrastructure est automatisé à l'aide d'AWS CDK et chaque partie (étiquetage, formation et périphérie) dispose de sa propre application AWS CDK pour permettre des déploiements indépendants.
3. La fonctionnalité de pipeline AWS CDK utilise AWS CodePipeline pour automatiser les déploiements d’infrastructure et de code.
4. L'AWS CDK déploie deux pipelines de code pour chaque étape : un pipeline d'actifs et un pipeline de flux de travail. Nous avons séparé le flux de travail du déploiement des ressources pour nous permettre de démarrer les flux de travail séparément au cas où il n'y aurait aucune modification des ressources (par exemple, lorsque de nouvelles images sont disponibles pour la formation).
   • Le pipeline de code d'actif déploie toute l'infrastructure requise pour que le flux de travail s'exécute correctement, comme Gestion des identités et des accès AWS (IAM), les fonctions Lambda et les images de conteneurs utilisées pendant la formation.
   • Le pipeline de code de workflow exécute le workflow d'étiquetage, de formation ou de déploiement Edge.
5. Les pipelines d'actifs sont automatiquement déclenchés lors de la validation ainsi que lorsqu'un pipeline de workflow précédent est terminé.
6. L'ensemble du processus est déclenché selon un calendrier à l'aide d'un Amazon Event Bridge règle de recyclage régulier.

Avec l'intégration CI/CD, toute la chaîne de bout en bout est désormais entièrement automatisée. Le pipeline est déclenché chaque fois que le code change dans notre référentiel git ainsi que selon un calendrier adapté aux modifications de données.

Penser à l'avenir

L'architecture de solution décrite représente les composants de base pour créer un pipeline MLOps de bout en bout en périphérie. Cependant, en fonction de vos besoins, vous pourriez envisager d'ajouter des fonctionnalités supplémentaires. Voici quelques exemples :

Conclusion

Dans cet article, nous avons décrit notre architecture pour créer un pipeline MLOps de bout en bout pour l'inspection visuelle de la qualité en périphérie à l'aide des services AWS. Cette architecture rationalise l'ensemble du processus, englobant l'étiquetage des données, le développement du modèle et le déploiement en périphérie, nous permettant de former et de mettre en œuvre de nouvelles versions du modèle de manière rapide et fiable. Avec les services sans serveur et gérés, nous pouvons nous concentrer sur la création de valeur commerciale plutôt que sur la gestion de l’infrastructure.

In Partie 2 Dans cette série, nous approfondirons un niveau et examinerons plus en détail la mise en œuvre de cette architecture, en particulier l'étiquetage et la création de modèles. Si vous souhaitez accéder directement au code, vous pouvez consulter le document ci-joint. GitHub repo.

---

À propos des auteurs

Michael Roth est un architecte de solutions senior chez AWS qui aide les clients du secteur manufacturier en Allemagne à résoudre leurs défis commerciaux grâce à la technologie AWS. Outre son travail et sa famille, il s'intéresse aux voitures de sport et apprécie le café italien.

Jörg Wöhrle est architecte de solutions chez AWS, travaillant avec des clients fabricants en Allemagne. Passionné par l'automatisation, Joerg a travaillé en tant que développeur de logiciels, ingénieur DevOps et ingénieur en fiabilité de site avant AWS. Au-delà du cloud, c'est un coureur ambitieux qui aime passer du temps de qualité avec sa famille. Alors si vous avez un défi DevOps ou si vous souhaitez vous lancer : faites-le-lui savoir.

Johannes Langer est architecte de solutions senior chez AWS, travaillant avec des entreprises clientes en Allemagne. Johannes est passionné par l'application de l'apprentissage automatique pour résoudre de vrais problèmes commerciaux. Dans sa vie personnelle, Johannes aime travailler sur des projets de rénovation domiciliaire et passer du temps dehors avec sa famille.

• Contenu propulsé par le référencement et distribution de relations publiques. Soyez amplifié aujourd'hui.
• PlatoData.Network Ai générative verticale. Autonomisez-vous. Accéder ici.
• PlatoAiStream. Intelligence Web3. Connaissance Amplifiée. Accéder ici.
• PlatonESG. Carbone, Technologie propre, Énergie, Environnement, Solaire, La gestion des déchets. Accéder ici.
• PlatoHealth. Veille biotechnologique et essais cliniques. Accéder ici.
• La source: https://aws.amazon.com/blogs/machine-learning/build-an-end-to-end-mlops-pipeline-for-visual-quality-inspection-at-the-edge-part-1/