Byg en ende-til-ende MLOps-pipeline til visuel kvalitetsinspektion ved kanten – Del 1 | Amazon Web Services

Byg en ende-til-ende MLOps-pipeline til visuel kvalitetsinspektion ved kanten – Del 1 | Amazon Web Services

Tidsstempel: 2. oktober 2023 kl. 12

En vellykket implementering af en maskinlæringsmodel (ML) i et produktionsmiljø er stærkt afhængig af en end-to-end ML-pipeline. Selvom det kan være udfordrende at udvikle en sådan pipeline, bliver det endnu mere komplekst, når man har at gøre med en edge ML use case. Machine learning at the edge er et koncept, der bringer muligheden for at køre ML-modeller lokalt til edge-enheder. For at implementere, overvåge og vedligeholde disse modeller på kanten kræves en robust MLOps-pipeline. En MLOps-pipeline gør det muligt at automatisere hele ML-livscyklussen fra datamærkning til modeltræning og implementering.

Implementering af en MLOps-pipeline på kanten introducerer yderligere kompleksitet, der gør automatiserings-, integrations- og vedligeholdelsesprocesserne mere udfordrende på grund af de øgede operationelle omkostninger. Men ved at bruge specialbyggede tjenester som Amazon SageMaker , AWS IoT Greengrass giver dig mulighed for at reducere denne indsats betydeligt. I denne serie guider vi dig gennem processen med at arkitekture og bygge en integreret end-to-end MLOps-pipeline til en computervision-brugscase på kanten ved hjælp af SageMaker, AWS IoT Greengrass og AWS Cloud Development Kit (AWS CDK).

Dette indlæg fokuserer på at designe den overordnede MLOps pipeline-arkitektur; del 2 , del 3 af denne serie fokus på implementeringen af ​​de enkelte komponenter. Vi har givet et eksempel på implementering i den medfølgende GitHub repository for at du selv kan prøve. Hvis du lige er begyndt med MLOps ved kanten på AWS, se MLOps på kanten med Amazon SageMaker Edge Manager og AWS IoT Greengrass for overblik og referencearkitektur.

Use case: Inspicering af kvaliteten af ​​metalmærker

Som ML-ingeniør er det vigtigt at forstå den business case, du arbejder på. Så før vi dykker ned i MLOps-pipeline-arkitekturen, lad os se på eksemplerne på brugen af ​​dette indlæg. Forestil dig en produktionslinje fra en producent, der graverer metalmærker for at skabe tilpassede bagagemærker. Kvalitetssikringsprocessen er dyr, fordi de rå metalmærker skal inspiceres manuelt for defekter som ridser. For at gøre denne proces mere effektiv bruger vi ML til at opdage defekte tags tidligt i processen. Dette hjælper med at undgå kostbare fejl på senere stadier af produktionsprocessen. Modellen skal identificere mulige defekter som ridser i næsten realtid og markere dem. I produktionsmiljøer skal du ofte håndtere ingen forbindelse eller begrænset båndbredde og øget latenstid. Derfor ønsker vi at implementere en on-edge ML-løsning til visuel kvalitetsinspektion, der kan køre konklusioner lokalt på butiksgulvet og mindske kravene med hensyn til tilslutning. For at holde vores eksempel ligetil træner vi en model, der markerer registrerede ridser med afgrænsningsrammer. Følgende billede er et eksempel på et tag fra vores datasæt med tre ridser markeret.

Metalmærke med ridser

Definition af pipeline-arkitekturen

