Hvordan Yara bruger MLOps funktioner i Amazon SageMaker til at skalere energioptimering på tværs af deres ammoniakanlæg

Yara er verdens førende plantenæringsvirksomhed og leverandør af miljø- og landbrugsløsninger. Yaras ambition er fokuseret på at skabe en naturpositiv fødevarefremtid, der skaber værdi for kunder, aktionærer og samfundet som helhed og leverer en mere bæredygtig fødevareværdikæde. Yara støtter vores vision om en verden uden sult og en planet, der respekteres, og forfølger en strategi for bæredygtig værdivækst, fremme af klimavenlig afgrødernæring og nul-emission energiløsninger. Yara er også verdens største producent af ammoniak, nitrater og NPK gødning. Deres produktionssegment er derfor en integreret byggesten til at levere på deres mission – med en klart udtalt ambition om at blive verdensførende på målinger som sikkerhed, miljømæssig fodaftryk, kvalitet og produktionsomkostninger. Yaras langsigtede mål er "Fremtidens anlæg" med nul emissioner og lave omkostninger.

Med udgangspunkt i en slank transformation øger Yara deres fokus på digitale løsninger for at hjælpe dem med at nå deres ambitioner. For at lede denne indsats etablerede Yara en global enhed kaldet Digital Production. Succesen med Digital Production og dens løsninger er en nøgleprioritet for Yara, og Yara øgede deres indsats betydeligt inden for dette felt. Et kritisk fokusområde er at udnytte den store mængde data, der genereres som en del af deres drift. Derfor bygger Yara datadrevne produkter, der hjælper dem med at optimere produktionen, øge produkternes kvalitet, øge pålideligheden af ​​produktionssteder, reducere emissioner, øge sikkerheden og produktiviteten for arbejdere, automatisere manuelle processer og meget mere.

Energi er en væsentlig omkostningskomponent for mange produktionsanlæg; energieffektivitet har derfor en væsentlig indvirkning på rentabiliteten. Der mangler dog ofte solide referencer for, hvordan en god præstation ser ud, og hvordan man kommer dertil. Yaras Energy Load Curve (ELC) er en løsning, der bruger den bedste historiske ydeevne på energiforbrug holdt op mod den nuværende ydeevne. Hvis det aktuelle forbrug afviger for meget fra det historisk bedste, giver værktøjet anbefalinger til operatørerne med henblik på at styre energiforbruget.

For at implementere ELC til produktionsanlæg og skalere det til flere steder over hele kloden, var Yara nødt til at bygge en MLOps-platform. Dette ville sikre, at Yara ville træne, implementere og vedligeholde modeller pålideligt og effektivt. For at skalere dette til flere steder var Yara desuden nødt til at automatisere implementerings- og vedligeholdelsesprocesserne. I dette indlæg diskuterer vi, hvordan Yara bruger Amazon SageMaker funktioner, herunder modelregistret, Amazon SageMaker Model Monitorog Amazon SageMaker Pipelines at strømline maskinlærings (ML) livscyklus ved at automatisere og standardisere MLOps-praksis. Vi giver et overblik over opsætningen og viser processen med at bygge, træne, implementere og overvåge ML-modeller for fabrikker over hele kloden.

Oversigt over løsning

ELC bruger Internet of Things (IoT) sensordata fra en fabrik. Disse sensorer måler metrik som produktionsgennemstrømning, omgivende forhold og råmaterialeforhold osv. Disse data bruges til at træne en energiforudsigelsesmodel, som derefter bruges til at generere forudsigelser pr. time. Anlægsoperatører overvåger det faktiske energiforbrug og sammenligner det med det optimale forbrug som forudsagt af ELC. Hvis det aktuelle energiforbrug afviger for meget fra det optimale punkt, giver ELC en handling til at justere interne procesvariable for at optimere energieffektiviteten baseret på analytiske modeller.

