Végponttól végpontig tartó MLOps csővezeték építése a peremeken végzett vizuális minőségellenőrzés érdekében – 1. rész | Amazon webszolgáltatások

A gépi tanulási (ML) modell sikeres üzembe helyezése éles környezetben nagymértékben függ a végpontok közötti ML-folyamattól. Bár egy ilyen csővezeték kifejlesztése kihívást jelenthet, még bonyolultabbá válik, ha egy él ML használati eset. A gépi tanulás a széleken egy olyan koncepció, amely az ML-modellek helyi futtatásának képességét biztosítja az éleszközökön. Ahhoz, hogy ezeket a modelleket a széleken telepítse, figyelje és karbantartsa, robusztus MLOps folyamatra van szükség. Az MLOps folyamat lehetővé teszi a teljes ML életciklus automatizálását az adatcímkézéstől a modell betanításáig és telepítéséig.

Az MLOps folyamat szélén való megvalósítása további bonyolultságokat eredményez, amelyek az automatizálási, integrációs és karbantartási folyamatokat nagyobb kihívást jelentenek a megnövekedett működési többletterhelés miatt. Azonban a célra épített szolgáltatások használatával, mint pl Amazon SageMaker és a AWS IoT Greengrass lehetővé teszi ennek az erőfeszítésnek a jelentős csökkentését. Ebben a sorozatban végigvezetjük az integrált, végpontokig terjedő MLOps-folyamat megtervezésének és felépítésének folyamatán a számítógépes látás peremén, a SageMaker, az AWS IoT Greengrass és a AWS Cloud Development Kit (AWS CDK).

Ez a bejegyzés az általános MLOps folyamat architektúrájának megtervezésére összpontosít; rész 2 és a rész 3 ennek a sorozatnak az egyes összetevőinek megvalósítására összpontosít. A mellékelt minta megvalósítást adtuk GitHub tárház hogy kipróbáld magad. Ha csak most kezdi használni az MLOp-okat az AWS szélén, tekintse meg a következőt MLO-k a széleken az Amazon SageMaker Edge Manager és az AWS IoT Greengrass segítségével áttekintéshez és referencia architektúrához.

Felhasználási eset: Fémcímkék minőségének ellenőrzése

ML mérnökként fontos, hogy megértse az üzleti ügyet, amelyen dolgozik. Mielőtt tehát belemerülnénk az MLOps folyamatarchitektúrába, nézzük meg ennek a bejegyzésnek a használati mintáját. Képzeljen el egy gyártó gyártósorát, amely fémcímkéket gravíroz, így személyre szabott poggyászcímkéket készít. A minőségbiztosítási eljárás költséges, mert a nyersfém címkéket manuálisan kell ellenőrizni, hogy nincsenek-e benne hibák, például karcolások. A folyamat hatékonyabbá tétele érdekében ML-t használunk a hibás címkék felismerésére a folyamat korai szakaszában. Ez segít elkerülni a költséges hibákat a gyártási folyamat későbbi szakaszaiban. A modellnek közel valós időben azonosítania kell a lehetséges hibákat, például a karcolásokat, és meg kell jelölnie azokat. Gyártó üzemi környezetben gyakran kell megküzdenie a kapcsolat hiányával vagy korlátozott sávszélességgel és megnövekedett késleltetéssel. Ezért egy olyan élvonalbeli ML-megoldást kívánunk megvalósítani a vizuális minőségellenőrzésre, amely lokálisan képes következtetéseket levonni a műhelyben, és csökkenti a csatlakozási követelményeket. Hogy példánk egyértelmű legyen, olyan modellt tanítunk, amely az észlelt karcokat határolókeretekkel jelöli. A következő kép egy példa az adatkészletünkből származó címkére, amelyen három karc van megjelölve.

A csővezeték architektúra meghatározása

Mostanra tisztáztuk a használati esetünket és azt a konkrét ML-problémát, amelyet meg kívánunk oldani, és amely a peremen történő objektumészlelés körül forog. Most itt az ideje, hogy felvázoljuk az MLOps folyamat architektúráját. Ebben a szakaszban még nem a technológiákat vagy konkrét szolgáltatásokat vizsgáljuk, hanem a folyamatunk magas szintű összetevőit. A gyors átképzés és üzembe helyezés érdekében automatizálnunk kell a teljes folyamatot a végpontokig: az adatcímkézéstől a betanításon át a következtetésekig. Van azonban néhány kihívás, amelyek különösen megnehezítik a csővezeték felállítását egy éles esethez:

• Ennek a folyamatnak a különböző részeinek felépítése különböző készségeket igényel. Például az adatok címkézése és képzése erősen adattudományi fókuszú, az élvonalbeli telepítéshez a dolgok internete (IoT) szakértője szükséges, és a teljes folyamat automatizálását általában olyan személy végzi, aki rendelkezik DevOps-készségekkel.
• A szervezettől függően ezt az egész folyamatot akár több csapat is végrehajthatja. A mi felhasználási esetünkben abból a feltételezésből dolgozunk, hogy a címkézésért, a képzésért és a telepítésért külön csoportok felelősek.
• A több szerep és készségkészlet eltérő követelményeket jelent a szerszámokkal és folyamatokkal szemben. Előfordulhat például, hogy az adattudósok figyelni szeretnék az ismerős notebook-környezetüket, és dolgozni szeretnének vele. Az MLOps mérnökei az infrastruktúrát kód (IaC) eszközként kívánják használni, és talán jobban ismerik a AWS felügyeleti konzol.

Mit jelent ez a csővezeték architektúránk szempontjából?

Először is kulcsfontosságú, hogy egyértelműen meghatározzuk a végpontok közötti rendszer fő összetevőit, amelyek lehetővé teszik a különböző csapatok számára, hogy önállóan dolgozhassanak. Másodszor, jól definiált interfészeket kell meghatározni a csapatok között az együttműködés hatékonyságának növelése érdekében. Ezek az interfészek segítenek minimalizálni a megszakításokat a csapatok között, lehetővé téve számukra, hogy szükség szerint módosítsák belső folyamataikat, amíg betartják a meghatározott interfészeket. A következő ábra szemlélteti, hogyan nézhet ki ez a számítógépes látási csővezetékünknél.

Vizsgáljuk meg részletesen az MLOps folyamat általános architektúráját:

1. A folyamat a fémcímkék nyers képeinek gyűjtésével kezdődik, amelyeket a gyártási környezetben egy élkamerás eszközzel rögzítenek, hogy létrehozzanak egy kezdeti betanítási adatkészletet.
2. A következő lépés ezeknek a képeknek a címkézése és a hibák megjelölése határolókeretekkel. Elengedhetetlen a címkézett adatkészlet verziószáma, biztosítva a felhasznált képzési adatok nyomon követhetőségét és elszámoltathatóságát.
3. Miután megkaptuk a címkézett adatkészletet, folytathatjuk a modell betanítását, finomhangolását, kiértékelését és verziószámát.
4. Ha elégedettek vagyunk modellünk teljesítményével, telepíthetjük a modellt egy szélső eszközre, és élő következtetéseket futtathatunk a peremen.
5. Amíg a modell gyártásban működik, az élkamerás eszköz értékes képadatokat generál, amelyek korábban nem látott hibákat és éles eseteket tartalmaznak. Ezeket az adatokat felhasználhatjuk modellünk teljesítményének további javítására. Ennek érdekében elmentjük azokat a képeket, amelyekre a modell alacsony megbízhatósággal jósol, vagy hibás előrejelzéseket ad. Ezek a képek ezután visszakerülnek a nyers adatkészletünkbe, újraindítva a teljes folyamatot.

Fontos megjegyezni, hogy a nyers képadatok, a címkézett adatkészlet és a betanított modell jól meghatározott interfészként szolgálnak a különböző folyamatok között. Az MLOps mérnökei és adatkutatói rugalmasan választhatják meg a folyamatban lévő technológiákat, mindaddig, amíg folyamatosan előállítják ezeket a műtermékeket. A legfontosabb, hogy egy zárt visszacsatolási hurkot hoztunk létre. A gyártás során készített hibás vagy alacsony megbízhatóságú előrejelzések felhasználhatók adatkészletünk rendszeres bővítésére, valamint a modell automatikus átképzésére és javítására.

Cél architektúra

Most, hogy a magas szintű architektúra létrejött, ideje egy szinttel mélyebbre menni, és megvizsgálni, hogyan építhetjük fel ezt az AWS-szolgáltatásokkal. Vegye figyelembe, hogy az ebben a bejegyzésben bemutatott architektúra feltételezi, hogy teljes mértékben át kívánja venni az irányítást a teljes adattudományi folyamat felett. Ha azonban még csak most kezdi a minőségellenőrzést a szélén, javasoljuk Amazon Lookout for Vision. Lehetővé teszi saját minőségellenőrzési modelljének betanítását anélkül, hogy ML-kódot kellene felépíteni, karbantartani vagy megérteni. További információkért lásd: Az Amazon Lookout for Vision mostantól támogatja a termékhibák szemrevételezését a széleken.

Ha azonban teljes irányítást szeretne átvenni, a következő diagram bemutatja, hogyan nézhet ki egy architektúra.

A korábbiakhoz hasonlóan nézzük végig a munkafolyamatot lépésről lépésre, és azonosítsuk, mely AWS szolgáltatások felelnek meg követelményeinknek:

1. Amazon egyszerű tárolási szolgáltatás (Amazon S3) nyers képadatok tárolására szolgál, mert olcsó tárolási megoldást biztosít számunkra.
2. A címkézési munkafolyamat a segítségével van irányítva AWS lépésfunkciók, egy kiszolgáló nélküli munkafolyamat-motor, amely megkönnyíti a címkézési munkafolyamat lépéseinek összehangolását. Ennek a munkafolyamatnak a részeként használjuk Amazon SageMaker Ground Truth a címkézés teljes automatizálása címkézési feladatok és irányított emberi munkaerő segítségével. AWS Lambda az adatok előkészítésére, a címkézési munkák elindítására és a címkék tárolására szolgál Amazon SageMaker Feature Store.
3. A SageMaker Feature Store tárolja a címkéket. Lehetővé teszi számunkra, hogy központilag kezeljük és megosszuk szolgáltatásainkat, és beépített adatverziós lehetőségeket biztosít számunkra, ami robusztusabbá teszi a folyamatot.
4. A modellépítési és oktatási csővezeték segítségével hangszereljük Amazon SageMaker csővezetékek. Beépített lépéseken keresztül integrálható a többi SageMaker funkcióval. SageMaker Training állások a modellképzés automatizálására szolgálnak, és SageMaker Feldolgozási munkák az adatok előkészítésére és a modell teljesítményének értékelésére szolgálnak. Ebben a példában a Ultralytics YOLOv8 Python csomag és modellarchitektúra objektumészlelési modell betanításához és exportálásához ONNX ML modell formátum a hordozhatóság érdekében.
5. Ha a teljesítmény elfogadható, a betanított modellt regisztrálják Amazon SageMaker Model Registry növekményes verziószámmal. Interfészként működik a modell betanítási és az éles telepítési lépések között. Itt kezeljük a modellek jóváhagyási állapotát is. A többi használt szolgáltatáshoz hasonlóan teljes körűen felügyelt, így nem kell saját infrastruktúránk működtetéséről gondoskodnunk.
6. Az éles üzembe helyezési munkafolyamat a Step Functions használatával automatizált, hasonlóan a címkézési munkafolyamathoz. A Step Functions API-integrációi segítségével könnyedén meghívhatjuk a különböző szükséges AWS szolgáltatás API-kat, például az AWS IoT Greengrass-t, új modellösszetevők létrehozásához, majd az összetevők telepítéséhez a peremeszközön.
7. Az AWS IoT Greengrass az eszköz szélső futási környezete. Ez kezeli a modellünk és a következtetési összetevőink telepítési életciklusát a széleken. Lehetővé teszi modellünk és következtetési összetevőink új verzióinak könnyű üzembe helyezését egyszerű API-hívások segítségével. Ezenkívül a szélén lévő ML modellek általában nem futnak elszigetelten; használhatjuk a különféle AWS és a közösség biztosította az AWS IoT Greengrass összetevőit más szolgáltatásokhoz való csatlakozáshoz.

A felvázolt architektúra hasonlít a korábban bemutatott magas szintű architektúránkra. Az Amazon S3, a SageMaker Feature Store és a SageMaker Model Registry interfészként szolgálnak a különböző folyamatok között. A megoldás futtatásához és üzemeltetéséhez szükséges erőfeszítések minimalizálása érdekében lehetőség szerint menedzselt és szerver nélküli szolgáltatásokat használunk.

Összeolvad egy robusztus CI/CD rendszerré

Az adatcímkézés, a modell betanítás és az éles üzembe helyezés lépései megoldásunk központi elemei. Mint ilyen, a mögöttes kóddal vagy adatokkal kapcsolatos bármely változás az említett részek bármelyikében a teljes hangszerelési folyamat új futtatását indítja el. Ennek eléréséhez integrálnunk kell ezt a folyamatot egy CI/CD rendszerbe, amely lehetővé teszi számunkra, hogy automatikusan telepítsük a kód- és infrastruktúra-módosításokat egy verziószámú kódtárból a termelésbe. A korábbi architektúrához hasonlóan itt is fontos szempont a csapat autonómia. A következő diagram azt mutatja, hogy ez hogyan nézhet ki AWS-szolgáltatások használatával.

Nézzük végig a CI/CD architektúrát:

1. AWS CodeCommit Git-tárunkként működik. Az egyszerűség kedvéért a megadott mintánkban almappákon keresztül különválasztottuk a különálló részeket (címkézés, modellképzés, éles telepítés) egyetlen git-tárházban. Valós forgatókönyv esetén minden csapat különböző adattárakat használhat az egyes részekhez.
2. Az infrastruktúra telepítése az AWS CDK segítségével automatizált, és minden rész (címkézés, képzés és él) saját AWS CDK alkalmazást kap, amely lehetővé teszi a független telepítést.
3. Az AWS CDK folyamat funkciót használja AWS CodePipeline az infrastruktúra és a kódtelepítések automatizálására.
4. Az AWS CDK minden lépéshez két kódfolyamatot telepít: egy eszközfolyamatot és egy munkafolyamat-folyamatot. Elválasztottuk a munkafolyamatot az eszköztelepítéstől, hogy a munkafolyamatokat külön indíthassuk el, ha nem történik eszközváltozás (például ha új képek állnak rendelkezésre a képzéshez).
   • Az eszközkód-folyamat a munkafolyamat sikeres futtatásához szükséges összes infrastruktúrát telepíti, mint pl AWS Identity and Access Management (IAM) szerepkörök, Lambda-függvények és a képzés során használt tárolóképek.
   • A munkafolyamat-kódfolyamat a tényleges címkézési, betanítási vagy éles üzembe helyezési munkafolyamatot futtatja.
5. Az eszközfolyamatok automatikusan aktiválódnak a véglegesítéskor, valamint egy korábbi munkafolyamat-folyamat befejezésekor.
6. Az egész folyamat ütemezetten indul el egy Amazon EventBridge szabály a rendszeres átképzésre.

A CI/CD integrációval a teljes, végpontokig tartó lánc immár teljesen automatizált. A folyamat minden alkalommal aktiválódik, amikor a kód megváltozik a git-tárolónkban, valamint az adatváltozásokhoz igazodó ütemezés szerint.

Gondolkozz előre

A leírt megoldás-architektúra azokat az alapvető összetevőket képviseli, amelyek egy végponttól végpontig tartó MLOps folyamat peremén történő felépítéséhez szükségesek. Igényeitől függően azonban fontolóra veheti további funkciók hozzáadását. Íme néhány példa:

Következtetés

Ebben a bejegyzésben felvázoltuk az AWS-szolgáltatások használatával végpontok közötti MLOps-folyamat felépítéséhez szükséges architektúrát, amely a széleken vizuális minőségellenőrzést végez. Ez az architektúra leegyszerűsíti a teljes folyamatot, beleértve az adatcímkézést, a modellfejlesztést és az éles telepítést, lehetővé téve számunkra a modell új verzióinak gyors és megbízható betanítását és bevezetését. A szerver nélküli és felügyelt szolgáltatásokkal az infrastruktúra menedzselése helyett az üzleti érték megteremtésére összpontosíthatunk.

In rész 2 Ennek a sorozatnak egy szinttel mélyebbre fogunk ásni, és részletesebben megvizsgáljuk ennek az architektúrának a megvalósítását, különösen a címkézést és a modellkészítést. Ha közvetlenül a kódra szeretne ugrani, nézze meg a mellékeltet GitHub repo.

---

A szerzőkről

Michael Roth az AWS vezető megoldástervezője, aki támogatja a németországi gyártó ügyfeleket abban, hogy az AWS technológián keresztül megoldják üzleti kihívásaikat. A munka és a család mellett érdeklik a sportautók, és élvezi az olasz kávét.

Jörg Wöhrle az AWS megoldástervezője, aki németországi gyártó ügyfelekkel dolgozik. Az automatizálás iránti szenvedéllyel Joerg az AWS előtti életében szoftverfejlesztőként, DevOps mérnökként és Site Reliability Engineerként dolgozott. A felhőkön túl ambiciózus futó, és minőségi időt tölt a családjával. Tehát ha DevOps kihívása van, vagy futni szeretne: tudassa vele.

Johannes Langer az AWS vezető megoldási építésze, vállalati ügyfelekkel dolgozik Németországban. Johannes szenvedélyesen használja a gépi tanulást valódi üzleti problémák megoldására. Magánéletében Johannes szívesen dolgozik otthoni fejlesztési projekteken, és a szabadban tölt időt családjával.

• SEO által támogatott tartalom és PR terjesztés. Erősödjön még ma.
• PlatoData.Network Vertical Generative Ai. Erősítse meg magát. Hozzáférés itt.
• PlatoAiStream. Web3 Intelligence. Felerősített tudás. Hozzáférés itt.
• PlatoESG. Carbon, CleanTech, Energia, Környezet, Nap, Hulladékgazdálkodás. Hozzáférés itt.
• PlatoHealth. Biotechnológiai és klinikai vizsgálatok intelligencia. Hozzáférés itt.
• Forrás: https://aws.amazon.com/blogs/machine-learning/build-an-end-to-end-mlops-pipeline-for-visual-quality-inspection-at-the-edge-part-1/