Vi har nu fået klarhed over vores use case og det specifikke ML-problem, vi sigter mod at løse, og som drejer sig om objektdetektion ved kanten. Nu er det tid til at udarbejde en arkitektur for vores MLOps-pipeline. På nuværende tidspunkt ser vi ikke på teknologier eller specifikke tjenester endnu, men snarere på højniveaukomponenterne i vores pipeline. For hurtigt at omskole og implementere, er vi nødt til at automatisere hele ende-til-ende-processen: fra datamærkning, til træning, til konklusioner. Der er dog et par udfordringer, der gør det særligt svært at opsætte en pipeline til en edge case:

  • At bygge forskellige dele af denne proces kræver forskellige færdighedssæt. For eksempel har datamærkning og træning et stærkt datavidenskabsfokus, edge-implementering kræver en Internet of Things (IoT)-specialist, og automatisering af hele processen udføres normalt af en person med et DevOps-færdighedssæt.
  • Afhængigt af din organisation kan hele denne proces endda blive implementeret af flere teams. For vores brugssag arbejder vi under den antagelse, at separate teams er ansvarlige for mærkning, træning og implementering.
  • Flere roller og færdighedssæt betyder andre krav, når det kommer til værktøj og processer. For eksempel vil datavidenskabsmænd måske overvåge og arbejde med deres velkendte notebook-miljø. MLOps ingeniører ønsker at arbejde ved at bruge infrastruktur som kodeværktøjer (IaC) og er måske mere fortrolige med AWS Management Console.

Hvad betyder det for vores pipeline-arkitektur?

For det første er det afgørende klart at definere hovedkomponenterne i end-to-end-systemet, der tillader forskellige teams at arbejde uafhængigt. For det andet skal veldefinerede grænseflader mellem teams defineres for at øge samarbejdseffektiviteten. Disse grænseflader hjælper med at minimere forstyrrelser mellem teams, hvilket gør dem i stand til at ændre deres interne processer efter behov, så længe de overholder de definerede grænseflader. Det følgende diagram illustrerer, hvordan dette kunne se ud for vores computervision-pipeline.

MLOps pipeline skriblerier

Lad os undersøge den overordnede arkitektur af MLOps pipeline i detaljer:

  1. Processen begynder med en samling af råbilleder af metalmærker, som optages ved hjælp af en kantkameraenhed i produktionsmiljøet for at danne et indledende træningsdatasæt.
  2. Det næste trin involverer at mærke disse billeder og markere defekter ved hjælp af afgrænsningsrammer. Det er vigtigt at versionere det mærkede datasæt, hvilket sikrer sporbarhed og ansvarlighed for de anvendte træningsdata.
  3. Når vi har et mærket datasæt, kan vi fortsætte med træning, finjustering, evaluering og versionering af vores model.
  4. Når vi er tilfredse med vores modelydeevne, kan vi implementere modellen til en edge-enhed og køre direkte konklusioner på kanten.
  5. Mens modellen kører i produktion, genererer kantkameraenheden værdifulde billeddata, der indeholder hidtil usete defekter og kantkasser. Vi kan bruge disse data til at forbedre vores models ydeevne yderligere. For at opnå dette gemmer vi billeder, som modellen forudsiger med lav sikkerhed eller laver fejlagtige forudsigelser. Disse billeder føjes derefter tilbage til vores rå datasæt, hvilket starter hele processen igen.

Det er vigtigt at bemærke, at de rå billeddata, det mærkede datasæt og den trænede model fungerer som veldefinerede grænseflader mellem de forskellige pipelines. MLOps ingeniører og dataforskere har fleksibiliteten til at vælge teknologierne i deres pipelines, så længe de konsekvent producerer disse artefakter. Det vigtigste er, at vi har etableret en lukket feedback-loop. Defekte forudsigelser eller forudsigelser med lav konfidens i produktionen kan bruges til regelmæssigt at udvide vores datasæt og automatisk genoptræne og forbedre modellen.

Målarkitektur

Nu hvor højniveauarkitekturen er etableret, er det tid til at gå et niveau dybere og se på, hvordan vi kunne bygge dette med AWS-tjenester. Bemærk, at arkitekturen vist i dette indlæg forudsætter, at du vil tage fuld kontrol over hele datavidenskabsprocessen. Men hvis du lige skal i gang med kvalitetskontrol på kanten, anbefaler vi Amazon Lookout for Vision. Det giver en måde at træne din egen kvalitetsinspektionsmodel på uden at skulle bygge, vedligeholde eller forstå ML-kode. For mere information, se Amazon Lookout for Vision understøtter nu visuel inspektion af produktfejl i kanten.

