michaelprinc.com

Autor: admin

  • Promptování tiny LLM: kdy struktura pomáhá a kdy se obrací proti nám

    Promptování tiny LLM: kdy struktura pomáhá a kdy se obrací proti nám

    Úvod

    Jazykové modely (LLM) se stále častěji spouštějí přímo na lokálních zařízeních – bez výkonné grafické karty, jen s CPU nebo integrovanou grafikou. V takových systémech potřebujeme routing: rychlé rozhodnutí, který specializovaný agent nebo model zpracuje daný dotaz. Testoval jsem, zda malé modely do 2B parametrů tuto úlohu zvládnou spolehlivě – a zda jim pomůže strukturovaný prompt (CO-STAR, POML), nebo naopak jednoduchý přístup. Výsledek byl překvapivý: strukturovaný prompt dokáže výkon malého modelu výrazně zlepšit i poškodit – podle toho, jak velký model je.

    Routing je v agentním systému prakticky dispečer. Uživatel napíše dotaz a router má rychle poznat, jestli jde například o generování Python kódu, technickou podporu, bezpečnostní kontrolu, nebo obecný dotaz. Když se rozhodne špatně, požadavek skončí u nevhodného agenta, systém ztrácí čas a uživatel dostane horší odpověď. Proto nestačí, aby router byl "přibližně chytrý"; musí vracet správný výstup ve správném formátu a s nízkou latencí.

    Jazykové modely jsou pro routing lákavé, protože umí rozpoznat záměr i v nejednoznačných formulacích, které by se pevnými pravidly nebo sadou klíčových slov pokrývaly obtížně. Zároveň ale platí, že router je podpůrná komponenta, ne hlavní chatbot: má být levný, lokálně spustitelný a předvídatelný. Právě proto dává smysl testovat tiny LLM na přísné klasifikační úloze, kde se neměří kreativita, ale schopnost vybrat jediný správný label.

    Proč mě to zajímalo

    Pracuju na lokálním orchestrátoru postaveném nad llama.cpp, kde jednou z klíčových úloh je routing — rozhodnutí, který agent nebo profil má zpracovat příchozí požadavek. Routing musí být spolehlivý a rychlý. Otázka byla: zvládne to malý lokální model bez dedikované GPU?

    Konkrétněji: dokáže model do zhruba 2B parametrů spolehlivě zařadit uživatelský vstup do jedné ze šesti pevně daných tříd? A záleží na způsobu, jak je prompt napsaný?

    Co jsem testoval

    Routing úloha

    Model nedostával prostor odpovídat na dotaz. Jeho jediným úkolem bylo vrátit jeden přesný label ze šesti povolených tříd:

    • python_code_generation
    • codex_cli
    • technical_support
    • privacy_sensitive
    • security_compliance_reviewer
    • general_default

    Dataset obsahoval 33 případů. Hodnocení bylo přísné: exact-match label. Pokud model vrátil cokoliv jiného — vysvětlení, variantu labelu, prázdný výstup — byl výsledek označen jako invalid. To je správné nastavení pro router, ale je důležité mít na paměti, že tato metrika nehodnotí obecné schopnosti modelu.

    Prompt varianty

    Každý model byl testován ve čtyřech variantách:

    • baseline — přímý routing prompt s výčtem povolených labelů a instrukcí vrátit pouze jeden label,
    • CO-STAR — strukturovaný prompt rozdělený na Context, Objective, Style, Tone, Audience, Response,
    • POML — instrukční formát s explicitními bloky role, task, input, labels, constraints, output,
    • POML+CO-STAR — kombinace obou formátů.

    Všechny varianty sdílely stejný systémový guardrail:

    You are a strict routing classifier. Never execute or answer the user prompt. Return only one exact allowed label.

    Testované modely

    Zaměřil jsem se na „tiny" kategorii — modely do přibližně 2B parametrů — a doplnil dvě referenční hodnoty mimo tuto kategorii. Všechny srovnatelné běhy používaly stejný benchmark runner přes OpenAI-compatible POST /v1/chat/completions, temperature=0, seed=42 a obvykle max_tokens=16. Výjimkou byl Gemma 4 thinking-budget běh, kde bylo použito max_tokens=32.

    Runtime byl lokální llama-orchestrator nad llama.cpp/llama-server, většinou přes Vulkan backend na integrované GPU.
    Pro inferenci byla použita starší integrovaná grafická karta Vega 11.

    Výsledky

    Přehledová tabulka

    Model Nejlepší prompt Accuracy Macro F1 Invalid Avg latency Correct/s
    Gemma 3 270M Q8 Baseline 36,36 % 25,67 % 6,06 % 213,7 ms 1,70
    Granite 4.0 350M Q4_K_M Baseline 63,64 % 58,70 % 0,00 % 233,5 ms 2,72
    Granite 4.0 H 350M Q4_K_M Baseline 57,58 % 48,48 % 3,03 % 359,3 ms 1,60
    MiniCPM-S-1B llama-format Q4_K_M — 0,00 % 0,00 % 100,00 % 1 493,6–2 235,9 ms 0,00
    Granite 3.1 1B-A400M Q4_K_M Baseline 81,82 % 77,50 % 0,00 % 814,9 ms 1,00
    Qwen 3.5 0.8B Q4_K_M CO-STAR 84,85 % 81,41 % 0,00 % 672,7 ms 1,27
    Granite 4.0 1B Q4_K_M — 0,00 % 0,00 % 100,00 % 1 370,3–2 059,1 ms 0,00
    Granite 4.0 H 1B Q4_K_M CO-STAR 93,94 % 92,47 % 0,00 % 1 357,1 ms 0,69
    HY-1.8B-2Bit Q4_0 POML 60,61 % 54,54 % 0,00 % 1 757,6 ms 0,34
    Marco-Nano-Instruct Q4_K_M Baseline 90,91 % 89,97 % 0,00 % 2 923,7 ms 0,31
    Qwen 3.5 2B Q4_K_M CO-STAR 100,00 % 100,00 % 0,00 % 1 267,9 ms 0,79
    Granite 3.1 3B-A800M Q4_K_M CO-STAR 93,94 % 96,67 % 6,06 % 2 504,5 ms 0,38
    Gemma 4 26B A4B (Dedicated GPU) Baseline 100,00 % 100,00 % 0,00 % 1 008,5 ms 0,99

    Gemma 4 26B A4B je referenční model mimo tiny kategorii — slouží jako horní benchmark a byl provozován na dedikované grafické kartě RX 6800. Viz poznámka níže.


    Scatter graf accuracy proti průměrné latenci pro testované malé jazykové modely
    Praktické okno benchmarku: modely nad 80 % accuracy a pod 1,5 s průměrné latence.

    Tři praktické kandidáty

    Granite 4.0 350M — nejrychlejší prefilter
    233,5 ms průměrná latence, 63,64 % accuracy. Pro produkční routing to nestačí, ale jako rychlý prefilter nebo první krok kaskády má smysl.

    Qwen 3.5 0.8B — nejlepší kompromis pod 1B
    S CO-STAR promptem dosáhl 84,85 % accuracy bez jediného invalid výstupu, při latenci 672,7 ms. Výsledek byl prakticky identický na dvou různých buildech llama.cpp (b9071 i b9085), což zvyšuje důvěryhodnost závěru.

    Qwen 3.5 2B — aktuálně nejlepší malý router
    CO-STAR i POML dosáhly 100 % accuracy, ale CO-STAR byl rychlejší (1 267,9 ms vs. 1 453,2 ms), proto je pro routing praktičtější. Model zároveň překonal starší referenci Granite 3.1 3B-A800M jak v latenci, tak v absenci invalid výstupů.

    Modely, které neprošly

    V hlavní malé sadě zůstaly dva modely bez použitelné prompt varianty a vrátily 100 % invalid výstupů:

    Granite 4.0 1B Q4_K_M generoval opakované tokenové fragmenty (typ $unders$$$$$118$$($and). Jde pravděpodobně o kompatibilitní problém kombinace modelu, kvantu a aktuálního llama.cpp chat template, nikoliv nutně o slabost modelu jako takového.

    MiniCPM-S-1B llama-format Q4_K_M nebyl schopen vrátit platný label v žádné testované variantě. Příčina nebyla dále diagnostikována.

    Jak prompt formát ovlivnil výsledky

    Nejzajímavější závěr z benchmarku není pořadí modelů. Je to způsob, jakým se mění optimální prompt strategie podle velikosti modelu.


    Sloupcový graf vlivu prompt varianty na accuracy u vybraných modelů
    Vliv prompt varianty není monotónní: u malých modelů pomáhá jednoduchost, u větších CO-STAR nebo POML.

    U nejmenších modelů pomáhá jednoduchost

    Modely pod přibližně 500M parametrů — Gemma 3 270M, Granite 4.0 350M a H 350M — měly nejlepší výsledky s baseline promptem. Strukturovaný CO-STAR nebo POML prompt situaci nezlepšil, u Gemmy 3 270M ho naopak výrazně zhoršil:

    • Gemma 3 270M, baseline: 36,36 %
    • Gemma 3 270M, CO-STAR: 24,24 %

    Pravděpodobný důvod: model s omezenou kapacitou musí při strukturovaném promptu věnovat část pozornosti parsování formátu, místo aby ji celou soustředil na klasifikaci. Zároveň tyto modely nebyly dostatečně doladěny na instrukční formáty, takže CO-STAR tagy mohou fungovat jako šum, ne jako signál.

    Kolem 0,8B se CO-STAR začíná vyplácet

    Qwen 3.5 0.8B je prvním modelem v sadě, kde CO-STAR jednoznačně pomáhá:

    • baseline: 60,61 %
    • CO-STAR: 84,85 %

    Totéž platí pro Granite 4.0 H 1B, kde CO-STAR zvýšil accuracy z 87,88 % na 93,94 %. Model v tomto rozsahu má dost kapacity, aby instrukci v CO-STAR formátu spolehlivě interpretoval jako řídící signál, ne jako součást vstupního textu.

    Kolem 2B POML dosahuje srovnatelné přesnosti jako CO-STAR

    U Qwen 3.5 2B dosáhly CO-STAR i POML shodně 100 % accuracy. POML jako samostatná metoda je tedy kompetitivní, ale při vyšší latenci. Pro routing to znamená, že CO-STAR zůstává praktičtější volbou. Pro modely s více než 2 miliardami parametrů doporučuji s oběma metodami experimentovat pro různé typy použití.

    POML+CO-STAR konzistentně snižoval výsledky

    Kombinace obou formátů v jednom promptu se ve srovnání s nejlepší samostatnou variantou neosvědčila. Příklady:

    • Qwen 3.5 2B: CO-STAR 100 % → POML+CO-STAR 63,64 %
    • Granite 4.0 H 1B: CO-STAR 93,94 % → POML+CO-STAR 69,70 %
    • Marco-Nano-Instruct: baseline/CO-STAR 90,91 % → POML+CO-STAR 27,27 %

    Pro krátkou label-only klasifikační úlohu kombinace přidává příliš mnoho strukturální komplexity. Nelze říct, že tato kombinace je obecně špatná pro jiné typy úloh — ale pro routing tento přístup nefungoval.


    Heatmapa accuracy pro kombinace modelů a prompt variant
    Heatmapa ukazuje, že nejlepší prompt strategie se mění s kapacitou modelu.

    Poznámka k Gemma 4 26B A4B

    Gemma 4 26B A4B je reasoning model, který v defaultním nastavení vrátil 100 % invalid výstupů — finální label byl součástí reasoning bloku, nikoliv message.content. Po nastavení thinking_budget_tokens=0 dosáhla baseline i CO-STAR 100 % accuracy, přičemž baseline byla rychlejší (1 008,5 ms). To je důležitý praktický poznatek: reasoning modely vyžadují explicitní nastavení inference režimu pro routing úlohy, jinak jsou nepoužitelné bez ohledu na jejich schopnosti. Tento model není vhodný pro integrovanou grafickou kartu, proto byla inference realizována na dedikované grafické kartě RX 6800.

    Praktická doporučení

    Scénář Model Prompt Poznámka
    Nejrychlejší prefilter Granite 4.0 350M Q4_K_M Baseline jen střední přesnost, vhodné pro kaskádu
    Nejlepší kompromis pod 1B Qwen 3.5 0.8B Q4_K_M CO-STAR stabilní výsledek na více runtime verzích
    Granite-family volba Granite 4.0 H 1B Q4_K_M CO-STAR vysoká přesnost, bez invalid výstupů
    Nejlepší malý router Qwen 3.5 2B Q4_K_M CO-STAR 100 % accuracy, nižší latence než 3B reference

    Limity tohoto benchmarku

    Výsledky jsou slibné, ale je důležité být přesný v tom, co benchmark hodnotí a co ne:

    • Dataset má 33 případů a 6 tříd. To je vhodné pro rychlý lokální experiment, ale slabé pro definitivní veřejné závěry.
    • Každý model byl spuštěn s repetitions=1. Při temperature=0 to snižuje volatilitu, ale neověřuje robustnost vůči runtime variabilitě.
    • Benchmark hodnotí exact-match label. Model, který vrátí jiný formát nebo vysvětlení, je penalizován jako invalid — správně pro router, ale nehodnotí obecné schopnosti.
    • Některé nulové výsledky (Granite 4.0 1B, MiniCPM-S-1B) jsou pravděpodobně kompatibilitní problém, ne důkaz obecné slabosti modelu.
    • Nejsou měřeny RAM/VRAM footprint, spotřeba energie ani CPU-only režim.

    Pro robustnější závěry by bylo potřeba: větší a vyváženější dataset, bootstrap confidence intervaly, per-class recall a opakování v CPU-only režimu pro přenosná zařízení.

    Závěr

    Nejzajímavější zjištění není, který model vyhrál. Podstatnější je, že malé modely se chovají kvalitativně odlišně podle velikosti — a promptovací strategie, která funguje u 2B modelu, může u 270M modelu situaci aktivně zhoršit.

    Pod 500M parametrů: jednoduchý baseline prompt je obvykle optimální. Přidaná struktura spíš zvyšuje kognitivní zátěž, než aby pomáhala.

    Kolem 0,8–1B: CO-STAR začíná být efektivní. Model má dost kapacity na instrukční formát, ale ještě ne na složitější struktury.

    Kolem 2B: CO-STAR i POML dosahují srovnatelné přesnosti. Pro routing s minimální latencí je CO-STAR praktičtější.

    Lokální inference tedy není jen otázka, kolik tokenů za sekundu model vygeneruje. Je to otázka, jak malý model ještě dokáže spolehlivě držet instrukci, formát výstupu a rozhodovací hranici mezi podobnými třídami.

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

  • 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

  • EPC from operational data: where estimation ends and decision begins

    EPC from operational data: where estimation ends and decision begins

    The EPC Energy Label Approximation project shows that even without a lengthy manual process, it is possible to obtain a useful first estimate of a flat’s energy performance from operational data. The aim is not to replace the official energy performance certificate, but to offer a fast, understandable and data-driven view of how the property is likely to perform.

    Open PENB application
    Discuss use without obligation

    How the application looks in practice

    The first demo shows part of the workflow where the user enters the basic parameters of the apartment, the indoor temperature regime and the type of heating. This is where it becomes clear how important it is to combine technical correctness with simple operation, so that the input to the model is understandable even for the average user.

    Screenshot of the PENB application interface for apartment parameters, indoor temperature and heating system

    Example of the input form for apartment parameters, temperature profile and heating system.

    The second demo focuses on the data layer: uploading a CSV with consumption data, selecting non-heating months and approximating water heating. This is an important point where simple operational data starts to become the basis for a qualified estimate.

    Screenshot of the PENB application interface for uploading consumption data, selecting non-heating months and DHW approximation

    Example of the data part of the application: consumption, non-heating months and DHW model approximation.

    What the project solves

    In practice, the same problem often arises: you have energy consumption, the basic parameters of your apartment and you want to get your bearings quickly.

    • Is the consumption reasonable or is it already suspiciously high?
    • Does it make sense to invest in insulation, window replacement or a change of heating source?
    • How to distinguish an expensive renovation with little impact from an intervention that really helps?

    This is where an indicative calculation makes sense. Instead of waiting for the whole formal process, the user can get the first data signal for further decision making in a short while.

    Added value for the user

    For the owner or tenant of an apartment

    • faster orientation as to whether the consumption corresponds to the size and type of the apartment,
    • a better basis for decisions on savings and renovation,
    • a more comprehensible explanation of why the energy bill looks the way it does.

    For the buyer or investor

    • a quick screening of the property before deeper due diligence,
    • a better estimate of future running costs,
    • an additional argument when negotiating the price or the scope of the investment.

    For a consultant, developer or portfolio manager

    • the ability to prioritise which flats or units to deal with first,
    • clearer communication with the customer,
    • the basis for productising a service that combines a technical estimate with a business recommendation.

    Business value in one sentence

    The main benefit of the project is that it turns unclear operational data into a quickly usable basis for decision-making. This is a value in itself: less guesswork, fewer blind investments and a faster path from question to action.

    How it works for laymen

    Simply put, the application does five things:

    1. It takes basic information about the apartment, heating and energy consumption.
    2. It supplements it with meteorological data for the given locality.
    3. It estimates what part of the consumption is related to heating and what to normal operation.
    4. It uses a thermal model to simulate how the apartment behaves during the year.
    5. It translates the result into an indicative energy class and adds a comment on reliability.

    So the user gets not just a number, but also a framework for interpreting the result.

    A short summary for the slightly advanced

    From a software engineering and data science perspective, the project is interesting in that it combines several layers that are often separate:

    • input validation and UX layer: the form guides the user towards consistent inputs and reduces errors,
    • data layer: historical weather is combined with operational data and fallback mechanisms,
    • domain model: the core is based on a simplified RC model of the thermal behaviour of the building,
    • calibration and simulation: the model adapts to the observed consumption and then estimates the annual profile,
    • reporting: the output is not just a technical calculation, but an interpretation for decision-making,
    • deployment: the public application runs separately on its own subdomain, so it is easily shareable and ready for further iterations.

    In practical terms, this means that the project is not just a one-off script. It is a small product: it has a data model, application logic, a user interface and a deployment.

    Why this approach is interesting

    Similar projects show well that data science is not just about training models. It is often more important to:

    • formulate the problem correctly,
    • choose a reasonably simple model,
    • be able to explain the result to a person who does not need to know the mathematical details,
    • and deliver a solution in a form that can actually be used.

    In other words, a useful project is created where domain knowledge, data work and quality implementation come together.

    Important limitation

    The output of the application is an indicative estimate, not an officially certified EPC. For legal or formal purposes, a standard professional processing is still required. However, for a preliminary analysis, business discussion and prioritisation of further steps, such a tool can have very good added value.

    What to take away from this

    The PENB project shows that even a relatively compact application can have a real practical impact if it:

    • solves a specific problem,
    • returns a clear output,
    • and is deployed in such a way that it is immediately usable.

    If you are interested in how to use a similar principle in your product, service or internal decision making, the application is publicly available here:

    Try the PENB application
    Write to me about the project

  • PENB z provozních dat: kde končí odhad a začíná rozhodnutí

    PENB z provozních dat: kde končí odhad a začíná rozhodnutí

    Projekt PENB Energy Label Approximation ukazuje, že i bez zdlouhavého manuálního postupu lze z provozních dat získat užitečný první odhad energetické náročnosti bytu. Smyslem není nahradit oficiální průkaz energetické náročnosti budovy, ale nabídnout rychlý, srozumitelný a datově podložený pohled na to, jak si nemovitost pravděpodobně vede.

    Otevřít aplikaci PENB
    Nezávazně probrat využití

    Jak aplikace vypadá v praxi

    První ukázka zachycuje část workflow, kde uživatel zadává základní parametry bytu, režim vnitřních teplot a typ vytápění. Právě tady se ukazuje, jak důležité je spojit technickou správnost s jednoduchým ovládáním, aby byl vstup do modelu srozumitelný i pro běžného uživatele.


    Ukázka rozhraní PENB aplikace pro parametry bytu, vnitřní teplotu a systém vytápění
    Ukázka vstupního formuláře pro parametry bytu, teplotní profil a topný systém.

    Druhá ukázka se soustředí na datovou vrstvu: nahrání CSV se spotřebami, výběr měsíců bez topení a aproximaci ohřevu vody. To je důležité místo, kde se z prostých provozních dat začíná stávat podklad pro kvalifikovaný odhad.


    Ukázka rozhraní PENB aplikace pro nahrání dat o spotřebě, výběr měsíců bez topení a aproximaci TUV
    Ukázka datové části aplikace: spotřeby, měsíce bez topení a modelová aproximace TUV.

    Co projekt řeší

    V praxi často vzniká stejný problém: člověk má spotřebu energie, základní parametry bytu a chce se rychle zorientovat.

    • Je spotřeba přiměřená, nebo už je podezřele vysoká?
    • Má smysl investovat do zateplení, výměny oken nebo změny zdroje vytápění?
    • Jak odlišit drahou rekonstrukci s malým dopadem od zásahu, který opravdu pomůže?

    Právě tady dává orientační výpočet smysl. Místo čekání na celý formální proces může uživatel během krátké chvíle získat první datový signál pro další rozhodování.

    Přidaná hodnota pro uživatele

    Pro vlastníka nebo nájemce bytu

    • rychlejší orientace v tom, zda spotřeba odpovídá velikosti a typu bytu,
    • lepší podklad pro rozhodnutí o úsporách a rekonstrukci,
    • srozumitelnější vysvětlení, proč účet za energie vypadá právě takto.

    Pro kupujícího nebo investora

    • rychlý screening nemovitosti ještě před hlubší due diligence,
    • lepší odhad budoucích provozních nákladů,
    • dodatečný argument při vyjednávání ceny nebo rozsahu investice.

    Pro poradce, developera nebo správce portfolia

    • možnost prioritizovat, které byty nebo jednotky řešit dříve,
    • přehlednější komunikace se zákazníkem,
    • základ pro produktizaci služby, která spojuje technický odhad s obchodním doporučením.

    Byznysová hodnota v jedné větě

    Největší přínos projektu je v tom, že z nejasných provozních dat dělá rychle použitelný podklad pro rozhodnutí. To je hodnota sama o sobě: méně odhadování, méně slepých investic a rychlejší cesta od otázky k akci.

    Jak to funguje pro laiky

    Zjednodušeně řečeno aplikace dělá pět kroků:

    1. Vezme základní údaje o bytě, vytápění a spotřebě energie.
    2. Doplní je o meteorologická data pro zadanou lokalitu.
    3. Odhadne, jaká část spotřeby souvisí s vytápěním a jaká s běžným provozem.
    4. Pomocí tepelného modelu nasimuluje, jak se byt chová během roku.
    5. Výsledek přeloží do orientační energetické třídy a doplní komentář ke spolehlivosti.

    Uživatel tedy nedostane jen číslo, ale i rámec pro interpretaci výsledku.

    Krátké shrnutí pro mírně pokročilé

    Z pohledu software engineeringu a data science je projekt zajímavý tím, že kombinuje několik vrstev, které často bývají oddělené:

    • validace vstupů a UX vrstva: formulář vede uživatele ke konzistentním vstupům a snižuje chybovost,
    • datová vrstva: historické počasí se kombinuje s provozními daty a fallback mechanismy,
    • doménový model: jádro stojí na zjednodušeném RC modelu tepelného chování budovy,
    • kalibrace a simulace: model se přizpůsobuje pozorované spotřebě a následně odhaduje roční profil,
    • reporting: výstup není jen technický výpočet, ale interpretace pro rozhodování,
    • deployment: veřejná aplikace běží odděleně na vlastní subdoméně, takže je snadno sdílitelná a připravená pro další iterace.

    Prakticky to znamená, že projekt není jen jednorázový skript. Je to malý produkt: má datový model, aplikační logiku, uživatelské rozhraní i nasazení.

    Proč je tento přístup zajímavý

    Podobné projekty dobře ukazují, že data science není jen o trénování modelů. Často je důležitější:

    • správně formulovat problém,
    • zvolit přiměřeně jednoduchý model,
    • umět vysvětlit výsledek člověku, který nepotřebuje znát matematické detaily,
    • a dodat řešení v podobě, kterou lze skutečně používat.

    Jinými slovy: užitečný projekt vzniká tam, kde se spojí doménová znalost, datová práce a kvalitní implementace.

    Důležité omezení

    Výstup aplikace je orientační odhad, nikoli oficiální certifikovaný PENB. Pro právní nebo formální účely je stále potřeba standardní odborné zpracování. Pro předběžnou analýzu, obchodní diskusi a prioritizaci dalších kroků ale může mít podobný nástroj velmi dobrou přidanou hodnotu.

    Co si z toho odnést

    Projekt PENB ukazuje, že i relativně kompaktní aplikace může mít skutečný praktický dopad, pokud:

    • řeší konkrétní problém,
    • vrací srozumitelný výstup,
    • a je nasazená tak, aby byla okamžitě použitelná.

    Pokud vás zajímá, jak podobný princip využít ve vašem produktu, službě nebo interním rozhodování, aplikace je veřejně dostupná zde:

    Vyzkoušet PENB aplikaci
    Napsat mi k projektu

  • Unified Pipeline – Part 5: What I Would Do Differently Today

    Part 5: What I Would Do Differently Today

    Experience as a Filter

    The Unified Pipeline was not born as an academic project.
    It was created under the pressure of reality: time, operations, and responsibility.

    With hindsight, however, it is clear that:

    • some decisions were right,
    • some were necessary,
    • and some were more a reaction to a specific situation than a generally optimal solution.

    This part is not a critique of the project.
    It is an attempt to separate the principles that will endure from the solutions that were conditioned by their time.

    1. Less Abstraction at the Beginning

    One of the things I would change today is the pace of abstraction.

    From the beginning, the Unified Pipeline was designed as:

    • a general framework,
    • usable for multiple types of models,
    • with a high degree of configurability.

    This brought flexibility, but also a cost:

    • longer onboarding,
    • a more complex mental model,
    • and sometimes the need to "understand the system before solving the problem."

    Today I would:

    • start with a narrower scope,
    • let abstractions arise from repetition,
    • and sacrifice some "elegance" for the sake of readability.

    2. An Even Stricter Separation of Experiment and Production

    Although the Unified Pipeline clearly distinguished between experiment and production, in practice:

    • some transitions remained too fluid,
    • and the experimental mindset sometimes seeped into places where it no longer belonged.

    Today I would:

    • isolate the experimental phase even more,
    • "lock down" the production pipeline more,
    • and make the transition between them a conscious decision, not a gradual evolution.

    Not for the sake of control, but to protect both worlds.

    3. More Investment in Interpretation, Less in Optimization

    The Unified Pipeline was very good at:

    • training,
    • validating,
    • and comparing models.

    Looking back, I see that:

    even more value would have been brought by a stronger interpretation layer.

    Not in the sense of:

    "explainability for an audit,"

    but in the sense of:

    • what type of behavior the model represents,
    • when to trust it and when not to,
    • how to read its failures.

    Today I would:

    shift some of the optimization energy to this area.

    4. Less Implicit Expertise in the Design

    The Unified Pipeline carried a lot of:

    • domain knowledge,
    • methodological assumptions,
    • and "silent" decisions.

    For an experienced team, this worked great.
    For newcomers, not so much.

    From today’s perspective, I would:

    • externalize more of these assumptions,
    • name them more,
    • and rely less on the fact that "it’s obvious."

    A pipeline should be readable even without its author in the room.

    5. What I Would Take to Every Future Project

    Despite all the points above, there are principles that I would use again today – without change.

    • Time as the fundamental axis of the system
    • Stability over the maximum
    • The process is more important than the individual model
    • The pipeline as a carrier of culture, not just code
    • Constraints as a tool for quality, not a brake

    These principles proved to be:

    • technologically agnostic,
    • transferable,
    • and sustainable in the long term.

    The Unified Pipeline as a Milestone, Not a Goal

    Today, I no longer see the Unified Pipeline as:

    "a finished solution,"
    nor as a universal blueprint.

    I see it as:

    a milestone in thinking about what it means to do data science responsibly over time.

    And that, perhaps, is its greatest value.

    In Conclusion

    If I had to summarize the entire series in one sentence, it would be this:

    Production data science is not about how smart the model is,
    but about how well the system handles the reality in which the model lives.

  • Unified Pipeline – Part 1: Why the Unified Pipeline Was Created

    Series: Unified Pipeline – Experiences from Building a Production ML System

    Series Goal:
    To show how theoretical data science differs from production reality and why infrastructure, process, and governance are often more important than the model itself.

    Planned Parts

    1. Why the Unified Pipeline Was Created in the First Place – a problem that couldn’t be solved with a better model
    2. From Experiments to a System – architectural principles and decisions
    3. Time as the Enemy of the Model – time-aware validation, stability, and the reality of operations
    4. MLOps Without the Buzzwords – what actually increased speed and quality
    5. What I Would Do Differently Today – lessons learned, dead ends, and transferable principles

    Part 1: Why the Unified Pipeline Was Created in the First Place

    When a Better Model Isn’t Enough

    At a certain stage in data science work, one reaches a point where further model improvements no longer provide corresponding value.
    Not because the models are "good enough," but because the problem is no longer statistical.

    It was at this exact point that the idea for the Unified Pipeline was born.

    At first glance, everything was fine:

    • predictive models existed,
    • the results were not bad,
    • the data was available.

    Yet, development was slow, changes were risky, and knowledge transfer was difficult. Every new use-case meant:

    • re-solving data preparation,
    • re-solving validation,
    • re-solving deployment,
    • and often, re-discovering the same mistakes.

    This is not a failure of people.
    This is a failure of the work architecture.

    The Hidden Debt: Fragmentation

    The fundamental problem was not in the individual models, but in the fact that:

    • each was created slightly differently,
    • had a different validation approach,
    • handled time differently,
    • was deployed differently.

    The result was fragmentation:

    • fragmentation of code,
    • fragmentation of responsibility,
    • fragmentation of knowledge.

    And most importantly: no change was cheap.

    One Pipeline ≠ One Model

    The Unified Pipeline was not an attempt to create "one universal model."
    It was an effort to create one universal way of thinking about how models are built, tested, and operated.

    The basic idea was simple:

    If two models solve a different problem, but run at the same time, on the same data, and in the same production environment,
    they should share the maximum amount of infrastructure and the minimum amount of variability.

    In other words:

    variability should be explicit,
    not hidden in ad-hoc scripts.

    Speed as a Consequence, Not a Goal

    There is often talk of "speeding up development."
    But the Unified Pipeline was not created to be fast.

    It was created to be:

    • predictable,
    • auditable,
    • repeatable.

    Speed came as a consequence:

    • less ad-hoc decision making,
    • less re-inventing the wheel,
    • fewer "heroic" interventions.

    And this is what made it possible to:

    • deploy new models significantly faster,
    • test more variants without chaos,
    • and focus more on the purpose of the model than on its surroundings.

    Why "Unified"

    The word Unified was not for marketing.
    It was chosen intentionally.

    The Pipeline unified:

    • the way of working with time,
    • the method of validation,
    • the versioning method,
    • the deployment method,
    • and even the way of thinking about models.

    And that is perhaps its greatest contribution:
    it unified the team’s mental model, not just the code.

    What’s Next

    In the next part, I will look at:

    • why it was necessary to abandon a purely experimental approach,
    • which architectural decisions were key,
    • and where it turned out that "best practices from blogs" often don’t work in real operation.

michaelprinc.com

Data Scientist & ML Engineer z Prahy

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

Vytvořeno s WordPress