Bygg en ende-til-ende MLOps-rørledning for visuell kvalitetsinspeksjon ved kanten – Del 1 | Amazon Web Services

Bygg en ende-til-ende MLOps-rørledning for visuell kvalitetsinspeksjon ved kanten – Del 1 | Amazon Web Services

Tidsstempel: 2. oktober 2023 12

En vellykket distribusjon av en maskinlæringsmodell (ML) i et produksjonsmiljø er sterkt avhengig av en ende-til-ende ML-pipeline. Selv om det kan være utfordrende å utvikle en slik rørledning, blir den enda mer kompleks når man har å gjøre med en edge ML brukssak. Maskinlæring på kanten er et konsept som bringer muligheten til å kjøre ML-modeller lokalt til edge-enheter. For å distribuere, overvåke og vedlikeholde disse modellene i kanten, kreves det en robust MLOps-rørledning. En MLOps-pipeline gjør det mulig å automatisere hele ML-livssyklusen fra datamerking til modelltrening og distribusjon.

Implementering av en MLOps-pipeline på kanten introduserer ytterligere kompleksitet som gjør automatiserings-, integrasjons- og vedlikeholdsprosessene mer utfordrende på grunn av de økte driftskostnadene. Imidlertid bruker spesialbygde tjenester som Amazon SageMaker og AWS IoT Greengrass lar deg redusere denne innsatsen betydelig. I denne serien leder vi deg gjennom prosessen med å bygge og bygge en integrert ende-til-ende MLOps-pipeline for et datasynsbruk på kanten ved hjelp av SageMaker, AWS IoT Greengrass og AWS skyutviklingssett (AWS CDK).

Dette innlegget fokuserer på å designe den overordnede MLOps-rørledningsarkitekturen; Del 2 og Del 3 av denne serien fokuserer på implementeringen av de enkelte komponentene. Vi har gitt et eksempel på implementering i den medfølgende GitHub repository for deg å prøve selv. Hvis du akkurat har begynt med MLOps på kanten på AWS, se MLOps på kanten med Amazon SageMaker Edge Manager og AWS IoT Greengrass for oversikt og referansearkitektur.

Brukstilfelle: Inspisere kvaliteten på metallbrikker

Som ML-ingeniør er det viktig å forstå forretningssaken du jobber med. Så før vi dykker inn i MLOps-rørledningsarkitekturen, la oss se på eksempelbruken for dette innlegget. Se for deg en produksjonslinje fra en produsent som graverer metallmerker for å lage tilpassede bagasjemerker. Kvalitetssikringsprosessen er kostbar fordi råmetalletikettene må inspiseres manuelt for defekter som riper. For å gjøre denne prosessen mer effektiv bruker vi ML for å oppdage feilmerker tidlig i prosessen. Dette bidrar til å unngå kostbare feil på senere stadier av produksjonsprosessen. Modellen skal identifisere mulige defekter som riper i nesten sanntid og merke dem. I produksjonsmiljøer må du ofte håndtere ingen tilkobling eller begrenset båndbredde og økt ventetid. Derfor ønsker vi å implementere en on-edge ML-løsning for visuell kvalitetsinspeksjon som kan kjøre inferens lokalt på butikkgulvet og redusere kravene til tilkobling. For å holde eksemplet vårt enkelt, trener vi en modell som markerer oppdagede riper med avgrensningsbokser. Følgende bilde er et eksempel på en tag fra datasettet vårt med tre riper merket.

Metallmerke med riper

Definere rørledningsarkitekturen

