Construiți o conductă MLOps de la capăt la capăt pentru inspecția vizuală a calității la margine – Partea 1 | Amazon Web Services

O implementare cu succes a unui model de învățare automată (ML) într-un mediu de producție se bazează în mare măsură pe o conductă ML end-to-end. Deși dezvoltarea unei astfel de conducte poate fi o provocare, devine și mai complexă atunci când aveți de-a face cu un caz de utilizare edge ML. Învățarea automată la margine este un concept care aduce capacitatea de a rula modele ML la nivel local pe dispozitivele edge. Pentru a implementa, monitoriza și menține aceste modele la margine, este necesară o conductă MLOps robustă. O conductă MLOps permite automatizarea întregului ciclu de viață ML, de la etichetarea datelor până la formarea modelului și implementarea.

Implementarea unei conducte MLOps la margine introduce complexități suplimentare care fac ca procesele de automatizare, integrare și întreținere să fie mai dificile din cauza cheltuielilor operaționale crescute implicate. Cu toate acestea, folosind servicii create special, cum ar fi Amazon SageMaker și AWS IoT Greengrass vă permite să reduceți semnificativ acest efort. În această serie, vă prezentăm prin procesul de arhitectură și construcție a unei conducte MLOps integrate end-to-end pentru un caz de utilizare de viziune computerizată la margine folosind SageMaker, AWS IoT Greengrass și Kit AWS Cloud Development (AWS CDK).

Acest post se concentrează pe proiectarea arhitecturii generale a conductei MLOps; Partea 2 și Partea 3 din această serie se concentrează pe implementarea componentelor individuale. Am furnizat un exemplu de implementare în documentul însoțitor GitHub depozit pentru ca tu să încerci tu. Dacă abia ați început să utilizați MLOps la marginea AWS, consultați MLOps la margine cu Amazon SageMaker Edge Manager și AWS IoT Greengrass pentru o imagine de ansamblu și o arhitectură de referință.

Caz de utilizare: inspectarea calității etichetelor metalice

În calitate de inginer ML, este important să înțelegeți cazul de afaceri la care lucrați. Așadar, înainte de a ne aprofunda în arhitectura conductei MLOps, să ne uităm la exemplul de caz de utilizare pentru această postare. Imaginați-vă o linie de producție a unui producător care gravează etichete metalice pentru a crea etichete de bagaje personalizate. Procesul de asigurare a calității este costisitor, deoarece etichetele din metal brut trebuie inspectate manual pentru defecte precum zgârieturi. Pentru a face acest proces mai eficient, folosim ML pentru a detecta etichetele defecte la începutul procesului. Acest lucru ajută la evitarea defectelor costisitoare în etapele ulterioare ale procesului de producție. Modelul ar trebui să identifice posibilele defecte, cum ar fi zgârieturile, în timp aproape real și să le marcheze. În mediile de producție, de multe ori nu trebuie să vă confruntați cu nicio conexiune sau cu lățime de bandă restrânsă și cu o latență crescută. Prin urmare, dorim să implementăm o soluție ML de vârf pentru inspecția vizuală a calității, care poate rula inferențe la nivel local în atelier și poate reduce cerințele în ceea ce privește conectivitate. Pentru a ne menține exemplul simplu, antrenăm un model care marchează zgârieturile detectate cu casete de delimitare. Următoarea imagine este un exemplu de etichetă din setul nostru de date cu trei zgârieturi marcate.

Definirea arhitecturii conductei

Acum am câștigat claritate în cazul nostru de utilizare și în problema specifică ML pe care ne propunem să o abordăm, care se învârte în jurul detectării obiectelor la margine. Acum este timpul să elaborăm o arhitectură pentru conducta noastră MLOps. În această etapă, nu ne uităm încă la tehnologii sau servicii specifice, ci mai degrabă la componentele de nivel înalt ale conductei noastre. Pentru a reinstrui și implementa rapid, trebuie să automatizăm întregul proces de la capăt la capăt: de la etichetarea datelor, la instruire, la inferență. Cu toate acestea, există câteva provocări care fac configurarea unei conducte pentru un caz marginal deosebit de dificilă:

