Jedna buňka rozhodne o celé tabulce
Chyba v datech málokdy vypadá jako chyba. Vypadá jako obyčejné číslo nebo obyčejné jméno, které jen sedí na špatném místě. Tahle hra staví přesně na tom: v malé tabulce firemních záznamů je jediná vadná buňka a úkolem je najít ji a pak určit, o jaký typ vady jde.
Kvalita dat se dá rozdělit na pár měřitelných vlastností: přesnost, úplnost, jednotnost a jedinečnost každého záznamu. Tahle hra trénuje pět konkrétních případů, kdy jedna z těch vlastností chybí, a každý z nich se v české firemní praxi opakuje dokola.
Pět vad, které se vrací
Duplicita je nejzákeřnější, protože zřídka vypadá jako duplicita. Stejná zákaznice se v tabulce objeví jako „Nováková Petra“ a o řádek níž jako „P. Nováková“. Jméno je jiné, ale IČO je stejné, a právě IČO je stabilní identifikátor, podle kterého se duplicita skutečně pozná, ne podle podobnosti textu.
Špatný formát IČO je druhá skupina. Osmimístné číslo se při špatném importu zkrátí na sedm číslic, natáhne na devět, nebo se rozdělí mezerami. Číslice mohou být správné, ale řetězec už neodpovídá tomu, co čeká registr ARES nebo účetní systém při párování faktury.
Chybějící diakritika je vada, která se dá snadno přehlédnout, protože zbytek jména vypadá v pořádku. „Kadlecová Sárka“ místo „Kadlecová Šárka“ je jediný chybějící háček, ale pro systém, který páruje zákazníky podle přesné shody jména, je to jiná osoba. Ve složitějších případech vznikne z chybného kódování takzvané mojibake, řetězec typu „Dvořáková“, který vznikl tím, že soubor uložený v UTF-8 někdo přečetl, jako by šlo o jednobajtové kódování.
Míchané jednotky jsou vada, která se v součtu vůbec neprojeví jako podezřelá. Sloupec délky v metrech obsahuje jednu hodnotu v centimetrech, sloupec hmotnosti v kilogramech jednu hodnotu v gramech. Report, který sloupec jen sečte, spočítá číslo bez chyby, jenže výsledek neznamená to, co si report myslí.
Nula místo prázdné hodnoty je poslední a možná nejtišší vada. Nula u tržeb může znamenat dvě úplně jiné věci: zákazník skutečně ukončil odběr, nebo obchodník ještě nestihl číslo zadat. Slít obě situace do jedné nuly umělé sníží průměr a schová neúplnost dat za zdánlivě čisté číslo.
Kontrola IČO jako vzor pro celou kvalitu dat
Kontrola IČO je dobrý příklad, proč se kvalita dat nedá odbýt zběžným pohledem. České IČO má vždy osm číslic a ta poslední je kontrolní, dopočítaná z prvních sedmi podle pevného algoritmu s váhami 8 až 2 a dělením jedenácti. Číslo, které projde textovým polem bez varování, může být přesto neplatné, a validace to odhalí okamžitě, zatímco člověk by si toho všiml až u chybové hlášky z registru nebo u vrácené faktury.
Stejná logika platí i pro ostatní čtyři vady. Každá se dá zachytit automatickým pravidlem, dřív než se dostane do reportu, faktury nebo tréninkových dat.
Proč AI potřebuje čistá data
Člověk nad podezřelým řádkem obvykle zaváhá. Model se nezastaví. Naučí se vzor, který mu data ukážou, ať je správný nebo ne, a bude ho opakovat důsledně a ve velkém měřítku. Duplicitní záznam nezpůsobí jen jednu chybnou fakturu, ale zkreslí i statistiku, ze které model počítá průměry a doporučení. Nula místo chybějící hodnoty nezůstane jedna anomálie, ale stane se tichým vzorem, který model převezme jako fakt.
Proto čištění dat není administrativní úkon, který se odbyde před zahájením projektu. Je to průběžná práce, protože nová data přibývají každý den a každý kanál, formulář nebo ruční přepis, může přinést jinou vadu. Kdo umí takovou vadu pojmenovat na první pohled, dřív ji chytí, než stihne poškodit rozhodnutí, které se na datech staví.
Kde se vada vezme a kdo ji obvykle najde
Většina vad z téhle hry nevzniká zlým úmyslem, ale běžným provozem. Excel při otevření souboru přepíše sloupec s IČO na číslo a smaže úvodní nulu. Import ze staršího systému uloží jméno v jednom kódování znaků a přečte ho v jiném, takže z diakritiky zbydou otazníky nebo mojibake. Dva obchodní týmy zadají stejnou firmu do dvou různých CRM, každý s trochu jiným zápisem jména, a po sloučení databází vzniknou dva záznamy tam, kde má být jeden. Nikdo tyhle vady nevytváří schválně, vznikají jako vedlejší produkt běžných kroků: importu, exportu, ručního přepisu a sloučení systémů.
Právě proto nestačí spolehnout se na to, že vadu odhalí ten, kdo data zadává. Člověk, který zapisuje fakturu, nevidí zbytek tabulky a nemá důvod pochybovat o vlastním zápisu. Vadu obvykle najde až někdo jiný, o krok dál v pipelině: účetní, kterému nesedí součet, analytik, kterému report vychází podezřele hladce, nebo model, který se z chybných dat naučil špatné pravidlo. Čím dřív se kontrola dostane co nejblíž ke zdroji dat, tím levnější je oprava.