Zgradite cevovod MLOps od konca do konca za vizualno kontrolo kakovosti na robu – 1. del | Spletne storitve Amazon

Uspešna uvedba modela strojnega učenja (ML) v produkcijskem okolju je močno odvisna od cevovoda ML od konca do konca. Čeprav je razvoj takšnega plinovoda lahko izziv, postane še bolj zapleten, če imamo opravka z primer uporabe edge ML. Strojno učenje na robu je koncept, ki prinaša zmožnost lokalnega izvajanja modelov ML na robnih napravah. Za uvajanje, spremljanje in vzdrževanje teh modelov na robu je potreben robusten cevovod MLOps. Cevovod MLOps omogoča avtomatizacijo celotnega življenjskega cikla ML od označevanja podatkov do usposabljanja in uvajanja modela.

Implementacija cevovoda MLOps na robu uvaja dodatne zapletenosti, zaradi katerih so procesi avtomatizacije, integracije in vzdrževanja bolj zahtevni zaradi povečanih operativnih stroškov. Vendar pa uporaba namensko izdelanih storitev, kot je Amazon SageMaker in AWS IoT Zelena trava omogoča znatno zmanjšanje tega napora. V tej seriji vas vodimo skozi proces arhitektiranja in gradnje integriranega cevovoda MLOps od konca do konca za primer uporabe računalniškega vida na robu z uporabo SageMaker, AWS IoT Greengrass in Komplet za razvoj oblaka AWS (AWS CDK).

Ta objava se osredotoča na oblikovanje celotne arhitekture cevovoda MLOps; Del 2 in Del 3 te serije se osredotočajo na izvajanje posameznih komponent. V prilogi smo zagotovili vzorčno izvedbo GitHub repozitorij da se sam preizkusiš. Če šele začenjate z MLOps na robu v AWS, glejte MLOps na robu z Amazon SageMaker Edge Manager in AWS IoT Greengrass za pregled in referenčno arhitekturo.

Primer uporabe: Pregled kakovosti kovinskih oznak

Kot inženir ML je pomembno, da razumete poslovni primer, na katerem delate. Preden se torej poglobimo v arhitekturo cevovoda MLOps, si poglejmo vzorčni primer uporabe za to objavo. Predstavljajte si proizvodno linijo proizvajalca, ki gravira kovinske oznake, da ustvari prilagojene oznake za prtljago. Postopek zagotavljanja kakovosti je drag, ker je treba oznake iz surove kovine ročno pregledati glede napak, kot so praske. Da bi bil ta postopek učinkovitejši, uporabljamo ML za odkrivanje napačnih oznak zgodaj v procesu. To pomaga preprečiti drage napake v kasnejših fazah proizvodnega procesa. Model mora skoraj v realnem času identificirati možne napake, kot so praske, in jih označiti. V okoljih proizvodnih delavnic se pogosto soočate z odsotnostjo povezljivosti ali omejeno pasovno širino in povečano zakasnitvijo. Zato želimo implementirati rešitev ML na robu za vizualno kontrolo kakovosti, ki lahko izvede sklepanje lokalno v delavnici in zmanjša zahteve glede povezljivosti. Da bo naš primer enostaven, urimo model, ki zaznane praske označuje z omejevalnimi okvirčki. Naslednja slika je primer oznake iz našega nabora podatkov s tremi označenimi praskami.

Definiranje arhitekture cevovoda

Zdaj smo razjasnili naš primer uporabe in specifično težavo ML, ki jo želimo obravnavati in se vrti okoli zaznavanja predmetov na robu. Zdaj je čas, da pripravimo arhitekturo za naš cevovod MLOps. Na tej stopnji še ne gledamo na tehnologije ali posebne storitve, temveč na komponente našega cevovoda na visoki ravni. Za hitro preusposabljanje in uvajanje moramo avtomatizirati celoten proces od konca do konca: od označevanja podatkov do usposabljanja in sklepanja. Vendar pa obstaja nekaj izzivov, zaradi katerih je vzpostavitev cevovoda za robni primer še posebej težka:

• Gradnja različnih delov tega procesa zahteva različne sklope spretnosti. Na primer, označevanje podatkov in usposabljanje imata močan poudarek na podatkovni znanosti, robna uvedba zahteva strokovnjaka za internet stvari (IoT), avtomatizacijo celotnega procesa pa običajno izvaja nekdo z naborom spretnosti DevOps.
• Odvisno od vaše organizacije lahko celoten postopek izvaja več skupin. Za naš primer uporabe delamo ob predpostavki, da so ločene ekipe odgovorne za označevanje, usposabljanje in uvajanje.
• Več vlog in sklopov spretnosti pomeni različne zahteve, ko gre za orodja in procese. Podatkovni znanstveniki bi na primer morda želeli spremljati svoje znano okolje prenosnih računalnikov in delati z njim. Inženirji MLOps želijo delati z uporabo orodij za infrastrukturo kot kodo (IaC) in morda bolje poznajo Konzola za upravljanje AWS.

Kaj to pomeni za našo arhitekturo cevovoda?

Prvič, ključno je jasno opredeliti glavne komponente sistema od konca do konca, ki omogoča neodvisno delo različnih ekip. Drugič, za izboljšanje učinkovitosti sodelovanja je treba določiti dobro definirane vmesnike med ekipami. Ti vmesniki pomagajo zmanjšati motnje med ekipami in jim omogočajo, da po potrebi spremenijo svoje notranje procese, če se držijo definiranih vmesnikov. Naslednji diagram prikazuje, kako bi to lahko izgledalo za naš cevovod računalniškega vida.

Oglejmo si podrobno celotno arhitekturo cevovoda MLOps:

1. Postopek se začne z zbiranjem neobdelanih slik kovinskih oznak, ki so zajete z uporabo robne kamere v produkcijskem okolju, da se oblikuje začetni nabor podatkov za usposabljanje.
2. Naslednji korak vključuje označevanje teh slik in označevanje napak z uporabo omejevalnih okvirjev. Bistveno je, da različico označenega nabora podatkov zagotovite sledljivost in odgovornost za uporabljene podatke o usposabljanju.
3. Ko imamo označen nabor podatkov, lahko nadaljujemo z usposabljanjem, finim prilagajanjem, ocenjevanjem in različico našega modela.
4. Ko smo zadovoljni z zmogljivostjo našega modela, lahko model namestimo na robno napravo in izvajamo sklepanje v živo na robu.
5. Medtem ko model deluje v proizvodnji, naprava robne kamere ustvarja dragocene slikovne podatke, ki vsebujejo prej nevidne napake in robove. Te podatke lahko uporabimo za nadaljnje izboljšanje delovanja našega modela. Da bi to dosegli, shranimo slike, za katere model napoveduje z nizko stopnjo zaupanja ali daje napačne napovedi. Te slike se nato dodajo nazaj v naš nabor neobdelanih podatkov, s čimer se znova sproži celoten postopek.

Pomembno je omeniti, da neobdelani slikovni podatki, označeni nabor podatkov in usposobljeni model služijo kot dobro definirani vmesniki med različnimi cevovodi. Inženirji MLOps in podatkovni znanstveniki imajo prožnost pri izbiri tehnologij v svojih cevovodih, če dosledno proizvajajo te artefakte. Najpomembneje je, da smo vzpostavili zaprto povratno zanko. Napačne napovedi ali napovedi z nizko stopnjo zaupanja, narejene v proizvodnji, se lahko uporabljajo za redno dopolnjevanje našega nabora podatkov ter samodejno ponovno usposabljanje in izboljšanje modela.

Ciljna arhitektura

Zdaj, ko je arhitektura na visoki ravni vzpostavljena, je čas, da gremo eno raven globlje in pogledamo, kako bi to lahko zgradili s storitvami AWS. Upoštevajte, da arhitektura, prikazana v tej objavi, predvideva, da želite prevzeti popoln nadzor nad celotnim procesom podatkovne znanosti. Vendar, če šele začenjate s pregledom kakovosti na robu, priporočamo Amazon Lookout for Vision. Zagotavlja način za usposabljanje lastnega modela nadzora kakovosti, ne da bi vam bilo treba graditi, vzdrževati ali razumeti kodo ML. Za več informacij glejte Amazon Lookout for Vision zdaj podpira vizualni pregled napak izdelka na robu.

Če pa želite prevzeti popoln nadzor, naslednji diagram prikazuje, kako bi lahko izgledala arhitektura.

Podobno kot prej se korak za korakom sprehodimo skozi potek dela in ugotovimo, katere storitve AWS ustrezajo našim zahtevam:

1. Preprosta storitev shranjevanja Amazon (Amazon S3) se uporablja za shranjevanje neobdelanih slikovnih podatkov, ker nam ponuja poceni rešitev za shranjevanje.
2. Potek dela označevanja je orkestriran z uporabo Korak funkcije AWS, mehanizem delovnega toka brez strežnika, ki olajša orkestriranje korakov delovnega toka označevanja. Kot del tega poteka dela uporabljamo Amazon SageMaker Ground Truth za popolno avtomatizacijo označevanja z uporabo označevalnih opravil in upravljane človeške delovne sile. AWS Lambda se uporablja za pripravo podatkov, začetek opravil označevanja in shranjevanje nalepk Trgovina s funkcijami Amazon SageMaker.
3. SageMaker Feature Store shrani oznake. Omogoča nam centralno upravljanje in skupno rabo naših funkcij ter nam nudi vgrajene zmogljivosti za različico podatkov, zaradi česar je naš cevovod bolj robusten.
4. Usmerjamo gradnjo modela in uporabo cevovoda za usposabljanje Amazonski cevovodi SageMaker. Integrira se z drugimi potrebnimi funkcijami SageMaker prek vgrajenih korakov. Zaposlitve za usposabljanje SageMaker se uporabljajo za avtomatizacijo usposabljanja modela in Opravila obdelave SageMaker se uporabljajo za pripravo podatkov in ovrednotenje delovanja modela. V tem primeru uporabljamo Ultralytics YOLOv8 Paket Python in arhitektura modela za usposabljanje in izvoz modela zaznavanja objektov v ONNX Format modela ML za prenosljivost.
5. Če je zmogljivost sprejemljiva, je usposobljeni model registriran v Register modelov Amazon SageMaker s priloženo inkrementalno številko različice. Deluje kot naš vmesnik med koraki usposabljanja modela in robne uvedbe. Tukaj upravljamo tudi stanje odobritve modelov. Podobno kot ostale uporabljene storitve je v celoti upravljana, zato nam ni treba skrbeti za vodenje lastne infrastrukture.
6. Delovni tok uvajanja robov je avtomatiziran z uporabo funkcij korakov, podobno kot delovni tok označevanja. Integracije API-jev funkcij Step Functions lahko uporabimo za enostavno klicanje različnih zahtevanih API-jev storitev AWS, kot je AWS IoT Greengrass, za ustvarjanje novih komponent modela in zatem razmestitev komponent v robno napravo.
7. AWS IoT Greengrass se uporablja kot okolje za izvajanje robnih naprav. Upravlja življenjski cikel uvajanja za naš model in komponente sklepanja na robu. Omogoča nam preprosto uvajanje novih različic našega modela in komponent sklepanja z uporabo preprostih klicev API-ja. Poleg tega modeli ML na robu običajno ne delujejo ločeno; lahko uporabimo različne AWS in skupnost zagotovil komponente AWS IoT Greengrass za povezovanje z drugimi storitvami.

Opisana arhitektura je podobna naši arhitekturi na visoki ravni, prikazani prej. Amazon S3, SageMaker Feature Store in SageMaker Model Registry delujejo kot vmesniki med različnimi cevovodi. Da bi čim bolj zmanjšali napor pri izvajanju in upravljanju rešitve, uporabljamo upravljane storitve in storitve brez strežnika, kjer koli je to mogoče.

Združitev v robusten sistem CI/CD

Označevanje podatkov, usposabljanje modela in koraki uvajanja robov so jedro naše rešitve. Kot taka bi morala vsaka sprememba, povezana z osnovno kodo ali podatki v katerem koli od teh delov, sprožiti nov zagon celotnega procesa orkestracije. Da bi to dosegli, moramo ta cevovod integrirati v sistem CI/CD, ki nam omogoča samodejno uvajanje kode in infrastrukturnih sprememb iz repozitorija kode z različicami v produkcijo. Podobno kot pri prejšnji arhitekturi je tu avtonomija ekipe pomemben vidik. Naslednji diagram prikazuje, kako bi to lahko izgledalo z uporabo storitev AWS.

Sprehodimo se skozi arhitekturo CI/CD:

1. AWS CodeCommit deluje kot naše Git repozitorij. Zaradi enostavnosti smo v našem predloženem vzorcu ločene dele (označevanje, usposabljanje modela, razmeščanje robov) ločili prek podmap v enem samem repozitoriju git. V resničnem scenariju lahko vsaka ekipa uporablja drugačna skladišča za vsak del.
2. Uvajanje infrastrukture je avtomatizirano z uporabo AWS CDK in vsak del (označevanje, usposabljanje in rob) dobi lastno aplikacijo AWS CDK, ki omogoča neodvisne uvedbe.
3. Funkcija cevovoda AWS CDK uporablja AWS CodePipeline za avtomatizacijo uvajanja infrastrukture in kode.
4. AWS CDK uvede dva cevovoda kode za vsak korak: cevovod sredstev in cevovod poteka dela. Delovni tok smo ločili od uvajanja sredstev, da lahko ločeno začnemo delovne tokove v primeru, da ni sprememb sredstev (na primer, ko so na voljo nove slike za usposabljanje).
   • Cevovod kode sredstva razmesti vso infrastrukturo, ki je potrebna za uspešno delovanje delovnega toka, kot npr AWS upravljanje identitete in dostopa (IAM), funkcije Lambda in slike vsebnika, uporabljene med usposabljanjem.
   • Cevovod kode delovnega toka izvaja dejanski delovni tok označevanja, usposabljanja ali uvajanja robov.
5. Cevovodi sredstev se samodejno sprožijo ob potrditvi in ​​tudi, ko je prejšnji cevovod poteka dela končan.
6. Celoten postopek se sproži po urniku z uporabo Amazon EventBridge pravilo za redno prekvalifikacijo.

Z integracijo CI/CD je celotna veriga od konca do konca zdaj popolnoma avtomatizirana. Cevovod se sproži vsakič, ko se koda spremeni v našem repozitoriju git, kot tudi po urniku, da se prilagodi spremembam podatkov.

Razmišljanje vnaprej

Opisana arhitektura rešitve predstavlja osnovne komponente za izgradnjo cevovoda MLOps od konca do konca na robu. Vendar pa lahko glede na vaše zahteve razmislite o dodajanju dodatnih funkcij. Sledi nekaj primerov:

zaključek

V tej objavi smo orisali našo arhitekturo za izgradnjo cevovoda MLOps od konca do konca za vizualni pregled kakovosti na robu z uporabo storitev AWS. Ta arhitektura poenostavi celoten proces, ki vključuje označevanje podatkov, razvoj modela in uvajanje robov, kar nam omogoča hitro in zanesljivo usposabljanje in implementacijo novih različic modela. Z brezstrežniškimi in upravljanimi storitvami se lahko osredotočimo na zagotavljanje poslovne vrednosti in ne na upravljanje infrastrukture.

In Del 2 v tej seriji se bomo poglobili še eno raven in si podrobneje ogledali izvedbo te arhitekture, zlasti označevanje in gradnjo modela. Če želite skočiti naravnost na kodo, si lahko ogledate priloženo GitHub repo.

---

O avtorjih

Michael Roth je višji arhitekt rešitev pri AWS, ki podpira proizvodne stranke v Nemčiji pri reševanju njihovih poslovnih izzivov s tehnologijo AWS. Poleg službe in družine ga zanimajo športni avtomobili in uživa v italijanski kavi.

Jörg Wöhrle je arhitekt rešitev pri AWS, ki dela s strankami iz proizvodnje v Nemčiji. S strastjo do avtomatizacije je Joerg v svojem življenju pred AWS delal kot razvijalec programske opreme, inženir DevOps in inženir zanesljivosti spletnega mesta. Onstran oblaka je ambiciozen tekač in uživa v kakovostnem času s svojo družino. Torej, če imate izziv DevOps ali želite iti na tek: povejte mu.

Johannes Langer je višji arhitekt rešitev pri AWS, ki dela s podjetniškimi strankami v Nemčiji. Johannes se navdušuje nad uporabo strojnega učenja za reševanje resničnih poslovnih problemov. V svojem zasebnem življenju Johannes uživa v delu na projektih izboljšav doma in preživlja čas na prostem s svojo družino.

• Distribucija vsebine in PR s pomočjo SEO. Okrepite se še danes.
• PlatoData.Network Vertical Generative Ai. Opolnomočite se. Dostopite tukaj.
• PlatoAiStream. Web3 Intelligence. Razširjeno znanje. Dostopite tukaj.
• PlatoESG. Ogljik, CleanTech, Energija, Okolje, sončna energija, Ravnanje z odpadki. Dostopite tukaj.
• PlatoHealth. Obveščanje o biotehnologiji in kliničnih preskušanjih. Dostopite tukaj.
• vir: https://aws.amazon.com/blogs/machine-learning/build-an-end-to-end-mlops-pipeline-for-visual-quality-inspection-at-the-edge-part-1/