Součást série o stavbě cz-agents → pod kapotou
Past nestrukturovaných dat
Většina středně velkých firem sedí na 5–10 letech archivovaných PDF. Faktury od dodavatelů, smlouvy v různých layoutech, technické dokumentace, scanované formuláře z přechodu z papírového provozu, výstupy z legacy systémů, které nikdy nedostaly export do strukturovaného formátu. Jakmile dorazí požadavek "potřebujeme to mít searchable / nakrmit do datawarehouse / vytěžit pro reporting", začne tradiční dialog s IT.
Odhad přijde mezi šesti a dvanácti měsíci práce, plus dvě FTE na permanentní údržbu. Důvod: žádný dvojí dokument není stejný. OCR vrací mírně jiné věci u různých skenerů. Layout faktur od jednoho dodavatele se mění každý rok. Razítka přes text rozbijou regex. Ke každému edge case je nutné dopsat heuristiku, ke každé heuristice testy, k testům monitoring v produkci.
Tahle past je tak rozšířená, že se kolem ní vybudovala celá průmyslová odvětví — od enterprise OCR vendorů (ABBYY, Kofax) po RPA platformy slibující "intelligent automation". Slibovaná páka je velká, faktická realizace bývá brutální. Implementace dlouho a draho, ROI se nedostaví dřív než po dvou letech, a první výjimkový scénář vyžaduje konzultanty.
Co Vision AI v posledních 18 měsících mění je struktura tradeoffs. Ne nutně kvalita výstupu — ta byla stejně dobrá u zralého OCR vendoru. Mění se jednotková ekonomika a vstupní bariéra. To je důvod, proč o tom má smysl psát rozhodovací rámec, ne dev tutoriál.
Dvě cesty, jiné tradeoffs
Pro pochopení rozhodnutí pomáhá oddělit dvě filozofie přístupu k nestrukturovaným datům:
- Klasická ETL pipeline: OCR engine (Tesseract, ABBYY) převede obraz na text, parser (regex / heuristiky / specifické gramatiky) extrahuje strukturovaná pole, downstream validace ošetří edge cases. Většina logiky je deterministická, audit-friendly, infrastruktura je under your control.
- Vision AI API: Multimodální LLM dostane stránku jako obrázek a požadavek na strukturovaný output. Žádný explicit OCR krok, žádné heuristiky — model rozumí razítkům, dvousloupcovým layoutům, spojeným polím "ne v tabulce ale v souvětí" v jednom kroku. Trade je vendor lock-in, opacity rozhodnutí, per-call náklady.
Tabulka srovnání na osách, které reálně rozhodují:
| Osa | Klasický ETL | Vision AI API |
|---|---|---|
| Vstupní investice | Vysoká (měsíce dev práce, infra setup) | Velmi nízká (dny, jeden API key) |
| Per-call náklady | Téměř nulové (vlastní compute) | Lineární s objemem (haléře–desítky haléřů per dokument) |
| Údržba | Trvalá — každý nový layout vyžaduje code change | Téměř nulová — model si poradí s variacemi sám |
| Přesnost na čistých dokumentech | Vyšší (deterministická) | ~95 %, statisticky robustní |
| Přesnost na špinavých dokumentech | Velmi nízká bez dodatečné práce | ~80 %, ale často lepší než ETL |
| Auditovatelnost rozhodnutí | Vysoká (regex match na pozici X) | Nízká (model si přečetl a usoudil) |
| Vendor lock-in | Nízký (open source komponenty) | Vysoký (Anthropic, OpenAI, Gemini) |
| Čas k MVP | 3–12 měsíců | 2–7 dní |
Žádný z přístupů není univerzálně lepší. Volba závisí na tom, jaké osy v konkrétním projektu váží nejvíc — a to není technické rozhodnutí, je to byznysové.
Case study: dražební vyhlášky z ISIR
Pro konkrétní aplikaci rámce zvolím doménu, ze které mám čerstvá data: český insolvenční rejstřík (ISIR). V rámci real-estate produktu jsem potřeboval každý den vytěžit z nově publikovaných dražebních vyhlášek pět polí (katastrální území, parcelní číslo, výměra, vyvolávací cena, termín dražby) na zhruba 200 nových PDF denně.
ISIR neuniformuje vstup. Každý insolvenční správce sazí vyhlášky jinak — někdo ve Wordu, někdo v TeXu, někdo skenuje předtištěný formulář s ručně dopsanými údaji. Layout, fonty, terminologie, pořadí sekcí — všechno se mění od kanceláře ke kanceláři. Příklady situací, na které se klasický parser zlomí:
- Razítko o nabytí právní moci přes text — text extraction vrátí prázdný řádek tam, kde má být katastrální území.
- Vyhláška je sken, ne digitální PDF —
pdf-parsevrátí prázdný buffer, OCR by musel běžet zvlášť. - Parcelní čísla v dvousloupcové tabulce — text extractor je smíchá do jednoho řádku v náhodném pořadí.
- Výměra je psaná každou kanceláří jinou frází — "o výměře 348 m²", "výměra: 348", "plocha 348 m²".
- Občas ručně dopsaná oprava ceny v dolním rohu, kterou OCR nepřečte.
Pro pět vyhlášek ladíte pět regexů. Pro 200 denně už ne. To je přesně typ úkolu, kde se "klasický ETL" stává údržbovým peklem dřív, než se MVP dostane do produkce.
Aplikace rámce: kdy se Vision AI vyplatí
Aplikujme tabulku z předchozí sekce na ISIR případ. Volba dopadne rozhodně ve prospěch Vision AI, ale stojí za to porozumět proč, protože stejné rozhodnutí by vypadalo jinak u jiného dataset.
Vstupní investice a čas k MVP
U klasického ETL by minimální životaschopná verze znamenala: postavit OCR pipeline (Tesseract + post-processing), napsat parser pro alespoň top 5 nejčastějších layoutů, otestovat na historických datech, pohnout do produkce. Realistický odhad 2–3 měsíce práce solo developerem. U Vision AI první funkční prototyp byl hotový do hodiny — vyrenderovat stránku na obrázek, poslat do API, validovat schema. Pro projekt s nejistým produktovým validation je tahle akcelerace zásadní.
Per-call náklady vs. přesnost
Tříostránková vyhláška v 200 DPI: zhruba 4 500 input tokenů a 800–1 200 output tokenů na Claude Haiku 4.5. V batch rate to vychází na desítky haléřů per dokument. Při 200 vyhláškách denně to dělá pod 50 Kč měsíčně. Pro srovnání: GPU instance pro vlastní OCR pipeline (i ta nejmenší) by stála násobky tisíců měsíčně, plus čas na maintenance při každé změně šablony.
To by ale samo o sobě rozhodnutí nezachránilo, pokud by přesnost byla špatná. Reálná čísla z produkce: ~95 % na čistých digitálních PDF, ~80 % na špinavých skenech. Pro produkt, kde každý lead stejně reviewuje člověk před rozhodnutím o nákupu, je 80 % použitelné. Pro automatický fakturový pipeline by 80 % bylo katastrofa.
Auditovatelnost a vendor lock-in
Tady Vision AI prohrává. ISIR data nepoužívám pro compliance reporting, kde by audit byl nutný. Pokud bych je používal, musel bych model output považovat za "vstup, který stejně musí být zvalidován jiným nezávislým způsobem", ne za autoritativní. Vendor lock-in na Anthropic API je akceptovatelný, protože model output je přenositelný — Vision API od OpenAI nebo Gemini lze nasadit za cenu pár hodin přepisu.
Škálovatelnost
Při 200 dokumentech denně je linearní cena per call neproblematická. Při 100 000 denně by Vision AI prodražilo proti vlastnímu pipeline. Hranice se posouvá rychle dolů s každou další generací modelů — Haiku 4.5 je o řád levnější než Opus 3 za stejný úkol — ale stále existuje a v rozhodnutí na ni musí být místo.
Tři principy pro nasazení Vision AI do produkce
Pokud volba padla na Vision AI, tři principy rozhodují, jestli z toho bude produkční systém nebo demo, které se rozbije při prvním reálném zákazníkovi.
1. Modelujte nejistotu v UI a procesech, ne v promptu
Model si neumí spolehlivě říct "tohle pole jsem si nebyl jistý". Ale produkt, do kterého ho zasazujete, ano. Per-field confidence (ať už explicit z modelu nebo z meta-validace proti jiným zdrojům), pending_human_review fronta, varovná indikace v UI, link na původní dokument. Uživatel produktu nemá problém s tím, že AI občas chybí — má problém s tím, když chyba není vidět. Trust nestavíte na zakrývání limitů, stavíte ho na tom, že limity jsou explicitní.
2. Skutečná cena nasazení není cena API
API náklady jsou typicky v jednotkách až nízkých desítkách procent z TCO. Většinu nákladů tvoří: lidský review nejistých výstupů, custom logika kolem retry/eskalace, monitoring drifty modelu (chování může změnit mezi verzemi modelu), schema validation, integrace do business procesů, training koncových uživatelů. Pokud business case stojí jen na "ušetříme za OCR licenci", obvykle nestačí. Pokud stojí na "zkrátíme čas zpracování z 5 dní na 1 hodinu při srovnatelné kvalitě", bývá robustní.
3. Defaultně nejlevnější model, eskalace jen tam, kde se vrátí
Haiku 4.5 zvládá 95 % rutinních dokumentů. Sonnet a Opus mají smysl jen tam, kde je míra chyb na Haiku ekonomicky neúnosná — typicky u dokumentů s vysokou hodnotou per kus (smlouvy, due diligence reporty). Strategy má vypadat: defaultní model je levný, na základě confidence threshold nebo doménového flagu eskalujte na silnější. Bez téhle vrstvy nakonec všichni "pro jistotu" pustí Opus na všechno a Vision AI ekonomika přestane sedět.
Závěr: rozhodnutí, ne technologie
Rozhodnutí Vision AI vs. klasický ETL není technické. Je to rozhodnutí o struktuře tradeoffů, které sedí konkrétnímu projektu — typicky: jak rychle musíme do produkce, kolik dat a jaké kvality, kolik je tolerance k chybě, jaký je vendor lock-in akceptovatelný, jaké jsou audit požadavky. Ze stejného technologického menu se dá pro různé projekty udělat opačné rozhodnutí, a obě budou správná.
Co skoro nikdy nesedí: defaultně sahat po Vision AI, protože "je to nové a moderní", nebo defaultně po klasickém ETL, protože "AI není auditovatelné". Obojí jsou heuristiky, které nahrazují přemýšlení. Skutečné rozhodnutí vyžaduje rozepsat osy nahoře, ohodnotit je váhou pro daný projekt, a na základě toho vybrat. To trvá hodinu, ale ušetří měsíce.