Jedna z najčastejších viet, ktorú počujeme pri vstupnom workshope s klientom: „Máme tisíce dokumentov, databázy, históriu servisných zápisov, e-maily od zákazníkov — dáta určite máme." Technicky je to pravda. No keď sa spýtame, ako vyzerá jeden reprezentatívny záznam a odkiaľ presne pochádza, začnú sa objavovať veci: súbory uložené v troch rôznych verziách SharePointu, záznamy duplicitné so vzájomne si odporujúcimi hodnotami, dokumenty naskenované ako obrázky bez OCR, Excel tabuľky so zmyslovými názvami stĺpcov len pre toho, kto ich vytvoril v roku 2018.
Dátová pripravenosť je, podľa viacerých prieskumov, kľúčovým rozlišovacím faktorom medzi AI projektmi, ktoré dosiahli merateľnú hodnotu, a tými, ktoré skončili ako opustené piloty. Tento článok nie je o tom, aké modely nasadiť. Je o tom, čo treba spraviť skôr, než sa k modelom vôbec dostanete.
Prečo "máme dáta" ≠ "dáta sú pripravené"
Pripravenosť dát pre AI má inú definíciu ako "dáta sú niekde uložené". Model — či už ide o RAG pipeline alebo fine-tuning — potrebuje dáta v konkrétnom stave:
- Strojovo čitateľné: text extrahovaný z PDF, obrázkov a tabuliek v štruktúrovanej podobe
- Konzistentné: rovnaké entity pomenované rovnako (zákazník "ACME s.r.o." vs. "Acme SR" vs. "ACME Slovakia" sú pre model tri rôzne entity)
- Relevantné a čisté: bez duplicít, bez zastaraných verzií, bez interného "šumu" (testovacie záznamy, sandbox dáta, draft dokumenty)
- Správne anotované alebo štruktúrované: model musí vedieť, čo dáta reprezentujú, nie len vidieť surový text
- Prístupné a spravovateľné: jasné vlastníctvo, verzia, dátum platnosti, prístupové práva
Cisco AI Readiness Index reportuje, že len ~34 % firiem hodnotí svoju dátovú pripravenosť ako dostatočnú pre AI nasadenie. Z nášho pohľadu v teréne toto číslo znie optimisticky — väčšina projektov strávi prvú tretinu celého engagementu práve na dátovej príprave, nie na modeloch.
Fáza 1: Inventúra — čo vlastne máme
Pred akýmkoľvek technickým rozhodnutím je nutné zmapovať existujúce dátové zdroje. V praxi to znamená odpovede na tieto otázky:
Kde dáta fyzicky sú?
- Databázy (PostgreSQL, MySQL, MSSQL, Oracle)
- Zdieľané disky a dokumentové systémy (SharePoint, Google Drive, NAS)
- ERP / MES / SCADA systémy (SAP, Infor, Siemens WinCC, Ignition)
- E-maily a komunikačné nástroje
- Papierová dokumentácia naskenovaná ako obrázky
- Logy strojov a senzorové dáta (MQTT, OPC-UA, priemyselné databázy ako InfluxDB)
Každý zdroj má iný formát, inú frekvenciu aktualizácie, iný stupeň štruktúrovanosti a iné prístupové práva. Zoznam všetkých zdrojov je prvý artefakt dátového pipeline projektu.
Aká je kvalita?
Pre každý zdroj odhadnúť:
- Percentuálna úplnosť kľúčových polí (koľko záznamov má vyplnené všetky povinné polia?)
- Konzistencia formátu (sú dátumy vždy v rovnakom formáte? Sú kategórie z fixného číselníka alebo voľný text?)
- Duplikácia (existujú záznamy, ktoré reprezentujú tú istú entitu viackrát?)
- Aktuálnosť (kedy bol záznam naposledy overený? Existujú zastaralé verzie?)
Tento audit nemusí byť perfektný — cieľom je identifikovať kritické problémy, ktoré by projekt zablokovali, nie dosiahnuť stopercentnú čistotu pred spustením.
Kto dáta vlastní?
Pre každý zdroj: kto je zodpovedný za obsah? Kto má oprávnenie meniť prístup? Kto vie povedať, čo záznam znamená? Bez jasného vlastníctva dát sa AI projekt môže zaseknúť v medziodborových sporoch o to, kto schváli, že jeho databáza môže byť použitá na tréning alebo retrieval.
Fáza 2: Extrakcia a normalizácia
Keď poznáme zdroje, nasleduje technická práca: dostať dáta do jednotnej podoby, s ktorou môže pipeline pracovať.
Extrakcia zo štruktúrovaných zdrojov
Z relačných databáz a ERP systémov je extrakcia relatívne priamočiara — SQL dotazy, API volania, CSV export. Kritické je definovať:
- 1.Ktoré tabuľky / polia sú relevantné pre daný use-case (nie extrahovať celý ERP)
- 2.Aká je frekvencia aktualizácie (batch raz denne, alebo streaming zmien cez CDC — Change Data Capture)
- 3.Ako sa mapujú technické názvy polí na ľudsky zrozumiteľné (stĺpec
ord_stat_cd→ "stav objednávky")
Extrakcia z neštruktúrovaných zdrojov
Dokumenty, e-maily, technické výkresy a naskenované formuláre sú náročnejšie. Potrebné kroky:
- OCR pre naskenované dokumenty: nástroje ako Tesseract, Azure AI Document Intelligence alebo Google Document AI dokážu extrahovať text z obrázkov a PDF. Kvalita OCR výstupu priamo ovplyvňuje kvalitu odpovedí modelu.
- Chunking: dlhé dokumenty treba rozdeliť na menšie segmenty pred vektorizáciou. Naivný chunking po 512 tokenoch rezom uprostred vety je bežný zdroj problémov v RAG pipeline kvality. Lepšie je chunkovanie po logických celkoch (odseky, sekcie, tabuľky).
- Metadata extrakcia: každý chunk musí niesť metadata — odkiaľ pochádza, dátum vzniku, aktuálnosť, autor, prípadne kategória. Tieto metadata slúžia na filtrovanie pri retrieval a na zobrazenie zdroja v odpovedi.
Normalizácia entít
Rovnaká firma v troch rôznych zápisoch je pre vektorový model tri rôzne entity s podobným embeddingom, ale pre fuzzy vyhľadávanie alebo filter je to problém. Entity resolution — zjednotenie rôznych zápistov tej istej entity — je práca, ktorá sa niekedy robí manuálne (číselníky zákazníkov), niekedy poloautomaticky (fuzzy matching na názvy firiem) a niekedy pomocou LLM (ak sú záznamy v prirodzenom jazyku).
Fáza 3: Čistenie a validácia kvality
Čistenie dát je iteratívny proces. Nie je možné urobiť ho raz dokonale — vznikajú nové dáta, menia sa formáty, objavia sa nové vzory chýb.
Konkrétne kroky, ktoré vidíme v praxi
- Odstraňovanie duplikátov: identifikácia záznamov, ktoré reprezentujú tú istú informáciu s rôznymi identifikátormi
- Oprava formátových chýb: dátumy v rôznych formátoch, číselné hodnoty so zapísanou jednotkou v poli, telefónne čísla s rôznymi formátmi prefixov
- Riešenie chýbajúcich hodnôt: doplnenie kde je to možné, explicitné označenie kde chýba, rozhodnutie o vylúčení kde je záznam bez povinného poľa nepoužiteľný
- Filtrovanie irelevantných dát: testovacie záznamy, sandbox prostredia, interné poznámky, dokumenty s klasifikáciou "draft" alebo "archív"
- Verifikácia aktuálnosti: pre znalostné bázy a RAG pipeline je stará informácia niekedy horšia ako žiadna informácia. Cenovníky spred dvoch rokov, technické listy zastaraných produktov — tie musia mať buď explicitný dátum v metadatách, alebo byť vylúčené.
Čistenie pre prípravu datasetu na fine-tuning má navyše špeciálnu vrstvu: každý tréningový príklad musí mať správnu formu vstup-výstup páru, výstup musí byť správny (nie "náš best-effort odhad"), a dataset musí pokrývať hlavné témy domény rovnomerne. Prázdne plochy v datasete sa premietnu do slepých miest modelu.
Fáza 4: Štruktúra a prístupové práva
Jedným z najčastejšie podceňovaných aspektov dátovej prípravy je kto smie vidieť čo. V enterprise prostredí existujú vrstvy prístupových práv:
- Obchodné zmluvy a ceny, ktoré smie vidieť len obchodný tím
- HR záznamy, ktoré smie vidieť len HR oddelenie
- Technická dokumentácia, ktorá je verejná interne, ale nesmie ísť ku klientom
- Regulačná dokumentácia, ktorá musí byť auditovateľná a nemôže byť zmenená bez záznamu
Keď nasadíte RAG systém, ktorý má prístup k celej znalostnej báze bez ohľadu na tieto práva, a zamestnanec z obchodného oddelenia sa opýta o výrobné náklady (ktoré smie vidieť len výrobný riaditeľ) — systém odpovie. To nie je feature, je to bezpečnostný incident.
Správne riešenie: prístupové práva sa musia preniesť aj do vektorovej databázy. Každý dokument alebo chunk musí mať metadata o tom, kto k nemu smie pristúpiť. Pri retrieval sa filtruje nie len podľa relevancie, ale aj podľa toho, či má volajúci používateľ prístup. Toto je netriviálna architektúra, ale pri deploymente v regulovaných odvetviach (GDPR, obchodné tajomstvo) je povinná.
Fáza 5: Pipeline a aktuálnosť
Dátový pipeline pre AI nie je jednorazová akcia — je to kontinuálny proces. Firemné dáta sa menia každý deň. Nové objednávky, nové dokumenty, zmenené ceny, aktualizované technické listy.
Typy pipeline architektúr
- Batch pipeline (raz denne / týždenne): extrakcia, čistenie a re-indexácia znalostnej bázy v pravidelných intervaloch. Vhodné pre väčšinu dokumentových RAG systémov — tolerancia na 24-hodinovú "staleness" je u väčšiny use-casov akceptovateľná.
- Streaming / near-real-time: zmeny v zdrojovom systéme sa propagujú do vektorovej databázy v priebehu minút. Potrebné pre use-casy, kde dáta zastarávajú rýchlo (ticketing systémy, live inventár, obchodné signály). Vyžaduje CDC (Change Data Capture) architektúru.
- Human-in-the-loop verifikácia: pre citlivé dáta (lekárske protokoly, právne dokumenty, bezpečnostné manuály) každá zmena znalostnej bázy prechádza cez ľudskú schválenie pred tým, než sa objaví v retrieval indexe.
Výber architektúry závisí od frekvencie zmien v zdrojových dátach a od tolerancie use-casu na zastaralosť. Pre väčšinu B2B firemných use-casov postačuje batch pipeline — jednoduchší na prevádzku, lacnejší, dostatočne aktuálny.
Monitoring dátovej kvality
Pipeline musí mať alerting na dátové anomálie: náhly pokles počtu dokumentov (možné zmazanie zdrojového repozitára), zvýšenie podielu prázdnych polí (zmena formátu zo zdrojového systému), duplicity nad prahom (výpadok deduplikácie). Bez monitoringu sa problémy s dátami objavia až keď model začne dávať zlé odpovede — a nie vždy je triviálne trasovať príčinu späť na zdroj.
Fáza 6: Governance a dokumentácia
Toto je časť, ktorú technické tímy neradi robia, ale bez ktorej sa AI projekt pri škálovaní rozpadne.
Čo musí byť zdokumentované
- Data dictionary: pre každý dátový zdroj a každé relevantné pole — čo to je, v akom formáte, kto ho vlastní, kedy bol naposledy overený
- Lineage: odkiaľ dáta prišli, cez aké transformácie prešli, kde sú teraz — schopnosť trasovať konkrétny výstup modelu späť na konkrétny zdrojový dokument
- Change log znalostnej bázy: každá zmena v retrieval indexe musí byť zaznamenaná — čo bolo pridané, čo zmenené, čo odstránené a kedy
- Prístupové práva a ich história: pre GDPR compliance a pri audite je potrebná história toho, kto mal prístup k čomu a kedy
Tieto požiadavky nie sú špecifické pre AI — sú to štandardy data governance, ktoré vyspelé firmy majú pre každý kritický systém. AI ich len zvýrazňuje, pretože výstupy modelu sú priamo viditeľné a ovplyvňujú rozhodnutia.
Typické pasce, ktoré vidíme v praxi
Skôr než prejdeme k záveru, niekoľko vzorcov, ktoré sa opakujú:
- "Dáme mu celý SharePoint": objem nie je problém, relevancia áno. Model indexujúci 50 000 dokumentov vrátane prezentácií z roku 2015, testovacích súborov a zápisníc z interných porád bude mať nižšiu retrieval presnosť ako model indexujúci 2 000 starostlivo vybraných a čistých dokumentov. Menej a lepšie je takmer vždy lepšie ako viac a nekvalitné.
- "Riešime to neskôr": dátová kvalita sa v AI projektoch neopravuje "neskôr". Ak pustíte do produkcie RAG systém s nekvalitnými dátami, používatelia ho prestanú dôverovať rýchlo — a dôveru je oveľa ťažšie získať späť ako vybudovať.
- "Naše dáta sú citlivé, ale nám to nevadí": GDPR a zákon o obchodnom tajomstve sa vzťahujú aj na AI systémy. Ak vaša znalostná báza obsahuje osobné údaje, zmluvy s NDA alebo utajované obchodné informácie, musíte mať právne konzistentný základ pre ich spracovanie aj v AI pipeline.
- "Fine-tunujeme na tom, čo máme": ako sme popísali v článku o príprave datasetu na fine-tuning, nedostatočný objem alebo zlá pokrytosť domény v tréningových dátach vyprodukuje model, ktorý s istotou odpovedá zle — čo je horšie než model, ktorý povie "neviem". Dátová dostatočnosť je pred-podmienka fine-tuningu, nie prajný predpoklad.
Praktické kroky pre začiatok
Ak chcete začať, nie sa stratiť v teórii:
- 1.Vyberte jeden use-case, nie "celú firmu". Jeden konkrétny problém (odpovede na technické dotazy zákazníkov, vyhľadávanie v servisnej dokumentácii, generovanie ponúk z katalógu) má ohraničený dátový rozsah.
- 2.Zmapujte dátové zdroje pre tento use-case — kde sú, aký formát, kto vlastní, aká je aktuálnosť.
- 3.Urobte dátový audit na vzorke — vezmite 100 náhodných záznamov a manuálne posúďte kvalitu. Väčšina problémov bude viditeľná.
- 4.Definujte minimálnu kvalitu pre produkčné nasadenie — nie "perfektné", ale "dostatočne dobré pre daný use-case".
- 5.Navrhnite pipeline — batch alebo streaming, prístupové práva, monitoring.
- 6.Iterujte: prvý index bude nedokonalý. Vyhodnoťte kvalitu RAG odpovedí, identifikujte najčastejšie príčiny zlých odpovedí, opravte dáta alebo pipeline, opakujte.
Časté otázky
Koľko dát potrebujeme na RAG systém?
Pre funkčný RAG systém neexistuje spodný limit počtu dokumentov — aj 50 dobre pripravených dokumentov môže dávať vynikajúce výsledky, ak pokrývajú relevantný rozsah domény. Kritickejšia ako kvantita je pokrytosť: ak používatelia kladú otázky, na ktoré v znalostnej báze odpoveď nie je, model to buď prizná (dobre nastavený guardrail), alebo odpoveď vymyslí (zlý stav). Inventarizujte otázky, ktoré systém musí vedieť zodpovedať, a overte, či sú zodpovedateľné z dostupných dát.
Môžeme použiť interné dáta na fine-tuning bez právnych rizík?
Závisí od povahy dát. Interné technické manuály, SOP dokumenty a historické záznamy bez osobných údajov sú typicky v poriadku — patria firme a neobsahujú PII. Záznamy so zákazníckymi dátami, zmluvami alebo osobnými údajmi zamestnancov vyžadujú právny základ podľa GDPR (súhlas, legitímny záujem, plnenie zmluvy) aj pre spracovanie v AI pipeline. Odporúčame konzultovať s DPO pred tým, než začnete budovať tréningový dataset z regulovaných dát.
Ako dlho trvá dátová príprava?
V praxi vidíme rozptyl od dvoch týždňov (jeden dobre definovaný zdroj, dobrá interná dokumentácia, ochotní dátoví vlastníci) po šesť mesiacov (fragment dát v troch rôznych systémoch, neexistujúca data governance, interné politické prekážky pri prístupe). Priemerný projekt strávi 30–40 % celkového času na dátovej príprave. Ak klient tvrdí, že to zvládnu za týždeň, je to buď veľmi malý scope, alebo podcenenie rozsahu problému.
Potrebujeme data engineer alebo to zvládne AI developer?
Pre jednoduchšie use-casy (PDF dokumenty, jednoduchý SharePoint export) zvládne AI developer základnú extrakciu a chunking. Pre komplexnejšie scenáre — streaming pipeline z ERP systémov, CDC architektúra, normalizácia entít naprieč viacerými zdrojmi, GDPR-compliant lineage — je potrebný skúsený data engineer. Podceňovanie tejto roly je jednou z najčastejších príčin oneskorenia AI projektov.
Musia byť dáta v slovenčine, alebo funguje aj angličtina?
Pre RAG systém na firemné dokumenty je jazyk dokumentov primárny — embedding modely sa používajú multilingválne (modely ako BGE-M3 pokrývajú 100+ jazykov vrátane slovenčiny), retrieval funguje dobre v oboch jazykoch. Pre fine-tuning je jazyk tréningových dát kritický — ak chcete model, ktorý odpovedá v profesionálnej slovenčine s firemnou terminológiou, tréningové príklady musia byť v slovenčine s touto terminológiou.
*Ak riešite prípravu firemných dát pre AI projekt a chcete sa vyhnúť zbytočným omylom, radi s vami prejdeme dátový audit a navrhneme pipeline architektúru primeranú vášmu use-casu. Kontaktujte nás pre nezáväznú konzultáciu.*