AISQL není BI s AI — je to datová věda v hávu SQL

Dříve znamenalo nasazení AI do produkce Python, MLOps pipeline, infrastrukturu pro nasazení modelů a datavědecký tým, který to celé drží pohromadě. Mezi „máme model“ a „běží v produkci“ zela propast.

Snowflake — a podobné platformy — tuto propast překlenuly. Analytici teď mohou zavolat LLM (velký jazykový model), klasifikovat tickety, extrahovat entity nebo vyhodnotit sentiment pouze SELECTem. Bez Pythonu. Bez externích API. Bez nové infrastruktury.

Vypadá to jako SQL. Používá se to jako SQL. A právě v tom je past.

Protože ve chvíli, kdy váš tým začne zacházet s AI funkcemi jako s běžným SQL — napsat, jednou otestovat, nasadit — tak to nedopadá dobře. Nástroje se staly výrazně jednodušší. Přístup, který vyžadují, se stal výrazně důležitější. A cena za to, když přístup nezměnítě, vzrostla o několik řádů.

Posun, na který nikdo týmy nepřipravuje

Tradiční analytika je deterministická. SUM(revenue) WHERE region = ‚EMEA‘ vrátí pokaždé stejný výsledek. Napíšete kód, jednou ověříte a nasadíte. Náklady jsou předvídatelné. Výstup je předvídatelný. Údržba je minimální.

AI funkce jsou probabilistické. Spusťte stejnou klasifikaci na stejném řádku dvakrát a možná dostanete různé odpovědi. „Přesnost“ už není otázka ano/ne — je to rozdělení pravděpodobnosti. Model s 92% přesností neselhává v 8 % případů pokaždé stejným způsobem; v různých případech chybuje z různých důvodů.

V tomto světě žijí data scientisti odjakživa. Pro analytické týmy je to novinka.

První věc, kterou si jako vlastník projektu musíte zapamatovat: přestaňte se ptát „funguje to?“ a začněte se ptát „kde selhává a co to stojí byznys?“ Klasifikátor s 95% přesností na ticketech zní skvěle — dokud si neuvědomíte, že těch 5 %, kde se mýlí, tvoří výhradně stížnosti velkých enterprise zákazníků. Agregovaná přesnost klame. Důležitý je typ chyb.

Když vám tým přinese číslo — „model má 91% přesnost“ — správná následná otázka není „dostaneme se na 95 %?“ Správná otázka je: „ukažte mi těch 9 %, kde se mýlí, a řekněte mi, která z těch chyb nás stojí peníze.“

Ekonomika se obrátila

Tradiční náklady na Snowflake se odvíjejí od doby běhu warehouse. Jednominutový dotaz na X-Small warehouse stojí zhruba 0,05 $. Spustíte ho tisíckrát za 50 $ a ani nemrknete. Compute je relativně levný, předvídatelný a snadno rozpočtovatelný.

AI funkce se neúčtují stejně. Účtují se za token, a rozptyl je obrovský:

• Spuštění stejného promptu přes milion řádků může stát od několika tisíc na menším modelu až po stovky tisíc na prémiových frontier modelech — za identickou práci.
• Stejný klasifikační úkol se může lišit v nákladech 10× podle toho, který model tým zvolí, přičemž na úrovni výsledku nemusí být žádný zřejmý kvalitativní rozdíl.

Na internetu kolují příběhy o týmech, které spustily jeden AI dotaz přes velký dataset a skončily s pětimístnou fakturou.

Praktický dopad pro vás jako vlastníka projektu: u tradičního SQL je „zkusme to a uvidíme“ chyba za pár korun. U AI funkcí na reálném datasetu je to chyba za vyšší řády. Ekonomika experimentování se obrátila, a to se musí projevit ve způsobu, jak projekty vymezujete.

Dvě rozpočtové otázky, které dříve neexistovaly, ale teď existují:

• Kolik stojí jedno spuštění na celém datasetu? Ne odhad. Změřené číslo z výběrového vzorku, přepočtené na celý objem.
• Kolik stojí každé spuštění při příchodu nových dat? Pipeline, která zpracovává každý nový ticket, zdražuje s rostoucím objemem ticketů. Dashboard ne.

Pokud tato čísla nejsou v zadávacím dokumentu projektu, projekt není plně definován.

ROI > přesnost

Týmy dělají chybu, kdy optimalizují přesnost izolovaně. Přesnost je uspokojivá. Je to číslo, které roste. Působí jako pokrok.

Ale přesnost bez navázaného byznysového výsledku je prázdná metrika.

Vezměme příklad analýzy sentimentu. Model s 65% celkovou přesností zní slabě — dokud se nepodíváte blíže na to, kde chybuje. Chyby se typicky shlukují v nejasném středu: sarkasmus, smíšená zpětná vazba, neutrální výroky, které mohly jít oběma směry. Jasně pozitivní a jasně negativní případy model klasifikuje správně téměř vždy. Většina AI funkcí pro tento účel poskytuje signál — skóre jistoty, nebo explicitní označení „neznámý“ či „smíšený“.

