Štítek: validace

  • 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.

  • 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ů.

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

Vytvořeno s WordPress