Amélioration de la stabilité et de la flexibilité des pipelines ML chez Amazon Packaging Innovation avec Amazon SageMaker Pipelines

Pour ravir les clients et minimiser les déchets d'emballage, Amazon doit sélectionner le type d'emballage optimal pour les milliards de colis expédiés chaque année. Si trop peu de protection est utilisée pour un article fragile comme une tasse à café, l'article arrivera endommagé et Amazon risque la confiance de son client. Utiliser trop de protection entraînera une augmentation des coûts et des bacs de recyclage trop pleins. Avec des centaines de millions de produits disponibles, un mécanisme de décision évolutif est nécessaire pour apprendre en permanence des tests de produits et des commentaires des clients.

Pour résoudre ces problèmes, l'équipe Amazon Packaging Innovation a développé des modèles d'apprentissage automatique (ML) qui classent si les produits conviennent aux types d'emballage Amazon tels que les expéditeurs, les sacs ou les boîtes, ou peuvent même être expédiés sans emballage supplémentaire. Auparavant, l'équipe a développé un pipeline personnalisé basé sur Fonctions d'étape AWS pour effectuer des entraînements hebdomadaires et des travaux d'inférence quotidiens ou mensuels. Cependant, au fil du temps, le pipeline n'a pas fourni une flexibilité suffisante pour lancer des modèles avec de nouvelles architectures. Le développement des nouveaux pipelines a présenté une surcharge et a nécessité une coordination entre les scientifiques des données et les développeurs. Pour surmonter ces difficultés et accélérer le déploiement de nouveaux modèles et architectures, l'équipe a choisi d'orchestrer la formation et l'inférence des modèles avec Pipelines Amazon SageMaker.

Dans cet article, nous discutons de l'architecture d'orchestration précédente basée sur Step Functions, décrivons les architectures de formation et d'inférence à l'aide de Pipelines, et soulignons la flexibilité obtenue par l'équipe Amazon Packaging Innovation.

Défis de l'ancien pipeline ML chez Amazon Packaging Innovation

Pour intégrer un retour d'information continu sur les performances des emballages, un nouveau modèle est formé chaque semaine en utilisant un nombre croissant d'étiquettes. L'inférence pour l'ensemble de l'inventaire de produits est effectuée mensuellement, et une inférence quotidienne est effectuée pour fournir des prédictions juste à temps pour l'inventaire nouvellement ajouté.

Pour automatiser le processus de formation de plusieurs modèles et fournir des prédictions, l'équipe avait développé un pipeline personnalisé basé sur Step Functions pour orchestrer les étapes suivantes :

