Comment Yara utilise les fonctionnalités MLOps d'Amazon SageMaker pour mettre à l'échelle l'optimisation énergétique dans ses usines d'ammoniac

Yara est le leader mondial de la nutrition des cultures et un fournisseur de solutions environnementales et agricoles. L'ambition de Yara est axée sur la croissance d'un avenir alimentaire positif pour la nature qui crée de la valeur pour les clients, les actionnaires et la société dans son ensemble, et offre une chaîne de valeur alimentaire plus durable. Soutenant notre vision d'un monde sans faim et d'une planète respectée, Yara poursuit une stratégie de croissance durable de la valeur, promouvant une nutrition des cultures respectueuse du climat et des solutions énergétiques à zéro émission. Yara est également le plus grand producteur mondial d'ammoniac, de nitrates et de NPK les engrais. Leur segment de production est donc un élément essentiel de la réalisation de leur mission, avec l'ambition clairement affichée de devenir le leader mondial sur des paramètres tels que la sécurité, l'empreinte environnementale, la qualité et les coûts de production. L'objectif à long terme de Yara est « l'usine du futur » avec zéro émission et de faibles coûts.

S'appuyant sur une transformation allégée, Yara se concentre davantage sur les solutions numériques pour les aider à réaliser leurs ambitions. Pour diriger cet effort, Yara a créé une unité mondiale appelée Digital Production. Le succès de la production numérique et de ses solutions est une priorité clé pour Yara, et Yara a considérablement accru ses efforts dans ce domaine. Un domaine critique consiste à tirer parti de la grande quantité de données générées dans le cadre de leurs opérations. Par conséquent, Yara développe des produits basés sur les données qui les aident à optimiser la production, à augmenter la qualité des produits, à accroître la fiabilité des sites de production, à réduire les émissions, à accroître la sécurité et la productivité des travailleurs, à automatiser les processus manuels, etc.

L'énergie est une composante de coût majeure pour de nombreuses usines de production ; par conséquent, l'efficacité énergétique a un impact substantiel sur la rentabilité. Cependant, il y a souvent un manque de références solides sur ce à quoi ressemble une bonne performance et comment y arriver. La courbe de charge énergétique (ELC) de Yara est une solution qui utilise les meilleures performances historiques en matière de consommation d'énergie par rapport aux performances actuelles. Si la consommation actuelle s'écarte trop du meilleur historique, l'outil donne des recommandations aux opérateurs afin de piloter la consommation d'énergie.

Pour déployer ELC dans les usines de production et l'adapter à plusieurs sites à travers le monde, Yara devait créer une plate-forme MLOps. Cela garantirait que Yara formerait, déploierait et maintiendrait des modèles de manière fiable et efficace. De plus, pour étendre cela à plusieurs sites, Yara devait automatiser les processus de déploiement et de maintenance. Dans cet article, nous expliquons comment Yara utilise Amazon Sage Maker fonctionnalités, y compris le registre des modèles, Moniteur de modèle Amazon SageMakeret Pipelines Amazon SageMaker pour rationaliser le cycle de vie de l'apprentissage automatique (ML) en automatisant et en standardisant les pratiques MLOps. Nous fournissons un aperçu de la configuration, présentant le processus de création, de formation, de déploiement et de surveillance des modèles ML pour les usines du monde entier.

Présentation de la solution

ELC utilise les données des capteurs de l'Internet des objets (IoT) d'une usine. Ces capteurs mesurent des paramètres tels que le débit de production, les conditions ambiantes et les conditions des matières premières, etc. Ces données sont utilisées pour former un modèle de prédiction énergétique qui est ensuite utilisé pour générer des prédictions horaires. Les exploitants d'usine surveillent la consommation d'énergie réelle et la comparent à la consommation optimale telle que prédite par ELC. Si la consommation d'énergie actuelle s'écarte trop du point optimal, ELC fournit une action pour ajuster les variables de processus internes afin d'optimiser l'efficacité énergétique sur la base de modèles analytiques.

ELC est hébergé dans le cloud. Afin de diffuser en temps réel les données des capteurs d'une usine, Yara utilise AWS IoT Greengrass pour communiquer en toute sécurité avec Noyau AWS IoT et exportez les données IoT vers le cloud AWS. AWS IoT SiteWise est un service géré qui peut collecter, organiser, rechercher et consommer des données d'équipement à partir d'équipements industriels à grande échelle. Yara a créé des API à l'aide Passerelle d'API Amazon pour exposer les données du capteur à des applications telles que ELC.

