Rakenna päästä päähän MLOps-putkisto visuaalista laaduntarkastusta varten reunassa – Osa 1 | Amazon Web Services

Koneoppimismallin (ML) onnistunut käyttöönotto tuotantoympäristössä on vahvasti riippuvainen päästä päähän ML-putkilinjaan. Vaikka tällaisen putkilinjan kehittäminen voi olla haastavaa, siitä tulee vieläkin monimutkaisempi, kun käsitellään edge ML -käyttötapaus. Koneoppiminen reunalla on konsepti, joka tuo mahdollisuuden ajaa ML-malleja paikallisesti reunalaitteisiin. Näiden mallien ottamiseksi käyttöön, valvomiseksi ja ylläpitämiseksi reunalla tarvitaan vankka MLOps-putkisto. MLOps-putki mahdollistaa koko ML-elinkaarin automatisoinnin datamerkinnöistä mallin koulutukseen ja käyttöönottoon.

MLOps-putkilinjan toteuttaminen reunassa lisää monimutkaisia ​​tekijöitä, jotka tekevät automaatio-, integraatio- ja ylläpitoprosesseista haastavampia lisääntyneiden käyttökustannusten vuoksi. Kuitenkin käyttämällä tarkoitukseen rakennettuja palveluita, kuten Amazon Sage Maker ja AWS IoT Vihreä ruoho voit vähentää merkittävästi tätä vaivaa. Tässä sarjassa opastamme sinut läpi integroidun päästä päähän MLOps-putkilinjan suunnittelun ja rakentamisen tietokonenäön käyttötapaukselle reunassa käyttämällä SageMakeria, AWS IoT Greengrassia ja AWS Cloud Development Kit (AWS CDK).

Tämä viesti keskittyy MLOps-putkiarkkitehtuurin suunnitteluun; Osa 2 ja Osa 3 tässä sarjassa keskitytään yksittäisten komponenttien toteuttamiseen. Olemme toimittaneet esimerkkitoteutuksen mukana GitHub-arkisto jotta voit kokeilla itseäsi. Jos olet vasta aloittamassa MLOpsin käyttöä AWS:n reunalla, katso MLOs reunassa Amazon SageMaker Edge Managerin ja AWS IoT Greengrassin avulla yleiskatsauksen ja referenssiarkkitehtuuria varten.

Käyttötapaus: Metallilappujen laadun tarkastus

ML-insinöörinä on tärkeää ymmärtää, minkä parissa työskentelet. Joten ennen kuin sukeltaamme MLOps-putkiarkkitehtuuriin, katsotaanpa tämän viestin esimerkkikäyttötapausta. Kuvittele valmistajan tuotantolinja, joka kaivertaa metallilaput luodakseen räätälöityjä matkatavaralappuja. Laadunvarmistusprosessi on kallis, koska raakametallimerkinnät on tarkastettava manuaalisesti vikojen, kuten naarmujen, varalta. Prosessin tehostamiseksi käytämme ML:ää viallisten tunnisteiden havaitsemiseen prosessin varhaisessa vaiheessa. Tämä auttaa välttämään kalliita vikoja tuotantoprosessin myöhemmissä vaiheissa. Mallin tulee tunnistaa mahdolliset viat, kuten naarmut, lähes reaaliajassa ja merkitä ne. Valmistustyöpajaympäristöissä joudut usein käsittelemään yhteyksien puuttumista tai rajoitettua kaistanleveyttä ja lisääntynyttä latenssia. Siksi haluamme ottaa käyttöön huippuluokan ML-ratkaisun visuaaliseen laaduntarkastukseen, joka voi tehdä päätelmiä paikallisesti myymälässä ja vähentää liitettävyyden vaatimuksia. Jotta esimerkkimme olisi selkeä, koulutamme mallin, joka merkitsee havaitut naarmut rajauslaatikoilla. Seuraava kuva on esimerkki tietojoukostamme kuuluvasta tunnisteesta, jossa on kolme naarmua.

Putkilinja-arkkitehtuurin määrittely

