In che modo Yara utilizza le funzionalità MLOps di Amazon SageMaker per ridimensionare l'ottimizzazione energetica nei suoi impianti di ammoniaca

Yara è l'azienda leader mondiale nella nutrizione delle colture e un fornitore di soluzioni ambientali e agricole. L'ambizione di Yara è focalizzata sulla crescita di un futuro alimentare positivo per la natura che crei valore per i clienti, gli azionisti e la società in generale e fornisca una catena del valore alimentare più sostenibile. Sostenendo la nostra visione di un mondo senza fame e un pianeta rispettato, Yara persegue una strategia di crescita sostenibile del valore, promuovendo una nutrizione delle colture rispettosa del clima e soluzioni energetiche a zero emissioni. Yara è anche il più grande produttore mondiale di ammoniaca, nitrati e NPK fertilizzanti. Il loro segmento di produzione è quindi un elemento fondamentale per realizzare la loro missione, con l'ambizione chiaramente dichiarata di diventare leader mondiale su parametri quali sicurezza, impatto ambientale, qualità e costi di produzione. L'obiettivo a lungo termine di Yara è "l'impianto del futuro" con zero emissioni e bassi costi.

Basandosi su una trasformazione snella, Yara aumenta la propria attenzione sulle soluzioni digitali per aiutarli a raggiungere le proprie ambizioni. Per guidare questo sforzo, Yara ha istituito un'unità globale denominata Produzione digitale. Il successo della produzione digitale e delle sue soluzioni è una priorità fondamentale per Yara e Yara ha aumentato notevolmente i propri sforzi in questo campo. Un'area critica è quella di sfruttare la grande quantità di dati generati come parte delle loro operazioni. Pertanto, Yara sta costruendo prodotti basati sui dati che li aiutano a ottimizzare la produzione, aumentare la qualità dei prodotti, aumentare l'affidabilità dei siti di produzione, ridurre le emissioni, aumentare la sicurezza e la produttività dei lavoratori, automatizzare i processi manuali e altro ancora.

L'energia è una componente di costo importante per molti impianti di produzione; quindi, l'efficienza energetica ha un impatto sostanziale sulla redditività. Tuttavia, spesso mancano solidi riferimenti su come siano le buone prestazioni e su come arrivarci. L'Energy Load Curve (ELC) di Yara è una soluzione che utilizza le migliori prestazioni storiche sul consumo energetico rispetto alle prestazioni attuali. Se il consumo di corrente si discosta troppo dal migliore storico, lo strumento fornisce raccomandazioni agli operatori per orientare il consumo di energia.

Per implementare ELC negli impianti di produzione e scalarlo su più siti in tutto il mondo, Yara aveva bisogno di creare una piattaforma MLOps. Ciò garantirebbe a Yara l'addestramento, l'implementazione e la manutenzione dei modelli in modo affidabile ed efficiente. Inoltre, per scalare questo su più siti, Yara aveva bisogno di automatizzare i processi di implementazione e manutenzione. In questo post, discutiamo di come sta usando Yara Amazon Sage Maker caratteristiche, incluso il registro dei modelli, Monitor modello Amazon SageMakere Pipeline di Amazon SageMaker per semplificare il ciclo di vita del machine learning (ML) automatizzando e standardizzando le pratiche MLOps. Forniamo una panoramica della configurazione, mostrando il processo di creazione, formazione, distribuzione e monitoraggio dei modelli ML per gli stabilimenti di tutto il mondo.

Panoramica della soluzione

ELC utilizza i dati dei sensori Internet of Things (IoT) provenienti da un impianto. Questi sensori misurano metriche come il rendimento di produzione, le condizioni ambientali e le condizioni delle materie prime, ecc. Questi dati vengono utilizzati per addestrare un modello di previsione energetica che viene quindi utilizzato per generare previsioni orarie. Gli operatori dell'impianto monitorano il consumo energetico effettivo e lo confrontano con il consumo ottimale previsto dall'ELC. Se il consumo di energia corrente si discosta troppo dal punto ottimale, l'ELC fornisce un'azione per regolare le variabili di processo interne per ottimizzare l'efficienza energetica sulla base di modelli analitici.

