Díl 2: Od experimentů k systému
Experiment je skvělý sluha, ale špatný pán
Většina data science týmů začíná správně:
rychlé experimenty, notebooky, iterace, hledání signálu v datech.
Problém nastává ve chvíli, kdy:
- experiment přežije svůj účel,
- a postupně se stane produkcí.
Notebook, který měl odpovědět na otázku „má to smysl?",
se nenápadně promění v:
- zdroj pravdy,
- referenční implementaci,
- a nakonec i kritickou závislost.
Unified Pipeline vznikla ve chvíli, kdy bylo zřejmé, že:
Experimentální přístup už brzdí systém jako celek.
Ne proto, že by experimenty byly špatné.
Ale proto, že nemají nést dlouhodobou odpovědnost.
Přechodový bod, který se často přehlíží
Existuje moment, kdy by se tým měl vědomě zeptat:
„Je tento model ještě experiment, nebo už systém?"
Tento přechodový bod je často ignorovaný, protože:
- model „funguje",
- metrika vypadá dobře,
- business je spokojený.
Jenže v tu chvíli se začíná kumulovat technický i metodický dluh:
- nejasná validační logika,
- implicitní předpoklady o datech,
- křehký deployment,
- znalost uzamčená v hlavách jednotlivců.
Unified Pipeline byla reakcí právě na tento tichý přechod do produkce bez změny myšlení.
Architektura jako nástroj disciplíny
Jedno z klíčových rozhodnutí bylo chápat architekturu ne jako:
„technické řešení"
ale jako:
nástroj vynucování správných rozhodnutí.
Pipeline byla navržena tak, aby:
- nešlo snadno obejít validaci,
- nešlo trénovat bez jasného časového kontextu,
- nešlo nasadit model bez verzování a metadat.
Ne proto, že by tým nebyl schopný disciplíny.
Ale proto, že systém má být silnější než individuální vůle.
Konfigurace místo improvizace
Zásadní posun nastal ve chvíli, kdy:
se rozhodování přesunulo z kódu do konfigurace.
To mělo několik důsledků:
- rozdíly mezi modely byly explicitní,
- pipeline byla čitelná i bez spuštění,
- a bylo možné porovnávat modely systematicky, ne pocitově.
Místo otázky:
„Co vlastně tento skript dělá?"
se tým mohl ptát:
„Jaký typ rozhodnutí tento model reprezentuje?"
A to je obrovský rozdíl.
Čas jako první třída problému
Jedním z nejsilnějších architektonických rozhodnutí bylo:
považovat čas za centrální osu celého systému.
Ne jako detail validace, ale jako:
základní strukturu pipeline.
To znamenalo, že:
- každé trénování mělo jasný časový kontext,
- validace respektovala realitu nasazení,
- a výsledky byly interpretovatelné i zpětně.
Unified Pipeline tím přestala optimalizovat „statistickou pravdu"
a začala optimalizovat rozhodování v čase.
Od „nejlepšího modelu" k „nejlepšímu procesu"
Možná nejdůležitější změna byla mentální:
Cílem už nebylo mít nejlepší model.
Cílem bylo mít nejlepší proces, který konzistentně vytváří dobré modely.
To znamenalo:
- méně heroických řešení,
- více reprodukovatelných postupů,
- méně závislosti na jednotlivcích,
- více sdíleného porozumění.
Unified Pipeline se tak stala spíš:
produkční filosofií
než jen technickým artefaktem.
Co bude dál
V dalším díle se zaměřím na téma, které bývá podceňované a přitom zásadní:
časová stabilita modelů
– proč standardní cross-validace selhává,
– jak se liší „dobrý model dnes" od „dobrého modelu za půl roku",
– a proč je čas často důležitější než feature engineering.
Napsat komentář