Analýza dat obyčejnou řečí: trvalý skill nad DuckDB

Čím dál víc lidí pouští chatbota na svoje data. Přetáhnou do okna export z e-shopu, docházku, výpis z účtu nebo výsledky dotazníku a zeptají se česky: kolik, kdy, proč. Odpověď přijde vzápětí, hezky naformátovaná, s procenty a se závěrem. Vypadá to jako budoucnost analytiky, ale je to ten nejtišší způsob, jak se splést.

Jazykový model je prediktor textu. Sám o sobě neumí počítat — umí napsat číslo, které v dané větě vypadá správně. Někdy je i správné, a právě v tom je problém: nemáte podle čeho poznat, které z těch čísel vzniklo z výpočtu a které z dojmu. Obecně tenhle rozdíl rozebírá tip analýza dat s AI — proč model nesmí počítat v chatu a jak poznat nástroj, který kód opravdu spouští. Tenhle návod na něj navazuje jedním konkrétním řešením: dát agentovi trvalý skill nad DuckDB CLI a pak se ptát obyčejnou řečí.

Nejdřív si ukážeme, kde se to láme, pak porovnáme dvě řešení. Následuje prompt, který celé nastavení založí, rozebraný řádek po řádku — a nakonec to podstatné: jak se pak ptáte a jak si ověříte, že odpověď sedí. Prompty jsou k okopírování, stačí doplnit hranaté závorky.

Vzorová situace