ELC è ospitato nel cloud. Per trasmettere i dati dei sensori da un impianto in tempo reale, Yara utilizza AWS IoT Greengrass con cui comunicare in modo sicuro AWS IoT Core ed esporta i dati IoT nel cloud AWS. AWS IoT SiteWise è un servizio gestito in grado di raccogliere, organizzare, cercare e utilizzare i dati delle apparecchiature da apparecchiature industriali su larga scala. Yara ha creato API utilizzando Gateway API Amazon per esporre i dati del sensore ad applicazioni come ELC.

Il back-end dell'applicazione ELC viene distribuito tramite Amazon ECS e alimenta i dashboard ELC sul front-end utilizzati dagli operatori dell'impianto. L'applicazione ELC è responsabile della fornitura di metriche di consumo energetico predittivo orario agli operatori dell'impianto. Ogni impianto è dotato di un proprio modello, perché le loro caratteristiche di consumo energetico sono diverse. Inoltre, gli impianti sono raggruppati in diverse regioni AWS in base alla loro posizione.

Il diagramma seguente illustra questa architettura.

Per creare ELC e scalare su più impianti, avevamo bisogno di una soluzione MLOps che supportasse quanto segue:

• Scalabilità – Può scalare in risposta ai volumi di dati. Alcuni impianti producono più dati di altri; ogni impianto può produrre diversi gigabyte di dati al giorno.
• Estensibilità – Può essere distribuito in nuove regioni e account.
• Ripetibilità – Dispone di modelli comuni che possiamo utilizzare per l'onboarding di un nuovo impianto.
• Flessibilità – Può modificare la configurazione di distribuzione in base alle esigenze di ciascun impianto.
• Affidabilità e monitoraggio – Può eseguire test e avere una chiara visibilità sullo stato di tutti gli impianti attivi. In caso di guasto, può tornare allo stato stabile precedente.
• Assistenza – La soluzione dovrebbe avere un basso sovraccarico di manutenzione. Dovrebbe utilizzare servizi serverless ove possibile per ridurre l'ingombro dell'infrastruttura.

Per ML, Yara ha deciso di utilizzare SageMaker. SageMaker è un servizio completamente gestito che copre l'intero flusso di lavoro ML. Le seguenti funzionalità sono state fondamentali nella scelta di SageMaker:

• Contenitori framework SageMaker – Yara aveva addestrato i modelli predittivi ELC su TensorFlow e, con i contenitori del framework SageMaker, Yara è stata in grado di sollevare e spostare questi modelli con modifiche minime al codice in SageMaker.
• Pipeline SageMaker – SageMaker Pipelines offre un'interfaccia Python per i data scientist per scrivere pipeline ML. Gran parte del codice ELC consiste in una pipeline di addestramento e inferenza, che sono definite in Python.
• Registro dei modelli SageMaker – Il registro dei modelli SageMaker consente di catalogare e controllare la versione dei modelli. Inoltre, semplifica la gestione dei metadati del modello, come le metriche di addestramento.
• Monitor modello SageMaker – Yara desiderava monitorare la qualità e la distribuzione dei dati in entrata, nonché le prestazioni del modello ELC. Le API SageMaker Model Monitor offrono il monitoraggio della qualità dei dati e dei modelli.

Per gestire l'integrazione continua e la distribuzione continua (CI/CD) per le pipeline ML, Yara utilizza Quadro di distribuzione di Amazon (ADF). ADF è un framework open source sviluppato da AWS per gestire e distribuire risorse su più account e regioni AWS all'interno di un'organizzazione AWS. ADF consente distribuzioni graduali, parallele, multi-account e tra regioni di applicazioni o risorse tramite la struttura definita in Organizzazioni AWS, approfittando di servizi come AWS Code Pipeline, AWSCodeBuild, AWS CodeCommite AWS CloudFormazione per alleviare il sollevamento pesante e la gestione rispetto a una configurazione CI/CD tradizionale.

Panoramica della soluzione

L'intera soluzione per la piattaforma MLOps è stata realizzata in due mesi in collaborazione con Servizi professionali AWS. Il team che ha lavorato al progetto era composto da data scientist, data engineer e specialisti DevOps. Per facilitare uno sviluppo più rapido in un ambiente multi-team, Yara ha scelto di utilizzare Zona di atterraggio AWSne e organizzazioni per creare, gestire e governare centralmente diversi account AWS. Ad esempio, Yara dispone di un account di distribuzione centrale e utilizza gli account del carico di lavoro per ospitare le applicazioni aziendali. ELC è un caso d'uso di ottimizzazione dei processi e viene implementato per ottimizzare gli account dei carichi di lavoro. Il team Yara Digital Production lavora anche su casi d'uso ML in aree diverse dall'ottimizzazione. Il framework MLOps supporta la distribuzione a qualsiasi account del carico di lavoro purché gli account vengano creati tramite le organizzazioni.

