Hur Yara använder MLOps-funktioner i Amazon SageMaker för att skala energioptimering över sina ammoniakfabriker

Yara är världens ledande växtnäringsföretag och en leverantör av miljö- och jordbrukslösningar. Yaras ambition är fokuserad på att utveckla en naturpositiv matframtid som skapar värde för kunder, aktieägare och samhället i stort, och levererar en mer hållbar livsmedelsvärdekedja. För att stödja vår vision om en värld utan hunger och en respekterad planet, följer Yara en strategi för hållbar värdetillväxt, främjande av klimatvänlig växtnäring och energilösningar med nollutsläpp. Yara är också världens största producent av ammoniak, nitrater och NPK gödningsmedel. Deras produktionssegment är därför en integrerad byggsten för att leverera på sitt uppdrag – med en tydligt uttalad ambition att bli världsledande på mätvärden som säkerhet, miljöpåverkan, kvalitet och produktionskostnader. Yaras långsiktiga mål är ”Framtidens anläggning” med nollutsläpp och låga kostnader.

Med utgångspunkt i en lean transformation ökar Yara sitt fokus på digitala lösningar för att hjälpa dem att uppnå sina ambitioner. För att leda detta arbete etablerade Yara en global enhet kallad Digital Production. Framgången för Digital Production och dess lösningar är en nyckelprioritet för Yara, och Yara ökade avsevärt sina ansträngningar inom detta område. Ett kritiskt fokusområde är att dra fördel av den stora mängd data som genereras som en del av deras verksamhet. Därför bygger Yara datadrivna produkter som hjälper dem att optimera produktionen, öka kvaliteten på produkterna, öka tillförlitligheten på produktionsplatserna, minska utsläppen, öka säkerheten och produktiviteten för arbetare, automatisera manuella processer med mera.

Energi är en viktig kostnadskomponent för många produktionsanläggningar; därför har energieffektivitet en betydande inverkan på lönsamheten. Det saknas dock ofta solida referenser för hur bra prestanda ser ut och hur man tar sig dit. Yaras energibelastningskurva (ELC) är en lösning som använder den bästa historiska prestanda för energiförbrukning som hålls upp mot nuvarande prestanda. Om den aktuella förbrukningen avviker för mycket från den historiskt bästa ger verktyget rekommendationer till operatörerna för att styra energiförbrukningen.

För att distribuera ELC till produktionsanläggningar och skala den till flera platser över hela världen behövde Yara bygga en MLOps-plattform. Detta skulle säkerställa att Yara skulle träna, distribuera och underhålla modeller på ett tillförlitligt och effektivt sätt. För att skala detta till flera platser behövde Yara dessutom automatisera driftsättnings- och underhållsprocesserna. I det här inlägget diskuterar vi hur Yara använder Amazon SageMaker funktioner, inklusive modellregistret, Amazon SageMaker modellmonitoroch Amazon SageMaker-rörledningar att effektivisera livscykeln för maskininlärning (ML) genom att automatisera och standardisera MLOps-praxis. Vi ger en översikt över installationen och visar upp processen att bygga, träna, distribuera och övervaka ML-modeller för anläggningar runt om i världen.

Översikt över lösningen

ELC använder Internet of Things (IoT) sensordata från en anläggning. Dessa sensorer mäter mätvärden som produktionsgenomströmning, omgivningsförhållanden och råmaterialförhållanden, etc. Dessa data används för att träna en energiförutsägelsemodell som sedan används för att generera förutsägelser per timme. Anläggningsoperatörer övervakar den faktiska energiförbrukningen och jämför den med den optimala förbrukningen som förutspåtts av ELC. Om den nuvarande energiförbrukningen avviker för mycket från den optimala punkten tillhandahåller ELC en åtgärd för att justera interna processvariabler för att optimera energieffektiviteten baserat på analytiska modeller.