ELC er hostet i skyen. For at streame sensordata fra et anlæg i realtid, bruger Yara AWS IoT Greengrass at kommunikere sikkert med AWS IoT Core og eksporter IoT-data til AWS-skyen. AWS IoT SiteWise er en administreret tjeneste, der kan indsamle, organisere, søge og forbruge udstyrsdata fra industrielt udstyr i stor skala. Yara har bygget API'er vha Amazon API Gateway at eksponere sensordata for applikationer såsom ELC.

ELC-applikationens backend implementeres via Amazon ECS og driver ELC-dashboards på frontenden, som bruges af fabriksoperatører. ELC-applikationen er ansvarlig for at levere forudsigelige energiforbrugsmålinger på timebasis til anlægsoperatører. Hvert anlæg er udstyret med sin egen model, fordi deres energiforbrugsegenskaber er forskellige. Desuden er planter samlet i forskellige AWS-regioner baseret på deres placering.

Følgende diagram illustrerer denne arkitektur.

For at bygge ELC og skalere til flere anlæg havde vi brug for en MLOps-løsning, der understøtter følgende:

• Skalerbarhed – Det kan skaleres som svar på datamængder. Nogle anlæg producerer mere data end andre; hver plante kan producere flere gigabyte data om dagen.
• Udvidbarhed – Det kan implementeres til nye regioner og konti.
• Gentagelsesnøjagtighed – Den har fælles skabeloner, som vi kan bruge til at ombord på et nyt anlæg.
• Fleksibilitet – Det kan ændre implementeringskonfigurationen baseret på hver enkelt fabriks behov.
• Pålidelighed og overvågning – Den kan køre test og have et klart overblik over status for alle aktive anlæg. I tilfælde af fejl kan den rulle tilbage til den tidligere stabile tilstand.
• Vedligeholdelse – Løsningen bør have en lav vedligeholdelsesomkostning. Det bør bruge serverløse tjenester, hvor det er muligt, for at reducere infrastrukturens fodaftryk.

Til ML besluttede Yara at bruge SageMaker. SageMaker er en fuldt administreret service, der dækker hele ML arbejdsgangen. Følgende funktioner var kritiske ved valget af SageMaker:

• SageMaker rammebeholdere – Yara havde trænet ELC-prædiktive modeller på TensorFlow, og med SageMaker rammebeholdere var Yara i stand til at løfte og flytte disse modeller med minimale kodeændringer til SageMaker.
• SageMaker Pipelines – SageMaker Pipelines tilbyder en Python-grænseflade til dataforskere til at skrive ML-pipelines. En stor del af ELC-koden består af en trænings- og en inferenspipeline, som er defineret i Python.
• SageMaker modelregistrering – SageMaker modelregistret gør det muligt at katalogisere og versionskontrol modeller. Derudover gør det det nemt at administrere modelmetadata, såsom træningsmålinger.
• SageMaker Model Monitor – Yara ønskede at overvåge kvaliteten og distributionen af ​​de indgående data samt ELC-modellens ydeevne. SageMaker Model Monitor API'er tilbyder data- og modelkvalitetsovervågning.

Til at styre den kontinuerlige integration og kontinuerlige levering (CI/CD) til ML-pipelines, bruger Yara Amazon Deployment Framework (ADF). ADF er en open source-ramme udviklet af AWS til at administrere og implementere ressourcer på tværs af flere AWS-konti og regioner i en AWS-organisation. ADF giver mulighed for trinvise, parallelle, multi-konto og tværgående udrulninger af applikationer eller ressourcer via strukturen defineret i AWS-organisationer, mens du udnytter tjenester som f.eks AWS CodePipeline, AWS CodeBuild, AWS CodeCommitog AWS CloudFormation for at afhjælpe de tunge løft og styring sammenlignet med et traditionelt CI/CD-setup.

Løsningsoversigt

Hele løsningen til MLOps-platformen blev bygget inden for to måneder i et samarbejde med AWS Professional Services. Teamet, der arbejdede på projektet, bestod af datavidenskabsmænd, dataingeniører og DevOps-specialister. For at facilitere hurtigere udvikling i et multi-team miljø, valgte Yara at bruge AWS Landing Zone og organisationer til centralt at oprette, administrere og styre forskellige AWS-konti. For eksempel har Yara en central implementeringskonto og bruger arbejdsbelastningskonti til at hoste forretningsapplikationer. ELC er en procesoptimeringsbrugscase og er implementeret for at optimere arbejdsbelastningskonti. Yara Digital Production-teamet arbejder også på ML use cases på andre områder end optimering. MLOps-rammen understøtter implementering til enhver arbejdsbelastningskonti, så længe konti er oprettet via Organisationer.

