Pelnas:
- Gebėjimas atpažinti ypatingus ML iššūkius, susijusius su kodo-duomenų-modelio trejetu ir paketu, ir pristatyti modelį internete arba partijomis pagal verslo poreikį.
- Galimybė įgyvendinti laipsniško ir atšaukimo diegimo modelius (šešėlis, kanarėlė, A/B, atšaukimas) ir prie kiekvieno diegimo pridėti išbandytą atšaukimo planą.
- Galimybė išlaikyti modelio, pradėto gaminti, duomenų kodo ir metrinės sąsajos atsekimą naudojant įvertinimo slenkstį valdomą CI / CD ir modelių registrą
Gauti modelį, kad būtų pasiektas 95 % tikslumas nešiojamajame kompiuteryje, yra tik pusė istorijos. Kita pusė – dažnai sudėtingiausia – yra patikimas, keičiamo dydžio ir prižiūrimas šio modelio pateikimas tikriems vartotojams. MLOps (Machine Learning Operations: ML modelių diegimo, valdymo ir priežiūros disciplina) sujungia programinės įrangos inžinerijos DevOps praktiką su unikaliais ML iššūkiais. Šiame skyriuje aprašome modelio perkėlimo į gamybą etapus ir kaip dirbtinis intelektas padeda šiame procese.
Kodėl ML skiriasi nuo įprastos programinės įrangos?
Įprastoje programinėje įrangoje elgsena yra kode; Jei kodas nesikeičia, elgsena nesikeičia. ML elgsena priklauso nuo kodo, duomenų ir modelio. Šie trys aspektai sukuria papildomus MLOps iššūkius:
- Duomenų poslinkis: gamyboje naudojami duomenys laikui bėgant tolsta nuo mokymo duomenų; modelis pasensta.
- Turite versti tris dalykus: kodą, duomenis ir modelį – visus tris.
- Tylus gedimas: modelis gali sugesti nesuduždamas, nepateikdamas klaidų, tiesiog pateikdamas neteisingas prognozes. Norint tai sugauti, reikia stebėti.
Štai kodėl yra didelis skirtumas tarp „veikiančio modelio“ ir „gamybai paruošto modelio“.
Modelių pakavimas ir pristatymas
Pirmasis modelio gamybos etapas yra jo supakavimas: modelio failas, būtinos bibliotekos, išankstinio apdorojimo kodas ir versijos informacija kartu kaip atkuriama visuma. Konteineris (pvz., „Docker“: programos įdėjimas į izoliuotą dėžutę su visomis jos priklausomybėmis) čia yra standartinis; Tai pašalina problemą „jis veikė mano mašinoje“.
Du pagrindiniai modelio aptarnavimo modeliai:
- Prisijungę / realiuoju laiku (internete): modelis yra už API ir pateikia momentinį kiekvienos gaunamos užklausos numatymą. Mažas delsos laikas yra labai svarbus.
- Paketas: modelis periodiškai apdoroja didelius duomenų rinkinius (pvz., naktį generuoja balus visiems klientams). Vėlavimas nesvarbus, svarbu efektyvumas.
Kuris yra teisingas, priklauso nuo verslo poreikio: momentinė rekomendacija internete, mėnesio rizikos balas partijomis.
Patarimas: „Realus laikas“ yra mokestis, o ne numatytasis. Partija yra daug pigesnė ir paprastesnė, jei rezultatas bus panaudotas per kelias valandas. Ar jums tikrai reikia greito atsakymo? Pirmiausia to paklausk.
Saugios platinimo strategijos
Naujo modelio atidarymas tiesiogiai visam srautui yra rizikingas; Jei negerai, nukenčia visi. Saugūs platinimo būdai:
- Šešėlinis diegimas: naujas modelis gauna gamybos srautą, tačiau jo prognozės vartotojui nerodomos, tik registruojamos. Jis lyginamas su senuoju modeliu, siekiant išsiaiškinti, ar jis yra saugus realiuose duomenyse.
- Kanarų diegimas: naujasis modelis pirmą kartą išleidžiamas nedideliam srauto procentui (pvz., 5 proc.); Jei nėra problemų, jis palaipsniui didinamas.
- A/B testavimas: Tikram vartotojui lygiagrečiai pateikiami du modeliai ir lyginamos verslo metrikos (konversija, paspaudimai).
- Atšaukimas: Galimybė greitai grįžti prie senosios versijos, jei naujasis modelis pasirodys blogas. Kiekvienas diegimas turi turėti atkūrimo planą.
Įspėjimas: Diegimas be atšaukimo plano nėra baigtas. Galimybė per kelias minutes grįžti prie senosios versijos apsaugo vartotoją, kai naujas modelis gamyboje elgiasi netikėtai. Išbandykite tai prieš įdiegdami.
Silpnas požiūris / Stiprus požiūris
Silpnas: „Modelis buvo geras testuojant, mes pradėjome tiesiogiai, atvėrėme jį visiems“.
Güçlü: "Surinkome modelį į konteinerius, pažymėjome jį kaip versiją. Pirma, 3 dienas paleidome jį šešėliniu režimu su gamybos srautu, palygindami prognozes su senuoju modeliu – nuokrypis buvo priimtinas. Tada atidarėme jį naudodami 5% canary, stebėjome pralaidumo metriką ir delsą. Kai nebuvo problemų, palaipsniui padidinome jį iki 100%. Prieš tai buvo komanda išbandyta.
Skirtumas: stiprus požiūris yra laipsniškas, išmatuotas ir grįžtamas. Rizika yra ribota kiekviename žingsnyje.
CI/CD ir automatika
CI/CD (Continuous Integration / Continuous Deployment: automatinio testavimo ir kodo pakeitimų išleidimo vamzdynas) ML apima ne tik kodą, bet ir duomenų bei modelio veiksmus. Geras ML CI/CD konvejeris: atlieka bandymus, kai kodas pasikeičia, atlieka duomenų patvirtinimą, perkvalifikuoja modelį (jei reikia), tikrina vertinimo slenksčius ir tik tuo atveju, jei slenksčiai išlieka, pažanga diegimas. Principas „mokymas yra automatinis, diegimas pagrįstas slenksčiu“ neleidžia blogam modeliui tyliai nutekėti į gamybą.
AI labai padeda nustatyti šiuos konvejerius: rašant konfigūracijos failo (YAML) juodraščius, bandomuosius atvejus, diegimo scenarijus. Bet jūs nustatote platinimo slenksčius (nesvarbu, kokia metrika viršija paskelbtą vertę) ir atšaukimo politiką; tai verslo rizikos sprendimai.
Atkuriamumo infrastruktūra
Siekiant atkurti modelio elgseną gamyboje, modelių registras: įrašas, kuriame saugomas, kuris modelis buvo apmokytas su kokiais duomenimis ir kodu ir kokia metrika jis buvo gautas. Kiekvienam gamybos modeliui turėtų būti stebima: mokymo duomenų versija, kodo versija (git commit), hiperparametrai, įvertinimo balai ir įdiegimo data. Iškilus problemai, turėtumėte atsakyti į klausimą „kuris modelis sukūrė šią prognozę, su kokiais duomenimis? per minutes. Tai pagilinsime 11 skyriuje.
trys mini dėklai
1 atvejis – problemą užklupo šešėlių pasiskirstymas. Rekomendacinis modelis bandymų metu pranoko senąjį. Nustatyta, kad naudojant gamybinį srautą šešėliniu režimu buvo pateiktos labai prastos rekomendacijos tam tikram vartotojų segmentui (naujiems naudotojams) – bandymo duomenys buvo nepakankamai reprezentatyvūs šiam segmentui. Modelis buvo pataisytas vartotojui jo nerodant. Jei jis būtų atidarytas tiesiogiai, nauja vartotojo patirtis būtų sutrikdyta.
2 atvejis – neatšaukiamas platinimas. Komanda pristatė naują kainodaros modelį, skirtą visam srautui, be jokių grąžinimo planų. Modelis kai kuriuos gaminius netikėtai kainavo labai pigiai. Grįžimas į seną versiją užtruko valandas, nes procesas nebuvo paruoštas. Buvo rimtai prarastos pajamos. Vėliau prie kiekvieno diegimo buvo pridėtas privalomas atšaukimo bandymas.
3 atvejis – tylus duomenų nukrypimas. Sukčiavimo modelis pasirodė kelis mėnesius be jokių klaidų. Tačiau sukčių taktika pasikeitė (duomenų dreifas) ir modelio atšaukimas tyliai sumažėjo. Niekas nepastebėjo, nes nebuvo stebėjimo. Sukūrus prognozės pasiskirstymo stebėjimo skydelį, dreifas tapo matomas anksti. Stebėsime 8 skyriuje.
Kopijuojami šablonai
Parašykite šio modelio diegimo plano projektą. Modelis: [ką jis veikia], naudojimas: [internete ar paketas?] Turėtų apimti: 1) pakuotę (konteinerį, versijų kūrimą) 2) laipsnišką diegimo strategiją (šešėlis / kanarėlė / A-B) ir kodėl3) metrika, kurią reikia stebėti (verslas + techninis + delsa) 4) grąžinimo planas ir kaip išbandyti 5) Diegimo kiekis turėtų viršyti ribą (kuris)
Patikrinkite šį ML CI/CD konvejerį:1) Ar eilutėje yra duomenų patvirtinimas?2) Ar diegimas gali vykti nesilaikant vertinimo slenksčio (ar ne)?3) Ar grąžinimas yra automatinis?4) Ar modelio registre stebimi duomenys+kodas+metrika?Pline konfigūracija: [config]
Padėkite man nuspręsti, ar internetinis ar paketinis pristatymas tinka šiam modeliui. Kiek laiko bus naudojamas rezultatas: [akimirksniu / minutė / valanda / diena]Numatyta užklausos apimtis: [skaičius]Ar yra delsos apribojimas: [ms]Kurią rekomenduotumėte dėl išlaidų ir sudėtingumo ir kodėl?
Parašykite šio modelio atšaukimo procedūrą.- Kokia metrika / slenkstis sukelia prastą našumą?- Kokie yra atšaukimo veiksmai?- Kiek laiko turėtų užtrukti atšaukimas (tikslas)?- Kaip išbandyti šią procedūrą prieš pradedant gaminti?
Pristatymo šablonų lentelė
kriterijus
Prisijungę (realiu laiku)
Partija
delsimas
Kritinis (ms)
nereikšmingas
Naudojimas
Reikalingas greitas atsakymas
Periodinis balas
Kaina
aukštas
žemas
sudėtingumo
aukštas
žemas
pavyzdys
Rekomendacija gyvai, sukčiai
Mėnesio rizikos balas
Dažnos klaidos
- Platinti be išgavimo plano. Netinkamas modelis paliečia visą vartotoją.
- Tiesiogiai atidaromas 100% srautas. Apribokite riziką laipsnišku paskirstymu.
- Stebėsenos nenustatymas. Modelis daro klaidas tyliai, be klaidų.
- Perteklinis pristatymas realiuoju laiku. Nors partijų pakanka, kaina ir sudėtingumas didėja.
- Nesusieja modelio duomenų kodo versijos. Negalite atkurti problemos.
- Automatinis išleidimas be platinimo slenksčio. Blogasis modelis tyliai įslenka.
Apibendrinant
Modelio perkėlimas į gamybą yra kitokia ir dažnai sunkesnė inžinerinė užduotis nei jo mokymas. ML reikalauja papildomos disciplinos, nes tai priklauso nuo kodo-duomenų-modelių trejeto: pakavimo ir versijų kūrimo, pristatymo modelio (internete / partijos), atitinkančio verslo poreikius, laipsniško ir grįžtamo diegimo, slenksčio valdomo CI / CD ir modelio registravimo. Dirbtinis intelektas yra galinga pagalba generuojant šios infrastruktūros kodą ir konfigūraciją; bet paskirstymo slenksčiai, susigrąžinimo politika ir rizikos sprendimai priklauso jums. Platinimas be atšaukimo plano nėra baigtas.
Taikymo užduotis
Sudėkite į konteinerį („Docker“) modelį ir pažymėkite jo versiją. Nuspręskite, ar siūlysite internetu, ar paketiniu būdu, atsižvelgdami į savo verslo poreikius, ir parašykite savo pagrindimą. Dokumentuokite etapinį diegimo planą (šešėlinį arba kanarinį) ir patikrintą atšaukimo procedūrą. Įsitikinkite, kad modelio registre įrašėte duomenų versiją, kodo patvirtinimą ir įvertinimo balus.
kontrolinis sąrašas
- [ ] Modelis supakuotas ir sukomplektuotas (konteineris + etiketė).
- [ ] Pristatymo modelis (internetinis/paketas) buvo pasirinktas pagal verslo poreikį.
- [ ] Įdiegta etapinio diegimo strategija (šešėlis/kanarėlė).
- [ ] Parašyta ir patikrinta atšaukimo procedūra.
- [ ] CI/CD nepaankstinu diegimo, kol nepasiekiama vertinimo slenkstis.
- [ ] Modelių registre yra duomenų+kodas+metrinė nuoroda.