Dobici:
- Sposobnost prepoznavanja posebnih izazova ML-a povezanih s triom kod-podaci-model i paketom te predstavljanje modela online ili u paketu prema poslovnim potrebama.
- Sposobnost implementacije postupnih i povratnih obrazaca implementacije (sjena, kanarinac, A/B, vraćanje) i dodavanje testiranog plana vraćanja svakoj implementaciji
- Sposobnost održavanja veze podataka-koda-metrike modela stavljenog u proizvodnju sljedivom pomoću CI/CD-a kontroliranog pragom evaluacije i registra modela
Natjerati model da postigne 95% točnosti u prijenosnom računalu samo je pola priče. Druga polovica—često teži dio—dostavljanje tog modela pravim korisnicima na pouzdan, skalabilan način koji se može održavati. MLOps (Operacije strojnog učenja: disciplina stavljanja, rada i održavanja ML modela u proizvodnju) kombinira DevOps praksu softverskog inženjeringa s jedinstvenim izazovima ML-a. U ovoj jedinici pokrivamo korake premještanja modela u proizvodnju i kako umjetna inteligencija pomaže u tom procesu.
Zašto se ML razlikuje od običnog softvera?
U običnom softveru, ponašanje je u kodu; Ako se kôd ne promijeni, ponašanje se ne mijenja. U ML-u ponašanje ovisi o kodu, podacima i modelu. Ove tri dimenzije stvaraju dodatne izazove MLO-a:
- Odstupanje podataka: Podaci u proizvodnji se s vremenom udaljavaju od podataka u obuci; model postaje zastario.
- Morate verzirati tri stvari: kod, podatke i model—sve tri.
- Tihi kvar: Model može pasti bez pada, bez davanja pogrešaka, jednostavno stvaranjem netočnih predviđanja. Uhvatiti ovo zahtijeva nadzor.
Zato postoji velika razlika između "radnog modela" i "modela spremnog za proizvodnju".
Pakiranje i prezentacija modela
Prvi korak u stavljanju modela u proizvodnju je njegovo pakiranje: datoteka modela, potrebne biblioteke, kod za pretprocesiranje i informacije o verziji zajedno u reproducibilnu cjelinu. Kontejnerizacija (npr. Docker: stavljanje aplikacije u izoliranu kutiju sa svim njenim ovisnostima) ovdje je standardna; Uklanja problem "radio je na mom stroju".
Dva osnovna obrasca posluživanja modela:
- Online/u stvarnom vremenu (online): Model se nalazi iza API-ja, vraćajući trenutno predviđanje za svaki dolazni zahtjev. Niska latencija je kritična.
- Skupina: model povremeno obrađuje velike skupove podataka (npr. generira rezultate za sve kupce noću). Latencija je nevažna, važna je učinkovitost.
Koji je pravi ovisi o poslovnim potrebama: trenutna preporuka na mreži, mjesečni rezultat rizika u seriji.
Savjet: "U stvarnom vremenu" je cijena, a ne zadana vrijednost. Serija je mnogo jeftinija i jednostavnija ako se rezultat iskoristi unutar nekoliko sati. Trebate li stvarno trenutni odgovor? Prvo to pitaj.
Sigurne strategije distribucije
Otvaranje novog modela izravno cijelom prometu je riskantno; Ako je krivo, pogođeni su svi. Sigurni obrasci distribucije:
- Primjena u sjeni: novi model prima proizvodni promet, ali se njegova predviđanja ne prikazuju korisniku, već se samo bilježe. Uspoređuje se sa starim modelom da se vidi je li siguran u stvarnim podacima.
- Implementacija Canaryja: novi model prvo se uvodi u mali postotak prometa (npr. 5%); Ako nema problema, postupno se povećava.
- A/B testiranje: Stvarnom korisniku paralelno se prikazuju dva modela i uspoređuju se poslovne metrike (konverzija, klikovi).
- Vraćanje: Mogućnost brzog vraćanja na staru verziju ako se novi model pokaže lošim. Svaka implementacija treba imati plan vraćanja.
Oprez: implementacija bez plana vraćanja nije dovršena. Mogućnost vraćanja na staru verziju u roku od nekoliko minuta štiti korisnika kada se novi model ponaša neočekivano u proizvodnji. Testirajte ovo prije postavljanja.
Slab pristup / Jak pristup
Slab: "Model je bio dobar na testiranju, pokrenuli smo ga uživo, otvorili smo ga svima."
Güçlü: "Model smo spremili u spremnik, označili ga kao verziju. Prvo smo ga pokrenuli u načinu rada u sjeni s proizvodnim prometom 3 dana, uspoređujući predviđanja sa starim modelom — odstupanje je bilo prihvatljivo. Zatim smo ga otvorili s 5% canary, pratili metriku protoka i latenciju. Kad nije bilo problema, postupno smo ga povećali na 100%. Prethodno smo testirali naredbu vraćanja."
Razlika: snažan pristup je postupan, odmjeren i reverzibilan. Rizik je ograničen na svakom koraku.
CI/CD i automatizacija
CI/CD (Continuous Integration/Continuous Deployment: cjevovod automatskog testiranja i objavljivanja promjena koda) u ML-u ne pokriva samo kod već i podatke i korake modela. Dobar ML CI/CD cjevovod: pokreće testove kada se kôd promijeni, provodi provjeru valjanosti podataka, ponovno obučava model (ako je potrebno), provjerava pragove evaluacije i unaprjeđuje implementaciju samo ako su pragovi održivi. Načelo "obuka je automatska, implementacija se temelji na pragu" sprječava da loš model tiho procuri u proizvodnju.
AI je od velike pomoći pri postavljanju ovih cjevovoda: pisanje nacrta konfiguracijske datoteke (YAML), testnih slučajeva, skripti za implementaciju. Ali vi određujete pragove distribucije (ma koja metrika premašuje objavljenu vrijednost) i politiku vraćanja; to su odluke o poslovnom riziku.
Infrastruktura ponovljivosti
Kako bi se reproduciralo ponašanje modela u proizvodnji, registar modela: zapis koji čuva koji model je obučen s kojim podacima i kodom te koju je metriku primio. Za svaki proizvodni model trebalo bi se moći pratiti sljedeće: verzija podataka o obuci, verzija koda (git commit), hiperparametri, rezultati evaluacije i datum implementacije. Kada se pojavi problem, trebali biste moći odgovoriti na pitanje "koji je model proizveo ovo predviđanje, s kojim podacima?" u roku od nekoliko minuta. Ovo ćemo produbiti u jedinici 11.
tri mini kućišta
Slučaj 1 - Problem uhvaćen distribucijom sjene. Model preporuke pobijedio je stari u testiranju. Utvrđeno je da njegovo pokretanje s produkcijskim prometom u načinu rada u sjeni daje vrlo loše preporuke za određeni segment korisnika (nove korisnike) — testni podaci nisu bili dovoljno reprezentativni za ovaj segment. Model je popravljen, a da nije prikazan korisniku. Ako bi se otvorio izravno, novo bi korisničko iskustvo bilo poremećeno.
Slučaj 2 - Neopoziva raspodjela. Tim je uveo novi model određivanja cijena za sav promet, bez planova vraćanja. Model je neočekivano neke proizvode cijenio vrlo jeftino. Vraćanje na staru verziju trajalo je satima jer proces nije bio spreman. Došlo je do ozbiljnog gubitka prihoda. Nakon toga, obavezno testiranje vraćanja dodano je svakoj implementaciji.
Slučaj 3 - Tiho pomicanje podataka. Mjesecima se pojavljivao obrazac prijevare bez ikakvih grešaka. Ali taktika prevaranata se promijenila (drift podataka) i opoziv modela tiho je pao. Nitko nije primijetio jer nije bilo nadzora. Nakon što je uspostavljena ploča za praćenje distribucije prognoze, pomak je postao rano vidljiv. Obradit ćemo praćenje u jedinici 8.
Predlošci koji se mogu kopirati
Napišite nacrt plana implementacije za ovaj model. Model: [što radi], upotreba: [online ili batch?] Treba uključiti: 1) Pakiranje (spremnik, verzija) 2) Inkrementalnu strategiju implementacije (shadow/canary/A-B) i zašto 3) Mjerne podatke za praćenje (poslovni + tehnički + latencija) 4) Plan vraćanja i kako testirati 5) Pragove implementacije (koji bi pokazatelj trebao premašiti koju vrijednost)
Provjerite ovaj ML CI/CD cjevovod:1) Je li provjera valjanosti podataka u redu?2) Može li se implementacija nastaviti bez zadržavanja praga evaluacije (treba li)?3) Je li vraćanje na staro stanje automatsko?4) Prate li se podaci+kod+metrika u registru modela?Pline konfiguracija: [config]
Pomozite mi da odlučim je li mrežna ili skupna prezentacija prikladna za ovaj model. Koliko dugo će se koristiti rezultat: [trenutak / minuta / sat / dan] Očekivani volumen zahtjeva: [broj] Postoji li ograničenje odgode: [ms] Koji biste preporučili u smislu cijene i složenosti i zašto?
Napišite proceduru vraćanja za ovaj model.- Koja metrika/prag izaziva lošu izvedbu?- Koji su koraci vraćanja?- Koliko bi trebalo trajati vraćanje (cilj)?- Kako testirati ovu proceduru prije proizvodnje?
Tablica uzoraka prezentacije
kriterij
Online (stvarno vrijeme)
Serija
kašnjenje
Kritično (ms)
neznatan
Korištenje
Potreban je trenutni odgovor
Periodični rezultat
trošak
visoka
nizak
složenost
visoka
nizak
primjer
Preporuka uživo, prevara
Mjesečni rezultat rizika
Uobičajene greške
- Distribuirajte bez plana preuzimanja. Pogrešan model pogađa cijelog korisnika.
- Otvaranje direktno na 100% promet. Ograničite rizik uz postupnu distribuciju.
- Ne uspostavljanje nadzora. Model proizvodi greške tiho, bez greške.
- Redundantna prezentacija u stvarnom vremenu. Dok je grupiranje dovoljno, troškovi i složenost rastu.
- Bez povezivanja verzija modela-podataka-koda. Ne možete reproducirati problem.
- Automatsko puštanje bez praga distribucije. Loš model se nečujno ušulja.
Ukratko
Premještanje modela u proizvodnju drugačiji je i često teži inženjerski zadatak od osposobljavanja. ML zahtijeva dodatnu disciplinu jer ovisi o trojcu kod-podaci-model: pakiranje i verzija, obrazac isporuke (online/serija) koji odgovara poslovnim potrebama, postupna i reverzibilna implementacija, CI/CD s kontrolom praga i registracija modela. Umjetna inteligencija moćna je pomoć u generiranju koda i konfiguracije ove infrastrukture; ali pragovi distribucije, politika povrata i odluke o riziku su vaše. Distribucija bez plana vraćanja nije potpuna.
Zadatak aplikacije
Spremite (Docker) model i označite njegovu verziju. Odlučite hoćete li nuditi online ili paketno na temelju svojih poslovnih potreba i napišite obrazloženje. Dokumentirajte plan implementacije u fazama (shadow ili canary) i testiranu proceduru vraćanja. Obavezno zabilježite verziju podataka, predaju koda i rezultate evaluacije u registru modela.
popis za provjeru
- [ ] Model je pakiran i verziran (spremnik + naljepnica).
- [ ] Uzorak prezentacije (online/serija) odabran je prema poslovnim potrebama.
- [ ] Implementirana strategija postupnog postavljanja (sjena/kanarinac).
- [ ] Postupak vraćanja na staro stanje napisan i testiran.
- [ ] CI/CD ne napreduje u implementaciji prije nego što se dostigne prag evaluacije.
- [ ] Registar modela sadrži vezu podaci+kod+metrika.