Følgende diagram illustrerer denne arkitektur.

Brug af en central implementeringskonto gør det nemt at administrere almindelige artefakter og CI/CD-pipelines. Med hensyn til adgangsstyring og sikkerhed for disse almindelige artefakter er det et enklere design, fordi tilladelsesgrænser og krypteringsnøgler administreres centralt ét sted. I de følgende sektioner leder vi dig gennem de trin, der kræves for at indsætte en ny use case til Yaras MLOps-platform.

Med hensyn til kontostrategi har Yara en sandbox, DEV, TEST og PROD opsætning. Sandkassekontoen bruges til at eksperimentere og afprøve nye ideer. DEV-kontoen er udgangspunktet for CI/CD-pipelines, og al udvikling starter her. Implementeringskontoen indeholder CI/CD-pipelinedefinitionen og er i stand til at implementere til DEV-, TEST- og PROD-kontiene. Denne kontoopsætning er afbildet i følgende figur.

Onboarding af en ny use case

Til dette indlæg antager vi, at vi har en fungerende prototype af en use case, og nu vil vi operationalisere den. Hvis denne use case tilhører et nyt produktområde, skal vi først klargøre konti ved hjælp af Organisationer, som automatisk udløser ADF til at bootstrap disse konti til implementering. Yara følger en DEV>TEST>PROD kontostrategi; denne konfiguration er dog ikke obligatorisk. Datakonti afslører API'er for dataadgang, og for en ny use case skal roller tildeles de nødvendige AWS identitets- og adgangsstyring (IAM)-tilladelser, så de kan få adgang til data-API'erne.

Dernæst skal vi definere, hvilke konti denne use case er implementeret til. Dette gøres ved hjælp af et implementeringskort i ADF. Implementeringskortet er en konfigurationsfil, der indeholder kortlægningen af ​​stadier og mål for pipelinen. Til at køre implementeringskortet bruger ADF CodePipeline. ADF giver fleksibiliteten til at administrere parametre pr. målmiljø, som stakken er implementeret til. Dette gør det nemt at administrere implementeringer og teste med mindre forekomster.

Til kryptering af alle artefakter, såsom kode, data og modelfiler, genererer vi en AWS Key Management Service (AWS KMS)-tast. Du kan også bruge server-side kryptering. Men fordi nogle af de genererede artefakter er tilgået på tværs af konti, er vi nødt til at generere vores egen nøgle og administrere dens tilladelsespolitikker for at give adgang på tværs af konti.

Til sidst skal vi oprette en modelpakkegruppe for at gruppere forskellige versioner af en model ved hjælp af SageMaker-modelregistret, som er SageMakers evne til at spore og administrere modeller, når de bevæger sig gennem ML-livscyklussen.

Model træningspipeline

For hver ny fabrik, der er ombord på ELC, skaber vi en ny SageMaker-uddannelsespipeline. Denne pipeline består af dataforbehandling og modeltræningstrin. SageMaker-pipelines passer godt til Yara, fordi de tilbyder en Python-grænseflade til at definere en ML-arbejdsgang. Desuden kan forskellige trin i arbejdsgangen konfigureres til at skalere forskelligt. For eksempel kan du definere en meget større instans til træning end for modelevalueringstrinnet. Input- og outputparametre for hvert trin i pipelinen gemmes, hvilket gør det nemt at spore hver kørsel og dens output. Oversigten over træningsarbejdsgangen på højt niveau er som følger.