Le backend de l'application ELC est déployé via Amazon ECS et alimente les tableaux de bord ELC sur le front-end qui sont utilisés par les opérateurs de l'usine. L'application ELC est chargée de fournir des mesures de consommation d'énergie prédictives horaires aux exploitants d'usines. Chaque usine est équipée de son propre modèle, car leurs caractéristiques de consommation d'énergie diffèrent. De plus, les usines sont regroupées dans différentes régions AWS en fonction de leur emplacement.

Le diagramme suivant illustre cette architecture.

Pour la création d'ELC et la mise à l'échelle de plusieurs usines, nous avions besoin d'une solution MLOps prenant en charge les éléments suivants :

• Évolutivité – Il peut évoluer en fonction des volumes de données. Certaines usines produisent plus de données que d'autres ; chaque usine peut produire plusieurs gigaoctets de données par jour.
• Extensibilité – Il peut être déployé dans de nouvelles régions et de nouveaux comptes.
• Répétabilité – Il a des modèles communs que nous pouvons utiliser pour intégrer une nouvelle usine.
• Flexibilité – Il peut modifier la configuration de déploiement en fonction des besoins de chaque usine.
• Fiabilité et suivi – Il peut exécuter des tests et avoir une visibilité claire sur l'état de toutes les usines actives. En cas d'échec, il peut revenir à l'état stable précédent.
• Entretien – La solution doit avoir un faible coût de maintenance. Il doit utiliser des services sans serveur dans la mesure du possible pour réduire l'empreinte de l'infrastructure.

Pour le ML, Yara a décidé d'utiliser SageMaker. SageMaker est un service entièrement géré qui couvre l'ensemble du flux de travail ML. Les fonctionnalités suivantes ont été essentielles dans le choix de SageMaker :

• Conteneurs de framework SageMaker – Yara avait formé des modèles prédictifs ELC sur TensorFlow, et avec les conteneurs de framework SageMaker, Yara a pu soulever et déplacer ces modèles avec un minimum de modifications de code dans SageMaker.
• Pipelines SageMaker – SageMaker Pipelines offre une interface Python permettant aux data scientists d'écrire des pipelines ML. Une grande partie du code ELC consiste en un pipeline d'entraînement et d'inférence, qui sont définis en Python.
• Registre de modèles SageMaker – Le registre de modèles SageMaker permet de cataloguer et de contrôler les versions des modèles. De plus, il facilite la gestion des métadonnées du modèle, telles que les métriques de formation.
• Moniteur de modèle SageMaker – Yara voulait surveiller la qualité et la distribution des données entrantes ainsi que les performances du modèle ELC. Les API SageMaker Model Monitor offrent une surveillance de la qualité des données et des modèles.

Pour gérer l'intégration continue et la livraison continue (CI/CD) pour les pipelines ML, Yara utilise Cadre de déploiement Amazon (ADF). ADF est une infrastructure open source développée par AWS pour gérer et déployer des ressources sur plusieurs comptes et régions AWS au sein d'une organisation AWS. ADF permet des déploiements par étapes, parallèles, multicomptes et interrégionaux d'applications ou de ressources via la structure définie dans Organisations AWS, tout en profitant de services tels que AWS CodePipeline, Création de code AWS, Code AWSCommitet AWS CloudFormation pour alléger le travail lourd et la gestion par rapport à une configuration CI/CD traditionnelle.

Vue d'ensemble de la solution

La solution complète pour la plate-forme MLOps a été construite en deux mois dans le cadre d'un effort collaboratif avec Services professionnels AWS. L'équipe travaillant sur le projet était composée de data scientists, d'ingénieurs de données et de spécialistes DevOps. Pour faciliter un développement plus rapide dans un environnement multi-équipes, Yara a choisi d'utiliser Zone d'atterrissage AWSne et les organisations pour créer, gérer et gouverner de manière centralisée différents comptes AWS. Par exemple, Yara dispose d'un compte de déploiement central et utilise des comptes de charge de travail pour héberger des applications métier. ELC est un cas d'utilisation d'optimisation de processus et est déployé pour optimiser les comptes de charge de travail. L'équipe Yara Digital Production travaille également sur des cas d'utilisation de ML dans des domaines autres que l'optimisation. L'infrastructure MLOps prend en charge le déploiement sur n'importe quel compte de charge de travail tant que les comptes sont créés via des organisations.