Il diagramma seguente illustra questa architettura.

L'utilizzo di un account di distribuzione centrale semplifica la gestione degli artefatti comuni e delle pipeline CI/CD. In termini di gestione degli accessi e sicurezza di questi artefatti comuni, è un design più semplice perché i limiti delle autorizzazioni e le chiavi di crittografia sono gestiti centralmente in un unico posto. Nelle sezioni seguenti, ti guideremo attraverso i passaggi necessari per eseguire l'onboarding di un nuovo caso d'uso sulla piattaforma MLOps di Yara.

In termini di strategia dell'account, Yara ha una configurazione sandbox, DEV, TEST e PROD. L'account sandbox viene utilizzato per sperimentare e provare nuove idee. L'account DEV è il punto di partenza delle pipeline CI/CD e tutto lo sviluppo inizia qui. L'account di distribuzione contiene la definizione della pipeline CI/CD ed è in grado di eseguire la distribuzione negli account DEV, TEST e PROD. Questa configurazione dell'account è illustrata nella figura seguente.

Onboarding di un nuovo caso d'uso

Per questo post, supponiamo di avere un prototipo funzionante di un caso d'uso e ora vogliamo renderlo operativo. Nel caso in cui questo caso d'uso appartenga a una nuova area di prodotto, dobbiamo prima eseguire il provisioning degli account utilizzando Organizations, che attiva automaticamente ADF per eseguire il bootstrap di questi account per la distribuzione. Yara segue una strategia dell'account DEV>TEST>PROD; tuttavia, questa configurazione non è obbligatoria. Gli account dati espongono le API per l'accesso ai dati e, per un nuovo caso d'uso, ai ruoli è necessario concedere quanto necessario Gestione dell'identità e dell'accesso di AWS (IAM) in modo che possano accedere alle API dei dati.

Successivamente, dobbiamo definire a quali account viene distribuito questo caso d'uso. Questa operazione viene eseguita utilizzando una mappa di distribuzione in ADF. La mappa di distribuzione è un file di configurazione che contiene il mapping delle fasi e delle destinazioni per la pipeline. Per eseguire la mappa di distribuzione, ADF usa CodePipeline. ADF offre la flessibilità necessaria per gestire i parametri in base all'ambiente di destinazione in cui viene distribuito lo stack. Ciò semplifica la gestione delle distribuzioni e il test con istanze più piccole.

Per crittografare tutti gli artefatti, come codice, dati e file di modello, generiamo un file Servizio di gestione delle chiavi AWS (AWS KMS). Puoi anche utilizzare la crittografia lato server. Tuttavia, poiché è possibile accedere ad alcuni degli artefatti generati da più account, è necessario generare la propria chiave e gestirne le policy di autorizzazione per concedere l'accesso tra più account.

Infine, dobbiamo creare un gruppo di pacchetti di modelli per raggruppare diverse versioni di un modello utilizzando il registro dei modelli di SageMaker, che è la capacità di SageMaker di tracciare e gestire i modelli mentre si spostano attraverso il ciclo di vita ML.

Pipeline di addestramento del modello

Per ogni nuovo impianto inserito per ELC, creiamo una nuova pipeline di formazione SageMaker. Questa pipeline è costituita da fasi di pre-elaborazione dei dati e di addestramento del modello. Le pipeline SageMaker sono adatte a Yara perché offrono un'interfaccia Python per la definizione di un flusso di lavoro ML. Inoltre, diverse fasi del flusso di lavoro possono essere configurate per ridimensionarsi in modo diverso. Ad esempio, puoi definire un'istanza molto più grande per l'addestramento rispetto alla fase di valutazione del modello. I parametri di input e output per ogni fase della pipeline vengono archiviati, il che semplifica il monitoraggio di ogni esecuzione e dei relativi output. Lo schema di alto livello del flusso di lavoro di formazione è il seguente.

Come parte della fase di valutazione del modello, viene utilizzato un set di dati di valutazione per generare metriche, come l'accuratezza e la deviazione dell'errore quadratico medio (RMSE) sul modello addestrato. Queste metriche vengono aggiunte ai metadati del modello prima di registrare il modello nel registro dei modelli. Attualmente, i modelli vengono promossi manualmente ad ambienti superiori e l'approvatore del modello può visualizzare le metriche del modello per garantire che la nuova versione funzioni meglio del modello corrente.

