zisky:
- Schopnost rozpoznat speciální výzvy ML související s trojicí a balíčkem kód-data-model a prezentovat model online nebo v dávce podle obchodních potřeb.
- Schopnost implementovat postupné a rollback vzory nasazení (shadow, canary, A/B, rollback) a přidat testovaný plán vrácení ke každému nasazení
- Schopnost udržovat vazbu mezi datovým kódem a metrikou modelu uváděného do výroby sledovatelný pomocí CI/CD a registru modelů řízených prahem hodnocení
Získání modelu s 95% přesností v notebooku je jen polovina příběhu. Druhá polovina – často ta nejtěžší – je dostat tento model ke skutečným uživatelům spolehlivým, škálovatelným a udržovatelným způsobem. MLOps (Machine Learning Operations: disciplína zavádění, provozování a udržování modelů ML do produkce) kombinuje postupy softwarového inženýrství DevOps s jedinečnými výzvami ML. V této jednotce se zabýváme kroky přesunu modelu do výroby a tím, jak v tomto procesu pomáhá umělá inteligence.
Proč se ML liší od běžného softwaru?
V běžném softwaru je chování v kódu; Pokud se kód nezmění, nezmění se ani chování. V ML chování závisí na kódu, datech a modelu. Tyto tři dimenze vytvářejí další výzvy MLOps:
- Datový drift: Data ve výrobě se postupem času vzdalují od dat v tréninku; model se stává zastaralým.
- Potřebujete verzi tří věcí: Kód, data a model – všechny tři.
- Tiché selhání: Model může selhat bez zhroucení, bez uvedení chyb, jednoduše tím, že vytvoří nesprávné předpovědi. Chytání tohoto vyžaduje sledování.
Proto je velký rozdíl mezi „pracovním modelem“ a „modelem připraveným na výrobu“.
Balení a prezentace modelů
Prvním krokem při uvedení modelu do výroby je jeho zabalení: soubor modelu, potřebné knihovny, kód předběžného zpracování a informace o verzi dohromady jako reprodukovatelný celek. Kontejnerizace (např. Docker: umístění aplikace do izolovaného boxu se všemi jejími závislostmi) je zde standardní; Odstraňuje problém „fungovalo to na mém počítači“.
Dva základní vzorce obsluhy modelu:
- Online/v reálném čase (online): Model je umístěn za rozhraním API a vrací okamžitou předpověď pro každý příchozí požadavek. Nízká latence je kritická.
- Dávka: Model pravidelně zpracovává velké soubory dat (např. generuje skóre pro všechny zákazníky v noci). Latence je irelevantní, důležitá je efektivita.
Který z nich je správný, závisí na potřebě podniku: okamžité doporučení online, měsíční skóre rizika v dávce.
Tip: „V reálném čase“ je cena, nikoli výchozí hodnota. Dávka je mnohem levnější a jednodušší, pokud bude výsledek použit během několika hodin. Opravdu potřebujete okamžitou odpověď? To se zeptejte jako první.
Bezpečné distribuční strategie
Otevření nového modelu přímo pro veškerý provoz je riskantní; Pokud je to špatně, všichni jsou postiženi. Vzory bezpečné distribuce:
- Stínové nasazení: Nový model přijímá produkční provoz, ale jeho předpovědi se uživateli nezobrazují, pouze se zaprotokolují. Porovnává se se starým modelem, aby se zjistilo, zda je bezpečný v reálných datech.
- Nasazení Canary: Nový model je nejprve zaveden pro malé procento provozu (např. 5 %); Pokud není problém, postupně se zvyšuje.
- A/B testování: Reálnému uživateli jsou paralelně prezentovány dva modely a porovnávány obchodní metriky (konverze, kliknutí).
- Rollback: Schopnost rychle se vrátit ke staré verzi, pokud se ukáže, že nový model je špatný. Každé nasazení by mělo mít plán vrácení.
Upozornění: Nasazení bez plánu vrácení není dokončeno. Možnost vrátit se ke staré verzi během několika minut chrání uživatele, když se nový model ve výrobě chová neočekávaně. Před nasazením to vyzkoušejte.
Slabý přístup / Silný přístup
Slabý: "Model byl dobrý při testování, pustili jsme se do ostrého provozu, otevřeli jsme ho všem."
Güçlü: "Model jsme zabalili do kontejneru, označili jej jako verzi. Nejprve jsme jej spustili ve stínovém režimu s produkčním provozem po dobu 3 dnů, porovnali jsme předpovědi se starým modelem — odchylka byla přijatelná. Pak jsme jej otevřeli s 5% kanárkem, sledovali metriky propustnosti a latenci. Když nebyly žádné problémy, postupně jsme jej zvýšili na 100 %. Než jsme otestovali rollback."
Rozdíl: silný přístup je postupný, odměřený a reverzibilní. Riziko je omezeno na každém kroku.
CI/CD a automatizace
CI/CD (Continuous Integration / Continuous Deployment: pipeline automatického testování a uvolňování změn kódu) v ML pokrývá nejen kód, ale také data a kroky modelu. Dobrý kanál ML CI/CD: spouští testy, když se kód změní, provádí validaci dat, přeškoluje model (je-li to nutné), kontroluje prahové hodnoty vyhodnocení a posouvá nasazení, pouze pokud prahové hodnoty platí. Princip „školení je automatické, nasazení je založeno na prahu“ zabraňuje tichému úniku špatného modelu do výroby.
Umělá inteligence je velmi užitečná při nastavování těchto kanálů: psaní konceptů konfiguračních souborů (YAML), testovacích případů, skriptů nasazení. Ale určujete prahové hodnoty distribuce (bez ohledu na to, která metrika překračuje publikovanou hodnotu) a zásady vrácení zpět; to jsou rozhodnutí o podnikatelských rizicích.
Infrastruktura reprodukovatelnosti
Aby bylo možné reprodukovat chování modelu ve výrobě, registr modelu: záznam, který uchovává, který model byl trénován s jakými daty a kódem a které metriky obdržel. Pro každý produkční model by mělo být možné sledovat následující údaje: verze školicích dat, verze kódu (git commit), hyperparametry, skóre hodnocení a datum nasazení. Když nastane problém, měli byste být schopni odpovědět na otázku "který model vytvořil tuto předpověď, s jakými daty?" během několika minut. To prohloubíme v jednotce 11.
tři mini pouzdra
Případ 1 – Problém zachycený distribucí stínů. Model doporučení porazil v testování ten starý. Bylo zjištěno, že jeho spuštění s produkčním provozem ve stínovém režimu poskytuje velmi špatná doporučení pro určitý segment uživatelů (nové uživatele) – testovací data tento segment nereprezentovala. Model byl opraven, aniž by se uživateli kdy zobrazil. Pokud by byl otevřen přímo, byla by nová uživatelská zkušenost narušena.
Případ 2 – Neodvolatelná distribuce. Tým zavedl nový cenový model pro veškerý provoz bez plánů vrácení. Model nečekaně nacenil některé produkty velmi levně. Návrat ke staré verzi trval hodiny, protože proces nebyl připraven. Došlo k vážnému výpadku příjmů. Poté bylo do každého nasazení přidáno povinné rollback testování.
Případ 3 – Tichý posun dat. Vzorec podvodu se objevoval měsíce bez jakýchkoli chyb. Ale taktika podvodníků se změnila (únos dat) a stažení modelu tiše kleslo. Nikdo si toho nevšiml, protože nebyl žádný monitoring. Jakmile byl ustaven panel pro sledování předpovědní distribuce, byl posun brzy viditelný. Budeme pokrývat monitorování v bloku 8.
Kopírovatelné šablony
Napište návrh plánu nasazení pro tento model. Model: [co to dělá], použití: [online nebo dávkově?] Mělo by zahrnovat: 1) Balení (kontejner, verzování)2) Strategie přírůstkového nasazení (stín/kanárek/A-B) a proč3) Metriky ke sledování (obchodní + technické + latence)4) Plán vrácení a způsob testování5) Prahové hodnoty nasazení (která metrika by měla překročit jakou hodnotu)
Zkontrolujte tento kanál ML CI/CD:1) Je na řádku validace dat?2) Může nasazení pokračovat bez udržení prahu vyhodnocení (nemělo by to tak být)?3) Je automatické vrácení zpět?4) Jsou data+kód+metriky sledovány v registru modelu?Konfigurace Pline: [config]
Pomozte mi rozhodnout, zda je pro tento model vhodná online nebo dávková prezentace. Jak dlouho bude výsledek používán: [okamžitá / minuta / hodina / den] Očekávaný objem požadavku: [číslo] Existuje omezení zpoždění: [ms]Který byste doporučili z hlediska ceny a složitosti a proč?
Napište postup vrácení pro tento model.- Jaká metrika/prahová hodnota spouští špatný výkon?- Jaké jsou kroky vrácení?- Jak dlouho by mělo vrácení trvat (cíl)?- Jak otestuji tento postup před výrobou?
Tabulka vzorů prezentace
kritérium
Online (v reálném čase)
Dávka
zpoždění
kritické (ms)
bezvýznamný
Využití
Je vyžadována okamžitá reakce
Periodické skóre
náklady
vysoká
nízká
složitost
vysoká
nízká
příklad
Živé doporučení, podvod
Měsíční skóre rizika
Časté chyby
- Distribuujte bez plánu vyhledávání. Špatný model zasáhne celého uživatele.
- Otevření přímo pro 100% provoz. Omezte riziko pomocí rozložené distribuce.
- Nezavádí se sledování. Model vytváří chyby tiše, bez chyby.
- Redundantní prezentace v reálném čase. Zatímco dávkování je dostatečné, náklady a složitost narůstají.
- Nepropojuje verze modelu-data-kódu. Problém nemůžete reprodukovat.
- Automatické uvolnění bez prahu distribuce. Špatný model se tiše vplíží dovnitř.
V souhrnu
Přesun modelu do výroby je jiný a často obtížnější inženýrský úkol než jeho výcvik. ML vyžaduje zvláštní disciplínu, protože závisí na trojici kód-data-model: balení a verzování, způsob doručení (online/dávka), který vyhovuje obchodním potřebám, postupné a reverzibilní nasazení, prahová hodnota CI/CD a registrace modelu. Umělá inteligence je mocným pomocníkem při generování kódu a konfiguraci této infrastruktury; ale distribuční prahy, zásady zpětného získání a rozhodnutí o riziku jsou na vás. Distribuce bez plánu vrácení není dokončena.
Aplikační úkol
Kontejnerujte (Docker) model a označte jeho verzi. Rozhodněte se, zda budete nabízet online nebo hromadně na základě vašich obchodních potřeb a napište své odůvodnění. Zdokumentujte plán postupného nasazení (stínový nebo kanárkový) a otestovaný postup vrácení. Ujistěte se, že jste zaznamenali verzi dat, odevzdání kódu a hodnocení hodnocení do registru modelu.
kontrolní seznam
- [ ] Model je zabalen a verzován (kontejner + štítek).
- [ ] Vzor prezentace (online/dávka) byl zvolen podle obchodních potřeb.
- [ ] Byla implementována strategie postupného zavádění (stín/kanárek).
- [ ] Postup vrácení napsaný a otestovaný.
- [ ] CI/CD nepokročí v nasazení, dokud není splněn práh hodnocení.
- [ ] Registr modelu obsahuje odkaz data+kód+metrika.