Série: Unified Pipeline – zkušenosti z budování produkčního ML systému
Cíl série:
Ukázat, jak se liší teoretická data science od produkční reality a proč je infrastruktura, proces a governance často důležitější než samotný model.
Navržené díly
- Proč vůbec vznikla Unified Pipeline – problém, který nešel vyřešit lepším modelem
- Od experimentů k systému – architektonické principy a rozhodnutí
- Čas jako nepřítel modelu – time-aware validace, stabilita a realita provozu
- MLOps bez buzzwordů – co skutečně zvyšovalo rychlost a kvalitu
- Co bych dnes udělal jinak – poučení, slepé uličky a přenositelné principy
Díl 1: Proč vůbec vznikla Unified Pipeline
Když lepší model nestačí
V určité fázi práce v data science se člověk dostane do bodu, kdy další zlepšování modelu přestává přinášet odpovídající hodnotu.
Ne proto, že by modely byly „dost dobré", ale proto, že problém už není statistický.
Přesně v tomto bodě vznikla myšlenka Unified Pipeline.
Na první pohled bylo vše v pořádku:
- existovaly predikční modely,
- výsledky nebyly špatné,
- data byla dostupná.
Přesto byl vývoj pomalý, změny rizikové a přenos know-how obtížný. Každý nový use-case znamenal:
- znovu řešit přípravu dat,
- znovu řešit validaci,
- znovu řešit deployment,
- a často i znovu objevovat stejné chyby.
To není selhání lidí.
To je selhání architektury práce.
Skrytý dluh: fragmentace
Zásadní problém nebyl v jednotlivých modelech, ale v tom, že:
- každý vznikal trochu jinak,
- měl jiný validační přístup,
- jinak pracoval s časem,
- jinak se nasazoval.
Výsledkem byla fragmentace:
- fragmentace kódu,
- fragmentace odpovědnosti,
- fragmentace znalostí.
A hlavně: žádná změna nebyla levná.
Jedna pipeline ≠ jeden model
Unified Pipeline nebyla pokus o vytvoření „jednoho univerzálního modelu".
Byla to snaha vytvořit jedno univerzální myšlení o tom, jak se modely staví, testují a provozují.
Základní myšlenka byla jednoduchá:
Pokud dva modely řeší odlišný problém, ale běží ve stejném čase, na stejných datech a ve stejném produkčním prostředí,
měly by sdílet maximální část infrastruktury a minimální část variability.
Jinými slovy:
variabilita má být explicitní,
ne skrytá v ad-hoc skriptech.
Rychlost jako důsledek, ne cíl
Často se mluví o „zrychlení vývoje".
Unified Pipeline ale nevznikla proto, aby byla rychlá.
Vznikla proto, aby byla:
- predikovatelná,
- auditovatelná,
- opakovatelná.
Rychlost přišla až jako důsledek:
- méně rozhodování ad-hoc,
- méně znovu-vynalézání,
- méně „heroických" zásahů.
A právě to umožnilo:
- nasazovat nové modely výrazně rychleji,
- testovat více variant bez chaosu,
- a soustředit se víc na smysl modelu než na jeho okolí.
Proč „Unified"
Slovo Unified nebylo marketingové.
Bylo zvolené záměrně.
Pipeline sjednocovala:
- způsob práce s časem,
- způsob validace,
- způsob verzování,
- způsob nasazení,
- i způsob, jakým se o modelech přemýšlí.
A to je možná její největší přínos:
sjednotila mentální model týmu, ne jen kód.
Co bude dál
V dalším díle se podívám na to:
- proč bylo nutné opustit čistě experimentální přístup,
- jaká architektonická rozhodnutí byla klíčová,
- a kde se ukázalo, že „best practices z blogů" často nefungují v reálném provozu.
Napsat komentář