Le diagramme suivant illustre cette architecture.

L'utilisation d'un compte de déploiement central facilite la gestion des artefacts communs et des pipelines CI/CD. En termes de gestion des accès et de sécurité de ces artefacts communs, il s'agit d'une conception plus simple car les limites d'autorisation et les clés de chiffrement sont gérées de manière centralisée à un seul endroit. Dans les sections suivantes, nous vous expliquons les étapes requises pour intégrer un nouveau cas d'utilisation à la plate-forme MLOps de Yara.

En termes de stratégie de compte, Yara a une configuration sandbox, DEV, TEST et PROD. Le compte sandbox est utilisé pour l'expérimentation et l'essai de nouvelles idées. Le compte DEV est le point de départ des pipelines CI/CD, et tout le développement commence ici. Le compte de déploiement contient la définition du pipeline CI/CD et peut être déployé sur les comptes DEV, TEST et PROD. Cette configuration de compte est illustrée dans la figure suivante.

Intégration d'un nouveau cas d'utilisation

Pour cet article, nous supposons que nous avons un prototype fonctionnel d'un cas d'utilisation, et maintenant nous voulons l'opérationnaliser. Dans le cas où ce cas d'utilisation appartient à un nouveau domaine de produits, nous devons d'abord provisionner les comptes à l'aide d'Organisations, ce qui déclenche automatiquement ADF pour démarrer ces comptes pour le déploiement. Yara suit une stratégie de compte DEV>TEST>PROD ; cependant, cette configuration n'est pas obligatoire. Les comptes de données exposent les API pour l'accès aux données, et pour un nouveau cas d'utilisation, les rôles doivent recevoir le nécessaire Gestion des identités et des accès AWS (IAM) afin qu'ils puissent accéder aux API de données.

Ensuite, nous devons définir sur quels comptes ce cas d'utilisation est déployé. Cela se fait à l'aide d'une carte de déploiement dans ADF. La carte de déploiement est un fichier de configuration qui contient le mappage des étapes et des cibles du pipeline. Pour exécuter la carte de déploiement, ADF utilise CodePipeline. ADF offre la flexibilité de gérer les paramètres par environnement cible dans lequel la pile est déployée. Cela facilite la gestion des déploiements et les tests avec des instances plus petites.

Pour chiffrer tous les artefacts, tels que le code, les données et les fichiers de modèle, nous générons un Service de gestion des clés AWS (AWS KMS). Vous pouvez également utiliser le chiffrement côté serveur. Cependant, étant donné que certains des artefacts générés sont accessibles à travers les comptes, nous devons générer notre propre clé et gérer ses politiques d'autorisation pour accorder l'accès entre comptes.

Enfin, nous devons créer un groupe de packages de modèles pour regrouper différentes versions d'un modèle à l'aide du registre de modèles SageMaker, qui est la capacité de SageMaker à suivre et à gérer les modèles tout au long du cycle de vie ML.

Modèle de pipeline de formation

Pour chaque nouvelle usine intégrée à ELC, nous créons un nouveau pipeline de formation SageMaker. Ce pipeline comprend des étapes de prétraitement des données et de formation du modèle. Les pipelines SageMaker conviennent parfaitement à Yara car ils offrent une interface Python pour définir un flux de travail ML. De plus, différentes étapes du flux de travail peuvent être configurées pour évoluer différemment. Par exemple, vous pouvez définir une instance beaucoup plus grande pour la formation que pour l'étape d'évaluation du modèle. Les paramètres d'entrée et de sortie de chaque étape du pipeline sont stockés, ce qui facilite le suivi de chaque exécution et de ses sorties. Le plan de haut niveau du flux de travail de formation est le suivant.

Dans le cadre de l'étape d'évaluation du modèle, un ensemble de données d'évaluation est utilisé pour générer des métriques, telles que la précision et l'écart de l'erreur quadratique moyenne (RMSE) sur le modèle entraîné. Ces métriques sont ajoutées aux métadonnées du modèle avant l'enregistrement du modèle dans le registre des modèles. Actuellement, les modèles sont promus manuellement vers des environnements supérieurs, et l'approbateur du modèle peut afficher les métriques du modèle pour s'assurer que la nouvelle version fonctionne mieux que le modèle actuel.

