Každá stredne veľká výrobná firma v SK/EU spracováva desiatky až stovky papierových alebo naskenovaných dokumentov denne — faktúry od dodávateľov, objednávky od odberateľov, dodacie listy, colné vyhlásenia, technické výkresy s kótami. A pri väčšine z nich niekde sedí zamestnanec, ktorý hodnoty ručne prepísuje do ERP, SAP alebo Excelu. Toto nie je problém, ktorý by firmy ignorovali — je to problém, ktorý sa im doteraz neoplatilo riešiť inak.
V roku 2026 sa to zmenilo. Moderné systémy document intelligence — kombinácia OCR (optického rozpoznávania znakov), vision-language modelov a validačnej logiky — dokážu spracovať štruktúrované aj polo-štruktúrované dokumenty s presnosťou, ktorú ručné prepísanie nedosiahne. Tento článok vysvetlí, kde sa táto technológia oplatí, ako vyzerá reálne nasadenie a kde sú limity, o ktorých vás nikto v marketingovom materiáli neinformuje.
Prečo klasické OCR nestačí
Keď väčšina ľudí počuje "OCR", predstaví si Tesseract alebo Adobe Acrobat — nástroje, ktoré z naskenovaného textu urobia editovateľný text. Pre jednoduchý prípad to stačí. Pre priemyselné dokumenty nie.
Problémy nastávajú hneď na niekoľkých úrovniach:
- Rozmazaný alebo natočený sken z 30-ročnej faxovej faktúry zaváha klasické OCR oveľa viac ako moderný VLM model.
- Tabuľky, kóty a schémy sú pre text-based OCR slepé miesto — dostanete správne znaky, ale stratíte štruktúru, z ktorej vychádza zmysel.
- Variabilita formátov: každý dodávateľ má inú šablónu faktúry. Klasické OCR riešenia to riešia set-up pravidlami pre každú šablónu (rule-based extraction) — čo pri desiatoch dodávateľoch znamená desiatky šablón a permanentnú údržbu.
- Kontextový zmysel: číslo "1500" v pravom dolnom rohu strany môže byť číslo stránky, číslo objednávky alebo suma v eurách — bez kontextu nevie klasické OCR rozlíšiť.
Moderné VLM (vision-language model, napríklad Qwen2.5-VL) tento problém riešia inak: nečítajú len znaky, rozumejú rozloženiu dokumentu a kontextu. Toto je kvalitatívny skok, nie evolučný.
Ako vyzerá document intelligence pipeline
Reálny priemyselný pipeline pre spracovanie dokumentov sa skladá z viacerých vrstiev. Každá z nich môže byť bod zlyhania, ak sa podceňuje.
1. Ingestion a normalizácia
Dokument príde ako naskenované PDF, fotografia z mobilu, email s prílohou alebo EDI výstup zo staršieho systému. Prvý krok je prevod do jednotného interného formátu — s metadátami (zdroj, dátum príjmu, typ dokumentu).
Tu sa skrýva skrytý problém: pri fotografiách z terénu je kvalita vstupu extrémne premenlivá. Neostré, zatienené, poprekladané — toto VLM zvláda lepšie ako klasické OCR, ale nie nekonečne lepšie. Kvalita vstupu stále limituje kvalitu výstupu.
2. Klasifikácia dokumentu
Predtým, ako sa spustí extrakcia, systém musí vedieť, čo spracováva. Faktúra, objednávka, dodací list a technický výkres vyžadujú rôzne extrakčné schémy. Klasifikátor (buď jednoduchý model, alebo pravidlová logika nad štruktúrou dokumentu) zaradí dokument do správnej kategórie.
3. Štruktúrovaná extrakcia
Jadro pipeline: z dokumentu sa extrahujú hodnoty podľa preddefinovanej schémy. Pre faktúru to typicky sú:
- Číslo faktúry, dátum vystavenia, dátum splatnosti
- IČO a DIČ dodávateľa a odberateľa
- Riadkové položky (popis, množstvo, jednotka, cena bez DPH, DPH, cena s DPH)
- Celková suma, číslo bankového účtu, variabilný symbol
VLM modely toto zvládajú priamo — na vstup dostanú obrázok alebo PDF a na výstup vrátia JSON podľa zadanej schémy. Výstup zodpovedá konceptu structured outputs a JSON mode — model produkuje len platný JSON s definovanými poľami.
Pre technické výkresy je situácia náročnejšia: kóty, tolerancie a materiálové špecifikácie sú roztrúsené v geometrickom kontexte schémy. VLM-72B modely v tom urobili výrazný pokrok, ale pre presné technické dokumenty sa odporúča človek v slučke pre finálnu verifikáciu kritických hodnôt.
4. Validácia a cross-check
Extrahované hodnoty sa podrobujú niekoľkým vrstvám validácie:
- Matematická konzistencia: súčet riadkových položiek musí zodpovedať celkovej sume; DPH musí korešpondovať s uvedenou sadzbou.
- Referenčná validácia: číslo objednávky na faktúre musí existovať v ERP; IČO dodávateľa musí byť v databáze schválených dodávateľov.
- Rozsahová validácia: suma faktúry v rozsahu, ktorý je pre daného dodávateľa typický (anomálie na manuálne preverenie).
Táto vrstva validácie je zásadná. V praxi sme videli prípady, kde model správne extrahoval čísla z dokumentu, ale suma faktúry nezodpovedala súčtu položiek — chyba bola v pôvodnom dokumente, nie v extrakciou. Bez validácie by ERP obsahovalo nekonzistentné dáta.
5. Integrácia do ERP a workflow
Validované záznamy sa odovzdajú do ERP cez API. Dokumenty s nízkou confidence (model si nie je istý hodnotou) alebo s failed validáciou idú do fronty na manuálne preverenie — s vyznačením konkrétneho poľa, kde je problém.
Toto je správny prístup: nie plná automatizácia, ale asistovaná automatizácia s jasným human-in-the-loop tam, kde je neistota.
Kde sa automatizácia oplatí a kde nie
Nie každý typ dokumentu je rovnako vhodný na automatizáciu. Na základe praktických nasadení vieme povedať:
Veľmi vhodné: - Faktúry od opakujúcich sa dodávateľov (systém sa "naučí" formát) - Štandardizované objednávkové formuláre (vlastné aj od obchodných partnerov) - Dodacie listy s barcódmi alebo QR kódmi (hybridný prístup OCR + barcode) - Certifikáty materiálov s definovanou štruktúrou
Vhodné s rezervou: - Faktúry od nových dodávateľov (prvé spracovanie vyžaduje vyššiu kontrolu) - Objednávky prijaté emailom v plain texte alebo HTML — tu môže LLM nad emailovým telom fungovať lepšie ako OCR nad obrázkom - Technické listy s tabuľkami parametrov
Menej vhodné bez špeciálneho riešenia: - Ručne písané dokumenty, starý fax s nízkou kvalitou - Technické výkresy s komplexnými geometrickými schémami a toleranciami — extrakcia funguje, ale vyžaduje verifikáciu - Zmluvy a právne dokumenty s komplikovanou štruktúrou (tu je hodnotnejší LLM nad priemyselnou dokumentáciou ako čistý OCR pipeline)
Technické rozhodnutia — cloud vs. on-prem
Väčšina firiem, s ktorými pracujeme, čelí otázke: cloudové API alebo vlastná inštalácia?
Cloud API (Azure AI Document Intelligence, Google Document AI, AWS Textract): - Rýchly štart, žiadna infraštruktúra - Pay-per-page model — pri veľkých objemoch (desaťtisíce dokumentov mesačne) môžu byť náklady významné - Faktúry a objednávky obsahujú obchodne citlivé dáta — pri regulovaných odvetviach alebo internej politike GDPR je cloud problematický
On-prem VLM (napr. Qwen2.5-VL-72B quantizovaný):
- Plná kontrola nad dátami — žiadny egress
- Vyššie VRAM nároky: 72B model vyžaduje multi-GPU setup (rádovo 40+ GB VRAM pre inferenciu)
- Jednorazová investícia do HW, potom marginal cost blízky nule pri škálovaní objemu
Pre väčšinu priemyselných firiem v EU je on-prem argument silný, ak máte dostatočný objem (rádovo tisíce dokumentov mesačne). Pre nižšie objemy alebo rýchly start môže byť cloud API rozumný odrazový mostík s plánom na migráciu.
Integrácia so štruktúrovanými výstupmi a ERP
Kritickým detailom v tomto pipeline je spoľahlivosť formátu výstupu z LLM. Model, ktorý raz vráti čisté JSON a inokedy vráti JSON obalený v markdown bloku, je pre automatizovanú integráciu nepoužiteľný.
Moderné modely podporujú constrained decoding — model generuje tokeny v súlade s definovanou JSON schémou, takže nie je fyzicky schopný vrátiť invalídny JSON. Toto je nutnosť, nie option, pre produkčné nasadenie. Viac o tom v článku Structured outputs a JSON mode.
Pre ERP integráciu platí pravidlo: nikdy nepíšte priamo do ERP z AI modelu. Štandardný vzor je:
- 1.AI extrahuje a validuje → výsledok do staging tabuľky
- 2.Validačné pravidlá (skript alebo workflow engine) skontrolujú konzistenciu
- 3.Pri úspechu → automatický import do ERP; pri neistote → fronta na ľudskú kontrolu
- 4.Ľudský reviewer vidí dokument, extrahované hodnoty a konkrétne pole s problémom
Tento vzor zachováva auditovateľnosť a zabraňuje tichému poškodeniu dát v ERP.
Výkresy a technická dokumentácia
Osobitnou kategóriou sú technické výkresy — DXF, PDF s geometriou, schémy zapojenia. Tradičný OCR je tu takmer nepoužiteľný, pretože väčšina informácie je vo vzťahoch medzi grafickými prvkami, nie v samotnom texte.
Moderné VLM modely dokážu z technického výkresu extrahovať: - Kóty a tolerancie (s presnosťou závislou od kvality vstupu) - Popis materiálov a povrchových úprav - Čísla dielcov a revízií
Kde stále potrebujete ľudskú kontrolu: kritické bezpečnostné tolerancie, schémy elektroinštalácie pre ATEX prostredí, dokumenty pre certifikačné procesy. AI tu pomáha ako asistent, nie ako autonómne rozhodnutie — podobne ako pri AI Copilot pre operátorov, kde model redukuje prácu, ale nenahrádza zodpovednosť.
Bežné omyly pri nasadení
Na záver technickej časti — problémy, ktoré vidíme opakovane:
"Nasadíme a zabudneme" — document intelligence pipeline potrebuje monitoring. Nový dodávateľ s nezvyčajnou šablónou faktúry zníži confidence score a poletí do manuálnej fronty; to je v poriadku, ale fronta sa musí sledovať.
Podceňovanie variability — v pilote testujete 50 faktúr od 5 dodávateľov. V produkcii máte 500 dodávateľov, z ktorých niektorí menia šablóny bez upozornenia. Testujte na diverzitnej vzorke, nie na "čistých" prípadoch.
Confidence skóre bez kalibrácie — model uvádza istotu extrakcie, ale tieto skóre sú kalibrované na tréningových dátach, nie na vašich dokumentoch. V prvých týždňoch produkcie sledujte, kde model prehlasuje "istý" a kde chyboval — podľa toho nastavte prahy pre manuálnu kontrolu.
Ignorovanie edge cases — čo sa stane, ak príde faktúra v nemčine? Alebo dokument s dvoma faktúrami v jednom PDF? Tieto prípady treba definovať a implementovať explicitne, nie dúfať, že si s nimi model poradí sám.
Časté otázky
Ako presné sú moderné systémy na extrakciu z faktúr?
Pre štruktúrované faktúry od opakujúcich sa dodávateľov dosahujú moderné VLM pipeline v praxi presnosť na úrovni 95–99 % pre kľúčové polia (číslo faktúry, suma, dátum). Pre nové alebo neštandardné formáty je presnosť nižšia — preto je kritická validačná vrstva a fronta na manuálnu kontrolu. Čísla z marketingových materiálov (99,9 %) sú zvyčajne z kontrolovaných testov, nie z reálnych produkčných nasadení s plnou variabilitou vstupov.
Treba na document intelligence GPU?
Pre cloudové API nie — platíte za API volania. Pre on-prem nasadenie s VLM modelmi (70B+) áno — potrebujete rádovo 40+ GB VRAM pre rozumné inference latencies. Menšie modely (7–14B) zvládnu aj RTX 4090 (24 GB VRAM pri quantizácii), ale s nižšou presnosťou na komplexných technických dokumentoch. Pre faktúry a objednávky stačí aj 7B model s dobrým výkonom.
Môžeme toto napojiť na náš existujúci SAP / Pohoda / iný ERP?
Áno — document intelligence pipeline produkuje štruktúrovaný JSON, ktorý možno importovať cez ERP API alebo cez štandardné integračné rozhrania (REST, IDOC pre SAP, CSV import pre jednoduchšie systémy). Integrácia sama o sebe nie je problém; väčšia práca je definovanie staging logiky a validačných pravidiel špecifických pre vaše obchodné procesy.
Čo s dokumentmi v rôznych jazykoch (nemčina, poľština)?
Moderné VLM modely sú multilingválne a zvládajú väčšinu európskych jazykov bez špeciálnej konfigurácie. Validačné pravidlá (napr. formát IČO, IBAN) je potrebné nastaviť per-krajina. Ak spracovávate veľké objemy z konkrétnej krajiny, oplatí sa overiť presnosť na reálnych vzorkách — performance nie je vždy rovnaká naprieč jazykmi.
Ako dlho trvá implementácia?
Jednoduchý pilot na jednom type dokumentu (napr. faktúry od top-20 dodávateľov) možno spustiť za 4–6 týždňov. Plné produkčné nasadenie s integráciou do ERP, monitoringom a pokrytím všetkých typov dokumentov sa pohybuje v rozsahu 3–6 mesiacov podľa komplexnosti prostredia a počtu integračných bodov.
*MP Industrial Solutions pomáha firmám prejsť od manuálneho prepísania dokumentov k overiteľnému automatizovanému toku — od pilotu na jednom type faktúry až po produkčné nasadenie s ERP integráciou. Ak riešite document intelligence alebo zvažujete, kde začať, radi posúdime váš konkrétny prípad.*