ELC är värd i molnet. För att strömma sensordata från en anläggning i realtid använder Yara AWS IoT Greengrass att kommunicera säkert med AWS IoT Core och exportera IoT-data till AWS-molnet. AWS IoT SiteWise är en hanterad tjänst som kan samla in, organisera, söka och konsumera utrustningsdata från industriell utrustning i stor skala. Yara har byggt API:er med hjälp av Amazon API Gateway för att exponera sensordata för applikationer som ELC.

ELC-applikationens backend distribueras via Amazon ECS och driver ELC-instrumentpaneler på fronten som används av anläggningsoperatörer. ELC-applikationen är ansvarig för att tillhandahålla prognoser för energiförbrukning per timme till anläggningsoperatörer. Varje anläggning är utrustad med sin egen modell, eftersom deras energiförbrukningsegenskaper skiljer sig åt. Dessutom är växter grupperade i olika AWS-regioner baserat på deras plats.

Följande diagram illustrerar denna arkitektur.

För att bygga ELC och skala till flera anläggningar behövde vi en MLOps-lösning som stöder följande:

• skalbarhet – Det kan skalas som svar på datavolymer. Vissa anläggningar producerar mer data än andra; varje anläggning kan producera flera gigabyte data per dag.
• Förlängbarhet – Det kan distribueras till nya regioner och konton.
• Repeterbarhet – Den har gemensamma mallar som vi kan använda för att omborda en ny anläggning.
• Flexibilitet – Den kan ändra driftsättningskonfigurationen baserat på varje anläggnings behov.
• Tillförlitlighet och övervakning – Den kan köra tester och ha en tydlig insyn i statusen för alla aktiva anläggningar. I händelse av fel kan den rulla tillbaka till det tidigare stabila tillståndet.
• Underhåll – Lösningen bör ha låga underhållskostnader. Den bör använda serverlösa tjänster där det är möjligt för att minska infrastrukturens fotavtryck.

För ML beslutade Yara att använda SageMaker. SageMaker är en fullt hanterad tjänst som täcker hela ML-arbetsflödet. Följande funktioner var avgörande för valet av SageMaker:

• SageMaker ramverksbehållare – Yara hade tränat ELC-prediktiva modeller på TensorFlow, och med SageMaker ramverkscontainrar kunde Yara lyfta och flytta dessa modeller med minimala kodändringar till SageMaker.
• SageMaker-rörledningar – SageMaker Pipelines erbjuder ett Python-gränssnitt för datavetare att skriva ML-pipelines. En stor del av ELC-koden består av en tränings- och en slutledningspipeline, som definieras i Python.
• SageMaker-modellregister – SageMakers modellregister gör det möjligt att katalogisera och versionskontrollera modeller. Dessutom gör det det enkelt att hantera modellmetadata, såsom träningsmått.
• SageMaker modellmonitor – Yara ville övervaka kvaliteten och distributionen av inkommande data samt ELC-modellens prestanda. SageMaker Model Monitor API:er erbjuder data- och modellkvalitetsövervakning.

För att hantera den kontinuerliga integrationen och kontinuerliga leveransen (CI/CD) för ML-pipelines använder Yara Amazon Deployment Framework (ADF). ADF är ett ramverk med öppen källkod utvecklat av AWS för att hantera och distribuera resurser över flera AWS-konton och regioner inom en AWS-organisation. ADF tillåter stegvisa, parallella, multikonton och regionöverskridande distributioner av applikationer eller resurser via strukturen som definieras i AWS-organisationer, samtidigt som du drar nytta av tjänster som t.ex AWS CodePipeline, AWS CodeBuild, AWS CodeCommitoch AWS molnformation för att lindra de tunga lyften och hanteringen jämfört med en traditionell CI/CD-uppsättning.

Lösningsöversikt

Hela lösningen för MLOps-plattformen byggdes inom två månader i ett samarbete med AWS professionella tjänster. Teamet som arbetade med projektet bestod av datavetare, dataingenjörer och DevOps-specialister. För att underlätta snabbare utveckling i en miljö med flera team valde Yara att använda AWS Landing Zone och organisationer för att centralt skapa, hantera och styra olika AWS-konton. Yara har till exempel ett centralt distributionskonto och använder arbetsbelastningskonton för att vara värd för affärsapplikationer. ELC är ett användningsfall för processoptimering och används för att optimera arbetsbelastningskonton. Yara Digital Production-teamet arbetar också med ML-användningsfall inom andra områden än optimering. MLOps-ramverket stöder distribution till alla arbetsbelastningskonton så länge kontona skapas via organisationer.