Som en del af modelevalueringsfasen bruges et evalueringsdatasæt til at generere metrics, såsom nøjagtighed og root-mean-squared error (RMSE) afvigelse på den trænede model. Disse metrikker føjes til modellens metadata, før modellen registreres i modelregistret. I øjeblikket promoveres modeller manuelt til højere miljøer, og modelgodkenderen kan se modelmålingerne for at sikre, at den nye version yder bedre end den nuværende model.

Modeller er versionsstyret med modelregistret, hvor hvert anlæg har sin egen modelpakkegruppe. Derudover kan du bruge modelregistret til at spore, hvilke modelversioner der er implementeret i hvilke miljøer. En model kan være i en Afvist, Afventer manuel godkendelse eller godkendt stat, og kun modeller, der er i godkendt stat kan indsættes. Dette giver også beskyttelse mod utilsigtet implementering af en ikke-godkendt version af modellen.

Modelinferens og overvågningspipeline

For at implementere modellen og opsætte modelovervågning, satte vi en anden SageMaker-pipeline op. ELC-applikationen giver anlægsoperatører forudsigelser efter behov, derfor tilgås modellerne via API-kald foretaget fra ELC-backend. SageMaker inference endpoints giver en fuldt administreret model-hosting-løsning med et API-lag; endepunkter tager modelinput som nyttelast og afkast forudsigelser. Fordi latency også er en afgørende faktor for de slutbrugere, der ikke ønsker at vente længe, ​​før de får opdaterede forudsigelser, valgte Yara SageMaker real-time inference endpoints, som er særligt velegnede til arbejdsbelastninger med meget lave latenskrav. Endelig, fordi ELC-applikationen ikke kan have nedetid, mens opdaterede modeller implementeres, er den afhængig af den blå/grønne implementeringsevne fra SageMaker real-time endpoints for at sikre, at den gamle modelversion fortsætter med at tjene forudsigelse, indtil den nye version er implementeret .

Følgende diagram illustrerer installations- og overvågningsopsætningen.

Til modelovervågning kører Yara SageMaker datakvalitet, model kvalitetog modelforklarlighed overvågning. Datakvalitetsovervågningen kontrollerer for sammenhæng og genererer datadistributionsstatistikker. Modelkvalitetsovervågning kontrollerer modellens ydeevne og sammenligner modellens nøjagtighed med træningsmetrikken. Modelovervågningsrapporter genereres på timebasis. Disse rapporter bruges til at overvåge modellens ydeevne i produktionen. Overvågning af modelforklarlighed bruges til at forstå, hvilke funktioner der bidrager mest til en forudsigelse.

Disse resultater af modelforklarlighed deles på ELC-dashboardet for at give anlægsoperatører mere kontekst om, hvad der driver energiforbruget. Dette understøtter også at bestemme handlingen for at justere den interne proces, hvis energiforbruget afviger fra det optimale punkt.

CI/CD flow

CI/CD-flowet for træningspipelines starter i DEV-kontoen. Yara følger en funktionsbaseret udviklingsmodel, og når en ny funktion udvikles, flettes funktionsgrenen ind i stammen, som starter implementeringen. ELC-modeller trænes i DEV-kontoen, og efter at modellen er trænet og evalueret, registreres den i modelregistret. En modelgodkender udfører fornuftstjek før opdatering af modelstatus til godkendt. Denne handling genererer en hændelse, der udløser implementeringen af ​​modelinferenspipelinen. Modelinferenspipelinen implementerer den nye modelversion til et SageMaker-slutpunkt i DEV.

Efter implementeringen af ​​slutpunktet startes tests for at kontrollere opsætningens adfærd. Til test bruger Yara CodeBuild testrapporter. Denne funktion giver udviklere mulighed for at køre enhedstests, konfigurationstests og funktionelle tests før og efter implementering. I dette tilfælde kører Yara funktionelle tests ved at sende testnyttelaster til SageMaker-slutpunkter og evaluere svaret. Når disse tests er bestået, fortsætter pipelinen med at implementere SageMaker-endepunkterne til TEST. ELC-backend er også implementeret til TEST, hvilket gør end-to-end test af appen mulig i dette miljø. Derudover kører Yara brugeraccepttest i TEST. Udløseren fra TEST til PROD-implementering er en manuel godkendelseshandling. Efter at den nye modelversion har bestået både funktions- og brugeraccepttest i TEST, godkender ingeniørteamet modelimplementeringen til PROD.