• Préparation des données pour les travaux d'entraînement et d'inférence et chargement des prédictions dans la base de données (Redshift d'Amazon) avec Colle AWS.
• Entraînement de modèle et inférence avec Amazon Sage Maker.
• Calcul des métriques de performance du modèle sur le jeu de validation avec Lot AWS.
• En utilisant Amazon DynamoDB pour stocker les configurations de modèle (telles que le taux de fractionnement des données pour la formation et la validation, l'emplacement de l'artefact du modèle, le type de modèle et le nombre d'instances pour la formation et l'inférence), les métriques de performances du modèle et la dernière version de modèle formée avec succès.
• Calcul des différences dans les scores de performance du modèle, changements dans la distribution des étiquettes de formation et comparaison de la taille des données d'entrée entre les versions précédente et nouvelle du modèle avec AWS Lambda fonctions.
• Compte tenu du grand nombre d'étapes, le pipeline nécessitait également un système d'alarme fiable à chaque étape pour alerter les parties prenantes de tout problème. Ceci a été accompli grâce à une combinaison de Service Amazon Simple Queue (Amazon SQS) et Service de notification simple d'Amazon (Amazon SNS). Les alarmes ont été créées pour informer les parties prenantes de l'entreprise, les scientifiques des données et les développeurs de toute étape ayant échoué et de grands écarts dans le modèle et les métriques de données.

Après avoir utilisé cette solution pendant près de 2 ans, l'équipe s'est rendu compte que cette implémentation ne fonctionnait bien que pour un flux de travail ML typique où un seul modèle était formé et noté sur un ensemble de données de validation. Cependant, la solution n'était pas suffisamment flexible pour les modèles complexes et n'était pas résistante aux pannes. Par exemple, l'architecture ne s'adaptait pas facilement à la formation de modèles séquentiels. Il était difficile d'ajouter ou de supprimer une étape sans dupliquer l'ensemble du pipeline et sans modifier l'infrastructure. Même de simples changements dans les étapes de traitement des données, tels que l'ajustement du taux de fractionnement des données ou la sélection d'un ensemble différent de fonctionnalités, nécessitaient une coordination à la fois d'un scientifique des données et d'un développeur. Lorsque le pipeline échouait à n'importe quelle étape, il devait être redémarré depuis le début, ce qui entraînait des exécutions répétées et une augmentation des coûts. Pour éviter des exécutions répétées et devoir redémarrer à partir de l'étape ayant échoué, l'équipe créerait une nouvelle copie d'une machine d'état abrégée. Ce dépannage a conduit à une prolifération des machines d'état, chacune commençant par les étapes couramment défaillantes. Enfin, si une tâche de formation rencontrait un écart dans la distribution des étiquettes, le score du modèle ou le nombre d'étiquettes, un scientifique des données devait revoir manuellement le modèle et ses métriques. Ensuite, un spécialiste des données accéderait à une table DynamoDB avec les versions de modèle et mettrait à jour la table pour s'assurer que le modèle correct était utilisé pour la tâche d'inférence suivante.

La maintenance de cette architecture nécessitait au moins une ressource dédiée et une ressource supplémentaire à plein temps pour le développement. Compte tenu des difficultés d'expansion du pipeline pour s'adapter à de nouveaux cas d'utilisation, les scientifiques des données avaient commencé à développer leurs propres flux de travail, ce qui avait conduit à une base de code croissante, à plusieurs tables de données avec des schémas de données similaires et à une surveillance décentralisée des modèles. L'accumulation de ces problèmes avait entraîné une baisse de la productivité de l'équipe et une augmentation des frais généraux.

Pour relever ces défis, l'équipe Amazon Packaging Innovation a évalué d'autres solutions existantes pour MLOps, notamment SageMaker Pipelines (Annonce de la sortie de décembre 2020). Pipelines est une capacité de SageMaker pour la création, la gestion, l'automatisation et la mise à l'échelle de flux de travail ML de bout en bout. Les pipelines vous permettent de réduire le nombre d'étapes sur l'ensemble du flux de travail ML et sont suffisamment flexibles pour permettre aux data scientists de définir un flux de travail ML personnalisé. Il s'occupe de la surveillance et de la journalisation des étapes. Il est également livré avec un registre de modèles qui versionne automatiquement les nouveaux modèles. Le registre de modèles comporte des flux de travail d'approbation intégrés pour sélectionner des modèles pour l'inférence en production. Les pipelines permettent également de mettre en cache les étapes appelées avec les mêmes arguments. Si une exécution précédente est trouvée, un cache est créé, ce qui permet un redémarrage facile au lieu de recalculer les étapes terminées avec succès.

Dans le processus d'évaluation, Pipelines s'est démarqué des autres solutions par sa flexibilité et la disponibilité de fonctionnalités permettant de prendre en charge et d'étendre les flux de travail actuels et futurs. Le passage aux pipelines a libéré le temps des développeurs de la maintenance et du dépannage de la plate-forme et a redirigé l'attention vers l'ajout de nouvelles fonctionnalités. Dans cet article, nous présentons la conception des workflows de formation et d'inférence de l'équipe Amazon Packaging Innovation à l'aide de Pipelines. Nous discutons également des avantages et de la réduction des coûts que l'équipe a réalisés en passant à Pipelines.

Canal de formation

L'équipe Amazon Packaging Innovation forme des modèles pour chaque type d'emballage en utilisant un nombre croissant d'étiquettes. Le diagramme suivant décrit l'ensemble du processus.

Le flux de travail commence par extraire les étiquettes et les fonctionnalités d'une base de données Amazon Redshift et décharger les données sur Service de stockage simple Amazon (Amazon S3) via une tâche d'extraction, de transformation et de chargement (ETL) planifiée. Avec les données d'entrée, un objet fichier avec le type de modèle et les paramètres est placé dans le compartiment S3. Ce fichier sert de déclencheur de pipeline via une fonction Lambda.

Les étapes suivantes sont entièrement personnalisables et entièrement définies par un spécialiste des données à l'aide du SDK Python SageMaker pour les pipelines. Dans le scénario que nous présentons dans cet article, les données d'entrée sont divisées en ensembles de formation et de validation et enregistrées dans un compartiment S3 en lançant une tâche de traitement SageMaker.

Lorsque les données sont prêtes dans Amazon S3, une tâche de formation SageMaker démarre. Une fois le modèle formé et créé avec succès, l'étape d'évaluation du modèle est effectuée sur les données de validation via une tâche de transformation par lots SageMaker. Les métriques du modèle sont ensuite comparées aux métriques du modèle de la semaine précédente à l'aide d'une tâche de traitement SageMaker. L'équipe a défini plusieurs critères personnalisés pour évaluer les écarts dans les performances du modèle. Le modèle est soit rejeté, soit approuvé sur la base de ces critères. Si le modèle est rejeté, le modèle approuvé précédent est utilisé pour les tâches d'inférence suivantes. Si le modèle est approuvé, sa version est enregistrée et ce modèle est utilisé pour les tâches d'inférence. Les parties prenantes reçoivent une notification du résultat via Amazon Cloud Watch alarmes.

La capture d'écran suivante de Amazon SageMakerStudio montre les étapes du pipeline de formation.

Pipelines suit chaque exécution de pipeline, que vous pouvez surveiller dans Studio. Vous pouvez également interroger la progression de l'exécution à l'aide de Boto3 au sein de l’ Interface de ligne de commande AWS (AWS CLI). Vous pouvez visualiser les métriques du modèle dans Studio et comparer différentes versions du modèle.

Pipeline d'inférence

L'équipe Amazon Packaging Innovation actualise mensuellement les prévisions pour l'ensemble de l'inventaire de produits. Des prédictions quotidiennes sont générées pour fournir des recommandations d'emballage juste à temps pour l'inventaire nouvellement ajouté à l'aide du dernier modèle formé. Cela nécessite que le pipeline d'inférence s'exécute quotidiennement avec différents volumes de données. Le diagramme suivant illustre ce flux de travail.

Semblable au pipeline de formation, l'inférence commence par le déchargement des données d'Amazon Redshift vers un compartiment S3. Un objet fichier placé dans Amazon S3 déclenche la fonction Lambda qui lance le pipeline d'inférence. Les entités sont préparées pour l'inférence et les données sont divisées en fichiers de taille appropriée à l'aide d'une tâche de traitement SageMaker. Ensuite, le pipeline identifie le dernier modèle approuvé pour exécuter les prédictions et les charger dans un compartiment S3. Enfin, les prédictions sont rechargées dans Amazon Redshift à l'aide de l'API boto3-data dans la tâche de traitement SageMaker.

La capture d'écran suivante de Studio montre les détails du pipeline d'inférence.

Avantages de choisir d'architecturer les flux de travail ML avec SageMaker Pipelines

Dans cette section, nous discutons des gains réalisés par l'équipe Amazon Packaging Innovation en passant aux pipelines pour la formation et l'inférence des modèles.

Fonctionnalités MLOps prêtes à l'emploi au niveau de la production

Tout en comparant différentes solutions internes et externes pour la prochaine solution de pipeline ML, un seul data scientist a pu prototyper et développer une version complète d'un flux de travail ML avec Pipelines dans un environnement Studio Jupyter en moins de 3 semaines. Même au stade du prototypage, il est devenu évident que Pipelines fournissait tous les composants d'infrastructure nécessaires pour un flux de production au niveau de la production : gestion des versions du modèle, mise en cache et alarmes. La disponibilité immédiate de ces fonctionnalités signifiait qu'aucun temps supplémentaire ne serait consacré à leur développement et à leur personnalisation. Ce fut une démonstration claire de valeur, qui a convaincu l'équipe Amazon Packaging Innovation que Pipelines était la bonne solution.

Flexibilité dans le développement de modèles ML

Le plus grand gain pour les data scientists de l'équipe était la possibilité d'expérimenter facilement et de parcourir différents modèles. Quel que soit le framework qu'ils préféraient pour leur travail de ML et le nombre d'étapes et de fonctionnalités qu'il impliquait, Pipelines a répondu à leurs besoins. Les scientifiques des données ont été habilités à expérimenter sans avoir à attendre le sprint de développement logiciel pour ajouter une fonctionnalité ou une étape supplémentaire.

Coûts Réduits

La fonctionnalité Pipelines de SageMaker est faim: vous ne payez que les ressources de calcul et le stockage associés à la formation et à l'inférence. Cependant, lorsque vous pensez au coût, vous devez tenir compte non seulement du coût des services utilisés, mais également des heures de développement nécessaires pour maintenir le flux de travail, le déboguer et le corriger. L'orchestration avec Pipelines est plus simple car elle se compose de moins d'éléments et d'une infrastructure familière. Auparavant, l'ajout d'une nouvelle fonctionnalité nécessitait au moins deux personnes (data scientist et ingénieur logiciel) au sein de l'équipe Amazon Packaging Innovation pour l'implémenter. Avec le pipeline repensé, les efforts d'ingénierie sont désormais dirigés vers une infrastructure personnalisée supplémentaire autour du pipeline, comme la création d'un référentiel unique pour le suivi du code d'apprentissage automatique, la simplification du déploiement du modèle sur les comptes AWS, le développement des travaux ETL intégrés et des fonctions réutilisables.

La possibilité de mettre en cache les étapes avec une entrée similaire a également contribué à la réduction des coûts, car les équipes étaient moins susceptibles de réexécuter l'ensemble du pipeline. Au lieu de cela, ils pourraient facilement le démarrer à partir du point de défaillance.

Conclusion

L'équipe Amazon Packaging Innovation forme des modèles ML sur une base mensuelle et met régulièrement à jour les prévisions pour les types d'emballage de produits recommandés. Ces recommandations les ont aidés à atteindre plusieurs objectifs à l'échelle de l'équipe et de l'entreprise en réduisant le gaspillage et en ravissant les clients à chaque commande. Les pipelines de formation et d'inférence doivent fonctionner de manière fiable sur une base régulière tout en permettant une amélioration constante des modèles.

La transition vers les pipelines a permis à l'équipe de déployer quatre nouvelles architectures de modèles multimodaux en production en moins de 2 mois. Le déploiement d'un nouveau modèle utilisant l'architecture précédente aurait nécessité 5 jours (avec la même architecture de modèle) à 1 mois (avec une nouvelle architecture de modèle). Le déploiement du même modèle à l'aide de Pipelines a permis à l'équipe de réduire le temps de développement à 4 heures avec la même architecture de modèle et à 5 jours avec une nouvelle architecture de modèle. Cela équivaut à une économie de près de 80 % des heures de travail.

Ressources additionnelles

Pour plus d'informations, consultez les ressources suivantes:

---

À propos des auteurs

Ankur Shukla est un scientifique principal des données chez AWS-ProServe basé à Palo Alto. Ankur a plus de 15 ans d'expérience dans le conseil en travaillant directement avec le client et en l'aidant à résoudre des problèmes commerciaux avec la technologie. Il dirige plusieurs initiatives mondiales de science appliquée et ML-Ops au sein d'AWS. Pendant son temps libre, il aime lire et passer du temps avec sa famille.

Akash Singla est un ingénieur principal en développement système au sein de l'équipe Amazon Packaging Innovation. Il a plus de 17 ans d'expérience dans la résolution de problèmes commerciaux critiques grâce à la technologie pour plusieurs secteurs d'activité verticaux. Il se concentre actuellement sur la mise à niveau de l'infrastructure NAWS pour une variété d'applications centrées sur l'emballage afin de mieux les faire évoluer.

Vitalina Komachko est un Data Scientist avec AWS Professional Services. Elle est titulaire d'un doctorat en pharmacologie et toxicologie, mais est passée à la science des données à partir d'un travail expérimental parce qu'elle voulait « posséder la génération de données et l'interprétation des résultats ». Plus tôt dans sa carrière, elle a travaillé avec des sociétés biotechnologiques et pharmaceutiques. Chez AWS, elle aime résoudre les problèmes des clients de divers secteurs et découvrir leurs défis uniques.

Prasanth Meiyappan est un scientifique appliqué senior chez Amazon Packaging Innovation depuis plus de 4 ans. Il a plus de 6 ans d'expérience dans l'industrie de l'apprentissage automatique et a expédié des produits pour améliorer l'expérience client de recherche et améliorer l'expérience d'emballage client. Prasanth est passionné par la durabilité et possède un doctorat en modélisation statistique du changement climatique.

Matthieu Balles est un chercheur scientifique principal qui travaille à optimiser la sélection des types d'emballages en utilisant les commentaires des clients et l'apprentissage automatique. Avant Amazon, Matt a travaillé comme post-doc effectuant des simulations de physique des particules en Allemagne et dans une vie antérieure, il a été directeur de production d'implants médicaux radioactifs dans une startup. Il est titulaire d'un doctorat. en physique de l'Université du Michigan.