• Construirea diferitelor părți ale acestui proces necesită seturi diferite de abilități. De exemplu, etichetarea datelor și instruirea se concentrează puternic pe știința datelor, implementarea edge necesită un specialist în Internet of Things (IoT), iar automatizarea întregului proces este de obicei realizată de cineva cu un set de abilități DevOps.
• În funcție de organizația dvs., întregul proces poate fi implementat chiar de mai multe echipe. Pentru cazul nostru de utilizare, lucrăm pe baza ipotezei că echipe separate sunt responsabile pentru etichetare, instruire și implementare.
• Mai multe roluri și seturi de abilități înseamnă cerințe diferite când vine vorba de instrumente și procese. De exemplu, oamenii de știință de date ar putea dori să monitorizeze și să lucreze cu mediul lor de notebook familiar. Inginerii MLOps doresc să lucreze folosind infrastructura ca instrumente de cod (IaC) și ar putea fi mai familiarizați cu Consola de administrare AWS.

Ce înseamnă acest lucru pentru arhitectura conductei noastre?

În primul rând, este esențial să definiți în mod clar componentele majore ale sistemului end-to-end, care permite diferitelor echipe să lucreze independent. În al doilea rând, trebuie definite interfețe bine definite între echipe pentru a spori eficiența colaborării. Aceste interfețe ajută la minimizarea întreruperilor dintre echipe, permițându-le să-și modifice procesele interne după cum este necesar, atâta timp cât respectă interfețele definite. Următoarea diagramă ilustrează cum ar putea arăta pentru conducta noastră de viziune computerizată.

Să examinăm în detaliu arhitectura generală a conductei MLOps:

1. Procesul începe cu o colecție de imagini brute ale etichetelor metalice, care sunt capturate folosind un dispozitiv de cameră de margine în mediul de producție pentru a forma un set de date de antrenament inițial.
2. Următorul pas implică etichetarea acestor imagini și marcarea defectelor folosind casete de delimitare. Este esențial să versionați setul de date etichetat, asigurând trasabilitatea și responsabilitatea pentru datele de antrenament utilizate.
3. După ce avem un set de date etichetat, putem continua cu antrenamentul, reglarea fină, evaluarea și versiunea modelului nostru.
4. Când suntem mulțumiți de performanța modelului nostru, putem implementa modelul pe un dispozitiv de margine și putem efectua inferențe live la margine.
5. În timp ce modelul funcționează în producție, dispozitivul de cameră de margine generează date de imagine valoroase care conțin defecte și carcase de margine nevăzute anterior. Putem folosi aceste date pentru a îmbunătăți și mai mult performanța modelului nostru. Pentru a realiza acest lucru, salvăm imagini pentru care modelul prezice cu o încredere scăzută sau face predicții eronate. Aceste imagini sunt apoi adăugate înapoi la setul nostru de date brute, inițiind din nou întregul proces.

Este important de reținut că datele brute ale imaginii, setul de date etichetat și modelul antrenat servesc ca interfețe bine definite între conductele distincte. Inginerii MLOps și oamenii de știință de date au flexibilitatea de a alege tehnologiile din conductele lor, atâta timp cât produc în mod constant aceste artefacte. Cel mai important, am stabilit o buclă de feedback închisă. Predicțiile defectuoase sau cu încredere scăzută făcute în producție pot fi utilizate pentru a crește în mod regulat setul de date și pentru a reinstrui și îmbunătăți automat modelul.

Arhitectura tinta

Acum, că arhitectura de nivel înalt este stabilită, este timpul să mergem la un nivel mai adânc și să vedem cum am putea construi acest lucru cu serviciile AWS. Rețineți că arhitectura prezentată în această postare presupune că doriți să preluați controlul deplin asupra întregului proces al științei datelor. Cu toate acestea, dacă tocmai ați început cu inspecția calității la margine, vă recomandăm Amazon Lookout pentru Vision. Oferă o modalitate de a vă instrui propriul model de inspecție a calității fără a fi nevoie să construiți, să întrețineți sau să înțelegeți codul ML. Pentru mai multe informații, consultați Amazon Lookout for Vision acceptă acum inspecția vizuală a defectelor produsului la margine.

Cu toate acestea, dacă doriți să preluați controlul deplin, următoarea diagramă arată cum ar putea arăta o arhitectură.

La fel ca înainte, să parcurgem fluxul de lucru pas cu pas și să identificăm ce servicii AWS se potrivesc cerințelor noastre:

1. Serviciul Amazon de stocare simplă (Amazon S3) este folosit pentru a stoca date brute de imagine deoarece ne oferă o soluție de stocare cu costuri reduse.
2. Fluxul de lucru de etichetare este orchestrat folosind Funcții pas AWS, un motor de flux de lucru fără server care facilitează orchestrarea pașilor fluxului de lucru de etichetare. Ca parte a acestui flux de lucru, folosim Amazon SageMaker Ground Adevăr pentru a automatiza complet etichetarea utilizând joburi de etichetare și forță de muncă umană gestionată. AWS Lambdas este utilizat pentru a pregăti datele, a începe lucrările de etichetare și pentru a stoca etichetele Magazinul de caracteristici Amazon SageMaker.
3. SageMaker Feature Store stochează etichetele. Ne permite să gestionăm și să partajăm la nivel central caracteristicile noastre și ne oferă capabilități încorporate de versiune a datelor, ceea ce face ca pipeline-ul nostru să fie mai robust.
4. Orchestrăm construcția de modele și pipeline de antrenament folosind Pipelines Amazon SageMaker. Se integrează cu celelalte funcții SageMaker necesare prin pași încorporați. Locuri de munca SageMaker Training sunt folosite pentru a automatiza antrenamentul modelului și SageMaker Procesare locuri de muncă sunt utilizate pentru a pregăti datele și a evalua performanța modelului. În acest exemplu, folosim Ultralytics YOLOv8 Pachetul Python și arhitectura modelului pentru a antrena și a exporta un model de detectare a obiectelor în ONNX Formatul modelului ML pentru portabilitate.
5. Dacă performanța este acceptabilă, modelul antrenat este înregistrat în Registrul de modele Amazon SageMaker cu un număr de versiune incremental atașat. Acționează ca interfață între pașii de formare a modelului și implementarea edge. De asemenea, gestionăm aici starea de aprobare a modelelor. Asemănător celorlalte servicii utilizate, este complet gestionat, astfel încât nu trebuie să ne ocupăm de gestionarea propriei infrastructuri.
6. Fluxul de lucru de implementare edge este automatizat folosind Funcții de pas, similar fluxului de lucru de etichetare. Putem folosi integrările API ale Step Functions pentru a apela cu ușurință diferitele API-uri de serviciu AWS necesare, cum ar fi AWS IoT Greengrass, pentru a crea noi componente de model și apoi a implementa componentele pe dispozitivul edge.
7. AWS IoT Greengrass este utilizat ca mediu de rulare a dispozitivului de vârf. Gestionează ciclul de viață de implementare pentru modelul nostru și componentele de inferență de la margine. Ne permite să implementăm cu ușurință noi versiuni ale modelului nostru și ale componentelor de inferență folosind apeluri API simple. În plus, modelele ML de la margine de obicei nu rulează izolat; putem folosi diversele AWS și comunitate a furnizat componente ale AWS IoT Greengrass pentru a se conecta la alte servicii.

Arhitectura prezentată seamănă cu arhitectura noastră de nivel înalt prezentată anterior. Amazon S3, SageMaker Feature Store și SageMaker Model Registry acționează ca interfețe între diferitele conducte. Pentru a minimiza efortul de a rula și opera soluția, folosim servicii gestionate și fără server ori de câte ori este posibil.

Fuzionarea într-un sistem robust CI/CD

Etichetarea datelor, formarea modelului și pașii de implementare edge sunt esențiale pentru soluția noastră. Ca atare, orice modificare legată de codul sau datele de bază din oricare dintre acele părți ar trebui să declanșeze o nouă rulare a întregului proces de orchestrare. Pentru a realiza acest lucru, trebuie să integrăm această conductă într-un sistem CI/CD care ne permite să implementăm automat modificările de cod și infrastructură dintr-un depozit de cod versiuni în producție. Similar cu arhitectura anterioară, autonomia echipei este un aspect important aici. Următoarea diagramă arată cum ar putea arăta folosind serviciile AWS.

Să trecem prin arhitectura CI/CD:

1. AWS CodeCommit acționează ca depozitul nostru Git. Din motive de simplitate, în eșantionul oferit de noi, am separat părțile distincte (etichetare, formare model, implementare margine) prin subfoldere într-un singur depozit git. Într-un scenariu real, fiecare echipă ar putea folosi depozite diferite pentru fiecare parte.
2. Implementarea infrastructurii este automatizată folosind AWS CDK, iar fiecare parte (etichetare, instruire și margine) primește propria aplicație AWS CDK pentru a permite implementări independente.
3. Funcția pipeline AWS CDK folosește AWS CodePipeline pentru a automatiza infrastructura și implementările de cod.
4. AWS CDK implementează două conducte de cod pentru fiecare pas: o conductă de active și o conductă de flux de lucru. Am separat fluxul de lucru de implementarea activelor pentru a ne permite să începem fluxurile de lucru separat în cazul în care nu există modificări ale activelor (de exemplu, când există imagini noi disponibile pentru instruire).
   • Conducta codului de active implementează toată infrastructura necesară pentru ca fluxul de lucru să ruleze cu succes, cum ar fi Gestionarea identității și accesului AWS (IAM), funcții Lambda și imagini container utilizate în timpul antrenamentului.
   • Canalul de cod al fluxului de lucru rulează fluxul de lucru real de etichetare, instruire sau implementare marginală.
5. Conductele de active sunt declanșate automat la comitere, precum și atunci când un flux de lucru anterior este finalizat.
6. Întregul proces este declanșat într-un program folosind un Amazon EventBridge regula pentru recalificare regulată.

Odată cu integrarea CI/CD, întregul lanț end-to-end este acum complet automatizat. Conducta este declanșată ori de câte ori codul se modifică în depozitul nostru git, precum și într-un program care să se adapteze la modificările datelor.

Gândind înainte

Arhitectura soluției descrisă reprezintă componentele de bază pentru a construi o conductă MLOps end-to-end la margine. Cu toate acestea, în funcție de cerințele dvs., vă puteți gândi la adăugarea de funcționalități suplimentare. Următoarele sunt câteva exemple:

Concluzie

În această postare, am subliniat arhitectura noastră pentru construirea unei conducte MLOps end-to-end pentru inspecția vizuală a calității la margine folosind serviciile AWS. Această arhitectură eficientizează întregul proces, cuprinzând etichetarea datelor, dezvoltarea modelului și implementarea edge, permițându-ne să antrenăm și să implementăm rapid și fiabil versiuni noi ale modelului. Cu servicii gestionate și fără server, ne putem concentra mai degrabă spre furnizarea de valoare pentru afaceri decât spre gestionarea infrastructurii.

In Partea 2 din această serie, vom aprofunda cu un nivel mai mult și vom analiza implementarea acestei arhitecturi mai detaliat, în special etichetarea și construirea de modele. Dacă doriți să treceți direct la cod, puteți verifica documentul însoțitor GitHub repo.

---

Despre autori

Michael Roth este arhitect senior de soluții la AWS, care sprijină clienții de producție din Germania pentru a-și rezolva provocările de afaceri prin tehnologia AWS. Pe lângă muncă și familie, el este interesat de mașinile sport și îi place cafeaua italiană.

Jörg Wöhrle este un arhitect de soluții la AWS, care lucrează cu clienți de producție din Germania. Cu o pasiune pentru automatizare, Joerg a lucrat ca dezvoltator de software, inginer DevOps și inginer pentru fiabilitatea site-ului în viața sa anterioară AWS. Dincolo de nor, este un alergător ambițios și se bucură de timp de calitate cu familia sa. Deci, dacă aveți o provocare DevOps sau doriți să alergați: anunțați-l.

Johannes Langer este arhitect senior de soluții la AWS, lucrând cu clienții întreprinderi din Germania. Johannes este pasionat de aplicarea învățării automate pentru a rezolva probleme reale de afaceri. În viața personală, lui Johannes îi place să lucreze la proiecte de îmbunătățire a locuinței și să petreacă timp în aer liber cu familia sa.

• Distribuție de conținut bazat pe SEO și PR. Amplifică-te astăzi.
• PlatoData.Network Vertical Generative Ai. Împuterniciți-vă. Accesați Aici.
• PlatoAiStream. Web3 Intelligence. Cunoștințe amplificate. Accesați Aici.
• PlatoESG. carbon, CleanTech, Energie, Mediu inconjurator, Solar, Managementul deșeurilor. Accesați Aici.
• PlatoHealth. Biotehnologie și Inteligență pentru studii clinice. Accesați Aici.
• Sursa: https://aws.amazon.com/blogs/machine-learning/build-an-end-to-end-mlops-pipeline-for-visual-quality-inspection-at-the-edge-part-1/