I modelli sono controllati dalla versione con il registro dei modelli, con ogni impianto che ha il proprio gruppo di pacchetti di modelli. Inoltre, è possibile utilizzare il registro dei modelli per tenere traccia delle versioni del modello distribuite in quali ambienti. Un modello può essere in a Rifiutato, In attesa di approvazione manuale, o Approvato stato, e solo i modelli che sono in Approvato stato può essere schierato. Ciò offre anche protezione dalla distribuzione accidentale di una versione non approvata del modello.

Inferenza del modello e pipeline di monitoraggio

Per distribuire il modello e impostare il monitoraggio del modello, abbiamo impostato una seconda pipeline SageMaker. L'applicazione ELC fornisce previsioni agli operatori dell'impianto su richiesta, quindi i modelli sono accessibili tramite chiamate API effettuate dal backend ELC. Gli endpoint di inferenza SageMaker forniscono una soluzione di hosting di modelli completamente gestita con un livello API; gli endpoint accettano l'input del modello come payload e restituiscono previsioni. Poiché la latenza è anche un fattore cruciale per gli utenti finali che non vogliono aspettare molto prima di ottenere previsioni aggiornate, Yara ha optato per gli endpoint di inferenza in tempo reale SageMaker, che sono particolarmente adatti per carichi di lavoro con requisiti di latenza molto bassi. Infine, poiché l'applicazione ELC non può avere tempi di inattività durante la distribuzione dei modelli aggiornati, si affida alla capacità di distribuzione blu/verde degli endpoint in tempo reale di SageMaker per garantire che la vecchia versione del modello continui a servire la previsione fino a quando la nuova versione non viene distribuita .

Il diagramma seguente illustra la configurazione della distribuzione e del monitoraggio.

Per il monitoraggio dei modelli, Yara esegue SageMaker qualità dei dati, qualità del modelloe spiegabilità del modello monitoraggio. Il monitoraggio della qualità dei dati verifica la coerenza e genera statistiche sulla distribuzione dei dati. Il monitoraggio della qualità del modello verifica le prestazioni del modello e confronta l'accuratezza del modello con le metriche di addestramento. I report di monitoraggio del modello vengono generati su base oraria. Questi report vengono utilizzati per monitorare le prestazioni del modello in produzione. Il monitoraggio della spiegabilità del modello viene utilizzato per comprendere quali caratteristiche contribuiscono maggiormente a una previsione.

Questi risultati di spiegabilità del modello sono condivisi sul dashboard ELC per fornire agli operatori dell'impianto un maggiore contesto su ciò che guida il consumo energetico. Ciò supporta anche la determinazione dell'azione per regolare il processo interno nel caso in cui il consumo di energia si discosti dal punto ottimale.

Flusso CI/CD

Il flusso CI/CD per le pipeline di addestramento inizia nell'account DEV. Yara segue un modello di sviluppo basato sulle funzionalità e quando viene sviluppata una nuova funzionalità, il feature branch viene unito al trunk, che avvia la distribuzione. I modelli ELC vengono addestrati nell'account DEV e dopo che il modello è stato addestrato e valutato, viene registrato nel registro dei modelli. Un approvatore del modello esegue controlli di integrità prima di aggiornare lo stato del modello a Approvato. Questa azione genera un evento che attiva la distribuzione della pipeline di inferenza del modello. La pipeline di inferenza del modello distribuisce la nuova versione del modello a un endpoint SageMaker in DEV.

Dopo la distribuzione dell'endpoint, vengono avviati i test per verificare il comportamento della configurazione. Per i test, Yara utilizza Rapporti sui test di CodeBuild. Questa funzionalità consente agli sviluppatori di eseguire unit test, test di configurazione e test funzionali prima e dopo la distribuzione. In questo caso, Yara esegue test funzionali passando i payload di test agli endpoint SageMaker e valutando la risposta. Dopo che questi test sono stati superati, la pipeline procede con la distribuzione degli endpoint SageMaker a TEST. Il back-end ELC viene distribuito anche a TEST, il che rende possibile il test end-to-end per l'app in questo ambiente. Inoltre, Yara esegue test di accettazione da parte dell'utente in TEST. Il trigger dalla distribuzione TEST a PROD è un'azione di approvazione manuale. Dopo che la nuova versione del modello ha superato i test funzionali e di accettazione da parte dell'utente in TEST, il team di ingegneri approva la distribuzione del modello in PROD.

