Bouw een end-to-end MLOps-pijplijn voor visuele kwaliteitscontrole aan de rand – Deel 1 | Amazon-webservices

Een succesvolle implementatie van een machine learning-model (ML) in een productieomgeving is sterk afhankelijk van een end-to-end ML-pijplijn. Hoewel het ontwikkelen van een dergelijke pijplijn een uitdaging kan zijn, wordt het zelfs nog complexer als er sprake is van een edge ML-gebruiksscenario. Machine learning aan de edge is een concept dat de mogelijkheid biedt om ML-modellen lokaal op edge-apparaten uit te voeren. Om deze modellen aan de edge te kunnen inzetten, monitoren en onderhouden is een robuuste MLOps-pijplijn vereist. Met een MLOps-pijplijn kan de volledige ML-levenscyclus worden geautomatiseerd, van het labelen van gegevens tot het trainen en implementeren van modellen.

Het implementeren van een MLOps-pijplijn aan de rand introduceert extra complexiteit die de automatiserings-, integratie- en onderhoudsprocessen uitdagender maakt vanwege de toegenomen operationele overhead. Het gebruik van speciaal gebouwde services zoals Amazon Sage Maker en AWS IoT Greengrass kunt u deze inspanning aanzienlijk verminderen. In deze serie begeleiden we u door het proces van het ontwerpen en bouwen van een geïntegreerde end-to-end MLOps-pijplijn voor een gebruiksscenario voor computervisie aan de edge met behulp van SageMaker, AWS IoT Greengrass en de AWS Cloud-ontwikkelingskit (AWS-CDK).

Dit bericht richt zich op het ontwerpen van de algemene MLOps-pijplijnarchitectuur; Deel 2 en Deel 3 van deze serie richten zich op de implementatie van de afzonderlijke componenten. In de begeleidende bijlage hebben wij een voorbeeld van een implementatie gegeven GitHub-repository zodat je het zelf kunt proberen. Als u net begint met MLOps aan de rand van AWS, raadpleeg dan MLOps aan de rand met Amazon SageMaker Edge Manager en AWS IoT Greengrass voor een overzicht en referentiearchitectuur.

Use case: Inspecteren van de kwaliteit van metalen tags

Als ML-engineer is het belangrijk om de businesscase waaraan u werkt te begrijpen. Laten we, voordat we in de MLOps-pijplijnarchitectuur duiken, eens kijken naar de voorbeeldtoepassing voor dit bericht. Stel je een productielijn voor van een fabrikant die metalen tags graveert om op maat gemaakte bagagelabels te maken. Het kwaliteitsborgingsproces is kostbaar omdat de onbewerkte metalen tags handmatig moeten worden geïnspecteerd op defecten zoals krassen. Om dit proces efficiënter te maken, gebruiken we ML om defecte tags vroeg in het proces te detecteren. Dit helpt kostbare defecten in latere stadia van het productieproces te voorkomen. Het model moet mogelijke defecten zoals krassen bijna in realtime identificeren en markeren. In productieomgevingen op de werkvloer heeft u vaak te maken met geen connectiviteit of beperkte bandbreedte en verhoogde latentie. Daarom willen we een on-edge ML-oplossing implementeren voor visuele kwaliteitsinspectie die lokaal op de werkvloer gevolgtrekkingen kan uitvoeren en de vereisten met betrekking tot connectiviteit kan verminderen. Om ons voorbeeld eenvoudig te houden, trainen we een model dat gedetecteerde krassen markeert met kaders. De volgende afbeelding is een voorbeeld van een tag uit onze dataset met drie gemarkeerde krassen.

Het definiëren van de pijplijnarchitectuur

We hebben nu duidelijkheid gekregen over onze use case en het specifieke ML-probleem dat we willen aanpakken, dat draait om objectdetectie aan de rand. Nu is het tijd om een ​​architectuur voor onze MLOps-pijplijn op te stellen. In dit stadium kijken we nog niet naar technologieën of specifieke diensten, maar eerder naar de hoogwaardige componenten van onze pijplijn. Om snel te kunnen omscholen en implementeren, moeten we het hele end-to-end-proces automatiseren: van het labelen van gegevens tot training en inferentie. Er zijn echter een paar uitdagingen die het opzetten van een pijplijn voor een edge-case bijzonder moeilijk maken:

• Het bouwen van verschillende delen van dit proces vereist verschillende vaardigheden. Datalabeling en -training hebben bijvoorbeeld een sterke focus op datawetenschap, edge-implementatie vereist een Internet of Things (IoT)-specialist en het automatiseren van het hele proces wordt meestal gedaan door iemand met een DevOps-vaardigheden.
• Afhankelijk van uw organisatie kan dit hele proces zelfs door meerdere teams worden uitgevoerd. Voor ons gebruiksscenario gaan we ervan uit dat afzonderlijke teams verantwoordelijk zijn voor labeling, training en implementatie.
• Meer rollen en vaardigheden betekenen andere eisen als het gaat om tools en processen. Datawetenschappers willen bijvoorbeeld hun vertrouwde notebookomgeving monitoren en ermee werken. MLOps-ingenieurs willen werken met infrastructuur als code (IaC)-tools en zijn wellicht meer bekend met de AWS-beheerconsole.

Wat betekent dit voor onze pijplijnarchitectuur?

Ten eerste is het van cruciaal belang om de belangrijkste componenten van het end-to-end-systeem, waarmee verschillende teams onafhankelijk kunnen werken, duidelijk te definiëren. Ten tweede moeten er goed gedefinieerde interfaces tussen teams worden gedefinieerd om de samenwerkingsefficiëntie te verbeteren. Deze interfaces helpen verstoringen tussen teams te minimaliseren, waardoor ze hun interne processen indien nodig kunnen aanpassen, zolang ze zich maar aan de gedefinieerde interfaces houden. Het volgende diagram illustreert hoe dit eruit zou kunnen zien voor onze computervisiepijplijn.

Laten we de algehele architectuur van de MLOps-pijplijn in detail bekijken:

1. Het proces begint met een verzameling onbewerkte afbeeldingen van metalen tags, die met een edge-camera in de productieomgeving worden vastgelegd om een ​​initiële trainingsdataset te vormen.
2. De volgende stap bestaat uit het labelen van deze afbeeldingen en het markeren van defecten met behulp van selectiekaders. Het is essentieel om een ​​versie van de gelabelde dataset te maken, zodat traceerbaarheid en verantwoording voor de gebruikte trainingsgegevens gewaarborgd zijn.
3. Nadat we een gelabelde dataset hebben, kunnen we doorgaan met het trainen, verfijnen, evalueren en versiebeheer van ons model.
4. Als we tevreden zijn met de prestaties van ons model, kunnen we het model op een edge-apparaat implementeren en live gevolgtrekkingen aan de edge uitvoeren.
5. Terwijl het model in productie is, genereert het edge-camera-apparaat waardevolle beeldgegevens met voorheen ongeziene defecten en edge-gevallen. We kunnen deze gegevens gebruiken om de prestaties van ons model verder te verbeteren. Om dit te bereiken slaan we beelden op waarvoor het model met weinig zekerheid voorspelt of foutieve voorspellingen doet. Deze afbeeldingen worden vervolgens weer toegevoegd aan onze onbewerkte dataset, waardoor het hele proces opnieuw wordt gestart.

Het is belangrijk op te merken dat de onbewerkte afbeeldingsgegevens, de gelabelde gegevensset en het getrainde model dienen als goed gedefinieerde interfaces tussen de verschillende pijplijnen. MLOps-ingenieurs en datawetenschappers hebben de flexibiliteit om de technologieën binnen hun pijplijnen te kiezen, zolang ze deze artefacten maar consistent produceren. Het belangrijkste is dat we een gesloten feedbacklus hebben gecreëerd. Foutieve of weinig betrouwbare voorspellingen die tijdens de productie zijn gedaan, kunnen worden gebruikt om onze dataset regelmatig uit te breiden en het model automatisch opnieuw te trainen en te verbeteren.

Doelarchitectuur

Nu de architectuur op hoog niveau is vastgesteld, is het tijd om een ​​niveau dieper te gaan en te kijken hoe we dit kunnen bouwen met AWS-services. Houd er rekening mee dat de architectuur die in dit bericht wordt weergegeven, ervan uitgaat dat u de volledige controle over het hele datawetenschapsproces wilt overnemen. Als u echter net begint met kwaliteitscontrole aan de rand, raden wij u aan Amazon Lookout voor visie. Het biedt een manier om uw eigen kwaliteitsinspectiemodel te trainen zonder dat u ML-code hoeft te bouwen, onderhouden of begrijpen. Voor meer informatie, zie Amazon Lookout for Vision ondersteunt nu visuele inspectie van productdefecten aan de rand.

Als u echter de volledige controle wilt hebben, laat het volgende diagram zien hoe een architectuur eruit zou kunnen zien.

Laten we, net als voorheen, stap voor stap door de workflow lopen en bepalen welke AWS-services aan onze eisen voldoen:

1. Amazon eenvoudige opslagservice (Amazon S3) wordt gebruikt om onbewerkte beeldgegevens op te slaan, omdat het ons een goedkope opslagoplossing biedt.
2. De labelworkflow wordt georkestreerd met behulp van AWS Stap Functies, een serverloze workflow-engine waarmee u eenvoudig de stappen van de labelworkflow kunt orkestreren. Als onderdeel van deze workflow gebruiken we Amazon SageMaker Grondwaarheid om de etikettering volledig te automatiseren met behulp van etiketteringstaken en beheerde menselijke arbeidskrachten. AWS Lambda wordt gebruikt om de gegevens voor te bereiden, de labeltaken te starten en de labels op te slaan Amazon SageMaker Feature Store.
3. SageMaker Feature Store slaat de labels op. Het stelt ons in staat onze functies centraal te beheren en te delen en biedt ons ingebouwde mogelijkheden voor gegevensversiebeheer, waardoor onze pijplijn robuuster wordt.
4. We orkestreren de modelbouw- en trainingspijplijn met behulp van Amazon SageMaker-pijpleidingen. Het kan via ingebouwde stappen worden geïntegreerd met de andere SageMaker-functies die nodig zijn. SageMaker Training banen worden gebruikt om de modeltraining te automatiseren, en Vacatures voor SageMaker Processing worden gebruikt om de gegevens voor te bereiden en de prestaties van het model te evalueren. In dit voorbeeld gebruiken we de Ultralytica YOLOv8 Python-pakket- en modelarchitectuur om een ​​objectdetectiemodel te trainen en te exporteren naar de ONNX ML-modelformaat voor draagbaarheid.
5. Als de prestaties acceptabel zijn, wordt het getrainde model geregistreerd Amazon SageMaker-modelregister met een oplopend versienummer eraan. Het fungeert als onze interface tussen de stappen voor modeltraining en edge-implementatie. Ook beheren wij hier de goedkeuringsstatus van modellen. Net als de andere gebruikte services wordt het volledig beheerd, dus we hoeven ons niet bezig te houden met het runnen van onze eigen infrastructuur.
6. De workflow voor edge-implementatie wordt geautomatiseerd met behulp van stapfuncties, vergelijkbaar met de labelworkflow. We kunnen de API-integraties van Step Functions gebruiken om eenvoudig de verschillende vereiste AWS-service-API's zoals AWS IoT Greengrass aan te roepen om nieuwe modelcomponenten te creëren en deze vervolgens op het edge-apparaat te implementeren.
7. AWS IoT Greengrass wordt gebruikt als de runtime-omgeving van het edge-apparaat. Het beheert de implementatielevenscyclus voor onze model- en inferentiecomponenten aan de rand. Hiermee kunnen we eenvoudig nieuwe versies van ons model en de inferentiecomponenten implementeren met behulp van eenvoudige API-aanroepen. Bovendien draaien ML-modellen aan de edge meestal niet geïsoleerd; we kunnen de verschillende gebruiken AWS en gemeenschap leverde componenten van AWS IoT Greengrass om verbinding te maken met andere diensten.

De geschetste architectuur lijkt op onze eerder getoonde architectuur op hoog niveau. Amazon S3, SageMaker Feature Store en SageMaker Model Registry fungeren als interfaces tussen de verschillende pijplijnen. Om de inspanning om de oplossing uit te voeren en te exploiteren te minimaliseren, maken we waar mogelijk gebruik van beheerde en serverloze services.

Samenvoegen tot een robuust CI/CD-systeem

De stappen voor het labelen van gegevens, modeltraining en edge-implementatie vormen de kern van onze oplossing. Als zodanig zou elke verandering met betrekking tot de onderliggende code of gegevens in een van deze delen een nieuwe uitvoering van het hele orkestratieproces moeten veroorzaken. Om dit te bereiken moeten we deze pijplijn integreren in een CI/CD-systeem waarmee we automatisch code- en infrastructuurwijzigingen vanuit een coderepository met versiebeheer in productie kunnen implementeren. Net als bij de vorige architectuur is teamautonomie hier een belangrijk aspect. Het volgende diagram laat zien hoe dit eruit zou kunnen zien met behulp van AWS-services.

Laten we de CI/CD-architectuur eens doornemen:

1. AWS Codecommit fungeert als onze Git-repository. Voor de eenvoud hebben we in ons geleverde voorbeeld de afzonderlijke delen (labeling, modeltraining, edge-implementatie) gescheiden via submappen in een enkele git-repository. In een realistisch scenario zou elk team voor elk onderdeel verschillende opslagplaatsen kunnen gebruiken.
2. De implementatie van de infrastructuur wordt geautomatiseerd met behulp van de AWS CDK en elk onderdeel (labeling, training en edge) krijgt zijn eigen AWS CDK-app om onafhankelijke implementaties mogelijk te maken.
3. De AWS CDK-pijplijnfunctie maakt gebruik van AWS CodePipeline om de infrastructuur en code-implementaties te automatiseren.
4. De AWS CDK implementeert voor elke stap twee codepijplijnen: een activapijplijn en een workflowpijplijn. We hebben de workflow gescheiden van de asset-implementatie, zodat we de workflows afzonderlijk kunnen starten voor het geval er geen asset-wijzigingen plaatsvinden (bijvoorbeeld wanneer er nieuwe afbeeldingen beschikbaar zijn voor training).
   • De assetcodepijplijn implementeert alle infrastructuur die nodig is om de workflow succesvol uit te voeren, zoals AWS Identiteits- en toegangsbeheer (IAM)-rollen, Lambda-functies en containerimages die tijdens de training worden gebruikt.
   • De werkstroomcodepijplijn voert de daadwerkelijke werkstroom voor labeling, training of edge-implementatie uit.
5. Assetpijplijnen worden automatisch geactiveerd bij het vastleggen ervan, maar ook wanneer een eerdere werkstroompijplijn is voltooid.
6. Het hele proces wordt volgens een schema geactiveerd met behulp van een Amazon EventBridge regel voor regelmatige omscholing.

Met de CI/CD-integratie is de hele end-to-end keten nu volledig geautomatiseerd. De pijplijn wordt geactiveerd wanneer code verandert in onze Git-repository en volgens een schema om tegemoet te komen aan gegevenswijzigingen.

Vooruit denken

De beschreven oplossingsarchitectuur vertegenwoordigt de basiscomponenten voor het bouwen van een end-to-end MLOps-pijplijn aan de rand. Afhankelijk van uw vereisten kunt u echter overwegen om extra functionaliteit toe te voegen. Hier volgen enkele voorbeelden:

Conclusie

In dit bericht hebben we onze architectuur geschetst voor het bouwen van een end-to-end MLOps-pijplijn voor visuele kwaliteitsinspectie aan de edge met behulp van AWS-services. Deze architectuur stroomlijnt het hele proces, inclusief datalabeling, modelontwikkeling en edge-implementatie, waardoor we snel en betrouwbaar nieuwe versies van het model kunnen trainen en implementeren. Met serverloze en beheerde services kunnen we onze focus richten op het leveren van bedrijfswaarde in plaats van op het beheren van de infrastructuur.

In Deel 2 van deze serie gaan we een niveau dieper en bekijken we de implementatie van deze architectuur in meer detail, met name labeling en modelbouw. Als je meteen naar de code wilt gaan, kun je de bijbehorende code bekijken GitHub repo.

---

Over de auteurs

Michael Roth is een Senior Solutions Architect bij AWS die productieklanten in Duitsland ondersteunt bij het oplossen van hun zakelijke uitdagingen via AWS-technologie. Naast werk en gezin is hij geïnteresseerd in sportwagens en houdt hij van Italiaanse koffie.

Jörg Wöhrle is een Solutions Architect bij AWS en werkt met productieklanten in Duitsland. Met een passie voor automatisering heeft Joerg in zijn pre-AWS-leven gewerkt als softwareontwikkelaar, DevOps-ingenieur en Site Reliability Engineer. Naast de cloud is hij een ambitieuze hardloper en geniet hij van quality time met zijn gezin. Dus heb je een DevOps uitdaging of wil je gaan hardlopen: laat het hem weten.

Johannes Langer is een Senior Solutions Architect bij AWS en werkt met zakelijke klanten in Duitsland. Johannes heeft een passie voor het toepassen van machine learning om echte bedrijfsproblemen op te lossen. In zijn persoonlijke leven werkt Johannes graag aan projecten voor woningverbetering en brengt hij graag tijd buitenshuis door met zijn gezin.

• Door SEO aangedreven content en PR-distributie. Word vandaag nog versterkt.
• PlatoData.Network Verticale generatieve AI. Versterk jezelf. Toegang hier.
• PlatoAiStream. Web3-intelligentie. Kennis versterkt. Toegang hier.
• PlatoESG. carbon, CleanTech, Energie, Milieu, Zonne, Afvalbeheer. Toegang hier.
• Plato Gezondheid. Intelligentie op het gebied van biotech en klinische proeven. Toegang hier.
• Bron: https://aws.amazon.com/blogs/machine-learning/build-an-end-to-end-mlops-pipeline-for-visual-quality-inspection-at-the-edge-part-1/