Men hvis du vil tage fuld kontrol, viser følgende diagram, hvordan en arkitektur kunne se ud.

MLOps pipeline arkitektur

På samme måde som før, lad os gå gennem arbejdsgangen trin for trin og identificere, hvilke AWS-tjenester, der passer til vores krav:

  1. Amazon Simple Storage Service (Amazon S3) bruges til at gemme rå billeddata, fordi det giver os en billig lagringsløsning.
  2. Mærkningsarbejdsgangen orkestreres vha AWS-trinfunktioner, en serverløs arbejdsprocesmotor, der gør det nemt at orkestrere trinene i etiketteringsarbejdsgangen. Som en del af denne arbejdsgang bruger vi Amazon SageMaker Ground Truth at fuldautomatisere mærkningen ved hjælp af mærkningsopgaver og administrerede menneskelige arbejdsstyrker. AWS Lambda bruges til at forberede dataene, starte mærkningsopgaverne og gemme etiketterne i Amazon SageMaker Feature Store.
  3. SageMaker Feature Store gemmer etiketterne. Det giver os mulighed for centralt at administrere og dele vores funktioner og giver os indbyggede dataversionsfunktioner, som gør vores pipeline mere robust.
  4. Vi orkestrerer modelbygningen og træningspipeline vha Amazon SageMaker Pipelines. Den integreres med de andre SageMaker-funktioner, der kræves via indbyggede trin. SageMaker Training jobs bruges til at automatisere modeltræningen, og SageMaker Processing jobs bruges til at udarbejde data og evaluere modellens ydeevne. I dette eksempel bruger vi Ultralytics YOLOv8 Python-pakke og modelarkitektur til at træne og eksportere en objektdetekteringsmodel til ONNX ML-modelformat til bærbarhed.
  5. Hvis ydelsen er acceptabel, er den trænede model registreret i Amazon SageMaker Model Registry med et inkrementelt versionsnummer vedhæftet. Det fungerer som vores grænseflade mellem modeltrænings- og kantimplementeringstrinene. Vi styrer også godkendelsestilstanden for modeller her. I lighed med de andre tjenester, der bruges, er det fuldt administreret, så vi ikke skal sørge for at drive vores egen infrastruktur.
  6. Edge-implementerings-workflowet automatiseres ved hjælp af Step Functions, svarende til label-workflowet. Vi kan bruge API-integrationerne af Step Functions til nemt at kalde de forskellige påkrævede AWS-service-API'er som AWS IoT Greengrass for at skabe nye modelkomponenter og bagefter implementere komponenterne til edge-enheden.
  7. AWS IoT Greengrass bruges som edge-enhedens runtime-miljø. Det styrer implementeringslivscyklussen for vores model og inferenskomponenter på kanten. Det giver os mulighed for nemt at implementere nye versioner af vores model og inferenskomponenter ved hjælp af simple API-kald. Derudover kører ML-modeller ved kanten normalt ikke isoleret; vi kan bruge de forskellige AWS , samfund leverede komponenter af AWS IoT Greengrass for at oprette forbindelse til andre tjenester.

Den skitserede arkitektur ligner vores højniveauarkitektur vist før. Amazon S3, SageMaker Feature Store og SageMaker Model Registry fungerer som grænseflader mellem de forskellige pipelines. For at minimere indsatsen for at køre og drive løsningen bruger vi administrerede og serverløse tjenester, hvor det er muligt.

Sammensmeltning til et robust CI/CD-system

Datamærkning, modeltræning og edge-implementering er kernen i vores løsning. Som sådan bør enhver ændring relateret til den underliggende kode eller data i nogen af ​​disse dele udløse en ny kørsel af hele orkestreringsprocessen. For at opnå dette er vi nødt til at integrere denne pipeline i et CI/CD-system, der giver os mulighed for automatisk at implementere kode- og infrastrukturændringer fra et versioneret kodelager til produktion. I lighed med den tidligere arkitektur er teamautonomi et vigtigt aspekt her. Følgende diagram viser, hvordan dette kunne se ud ved at bruge AWS-tjenester.

CI/CD pipeline