Les modèles sont contrôlés par version avec le registre de modèles, chaque usine ayant son propre groupe de packages de modèles. De plus, vous pouvez utiliser le registre de modèles pour suivre quelles versions de modèle sont déployées dans quels environnements. Un modèle peut être dans un Rejeté, En attente d'approbation manuelleou A approuvé état, et seuls les modèles qui sont dans l'état A approuvé état peut être déployé. Cela offre également une protection contre le déploiement accidentel d'une version non approuvée du modèle.

Inférence de modèle et pipeline de surveillance

Pour déployer le modèle et configurer la surveillance du modèle, nous avons configuré un deuxième pipeline SageMaker. L'application ELC fournit aux opérateurs de l'usine des prédictions à la demande, par conséquent, les modèles sont accessibles via des appels API effectués à partir du backend ELC. Les points de terminaison d'inférence SageMaker fournissent une solution d'hébergement de modèles entièrement gérée avec une couche API ; les points de terminaison prennent l'entrée du modèle comme charge utile et renvoient des prédictions. Étant donné que la latence est également un facteur crucial pour les utilisateurs finaux qui ne veulent pas attendre longtemps avant d'obtenir des prédictions mises à jour, Yara a opté pour les points de terminaison d'inférence en temps réel SageMaker, qui sont particulièrement adaptés aux charges de travail avec des exigences de latence très faibles. Enfin, étant donné que l'application ELC ne peut pas avoir de temps d'arrêt pendant le déploiement des modèles mis à jour, elle s'appuie sur la capacité de déploiement bleu/vert des points de terminaison en temps réel SageMaker pour garantir que l'ancienne version du modèle continue de servir la prédiction jusqu'à ce que la nouvelle version soit déployée. .

Le schéma suivant illustre la configuration du déploiement et de la surveillance.

Pour la surveillance des modèles, Yara exécute SageMaker qualité des données, qualité du modèleet explicabilité du modèle surveillance. La surveillance de la qualité des données vérifie la cohérence et génère des statistiques de distribution des données. La surveillance de la qualité du modèle vérifie les performances du modèle et compare la précision du modèle aux métriques de formation. Les rapports de surveillance des modèles sont générés toutes les heures. Ces rapports sont utilisés pour surveiller les performances du modèle en production. La surveillance de l'explicabilité du modèle est utilisée pour comprendre quelles caractéristiques contribuent le plus à une prédiction.

Ces résultats d'explicabilité du modèle sont partagés sur le tableau de bord ELC pour fournir aux exploitants d'usines plus de contexte sur ce qui motive la consommation d'énergie. Cela prend également en charge la détermination de l'action pour ajuster le processus interne au cas où la consommation d'énergie s'écarte du point optimal.

Flux CI/CD

Le flux CI/CD pour les pipelines de formation commence dans le compte DEV. Yara suit un modèle de développement basé sur les fonctionnalités et lorsqu'une nouvelle fonctionnalité est développée, la branche de fonctionnalité est fusionnée dans le tronc, ce qui démarre le déploiement. Les modèles ELC sont formés dans le compte DEV et une fois le modèle formé et évalué, il est enregistré dans le registre des modèles. Un approbateur de modèle effectue des vérifications d'intégrité avant de mettre à jour le statut du modèle pour A approuvé. Cette action génère un événement qui déclenche le déploiement du pipeline d'inférence de modèle. Le pipeline d'inférence de modèle déploie la nouvelle version de modèle sur un point de terminaison SageMaker dans DEV.

Après le déploiement du point de terminaison, les tests pour vérifier le comportement de l'installation sont lancés. Pour les tests, Yara utilise Rapports de test CodeBuild. Cette fonctionnalité permet aux développeurs d'exécuter des tests unitaires, des tests de configuration et des tests fonctionnels avant et après le déploiement. Dans ce cas, Yara exécute des tests fonctionnels en transmettant des charges utiles de test aux terminaux SageMaker et en évaluant la réponse. Une fois ces tests réussis, le pipeline procède au déploiement des points de terminaison SageMaker sur TEST. Le backend ELC est également déployé sur TEST, ce qui permet de tester l'application de bout en bout dans cet environnement. De plus, Yara exécute des tests d'acceptation par les utilisateurs dans TEST. Le déclencheur du déploiement TEST vers PROD est une action d'approbation manuelle. Une fois que la nouvelle version du modèle a réussi les tests d'acceptation fonctionnels et utilisateur dans TEST, l'équipe d'ingénierie approuve le déploiement du modèle dans PROD.