To vám umožní postavit víceúrovňovou pipeline. Jasné případy — řekněme 80 % ticketů — model zařadí automaticky. Nejasné — zbývajících 20 % — jdou k lidskému reviewerovi. Fronta pro ruční review se zmenšila z milionu ticketů na dvě stě tisíc, a automaticky zpracovaná část je vysoce přesná, protože jste automatizovali jen případy, kde si byl model jistý. Celkové číslo je stále 65 %, ale byznysovým výsledkem je 80% snížení ruční práce. To je reálný ROI výsledek, který souhrnná přesnost zcela skrývá.

Správná otázka tedy není „jak přesný to dokážeme udělat?“ — ale „kde leží optimální bod mezi přesností a náklady pro výsledek, který potřebujeme?“ Přesnost a náklady pro její zvýšení jsou křivka. Vyždímat poslední procentní body přesnosti obvykle znamená skok na výrazně dražší model, složitější prompt nebo delší frontu pro ruční review — a tyto náklady jsou významné a opakující se. Cílem je najít bod na křivce, kde každý další přírůstek přesnosti přestane stát za to, co stojí.

Takto uvažují data scientisti. Takhle se již delší dobu navigují kompromisy mezi přesností a úplností. A teď je to problém vašeho týmu — a váš, jako člověka, který definuje, co je „dost dobré“.

Pokud vám tým nedokáže říct, jaká prahová hodnota přesnosti zajistí požadovaný byznysový výsledek, je to signál, že byznysový výsledek sám o sobě není dostatečně jasně definován. A to vede k dalšímu tématu.

Konverzace s businessem se musí změnit

Tradiční sběr požadavků pro BI se týká hlavně co zobrazit. Které KPI. Které dimenze. Které filtry. Byznys řekne „potřebuji čtvrtletní tržby podle regionu“ a analytik to postaví. Výstup je deterministický, takže rozhovor se týká rozsahu, ne chování.

Sběr požadavků pro AI analytiku je fundamentálně jiný. Výstup je probabilistický, náklady se liší podle přístupu a definice „správně“ už není zřejmá. Pět rozhovorů musí proběhnout dříve, než někdo napíše první volání funkce:

1. Co vlastně znamená úspěch — v byznysových pojmech, ne v pojmech přesnosti?

„Klasifikovat support tickety“ není požadavek. „Snížit průměrnou dobu do první odpovědi o 30 % automatickým směrováním ticketů na správný tým“ je. Druhé vymezení vám říká, jaká prahová hodnota přesnosti je důležitá, kde jsou chyby přijatelné a jak měřit, zda to funguje v produkci.

Pokud byznys nedokáže formulovat výsledek v těchto pojmech, projekt není připraven začít. To je nepohodlné říkat na kickoff meetingu. Řekněte to přesto.

2. Jaká je cena za to, mýlit se — a je symetrická?

Skoro žádný úkol AI analytiky nemá symetrické náklady na chybu. Špatná klasifikace běžného ticketu jako urgentního zbytečně zabere pár minut času zkušeného agenta. Špatná klasifikace urgentního enterprise problému jako běžného může stát kontrakt. Označit skutečný signál podvodu jako šum je něco jiného než označit běžnou transakci jako podvodnou.

Byznys musí tuto asymetrii explicitně pojmenovat. Přímo ovlivňuje nastavení modelu, prahovou hodnotu pro ruční review a to, jaký typ chyby tým optimalizuje. Pokud o tom nikdo na byznysové straně nepřemýšlel, proveďte je tím, než tým začne stavět.

3. Kde ruční review zapadá do procesu?

AI analytika zřídkakdy funguje na principu „nastavíme a zapomeneme.“ Pro většinu případů je správná odpověď víceúrovňový systém: model zpracuje jisté případy automaticky, nejasné jdou k člověku a hraniční případy jsou eskalovány.

Navrhnout tento postup je byznysový rozhovor, ne technický. Kdo provádí review? Jak často? Jaké je SLA pro frontu reviewu? Co se děje se zpětnou vazbou — zlepšuje systém, nebo jen leží ladem? Tyto otázky potřebují odpovědi před spuštěním, ne po něm.

4. Jaká je tolerovaná výše rozpočtu — a škáluje s objemem?

Tradiční náklady na BI také škálují s objemem dat a frekvencí spouštění — větší tabulky znamenají větší warehouse, častější spouštění znamená více compute. Rozdíl u AI analytiky není v tom, zda náklady škálují, ale jak strmě a kolik nových pák přibývá.

Tři věci, které je třeba probrat s byznysem:

• Výchozí bod je jiný. AI náklady na řádek jsou o řády vyšší než SQL náklady na řádek. Změna rozsahu, která by byla zaokrouhlovací chybou v tradiční pipeline, může být v AI pipeline rozpočtovou událostí.
• Volba modelu je druhá nákladová dimenze, která v BI neexistuje. Zdvojnásobení datasetu zdvojnásobí náklady. Přechod na prémiový model navíc může náklady vynásobit dalšími 10–50×. Byznys musí vědět, kdo rozhoduje o volbě modelu — a že odpověď může změnit fakturu o řád.
• Opakované spuštění není cachované. V tradičním BI je znovu-dotazování na materializovaná data levné. U AI funkcí je každé spuštění čerstvý compute. Úprava promptu kvůli hraničnímu případu znamená znovu zpracovat dotčené řádky od nuly. Iterace má reálnou nákladovou položku.

Tyto dynamiky musí být na stole při definici projektu, ne jako překvapení na první faktuře.

5. Jak poznáme za tři měsíce, že to stále funguje?

Tradiční BI selhává zřetelně. Dotaz spadne, dashboard ukáže nulu, někdo si toho všimne. AI analytika selhává tiše — přesnost se postupně zhoršuje, hraniční případy se posouvají, model dál produkuje věrohodně vypadající výstupy, které se pomalu odkloňují od reality.

Byznys se musí zavázat k průběžnému procesu review, nejen ke spuštění. Kdo měsíčně sleduje kvalitu výstupů? Kdo rozhoduje, kdy přesnost klesla natolik, že je třeba upravit prompt nebo vyměnit model? Kdo vlastní rozpočet na tuto udržovací práci?

Pokud tito vlastníci neexistují při spuštění, projekt je nastaven na to, aby tiše selhal za šest měsíců.

Červená nit spojující všech pět: AI analytika vyžaduje, aby byznys uvažoval probabilisticky. Většina stakeholderů je nastavena na deterministické systémy — chtějí jasnou odpověď na to, co nástroj bude dělat, co bude stát a jak přesný bude. Upřímná odpověď zní: „záleží na okolnostech, tady je rozmezí a tady je to, co se budeme učit společně.“

To je náročnější rozhovor než definovat rozsah dashboardu. Je to zároveň rozhovor, který odděluje AI projekty přinášející byznysovou hodnotu od těch, které vytvoří působivé demo a tiše zmizí.

Co to znamená pro váš tým

Posun na technické straně je stejně reálný. Vaši analytici teď musí pracovat způsobem, jakým data scientisti pracovali vždy:

• Experimentujte na vzorku, než škálujete. S náklady za token přestalo být „zkusme to a uvidíme“ zdarma. Správný postup je ruční označení malé evaluační sady, iterace promptů na ní levně, a teprve pak škálování na celý dataset, jakmile výsledky splní byznysovou prahovou hodnotu.

• Zacházejte s prompty jako s kódem. Prompt je nová byznysová logika — definuje, co se počítá jako stížnost, co dělá ticket urgentním, co konkrétně vaše kategorie znamenají. Zaslouží si stejnou správu verzí, code review a testování jako cokoliv jiného ve vrstvě transformace dat.

• Sledujte drift. Modely jsou aktualizovány dodavatelem. Vstupní data se mění. Co fungovalo loni ve čtvrtletí, může tiše degradovat. Tým potřebuje označenou „referenční sadu“, která se spouští pravidelně a hlásí, když přesnost klesne — stejně jako se hlásí problémy s čerstvostí dat.

Nic z toho není exotické. Je to přímo převzato z MLOps a data science. Pro většinu analytických týmů je to ale novinka a nestane se to samo od sebe. Jako vlastník projektu nastavujete očekávání. Pokud k projektu přistoupíte jako k běžnému BI projektu, váš tým to udělá také — a za šest měsíců zjistíte, že jím nebyl.

Závěr

Příslib AI v SQL je velký. Vaši analytici teď mohou dělat práci, která dříve vyžadovala celý ML tým. To je skutečně revoluční.

Ale přistup, která dříve sídlil v DS týmu — experimentování, evaluace, vnímání nákladů, monitoring driftu — nezmizí jen proto, že nástroj se zjednodušil. Přesouvá se na analytický tým. A rozhovory, které dříve patřily do plánování DS projektů, se musí přesunout na byznysovou stranu: k lidem, kteří práci zadávají, definují úspěch a vlastní výsledek.

Platformy demokratizovali AI přes SQL. Práce na tom, aby AI přinášela byznysovou hodnotu, stále vypadá jako data science.

Jan Šulc

Business analytik ve společnosti Revolt BI se zkušenostmi se Snowflake a moderními datovými platformami. 

---

Navrhuje škálovatelné datové modely, automatizuje procesy zpracování dat a podílí se na implementaci AI řešení v oblasti enterprise analytiky. Jan pomáhá firmám propojit byznysové cíle s technickou architekturou a proměňovat data a AI v měřitelnou obchodní hodnotu.

Rezervujte si bezplatnou 30minutovou konzultaci. Vezmeme jeden reálný use case z vašeho stacku a ukážeme vám skutečné náklady v kreditech — ještě před tím, než schválíte rozpočet.