Olemme nyt saaneet selvyyttä käyttötapaukseemme ja erityiseen ML-ongelmaan, jota pyrimme ratkaisemaan ja joka pyörii kohteen havaitsemisen ympärillä. Nyt on aika laatia arkkitehtuuri MLOps-putkilinjallemme. Tässä vaiheessa emme vielä tarkastele teknologioita tai erityisiä palveluita, vaan putkilinjamme korkean tason komponentteja. Jotta voimme kouluttaa uudelleen ja ottaa käyttöön nopeasti, meidän on automatisoitava koko päästä päähän -prosessi: tietojen merkitsemisestä koulutukseen ja päättelyyn. On kuitenkin olemassa muutamia haasteita, jotka tekevät putkilinjan määrittämisestä reunakoteloa varten erityisen vaikeaa:

• Tämän prosessin eri osien rakentaminen vaatii erilaisia ​​taitoja. Esimerkiksi tietojen merkitsemisessä ja koulutuksessa on vahva datatieteellinen painopiste, reunan käyttöönotto vaatii Internet of Things (IoT) -asiantuntijan ja koko prosessin automatisoinnin tekee yleensä joku, jolla on DevOps-taidot.
• Organisaatiostasi riippuen koko prosessi voidaan toteuttaa jopa useiden tiimien toimesta. Käyttötapauksessamme työskentelemme olettaen, että erilliset tiimit vastaavat merkinnöistä, koulutuksesta ja käyttöönotosta.
• Lisää rooleja ja osaamiskokonaisuuksia merkitsee erilaisia ​​vaatimuksia työkaluille ja prosesseille. Esimerkiksi datatieteilijät saattavat haluta seurata ja työskennellä tutun kannettavan ympäristön kanssa. MLOps-insinöörit haluavat työskennellä käyttämällä infrastruktuuria koodityökaluina (IaC) ja saattavat tuntea paremmin AWS-hallintakonsoli.

Mitä tämä tarkoittaa putkiarkkitehtuurimme kannalta?

Ensinnäkin on ratkaisevan tärkeää määritellä selkeästi päästä päähän -järjestelmän tärkeimmät osat, jotta eri tiimit voivat työskennellä itsenäisesti. Toiseksi on määriteltävä hyvin määritellyt rajapinnat tiimien välille yhteistyön tehostamiseksi. Nämä rajapinnat auttavat minimoimaan ryhmien välisiä häiriöitä, jolloin ne voivat muokata sisäisiä prosessejaan tarpeen mukaan, kunhan ne noudattavat määritettyjä rajapintoja. Seuraava kaavio havainnollistaa, miltä tämä voisi näyttää tietokonenäköputkistossamme.

Tarkastellaan MLOps-putkilinjan yleistä arkkitehtuuria yksityiskohtaisesti:

1. Prosessi alkaa kokoelmalla raakakuvia metallitunnisteista, jotka on otettu reunakameralaitteella tuotantoympäristössä alustavan harjoitustietojoukon muodostamiseksi.
2. Seuraava vaihe sisältää näiden kuvien merkitsemisen ja virheiden merkitsemisen rajauslaatikoilla. On välttämätöntä versioida merkitty tietojoukko, mikä varmistaa käytetyn harjoitustiedon jäljitettävyyden ja vastuullisuuden.
3. Kun meillä on merkitty tietojoukko, voimme jatkaa mallin koulutusta, hienosäätöä, arviointia ja versioimista.
4. Kun olemme tyytyväisiä mallimme suorituskykyyn, voimme ottaa mallin käyttöön reunalaitteella ja suorittaa reaaliaikaisia ​​päätelmiä reunalla.
5. Kun malli toimii tuotannossa, reunakameralaite tuottaa arvokasta kuvadataa, joka sisältää ennen näkemättömiä vikoja ja reunatapauksia. Voimme käyttää näitä tietoja mallimme suorituskyvyn parantamiseen. Tämän saavuttamiseksi tallennamme kuvia, joille malli ennustaa huonolla varmuudella tai tekee virheellisiä ennusteita. Nämä kuvat lisätään sitten takaisin raakatietojoukkoomme, jolloin koko prosessi käynnistetään uudelleen.

