Kuptimi i ciklit jetësor të mësimit të makinerive po evoluon vazhdimisht. Kur takova për herë të parë grafikët që ilustrojnë këtë "cikli", theksi ishte te të dyshuarit e zakonshëm (gëlltitja e të dhënave, pastrimi, EDA, modelimi etj.). Më pak theks iu kushtua gjendjes përfundimtare më të pakapshme dhe më pak të prekshme - “shpërndarja e modelit”, “shërbimi i modelit”, “vëzhgueshmëria e modelit”, etj.
Ndërsa cikli i jetës së ML nga fundi në fund është paraqitur gjithmonë si një "cikli" aktual, deri më tani ka pasur sukses të kufizuar në menaxhimin real të këtij procesi nga fundi në fund në shkallën e nivelit të ndërmarrjes.
Arkitektura MLOps e bazuar në orkestrim
Shumica e arkitekturave ose zbatimeve të MLOps që kam hasur janë "Orkestrimi" i bazuar në lidhje të ngushtë midis komponentëve të ndryshëm. Të dhënat zakonisht presin në një depo dhe një mjet orkestrimi i rrjedhës së punës përdoret për të planifikuar nxjerrjen dhe përpunimin, si dhe rikualifikimin e modelit në të dhëna të freskëta.
Kjo arkitekturë është veçanërisht e dobishme për problemet ku përdoruesit nuk kanë nevojë për rezultate në kohë reale, si p.sh. një motor rekomandimi për përmbajtje (për këngë ose artikuj) që shërben rekomandime të modelit të llogaritur paraprakisht kur përdoruesit hyjnë në llogaritë e tyre.
Por kjo arkitekturë dështon në skenarët më poshtë.
- Kur ka burime të reja të të dhënave që shtohen vazhdimisht në ciklin jetësor të ML
- Kur modeli duhet të ritrajnohet për aplikime në kohë reale
- Kur ka kërkesë për rikualifikim manual të modelit të nxitur nga përdoruesi
Arkitektura MLOps e bazuar në mesazhe
Arkitektura e bazuar në mesazhe ndjek një qasje të ndryshme ku një ndërmjetës mesazhesh (p.sh. Kafka) vepron si ndërmjetës për të ndihmuar në koordinimin e proceseve midis komponentëve të ndryshëm të ML.
Kjo është shumë e dobishme kur duam që sistemi ynë të stërvitet vazhdimisht për gëlltitjen e të dhënave në kohë reale nga një pajisje IoT për analitikën e transmetimit ose për shërbimin në internet.
Më poshtë janë hapat si pjesë e kësaj arkitekture:
- "ADS Creation Pipeline" thith dhe përpunon të dhënat burimore për ndërtimin e ruajtjes së veçorive dhe të dhënave përfundimtare analitike. Pasi procesi të përfundojë, ai dërgon një mesazh te ndërmjetësi i mesazheve.
- “Trajnimi i modelit të tubacionit” pajtohet te ndërmjetësi i mesazheve, kështu që kur mesazhi i ri vjen nga “Tubacioni i krijimit të ADS”, atëherë ai do të filloni procesin e trajnimit të modelit dhe vendosni modelin përfundimtar në një regjistër modeli dhe në pikën përfundimtare të API. Pasi procesi të përfundojë, ai dërgon një mesazh tjetër te ndërmjetësi i mesazheve.
- "Tubacioni i shërbimit të modelit" pajtohet te ndërmjetësi i mesazheve dhe njoftohet kur mesazhi i ri vjen nga "Tubacioni i trajnimit model". Në rast të prishjes së modelit ose zhvendosjes së të dhënave, ai i dërgon mesazhe të veçanta ndërmjetësit në mënyrë që ose të fillojë rikualifikimin e modelit (në rast të prishjes së modelit) ose të fillojë gëlltitjen e të dhënave të reja (në rast të zhvendosjes së të dhënave).
Përmbledhje
Si përfundim, arkitektura MLOps e drejtuar nga ngjarjet “bazuar në mesazhe” ndihmon shumë në shkëputjen e komponentëve të ndryshëm të ML, ndërkohë që orkestron të gjithë ciklin jetësor të ML duke përdorur mesazhet e ndërmjetësit.
Kjo kujdeset për kufizimet e përmendura për arkitekturën MLOps “Bazuar në orkestrim”.
- Shtimi i pandërprerë i burimeve të reja të të dhënave — Meqenëse çdo burim i të dhënave do të ketë linjën e vet, i cili thjesht duhet të abonohet te ndërmjetësi i mesazheve për të shtyrë/tërhequr mesazhet.
- Ritrajnimi i modelit në kohë reale — Meqenëse tubacioni i trajnimit të modelit është i shkëputur nga komponentë të tjerë, ai mund të aktivizohet në mënyrë të pavarur duke përdorur ndërmjetësin e mesazheve, pa ndikuar në të gjithë procesin.
Do të ketë shumë evolucione të tjera në arkitekturat MLOps dhe shpresoj se ky artikull do të shërbejë si një abetare për përsëritjet e ardhshme.