Følgende figur illustrerer denne arbejdsgang.

Almindelige komponenter

Til ELC bruger vi flere komponenter, der er fælles for alle implementeringsstadier (DEV, TEST, PROD) og modeller. Disse komponenter findes i vores implementeringskonto og inkluderer modelversionskontrol, et containerimage-lager, en krypteringsnøgle og en bøtte til at gemme almindelige artefakter.

Der er flere fordele ved at bruge almindelige artefakter. For eksempel skal ressourcerne ikke oprettes for hver konto, hvilket håndhæver kompatibilitet mellem konti. Det betyder, at vi bygger containerbilleder én gang og genbruger dem på alle målkonti, hvilket reducerer byggetiden.

Denne pipeline gemmer de forskellige modelversioner i en fælles modelregistrering i implementeringskontoen. Fra denne centrale placering kan modeller implementeres på alle konti uden at overføre dem. På samme måde gør brugen af ​​en centralt lagret krypteringsnøgle det nemmere at administrere nøglen og tilladelser på tværs af konti.

En ulempe ved at bruge almindelige artefakter er, at onboarding-trinnet i en ny use case kan blive mere kompliceret. For at indsætte en ny use case skal der oprettes et nyt modelregister og om nødvendigt et nyt containerimage-lager. Vi anbefaler også at oprette en ny krypteringsnøgle for strengt at adskille ressourcer og lagrede data.

Konklusion

I dette indlæg demonstrerede vi, hvordan Yara brugte SageMaker og ADF til at bygge en meget skalerbar MLOps-platform. ML er en tværgående funktion, og teams implementerer modeller til forskellige forretningsenhedskonti. Derfor gør ADF, som tilbyder native integration med Organisationer, det til en ideel kandidat til at bootstrap konti til at opsætte CI/CD pipelines. Operationelt kører ADF-pipelines i den centrale implementeringskonto, hvilket gør det nemt at få et overordnet sundhedsoverblik over implementeringer. Endelig bruger ADF AWS-administrerede tjenester som CodeBuild, CodeDeploy, CodePipeline og CloudFormation, hvilket gør det nemt at konfigurere og vedligeholde.

SageMaker leverer et bredt spektrum af ML-kapaciteter, som gør det muligt for teams at fokusere mere på at løse forretningsproblemer og mindre på at bygge og vedligeholde infrastruktur. Derudover giver SageMaker Pipelines et rigt sæt API'er til at oprette, opdatere og implementere ML-arbejdsgange, hvilket gør det til et godt egnet til MLOps.

Endelig giver MLOps den bedste praksis til at implementere og vedligeholde ML-modeller i produktionen pålideligt og effektivt. Det er afgørende for teams, der skaber og implementerer ML-løsninger i stor skala, at implementere MLOps. I Yaras tilfælde reducerer MLOps markant den indsats, der kræves for at indbygge en ny fabrik, udrulle opdateringer til ELC og sikre, at modellerne overvåges for kvalitet.

For mere information om, hvordan du implementerer programmer ved hjælp af ADF, se eksempler.

---

Om forfatterne

Shaheer Mansoor er Data Scientist hos AWS. Hans fokus er på at bygge maskinlæringsplatforme, der kan hoste AI-løsninger i stor skala. Hans interesseområder er MLOps, featurebutikker, modelhosting og modelovervågning.

Tim Becker er Senior Data Scientist hos Yara International. Inden for Digital Produktion er hans fokus på procesoptimering af ammoniak- og salpetersyreproduktion. Han har en ph.d. i termodynamik og brænder for at bringe procesteknik og maskinlæring sammen.

Yongyos Kaewpitakkun er senior dataforsker i Digital Production-teamet hos Yara International. Han har en ph.d. i AI/machine learning og mange års praktisk erfaring med at udnytte maskinlæring, computervision og modeller for behandling af naturlige sprog til at løse udfordrende forretningsproblemer.