Fitimet:
- Aftësia për të njohur sfidat e veçanta të ML në lidhje me treshen dhe paketën e kodit-të dhënave-modelit dhe paraqitjes së modelit online ose në grup sipas nevojave të biznesit.
- Aftësia për të zbatuar modelet e vendosjes graduale dhe të kthimit (hije, kanarina, A/B, rikthim) dhe për të shtuar një plan rikthimi të testuar për çdo vendosje
- Aftësia për të mbajtur të gjurmueshme lidhjen e të dhënave-kodit-metrik të modelit të vënë në prodhim me CI/CD të kontrolluar nga pragu i vlerësimit dhe regjistrin e modelit
Marrja e një modeli për të arritur saktësi 95% në fletore është vetëm gjysma e historisë. Gjysma tjetër - shpesh pjesa e vështirë - është marrja e atij modeli te përdoruesit e vërtetë në një mënyrë të besueshme, të shkallëzuar dhe të mirëmbajtur. MLOps (Machine Learning Operations: disiplina e vendosjes, funksionimit dhe mirëmbajtjes së modeleve ML në prodhim) kombinon praktikat DevOps të inxhinierisë softuerike me sfidat unike të ML. Në këtë njësi, ne mbulojmë hapat e zhvendosjes së modelit në prodhim dhe se si inteligjenca artificiale ndihmon në këtë proces.
Pse ML është i ndryshëm nga softveri i zakonshëm?
Në softuerin e zakonshëm, sjellja është në kod; Nëse kodi nuk ndryshon, sjellja nuk ndryshon. Në ML, sjellja varet nga kodi, të dhënat dhe modeli. Këto tre dimensione krijojnë sfidat shtesë të MLO-ve:
- Zhvendosja e të dhënave: Të dhënat në prodhim largohen nga të dhënat në trajnim me kalimin e kohës; modeli bëhet i vjetëruar.
- Ju duhet të versiononi tre gjëra: Kodin, të dhënat dhe modelin - të treja.
- Dështim i heshtur: Një model mund të dështojë pa u përplasur, pa dhënë gabime, thjesht duke prodhuar parashikime të pasakta. Kapja e kësaj kërkon monitorim.
Kjo është arsyeja pse ka një ndryshim të madh midis një "modeli pune" dhe një "modeli të gatshëm për prodhim".
Paketimi dhe prezantimi i modelit
Hapi i parë në vënien e modelit në prodhim është paketimi i tij: skedari i modelit, bibliotekat e nevojshme, kodi i parapërpunimit dhe informacioni i versionit së bashku si një tërësi e riprodhueshme. Kontejnerizimi (p.sh. Docker: vendosja e aplikacionit në një kuti të izoluar me të gjitha varësitë e tij) është standard këtu; Ai eliminon problemin "po punonte në makinën time".
Dy modele bazë të shërbimit të modelit:
- Online/në kohë reale (online): Modeli qëndron pas një API, duke kthyer një parashikim të menjëhershëm për çdo kërkesë hyrëse. Latenca e ulët është kritike.
- Batch: Modeli përpunon grupe të mëdha të dhënash në mënyrë periodike (p.sh. gjeneron rezultate për të gjithë klientët gjatë natës). Vonesa është e parëndësishme, efikasiteti është i rëndësishëm.
Cila është e drejtë varet nga nevoja e biznesit: rekomandimi i menjëhershëm në internet, rezultati mujor i rrezikut në grup.
Këshillë: "Në kohë reale" është një kosto, jo e paracaktuar. Seria është shumë më e lirë dhe më e thjeshtë nëse rezultati do të përdoret brenda disa orësh. Keni vërtet nevojë për një përgjigje të menjëhershme? Pyete atë së pari.
Strategjitë e sigurta të shpërndarjes
Hapja e një modeli të ri drejtpërdrejt për të gjithë trafikun është e rrezikshme; Nëse është e gabuar, të gjithë janë të prekur. Modelet e sigurta të shpërndarjes:
- Vendosja e hijes: Modeli i ri merr trafikun e prodhimit, por parashikimet e tij nuk i shfaqen përdoruesit, por regjistrohen vetëm. Krahasohet me modelin e vjetër për të parë nëse është i sigurt në të dhënat reale.
- Shpërndarja e Kanarit: Modeli i ri fillimisht shpërndahet në një përqindje të vogël trafiku (p.sh. 5%); Nëse nuk ka problem, rritet gradualisht.
- Testimi A/B: Përdoruesit real i prezantohen paralelisht dy modele dhe krahasohen metrikat e biznesit (konvertimi, klikimet).
- Rikthim: Aftësia për t'u rikthyer shpejt në versionin e vjetër nëse modeli i ri rezulton i keq. Çdo vendosje duhet të ketë një plan rikthimi.
Kujdes: Një vendosje pa një plan rikthimi nuk është i plotë. Mundësia për t'u rikthyer në versionin e vjetër brenda pak minutash e mbron përdoruesin kur modeli i ri sillet në mënyrë të papritur në prodhim. Provoni këtë përpara vendosjes.
Qasje e dobët / Qasje e fortë
I dobët: “Modelja ishte e mirë në testim, dolëm live, ia hapëm të gjithëve”.
Güçlü: "Ne e kontejneruam modelin, e etiketuam si version. Së pari, e përdorëm në modalitetin hije me trafikun e prodhimit për 3 ditë, duke krahasuar parashikimet me modelin e vjetër — devijimi ishte i pranueshëm. Më pas e hapëm me 5% kanarinë, monitoruam metrikën e xhiros dhe vonesën. Kur nuk kishte probleme, e rritëm gradualisht në 0 mbrapa në 10%.
Dallimi: qasja e fortë është graduale, e matur dhe e kthyeshme. Rreziku është i kufizuar në çdo hap.
CI/CD dhe automatizimi
CI/CD (Integrimi i vazhdueshëm / Vendosja e vazhdueshme: tubacioni i testimit automatik dhe lëshimit të ndryshimeve të kodit) në ML mbulon jo vetëm kodin, por edhe hapat e të dhënave dhe modelit. Një tubacion i mirë ML CI/CD: kryen teste kur ndryshon kodi, kryen vërtetimin e të dhënave, ritrajnon modelin (nëse është e nevojshme), kontrollon pragjet e vlerësimit dhe avancon vendosjen vetëm nëse pragjet qëndrojnë. Parimi i "stërvitjes është automatik, vendosja është e bazuar në prag" parandalon që modeli i keq të rrjedhë në heshtje në prodhim.
AI është shumë i dobishëm kur vendosni këto tubacione: shkrimi i drafteve të skedarit të konfigurimit (YAML), rastet e testimit, skriptet e vendosjes. Por ju përcaktoni pragjet e shpërndarjes (çfarëdo metrikë që tejkalon vlerën e publikuar) dhe politikën e rikthimit; këto janë vendime për rrezikun e biznesit.
Infrastruktura e riprodhueshmërisë
Për të riprodhuar sjelljen e një modeli në prodhim, regjistri i modelit: një rekord që mban se cili model është trajnuar me cilat të dhëna dhe kode dhe cilat metrikë ka marrë. Për secilin model prodhimi, këto duhet të jenë të gjurmueshme: versioni i të dhënave të trajnimit, versioni i kodit (git commit), hiperparametrat, rezultatet e vlerësimit dhe data e vendosjes. Kur lind një problem, ju duhet të jeni në gjendje t'i përgjigjeni pyetjes "cili model e ka prodhuar këtë parashikim, me cilat të dhëna?" brenda minutave. Këtë do ta thellojmë në njësinë 11.
tre mini kuti
Rasti 1 - Problemi i kapur nga shpërndarja e hijes. Një model rekomandimi mundi atë të vjetër në testim. Ekzekutimi i tij me trafikun e prodhimit në modalitetin hije u zbulua se prodhonte rekomandime shumë të dobëta për një segment të caktuar përdoruesish (përdorues të rinj) - të dhënat e testit ishin nënpërfaqësuese të këtij segmenti. Modeli u rregullua pa u shfaqur kurrë tek përdoruesi. Nëse do të hapej drejtpërdrejt, përvoja e re e përdoruesit do të ndërpritet.
Rasti 2 - Shpërndarja e pakthyeshme. Një ekip prezantoi një model të ri çmimi për të gjithë trafikun, pa plane rikthimi. Modeli i ka kushtuar papritur disa produkte shumë lirë. Rikthimi në versionin e vjetër zgjati orë të tëra sepse procesi nuk ishte gati. Pati një humbje të rëndë të të ardhurave. Më pas, testimi i detyrueshëm i rikthimit u shtua në çdo vendosje.
Rasti 3 - Zhvendosje e heshtur e të dhënave. Një model mashtrimi u shfaq për muaj të tërë pa asnjë gabim. Por taktikat e mashtruesve ndryshuan (zhvendosja e të dhënave) dhe tërheqja e modelit ra në heshtje. Askush nuk e vuri re sepse nuk kishte monitorim. Pasi u krijua një panel monitorimi i shpërndarjes së parashikimeve, zhvendosja u bë e dukshme herët. Ne do të mbulojmë monitorimin në njësinë 8.
Modele të kopjueshme
Shkruani një draft plan vendosjeje për këtë model. Modeli: [çfarë bën], përdorimi: [online apo grumbull?] Duhet të përfshijë: 1) Paketimin (kontejner, versionin) 2) Strategjinë e vendosjes në rritje (hije/kanari/A-B) dhe pse3) Metrikë për të gjurmuar (biznes + teknik + vonesë) 4) Plani i rikthimit dhe si të testohet 5) vendosja me vlerë të caktuar)
Kontrollo këtë tubacion ML CI/CD:1) A është vërtetimi i të dhënave në linjë?2) A mund të vazhdojë vendosja pa mbajtur pragun e vlerësimit (a nuk duhet të jetë)?3) A është kthimi automatik?4) A gjurmohen të dhënat+kodi+metrikat në regjistrin e modelit? Konfigurimi i linjës: [konfigurim]
Më ndihmo të vendos nëse prezantimi në internet apo grupi është i përshtatshëm për këtë model. Sa kohë do të përdoret rezultati: [i menjëhershëm / minutë / orë / ditë] Vëllimi i pritshëm i kërkesës: [numri] A ka një kufizim vonesë: [ms] Cilin do të rekomandonit për sa i përket kostos dhe kompleksitetit dhe pse?
Shkruani një procedurë rikthimi për këtë model.- Cila metrikë/prag shkakton performancë të dobët?- Cilat janë hapat e rikthimit?- Sa kohë duhet të zgjasë rikthimi (objektivi)?- Si ta testoj këtë procedurë përpara prodhimit?
Tabela e modelit të prezantimit
kriteri
Online (në kohë reale)
Batch
vonesë
Kritike (ms)
i parëndësishëm
Përdorimi
Kërkohet përgjigje e menjëhershme
Rezultati periodik
Kostoja
lartë
të ulëta
kompleksiteti
lartë
të ulëta
shembull
Rekomandim i drejtpërdrejtë, mashtrim
Rezultati mujor i rrezikut
Gabimet e zakonshme
- Shpërndani pa një plan rikthimi. Modeli i gabuar godet të gjithë përdoruesin.
- Hapja direkt në trafik 100%. Kufizoni rrezikun me shpërndarje të shkallëzuar.
- Mos vendosja e monitorimit. Modeli prodhon gabime në heshtje, pa gabime.
- Prezantim i tepërt në kohë reale. Ndërsa grumbullimi është i mjaftueshëm, kostoja dhe kompleksiteti rriten.
- Nuk lidh versionet e kodit model-të dhëna. Ju nuk mund ta riprodhoni problemin.
- Lëshimi automatik pa prag shpërndarjeje. Modelja e keqe futet fshehurazi në heshtje.
Në përmbledhje
Zhvendosja e modelit në prodhim është një detyrë e ndryshme dhe shpesh më e vështirë inxhinierike sesa trajnimi i tij. ML kërkon disiplinë shtesë sepse varet nga treshja e kodit-të dhënave-modelit: paketimi dhe versionimi, modeli i dorëzimit (online/batch) që i përshtatet nevojave të biznesit, vendosja gradual dhe e kthyeshme, CI/CD e kontrolluar nga pragu dhe regjistrimi i modelit. Inteligjenca artificiale është një ndihmë e fuqishme në gjenerimin e kodit dhe konfigurimit të kësaj infrastrukture; por pragjet e shpërndarjes, politika e rikthimit dhe vendimet e rrezikut janë tuajat. Një shpërndarje pa një plan rikthimi nuk është i plotë.
Detyra e aplikimit
Kontejneroni (Docker) një model dhe etiketoni atë version. Vendosni nëse do të ofroni online ose grupe bazuar në nevojat e biznesit tuaj dhe shkruani justifikimin tuaj. Dokumentoni një plan vendosjeje me faza (hije ose kanarinë) dhe një procedurë rikthimi të testuar. Sigurohuni që të regjistroni versionin e të dhënave, kryerjen e kodit dhe rezultatet e vlerësimit në regjistrin e modelit.
listë kontrolli
- [ ] Modeli është i paketuar dhe i versionuar (enë + etiketë).
- [ ] Modeli i prezantimit (online/batch) u zgjodh sipas nevojës së biznesit.
- [ ] Zbatohet strategjia e vendosjes me faza (hije/kanari).
- [ ] Procedura e rikthimit e shkruar dhe e testuar.
- [ ] CI/CD nuk e avancon vendosjen përpara se të përmbushet pragu i vlerësimit.
- [ ] Regjistri i modelit mban lidhjen të dhëna+kodi+metrik.