Bygg en heltäckande MLOps-pipeline för visuell kvalitetsinspektion vid kanten – Del 1 | Amazon webbtjänster

En framgångsrik implementering av en maskininlärningsmodell (ML) i en produktionsmiljö är starkt beroende av en ML-pipeline från slut till slut. Även om det kan vara utmanande att utveckla en sådan pipeline, blir det ännu mer komplext när man har att göra med en edge ML användningsfall. Maskininlärning vid kanten är ett koncept som ger möjligheten att köra ML-modeller lokalt till edge-enheter. För att distribuera, övervaka och underhålla dessa modeller vid kanten krävs en robust MLOps-pipeline. En MLOps-pipeline gör det möjligt att automatisera hela ML-livscykeln från datamärkning till modellträning och implementering.

Att implementera en MLOps-pipeline vid kanten introducerar ytterligare komplexitet som gör automations-, integrations- och underhållsprocesserna mer utmanande på grund av de ökade driftskostnaderna. Använder dock specialbyggda tjänster som Amazon SageMaker och AWS IoT Greengrass gör att du kan minska denna ansträngning avsevärt. I den här serien leder vi dig genom processen att utforma och bygga en integrerad end-to-end MLOps-pipeline för ett användningsfall för datorvision vid kanten med SageMaker, AWS IoT Greengrass och AWS Cloud Development Kit (AWS CDK).

Det här inlägget fokuserar på att designa den övergripande MLOps pipeline-arkitekturen; del 2 och del 3 i denna serie fokuserar på implementeringen av de enskilda komponenterna. Vi har tillhandahållit ett exempel på implementering i den medföljande GitHub repository för att du ska prova dig fram. Om du precis har börjat med MLOps vid kanten på AWS, se MLOps i kanten med Amazon SageMaker Edge Manager och AWS IoT Greengrass för en översikt och referensarkitektur.

Användningsfall: Inspektera kvaliteten på metalletiketter

Som ML-ingenjör är det viktigt att förstå det affärscase du arbetar med. Så innan vi dyker in i MLOps pipeline-arkitektur, låt oss titta på exempelanvändningsfallet för det här inlägget. Föreställ dig en produktionslinje från en tillverkare som graverar metalletiketter för att skapa skräddarsydda bagageetiketter. Kvalitetssäkringsprocessen är kostsam eftersom råmetalletiketterna måste inspekteras manuellt för defekter som repor. För att göra denna process mer effektiv använder vi ML för att upptäcka felaktiga taggar tidigt i processen. Detta hjälper till att undvika kostsamma defekter i senare skeden av produktionsprocessen. Modellen ska identifiera möjliga defekter som repor i nästan realtid och markera dem. I tillverkningsmiljöer på verkstadsgolvet måste du ofta hantera ingen anslutning eller begränsad bandbredd och ökad latens. Därför vill vi implementera en on-edge ML-lösning för visuell kvalitetsinspektion som kan dra slutsatser lokalt på verkstadsgolvet och minska kraven på anslutning. För att hålla vårt exempel rakt på sak tränar vi en modell som markerar upptäckta repor med begränsningsrutor. Följande bild är ett exempel på en tagg från vår datauppsättning med tre repor markerade.

Definiera pipeline-arkitekturen

Vi har nu fått klarhet i vårt användningsfall och det specifika ML-problem vi siktar på att ta itu med, vilket kretsar kring objektdetektering vid kanten. Nu är det dags att utarbeta en arkitektur för vår MLOps-pipeline. I det här skedet tittar vi inte på teknologier eller specifika tjänster ännu, utan snarare komponenterna på hög nivå i vår pipeline. För att snabbt kunna omskola och distribuera måste vi automatisera hela hela processen: från datamärkning, till utbildning, till slutledning. Det finns dock några utmaningar som gör det särskilt svårt att sätta upp en pipeline för ett kantfall:

• Att bygga olika delar av denna process kräver olika färdigheter. Datamärkning och utbildning har till exempel ett starkt datavetenskapligt fokus, edge-distribution kräver en Internet of Things (IoT)-specialist, och automatisering av hela processen görs vanligtvis av någon med en DevOps-färdighet.
• Beroende på din organisation kan hela denna process till och med implementeras av flera team. För vårt användningsfall arbetar vi under antagandet att separata team är ansvariga för märkning, utbildning och driftsättning.
• Fler roller och kompetensuppsättningar innebär andra krav när det kommer till verktyg och processer. Dataforskare kanske till exempel vill övervaka och arbeta med sin välbekanta bärbara miljö. MLOps ingenjörer vill arbeta med infrastruktur som kodverktyg (IaC) och kanske är mer bekanta med AWS Management Console.

Vad betyder detta för vår pipeline-arkitektur?

För det första är det avgörande att tydligt definiera de viktigaste komponenterna i helhetssystemet som gör att olika team kan arbeta självständigt. För det andra måste väldefinierade gränssnitt mellan team definieras för att effektivisera samarbetet. Dessa gränssnitt hjälper till att minimera störningar mellan team, vilket gör det möjligt för dem att modifiera sina interna processer efter behov så länge de följer de definierade gränssnitten. Följande diagram illustrerar hur detta kan se ut för vår pipeline för datorvision.

Låt oss undersöka den övergripande arkitekturen för MLOps pipeline i detalj:

1. Processen börjar med en samling råbilder av metalletiketter, som fångas med hjälp av en kantkameraenhet i produktionsmiljön för att bilda en första träningsdatauppsättning.
2. Nästa steg innebär att märka dessa bilder och markera defekter med begränsningsrutor. Det är viktigt att versionera den märkta datamängden, vilket säkerställer spårbarhet och ansvarighet för den använda utbildningsdatan.
3. Efter att vi har en märkt datauppsättning kan vi fortsätta med utbildning, finjustering, utvärdering och versionering av vår modell.
4. När vi är nöjda med vår modellprestanda kan vi distribuera modellen till en edge-enhet och köra direkta slutsatser vid kanten.
5. Medan modellen är i produktion, genererar kantkameraenheten värdefull bilddata som innehåller tidigare osynliga defekter och kantfodral. Vi kan använda dessa data för att ytterligare förbättra vår modells prestanda. För att åstadkomma detta sparar vi bilder som modellen förutsäger med låg tillförsikt eller gör felaktiga förutsägelser. Dessa bilder läggs sedan tillbaka till vår rådatauppsättning, vilket initierar hela processen igen.

Det är viktigt att notera att råbildsdata, märkt dataset och tränad modell fungerar som väldefinierade gränssnitt mellan de distinkta pipelines. MLOps-ingenjörer och datavetare har flexibiliteten att välja teknologier inom sina pipelines så länge de konsekvent producerar dessa artefakter. Det viktigaste är att vi har etablerat en sluten återkopplingsslinga. Felaktiga förutsägelser eller förutsägelser med låg konfidens som görs i produktionen kan användas för att regelbundet utöka vår datauppsättning och automatiskt omskola och förbättra modellen.

Målarkitektur

Nu när högnivåarkitekturen är etablerad är det dags att gå en nivå djupare och titta på hur vi skulle kunna bygga detta med AWS-tjänster. Observera att arkitekturen som visas i det här inlägget förutsätter att du vill ta full kontroll över hela datavetenskapsprocessen. Men om du precis har börjat med kvalitetskontroll på kanten rekommenderar vi Amazon Lookout for Vision. Det ger ett sätt att träna din egen kvalitetsinspektionsmodell utan att behöva bygga, underhålla eller förstå ML-kod. För mer information, se Amazon Lookout for Vision stöder nu visuell inspektion av produktdefekter i kanten.

Men om du vill ta full kontroll visar följande diagram hur en arkitektur skulle kunna se ut.

I likhet med tidigare, låt oss gå igenom arbetsflödet steg för steg och identifiera vilka AWS-tjänster som passar våra krav:

1. Amazon enkel lagringstjänst (Amazon S3) används för att lagra rå bilddata eftersom det ger oss en billig lagringslösning.
2. Märkningsarbetsflödet orkestreras med hjälp av AWS stegfunktioner, en serverlös arbetsflödesmotor som gör det enkelt att orkestrera stegen i etiketteringsarbetsflödet. Som en del av detta arbetsflöde använder vi Amazon SageMaker Ground Sannhet att helt automatisera märkningen med hjälp av märkningsjobb och hanterad mänsklig arbetsstyrka. AWS Lambda används för att förbereda data, starta märkningsjobben och lagra etiketterna i Amazon SageMaker Feature Store.
3. SageMaker Feature Store lagrar etiketterna. Det tillåter oss att centralt hantera och dela våra funktioner och ger oss inbyggda dataversionsfunktioner, vilket gör vår pipeline mer robust.
4. Vi orkestrerar modellbygget och utbildningspipeline med hjälp av Amazon SageMaker-rörledningar. Den integreras med de andra SageMaker-funktionerna som krävs via inbyggda steg. SageMaker Training jobb används för att automatisera modellträningen, och SageMaker Processing kontaktinformation förvaltning används för att förbereda data och utvärdera modellens prestanda. I det här exemplet använder vi Ultralytics YOLOv8 Python-paket och modellarkitektur för att träna och exportera en objektdetekteringsmodell till ONNX ML modellformat för portabilitet.
5. Om prestandan är acceptabel registreras den utbildade modellen i Amazon SageMaker Model Registry med ett inkrementellt versionsnummer bifogat. Det fungerar som vårt gränssnitt mellan modellträningen och edge-deployment-stegen. Vi hanterar även godkännandestatus för modeller här. I likhet med de andra tjänsterna som används är den helt hanterad, så vi behöver inte sköta vår egen infrastruktur.
6. Edge-distributionsarbetsflödet automatiseras med hjälp av Step Functions, liknande etiketteringsarbetsflödet. Vi kan använda API-integreringarna av Step Functions för att enkelt anropa de olika nödvändiga AWS-tjänst-API:erna som AWS IoT Greengrass för att skapa nya modellkomponenter och efteråt distribuera komponenterna till edge-enheten.
7. AWS IoT Greengrass används som edge device runtime-miljö. Den hanterar distributionslivscykeln för vår modell och slutledningskomponenter vid kanten. Det gör att vi enkelt kan distribuera nya versioner av vår modell och slutledningskomponenter med enkla API-anrop. Dessutom körs ML-modeller vid kanten vanligtvis inte isolerade; vi kan använda de olika AWS och samfundet tillhandahållit komponenter av AWS IoT Greengrass för att ansluta till andra tjänster.

Arkitekturen som beskrivs liknar vår högnivåarkitektur som visats tidigare. Amazon S3, SageMaker Feature Store och SageMaker Model Registry fungerar som gränssnitt mellan de olika pipelines. För att minimera ansträngningen att köra och driva lösningen använder vi hanterade och serverlösa tjänster där det är möjligt.

Sammanfogas till ett robust CI/CD-system

Datamärkningen, modellutbildningen och edge-implementeringen är kärnan i vår lösning. Som sådan bör varje förändring relaterad till den underliggande koden eller data i någon av dessa delar utlösa en ny körning av hela orkestreringsprocessen. För att uppnå detta måste vi integrera denna pipeline i ett CI/CD-system som tillåter oss att automatiskt distribuera kod- och infrastrukturändringar från ett versionskodlager till produktion. I likhet med den tidigare arkitekturen är teamautonomi en viktig aspekt här. Följande diagram visar hur detta kan se ut med AWS-tjänster.

Låt oss gå igenom CI/CD-arkitekturen:

1. AWS CodeCommit fungerar som vårt Git-förråd. För enkelhetens skull separerade vi i vårt tillhandahållna exempel de distinkta delarna (märkning, modellträning, edge-distribution) via undermappar i ett enda git-förråd. I ett verkligt scenario kan varje team använda olika förråd för varje del.
2. Infrastrukturdistribution automatiseras med hjälp av AWS CDK och varje del (märkning, utbildning och edge) får sin egen AWS CDK-app för att tillåta oberoende distributioner.
3. AWS CDK pipeline-funktionen använder AWS CodePipeline för att automatisera infrastrukturen och kodinstallationer.
4. AWS CDK distribuerar två kodpipelines för varje steg: en tillgångspipeline och en arbetsflödespipeline. Vi separerade arbetsflödet från tillgångsdistributionen för att tillåta oss att starta arbetsflödena separat om det inte finns några tillgångsändringar (till exempel när det finns nya bilder tillgängliga för utbildning).
   • Asset code pipeline distribuerar all infrastruktur som krävs för att arbetsflödet ska fungera framgångsrikt, som t.ex AWS identitets- och åtkomsthantering (IAM) roller, lambdafunktioner och behållarbilder som används under träning.
   • Arbetsflödeskodpipelinen kör själva arbetsflödet för märkning, utbildning eller edge-distribution.
5. Asset pipelines utlöses automatiskt vid commit såväl som när en tidigare arbetsflödespipeline är klar.
6. Hela processen utlöses enligt ett schema med hjälp av en Amazon EventBridge regel för regelbunden omskolning.

Med CI/CD-integrationen är hela kedjan från slut till ände nu helt automatiserad. Pipelinen triggas när koden ändras i vårt git-förråd samt enligt ett schema för att ta hänsyn till dataändringar.

Framåttänkande

Den beskrivna lösningsarkitekturen representerar de grundläggande komponenterna för att bygga en ände-till-ände MLOps-pipeline vid kanten. Beroende på dina krav kan du dock tänka på att lägga till ytterligare funktionalitet. Följande är några exempel:

Slutsats

I det här inlägget beskrev vi vår arkitektur för att bygga en end-to-end MLOps-pipeline för visuell kvalitetsinspektion vid kanten med hjälp av AWS-tjänster. Denna arkitektur effektiviserar hela processen och omfattar datamärkning, modellutveckling och edge-distribution, vilket gör det möjligt för oss att snabbt och tillförlitligt träna och implementera nya versioner av modellen. Med serverlösa och hanterade tjänster kan vi rikta vårt fokus mot att leverera affärsvärde snarare än att hantera infrastruktur.

In del 2 av denna serie kommer vi att fördjupa oss en nivå djupare och titta på implementeringen av denna arkitektur mer detaljerat, särskilt märkning och modellbygge. Om du vill hoppa direkt till koden kan du kolla in den medföljande GitHub repo.

---

Om författarna

Michael Roth är en Senior Solutions Architect på AWS som stödjer tillverkningskunder i Tyskland för att lösa deras affärsutmaningar genom AWS-teknik. Förutom arbete och familj är han intresserad av sportbilar och tycker om italienskt kaffe.

Jörg Wöhrle är lösningsarkitekt på AWS och arbetar med tillverkande kunder i Tyskland. Med en passion för automation har Joerg arbetat som mjukvaruutvecklare, DevOps-ingenjör och Site Reliability Engineer i sitt liv före AWS. Bortom molnet är han en ambitiös löpare och tycker om kvalitetstid med sin familj. Så om du har en DevOps-utmaning eller vill springa: låt honom veta.

Johannes Langer är Senior Solutions Architect på AWS och arbetar med företagskunder i Tyskland. Johannes brinner för att tillämpa maskininlärning för att lösa verkliga affärsproblem. I sitt personliga liv tycker Johannes om att arbeta med hemförbättringsprojekt och spendera tid utomhus med sin familj.

• SEO-drivet innehåll och PR-distribution. Bli förstärkt idag.
• PlatoData.Network Vertical Generative Ai. Styrka dig själv. Tillgång här.
• PlatoAiStream. Web3 Intelligence. Kunskap förstärkt. Tillgång här.
• Platoesg. Kol, CleanTech, Energi, Miljö, Sol, Avfallshantering. Tillgång här.
• PlatoHealth. Biotech och kliniska prövningar Intelligence. Tillgång här.
• Källa: https://aws.amazon.com/blogs/machine-learning/build-an-end-to-end-mlops-pipeline-for-visual-quality-inspection-at-the-edge-part-1/