Lad os gå gennem CI/CD-arkitekturen:

  1. AWS CodeCommit fungerer som vores Git-lager. For nemheds skyld adskilte vi i vores leverede eksempel de forskellige dele (mærkning, modeltræning, edge-implementering) via undermapper i et enkelt git-lager. I et scenarie i den virkelige verden kan hvert team bruge forskellige arkiver for hver del.
  2. Infrastrukturimplementering er automatiseret ved hjælp af AWS CDK, og hver del (mærkning, træning og edge) får sin egen AWS CDK-app for at tillade uafhængige implementeringer.
  3. AWS CDK pipeline-funktionen bruger AWS CodePipeline at automatisere infrastrukturen og kodeimplementeringer.
  4. AWS CDK implementerer to kodepipelines for hvert trin: en aktivpipeline og en workflowpipeline. Vi adskilte arbejdsgangen fra aktivimplementeringen for at give os mulighed for at starte arbejdsgangene separat, hvis der ikke er ændringer i aktiver (f.eks. når der er nye billeder tilgængelige til træning).
    • Asset code pipeline implementerer al den infrastruktur, der kræves for, at workflowet kan køre med succes, som f.eks AWS identitets- og adgangsstyring (IAM)-roller, Lambda-funktioner og containerbilleder brugt under træning.
    • Workflow-kodepipelinen kører selve mærknings-, trænings- eller edge-implementeringsworkflowet.
  5. Asset-pipelines udløses automatisk ved commit, såvel som når en tidligere workflow-pipeline er færdig.
  6. Hele processen udløses på et skema ved hjælp af en Amazon Eventbridge regel for regelmæssig omskoling.

Med CI/CD-integrationen er hele ende-til-ende-kæden nu fuldautomatiseret. Pipelinen udløses, hver gang kode ændres i vores git-lager samt på en tidsplan for at imødekomme dataændringer.

Tænker fremad

Den beskrevne løsningsarkitektur repræsenterer de grundlæggende komponenter til at bygge en ende-til-ende MLOps-pipeline ved kanten. Afhængigt af dine krav kan du dog overveje at tilføje yderligere funktionalitet. Følgende er nogle eksempler:

Konklusion

I dette indlæg skitserede vi vores arkitektur for at bygge en ende-til-ende MLOps-pipeline til visuel kvalitetsinspektion ved kanten ved hjælp af AWS-tjenester. Denne arkitektur strømliner hele processen, der omfatter datamærkning, modeludvikling og edge-implementering, hvilket gør os i stand til hurtigt og pålideligt at træne og implementere nye versioner af modellen. Med serverløse og administrerede tjenester kan vi rette vores fokus mod at levere forretningsværdi frem for at administrere infrastruktur.

In del 2 af denne serie vil vi dykke et niveau dybere og se på implementeringen af ​​denne arkitektur mere detaljeret, specifikt mærkning og modelbygning. Hvis du vil springe direkte til koden, kan du tjekke den medfølgende GitHub repo.

Om forfatterne

Michael RothMichael Roth er en Senior Solutions Architect hos AWS, der støtter produktionskunder i Tyskland med at løse deres forretningsudfordringer gennem AWS-teknologi. Udover arbejde og familie er han interesseret i sportsvogne og nyder italiensk kaffe.

Jörg WöhrleJörg Wöhrle er Solutions Architect hos AWS, der arbejder med produktionskunder i Tyskland. Med en passion for automatisering har Joerg arbejdet som softwareudvikler, DevOps-ingeniør og Site Reliability Engineer i sit liv før AWS. Ud over skyen er han en ambitiøs løber og nyder kvalitetstid med sin familie. Så hvis du har en DevOps-udfordring eller ønsker at løbe: lad ham det vide.

Johannes LangerJohannes Langer er Senior Solutions Architect hos AWS, der arbejder med virksomhedskunder i Tyskland. Johannes brænder for at anvende machine learning til at løse reelle forretningsproblemer. I sit personlige liv nyder Johannes at arbejde på boligforbedringsprojekter og tilbringe tid udendørs med sin familie.

Tidsstempel:

Mere fra AWS maskinindlæring