ML-OPS
Pro mnoho výzkumníků končí práce na ML modelu předáním Jupyter notebooku. V lepším případě je vyčištěný a může se z něj rovnou sestavit skript. V tom horším je zaplevelený analýzou a buňky se dokonce musí pouštět v určitém pořadí. Kdo ale zaručí, že takový kód bude fungovat? Že bude lepší, než předchozí verze? Jak se nasadí? Že v něm není modelová chyba, například datový drift, protože data Vašich mladých respondentů z Masarykovy univerzity najednou selhávají na seniorech? A jak se v případě odhalení takové chyby provede rollback na starou verzi?
Nasazení nového modelu do produkce má několik kroků. Tedy v případě, že se chcete držet průmyslového standardu. Při správné implementaci by měly pomoci řešit otázky nastíněné v minulém odstavci.
Fáze předání modelu
Kód modelu se předává minimální, nejlépe bez zakomentovaných a mrtvých částí kódu. Balíčky, v ML světě zpravidla Python packages, jsou minimální, bez redundancí, a zafixované na konkrétní verze. Kód se načte a spustí se skript nad validačními daty. Nastavená metrika by měla vykazovat stejná nebo vyšší čísla. Ne vždy je metrikou pouze přesnost, někdy ji můžeme snížit na úkor vyšší rychlostí nebo nižší ceny běhu.
Jinak i samotná přesnost se dá počítat různě, ale to už pro jednoduchost článku odkážu někam jinam.
Nasazení
Jedním z velkých problémů ML oboru je reprodukovatelnost sestavení. Velkou slabinou neuronových sítí je náchylnost na drobné změny vstupů, teorie chaosu v nich pak řádí jako divá. Viděl jsem neuronové sítě, které změnily své výstupy, jenom protože se změnila minor verze balíčku podpůrné matematické knihovny Numpy. V praxi se kódu s volnou definicí balíčků rok, dva po jeho vytvoření, začíná měnit výstup k nepoznání. Předcházení tomuto problému pomáhá fixace na konkrétní verze balíčku a sestavení tzv. kontejneru nástrojem Docker. Takový kontejner má vlastní knihovny a operační systém, oddělený od jakéhokoliv softwaru hostujícího systému, který by jej mohl ovlivňovat.
Docker kontejner lze sestavovat i automaticky po provedení předchozí fáze (nebo zároveň s ní). Například nástroji CI/CD. Správně by se měl pak otestovat i ten, neboť i v něm se mohou lišit verze knihoven od starších buildů. Dockerizace je i poměrně spolehlivý způsob jak zajistit, aby fungovaly GPU, pokud o ně stojíme.
Náš hotový docker kontejner můžeme spojit s jiným, třeba webovým rozhraním nebo obecným API, které přijdou v jiném kontejneru. Tomuto spojování se říká orchestrace a starají se o ni další nástroje, například Kubernetes. Ten, ať už lokálně, nebo třeba v prostředí Google Cloudu, zajistí, že jej může použít i koncový uživatel. Navíc jednotlivé služby dokáže v případě potřeby škálovat. Pokud je potřeba najednou odbavit i desetkrát větší traffic v době oběda, kontejnery se naklonují a pak zase samy odpadnou.
Kontejnerizace bohužel není lékem na všechno a stále neřeší dostupnost starých knihoven na interneru nebo hardwarové odchylky v počítání, ale to už je povídání na delší zimní večery. V současné době jde o nejspolehlivější způsob, jak lze zajistit opětovné a bezproblémové nasazení do produkce.
Monitoring provozu
Práce nekončí ani po nasazení. Systém je potřeba logovat a monitorovat. Že nedošlo k pádu nebo k problémům subtilnějšího rázu. Například že dům na okraji Brna neocenil na 140 milionů. Google Cloud (a podobné systémy) obsahuje nástroje pro logování a monitoring, kde můžeme vidět jak výpisy, tak možnost nastavení systému thresholdů a alarmů. Podobné outliery jako dům za 140 milionů by tak měly být zachytitelné.
Verzování a řešení problémů
Samotný model, docker kontejner i build v rámci Kubernetes lze verzovat. V případě detekce problému monitoringem bychom měli být schopni spustit tzv. rollback, tedy návrat k předchozím verzím.
Závěr
ML-OPS je mladý obor inspirovaný postupy z DevOps, který začíná tam, kde končí práce research týmu. A troufám si říct, že moc nás zatím není. Nebo aspoň ne s minimálně 5+ let zkušenostmi, kdy jsem se v praxi setkal s mnoha problémy, na které současné materiály nikoho nepřipraví. V případě zájmu mohu pomoci tyto procesy nastavit nebo rovnou přemigrovat celý systém do prostředí Google Cloudu. Výhodou takového systému je pak jednoduchost vývoje nebo reprodukovatelnost a škálovatelnost produkce.