Dette blogindlæg er medforfattet af Guillermo Ribeiro, Sr. Data Scientist hos Cepsa.
Machine learning (ML) har hurtigt udviklet sig fra at være en fashionabel trend, der dukker op fra akademiske miljøer og innovationsafdelinger, til at blive et nøglemiddel til at levere værdi på tværs af virksomheder i alle brancher. Denne overgang fra eksperimenter i laboratorier til løsning af problemer i den virkelige verden i produktionsmiljøer går hånd i hånd med MLOps, eller tilpasningen af DevOps til ML-verdenen.
MLOps hjælper med at strømline og automatisere den fulde livscyklus for en ML-model, idet den sætter fokus på kildedatasættene, eksperimentets reproducerbarhed, ML-algoritmekode og modelkvalitet.
At Cepsa, et globalt energiselskab, bruger vi ML til at tackle komplekse problemer på tværs af vores brancher, fra at udføre forudsigelig vedligeholdelse af industrielt udstyr til overvågning og forbedring af petrokemiske processer på vores raffinaderier.
I dette indlæg diskuterer vi, hvordan vi byggede vores referencearkitektur til MLOps ved hjælp af følgende vigtige AWS-tjenester:
- Amazon SageMaker, en tjeneste til at bygge, træne og implementere ML-modeller
- AWS-trinfunktioner, en serverløs lav-kode visuel workflow-tjeneste, der bruges til at orkestrere og automatisere processer
- Amazon Eventbridge, en serverløs begivenhedsbus
- AWS Lambda, en serverløs computertjeneste, der giver dig mulighed for at køre kode uden at klargøre eller administrere servere
Vi forklarer også, hvordan vi anvendte denne referencearkitektur til at starte nye ML-projekter i vores virksomhed.
Udfordringen
I løbet af de sidste 4 år har flere brancher på tværs af Cepsa sat gang i ML-projekter, men snart begyndte visse problemer og begrænsninger at opstå.
Vi havde ikke en referencearkitektur til ML, så hvert projekt fulgte en anden implementeringsvej, der udførte ad hoc modeltræning og implementering. Uden en fælles metode til at håndtere projektkode og parametre og uden et ML-modelregistrering eller versioneringssystem mistede vi sporbarheden mellem datasæt, kode og modeller.
Vi opdagede også plads til forbedringer i den måde, vi drev modeller på i produktionen, fordi vi ikke overvågede installerede modeller og derfor ikke havde midlerne til at spore modellens ydeevne. Som en konsekvens heraf omskolede vi normalt modeller baseret på tidsplaner, fordi vi manglede de rigtige målinger til at træffe informerede omskolingsbeslutninger.
løsningen
Med udgangspunkt i de udfordringer, vi skulle overvinde, designede vi en generel løsning, der havde til formål at afkoble dataforberedelse, modeltræning, inferens og modelovervågning, og indeholdt et centraliseret modelregister. På denne måde forenklede vi administrationen af miljøer på tværs af flere AWS-konti, samtidig med at vi introducerede centraliseret modelsporbarhed.
Vores data scientists og udviklere bruger AWS Cloud9 (en cloud IDE til at skrive, køre og fejlfinde kode) til datastrid og ML-eksperimentering og GitHub som Git-kodelageret.
En automatisk træningsworkflow bruger den kode, som datavidenskabsteamet har bygget til tog modeller på SageMaker og at registrere outputmodeller i modelregistret.
En anden arbejdsgang administrerer modelimplementering: den henter referencen fra modelregistret og opretter et slutningsendepunkt ved hjælp af SageMaker model hosting funktioner.
Vi implementerede både modeltrænings- og implementeringsarbejdsgange ved hjælp af Step Functions, fordi det gav en fleksibel ramme, der muliggør oprettelse af specifikke arbejdsgange for hvert projekt og orkestrerer forskellige AWS-tjenester og -komponenter på en ligetil måde.
Dataforbrugsmodel
I Cepsa bruger vi en række datasøer til at dække forskellige forretningsbehov, og alle disse datasøer deler en fælles dataforbrugsmodel, der gør det nemmere for dataingeniører og dataforskere at finde og forbruge de data, de har brug for.
For nemt at håndtere omkostninger og ansvar er datasømiljøer fuldstændig adskilt fra dataproducent- og forbrugerapplikationer og implementeret i forskellige AWS-konti, der tilhører en fælles AWS-organisation.
De data, der bruges til at træne ML-modeller og de data, der bruges som slutningsinput for trænede modeller, stilles til rådighed fra de forskellige datasøer gennem et sæt veldefinerede API'er ved hjælp af Amazon API Gateway, en tjeneste til at oprette, udgive, vedligeholde, overvåge og sikre API'er i stor skala. API-backend bruger Amazonas Athena (en interaktiv forespørgselstjeneste til at analysere data ved hjælp af standard SQL) for at få adgang til data, der allerede er gemt i Amazon Simple Storage Service (Amazon S3) og katalogiseret i AWS Lim Datakatalog.
Følgende diagram giver et generelt overblik over Cepsas MLOps-arkitektur.
Model træning
Uddannelsesprocessen er uafhængig for hver model og varetages af en Trin Funktioner standard arbejdsgang, hvilket giver os fleksibilitet til at modellere processer ud fra forskellige projektkrav. Vi har en defineret basisskabelon, som vi genbruger på de fleste projekter, og udfører mindre justeringer, når det er nødvendigt. For eksempel har nogle projektejere besluttet at tilføje manuelle porte for at godkende implementeringer af nye produktionsmodeller, mens andre projektejere har implementeret deres egne fejlfindings- og genforsøgsmekanismer.
Vi udfører også transformationer på de inputdatasæt, der bruges til modeltræning. Til dette formål bruger vi Lambda-funktioner, der er integreret i træningsarbejdsgangene. I nogle scenarier, hvor der kræves mere komplekse datatransformationer, kører vi vores kode ind Amazon Elastic Container Service (Amazon ECS) på AWS Fargate, en serverløs computer til at køre containere.
Vores datavidenskabsteam bruger ofte tilpassede algoritmer, så vi udnytter muligheden for at bruge tilpassede beholdere i SageMaker modeltræning, stole på Amazon Elastic Container Registry (Amazon ECR), et fuldt administreret containerregister, der gør det nemt at gemme, administrere, dele og implementere containerbilleder.
De fleste af vores ML-projekter er baseret på Scikit-learn-biblioteket, så vi har udvidet standarden SageMaker Scikit-learn container at inkludere de miljøvariabler, der kræves til projektet, såsom Git-lageroplysninger og implementeringsmuligheder.
Med denne tilgang skal vores dataforskere blot fokusere på at udvikle træningsalgoritmen og specificere de biblioteker, som projektet kræver. Når de skubber kodeændringer til Git-lageret, vil vores CI/CD-system (Jenkins hostet på AWS) bygger containeren med træningskoden og bibliotekerne. Denne beholder skubbes til Amazon ECR og videregives til sidst som en parameter til SageMaker-uddannelsen.
Når træningsprocessen er afsluttet, gemmes den resulterende model i Amazon S3, en reference tilføjes i modelregistret, og alle indsamlede oplysninger og målinger gemmes i forsøgskataloget. Dette sikrer fuld reproducerbarhed, fordi algoritmekoden og bibliotekerne er knyttet til den trænede model sammen med de data, der er knyttet til eksperimentet.
Følgende diagram illustrerer modeltrænings- og omskolingsprocessen.
Modelimplementering
Arkitekturen er fleksibel og tillader både automatiske og manuelle udrulninger af de trænede modeller. Modeldeployer-workflowet aktiveres automatisk ved hjælp af en hændelse, som SageMaker-uddannelsen udgiver i EventBridge, efter træningen er afsluttet, men den kan også aktiveres manuelt, hvis det er nødvendigt, ved at sende den rigtige modelversion fra modelregistret. For mere information om automatisk opkald, se Automatisering af Amazon SageMaker med Amazon EventBridge.
Modeldeployerens arbejdsgang henter modeloplysningerne fra modelregistret og bruger dem AWS CloudFormation, en administreret infrastruktur som kodetjeneste, til enten at implementere modellen til et slutpunkt i realtid eller udføre batch-inferens med et lagret inputdatasæt, afhængigt af projektets krav.
Når en model er succesfuldt implementeret i ethvert miljø, opdateres modelregistret med et nyt tag, der angiver, i hvilke miljøer modellen kører i øjeblikket. Hver gang et slutpunkt fjernes, slettes dets tag også fra modelregistret.
Følgende diagram viser arbejdsgangen for modelimplementering og inferens.
Eksperimenter og modelregistrering
Lagring af hvert eksperiment og modelversion på et enkelt sted og at have et centraliseret kodelager gør det muligt for os at afkoble modeltræning og implementering og bruge forskellige AWS-konti til hvert projekt og hvert miljø.
Alle eksperimentposter gemmer commit-id'et for trænings- og inferenskoden, så vi har fuldstændig sporbarhed af hele eksperimenteringsprocessen og er i stand til nemt at sammenligne forskellige eksperimenter. Dette forhindrer os i at udføre dobbeltarbejde på den videnskabelige udforskningsfase for algoritmer og modeller, og gør os i stand til at implementere vores modeller hvor som helst, uafhængigt af den konto og det miljø, hvor modellen blev trænet. Dette gælder også for modeller, der er trænet i vores AWS Cloud9-eksperimenteringsmiljø.
Alt i alt har vi fuldt automatiserede modeltrænings- og implementeringspipelines og har fleksibiliteten til at udføre hurtige manuelle modelimplementeringer, når noget ikke fungerer korrekt, eller når et team har brug for en model, der er implementeret til et andet miljø til eksperimenterende formål.
En detaljeret use case: YET Dragon-projektet
YET Dragon-projektet har til formål at forbedre produktionsydelsen på Cepsas petrokemiske fabrik i Shanghai. For at nå dette mål studerede vi produktionsprocessen grundigt og ledte efter de mindre effektive trin. Vores mål var at øge udbytteeffektiviteten af processerne ved at holde komponentkoncentrationen nøjagtigt under en tærskel.
For at simulere denne proces byggede vi fire generaliserede additivmodeller eller GAM, lineære modeller, hvis respons afhænger af glatte funktioner af prædiktorvariabler, for at forudsige resultaterne af to oxidationsprocesser, en koncentrationsproces og det førnævnte udbytte. Vi byggede også en optimizer til at behandle resultaterne af de fire GAM-modeller og finde de bedste optimeringer, der kunne anvendes i anlægget.
Selvom vores modeller er trænet med historiske data, kan anlægget nogle gange fungere under omstændigheder, der ikke var registreret i træningsdatasættet; vi forventer, at vores simuleringsmodeller ikke vil fungere godt under disse scenarier, så vi byggede også to anomalidetektionsmodeller ved hjælp af Isolation Forests-algoritmer, som bestemmer, hvor langt datapunkter er til resten af dataene for at detektere uregelmæssighederne. Disse modeller hjælper os med at opdage sådanne situationer for at deaktivere de automatiserede optimeringsprocesser, når dette sker.
Industrielle kemiske processer er meget varierende, og ML-modellerne skal være godt tilpasset fabrikkens drift, så hyppig omskoling er påkrævet samt sporbarhed af de modeller, der er indsat i hver situation. YET Dragon var vores første ML-optimeringsprojekt med et modelregister, fuld reproducerbarhed af eksperimenterne og en fuldt styret automatiseret træningsproces.
Nu er den komplette pipeline, der bringer en model i produktion (datatransformation, modeltræning, eksperimentsporing, modelregistrering og modelimplementering), uafhængig for hver ML-model. Dette gør det muligt for os at forbedre modeller iterativt (for eksempel tilføje nye variabler eller teste nye algoritmer) og forbinde trænings- og implementeringsstadierne til forskellige triggere.
Resultaterne og fremtidige forbedringer
Vi er i øjeblikket i stand til automatisk at træne, implementere og spore de seks ML-modeller, der bruges i YET Dragon-projektet, og vi har allerede implementeret over 30 versioner for hver af produktionsmodellerne. Denne MLOps-arkitektur er blevet udvidet til hundredvis af ML-modeller i andre projekter på tværs af virksomheden.
Vi planlægger at fortsætte med at lancere nye YET-projekter baseret på denne arkitektur, som har reduceret projektets gennemsnitlige varighed med 25 %, takket være reduktionen af bootstrapping-tiden og automatiseringen af ML-pipelines. Vi har også estimeret besparelser på omkring €300,000 om året takket være stigningen i udbytte og koncentration, som er et direkte resultat af YET Dragon-projektet.
Den kortsigtede udvikling af denne MLOps-arkitektur går i retning af modelovervågning og automatiseret test. Vi planlægger automatisk at teste modeleffektivitet i forhold til tidligere implementerede modeller, før en ny model implementeres. Vi arbejder også med implementeringen af modelovervågning og overvågning af inferensdatadrift med Amazon SageMaker Model Monitor, for at automatisere modelomskoling.
Konklusion
Virksomheder står over for udfordringen med at bringe deres ML-projekter i produktion på en automatiseret og effektiv måde. Automatisering af hele ML-modellens livscyklus hjælper med at reducere projekttiden og sikrer bedre modelkvalitet og hurtigere og hyppigere implementeringer til produktionen.
Ved at udvikle en standardiseret MLOps-arkitektur, som er blevet vedtaget af forskellige virksomheder på tværs af virksomheden, var vi hos Cepsa i stand til at fremskynde opstart af ML-projekter og forbedre kvaliteten af ML-modeller, hvilket giver en pålidelig og automatiseret ramme, hvorpå vores datavidenskabsteams kan innovere hurtigere .
For mere information om MLOps på SageMaker, besøg Amazon SageMaker til MLOps og tjek andre kundetilfælde i AWS Machine Learning Blog.
Om forfatterne
Guillermo Ribeiro Jiménez er Sr Data Scientist ved Cepsa med en ph.d. i kernefysik. Han har 6 års erfaring med datavidenskabelige projekter, hovedsageligt i tele- og energibranchen. Han leder i øjeblikket dataforskerteams i Cepsas Digital Transformation-afdeling med fokus på skalering og produktisering af maskinlæringsprojekter.
Guillermo Menéndez Corral er Solutions Architect hos AWS Energy and Utilities. Han har over 15 års erfaring med at designe og bygge SW-applikationer og yder i øjeblikket arkitektonisk vejledning til AWS-kunder i energiindustrien med fokus på analyse og maskinlæring.
- Coinsmart. Europas bedste Bitcoin og Crypto Exchange.
- Platoblokkæde. Web3 Metaverse Intelligence. Viden forstærket. FRI ADGANG.
- CryptoHawk. Altcoin radar. Gratis prøveversion.
- Kilde: https://aws.amazon.com/blogs/machine-learning/how-cepsa-used-amazon-sagemaker-and-aws-step-functions-to-industrialize-their-ml-projects-and-operate- deres-modeller-i-skala/
- "
- 000
- 100
- 15 år
- a
- evne
- Om
- adgang
- Konto
- opnå
- tværs
- Ad
- tilføjet
- Fordel
- mod
- algoritme
- algoritmer
- Alle
- tillader
- allerede
- Amazon
- blandt
- analytics
- analysere
- overalt
- api
- API'er
- applikationer
- anvendt
- tilgang
- Godkend
- arkitektonisk
- arkitektur
- omkring
- forbundet
- automatisere
- Automatiseret
- Automatisk Ur
- automatisk
- Automatisering
- Automation
- til rådighed
- AWS
- fordi
- blive
- før
- være
- jf. nedenstående
- BEDSTE
- Blog
- bygge
- Bygning
- bygger
- virksomhed
- virksomheder
- tilfælde
- tilfælde
- centraliseret
- vis
- udfordre
- udfordringer
- kemikalie
- Cloud
- kode
- begå
- Fælles
- selskab
- fuldføre
- fuldstændig
- komplekse
- komponent
- komponenter
- Compute
- koncentration
- Tilslut
- forbruge
- forbruger
- forbrug
- Container
- Beholdere
- Omkostninger
- kunne
- dæksel
- skabe
- skaber
- skabelse
- For øjeblikket
- skik
- kunde
- Kunder
- data
- datalogi
- dataforsker
- besluttede
- afgørelser
- Afhængigt
- afhænger
- indsætte
- indsat
- implementering
- implementeringer
- konstrueret
- designe
- detaljeret
- opdaget
- Detektion
- Bestem
- udviklere
- udvikling
- forskellige
- digital
- Digital Transformation
- direkte
- diskutere
- Drage
- hver
- nemt
- effektivitet
- effektiv
- smergel
- muliggør
- Endpoint
- energi
- Engine (Motor)
- Ingeniører
- Miljø
- udstyr
- anslået
- begivenhed
- evolution
- præcist nok
- eksempel
- forvente
- erfaring
- eksperiment
- udforskning
- vender
- FAST
- hurtigere
- Feature
- featured
- Endelig
- Fornavn
- Fleksibilitet
- fleksibel
- Fokus
- efter
- Framework
- fra
- fuld
- funktioner
- fremtiden
- Gates
- Generelt
- Git
- GitHub
- Global
- mål
- håndtere
- have
- hjælpe
- hjælper
- stærkt
- historisk
- besidder
- hostede
- Hosting
- Hvordan
- HTTPS
- Hundreder
- billeder
- implementering
- implementeret
- Forbedre
- forbedring
- I andre
- omfatter
- Forøg
- uafhængig
- uafhængigt
- industrielle
- industrien
- oplysninger
- informeret
- Infrastruktur
- Innovation
- indgang
- integreret
- interaktiv
- indføre
- isolation
- spørgsmål
- IT
- Holde
- holde
- Nøgle
- lancering
- førende
- læring
- Bibliotek
- linjer
- placering
- leder
- maskine
- machine learning
- lavet
- vedligeholde
- vedligeholdelse
- lave
- maerker
- administrere
- lykkedes
- styring
- måde
- manuel
- manuelt
- midler
- Metrics
- ML
- model
- modeller
- Overvåg
- overvågning
- mere
- mest
- flere
- behov
- betjene
- drift
- optimering
- Indstillinger
- ordrer
- organisation
- Andet
- egen
- ejere
- Passing
- ydeevne
- udfører
- fase
- Fysik
- punkter
- forudsige
- problemer
- behandle
- Processer
- producent
- produktion
- projekt
- projekter
- forudsat
- giver
- leverer
- offentliggøre
- formål
- formål
- skubbet
- kvalitet
- realtid
- reducere
- register
- registreret
- pålidelig
- Repository
- påkrævet
- Krav
- svar
- ansvar
- REST
- resulterer
- Resultater
- Kør
- kører
- Scale
- skalering
- Videnskab
- Videnskabsmand
- forskere
- sikker
- Series
- Serverless
- tjeneste
- Tjenester
- sæt
- Shanghai
- Del
- kort sigt
- Simpelt
- simulation
- enkelt
- Situationen
- SIX
- So
- løsninger
- Løsninger
- nogle
- noget
- specifikke
- hastighed
- etaper
- standard
- påbegyndt
- opbevaring
- butik
- strømline
- Succesfuld
- systemet
- mål
- hold
- hold
- Telco
- prøve
- Test
- The Source
- derfor
- grundigt
- tærskel
- Gennem
- tid
- gange
- mod
- Sporbarhed
- spor
- Sporing
- Kurser
- Transformation
- transformationer
- overgang
- under
- us
- brug
- sædvanligvis
- forsyningsselskaber
- værdi
- udgave
- veldefinerede
- mens
- uden
- Arbejde
- arbejdsgange
- arbejder
- world
- skrivning
- år
- år
- Udbytte