Följande diagram illustrerar denna arkitektur.

Att använda ett centralt distributionskonto gör det enkelt att hantera vanliga artefakter och CI/CD-pipelines. När det gäller åtkomsthantering och säkerhet för dessa vanliga artefakter är det en enklare design eftersom behörighetsgränser och krypteringsnycklar hanteras centralt på ett ställe. I följande avsnitt leder vi dig genom stegen som krävs för att ta med ett nytt användningsfall till Yaras MLOps-plattform.

När det gäller kontostrategi har Yara en sandlåda, DEV, TEST och PROD-inställning. Sandlådekontot används för att experimentera och prova nya idéer. DEV-kontot är startpunkten för CI/CD-pipelines, och all utveckling börjar här. Distributionskontot innehåller CI/CD-pipelinedefinitionen och kan distribueras till DEV-, TEST- och PROD-kontona. Denna kontoinställning visas i följande figur.

Inleder ett nytt användningsfall

För det här inlägget antar vi att vi har en fungerande prototyp av ett användningsfall, och nu vill vi operationalisera det. Om det här användningsfallet tillhör ett nytt produktområde måste vi först tillhandahålla kontona med hjälp av Organisationer, vilket automatiskt utlöser ADF för att starta upp dessa konton för distribution. Yara följer en DEV>TEST>PROD-kontostrategi; denna konfiguration är dock inte obligatorisk. Datakonton exponerar API:er för dataåtkomst, och för ett nytt användningsfall måste roller tilldelas de nödvändiga AWS identitets- och åtkomsthantering (IAM)-behörigheter så att de kan komma åt data-API:erna.

Därefter måste vi definiera vilka konton detta användningsfall ska distribueras till. Detta görs med hjälp av en distributionskarta i ADF. Utbyggnadskartan är en konfigurationsfil som innehåller kartläggningen av etapper och mål för pipelinen. För att köra distributionskartan använder ADF CodePipeline. ADF ger flexibiliteten att hantera parametrar per målmiljö som stacken distribueras till. Detta gör det enkelt att hantera distributioner och testa med mindre instanser.

För att kryptera alla artefakter, såsom kod, data och modellfiler, genererar vi en AWS nyckelhanteringstjänst (AWS KMS)-tangent. Du kan också använda kryptering på serversidan. Men eftersom vissa av de genererade artefakterna nås över konton måste vi generera vår egen nyckel och hantera dess behörighetspolicyer för att ge åtkomst över flera konton.

Slutligen måste vi skapa en modellpaketgrupp för att gruppera olika versioner av en modell med hjälp av SageMaker-modellregistret, vilket är SageMakers förmåga att spåra och hantera modeller när de rör sig genom ML-livscykeln.

Modell utbildning pipeline

För varje ny anläggning ombord för ELC skapar vi en ny SageMaker-utbildningspipeline. Denna pipeline består av dataförbehandling och modellutbildningssteg. SageMaker-pipelines passar Yara bra eftersom de erbjuder ett Python-gränssnitt för att definiera ett ML-arbetsflöde. Dessutom kan olika steg i arbetsflödet konfigureras för att skala olika. Du kan till exempel definiera en mycket större instans för utbildning än för modellutvärderingssteget. In- och utgångsparametrar för varje steg i pipelinen lagras, vilket gör det enkelt att spåra varje körning och dess utgångar. Översikten över utbildningsarbetsflödet på hög nivå är följande.

Som en del av modellutvärderingsstadiet används en utvärderingsdatauppsättning för att generera mätvärden, såsom noggrannhet och RMSE-avvikelse (root-mean-squared error) på den tränade modellen. Dessa mätvärden läggs till i modellens metadata innan modellen registreras i modellregistret. För närvarande marknadsförs modeller manuellt till högre miljöer, och modellgodkännaren kan se modellmåtten för att säkerställa att den nya versionen presterar bättre än den nuvarande modellen.