Vi har nå fått klarhet i brukssaken vår og det spesifikke ML-problemet vi tar sikte på å adressere, som dreier seg om objektdeteksjon ved kanten. Nå er det på tide å utarbeide en arkitektur for MLOps-rørledningen vår. På dette stadiet ser vi ikke på teknologier eller spesifikke tjenester ennå, men snarere høynivåkomponentene i rørledningen vår. For raskt å omskolere og distribuere, må vi automatisere hele ende-til-ende-prosessen: fra datamerking, til opplæring, til slutning. Det er imidlertid noen få utfordringer som gjør det spesielt vanskelig å sette opp en pipeline for en kantsak:

  • Å bygge ulike deler av denne prosessen krever ulike ferdighetssett. For eksempel har datamerking og opplæring et sterkt datavitenskapelig fokus, edge-distribusjon krever en Internet of Things (IoT)-spesialist, og automatisering av hele prosessen gjøres vanligvis av noen med et DevOps-kompetansesett.
  • Avhengig av organisasjonen din, kan hele denne prosessen til og med implementeres av flere team. For vår brukssituasjon jobber vi under forutsetningen om at separate team er ansvarlige for merking, opplæring og distribusjon.
  • Flere roller og ferdighetssett betyr andre krav når det kommer til verktøy og prosesser. For eksempel kan dataforskere ønske å overvåke og jobbe med sitt kjente bærbare miljø. MLOps-ingeniører ønsker å jobbe med infrastruktur som kodeverktøy (IaC) og er kanskje mer kjent med AWS-administrasjonskonsoll.

Hva betyr dette for rørledningsarkitekturen vår?

For det første er det avgjørende å tydelig definere hovedkomponentene i ende-til-ende-systemet som lar forskjellige team jobbe uavhengig. For det andre må veldefinerte grensesnitt mellom team defineres for å forbedre samarbeidseffektiviteten. Disse grensesnittene bidrar til å minimere forstyrrelser mellom teamene, slik at de kan endre sine interne prosesser etter behov så lenge de overholder de definerte grensesnittene. Følgende diagram illustrerer hvordan dette kan se ut for vår datasynspipeline.

MLOps pipeline skriblerier

La oss undersøke den overordnede arkitekturen til MLOps-rørledningen i detalj:

  1. Prosessen begynner med en samling av råbilder av metalletiketter, som fanges opp ved hjelp av en kantkameraenhet i produksjonsmiljøet for å danne et første treningsdatasett.
  2. Det neste trinnet innebærer å merke disse bildene og merke defekter ved hjelp av avgrensningsbokser. Det er viktig å versjonere det merkede datasettet, for å sikre sporbarhet og ansvarlighet for de brukte treningsdataene.
  3. Etter at vi har et merket datasett, kan vi fortsette med opplæring, finjustering, evaluering og versjonering av modellen vår.
  4. Når vi er fornøyd med modellytelsen vår, kan vi distribuere modellen til en edge-enhet og kjøre direkte konklusjoner på kanten.
  5. Mens modellen opererer i produksjon, genererer kantkameraenheten verdifulle bildedata som inneholder tidligere usynlige defekter og kanthus. Vi kan bruke disse dataene til å forbedre modellens ytelse ytterligere. For å oppnå dette lagrer vi bilder som modellen forutsier med lav selvtillit eller kommer med feilaktige spådommer. Disse bildene legges deretter tilbake til vårt rå datasett, og starter hele prosessen på nytt.

Det er viktig å merke seg at de rå bildedataene, det merkede datasettet og den opplærte modellen fungerer som veldefinerte grensesnitt mellom de distinkte rørledningene. MLOps-ingeniører og dataforskere har fleksibiliteten til å velge teknologiene i sine rørledninger så lenge de konsekvent produserer disse artefaktene. Det viktigste er at vi har etablert en lukket tilbakemeldingssløyfe. Forutsigelser med feil eller lav konfidens som er gjort i produksjonen, kan brukes til å jevnlig utvide datasettet vårt og automatisk omskolere og forbedre modellen.

Målarkitektur

Nå som høynivåarkitekturen er etablert, er det på tide å gå et nivå dypere og se på hvordan vi kan bygge dette med AWS-tjenester. Merk at arkitekturen vist i dette innlegget forutsetter at du vil ta full kontroll over hele datavitenskapsprosessen. Men hvis du akkurat er i gang med kvalitetskontroll på kanten, anbefaler vi Amazon Lookout for Vision. Det gir en måte å trene opp din egen kvalitetsinspeksjonsmodell uten å måtte bygge, vedlikeholde eller forstå ML-kode. For mer informasjon, se Amazon Lookout for Vision støtter nå visuell inspeksjon av produktfeil i kanten.

Men hvis du ønsker å ta full kontroll, viser følgende diagram hvordan en arkitektur kan se ut.

