Câștiguri:
- Abilitatea de a recunoaște provocările speciale ale ML legate de trio-ul cod-date-model și de a prezenta modelul online sau în lot, în funcție de nevoia afacerii.
- Abilitatea de a implementa modele de implementare graduală și de rollback (umbră, canary, A/B, rollback) și de a adăuga un plan de rollback testat la fiecare implementare
- Capacitatea de a păstra legătura de date-cod-metric a modelului pus în producție urmăribilă cu CI/CD controlat de prag de evaluare și registru de model
Obținerea unui model pentru a obține o precizie de 95% în notebook este doar jumătate din poveste. Cealaltă jumătate – deseori partea grea – este aducerea acestui model către utilizatori reali într-un mod fiabil, scalabil și care poate fi întreținut. MLOps (Machine Learning Operations: disciplina de punere, operare și menținere a modelelor ML în producție) combină practicile DevOps ale ingineriei software cu provocările unice ale ML. În această unitate, acoperim pașii de mutare a modelului în producție și modul în care inteligența artificială ajută în acest proces.
De ce este ML diferit de software-ul obișnuit?
În software-ul obișnuit, comportamentul este în cod; Dacă codul nu se schimbă, comportamentul nu se schimbă. În ML, comportamentul depinde atât de cod, de date, cât și de model. Aceste trei dimensiuni creează provocările suplimentare ale MLOps:
- Derivarea datelor: datele din producție se îndepărtează de datele din antrenament în timp; modelul devine învechit.
- Trebuie să versionați trei lucruri: cod, date și model - toate trei.
- Eșec silențios: un model poate eșua fără să se prăbușească, fără a da erori, pur și simplu prin producerea de predicții incorecte. Prinderea acestui lucru necesită monitorizare.
De aceea există o mare diferență între un „model de lucru” și un „model gata de producție”.
Ambalare si prezentare model
Primul pas în introducerea modelului în producție este împachetarea acestuia: fișierul model, bibliotecile necesare, codul de preprocesare și informațiile despre versiune împreună ca un întreg reproductibil. Containerizarea (de exemplu, Docker: punerea aplicației într-o casetă izolată cu toate dependențele sale) este standard aici; Elimină problema „funcționa la mașina mea”.
Două modele de bază de servire a modelului:
- Online/în timp real (online): modelul se află în spatele unui API, returnând o predicție instantanee pentru fiecare solicitare primită. Latența scăzută este critică.
- Lot: modelul procesează seturi mari de date periodic (de exemplu, generează scoruri pentru toți clienții pe timp de noapte). Latența este irelevantă, eficiența este importantă.
Care este corect depinde de nevoia afacerii: recomandare instantanee online, scor lunar de risc în lot.
Sfat: „În timp real” este un cost, nu implicit. Lotul este mult mai ieftin și mai simplu dacă rezultatul va fi folosit în câteva ore. Chiar ai nevoie de un răspuns instantaneu? Întreabă asta mai întâi.
Strategii de distribuție sigure
Deschiderea unui nou model direct către tot traficul este riscantă; Dacă este greșit, toată lumea este afectată. Modele de distribuție sigure:
- Implementare în umbră: noul model primește trafic de producție, dar previziunile sale nu sunt afișate utilizatorului, ci doar înregistrate. Se compară cu modelul vechi pentru a vedea dacă este sigur în datele reale.
- Implementarea Canary: noul model este mai întâi implementat la un procent mic din trafic (de exemplu, 5%); Dacă nu există nicio problemă, aceasta crește treptat.
- Testare A/B: Două modele sunt prezentate utilizatorului real în paralel și sunt comparate valorile de afaceri (conversie, clicuri).
- Rollback: capacitatea de a reveni rapid la versiunea veche dacă noul model se dovedește a fi prost. Fiecare implementare ar trebui să aibă un plan de rollback.
Atenție: O implementare fără un plan de rollback nu este completă. Posibilitatea de a reveni la versiunea veche în câteva minute protejează utilizatorul atunci când noul model se comportă neașteptat în producție. Testați acest lucru înainte de implementare.
Abordare slabă / Abordare puternică
Slab: „Modelul a fost bun la testare, am intrat live, l-am deschis tuturor”.
Güçlü: "Am containerizat modelul, l-am etichetat ca versiune. Mai întâi, l-am rulat în modul umbră cu trafic de producție timp de 3 zile, comparând previziunile cu modelul vechi — deviația a fost acceptabilă. Apoi l-am deschis cu 5% canary, am monitorizat metrica de debit și latența. Când nu au fost probleme, am crescut treptat până la 100%.
Diferența: abordarea puternică este graduală, măsurată și reversibilă. Riscul este limitat la fiecare pas.
CI/CD și automatizare
CI/CD (Continuous Integration / Continuous Deployment: conductă de testare automată și eliberare a modificărilor de cod) în ML acoperă nu numai codul, ci și pașii de date și model. O conductă bună ML CI/CD: rulează teste când codul se modifică, efectuează validarea datelor, reantrenează modelul (dacă este necesar), verifică pragurile de evaluare și avansează implementarea doar dacă pragurile sunt valabile. Principiul „antrenamentul este automat, implementarea se bazează pe prag” previne scurgerea în tăcere a modelului prost în producție.
AI este foarte utilă la configurarea acestor conducte: scrierea schițelor fișierelor de configurare (YAML), cazuri de testare, scripturi de implementare. Dar determinați pragurile de distribuție (indiferent de valoarea care depășește valoarea publicată) și politica de rollback; acestea sunt decizii de risc de afaceri.
Infrastructura de reproductibilitate
Pentru a reproduce comportamentul unui model în producție, registru de modele: o înregistrare care păstrează ce model a fost antrenat cu ce date și cod și ce metrici a primit. Pentru fiecare model de producție, următoarele ar trebui să fie urmăribile: versiunea datelor de antrenament, versiunea codului (git commit), hiperparametrii, scorurile de evaluare și data implementării. Când apare o problemă, ar trebui să puteți răspunde la întrebarea „ce model a produs această predicție, cu ce date?” în câteva minute. Vom aprofunda acest lucru în unitatea 11.
trei mini cutii
Cazul 1 - Problemă surprinsă de distribuția umbră. Un model de recomandare l-a depășit pe cel vechi la testare. S-a constatat că rularea acestuia cu trafic de producție în modul umbră produce recomandări foarte slabe pentru un anumit segment de utilizatori (utilizatori noi) - datele de testare erau subreprezentative pentru acest segment. Modelul a fost reparat fără a fi niciodată afișat utilizatorului. Dacă ar fi deschis direct, noua experiență de utilizator ar fi perturbată.
Cazul 2 - Distribuție irevocabilă. O echipă a lansat un nou model de prețuri pentru tot traficul, fără planuri de returnare. Modelul a prețuit în mod neașteptat unele produse foarte ieftin. Revenirea la versiunea veche a durat ore, deoarece procesul nu era gata. S-a produs o pierdere serioasă de venituri. Ulterior, testarea de rollback obligatorie a fost adăugată la fiecare implementare.
Cazul 3 - Derivare silențioasă a datelor. Un model de fraudă a apărut luni de zile fără erori. Dar tacticile escrocilor s-au schimbat (deriva de date) și rechemarea modelului a scăzut în tăcere. Nimeni nu a observat pentru că nu a fost monitorizat. Odată ce a fost înființat un panou de monitorizare a distribuției prognozate, deriva a devenit vizibilă devreme. Vom acoperi monitorizarea în unitatea 8.
Șabloane copiabile
Scrieți o schiță de plan de implementare pentru acest model. Model: [ce face], utilizare: [online sau lot?] Ar trebui să includă:1) Ambalare (container, versiuni)2) Strategie de implementare incrementală (umbră/canary/A-B) și de ce3) Valori de urmărit (afacere + tehnic + latență)4) Planul de rollback și modul de testare5) Pragurile de implementare ar trebui să depășească (whi valoare)
Verificați această conductă ML CI/CD:1) Validarea datelor este în linie?2) Se poate desfășura implementarea fără a menține pragul de evaluare (nu ar trebui)?3) Rollback-ul este automat?4) Datele+codul+metricile sunt urmărite în registrul modelului? Configurația liniei: [config]
Ajutați-mă să decid dacă prezentarea online sau în lot este potrivită pentru acest model. Cât timp va fi folosit rezultatul: [instant / minut / oră / zi]Volumul de solicitare așteptat: [număr]Există o constrângere de întârziere: [ms]Pe care ați recomanda-o în ceea ce privește costul și complexitatea și de ce?
Scrieți o procedură de rollback pentru acest model.- Ce măsurătoare/prag declanșează o performanță slabă?- Care sunt pașii de rollback?- Cât ar trebui să dureze rollback-ul (ținta)?- Cum testez această procedură înainte de producție?
Tabel model de prezentare
criteriu
Online (în timp real)
lot
întârziere
Critic (ms)
nesemnificativ
Utilizare
Este necesar un răspuns instantaneu
Scorul periodic
Cost
înalt
scăzută
complexitate
înalt
scăzută
exemplu
Recomandare live, înșelătorie
Scorul lunar de risc
Greșeli comune
- Distribuiți fără un plan de recuperare. Modelul greșit lovește întregul utilizator.
- Deschidere direct la trafic 100%. Limitați riscul cu distribuție eșalonată.
- Nestabilirea monitorizării. Modelul produce erori în tăcere, fără eroare.
- Prezentare redundantă în timp real. În timp ce lotizarea este suficientă, costurile și complexitatea cresc.
- Nu se conectează versiunile model-date-cod. Nu puteți reproduce problema.
- Eliberare automată fără prag de distribuție. Modelul rău se strecoară în tăcere.
Pe scurt
Mutarea modelului în producție este o sarcină de inginerie diferită și adesea mai dificilă decât formarea lui. ML necesită o disciplină suplimentară, deoarece depinde de trio-ul cod-date-model: ambalare și versiuni, model de livrare (online/loturi) care se potrivește nevoilor afacerii, implementare treptată și reversibilă, CI/CD controlat de prag și înregistrarea modelului. Inteligența artificială este un ajutor puternic în generarea codului și configurației acestei infrastructuri; dar pragurile de distribuție, politica de clawback și deciziile de risc sunt ale tale. O distribuție fără un plan de rollback nu este completă.
Sarcina de aplicare
Containerizați (Docker) un model și etichetați-i versiunea. Decideți dacă veți oferi online sau în lot în funcție de nevoile dvs. de afaceri și scrieți justificarea. Documentați un plan de implementare în etape (umbră sau canar) și o procedură de rollback testată. Asigurați-vă că înregistrați versiunea datelor, codul de comitere și scorurile de evaluare în registrul modelului.
lista de verificare
- [ ] Modelul este ambalat și versionat (container + etichetă).
- [ ] Modelul de prezentare (online/lot) a fost ales în funcție de nevoia afacerii.
- [ ] Strategia de implementare în etape (umbră/canar) implementată.
- [ ] Procedura de rollback scrisă și testată.
- [ ] CI/CD nu avansează implementarea înainte de atingerea pragului de evaluare.
- [ ] Registrul modelului deține legătura date+cod+metric.