On tärkeää huomata, että raakakuvadata, merkitty tietojoukko ja koulutettu malli toimivat hyvin määriteltyinä liitäntöinä erillisten liukuputkien välillä. MLOpsin insinööreillä ja datatieteilijöillä on joustavuus valita teknologiansa, kunhan he tuottavat jatkuvasti näitä artefakteja. Mikä tärkeintä, olemme luoneet suljetun palautesilmukan. Tuotannossa tehtyjä virheellisiä tai heikosti luotettavia ennusteita voidaan käyttää tietojoukkomme säännöllisesti täydentämiseen ja mallin automaattiseen uudelleenkouluttamiseen ja parantamiseen.

Kohdearkkitehtuuri

Nyt kun korkean tason arkkitehtuuri on vakiintunut, on aika mennä tasoa syvemmälle ja katsoa, ​​kuinka voisimme rakentaa tämän AWS-palveluilla. Huomaa, että tässä viestissä näkyvä arkkitehtuuri olettaa, että haluat hallita koko datatieteen prosessia. Suosittelemme kuitenkin, että olet vasta aloittamassa laaduntarkastusta reunalla Amazon Lookout for Vision. Se tarjoaa tavan kouluttaa omaa laaduntarkastusmalliasi ilman, että sinun tarvitsee rakentaa, ylläpitää tai ymmärtää ML-koodia. Lisätietoja on kohdassa Amazon Lookout for Vision tukee nyt tuotevirheiden visuaalista tarkastusta reunassa.

Jos kuitenkin haluat ottaa täyden hallinnan, seuraava kaavio näyttää, miltä arkkitehtuuri voisi näyttää.

Kuten aiemmin, käydään läpi työnkulku vaihe vaiheelta ja selvitetään, mitkä AWS-palvelut sopivat vaatimuksiimme:

1. Amazonin yksinkertainen tallennuspalvelu (Amazon S3) käytetään raakakuvatietojen tallentamiseen, koska se tarjoaa meille edullisen tallennusratkaisun.
2. Merkintätyönkulku on ohjattu käyttämällä AWS-vaihetoiminnot, palvelimeton työnkulkumoottori, jonka avulla on helppo organisoida merkintätyönkulun vaiheet. Osana tätä työnkulkua käytämme Amazon SageMaker Ground Totuus automatisoida merkinnät täysin käyttämällä merkintätöitä ja ohjattua ihmistyövoimaa. AWS Lambda käytetään tietojen valmisteluun, merkintätöiden aloittamiseen ja tarrojen tallentamiseen Amazon SageMaker -ominaisuuskauppa.
3. SageMaker Feature Store tallentaa tarrat. Sen avulla voimme hallita ja jakaa ominaisuuksiamme keskitetysti, ja se tarjoaa meille sisäänrakennetut tietojen versiointiominaisuudet, mikä tekee putkistostamme kestävämmän.
4. Suunnittelemme mallinrakennus- ja koulutusputkien avulla Amazon SageMaker -putkistot. Se integroituu muiden vaadittavien SageMaker-ominaisuuksien kanssa sisäänrakennettujen vaiheiden kautta. SageMaker Training työpaikan käytetään automatisoimaan mallin koulutusta ja SageMaker Processing työpaikan käytetään tietojen valmisteluun ja mallin suorituskyvyn arvioimiseen. Tässä esimerkissä käytämme Ultralytics YOLOv8 Python-paketti ja malliarkkitehtuuri kohteen tunnistusmallin kouluttamiseen ja viemiseen ONNX ML-mallin muoto siirrettävyyttä varten.
5. Jos suorituskyky on hyväksyttävä, koulutettu malli rekisteröidään Amazon SageMaker -mallirekisteri johon on liitetty asteittainen versionumero. Se toimii rajapintana mallikoulutuksen ja reunan käyttöönottovaiheiden välillä. Hallitsemme myös mallien hyväksyntätilan täällä. Kuten muutkin käytetyt palvelut, se on täysin hallittavissa, joten meidän ei tarvitse huolehtia oman infrastruktuurimme ylläpidosta.
6. Reunan käyttöönoton työnkulku automatisoidaan Step Functions -toiminnolla, joka on samanlainen kuin merkintätyönkulku. Voimme käyttää Step Functionsin API-integraatioita kutsuaksemme helposti erilaisia ​​tarvittavia AWS-palvelusovellusliittymiä, kuten AWS IoT Greengrass, luodaksemme uusia mallikomponentteja ja ottaaksesi komponentit käyttöön reunalaitteeseen.
7. AWS IoT Greengrassia käytetään reunalaitteiden ajonaikaisena ympäristönä. Se hallitsee mallimme ja päättelykomponenttien käyttöönoton elinkaarta reunalla. Sen avulla voimme helposti ottaa käyttöön uusia versioita mallistamme ja päättelykomponenteistamme yksinkertaisten API-kutsujen avulla. Lisäksi reunassa olevat ML-mallit eivät yleensä toimi erillään; voimme käyttää erilaisia AWS ja yhteisö toimitti AWS IoT Greengrassin komponentteja muodostaakseen yhteyden muihin palveluihin.