MLOps rørledningsarkitektur

På samme måte som før, la oss gå gjennom arbeidsflyten trinn for trinn og identifisere hvilke AWS-tjenester som dekker kravene våre:

  1. Amazon enkel lagringstjeneste (Amazon S3) brukes til å lagre rå bildedata fordi det gir oss en rimelig lagringsløsning.
  2. Merkearbeidsflyten er orkestrert ved hjelp av AWS trinnfunksjoner, en serverløs arbeidsflytmotor som gjør det enkelt å orkestrere trinnene i merkearbeidsflyten. Som en del av denne arbeidsflyten bruker vi Amazon SageMaker Ground Truth å fullautomatisere merkingen ved å bruke merkejobber og administrerte menneskelige arbeidsstyrker. AWS Lambda brukes til å klargjøre dataene, starte merkejobbene og lagre etikettene i Amazon SageMaker Feature Store.
  3. SageMaker Feature Store lagrer etikettene. Den lar oss administrere og dele funksjonene våre sentralt og gir oss innebygde dataversjonsfunksjoner, noe som gjør pipelinen vår mer robust.
  4. Vi orkestrerer modellbygging og treningspipeline ved hjelp av Amazon SageMaker-rørledninger. Den integreres med de andre SageMaker-funksjonene som kreves via innebygde trinn. SageMaker Training kontaktinformasjon management brukes til å automatisere modellopplæringen, og SageMaker Processing kontaktinformasjon management brukes til å forberede dataene og evaluere modellens ytelse. I dette eksemplet bruker vi Ultralytics YOLOv8 Python-pakke og modellarkitektur for å trene og eksportere en objektdeteksjonsmodell til ONNX ML modellformat for portabilitet.
  5. Hvis ytelsen er akseptabel, registreres den trente modellen i Amazon SageMaker modellregister med et inkrementelt versjonsnummer vedlagt. Den fungerer som grensesnittet vårt mellom trinnene for modellopplæring og edge-distribusjon. Vi administrerer også godkjenningstilstanden til modellene her. I likhet med de andre tjenestene som brukes, er det fullt administrert, så vi trenger ikke å ta oss av driften av vår egen infrastruktur.
  6. Edgedistribusjonsarbeidsflyten automatiseres ved hjelp av Step Functions, som ligner på merkearbeidsflyten. Vi kan bruke API-integrasjonene til Step Functions for enkelt å kalle de ulike nødvendige AWS-tjeneste-APIene som AWS IoT Greengrass for å lage nye modellkomponenter og deretter distribuere komponentene til edge-enheten.
  7. AWS IoT Greengrass brukes som kjøretidsmiljøet for edge-enheten. Den styrer distribusjonslivssyklusen for modellen vår og slutningskomponenter på kanten. Det lar oss enkelt distribuere nye versjoner av modellen vår og slutningskomponenter ved hjelp av enkle API-kall. I tillegg kjører ML-modeller ved kanten vanligvis ikke isolert; vi kan bruke de forskjellige AWS og samfunnet leverte komponenter av AWS IoT Greengrass for å koble til andre tjenester.

Arkitekturen som er skissert ligner vår høynivåarkitektur vist tidligere. Amazon S3, SageMaker Feature Store og SageMaker Model Registry fungerer som grensesnitt mellom de forskjellige rørledningene. For å minimere innsatsen for å kjøre og drifte løsningen, bruker vi administrerte og serverløse tjenester der det er mulig.

Sammenslåing til et robust CI/CD-system

Datamerking, modellopplæring og edge-implementering er kjernen i løsningen vår. Som sådan bør enhver endring relatert til den underliggende koden eller dataene i noen av disse delene utløse en ny kjøring av hele orkestreringsprosessen. For å oppnå dette, må vi integrere denne rørledningen i et CI/CD-system som lar oss automatisk distribuere kode- og infrastrukturendringer fra et versjonert kodelager til produksjon. I likhet med den forrige arkitekturen er teamautonomi et viktig aspekt her. Følgende diagram viser hvordan dette kan se ut ved bruk av AWS-tjenester.

CI/CD pipeline

