Ehitage otsast lõpuni MLOps torujuhe visuaalseks kvaliteedikontrolliks servas – 1. osa | Amazoni veebiteenused

Masinõppe (ML) mudeli edukas juurutamine tootmiskeskkonnas sõltub suuresti täielikust ML-konveierist. Kuigi sellise torujuhtme väljatöötamine võib olla keeruline, muutub see veelgi keerulisemaks edge ML kasutusjuht. Masinõpe ääres on kontseptsioon, mis toob ML-mudelite kohapeal käitamise võimaluse ääreseadmetesse. Nende mudelite äärealadel juurutamiseks, jälgimiseks ja hooldamiseks on vaja tugevat MLOps torujuhet. MLOps-konveier võimaldab automatiseerida kogu ML-i elutsüklit alates andmete märgistamisest kuni mudeli koolituse ja juurutamiseni.

MLOps-konveieri juurutamine serval toob kaasa täiendavaid keerukusi, mis muudavad automatiseerimis-, integreerimis- ja hooldusprotsessid keerukamaks, kuna sellega kaasnevad suuremad üldkulud. Kasutades aga sihipäraseid teenuseid nagu Amazon SageMaker ja AWS IoT Greengrass võimaldab teil seda pingutust oluliselt vähendada. Selles seerias tutvustame teid arvutinägemise kasutusjuhtumi serval integreeritud otsast lõpuni MLOps torujuhtme kujundamise ja ehitamise protsessis, kasutades SageMakerit, AWS IoT Greengrassi ja AWS pilvearenduskomplekt (AWS CDK).

See postitus keskendub üldise MLOps torujuhtme arhitektuuri kujundamisele; Osa 2 ja Osa 3 seeria keskendub üksikute komponentide rakendamisele. Oleme esitanud näidisrakenduse kaasasolevas dokumendis GitHubi hoidla et saaksid end proovile panna. Kui alles alustate MLOps-idega AWS-i servas, vaadake MLOd äärel Amazon SageMaker Edge Manageri ja AWS IoT Greengrassiga ülevaate ja viitearhitektuuri jaoks.

Kasutusjuhtum: metallsiltide kvaliteedi kontrollimine

ML-i insenerina on oluline mõista ärijuhtumit, mille kallal töötate. Nii et enne kui sukeldume MLOps torujuhtme arhitektuuri, vaatame selle postituse näidiskasutusjuhtumit. Kujutage ette tootja tootmisliini, mis graveerib metallist silte, et luua kohandatud pagasisilte. Kvaliteedi tagamise protsess on kulukas, kuna toormetallist silte tuleb käsitsi kontrollida, et tuvastada selliseid defekte nagu kriimustused. Selle protsessi tõhusamaks muutmiseks kasutame vigaste siltide tuvastamiseks protsessi alguses ML-i. See aitab vältida kulukaid defekte tootmisprotsessi hilisemates etappides. Mudel peaks peaaegu reaalajas tuvastama võimalikud defektid, nagu kriimustused, ja need märkima. Tootmistöökodade keskkondades peate sageli tegelema ühenduvuse puudumise või piiratud ribalaiuse ja suurenenud latentsusega. Seetõttu tahame visuaalseks kvaliteedikontrolliks juurutada kaasaegse ML-lahenduse, mis võimaldab teha järeldusi kohapeal ja vähendab ühenduvusega seotud nõudeid. Et näide oleks arusaadav, koolitame välja mudeli, mis märgib tuvastatud kriimustused piirdekastidega. Järgmine pilt on näide meie andmestiku sildist, millel on kolm kriimu.

Torujuhtme arhitektuuri määratlemine

Oleme nüüdseks saanud selgust oma kasutusjuhtumis ja konkreetses ML-i probleemis, millega me püüame tegeleda ja mis keerleb objektide tuvastamise ümber servas. Nüüd on aeg koostada meie MLOps torujuhtme arhitektuur. Praeguses etapis me ei vaatle veel tehnoloogiaid ega konkreetseid teenuseid, vaid pigem meie torujuhtme kõrgetasemelisi komponente. Kiireks ümberõpetamiseks ja juurutamiseks peame automatiseerima kogu täieliku protsessi: alates andmete märgistamisest kuni väljaõppeni ja lõpetades järeldustega. Siiski on mõned väljakutsed, mis muudavad torujuhtme seadistamise äärekorpuse jaoks eriti keeruliseks:

• Selle protsessi erinevate osade loomine nõuab erinevaid oskusi. Näiteks andmete märgistamisel ja koolitusel on tugev andmeteaduse fookus, serva juurutamiseks on vaja asjade Interneti (IoT) spetsialisti ja kogu protsessi automatiseerimisega tegeleb tavaliselt keegi, kellel on DevOpsi oskuste kogum.
• Olenevalt teie organisatsioonist võib kogu seda protsessi rakendada isegi mitu meeskonda. Meie kasutusjuhtumi puhul lähtume eeldusest, et märgistamise, koolituse ja juurutamise eest vastutavad eraldi meeskonnad.
• Rohkem rolle ja oskusi tähendab erinevaid nõudeid tööriistade ja protsesside osas. Näiteks võivad andmeteadlased soovida jälgida oma tuttavat sülearvutikeskkonda ja sellega töötada. MLOps-i insenerid soovivad töötada koodi (IaC) tööriistadena infrastruktuuri ja võivad olla paremini tuttavad AWS-i juhtimiskonsool.

Mida see meie torujuhtme arhitektuuri jaoks tähendab?

Esiteks on ülioluline selgelt määratleda täieliku süsteemi peamised komponendid, mis võimaldavad erinevatel meeskondadel iseseisvalt töötada. Teiseks tuleb koostöö tõhususe suurendamiseks määratleda hästi määratletud liidesed meeskondade vahel. Need liidesed aitavad minimeerida häireid meeskondade vahel, võimaldades neil vajaduse korral oma sisemisi protsesse muuta seni, kuni nad järgivad määratletud liideseid. Järgmine diagramm illustreerib, kuidas see meie arvutinägemise torujuhtme jaoks välja näeb.

Uurime üksikasjalikult MLOps torujuhtme üldist arhitektuuri:

1. Protsess algab metallsiltide toorpiltide kogumisega, mis jäädvustatakse tootmiskeskkonnas servakaamera abil, et moodustada esialgne koolitusandmekogu.
2. Järgmine samm hõlmab nende piltide märgistamist ja defektide märgistamist piirdekastide abil. Märgistatud andmestiku versioon on oluline, tagades kasutatud treeningandmete jälgitavuse ja vastutuse.
3. Kui meil on märgistatud andmestik, saame jätkata oma mudeli koolitamist, peenhäälestamist, hindamist ja versioonide loomist.
4. Kui oleme oma mudeli jõudlusega rahul, saame mudeli juurutada servaseadmesse ja teha servas reaalajas järeldusi.
5. Kui mudel töötab tootmises, genereerib servakaamera seade väärtuslikke pildiandmeid, mis sisaldavad seninägematuid defekte ja servajuhtumeid. Saame neid andmeid kasutada oma mudeli jõudluse edasiseks parandamiseks. Selle saavutamiseks salvestame pildid, mille puhul mudel ennustab madala usaldusväärsusega või teeb ekslikke ennustusi. Seejärel lisatakse need pildid tagasi meie töötlemata andmekogumisse, käivitades kogu protsessi uuesti.

Oluline on märkida, et töötlemata pildiandmed, märgistatud andmekogum ja koolitatud mudel toimivad täpselt määratletud liidestena erinevate torujuhtmete vahel. MLOpsi inseneridel ja andmeteadlastel on paindlikkus valida tehnoloogiaid oma torujuhtmetes seni, kuni nad neid artefakte pidevalt toodavad. Kõige olulisem on see, et oleme loonud suletud tagasisideahela. Tootmises tehtud vigaseid või madala usaldusväärsusega ennustusi saab kasutada meie andmekogumi korrapäraseks täiendamiseks ning mudeli automaatseks ümberõppeks ja täiustamiseks.

Sihtarhitektuur

Nüüd, kui kõrgetasemeline arhitektuur on loodud, on aeg minna ühe taseme võrra sügavamale ja vaadata, kuidas saaksime seda AWS-i teenustega luua. Pange tähele, et selles postituses näidatud arhitektuur eeldab, et soovite kogu andmeteaduse protsessi täielikult kontrollida. Kui aga alles alustate kvaliteedikontrolliga, soovitame seda teha Amazon Lookout for Vision. See annab võimaluse koolitada oma kvaliteedikontrolli mudelit, ilma et peaksite ML-koodi koostama, hooldama või mõistma. Lisateabe saamiseks vaadake Amazon Lookout for Vision toetab nüüd toote defektide visuaalset kontrollimist servas.

Kui soovite aga täieliku kontrolli enda kätte võtta, näitab järgmine diagramm, milline võiks arhitektuur välja näha.

Sarnaselt varasemaga käime samm-sammult läbi töövoo ja selgitame välja, millised AWS-i teenused meie nõuetele vastavad:

1. Amazoni lihtne salvestusteenus (Amazon S3) kasutatakse toorpildiandmete salvestamiseks, kuna see pakub meile odavat salvestuslahendust.
2. Märgistamise töövoog juhitakse kasutades AWS-i astmefunktsioonid, serverita töövoomootor, mis muudab sildistamise töövoo etappide juhtimise lihtsaks. Selle töövoo osana kasutame Amazon SageMaker Ground Truth märgistamise täielik automatiseerimine, kasutades märgistamistöid ja juhitud inimtööjõudu. AWS Lambda kasutatakse andmete ettevalmistamiseks, märgistamistööde alustamiseks ja siltide salvestamiseks Amazon SageMakeri funktsioonipood.
3. SageMaker Feature Store salvestab sildid. See võimaldab meil keskselt hallata ja jagada oma funktsioone ning pakub meile sisseehitatud andmete versioonimisvõimalusi, mis muudab meie konveieri tugevamaks.
4. Orkestreerime mudeliehituse ja koolitustorustiku kasutades Amazon SageMakeri torujuhtmed. See integreerub muude SageMakeri funktsioonidega, mis on vajalikud sisseehitatud sammude kaudu. SageMaker Training töökohti kasutatakse mudelikoolituse automatiseerimiseks ja SageMaker Töötlemise töökohad kasutatakse andmete ettevalmistamiseks ja mudeli toimivuse hindamiseks. Selles näites kasutame Ultralytics YOLOv8 Pythoni pakett ja mudeliarhitektuur objekti tuvastamise mudeli koolitamiseks ja eksportimiseks ONNX ML mudelivorming kaasaskantavuse tagamiseks.
5. Kui jõudlus on vastuvõetav, registreeritakse koolitatud mudel Amazon SageMakeri mudeliregister millele on lisatud järkjärguline versiooninumber. See toimib meie liidesena mudelikoolituse ja serva juurutamise etappide vahel. Samuti haldame siin mudelite kinnitusolekut. Sarnaselt teistele kasutatavatele teenustele on see täielikult hallatud, nii et me ei pea oma infrastruktuuri haldamise eest hoolitsema.
6. Serva juurutamise töövoog automatiseeritakse sammufunktsioonide abil, sarnaselt sildistamise töövooga. Saame kasutada Step Functionsi API-integratsioone, et hõlpsasti kutsuda erinevaid vajalikke AWS-i teenuse API-sid, nagu AWS IoT Greengrass, et luua uusi mudelikomponente ja seejärel juurutada komponendid ääreseadmesse.
7. AWS IoT Greengrassi kasutatakse servaseadme käituskeskkonnana. See haldab meie mudeli ja järelduskomponentide juurutamise elutsüklit äärel. See võimaldab meil lihtsate API-kutsete abil hõlpsasti juurutada meie mudeli uusi versioone ja järelduskomponente. Lisaks ei tööta servas olevad ML-mudelid tavaliselt eraldi; saame kasutada erinevaid AWS ja kogukond pakuti AWS IoT Greengrassi komponente teiste teenustega ühenduse loomiseks.

Väljatoodud arhitektuur sarnaneb meie varem näidatud kõrgetasemelise arhitektuuriga. Amazon S3, SageMaker Feature Store ja SageMaker Model Registry toimivad liidestena erinevate torujuhtmete vahel. Lahenduse käitamiseks ja käitamiseks kuluvate pingutuste minimeerimiseks kasutame võimaluse korral hallatud ja serverita teenuseid.

Ühinemine tugevaks CI/CD süsteemiks

Andmete märgistamine, mudeli koolitus ja serva juurutamise etapid on meie lahenduse keskmes. Sellisena peaksid kõik muudatused, mis on seotud nende osade aluseks oleva koodi või andmetega, käivitama kogu orkestreerimisprotsessi uue käigu. Selle saavutamiseks peame integreerima selle torujuhtme CI/CD süsteemi, mis võimaldab meil automaatselt juurutada koodi ja infrastruktuuri muudatused versioonide koodihoidlast tootmisse. Sarnaselt eelmisele arhitektuurile on siin oluline aspekt meeskonna autonoomia. Järgmine diagramm näitab, kuidas see AWS-i teenuseid kasutades välja näeb.

Vaatame läbi CI/CD arhitektuuri:

1. AWS CodeCommit toimib meie Giti hoidlana. Lihtsuse huvides eraldasime meie esitatud proovis erinevad osad (märgistamine, mudeli koolitus, serva juurutamine) alamkaustade kaudu ühes git-hoidlas. Reaalse stsenaariumi korral võib iga meeskond kasutada iga osa jaoks erinevaid hoidlaid.
2. Infrastruktuuri juurutamine automatiseeritakse AWS CDK abil ja iga osa (märgistus, koolitus ja serv) saab iseseisva juurutamise võimaldamiseks oma AWS CDK rakenduse.
3. AWS CDK torujuhtme funktsioon kasutab AWS CodePipeline infrastruktuuri ja koodi juurutamise automatiseerimiseks.
4. AWS CDK juurutab iga etapi jaoks kaks koodikonveieri: varade konveier ja töövoo konveier. Eraldasime töövoo vara juurutamisest, et saaksime töövooge eraldi käivitada juhuks, kui vara muudatusi ei toimu (näiteks kui koolituseks on saadaval uued pildid).
   • Varakoodide konveier juurutab kogu töövoo edukaks toimimiseks vajaliku infrastruktuuri, näiteks AWS-i identiteedi- ja juurdepääsuhaldus (IAM) rollid, lambda funktsioonid ja treeningu ajal kasutatavad konteineri kujutised.
   • Töövoo koodikonveier käivitab tegeliku sildistamise, koolituse või serva juurutamise töövoo.
5. Varade konveierid käivitatakse automaatselt nii kinnitamisel kui ka siis, kui eelmine töövoo konveier on valmis.
6. Kogu protsess käivitatakse ajakava alusel, kasutades Amazon EventBridge regulaarse ümberõppe reegel.

CI/CD integratsiooniga on kogu otsast lõpuni ahel nüüd täielikult automatiseeritud. Konveier käivitub alati, kui kood meie git-hoidlas muutub, samuti ajakava alusel, et kohaneda andmete muudatustega.

Ette mõeldes

Kirjeldatud lahenduse arhitektuur esindab põhikomponente MLOps-i ots-otsa torujuhtme ehitamiseks servas. Sõltuvalt teie vajadustest võiksite siiski mõelda täiendavate funktsioonide lisamisele. Siin on mõned näited.

Järeldus

Selles postituses kirjeldasime oma arhitektuuri otsast lõpuni MLOps torujuhtme ehitamiseks visuaalseks kvaliteedikontrolliks servas, kasutades AWS-i teenuseid. See arhitektuur muudab kogu protsessi sujuvamaks, hõlmates andmete märgistamist, mudelite arendamist ja servade juurutamist, võimaldades meil kiiresti ja usaldusväärselt koolitada ja rakendada mudeli uusi versioone. Serverita ja hallatavate teenuste abil saame suunata oma fookuse pigem äriväärtuse pakkumisele kui infrastruktuuri haldamisele.

In Osa 2 Selle seeria osas süveneme ühe taseme võrra sügavamale ja vaatame üksikasjalikumalt selle arhitektuuri rakendamist, täpsemalt märgistamist ja mudelite ehitamist. Kui soovite otse koodi juurde hüpata, saate vaadata kaasasolevat GitHub repo.

---

Autoritest

Michael Roth on AWS-i vanemlahenduste arhitekt, kes toetab Saksamaa tootmiskliente nende äriprobleemide lahendamisel AWS-tehnoloogia abil. Lisaks tööle ja perele on ta huvitatud sportautodest ja naudib Itaalia kohvi.

Jörg Wöhrle on AWS-i lahenduste arhitekt, kes töötab tootmisklientidega Saksamaal. Kirglikult automatiseerimise vastu on Joerg oma AWS-i-eelses elus töötanud tarkvaraarendaja, DevOpsi insenerina ja saidi töökindluse insenerina. Lisaks pilvedele on ta ambitsioonikas jooksja ja naudib perega kvaliteetaega. Nii et kui teil on DevOpsi väljakutse või soovite jooksma minna, andke talle teada.

Johannes Langer on AWS-i vanemlahenduste arhitekt, kes töötab äriklientidega Saksamaal. Johannes on kirglik masinõppe rakendamise vastu tõeliste äriprobleemide lahendamiseks. Isiklikus elus meeldib Johannesele koduparandusprojektidega tegelemine ja perega õues viibimine.

• SEO-põhise sisu ja PR-levi. Võimenduge juba täna.
• PlatoData.Network Vertikaalne generatiivne Ai. Jõustage ennast. Juurdepääs siia.
• PlatoAiStream. Web3 luure. Täiustatud teadmised. Juurdepääs siia.
• PlatoESG. Süsinik, CleanTech, Energia, Keskkond päikeseenergia, Jäätmekäitluse. Juurdepääs siia.
• PlatoTervis. Biotehnoloogia ja kliiniliste uuringute luureandmed. Juurdepääs siia.
• Allikas: https://aws.amazon.com/blogs/machine-learning/build-an-end-to-end-mlops-pipeline-for-visual-quality-inspection-at-the-edge-part-1/