Petra dělá provozní controlling ve firmě s osmdesáti zaměstnanci. Každý měsíc dostane tři exporty: prodeje z pokladny (asi čtyřicet tisíc řádků), skladové pohyby a náklady z účetnictví. Úkol jednoduchý na popsání a otravný na provedení — říct, co se v číslech za minulý měsíc změnilo a proč. Rok to dělala v tabulkovém procesoru: otevřít, opravit desetinné čárky, postavit kontingenční tabulku, zkopírovat do reportu. Půl dne. A když se šéf zeptal na něco, co v šabloně nebylo („a kolik z toho jsou vratky?"), znamenalo to další hodinu.

Pak zkusila chatbota. Dva měsíce nadšení, třetí měsíc se v reportu objevila tržba, která nesedla účetnictví o sto tisíc. Dohledávání trvalo dva dny a příčina byla banální: v jednom exportu byla částka s desetinnou čárkou a model si polovinu řádků přečetl jako text, takže se nesečetly. Nic nespadlo, žádná chybová hláška. Jen tam bylo o sto tisíc míň.

Dneska má Petra DuckDB CLI a v agentovi jeden trvalý skill, který říká, jak se s daty zachází: prohlédnout soubor, napsat dotaz, ukázat dotaz i výsledek. Měsíční report jí zabere dvacet minut a na otázku o vratkách odpoví za dvě. Rozdíl není v tom, že by AI byla chytřejší, ale v tom, že přestala počítat a začala se ptát databáze.

Proč to chatbot spočítá špatně

Za tím, proč se analýza v chatu pokazí, nestojí hloupost modelu, ale dvě konkrétní vlastnosti. Je potřeba je znát jménem — jinak je nepoznáte, až se projeví.

Háček první: model špatně odhadne, jestli si má napsat skript

Moderní modely nejsou naivní. Vědí, že složitější výpočet mají svěřit kódu — obvykle si napíšou Python, spustí ho a vrátí výsledek běhu. U jednoduchých věcí to neudělají, a je to rozumné: kvůli součtu tří čísel není potřeba startovat interpret. Problém je hranice. Model musí odhadnout, jestli je zadání ještě „z hlavy", nebo už „na skript" — a tenhle odhad dělá stejně jako všechno ostatní, tedy pravděpodobnostně. Součet přes dvacet tisíc řádků přitom vypadá v zadání stejně nevinně jako součet přes dvacet řádků. A když se model splete, nedostanete varování „tohle jsem odhadl", ale číslo uvedené stejně sebejistě jako to spočítané.

Typicky se to stane u tří věcí:

• Součet nebo průměr přes velký soubor. Model vidí jen výřez dat, zbytek odhadne. Výsledek sedí do rozsahu a nikoho nenapadne ho ověřovat.
• Průměr místo mediánu u zešikmených dat. Zeptáte se na „typickou objednávku" a dostanete průměr. U dat, kde jsou tři objednávky za dva miliony a osm tisíc za šest set korun, průměr nepopisuje žádného skutečného zákazníka.
• Počítání „přibližně". Otázka „kolik procent transakcí je pod tisíc korun" svádí k odhadu ze vzorku. U dvaceti řádků správně, u dvaceti tisíc mimo.

Háček druhý: skript píše pokaždé znovu a jinak

Řekněme, že model odhadne správně a skript si napíše. Vyhráli jste jen napůl. Za měsíc otevřete nový chat, nahrajete stejný export s novými daty, položíte stejnou otázku — a model napíše jiný skript: jinak si poradí s prázdnými buňkami, jinak zaokrouhlí, jinak si vyloží sloupec stav, možná vyfiltruje storna a možná ne.

Důsledky jsou tři:

• Tokeny, peníze a čas. Za psaní téhož kódu platíte pokaždé znovu a generování s laděním trvá minuty, zatímco odpověď nad SQL dotazem sekundy.
• Riziko chyby. Každé nové psaní je nová příležitost něco přehlédnout; deset generování je deset losování.
• Konec reprodukovatelnosti. Nejhorší z nich. Reprodukovatelnost je základní zásada datové analýzy: stejná data plus stejný postup musí dát stejné číslo — zítra, za rok, i když to spustí někdo jiný. Když postup vzniká pokaždé znovu, nemáte postup, ale pokaždé nový experiment se stejným názvem.

Test, jestli se vás to týká: dokážete říct, jak vzniklo číslo, které jste minulý měsíc poslali do reportu? Ne „zeptal jsem se AI", ale kterými řádky a po jakém filtru.

Jak taková tichá chyba vypadá v praxi

Nejčastější tichá chyba v českých datech není špatná matematika, ale špatně přečtený soubor. Vezměte typický export se středníkem a desetinnou čárkou:

datum;kategorie;castka
2026-01-05;Nájem;-12500,00
2026-01-07;Potraviny;-842,50
2026-01-09;Potraviny;-1230,00
2026-02-01;Mzda;48000,00

Bez ošetření to dopadne takhle (skutečný výstup, ne ilustrace):

duckdb -c "FROM 'vypis.csv' LIMIT 3;"

┌────────────┬───────────┬───────────┐
│   datum    │ kategorie │  castka   │
│    date    │  varchar  │  varchar  │
├────────────┼───────────┼───────────┤
│ 2026-01-05 │ Nájem     │ -12500,00 │
│ 2026-01-07 │ Potraviny │ -842,50   │
│ 2026-01-09 │ Potraviny │ -1230,00  │
└────────────┴───────────┴───────────┘

Všimněte si druhého řádku hlavičky. datum je datum, kategorie je text — a castka je taky text, protože kvůli desetinné čárce ji nešlo přečíst jako číslo. Jakýkoli součet nad takovým sloupcem buď spadne, nebo v jiných nástrojích tiše sečte jen řádky, které se přečíst daly. Nikde se nic nezhroutilo, jen se sešlo číslo psané po česku a nástroj, který o tom neví — a v chatu byste tenhle řádek hlavičky nikdy neviděli. Oprava je přitom jeden parametr:

SELECT * FROM read_csv('vypis.csv', delim = ';', decimal_separator = ',');

Podobných pastí je několik a všechny se chovají stejně nenápadně: kódování (starší české systémy dávají CP1250, takže se rozsypou háčky a kategorie „Nájem" a „N?jem" jsou najednou dvě různé), oddělovač, tisícové oddělovače v číslech, datum jako text a mezisoučtové řádky uvnitř dat, které se sečtou podruhé. Poučení není „nepoužívejte AI na data", ale: než se cokoli spočítá, musí být vidět, co se vlastně načetlo.

Dvě cesty, jak to spravit

Cesty jsou dvě a je poctivé říct rovnou, že ta pracnější je lepší. Poctivá cesta: napsat skript jednou pořádně, uložit ho a spouštět. Necháte si napsat skript v Pythonu nebo R, který data načte, vyčistí, spočítá a uloží výsledky. Žije v souboru vedle dat, verzujete ho, a když ho příští měsíc pustíte nad novým exportem, dostanete čísla spočítaná úplně stejně jako minule. Rozhodnutí o čištění jsou v něm zapsaná a čitelná. To je reprodukovatelnost v plné síle a rozebírá ji druhý článek téhle série, reprodukovatelná analýza dat.

Daň je čas: první verze vezme půl dne a každá nová otázka znamená sáhnout do kódu a otestovat, že se nerozbilo něco jiného. U analýzy, ze které se rozhoduje o penězích, ji zaplatíte rádi. U otázky „a kolik z toho jsou vratky?" v úterý odpoledne je to překážka, kvůli které se ta otázka nikdy nepoloží.

Pragmatická cesta: dát agentovi trvalý skill nad DuckDB CLI. Nepíšete skript, píšete zadání česky. Agent si soubor nejdřív prohlédne, pak napíše SQL dotaz, spustí ho přes DuckDB a vrátí vám výsledek i ten dotaz. Výpočet dělá databáze, ne model — žádné odhadování z hlavy. A protože jsou pravidla uložená ve skillu, chová se agent pokaždé stejně. Reprodukovatelnost je tu ale jen poloviční: dotaz reprodukovatelný je, cesta k němu ne. Uložené SQL spustíte kdykoli znovu a dá stejné číslo; když si ho neuložíte, agent příště napíše podobný, ale ne nutně identický.

| | Skript napsaný jednou pořádně | Trvalý skill nad DuckDB | | --- | --- | --- | | Náklad na start | půl dne až den | patnáct minut | | Náklad na novou otázku | úprava kódu a test | jedna věta česky | | Reprodukovatelnost | úplná, postup je v souboru | částečná, uložíte-li si dotaz | | Kdo počítá | kód, který jste schválili | databáze podle dotazu, který vidíte | | Auditní stopa | verzovaný skript a log běhu | SQL dotaz u každé odpovědi | | Hodí se na | pravidelný report, čísla do účetnictví | průzkum, jednorázová otázka |

Rozhodovací pravidlo: jednorázová otázka a průzkum → skill. Číslo, které se opakuje nebo které někdo bude přepočítávat → skript. A hezky se to kombinuje: skillem prozkoumáte data a najdete správnou otázku, pak si necháte napsat skript, který na ni bude odpovídat každý měsíc stejně.

Co je DuckDB a proč zrovna ono

DuckDB je otevřená analytická databáze. „Analytická" znamená, že je stavěná na dotazy typu „sečti, seskup, porovnej, najdi odlehlé hodnoty" nad velkými tabulkami, ne na tisíce drobných zápisů za sekundu jako databáze za e-shopem. Existuje jako knihovna do různých jazyků a — pro nás podstatné — jako CLI, tedy jeden program, který spustíte v terminálu. Je zdarma a instalaci najdete na duckdb.org.

Databáze, která nepotřebuje databázi

Tohle je vlastnost, kvůli které celý postup dává smysl. Klasická databáze potřebuje instalaci, založení databáze, definici tabulek a import dat; než se dostanete k první otázce, uteče půlden. DuckDB tenhle krok umí přeskočit: čte soubor přímo z disku, jako by to byla tabulka. Cesta k souboru se píše na místo, kde by jinak byl název tabulky:

FROM 'prodeje.csv' LIMIT 5;

Žádné zakládání, žádný import, nic se nikam nekopíruje. Funguje to na CSV, Parquet, JSON, na komprimované soubory (.csv.gz se rozbalí za chodu) a po doinstalování rozšíření i na XLSX. Zvládne i víc souborů najednou přes hvězdičku v cestě:

FROM read_csv('exporty/*.csv', union_by_name = true, filename = true);

union_by_name spáruje sloupce podle jména, ne podle pořadí — nutné, když má jeden z exportů sloupce přehozené. A filename přidá sloupec s cestou, takže poznáte, ze kterého souboru řádek přišel.

Dva příkazy, které stojí za celý nástroj

Na začátku každé analýzy jsou dvě otázky: co v souboru je a jak to vypadá.

SUMMARIZE FROM 'prodeje.csv';

Vrátí jeden řádek za každý sloupec a v něm název, typ, minimum, maximum, přibližný počet unikátních hodnot, průměr, směrodatnou odchylku, kvartily a podíl prázdných hodnot. Jedním příkazem vidíte, jestli se datum načetlo jako datum, jestli je mezi minimem a maximem částky něco nesmyslného, kolik hodnot chybí a jestli má sloupec „region" pět kategorií, nebo pět set (což bývá známka překlepů).

FROM 'prodeje.csv' LIMIT 5;

Prvních pár řádků — a nejdůležitějších pět sekund celé analýzy, protože v hlavičce výpisu jsou typy sloupců. Právě tady poznáte, že se z částky s desetinnou čárkou stal text.

Proč ne tabulkový procesor a proč ne Python

Tabulkový procesor má tři vlastnosti, které se u analýzy dat obracejí proti vám. Nepamatuje si postup — kontingenční tabulka ukazuje výsledek, ale ne to, co jste před ní ručně smazali. Mění data pod rukama: autoformát převede kódy na datumy, ořízne nuly na začátku, sjednotí, co sjednotit nemá. A na desítkách tisíc řádků je pomalý, takže se lidi uchylují ke vzorkům. Neznamená to, že ho zahodíte — naopak, tenhle postup ho přesouvá z počítadla na kontrolní stanoviště, kde si člověk ručně prohlédne deset řádků a ověří, že dotaz nelže. U menších souborů zůstává kontingenční tabulka i vzorce s pomocí AI skvělá volba.

Python je zase mocnější a na složitou statistiku, modelování nebo grafiku nemá SQL šanci. Na běžné „sečti po měsících a kategoriích" má ale tři nevýhody. Je to hodně kódu na málo výsledku: načíst soubor, ošetřit kódování a desetinnou čárku, převést datum, seskupit, seřadit — třicet řádků, ve kterých je třicet příležitostí k chybě, zatímco ekvivalentní SQL dotaz má pět řádků a čte se skoro jako věta. Prostředí je věc navíc: verze Pythonu, balíčky, chybějící pandas, a každá z těch věcí umí sežrat čtvrthodinu; DuckDB CLI je jeden program bez závislostí.

A hlavně: kód se hůř kontroluje. Třicet řádků Pythonu si přečtete se skřípěním zubů, nebo vůbec. V pěti řádcích SQL uvidíte WHERE stav <> 'storno' a hned víte, co se vyřadilo. Kontrolovatelnost je u téhle úlohy důležitější než síla nástroje, protože kontrola je jediné, co vás dělí od tiché chyby. Třetí možnost samozřejmě existuje: skript v Pythonu, který si uvnitř volá DuckDB — to je právě ta poctivá cesta z druhého článku série.

Nastavení: jeden prompt, který to celé založí

Otevřete agenta, který má přístup k souborům a umí spouštět příkazy — Claude Code, Claude Cowork nebo Codex — a pošlete mu tenhle text. Jednou, ne v každém chatu.

Nainstaluj mi DuckDB CLI (jen pokud ho ještě nemám; je zdarma,
návod na duckdb.org) a vytvoř trvalý, opakovaně použitelný skill,
kterým budu nad libovolným datovým souborem dělat analýzy tak,
že ti obyčejnou řečí řeknu, co chci.

Skill ať dodržuje tohle:
- Počítá se přes DuckDB CLI (příkaz duckdb), který čte CSV, Excel,
  Parquet, JSON i gzip přímo ze souboru, bez zakládání databáze.
  SQL syntaxi ber z dokumentace:
  duckdb.org/docs/current/sql/introduction.
- Než napíšeš dotaz, prohlédni si soubor: schéma a statistiky přes
  SUMMARIZE FROM 'soubor', prvních pár řádků přes FROM 'soubor'
  LIMIT 5. Nehádej názvy ani typy sloupců, a když je cokoli
  nejasného, zeptej se uživatele.
- U každé odpovědi ukaž SQL dotaz, kterým výsledek vznikl,
  a počet řádků, které do něj vstoupily.
- Data neupravuj a nepřepisuj. Když je potřeba něco vyřadit nebo
  opravit, udělej to v dotazu a napiš, co a proč jsi vyřadil.
- Skill ulož tak, aby se načítal sám, kdykoli budu mluvit
  o analýze datového souboru — nemusím ho vyvolávat ručně.

Až to bude hotové, ukaž mi, kam jsi skill uložil a co v něm stojí.

Agent DuckDB nainstaluje (nebo zjistí, že už ho máte), založí skill a ukáže vám ho; trvá to pár minut. Poslední řádek nevynechávejte — soubor se skillem si přečtěte, protože od téhle chvíle řídí každou vaši analýzu.

Rozbor řádek po řádku

Každý řádek je proti konkrétnímu selhání. Stojí za to vědět proti kterému — pak si skill umíte upravit.

„Jen pokud ho ještě nemám." Agenti poslušně provedou, co jim řeknete, i podruhé; bez téhle pojistky vám může přeinstalovat něco, co funguje. „Trvalý, opakovaně použitelný" je pak klíčové slovo celého zadání: rozdíl mezi instrukcí v chatu a skillem je rozdíl mezi „řekl jsem to jednou" a „platí to pořád".

„Počítá se přes DuckDB CLI." Bez tohohle řádku má agent na výběr a sáhne po tom, co zná — obvykle po Pythonu. Věta zavírá dveře odhadování z hlavy. A „čte přímo ze souboru, bez zakládání databáze" brání tomu, aby začal budovat schéma a importovat data.

„SQL syntaxi ber z dokumentace." DuckDB má vlastní rozšíření nad standardní SQL (SUMMARIZE, GROUP BY ALL, dotaz začínající FROM) a model, který si vzpomíná na obecné SQL, si funkce vymyslí. Odkaz na dokumentaci je nejlevnější pojistka proti halucinaci.

„Než napíšeš dotaz, prohlédni si soubor." Celá metodika ve dvou příkazech. Bez ní agent píše dotaz podle toho, jak si sloupce představuje.

„Nehádej názvy ani typy sloupců." Agent předpokládá sloupec datum, ve skutečnosti se jmenuje date_created, dotaz spadne — to je ten lepší případ. Horší je, když existují oba a on si vybere ten nesprávný.

„Když je cokoli nejasného, zeptej se uživatele." Nejdůležitější a nejvíc opomíjený řádek. Modely mají zabudovanou snahu odpovědět, ne se ptát. Jenže rozhodnutí typu „mají se storna počítat?", „je cena s DPH?", „co s řádky bez data?" nejsou technická, jsou věcná — a odpověď zná jenom člověk. Tenhle řádek je datová podoba pravidla „AI navrhuje, člověk schvaluje".

„Ukaž SQL dotaz a počet řádků." Auditní stopa u každé odpovědi; bez ní se vracíte k číslu bez původu.

„Data neupravuj a nepřepisuj." Agent, který „opraví" překlepy v kategoriích rovnou v souboru, vám zničí možnost cokoli zkontrolovat. Čištění patří do dotazu, ne do dat.

Co je skill a proč zrovna trvalý

Skill je trvalá instrukce pro agenta, uložená jako soubor. Má krátký popis, podle kterého se agent rozhodne, kdy ji použít, a delší tělo s pravidly. Když se zeptáte na něco, co popisu odpovídá, tělo se načte a agent podle něj postupuje.

Na tom „trvalý" stojí celý rozdíl. Když stejná pravidla vkládáte do každého chatu ručně, časem je zkrátíte, občas na ně zapomenete a v každém chatu jsou trochu jiná — a tím se vrátíte k té nereprodukovatelnosti, kvůli které to celé děláte. Instrukce, kterou musíte pokaždé napsat znovu, je instrukce, kterou dřív nebo později nenapíšete.

Kam se skill ukládá, se liší nástroj od nástroje a v čase se to mění, takže je nejlepší nechat to na agentovi — proto to v promptu stojí obecně. V Claude Code je konvence taková, že skill je soubor SKILL.md ve složce pojmenované po něm, buď osobní (v domovské složce, platí ve všech projektech), nebo projektový (v repozitáři, sdílí se s týmem). V hlavičce je name a description; podle popisu se skill sám aktivuje. Podrobněji je o tom kapitola rutiny a agenti.

Osobní, nebo projektový? Osobní, když analyzujete různá data a pravidla jsou vaše. Projektový, když jde o data konkrétní firmy a chcete, aby všichni počítali stejně; pak se skill dá rozšířit o věci specifické pro vaše data. Je to nejlevnější způsob, jak ve firmě sjednotit definice — víc v tipu AI ve firmě.

A než skill pustíte na ostrá data, vyzkoušejte ho nanečisto: nechte si vyrobit testovací CSV o dvou stech řádcích s typickými českými neduhy (středník, desetinná čárka, pár duplicit, prázdné kategorie, „Praha" i „praha ", celý týden bez záznamu) a pusťte na něj skill. Když agent rovnou počítá, aniž by se podíval, pravidla zpřísněte.

Jak se pak ptáte

Od téhle chvíle se ptáte česky. Následuje osm zadání, která pokryjí většinu běžné práce s daty a nejsou vázaná na jeden obor — fungují nad prodeji, docházkou, výsledky měření i výpisem z účtu.

1. První seznámení s neznámým souborem

Než položíte první skutečnou otázku, potřebujete vědět, co v souboru je.

Budeme analyzovat soubor [název souboru].

Zatím nic nepočítej. Prohlédni si ho a napiš mi:
1. Kolik má řádků a sloupců.
2. U každého sloupce: jak se jmenuje, jaký typ se načetl, kolik
   má prázdných hodnot a kolik různých hodnot obsahuje.
3. Které sloupce se podle tebe načetly ve špatném typu (typicky
   číslo nebo datum přečtené jako text) a jak by se to opravilo.
4. Co je v těchto datech jedno pozorování — co znamená jeden řádek.
5. Na co se mě potřebuješ zeptat, než začneme počítat. Nešetři:
   radši se zeptej na pět věcí, než abys jednu odhadl.

Bod 3 je pojistka proti tiché chybě z úvodu — když se v odpovědi objeví, že „částka se načetla jako text", máte diagnózu dřív, než jste cokoli sečetli. A když agent neumí říct, co je jeden řádek, jsou v datech obvykle smíchané úrovně, třeba objednávky a mezisoučty.

2. Přehled po obdobích s kategoriemi a skupinou Ostatní

Nejčastější zadání vůbec: vidět, jak se struktura vyvíjí v čase, a netopit se v padesáti kategoriích, ze kterých čtyřicet má po dvou řádcích.

Budeme analyzovat soubor [název souboru].

Udělej mi přehled po [měsících] podle opakovaných kategorií.
To, co se pravidelně neopakuje, zařaď do skupiny Ostatní.
Za opakovanou považuj kategorii, která se objeví aspoň
[ve třech obdobích] a tvoří aspoň [1 %] celku.

Výstup: tabulka období krát kategorie, v buňkách [součet částky]
a v závorce počet záznamů, plus součty za kategorii i za období.

Pod přehledem vypiš všechny anomálie porušující typické vzorce:
- kategorie, která se objevila poprvé nebo naopak zmizela,
- hodnota odchýlená od obvyklé úrovně dané kategorie
  o víc než [dvojnásobek],
- období, ve kterém chybí kategorie, jež jinak bývá vždy.

U každé anomálie napiš, o který konkrétní řádek jde.
Nevysvětluj příčiny, jen ukaž, co je nezvyklé.

Pohlídejte si tři věci. Co spadlo do Ostatních — když je to čtyřicet procent celku, jsou prahy špatně. Žádné vysvětlování příčin; poslední věta promptu je tam schválně, protože vysvětlení si model vymyslí přesvědčivě a jenom vy víte, že v květnu vypadl dodavatel. A jestli se nic neztratilo: součet za období musí sedět s celkovým součtem souboru.

3. Porovnání dvou období

Tabulka ukáže, co se stalo. Tohle zadání ukáže, čím to je.

Porovnej v souboru [název] období [A] proti období [B].

Chci tabulku: [kategorie], hodnota v období A, hodnota v období B,
absolutní rozdíl, procentní změna a PŘÍSPĚVEK k celkové změně
v procentních bodech. Seřaď podle příspěvku, největší nahoře.

Pak zvlášť rozlož celkovou změnu na dvě složky: změnu počtu
záznamů a změnu průměrné hodnoty záznamu.

Nakonec vypiš kategorie, které jsou jen v jednom z období.

Období definuj podle sloupce [datum] a napiš mi, kolik dní každé
z nich obsahuje — když se liší, upozorni na to.

Vrátí rozpad, ze kterého je vidět, která kategorie za změnu skutečně může. Rozklad na počet a průměr je nejrychlejší diagnostika, jakou máte — „přišlo míň záznamů" a „záznamy byly menší" jsou dva různé problémy. Poslední odstavec je proti nejčastější chybě ve srovnávání: únor má o tři dny míň než leden a už to samo vyrobí „propad" kolem deseti procent.

4. Duplicity a nekonzistence

Špinavá data nevypadají špinavě. Poznají se jenom tím, že se zeptáte.

V souboru [název] chci najít nepořádek. Nic neopravuj, jen vypiš.

1. Úplné duplicity: řádky shodné ve všech sloupcích, s třemi příklady.
2. Duplicity podle klíče [sloupec nebo kombinace sloupců]: záznamy
   se stejným klíčem, ale odlišné v ostatních sloupcích.
3. Textové hodnoty, které jsou nejspíš totéž psané jinak: liší se
   jen velikostí písmen, mezerami na konci, diakritikou nebo
   překlepem. Ukaž je ve dvojicích s četností obou variant.
4. Hodnoty mimo očekávaný rozsah: záporná čísla tam, kde nedávají
   smysl, data v budoucnosti, nulové částky.
5. Sloupce, kde chybí víc než [5 %] hodnot.

U každého bodu napiš počet zasažených řádků a podíl z celku.

Vrátí soupis, který byste ručně hledali půl dne. Bod 3 je nejcennější — dvě varianty psaní téže kategorie tiše rozdělí čísla na půl a v souhrnu to není vidět. Nález v bodu 2 znamená buď opravné verze v datech, nebo špatně zvolený klíč; rozhodnout to musíte vy.

5. Segmentace: kdo nebo co tvoří většinu

Klasický Paretův pohled. Funguje na zákazníky, produkty, dodavatele i chybové kódy.

V souboru [název] mě zajímá rozložení podle [sloupec, např.
zákazník / produkt / pobočka].

1. Seřaď segmenty podle [součtu hodnoty] a ukaž top 20:
   segment, hodnota, podíl na celku, kumulativní podíl.
2. Napiš, kolik segmentů dělá 50 % a kolik 80 % celku.
3. U každého segmentu z top 20 přidej počet záznamů a MEDIÁN
   hodnoty záznamu, ne průměr.
4. Zvlášť ukaž segmenty s jediným záznamem — kolik jich je
   a jaký podíl celku tvoří dohromady.

Přidej řádek „zbytek" se souhrnem ostatních segmentů,
ať tabulka sedí na celek.

Medián místo průměru v bodu 3 je tam schválně: u zešikmených dat popisuje průměr něco, co v datech neexistuje, a když se od mediánu výrazně liší, táhne segment pár extrémů. Bod 4 bývá překvapení: „dlouhý ocas" jednorázových segmentů často tvoří větší podíl, než kdokoli čekal.

6. Spojení dvou souborů přes společný klíč

Ta chvíle, kdy prodeje potřebujete obohatit o číselník produktů nebo docházku o organizační strukturu.

Mám dva soubory: [soubor A] a [soubor B].
Chci je propojit přes [společný sloupec].

Nejdřív mi bez počítání napiš:
- kolik unikátních hodnot klíče je v každém souboru,
- kolik hodnot z A nemá protějšek v B a naopak — u obou ukaž
  pět příkladů,
- jestli je vztah 1:1, nebo se některý klíč v jednom ze souborů
  opakuje (a kolikrát nejvíc).

Teprve pak je spoj tak, aby se ze souboru A neztratil ani jeden
řádek, a doplň z B sloupce [výčet].
Po spojení mi napiš, kolik má výsledek řádků, a porovnej to
s počtem řádků v A. Když se čísla liší, vysvětli proč.

Vrátí diagnostiku a teprve pak spojení — a ta předběžná kontrola je celý smysl promptu. Spojování je nejrychlejší způsob, jak nepozorovaně nafouknout data: když se klíč v druhém souboru opakuje, počet řádků se znásobí a všechny součty jsou vyšší; když chybí, tiše vypadnou řádky.

7. Kontrola úplnosti dat

Nejpodceňovanější zadání ze všech: analýza nad neúplnými daty je horší než žádná, protože vypadá kompletně.

V souboru [název] chci ověřit, jestli jsou data úplná.

1. Nejstarší a nejnovější [datum] v souboru.
2. Časovou řadu počtu záznamů po [dnech / týdnech / měsících] —
   vypiš ji celou, ať vidím díry.
3. Období, ve kterých není ani jeden záznam, i když sousední
   období záznamy mají. Vypiš je jako konkrétní rozsahy.
4. Období, kde je počet záznamů výrazně nižší nebo vyšší než
   obvykle (odchylka od mediánu o víc než [50 %]).
5. Jestli se v čase mění složení dat: kategorie objevující se jen
   v části období, nebo sloupec, který je od určitého data
   prázdný. Napiš i to, kdy přesně ke změně došlo.

Vrátí mapu děr. Bod 5 je ten, kvůli kterému to děláte — když se v půlce období změnila metodika sběru nebo se přestal plnit jeden sloupec, každé srovnání „letos proti loni" je od té chvíle nesmysl a nikde to není napsané.

8. A na konec: výsledek dostat ven z chatu

Nechte si výsledek uložit do CSV se středníkem a hlavičkou a vedle něj textový soubor s dotazem, zdrojovým souborem, počtem řádků a seznamem toho, co bylo vyřazeno a proč. Dotaz si vyžádejte tak, aby šel příští měsíc pustit nad novým exportem beze změny — bez natvrdo zapsaných dat a hodnot. Takhle uložený dotaz je zárodek reprodukovatelné analýzy a stačí ho zabalit do skriptu; jak z toho udělat pravidelnou rutinu, ukazuje tip osobní rozpočet z bankovního výpisu.

Jak poznáte, že výsledek sedí

Nic z předchozího neznamená, že je výsledek správně. Znamená to, že je kontrolovatelný — a kontrola je pořád na vás. Čtyři návyky, každý na pár minut.

Nechte si vypsat dotaz, který to spočítal

Skill to má nařízené, ale vy si to musíte doopravdy přečíst. Nemusíte umět SQL psát, stačí ho umět zkontrolovat: hledáte odkud se čte, co se vyřadilo (WHERE), podle čeho se seskupuje (GROUP BY) a co se sčítá. Když v dotazu uvidíte filtr, o kterém jste nevěděli, máte odpověď na to, proč číslo nesedí.

Ukaž mi dotaz, kterým vzniklo číslo [konkrétní hodnota], a rozeber
mi ho po částech běžnou češtinou — u každé části napiš, jaké
rozhodnutí o mých datech v sobě skrývá.

Pak zvlášť vypiš:
- které řádky dotaz vyřadil a kolik jich bylo,
- co se stane s řádky, kde je [sloupec] prázdný,
- kde by dotaz mohl vrátit špatné číslo, aniž by spadl.

Nakonec napiš jednu alternativu: jak by šlo totéž spočítat jinak
a proč by výsledek mohl vyjít jinak.

Poslední odstavec je nejcennější. Když dvě rozumné cesty ke stejnému číslu dají různý výsledek, není chyba ve výpočtu — je v zadání. Typicky se ukáže, že „měsíční tržba" znamená tři různé věci podle toho, počítá-li se podle data objednávky, zaplacení, nebo faktury.

Kontrolní součet proti jinému zdroji

Nejsilnější kontrola, jakou máte: vezměte jedno číslo, které znáte odjinud, a porovnejte ho. Celkový obrat z účetnictví, počet zaměstnanců z personálního systému, počet objednávek z administrace.

Když sedí, věříte celé cestě od načtení souboru po agregaci. Když nesedí, rozdíl vám obvykle rovnou řekne, kde je problém: chybí zaokrouhlená částka? Nejspíš vypadly řádky s prázdnou hodnotou. Chybí přesně jedna kategorie? Filtr. Je to o dvacet procent míň? Podívejte se na typ sloupce.

Kolik řádků vypadlo a proč

Každý filtr něco zahazuje a tichý úbytek řádků je nejčastější příčina špatného čísla, které nikoho neupozorní. U každého mezikroku chcete znát tři čísla: kolik řádků bylo na začátku, kolik zbylo a kolik z toho udělal který krok.

U poslední analýzy mi udělej bilanci řádků:
- kolik řádků měl zdrojový soubor,
- kolik jich postupně ubylo v každém kroku a z jakého důvodu,
- kolik jich vstoupilo do finálního výsledku,
- kontrola: sedí součet vyřazených a započítaných na celek?

U každého kroku, který vyřadil víc než [2 %] řádků, ukaž pět
konkrétních vyřazených řádků, ať vidím, o co jsem přišel.

Pokud nějaké řádky vypadly nechtěně, napiš to natvrdo místo
toho, abys to vysvětloval.

Ukázka vyřazených řádků je ta část, kde se poznají skutečné problémy — najednou vidíte, že „vyřazeno 340 řádků bez data" jsou objednávky z jedné pobočky, která datum zapisuje jinak.

Test na malém vzorku, kde znáte odpověď

Nejpodceňovanější návyk: spočítejte totéž ručně na deseti řádcích a porovnejte. Vezměte jednu kategorii a jeden měsíc, kde je záznamů málo, otevřete data v tabulkovém procesoru, sečtěte to a porovnejte s tím, co vrátil dotaz.

Zabere to pět minut a chytí to třídu chyb, kterou žádná jiná kontrola nechytí — testujete totiž pochopení zadání, ne správnost výpočtu. Databáze počítá spolehlivě; otázka je, jestli počítá to, co jste chtěli.

AI navrhuje, člověk schvaluje — v datové podobě

Zásada, která platí na celém tomhle webu, má u dat konkrétní podobu: AI smí navrhnout výpočet, ale význam čísla schvaluje člověk.

Za prvé, věcná rozhodnutí nedelegujete. Jestli se počítají storna, jestli je cena s DPH, co se stane s řádky bez kategorie, jestli se vratky odečítají nebo evidují zvlášť — na tyhle otázky nezná odpověď žádný model, protože nejsou v datech, ale ve vaší firmě. Proto je ve skillu ten řádek o ptaní se.

Za druhé, výsledek se ověřuje proti realitě, ne proti dojmu: číslo není správné proto, že vypadá rozumně, ale když sedí na něco nezávislého. Za třetí, odpovědnost za číslo v reportu je vaše. Když se na poradě zeptají „odkud to je?", věta „to mi spočítala AI" není odpověď. Odpověď je „ze souboru XY za období Z, po vyřazení storen, sedí to na účetnictví na tisícikoruny".

A jedna věc navíc: citlivá data. Výhoda tady popsaného postupu je, že data zůstávají na vašem disku — DuckDB je počítá lokálně a agent posílá do modelu jen dotazy a agregované výsledky. Přesto platí obvyklé pravidlo: pracujte v placeném účtu se smluvní ochranou dat a osobní údaje z exportu vyhoďte nebo nahraďte pořadovým číslem. Souhrn po kategoriích nikdy nepotřebuje jména.

Nejčastější chyby

• Věřit číslu, u kterého jste neviděli dotaz. Skill má ukazování dotazu nařízené, ale když ho přeskočíte a jen zkopírujete výsledek, jste zpátky na začátku.
• Nechat agenta hádat význam sloupců. Sloupec hodnota může být s DPH i bez, datum může být objednávka i expedice, stav může mít osm hodnot, z nichž tři znamenají zrušeno. Když se agent nezeptá, vysvětlete mu to sami — a přidejte tu informaci do skillu.
• Přehlédnout typ sloupce. Nejtišší chyba v českých datech: částka s desetinnou čárkou se načte jako text a součty jsou neúplné. Řádek s typy je hned pod hlavičkou výpisu.
• Nechat si vysvětlit příčinu anomálie. Když necháte agenta říct, proč v květnu vyskočila jedna kategorie, vymyslí si věrohodné vysvětlení. Příčinu znáte vy nebo ji zjistíte dotazem k lidem — víc v tipu ověřování faktů.
• Používat skill i na čísla, která mají být reprodukovatelná. Podklady pro účetnictví nebo publikovaný výsledek patří do uloženého skriptu, ne do konverzace.
• Nechat agenta upravovat zdrojová data. Jakmile se soubor přepíše, ztrácíte možnost cokoli ověřit.
• Zapomenout na kontrolní součet. Jediné číslo z nezávislého zdroje ušetří dny dohledávání — a vypadá zbytečně přesně do chvíle, kdy zbytečné není.

Nejlepší nástroje

• DuckDB CLI — výpočetní stroj celého postupu: čte CSV, Excel, Parquet, JSON i komprimované soubory přímo z disku a odpovídá SQL dotazem, který je vidět a dá se zkontrolovat.
• Claude Code — agent nad složkou s daty: nainstaluje DuckDB, založí a udržuje skill, píše a spouští dotazy. Podrobněji v tipu Claude Code jako osobní automatizační motor.
• Claude Cowork — stejná práce v desktopovém režimu nad složkou souborů, bez terminálu.
• Skill (trvalá instrukce agenta) — místo, kde jsou uložená pravidla postupu i znalosti o vašich datech.
• Tabulkový procesor — kontrolní stanoviště, ne počítadlo: na ruční ověření deseti řádků a na rychlý souhrn přes kontingenční tabulku.
• Python s DuckDB nebo pandas — pro chvíle, kdy skill nestačí: statistika, modelování, grafy a všechno, co má běžet každý měsíc stejně. Cesta k tomu je v tipu malé skripty bez programování.

Co vám to přinese

• Čas: otázka, na kterou se dřív stavěla kontingenční tabulka, je hotová za minutu; odpoledne nad exportem se scvrkne na půl hodiny.
• Peníze: rozhodujete podle rozpadu, ne podle souhrnného čísla, takže řešíte skutečnou příčinu. Jedno nesprávné číslo v podkladu stojí víc než večer strávený jeho ověřením.
• Klid: u každého čísla víte, ze kterých řádků vzniklo a jakým dotazem. Otázka „odkud to máš?" přestane být nepříjemná.
• Kvalita: povinné prohlédnutí souboru odhalí duplicity, chybějící období a špatně načtené typy dřív, než se dostanou do reportu.

Pro tip

Až budete mít skill zaběhnutý, udělejte krok navíc: doplňte do něj znalosti o vašich konkrétních datech. Ne jen jak se počítá, ale co která věc znamená. Že sloupec stav má hodnoty nova, zaplacena, storno a vratka a že storna se do obratu nepočítají, zatímco vratky ano, jen se odečítají. Že soubor z pokladny má středník a CP1250, zatímco export z e-shopu čárku a UTF-8.

Vzniká tím něco cennějšího než návod k nástroji: zapsaná datová definice vaší firmy. Znalost, která dosud existovala jen v hlavě jednoho člověka, se stane souborem, který se sdílí, verzuje a opravuje — a všichni díky ní počítají stejně. Je to nejlevnější řešení sporu „mně to vyšlo jinak", který v každé firmě zabírá víc času než samotná analýza.

A závěrečné pravidlo nad celým návodem: model nesmí být tím, kdo počítá — smí být jen tím, kdo umí položit otázku a napsat dotaz. Ve chvíli, kdy se číslo objeví v odpovědi bez dotazu, který ho spočítal, nemáte analýzu. Máte text, který má náhodou desetinnou čárku. Na plnou reprodukovatelnost, kde postup žije ve verzovaném skriptu, navazuje reprodukovatelná analýza dat.