michaelprinc.com

Štítek: serie

  • Aproximace PENB štítku – Díl 1: Proč nestačí čekat na formální audit

    Série: Aproximace PENB štítku – zkušenosti z budování veřejné aplikace

    Cíl série:
    Popsat projekt od problému přes data a model až po veřejné nasazení tak, aby bylo jasné, kde se potkává data science, produktové myšlení a kvalitní implementace.

    Navazující díly

    1. Proč nestačí čekat na formální audit – kdy je orientační výpočet užitečnější než čekání.
    2. Jak z běžných spotřeb vznikne validní vstup – co je potřeba připravit dřív, než model začne počítat.
    3. Počasí, topná sezona a RC model bez magie – kde se potkává doménová logika a data.
    4. Jak z výpočtu udělat aplikaci pro běžného uživatele – proč UX není kosmetika.
    5. Nasazení, limity a co by přišlo dál – co funguje dnes a co by mělo přijít v další iteraci.

    Díl 1: Proč nestačí čekat na formální audit

    Kde vznikl skutečný problém

    Formální PENB dává smysl ve chvíli, kdy člověk řeší právní povinnost nebo finální dokument pro prodej či pronájem. Jenže většina rozhodnutí vzniká dřív.

    Člověk chce vědět:

    • jestli je jeho spotřeba normální,
    • zda má smysl investovat do úprav bytu,
    • jestli je konkrétní byt podezřele energeticky náročný,
    • zda má smysl pokračovat v hlubší analýze.

    Právě v této fázi bývá formální audit příliš pomalý. Potřebujete rychlý, ale stále obhajitelný signál.

    Nejtěžší není výpočet, ale správné zadání problému

    Na podobných projektech je dobře vidět rozdíl mezi technicky zajímavým modelem a prakticky užitečným produktem.

    Technická otázka zní:

    Dá se z provozních dat aproximovat energetická náročnost bytu?

    Produktová otázka zní jinak:

    Dá se člověku rychle a srozumitelně pomoci rozhodnout, zda má smysl řešit byt podrobněji?

    To druhé je důležitější. Aplikace proto nevznikla jako náhražka certifikovaného PENB, ale jako nástroj pro první orientaci.

    Proč provozní data dávají smysl

    Lidé často nemají po ruce technickou dokumentaci budovy, ale mají:

    • účty a spotřebu,
    • základní parametry bytu,
    • informaci o zdroji vytápění,
    • přibližnou představu o tom, jak byt používají.

    To není perfektní dataset. Ale je to dataset, který opravdu existuje. A dobrý produkt často začíná právě tam, kde jsou data reálně dostupná, ne tam, kde by byla ideální.

    Co musí podobný nástroj splnit

    Pokud má být aplikace užitečná, musí splnit čtyři podmínky:

    • být rychlá, aby pomáhala ještě před formálním auditem,
    • být srozumitelná, aby výsledek nebyl jen další technická bariéra,
    • otevřeně přiznávat omezení, protože nejistotu nelze skrýt,
    • být veřejně dostupná, aby bylo možné princip okamžitě ukázat v praxi.

    To je zároveň důvod, proč projekt neskončil jako skript v notebooku. Od začátku směřoval k aplikaci.

    Hodnota pro uživatele není v čísle, ale v rozhodnutí

    Samotná energetická třída je jen část výsledku.

    Větší hodnotu má to, že aplikace pomáhá odpovědět na praktické otázky:

    • má smysl pokračovat v due diligence,
    • je spotřeba konzistentní s parametry bytu,
    • je vhodné plánovat rekonstrukci,
    • stojí za to objednat detailní audit.

    Jinými slovy: projekt je zajímavý tím, že převádí nejasná provozní data do akčního rámce pro další krok.

    Co bude dál

    V dalším díle se podívám na to, proč je u podobné aplikace kritické správně připravit vstupní data, jak oddělit topení od běžného provozu a proč validace vstupů často rozhoduje víc než samotná optimalizace modelu.

    Projektová case study
    Další díl
    Otevřít aplikaci

  • Aproximace PENB štítku – Díl 2: Jak z běžných spotřeb vznikne validní vstup

    Díl 2: Jak z běžných spotřeb vznikne validní vstup

    Model je jen tak dobrý, jak dobrý je vstup

    U projektů pracujících s provozními daty bývá největší chybou představa, že hlavní hodnota leží až v samotném algoritmu. Ve skutečnosti se kvalita výsledku často rozhoduje ještě před výpočtem.

    V případě aproximace PENB je kritické hlavně to, aby aplikace správně pochopila:

    • jaká data o spotřebě má k dispozici,
    • jaké období pokrývají,
    • kdy uživatel topí a kdy ne,
    • jaká část energie pravděpodobně souvisí s vytápěním a jaká s TUV nebo běžným provozem.

    Co aplikace od uživatele skutečně potřebuje

    Praktický vstup je schválně relativně střídmý:

    • lokalita,
    • plocha bytu a výška stropu,
    • typ vytápění,
    • teplotní režim,
    • časová řada spotřeby,
    • volba měsíců bez topení,
    • způsob aproximace TUV.

    To je důležitý kompromis. Kdyby aplikace chtěla příliš mnoho detailů, běžný uživatel by ji nedokončil. Kdyby naopak chtěla příliš málo, výsledek by ztrácel oporu v realitě.

    Proč nestačí jen nahrát CSV

    Nahrání souboru je technicky jednoduché, ale datově nestačí. Spotřeba sama o sobě neříká:

    • zda jde o vytápění, nebo jinou složku,
    • zda je v datech mezera,
    • zda pozorování odpovídají topné sezoně,
    • zda je délka měření dostatečná pro zvolený režim výpočtu.

    Proto je součástí workflow i volba měsíců bez topení a rozdělení energie na část související s vytápěním a část spojenou s TUV či běžným provozem.

    Validace není o omezování uživatele

    Dobrá validace nepůsobí jako překážka. Je to způsob, jak zabránit tomu, aby aplikace vracela sebevědomý výsledek z nekonzistentních dat.

    V tomto projektu validace řeší například:

    • minimální délku dat podle výpočetního režimu,
    • logiku vstupních polí pro typ vytápění,
    • konzistenci teplotního režimu,
    • přítomnost očekávaných sloupců ve vstupním souboru.

    Z produktového hlediska je to důležité proto, že uživatel dostane zpětnou vazbu včas, ne až po několikaminutovém výpočtu.

    Co je na tom zajímavé pro data science

    Podobné workflow dobře ukazuje, že datová věda v produkci není jen modelování. Je to i návrh toho, jak mají data do systému vstupovat, aby byl výsledek opakovatelný a interpretovatelný.

    Přesně tady se potkává:

    • datová kvalita,
    • doménová logika,
    • UX formuláře,
    • a provozní realita běžného uživatele.

    Co bude dál

    V dalším díle se podívám na samotné jádro odhadu: jak do aplikace vstupuje počasí, proč je potřeba rozlišovat topnou sezonu a jakou roli hraje zjednodušený RC model při kalibraci energetického chování bytu.

    Předchozí díl
    Další díl
    Projektová case study

  • Aproximace PENB štítku – Díl 3: Počasí, topná sezona a RC model bez magie

    Díl 3: Počasí, topná sezona a RC model bez magie

    Proč nestačí vidět jen spotřebu

    Stejná spotřeba může znamenat něco jiného v lednu a něco jiného v dubnu. Bez kontextu počasí a sezóny proto nelze rozumně odhadovat, jakou část energie skutečně vysvětluje vytápění.

    Právě proto aplikace nestojí jen na nahraném CSV. Vedle provozních dat doplňuje i meteorologický kontext pro konkrétní lokalitu.

    Hybridní vrstva počasí jako praktické rozhodnutí

    V ideálním světě by existoval jeden perfektní zdroj dat, vždy dostupný a bez výpadků. V praxi je lepší počítat s tím, že síť, API nebo rozsah historických dat nebude vždy ideální.

    Projekt proto používá vícevrstvý přístup:

    • novější data získává z WeatherAPI,
    • starší historii doplňuje přes Open-Meteo,
    • a teprve jako poslední fallback používá syntetickou aproximaci.

    To není jen technický detail. Je to příklad toho, jak se robustnost buduje už v návrhu datové vrstvy.

    Kde vstupuje topná sezona

    Spotřeba energie není homogenní. Některé měsíce reprezentují hlavně vytápění, jiné spíš běžný provoz a TUV. Pokud to model nerozliší, začne kalibrovat nesprávný signál.

    Proto uživatel v aplikaci vybírá měsíce bez topení a systém s nimi dále pracuje při odhadu složek spotřeby. Nejde o zbytečný detail, ale o jeden z nejdůležitějších kroků celé logiky.

    Proč zrovna RC model

    Zjednodušený RC model není zajímavý proto, že by byl teoreticky nejkomplexnější. Je zajímavý tím, že nabízí rozumnou rovnováhu mezi:

    • doménovou interpretovatelností,
    • výpočetní jednoduchostí,
    • možností kalibrace na reálná data.

    Model pomáhá převést chování bytu do struktury, se kterou lze dál pracovat. Nejde o „černou skříňku“, ale o vysvětlitelnou aproximaci tepelné dynamiky.

    Více režimů výpočtu není kosmetika

    Aplikace dnes nabízí několik výpočetních režimů. To je důležité nejen kvůli výkonu, ale i kvůli povaze dostupných dat.

    • někdy stačí rychlý orientační výpočet,
    • jindy dává smysl lokální optimalizace,
    • a v náročnější variantě je možné jít i do robustnější kalibrace.

    Tohle je dobrý příklad produktového kompromisu: nesnažit se vnucovat všem jeden „správný“ režim, ale nabídnout několik cest podle kvality vstupu a očekávání uživatele.

    Co bude dál

    V dalším díle se posunu od výpočetního jádra k uživatelské vrstvě: proč nestačí mít správný model, jak byly navržené jednotlivé kroky rozhraní a proč je u podobných nástrojů UX součástí technické kvality.

    Předchozí díl
    Další díl
    Otevřít aplikaci

  • Aproximace PENB štítku – Díl 4: Jak z výpočtu udělat aplikaci pro běžného uživatele

    Díl 4: Jak z výpočtu udělat aplikaci pro běžného uživatele

    Proč nestačí správný model

    Mnoho technických projektů selže ne proto, že by byl model špatný, ale proto, že se s ním reálný uživatel nedokáže domluvit. U aplikace pro aproximaci PENB je to obzvlášť důležité, protože cílová skupina není tvořena jen analytiky.

    Použitelná veřejná aplikace musí splnit tři věci současně:

    • uživatel musí pochopit, co má zadat,
    • systém musí dostat konzistentní vstup,
    • výstup musí být čitelný i bez hlubší technické znalosti.

    Pět kroků místo jedné zahlcené obrazovky

    Současné rozhraní pracuje s logickým rozdělením do několika kroků: lokalita, byt, data, výpočet a výsledek. To je důležité z praktického důvodu.

    Když člověk vidí vše najednou, snadno ztratí kontext. Když je veden po krocích, pravděpodobnost správného vstupu se zvyšuje.

    Tohle není jen UX pravidlo. Je to i způsob, jak zlepšit kvalitu dat, která nakonec dorazí do modelu.

    Formulář jako součást doménové logiky

    Veřejná aplikace nemá být jen tenká vrstva nad backendem. V tomto projektu formulář aktivně pomáhá se strukturou vstupu:

    • vede uživatele k tomu, které informace jsou opravdu podstatné,
    • rozlišuje rychlé a podrobnější výpočetní režimy,
    • pracuje s měsíci bez topení a TUV už ve chvíli zadání,
    • připravuje půdu pro interpretaci výsledku.

    Z tohoto pohledu není UX oddělené od data science. Je to jedna z vrstev, která určuje, zda model dostane smysluplný vstup.

    Výsledek musí být srozumitelný, ne jen přesný

    Uživatel obvykle nepotřebuje vědět všechny interní parametry kalibrace. Potřebuje pochopit:

    • jaká energetická třída z výpočtu vychází,
    • nakolik se na odhad dá spoléhat,
    • jaké jsou limity interpretace,
    • jaký další krok dává smysl.

    Proto výstup kombinuje energetickou třídu, základní metriky, slovní komentář a exportovatelný report. Výsledek tak funguje i jako komunikační artefakt, ne jen jako technický mezivýstup.

    Dvojjazyčnost jako produktová vlastnost

    Zajímavou částí projektu je i to, že aplikace není připravená jen pro lokální test. Má českou i anglickou jazykovou variantu. To zvyšuje použitelnost při prezentaci projektu, sdílení s klienty i dalším rozvoji.

    Technicky to znamená víc práce. Produktově to ale výrazně posouvá hodnotu celé aplikace.

    Co bude dál

    V posledním díle se podívám na deployment, export reportů, aktuální omezení projektu a také na to, co bych v další iteraci rozšířil nebo zpřesnil.

    Předchozí díl
    Další díl
    Projektová case study

  • Aproximace PENB štítku – Díl 5: Nasazení, limity a co by přišlo dál

    Díl 5: Nasazení, limity a co by přišlo dál

    Kdy je projekt opravdu projektem

    Dokud výpočet žije jen lokálně, je to experiment. Ve chvíli, kdy ho lze otevřít na veřejné URL, přepnout jazyk, projít workflow a stáhnout report, začíná se z něj stávat skutečný produkt.

    To je i případ této aplikace. Výpočetní logika je důležitá, ale stejně důležité je, že je nasazená jako veřejně dostupná služba.

    Co dává hodnotu z provozního hlediska

    Projekt dnes stojí na několika praktických stavebních kamenech:

    • kontejnerizované nasazení v Dockeru,
    • oddělená česká a anglická varianta,
    • persistentní storage pro lokální stav a reporty,
    • HTML export výsledků,
    • jasné oddělení UI, modelu a reportovací vrstvy.

    To jsou přesně ty prvky, které rozhodují o tom, jestli lze aplikaci dál rozvíjet bez přepisování od nuly.

    Transparentnost limitů je součást kvality

    U podobného nástroje je důležité nejen to, co umí, ale i to, co zatím neumí nebo co řeší jen aproximačně.

    Z aktuální implementace je dobré otevřeně říct například to, že:

    • výstup je orientační, ne certifikovaný PENB,
    • referenční rok je v MVP aproximovaný typický rok, nikoli plnohodnotný TMY dataset,
    • kvalita výsledku závisí na rozsahu a konzistenci vstupních dat,
    • některé části prezentace výsledků mají stále prostor pro další rozšíření.

    To není slabina komunikace. To je její profesionalizace.

    Co bych rozvíjel v další iteraci

    Pokud by projekt pokračoval do další verze, největší smysl by podle mě měly tyto směry:

    • přesnější práce s referenčním rokem a klimatickými scénáři,
    • rozšíření interpretace výsledku o další doporučení,
    • hlubší práci s vizualizacemi a vysvětlením kalibrace,
    • robustnější práci s širším spektrem vstupních situací.

    Tyto kroky by neposouvaly jen technickou stránku modelu. Zvyšovaly by i důvěru uživatele ve výstup a schopnost nástroj využít v reálném rozhodování.

    Co si z celé série odnést

    Na projektu aproximace PENB je dobře vidět, že kvalitní datová aplikace nevzniká jedním chytrým nápadem. Vzniká souhrou několika disciplín:

    • správně zvoleného problému,
    • rozumného modelu,
    • kvalitního datového workflow,
    • použitelného rozhraní,
    • a deploymentu, který dovolí výsledek skutečně používat.

    Právě tato kombinace je podle mě zajímavější než samotný fakt, že aplikace vrací energetickou třídu.

    Předchozí díl
    Projektová case study
    Otevřít aplikaci

  • Unified Pipeline – Díl 2: Od experimentů k systému

    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.

  • Unified Pipeline – Díl 3: Čas jako nepřítel modelu

    Díl 3: Čas jako nepřítel modelu

    Když validace lže, aniž by chtěla

    Jedna z nejnepříjemnějších zkušeností v aplikované data science je tato:

    Model má skvělé validační metriky –
    a přesto v produkci selhává.

    Ne dramaticky.
    Ne hned.
    Ale systematicky.

    Predikce jsou „nějak horší", stabilita kolísá a důvěra v model se postupně vytrácí. Přitom:

    • pipeline běží,
    • data tečou,
    • kód se nezměnil.

    Problém není v implementaci.
    Problém je v čase.

    Iluze náhodnosti

    Standardní validační přístupy implicitně předpokládají, že:

    • data jsou náhodně promíchaná,
    • rozdělení je stabilní,
    • budoucnost je statisticky podobná minulosti.

    To jsou rozumné předpoklady pro učebnice.
    Ale ne pro rozhodovací systémy běžící v čase.

    Jakmile model:

    • ovlivňuje reálná rozhodnutí,
    • pracuje s chováním lidí,
    • reaguje na externí podmínky,

    pak se čas stává aktivním aktérem, ne jen indexem.

    Proč náhodné dělení dat selhává

    Při náhodném dělení trénovacích a validačních dat:

    • model vidí budoucí vzory,
    • učí se vztahy, které v reálném čase neexistují,
    • a metriky vypadají lépe, než odpovídá realitě.

    To není chyba metodiky.
    To je nesoulad mezi otázkou a nástrojem.

    Otázka v produkci totiž zní:

    „Jak se model zachová na datech, která ještě neexistují?"

    Ale náhodná validace odpovídá na jinou otázku:

    „Jak dobře model interpoluje v rámci známého rozdělení?"

    Unified Pipeline a časová disciplína

    Unified Pipeline postavila čas do centra celého procesu:

    • trénování,
    • validace,
    • i interpretace výsledků.

    Každý model byl:

    • zasazen do konkrétního časového kontextu,
    • testován na datech, která skutečně následovala,
    • a hodnocen nejen podle výkonu, ale i stability v čase.

    Validace přestala být jednorázovým číslem
    a stala se časovou trajektorií.

    Stabilita jako metrika kvality

    Postupně se ukázalo, že:

    • nejvyšší validační metrika není nutně nejlepší volba,
    • model s mírně horším výkonem, ale vyšší stabilitou, je v produkci často cennější.

    To vedlo k posunu v uvažování:

    • od maximalizace bodové metriky,
    • k hodnocení chování modelu napříč obdobími.

    Jinými slovy:

    Model není hodnocen podle toho, jak dobrý byl,
    ale podle toho, jak spolehlivý bývá.

    Čas odhaluje skutečný overfitting

    Overfitting se často chápe jako:

    • příliš složitý model,
    • příliš mnoho parametrů,
    • příliš málo regularizace.

    Čas ale ukazuje jiný typ přetrénování:

    model je perfektně přizpůsobený minulému světu,
    ale křehký vůči změnám.

    Unified Pipeline tím pádem neřešila jen:

    zda je model přetrénovaný,

    ale hlavně:

    na co je přetrénovaný.

    Nepříjemná pravda

    Jedno z nejdůležitějších zjištění bylo toto:

    Pokud model neumí selhávat předvídatelně,
    neumí být důvěryhodný.

    Časová validace často:

    • snižovala metriky,
    • komplikovala porovnání,
    • a nutila tým k nepříjemným rozhodnutím.

    Ale právě díky tomu:

    • mizela falešná jistota,
    • a rostla důvěra v to, co model skutečně umí.

    Co bude dál

    V dalším díle se posunu od metodiky k praxi:

    MLOps bez buzzwordů
    – co skutečně zrychlovalo vývoj,
    – co naopak přidávalo složitost bez hodnoty,
    – a proč „správná infrastruktura" často znamená méně, ne více nástrojů.

  • Unified Pipeline – Díl 4: MLOps bez buzzwordů

    Díl 4: MLOps bez buzzwordů

    Když nástroje začnou být cílem

    V určité fázi projektu se MLOps začne chovat zvláštně:

    • přibývají nástroje,
    • přibývají procesy,
    • ale nepřibývá jistota ani rychlost.

    Místo aby infrastruktura zjednodušovala práci data scientistům,
    začíná vyžadovat:

    • synchronizaci,
    • obcházení,
    • vysvětlování,
    • a někdy i manuální zásahy „aby to prošlo".

    Unified Pipeline vznikala s vědomým cílem:

    MLOps má snižovat kognitivní zátěž, ne ji přelévat jinam.

    Co jsme považovali za skutečný přínos

    Postupně se ukázalo, že většina reálné hodnoty nepřichází z „velkých MLOps konceptů", ale z několika nenápadných principů:

    Jednoznačný vstup → jednoznačný výstup

    Každý běh modelu musel mít:

    • jasně definovaný datový výřez,
    • explicitní konfiguraci,
    • dohledatelný výsledek.

    Metadata nejsou bonus, ale základ

    Bez metadat:

    • nelze porovnávat modely,
    • nelze vysvětlovat rozhodnutí,
    • nelze se vracet v čase.

    Automatizace až po stabilizaci

    Vše, co se automatizovalo příliš brzy,
    pouze urychlilo chaos.

    Co naopak nepřineslo očekávanou hodnotu

    Unified Pipeline nebyla imunní vůči slepým uličkám. Některé věci vypadaly dobře na prezentacích, ale v praxi selhaly:

    Příliš jemnozrnná orchestrace

    Každý mikrokrok zvlášť řízený vedl k:

    • křehkosti,
    • obtížnému debugování,
    • a ztrátě přehledu.

    Univerzální řešení bez kontextu

    Snaha mít „jednu pipeline pro všechno"
    končila buď:

    • explozí podmínek,
    • nebo implicitními výjimkami.

    Komplexní monitoring bez interpretační vrstvy

    Grafy bez kontextu nevytvářejí porozumění.
    Jen další šum.

    MLOps jako sociotechnický systém

    Důležitý posun nastal ve chvíli, kdy se na MLOps přestalo nahlížet čistě technicky.

    Pipeline totiž:

    • formuje způsob práce,
    • ovlivňuje rozhodování,
    • a určuje, co je „normální" a co „výjimka".

    Unified Pipeline tak fungovala jako:

    • nepsaná dokumentace dobré praxe,
    • ochrana před unáhlenými zkratkami,
    • a společný referenční rámec týmu.

    Rychlost se vrací – tentokrát udržitelně

    Teprve když:

    • byly jasné hranice pipeline,
    • byly stabilní vstupy a výstupy,
    • a proces byl pochopitelný i bez autora,

    začala se znovu objevovat rychlost.

    Ale jiná než na začátku projektu:

    • méně dramatická,
    • méně viditelná,
    • zato dlouhodobě spolehlivá.

    Rekapitulace: Co si odnést při návrhu podobného frameworku

    Na závěr několik praktických, přenositelných tipů pro každého, kdo uvažuje o vlastním „unified" přístupu.

    1. Nezačínejte nástroji, ale otázkami

    Ptejte se:

    • Jaká rozhodnutí má systém podporovat?
    • Jaké chyby jsou ještě přijatelné?
    • Co musí být dohledatelné i za rok?

    Teprve pak vybírejte technologii.

    2. Čas patří do architektury, ne jen do validace

    Pokud pipeline:

    • neví, kdy model vznikl,
    • na jakém období byl testován,
    • a pro jaký čas je určen,

    pak není produkční – jen běží v produkci.

    3. Konfigurace je komunikační nástroj

    Dobrá konfigurace:

    • vysvětluje rozhodnutí,
    • umožňuje srovnání,
    • a nutí k explicitnosti.

    Pokud konfigurace nejde přečíst bez spuštění kódu,
    není dostatečně dobrá.

    4. Optimalizujte na stabilitu, ne na maximum

    Model s nejvyšší metrikou:

    • bývá nejkřehčí.

    Model, který se chová čitelně v čase:

    • bývá nejcennější.

    5. Pipeline má chránit tým – i před ním samým

    Dobře navržený framework:

    • brání impulzivním zkratkám,
    • snižuje závislost na jednotlivcích,
    • a zvyšuje důvěru ve výsledky.

    To je jeho skutečná role.

    Co bude dál

    V posledním díle se podívám zpětně:

    Co bych dnes udělal jinak
    – kde byla Unified Pipeline zbytečně ambiciózní,
    – kde naopak mohla jít dál,
    – a které principy bych si vzal do jakéhokoli dalšího projektu.

  • Unified Pipeline – Díl 5: Co bych dnes udělal jinak

    Díl 5: Co bych dnes udělal jinak

    Zkušenost jako filtr

    Unified Pipeline nevznikla jako akademický projekt.
    Vznikla tlakem reality: času, provozu a odpovědnosti.

    S odstupem je ale jasné, že:

    • některá rozhodnutí byla správná,
    • některá byla nutná,
    • a některá byla spíš reakcí na konkrétní situaci než obecně optimálním řešením.

    Tento díl není kritikou projektu.
    Je pokusem oddělit principy, které přetrvají, od řešení, která byla dobově podmíněná.

    1. Méně abstrakce na začátku

    Jedna z věcí, kterou bych dnes změnil, je tempo abstrakce.

    Unified Pipeline byla od začátku navrhována jako:

    • obecný rámec,
    • použitelný pro více typů modelů,
    • s vysokou mírou konfigurovatelnosti.

    To přineslo flexibilitu, ale i cenu:

    • delší onboarding,
    • složitější mentální model,
    • a občas nutnost „pochopit systém dřív, než vyřeším problém".

    Dnes bych:

    • začal s užším scope,
    • nechal abstrakce vznikat až z opakování,
    • a část „elegance" obětoval ve prospěch čitelnosti.

    2. Ještě tvrdší oddělení experimentu a produkce

    Přestože Unified Pipeline jasně rozlišovala mezi experimentem a produkcí, v praxi:

    • zůstávaly některé přechody příliš plynulé,
    • a experimentální myšlení občas prosakovalo tam, kde už nemělo být.

    Dnes bych:

    • experimentální fázi ještě víc izoloval,
    • produkční pipeline více „uzamkl",
    • a přechod mezi nimi udělal vědomým rozhodnutím, ne postupnou evolucí.

    Ne kvůli kontrole, ale kvůli ochraně obou světů.

    3. Více investice do interpretace, méně do optimalizace

    Unified Pipeline byla velmi dobrá v:

    • trénování,
    • validaci,
    • a porovnávání modelů.

    Zpětně vidím, že:

    ještě víc hodnoty by přinesla silnější interpretační vrstva.

    Ne ve smyslu:

    „explainability pro audit",

    ale ve smyslu:

    • jaký typ chování model reprezentuje,
    • kdy mu věřit a kdy ne,
    • jak číst jeho selhání.

    Dnes bych:

    část optimalizační energie přesunul právě sem.

    4. Méně implicitní expertízy v designu

    Unified Pipeline v sobě nesla hodně:

    • doménové znalosti,
    • metodických předpokladů,
    • a „tichých" rozhodnutí.

    Pro zkušený tým to fungovalo skvěle.
    Pro nově příchozí už méně.

    Z dnešního pohledu bych:

    • víc těchto předpokladů externalizoval,
    • víc je pojmenoval,
    • a méně spoléhal na to, že „je to přece jasné".

    Pipeline má být čitelná i bez autora v místnosti.

    5. Co bych si vzal do každého dalšího projektu

    Navzdory všem výše uvedeným bodům existují principy, které bych dnes použil znovu – beze změny.

    • Čas jako základní osa systému
    • Stabilita nad maximem
    • Proces důležitější než jednotlivý model
    • Pipeline jako nositel kultury, ne jen kódu
    • Omezení jako nástroj kvality, ne brzda

    Tyto principy se ukázaly jako:

    • technologicky agnostické,
    • přenositelné,
    • a dlouhodobě udržitelné.

    Unified Pipeline jako mezník, ne cíl

    Dnes už Unified Pipeline nevnímám jako:

    „hotové řešení",
    ani jako univerzální blueprint.

    Vnímám ji jako:

    mezník v přemýšlení o tom, co znamená dělat data science zodpovědně v čase.

    A právě to je možná její největší hodnota.

    Závěrem

    Pokud bych měl celou sérii shrnout do jedné věty, zněla by takto:

    Produkční data science není o tom, jak chytrý je model,
    ale o tom, jak dobře systém zvládá realitu, ve které model žije.

  • Unified Pipeline – Díl 1: Proč vůbec vznikla Unified Pipeline

    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

    1. Proč vůbec vznikla Unified Pipeline – problém, který nešel vyřešit lepším modelem
    2. Od experimentů k systému – architektonické principy a rozhodnutí
    3. Čas jako nepřítel modelu – time-aware validace, stabilita a realita provozu
    4. MLOps bez buzzwordů – co skutečně zvyšovalo rychlost a kvalitu
    5. 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.

michaelprinc.com

Data Scientist & ML Engineer z Prahy

© 2026 Michael Princ. Všechna práva vyhrazena.

Vytvořeno s WordPress