Esitetty arkkitehtuuri muistuttaa korkean tason arkkitehtuuriamme aiemmin. Amazon S3, SageMaker Feature Store ja SageMaker Model Registry toimivat rajapinnoina eri putkien välillä. Minimoidaksemme ponnisteluja ratkaisun käyttämiseen ja käyttämiseen käytämme hallittuja ja palvelimettomia palveluita aina kun mahdollista.

Yhdistetään vahvaksi CI/CD-järjestelmäksi

Tietojen merkitseminen, mallikoulutus ja reunan käyttöönottovaiheet ovat ratkaisumme ydin. Sellaisenaan kaikki taustalla olevaan koodiin tai tietoihin liittyvät muutokset missä tahansa näistä osista käynnistävät koko orkestrointiprosessin uuden ajon. Tämän saavuttamiseksi meidän on integroitava tämä putki CI/CD-järjestelmään, jonka avulla voimme automaattisesti ottaa käyttöön koodin ja infrastruktuurin muutokset versioidusta koodivarastosta tuotantoon. Kuten edellisessä arkkitehtuurissa, tiimin autonomia on tärkeä näkökohta tässä. Seuraava kaavio näyttää, miltä tämä voisi näyttää AWS-palveluita käytettäessä.

Käydään läpi CI/CD-arkkitehtuuri:

1. AWS CodeCommit toimii Git-tietovarastona. Yksinkertaisuuden vuoksi erotimme toimitetussa näytteessämme erilliset osat (merkinnät, mallin koulutus, reunan käyttöönotto) alikansioiden kautta yhdessä git-varastossa. Todellisessa skenaariossa kukin tiimi saattaa käyttää eri arkistot kullekin osalle.
2. Infrastruktuurin käyttöönotto automatisoidaan AWS CDK:n avulla, ja jokainen osa (merkintä, koulutus ja reuna) saa oman AWS CDK -sovelluksensa, joka mahdollistaa itsenäisen käyttöönoton.
3. AWS CDK -liukuhihnaominaisuus käyttää AWS-koodiputki automatisoida infrastruktuuria ja koodin käyttöönottoa.
4. AWS CDK ottaa käyttöön kaksi koodiliukuhihnaa kutakin vaihetta varten: resurssien liukuhihnan ja työnkulkuprosessin. Erotimme työnkulun resurssien käyttöönotosta, jotta voimme aloittaa työnkulut erikseen, jos resursseihin ei tapahdu muutoksia (esimerkiksi kun koulutukseen on saatavilla uusia kuvia).
   • Omaisuuskoodiputkisto ottaa käyttöön kaiken infrastruktuurin, joka tarvitaan työnkulun onnistumiseen, kuten esim AWS-henkilöllisyyden ja käyttöoikeuksien hallinta (IAM) roolit, Lambda-toiminnot ja harjoituksen aikana käytetyt säilön kuvat.
   • Työnkulun koodiliukulinja suorittaa varsinaisen merkinnän, koulutuksen tai reunan käyttöönoton työnkulun.