La oss gå gjennom CI/CD-arkitekturen:

  1. AWS CodeCommit fungerer som vårt Git-lager. For enkelhets skyld, i vårt oppgitte eksempel, separerte vi de distinkte delene (merking, modellopplæring, edge-distribusjon) via undermapper i et enkelt git-lager. I et virkelighetsscenario kan hvert team bruke forskjellige depoter for hver del.
  2. Infrastrukturdistribusjon automatiseres ved hjelp av AWS CDK, og hver del (merking, opplæring og edge) får sin egen AWS CDK-app for å tillate uavhengige distribusjoner.
  3. AWS CDK pipeline-funksjonen bruker AWS CodePipeline for å automatisere infrastrukturen og kodedistribusjoner.
  4. AWS CDK distribuerer to kodepipelines for hvert trinn: en eiendelpipeline og en arbeidsflytpipeline. Vi skilte arbeidsflyten fra aktivadistribusjonen for å tillate oss å starte arbeidsflytene separat i tilfelle det ikke er noen aktivumendringer (for eksempel når det er nye bilder tilgjengelig for opplæring).
    • Eiendelskode-pipelinen distribuerer all infrastruktur som kreves for at arbeidsflyten skal kjøre vellykket, for eksempel AWS identitets- og tilgangsadministrasjon (IAM) roller, lambdafunksjoner og beholderbilder brukt under trening.
    • Arbeidsflytkoderørledningen kjører selve arbeidsflyten for merking, opplæring eller edge-distribusjon.
  5. Asset-pipelines utløses automatisk ved commit så vel som når en tidligere arbeidsflyt-pipeline er fullført.
  6. Hele prosessen utløses på en tidsplan ved hjelp av en Amazon EventBridge regel for regelmessig omskolering.

Med CI/CD-integrasjonen er hele ende-til-ende-kjeden nå helautomatisert. Rørledningen utløses når kodeendringer i git-depotet vårt, så vel som på en tidsplan for å imøtekomme dataendringer.

Tenker fremover

Løsningsarkitekturen som er beskrevet representerer de grunnleggende komponentene for å bygge en ende-til-ende MLOps-rørledning ved kanten. Avhengig av kravene dine kan du imidlertid tenke på å legge til ekstra funksjonalitet. Følgende er noen eksempler:

konklusjonen

I dette innlegget skisserte vi arkitekturen vår for å bygge en ende-til-ende MLOps-pipeline for visuell kvalitetsinspeksjon på kanten ved hjelp av AWS-tjenester. Denne arkitekturen strømlinjeformer hele prosessen, og omfatter datamerking, modellutvikling og edge-distribusjon, noe som gjør oss i stand til raskt og pålitelig å trene og implementere nye versjoner av modellen. Med serverløse og administrerte tjenester kan vi rette fokuset mot å levere forretningsverdi i stedet for å administrere infrastruktur.

In Del 2 av denne serien vil vi gå et nivå dypere og se på implementeringen av denne arkitekturen mer detaljert, spesielt merking og modellbygging. Hvis du vil hoppe rett til koden, kan du sjekke ut den medfølgende GitHub repo.

Om forfatterne

Michael RothMichael Roth er en senior løsningsarkitekt hos AWS som støtter produksjonskunder i Tyskland for å løse deres forretningsutfordringer gjennom AWS-teknologi. Ved siden av jobb og familie er han interessert i sportsbiler og liker italiensk kaffe.

Jörg WöhrleJörg Wöhrle er en løsningsarkitekt hos AWS, og jobber med produksjonskunder i Tyskland. Med en lidenskap for automatisering har Joerg jobbet som programvareutvikler, DevOps-ingeniør og Site Reliability Engineer i sitt liv før AWS. Utenfor skyene er han en ambisiøs løper og liker kvalitetstid med familien. Så hvis du har en DevOps-utfordring eller ønsker å løpe: gi ham beskjed.

Johannes LangerJohannes Langer er Senior Solutions Architect hos AWS, og jobber med bedriftskunder i Tyskland. Johannes brenner for å bruke maskinlæring for å løse reelle forretningsproblemer. I sitt personlige liv liker Johannes å jobbe med oppussingsprosjekter og tilbringe tid utendørs med familien.

Tidstempel:

Mer fra AWS maskinlæring