Kasu:
- Oskus ära tunda ML-i erilisi väljakutseid, mis on seotud kood-andmed-mudel kolmiku ja paketiga ning esitleda mudelit veebis või partiidena vastavalt ärivajadusele.
- Võimalus juurutada järkjärgulisi ja tagasipööramise mustreid (vari, kanaarilind, A/B, tagasipööramine) ja lisada igale juurutusele testitud tagasipööramise plaan
- Võimalus hoida tootmisse pandud mudeli andmekoodi-meetrilist linki jälgitavana hindamislävega juhitava CI/CD ja mudeliregistri abil
Mudeli hankimine, et saavutada sülearvuti 95% täpsus, on vaid pool lugu. Teine pool – sageli raske osa – on selle mudeli usaldusväärsel, skaleeritaval ja hooldataval viisil tegelik kasutajateni jõudmine. MLOps (Machine Learning Operations: ML-mudelite tootmisesse panemise, käitamise ja hooldamise distsipliin) ühendab tarkvaratehnika DevOpsi praktikad ML ainulaadsete väljakutsetega. Selles üksuses käsitleme mudeli tootmisse viimise etappe ja seda, kuidas tehisintellekt selles protsessis aitab.
Miks erineb ML tavalisest tarkvarast?
Tavatarkvaras on käitumine koodis; Kui kood ei muutu, siis käitumine ei muutu. ML-is sõltub käitumine nii koodist, andmetest kui ka mudelist. Need kolm mõõdet loovad MLOps-i lisaväljakutseid:
- Andmete triiv: tootmises olevad andmed eemalduvad aja jooksul koolituse andmetest; mudel vananeb.
- Peate versiooni kolme asja kohta: kood, andmed ja mudel – kõik kolm.
- Vaikne rike: mudel võib ebaõnnestuda ilma kokkujooksmiseta, ilma vigadeta, lihtsalt valede prognooside esitamise tõttu. Selle tabamine nõuab jälgimist.
Seetõttu on "töötava mudeli" ja "tootmisvalmis mudeli" vahel suur erinevus.
Mudeli pakendamine ja esitlus
Esimene samm mudeli tootmisse panemisel on selle pakkimine: mudelifail, vajalikud teegid, eeltöötluskood ja versiooniteave koos reprodutseeritavaks tervikuks. Konteinerimine (nt Docker: rakenduse paigutamine isoleeritud kasti koos kõigi selle sõltuvustega) on siin standardne; See kõrvaldab probleemi "see töötas minu masinaga".
Mudeli teenindamise kaks põhimustrit:
- Võrgus/reaalajas (veebis): mudel asub API taga, tagastades iga sissetuleva päringu kohta kohese ennustuse. Madal latentsusaeg on kriitiline.
- Partii: mudel töötleb perioodiliselt suuri andmekogumeid (nt genereerib öösel hinded kõigile klientidele). Latentsus on ebaoluline, tõhusus on oluline.
Milline neist on õige, sõltub ettevõtte vajadusest: kiire soovitus veebis, igakuine riskiskoor partiidena.
Näpunäide: "Reaalajas" on kulu, mitte vaikeväärtus. Partii on palju odavam ja lihtsam, kui tulemust kasutatakse tundide jooksul. Kas vajate tõesti kohest vastust? Küsi seda kõigepealt.
Turvalised levitamisstrateegiad
Uue mudeli avamine otse kogu liiklusele on riskantne; Kui see on vale, mõjutab see kõiki. Ohutu levitamise mustrid:
- Varijuutamine: uus mudel saab tootmisliikluse, kuid selle ennustusi kasutajale ei näidata, vaid ainult logitakse. Seda võrreldakse vana mudeliga, et näha, kas see on reaalsetes andmetes ohutu.
- Kanaari juurutamine: uus mudel võetakse esmalt kasutusele väikesele osale liiklusest (nt 5%); Kui probleemi pole, suurendatakse seda järk-järgult.
- A/B testimine: reaalsele kasutajale esitatakse paralleelselt kahte mudelit ja võrreldakse ärimõõdikuid (konversioon, klikid).
- Tagasivõtmine: Võimalus kiiresti naasta vanale versioonile, kui uus mudel osutub halvaks. Igal kasutuselevõtul peaks olema tagasipööramise plaan.
Ettevaatust. Juurutamine ilma tagasipööramisplaanita ei ole lõpule viidud. Võimalus mõne minuti jooksul vanale versioonile naasta kaitseb kasutajat, kui uus mudel käitub tootmises ootamatult. Testige seda enne kasutuselevõttu.
Nõrk lähenemine / tugev lähenemine
Nõrk: "Mudel oli testimisel hea, läksime otseülekandesse, avasime selle kõigile."
Güçlü: "Konteinerisime mudeli, märgistasime selle versiooniks. Esiteks käitasime seda 3 päeva varirežiimis tootmisliiklusega, võrreldes ennustusi vana mudeliga – kõrvalekalle oli vastuvõetav. Seejärel avasime selle 5% kanaariga, jälgisime läbilaskevõime mõõdikuid ja latentsust. Kui probleeme polnud, suurendasime seda järk-järgult 100% tagasipööramise käsuni."
Erinevus: tugev lähenemine on järkjärguline, mõõdetud ja pöörduv. Risk on igal sammul piiratud.
CI/CD ja automaatika
CI/CD (Continuous Integration / Continuous Deployment: automaatse testimise ja koodimuudatuste vabastamise konveier) ML-is hõlmab mitte ainult koodi, vaid ka andmete ja mudeli etappe. Hea ML CI/CD konveier: testib, kui kood muutub, teostab andmete valideerimist, koolitab mudeli ümber (vajadusel), kontrollib hindamislävesid ja viib juurutamist edasi ainult siis, kui läved kehtivad. Põhimõte “koolitus on automaatne, juurutamine lävepõhine” takistab halva mudeli vaikselt tootmisse lekkimist.
Tehisintellekt on nende torujuhtmete seadistamisel väga abiks: konfiguratsioonifaili (YAML) mustandite, testjuhtumite, juurutusskriptide kirjutamisel. Kuid te määrate jaotusläved (mis tahes mõõdik, mis ületab avaldatava väärtuse) ja tagasipööramise poliitika; need on äririskiga seotud otsused.
Reprodutseeritavuse infrastruktuur
Tootmismudeli käitumise taasesitamiseks mudeliregister: kirje, mis hoiab, millist mudelit milliste andmete ja koodiga koolitati ning milliseid mõõdikuid see sai. Iga tootmismudeli puhul peaksid olema jälgitavad järgmised andmed: koolitusandmete versioon, koodi versioon (git commit), hüperparameetrid, hindamisskoorid ja juurutamise kuupäev. Probleemi ilmnemisel peaksite suutma vastata küsimusele "milline mudel koostas selle prognoosi ja milliste andmetega?" minutite jooksul. Süvendame seda üksuses 11.
kolm minikarpi
Juhtum 1 – probleemi tabas varjujaotus. Soovitusmudel ületas testimisel vana. Leiti, et selle käitamine tootmisliiklusega varirežiimis andis teatud kasutajasegmendile (uutele kasutajatele) väga halbu soovitusi – testiandmed olid selle segmendi jaoks alaesindatud. Mudel fikseeriti, ilma et seda oleks kunagi kasutajale kuvatud. Kui see avataks otse, oleks uus kasutajakogemus häiritud.
2. juhtum – tühistamatu levitamine. Meeskond võttis kogu liikluse jaoks kasutusele uue hinnamudeli, ilma tagasipööramisplaanideta. Mudel pani mõne toote ootamatult väga odavalt hinda. Vanale versioonile naasmine võttis tunde, kuna protsess polnud valmis. Oli tõsine sissetuleku kaotus. Hiljem lisati igale kasutuselevõtule kohustuslik tagasipööramistestimine.
Juhtum 3 – vaikne andmetriiv. Pettusmuster ilmus mitu kuud ilma ühegi veata. Kuid petturite taktika muutus (andmete triiv) ja mudeli tagasikutsumine langes vaikselt. Keegi ei märganud, sest järelevalvet polnud. Kui prognoositava leviku seirepaneel oli loodud, muutus triiv varakult nähtavaks. Jälgime 8. üksuses.
Kopeeritavad mallid
Kirjutage selle mudeli juurutusplaani mustand. Mudel: [mida see teeb], kasutus: [veebis või partii?] Peaks sisaldama: 1) pakkimist (konteiner, versioonide loomine) 2) järkjärgulist juurutamise strateegiat (vari/kanaari/A-B) ja miks3) jälgitavad mõõdikud (äri + tehniline + latentsus) 4) tagasipööramisplaan ja kuidas testida5) juurutamine peaks ületama künniseid (milliseid väärtusi)
Kontrollige seda ML CI/CD konveieri:1) Kas andmete valideerimine on real?2) Kas juurutamine võib jätkuda hindamisläve hoidmata (kas ei peaks)?3) Kas tagasipööramine on automaatne?4) Kas andmeid+koodi+mõõdikuid jälgitakse mudeliregistris?Pliini konfiguratsioon: [config]
Aidake mul otsustada, kas selle mudeli jaoks sobib veebipõhine või partii esitlus. Kui kaua tulemust kasutatakse: [kiire / minut / tund / päev]Oodatav päringu maht: [arv]Kas on viivituspiirang: [ms]Millist soovitaksite kulude ja keerukuse seisukohalt ning miks?
Kirjutage selle mudeli jaoks tagasipööramise protseduur.- Milline mõõdik/lävi põhjustab kehva jõudluse?- Millised on tagasivõtmise sammud?- Kui kaua peaks tagasipööramine aega võtma (sihtmärk)?- Kuidas seda protseduuri enne tootmist testida?
Esitlusmustri tabel
kriteerium
Internetis (reaalajas)
Partii
viivitus
Kriitiline (ms)
tähtsusetu
Kasutamine
Vajalik kohene reageerimine
Perioodiline skoor
Maksumus
kõrge
madal
keerukus
kõrge
madal
näide
Reaalajas soovitus, pettus
Igakuine riskiskoor
Levinud vead
- Levitage ilma väljavõtmisplaanita. Vale mudel tabab kogu kasutajat.
- Avatakse otse 100% liiklusele. Piirake riski astmelise jaotusega.
- Järelevalvet ei kehtestata. Mudel tekitab vigu vaikselt, vigadeta.
- Üleliigne reaalajas esitlus. Kuigi partiide komplekteerimine on piisav, paisuvad kulud ja keerukus.
- Mudeli-andmete-koodi versioone ei seostata. Te ei saa probleemi taasesitada.
- Automaatne vabastamine ilma levitamisläveta. Halb modell hiilib vaikselt sisse.
Kokkuvõttes
Mudeli tootmisse viimine on teistsugune ja sageli keerulisem inseneriülesanne kui selle väljaõpe. ML nõuab täiendavat distsipliini, sest see sõltub koodi-andmete-mudeli kolmikust: pakkimine ja versioonide koostamine, ärivajadustele vastav tarnemuster (veebis/partii), järkjärguline ja pöörduv juurutamine, lävega juhitav CI/CD ja mudeli registreerimine. Tehisintellekt on selle infrastruktuuri koodi ja konfiguratsiooni loomisel võimas abivahend; kuid levikünnised, tagasinõudmispoliitika ja riskiotsused on teie. Ilma tagasipööramisplaanita levitamine ei ole täielik.
Rakenduse ülesanne
Konteinerige (Docker) mudel ja märgistage selle versioon. Otsustage, kas pakute oma ettevõtte vajadustest lähtuvalt veebipõhist pakkumist või komplekti, ja kirjutage oma põhjendus. Dokumenteerige etapiviisiline kasutuselevõtuplaan (vari või kanaarilind) ja testitud tagasipööramise protseduur. Kindlasti salvestage mudeliregistrisse andmete versioon, koodi kinnitamine ja hindamisskoorid.
kontrollnimekiri
- [ ] Mudel on pakendatud ja versioonidega (konteiner + silt).
- [ ] Esitlusmuster (veebis/partii) valiti vastavalt ärivajadusele.
- [ ] Rakendatud on etapiviisilise kasutuselevõtu strateegia (vari/kanaarilind).
- [ ] Tagasipööramisprotseduur on kirjutatud ja testitud.
- [ ] CI/CD ei vii kasutuselevõttu edasi enne, kui hindamislävi on täidetud.
- [ ] Mudeliregister sisaldab linki andmed+kood+meetriline link.