Modellerna är versionskontrollerade med modellregistret, där varje anläggning har sin egen modellpaketgrupp. Dessutom kan du använda modellregistret för att spåra vilka modellversioner som distribueras till vilka miljöer. En modell kan vara i en Förkastas, Väntar på manuellt godkännande, eller Godkänd stat, och endast modeller som finns i Godkänd staten kan sättas in. Detta ger också skydd mot att oavsiktligt använda en icke-godkänd version av modellen.

Modell inferens och övervakning pipeline

För att distribuera modellen och ställa in modellövervakning satte vi upp en andra SageMaker-pipeline. ELC-applikationen ger anläggningsoperatörer förutsägelser på begäran, därför nås modellerna via API-anrop från ELC-backend. SageMaker slutpunkter ger en helt hanterad modell värdlösning med ett API-lager; endpoints tar modellindata som nyttolast och returförutsägelser. Eftersom latens också är en avgörande faktor för slutanvändare som inte vill vänta länge innan de får uppdaterade förutsägelser, valde Yara SageMaker realtids slutpunkter för slutpunkter, som är särskilt lämpliga för arbetsbelastningar med mycket låga latenskrav. Slutligen, eftersom ELC-applikationen inte kan ha driftstopp medan uppdaterade modeller distribueras, förlitar den sig på den blå/gröna distributionsförmågan hos SageMaker realtidsslutpunkter för att säkerställa att den gamla modellversionen fortsätter att tjäna förutsägelser tills den nya versionen distribueras .

Följande diagram illustrerar installationen och övervakningsinställningarna.

För modellövervakning driver Yara SageMaker Datakvalitet, modellkvalitetoch modellförklarbarhet övervakning. Uppföljningen av datakvalitet kontrollerar konsistens och genererar statistik över datadistribution. Modellkvalitetsövervakning kontrollerar modellens prestanda och jämför modellens noggrannhet med träningsmåtten. Modellövervakningsrapporter genereras på timbasis. Dessa rapporter används för att övervaka modellprestanda i produktionen. Modellförklaringsövervakning används för att förstå vilka egenskaper som bidrar mest till en förutsägelse.

Dessa resultat av modellförklaring delas på ELC-instrumentpanelen för att ge anläggningsoperatörer mer sammanhang om vad som driver energiförbrukningen. Detta stöder också bestämning av åtgärden för att justera den interna processen om energiförbrukningen avviker från den optimala punkten.

CI/CD-flöde

CI/CD-flödet för utbildningspipelines börjar i DEV-kontot. Yara följer en funktionsbaserad utvecklingsmodell och när en ny funktion utvecklas slås funktionsgrenen samman i trunk, vilket startar distributionen. ELC-modeller tränas i DEV-kontot och efter att modellen har tränats och utvärderats, registreras den i modellregistret. En modellgodkännare utför förnuftskontroller innan modellstatusen uppdateras till Godkänd. Denna åtgärd genererar en händelse som utlöser distributionen av modellinferenspipeline. Modellinferenspipelinen distribuerar den nya modellversionen till en SageMaker-slutpunkt i DEV.

Efter implementeringen av slutpunkten startas tester för att kontrollera installationens beteende. För testning använder Yara CodeBuild testrapporter. Den här funktionen låter utvecklare köra enhetstester, konfigurationstester och funktionstester före och efter driftsättning. I det här fallet kör Yara funktionstester genom att skicka testnyttolaster till SageMaker-slutpunkter och utvärdera svaret. Efter att dessa tester har godkänts fortsätter pipelinen att distribuera SageMaker-ändpunkterna för att TEST. ELC-backend är också utplacerat för TEST, vilket gör end-to-end-testning av appen möjlig i den här miljön. Dessutom kör Yara användaracceptanstestning i TEST. Utlösaren från TEST till PROD-distribution är en manuell godkännandeåtgärd. Efter att den nya modellversionen har klarat både funktions- och användaracceptanstestning i TEST, godkänner ingenjörsteamet modelldistributionen till PROD.