La figure suivante illustre ce workflow.

Composants communs

Pour ELC, nous utilisons plusieurs composants communs à toutes les étapes de déploiement (DEV, TEST, PROD) et modèles. Ces composants résident dans notre compte de déploiement et incluent le contrôle de version du modèle, un référentiel d'images de conteneurs, une clé de chiffrement et un compartiment pour stocker les artefacts communs.

L'utilisation d'artefacts courants présente plusieurs avantages. Par exemple, les ressources ne doivent pas nécessairement être créées pour chaque compte, ce qui renforce la compatibilité entre les comptes. Cela signifie que nous créons des images de conteneurs une seule fois et que nous les réutilisons dans tous les comptes cibles, ce qui réduit le temps de création.

Ce pipeline stocke les différentes versions de modèle dans un registre de modèles commun dans le compte de déploiement. À partir de cet emplacement central, les modèles peuvent être déployés dans tous les comptes sans les transférer. De même, l'utilisation d'une clé de chiffrement stockée de manière centralisée facilite la gestion de la clé et des autorisations entre comptes.

L'un des inconvénients de l'utilisation d'artefacts communs est que l'étape d'intégration d'un nouveau cas d'utilisation peut devenir plus élaborée. Pour intégrer un nouveau cas d'utilisation, un nouveau registre de modèles doit être créé et, si nécessaire, un nouveau référentiel d'images de conteneurs. Nous vous recommandons également de créer une nouvelle clé de chiffrement pour séparer strictement les ressources et les données stockées.

Conclusion

Dans cet article, nous avons montré comment Yara a utilisé SageMaker et ADF pour créer une plate-forme MLOps hautement évolutive. Le ML est une capacité interfonctionnelle, et les équipes déploient des modèles sur différents comptes d'unité commerciale. Par conséquent, ADF, qui offre une intégration native avec les organisations, en fait un candidat idéal pour amorcer des comptes afin de configurer des pipelines CI/CD. Sur le plan opérationnel, les pipelines ADF s'exécutent dans le compte de déploiement central, ce qui facilite l'obtention d'une vue d'ensemble de l'état des déploiements. Enfin, ADF utilise des services gérés AWS comme CodeBuild, CodeDeploy, CodePipeline et CloudFormation, ce qui facilite la configuration et la maintenance.

SageMaker fournit un large éventail de fonctionnalités ML, ce qui permet aux équipes de se concentrer davantage sur la résolution des problèmes commerciaux et moins sur la construction et la maintenance de l'infrastructure. De plus, SageMaker Pipelines fournit un riche ensemble d'API pour créer, mettre à jour et déployer des flux de travail ML, ce qui en fait un excellent choix pour MLOps.

Enfin, MLOps fournit les meilleures pratiques pour déployer et maintenir des modèles ML en production de manière fiable et efficace. Il est essentiel pour les équipes qui créent et déploient des solutions ML à grande échelle de mettre en œuvre des MLOps. Dans le cas de Yara, MLOps réduit considérablement les efforts nécessaires pour intégrer une nouvelle usine, déployer les mises à jour d'ELC et garantir la qualité des modèles.

Pour plus d'informations sur le déploiement d'applications à l'aide d'ADF, consultez le exemples.

---

À propos des auteurs

Shaheer Mansour est Data Scientist chez AWS. Il se concentre sur la création de plates-formes d'apprentissage automatique capables d'héberger des solutions d'IA à grande échelle. Ses domaines d'intérêt sont les MLOps, les magasins de fonctionnalités, l'hébergement de modèles et la surveillance des modèles.

Tim Becker est Senior Data Scientist chez Yara International. Au sein de la production numérique, il se concentre sur l'optimisation des processus de production d'ammoniac et d'acide nitrique. Il est titulaire d'un doctorat en thermodynamique et est passionné par l'association de l'ingénierie des procédés et de l'apprentissage automatique.

Yongyos Kaewpitakkun est data scientist senior au sein de l'équipe Digital Production de Yara International. Il est titulaire d'un doctorat en intelligence artificielle/apprentissage automatique et possède de nombreuses années d'expérience pratique dans l'exploitation de modèles d'apprentissage automatique, de vision par ordinateur et de traitement du langage naturel pour résoudre des problèmes commerciaux complexes.