5. Resurssiputket käynnistyvät automaattisesti, kun edellinen työnkulkuprosessi on valmis.
6. Koko prosessi käynnistetään aikataulun mukaan käyttämällä Amazon EventBridge säännöllisen uudelleenkoulutuksen sääntö.

CI/CD-integraation ansiosta koko päästä päähän -ketju on nyt täysin automatisoitu. Liukulinja laukeaa aina, kun koodi muuttuu git-tietovarastossamme sekä aikataulussa datamuutosten huomioon ottamiseksi.

Ajatella etukäteen

Kuvattu ratkaisuarkkitehtuuri edustaa peruskomponentteja päästä-päähän MLOps-putkilinjan rakentamiseen reunaan. Vaatimuksistasi riippuen voit kuitenkin harkita lisätoimintojen lisäämistä. Seuraavassa on joitain esimerkkejä:

Yhteenveto

Tässä viestissä hahmotimme arkkitehtuurimme päästä päähän MLOps-putkilinjan rakentamiseksi visuaalista laaduntarkastusta varten reunalla AWS-palveluiden avulla. Tämä arkkitehtuuri virtaviivaistaa koko prosessia sisältäen tietojen merkitsemisen, mallin kehittämisen ja reunan käyttöönoton, minkä ansiosta voimme nopeasti ja luotettavasti kouluttaa ja ottaa käyttöön uusia mallin versioita. Palvelimettomilla ja hallituilla palveluilla voimme suunnata keskittymisemme liikearvon tuottamiseen infrastruktuurin hallinnan sijaan.

In Osa 2 Tässä sarjassa syvennymme yhden tason syvemmälle ja tarkastelemme tämän arkkitehtuurin toteutusta tarkemmin, erityisesti etiketöintiä ja mallinrakennusta. Jos haluat hypätä suoraan koodiin, voit katsoa mukana GitHub repo.

---

Tietoja kirjoittajista

Michael Roth on AWS:n vanhempi ratkaisuarkkitehti, joka tukee valmistusasiakkaita Saksassa ratkaisemaan liiketoimintahaasteitaan AWS-teknologian avulla. Työn ja perheen lisäksi hän on kiinnostunut urheiluautoista ja nauttii italialaista kahvia.

Jörg Wöhrle on ratkaisuarkkitehti AWS:ssä ja työskentelee valmistusasiakkaiden kanssa Saksassa. Intohimona automaatiota kohtaan Joerg on työskennellyt ohjelmistokehittäjänä, DevOps-insinöörinä ja sivuston luotettavuusinsinöörinä ennen AWS:ää. Pilvien lisäksi hän on kunnianhimoinen juoksija ja nauttii laatuajasta perheensä kanssa. Joten jos sinulla on DevOps-haaste tai haluat mennä lenkille: kerro hänelle.

Johannes Langer on AWS:n vanhempi ratkaisuarkkitehti, joka työskentelee yritysasiakkaiden kanssa Saksassa. Johannes on intohimoinen koneoppimisen soveltamisesta todellisten yritysongelmien ratkaisemiseen. Yksityiselämässään Johannes nauttii kodin kunnostusprojekteista ja ulkoilusta perheen kanssa.

• SEO-pohjainen sisällön ja PR-jakelu. Vahvista jo tänään.
• PlatoData.Network Vertical Generatiivinen Ai. Vahvista itseäsi. Pääsy tästä.
• PlatoAiStream. Web3 Intelligence. Tietoa laajennettu. Pääsy tästä.
• PlatoESG. hiili, CleanTech, energia, ympäristö, Aurinko, Jätehuolto. Pääsy tästä.
• PlatonHealth. Biotekniikan ja kliinisten kokeiden älykkyys. Pääsy tästä.
• Lähde: https://aws.amazon.com/blogs/machine-learning/build-an-end-to-end-mlops-pipeline-for-visual-quality-inspection-at-the-edge-part-1/