Služby

Pilot s velkým jazykovým modelem se dnes postaví za týden. Většina pilotů se ale do provozu nedostane — a skoro nikdy kvůli modelu. Model nemá odkud vzít kontext, nikdo ve firmě neumí jednoznačně říct, co znamená „aktivní zákazník“, a když se výstup splete, není podle čeho poznat, že se spletl.

Cybrainia proto začíná od téhle strany. Nejdřív se pojmenuje rozhodnutí, které má AI změnit. Pak se dohledá, odkud pro něj vzít data a jak se pozná dobrý výstup. Volba modelu přijde na řadu až potom a bývá to to nejmenší rozhodnutí v projektu.

Prakticky to znamená: vyhledávání nad daty, která mají popsanou strukturu i význam; katalog a sémantická vrstva jako zdroj kontextu místo syrových tabulek; vyhodnocování nasazené dřív, než se funkce pustí k uživatelům; a strop na náklady, protože jinak ho nastaví až první faktura.

Kde je hranice: modely netrénuji. Stavím to, co je kolem nich, a nasazuji hotové. Na návrh experimentu nebo na vlastní model je potřeba někdo jiný a řeknu to hned. A pokud na otázku „co se stane, když se to sebejistě splete“ nikdo nemá odpověď, ta funkce ještě není připravená k návrhu — občas z toho vyjde, že správná odpověď je obyčejný dotaz do databáze.

Datový sklad je společný jazyk firmy. Proto o výsledku rozhoduje modelování, ne volba nástroje — nástroje se vymění po pár letech, dohodnutá definice granularity je přežije všechny.

Cybrainia staví sklady v BigQuery ve vrstvách, kde každá má jednu práci. Raw se nepřepisuje. Staging čistí a typuje. Jádro nese obchodní význam. Marty jsou tvarované pro konzumenty a je levné je zahodit. Transformace v dbt nebo v Dataformu — podle toho, co si klientův tým dokáže převzít, ne podle toho, co je obecně lepší. Ingest v dlt, který data jen přiveze a nic jiného nedělá; schémata, která zdrojové systémy mění bez ohlášení, se pak lámou na hranici, a ne ve čtyři ráno uprostřed transformace. Infrastruktura v Terraformu, konzole jen na čtení.

Náklady jsou vlastnost návrhu. Tabulka bez partitioningu je rozhodnutí platit pokaždé, když se jí někdo dotkne. Na cenu dotazu se dívám stejně jako na latenci — jako na něco, za co odpovídá architektura, ne jako na něco, co o půl roku později objeví finance.

Kde je hranice: streaming. Pro detekci podvodů nebo provozní alerting je to správná odpověď. Pro report, který si člověk otevře jednou denně, skoro nikdy — ztrojnásobí provozní plochu za latenci, kterou nikdo nevyužije. Než na něj kývnu, ptám se, kdo to číslo čte a jak rychle podle něj jedná. A hloubku mám na Google Cloudu; na AWS a Azure se zorientuji, ale nebudu předstírat, že tam znám ostré hrany.

Většina firem strávila poslední roky tím, že dostala data do skladu. Teď zjišťuje, že mít data není totéž co mít jejich význam — a že ten význam je rozprostřený mezi sémantický model v BI nástroji, pár SQL v transformacích a tři analytiky.

Dokud na konci seděl člověk a klikal na připravený dashboard, dalo se to unést. Přestává to jít ve chvíli, kdy má na otázku odpovědět stroj, kterému k ní nikdo cestu předem nepřipravil. Agent dostane tabulku fct_subscription_events a nemá odkud vědět, že „aktivní zákazník“ je sporný pojem, který si finance a marketing definují každý jinak. Tak si tipne — plynule a špatně.

Cybrainia proto drží definice metrik jako verzovaný text: míry, dimenze, granularita, joiny a jedna věta obyčejnou češtinou, co tím byznys myslí. V repozitáři skladu, v code review, mimo proprietární formát. Metrika se překládá do SQL až při dotazu; druhá zhmotněná kopie pravdy se dřív nebo později rozejde a je z toho původní problém s infrastrukturou navíc. Katalog vzniká z modelů, ne ručním vyplňováním — a slouží agentům jako zdroj kontextu, což je poprvé konzument, kterému chybějící popis viditelně vadí.

Kde je hranice: tohle je oblast, ve které se právě pohybuji, ne usazená specializace — čtěte to jako pozici, kterou aktivně zkouším. A nedává smysl ji stavět nad skladem, kterému nikdo nevěří. Sémantická vrstva nad modely, o jejichž číslech se vede spor, ten spor jen posune o patro výš.

Je to nejstarší část téhle práce a lidi překvapuje, že stojí vedle architektury datového skladu. Neměla by: sběrná vrstva rozhoduje, jestli má smysl sklad nad ní stavět. Pěkně namodelovaný sklad plněný špatně instrumentovanými událostmi je drahý způsob, jak se sebejistě mýlit.

Cybrainia řeší GTM jako produkční nasazení, kterým ve skutečnosti je — konvence pojmenování, data layer, který někdo navrhl schválně, verzování a proces změn. Bez toho je to způsob, jak dostat kód do produkce bez code review, a přesně tak se to taky chová. Na server-side GTM posílá prohlížeč jednu first-party událost na tag server a rozeslání, obohacení i vynucení souhlasu se dějí tam. Dál GA4, Measurement Protocol, export do BigQuery a modelování, které po něm musí přijít, protože export není sklad.

Dvě věci opakuji na každé zakázce. Data layer je API: má konzumenty, má kontrakt a jeho změna rozbíjí věci tiše. A skutečná hodnota server-side taggingu není obcházení blokátorů, ale jedno auditovatelné místo, kde se rozhoduje, co z firmy odchází a komu. Kdo si ho pořídí kvůli tomu prvnímu, má za pár měsíců stejný nepořádek, jen běží na Cloud Runu.

Kde je hranice: měřit se má míň, ne víc. Každá událost je závazek na údržbu a nejcennější výstup většiny zakázek je seznam věcí, které se přestaly sbírat. Přestavba trackingu od nuly proto, že GA4 mate, obvykle jen zdědí staré zlozvyky a přidá k nim tag server.