La figura seguente illustra questo flusso di lavoro.

Componenti comuni

Per ELC, utilizziamo diversi componenti comuni a tutte le fasi di implementazione (DEV, TEST, PROD) e modelli. Questi componenti risiedono nel nostro account di distribuzione e includono il controllo della versione del modello, un repository di immagini del contenitore, una chiave di crittografia e un bucket per archiviare artefatti comuni.

Ci sono diversi vantaggi nell'usare artefatti comuni. Ad esempio, le risorse non devono essere create per ogni account, il che impone la compatibilità tra gli account. Ciò significa che creiamo le immagini del contenitore una volta e le riutilizziamo in tutti gli account di destinazione, riducendo i tempi di creazione.

Questa pipeline archivia le diverse versioni del modello in un registro del modello comune nell'account di distribuzione. Da questa posizione centrale, i modelli possono essere distribuiti in tutti gli account senza trasferirli. Allo stesso modo, l'uso di una chiave di crittografia archiviata centralmente semplifica la gestione della chiave e delle autorizzazioni tra account.

Uno svantaggio dell'utilizzo di artefatti comuni è che la fase di onboarding di un nuovo caso d'uso può diventare più elaborata. Per eseguire l'onboarding di un nuovo caso d'uso, è necessario creare un nuovo registro del modello e, se necessario, un nuovo repository di immagini del contenitore. Si consiglia inoltre di creare una nuova chiave di crittografia per separare rigorosamente le risorse e i dati archiviati.

Conclusione

In questo post, abbiamo dimostrato come Yara ha utilizzato SageMaker e ADF per creare una piattaforma MLOps altamente scalabile. Il machine learning è una funzionalità interfunzionale e i team distribuiscono i modelli a diversi account di business unit. Pertanto, ADF, che offre l'integrazione nativa con le organizzazioni, lo rende un candidato ideale per eseguire il bootstrap degli account per configurare pipeline CI/CD. Dal punto di vista operativo, le pipeline di ADF vengono eseguite nell'account di distribuzione centrale, il che semplifica la visualizzazione dell'integrità generale delle distribuzioni. Infine, ADF utilizza servizi gestiti da AWS come CodeBuild, CodeDeploy, CodePipeline e CloudFormation, semplificando la configurazione e la manutenzione.

SageMaker offre un'ampia gamma di funzionalità ML, che consente ai team di concentrarsi maggiormente sulla risoluzione dei problemi aziendali e meno sulla creazione e la manutenzione dell'infrastruttura. Inoltre, SageMaker Pipelines fornisce un ricco set di API per creare, aggiornare e distribuire flussi di lavoro ML, rendendolo perfetto per MLOps.

Infine, MLOps fornisce le best practice per distribuire e mantenere i modelli ML in produzione in modo affidabile ed efficiente. È fondamentale per i team che creano e distribuiscono soluzioni ML su larga scala per implementare MLOps. Nel caso di Yara, MLOps riduce significativamente lo sforzo necessario per l'onboarding di un nuovo impianto, implementare gli aggiornamenti a ELC e garantire che i modelli siano monitorati per la qualità.

Per ulteriori informazioni su come distribuire le applicazioni utilizzando ADF, vedere il Esempi.

---

Circa gli autori

Shaheer Mansoor è un Data Scientist presso AWS. Il suo focus è sulla creazione di piattaforme di machine learning in grado di ospitare soluzioni AI su larga scala. Le sue aree di interesse sono MLOps, feature store, model hosting e model monitoring.

Tim Becker è Senior Data Scientist presso Yara International. Nell'ambito della produzione digitale, si concentra sull'ottimizzazione dei processi di produzione di ammoniaca e acido nitrico. Ha conseguito un dottorato di ricerca in termodinamica ed è appassionato di riunire l'ingegneria di processo e l'apprendimento automatico.

Yongyos Kaewpitakkun è un data scientist senior nel team di produzione digitale di Yara International. Ha un dottorato di ricerca in AI/apprendimento automatico e molti anni di esperienza pratica sfruttando l'apprendimento automatico, la visione artificiale e i modelli di elaborazione del linguaggio naturale per risolvere problemi aziendali complessi.