Följande bild illustrerar detta arbetsflöde.

Vanliga komponenter

För ELC använder vi flera komponenter som är gemensamma för alla installationssteg (DEV, TEST, PROD) och modeller. Dessa komponenter finns i vårt distributionskonto och inkluderar modellversionskontroll, ett lagringsutrymme för behållarbilder, en krypteringsnyckel och en hink för att lagra vanliga artefakter.

Det finns flera fördelar med att använda vanliga artefakter. Till exempel behöver resurserna inte skapas för varje konto, vilket tvingar fram kompatibilitet mellan kontona. Det innebär att vi bygger behållarbilder en gång och återanvänder dem i alla målkonton, vilket minskar byggtiden.

Denna pipeline lagrar de olika modellversionerna i ett gemensamt modellregister i distributionskontot. Från denna centrala plats kan modeller distribueras på alla konton utan att överföra dem. På samma sätt gör användningen av en centralt lagrad krypteringsnyckel det enklare att hantera nyckeln och behörigheter för flera konton.

En nackdel med att använda vanliga artefakter är att introduktionssteget för ett nytt användningsfall kan bli mer komplicerat. För att ta med ett nytt användningsfall måste ett nytt modellregister skapas och vid behov ett nytt arkiv för containeravbildningar. Vi rekommenderar också att du skapar en ny krypteringsnyckel för att strikt separera resurser och lagrad data.

Slutsats

I det här inlägget visade vi hur Yara använde SageMaker och ADF för att bygga en mycket skalbar MLOps-plattform. ML är en tvärfunktionell förmåga och team distribuerar modeller till olika affärsenhetskonton. Därför gör ADF, som erbjuder inbyggd integration med organisationer, det till en idealisk kandidat att starta upp konton för att sätta upp CI/CD-pipelines. Operationellt körs ADF-pipelines i det centrala driftsättningskontot, vilket gör det enkelt att få en övergripande hälsoöversikt över driftsättningar. Slutligen använder ADF AWS-hanterade tjänster som CodeBuild, CodeDeploy, CodePipeline och CloudFormation, vilket gör det enkelt att konfigurera och underhålla.

SageMaker tillhandahåller ett brett spektrum av ML-funktioner, vilket gör det möjligt för team att fokusera mer på att lösa affärsproblem och mindre på att bygga och underhålla infrastruktur. Dessutom tillhandahåller SageMaker Pipelines en rik uppsättning API:er för att skapa, uppdatera och distribuera ML-arbetsflöden, vilket gör det perfekt för MLOps.

Slutligen tillhandahåller MLOps de bästa metoderna för att distribuera och underhålla ML-modeller i produktion på ett tillförlitligt och effektivt sätt. Det är avgörande för team som skapar och distribuerar ML-lösningar i stor skala för att implementera MLOps. I Yaras fall minskar MLOps avsevärt den ansträngning som krävs för att ta ombord en ny anläggning, rulla ut uppdateringar till ELC och säkerställa att modellerna övervakas med avseende på kvalitet.

För mer information om hur du distribuerar applikationer med ADF, se exempel.

---

Om författarna

Shaheer Mansoor är Data Scientist på AWS. Hans fokus ligger på att bygga maskininlärningsplattformar som kan vara värd för AI-lösningar i stor skala. Hans intresseområden är MLOps, featurebutiker, modellvärd och modellövervakning.

Tim Becker är Senior Data Scientist på Yara International. Inom Digital Production ligger hans fokus på processoptimering av ammoniak- och salpetersyraproduktion. Han har en doktorsexamen i termodynamik och brinner för att föra samman processteknik och maskininlärning.

Yongyos Kaewpitakkun är senior dataforskare i Digital Production-teamet på Yara International. Han har en doktorsexamen i AI/maskininlärning och många års praktisk erfarenhet av att utnyttja maskininlärning, datorseende och bearbetningsmodeller för naturligt språk för att lösa utmanande affärsproblem.