Dostanete technickú dokumentáciu k výrobnej linke: 1 200 strán PDF. Z toho zhruba tretina sú tabuľky s parametrami, ďalšia tretina hydraulické a elektrické schémy, zvyšok súvislý text. Nastavíte RAG pipeline, zaindexujete dokumenty, otestujete prvých dvadsať otázok — a tri štvrtiny z nich dostane nesprávne alebo neúplné odpovede. Technik sa pýta na prúdovú záťaž konkrétneho pohonu v tabuľke na strane 847. Model odpovedá presvedčivo a nesprávne, pretože tabuľku nikdy nevidel — naivný pipeline ju sparsoval ako rozsypaný text a pri chunkovacom kroku zahodil väzbu medzi hodnotami a stĺpcami.
Toto nie je teoretický problém. V priemyselnom prostredí — výroba, energetika, strojárstvo — je až 40–60 % informačnej hodnoty dokumentov viazaných na netext: tabuľky, výkresy, P&ID diagramy, schémy zapojenia, výrobné tolerancie v grafoch. Text-only RAG tieto informácie systematicky stráca. Multimodálny RAG tieto problémy rieši — ale nie zadarmo a nie rovnako pre každý typ obsahu. Tento článok rozhoduje, kedy do neho ísť, aké nástroje použiť a kde sú reálne výzvy.
Kde text-only RAG zlyhá a prečo
Skôr ako prejdeme na riešenia, je dôležité presne pochopiť, prečo naivný pipeline zlyhá na netext-ovom obsahu. Existujú tri mechanizmy zlyhania:
Tabuľky: Klasický chunking podľa počtu tokenov rozseká tabuľku na fragmenty. Záhlavie stĺpcov zostane v jednom chunku, hodnoty v ďalšom. Merged cells sa stratia. Výsledok: retrieval nájde fragment s číslom, ale bez kontextu, čo to číslo znamená. Model buď halucinuje, alebo správne povie „neviem" — oba výsledky sú pre technickú dokumentáciu neprijateľné.
Obrázky a schémy: PDF parser extrahuje text a obrázky oddelene. Ak obrázok nie je popísaný textom v okolí, pipeline ho ignoruje. Väčšina priemyselných výkresov má veľmi strohý textový kontext — čísla komponentov, legendu — a obsahovú informáciu nesie vizuálne rozloženie. To text-only model nevidí.
Naskenované dokumenty: Starší výrobný dokument je skenovaný obrázok. OCR ho skonvertuje na text, ale stratí 2D layout. Tabuľka v súvislom texte vyzerá ako nezmyselná séria čísel. Výkresy zostanú ako obrázky bez textu, ktoré pipeline ignoruje.
Tri architektúry multimodálneho RAG
Neexistuje jedno riešenie. V praxi sa ustálili tri prístupy, každý s iným trade-off medzi kvalitou, nákladmi a komplexitou.
1. Caption-and-index (popis a indexácia)
Najjednoduchšia cesta k multimodálnemu RAG. Pri ingestion pipeline použijete vision-language model (VLM) — model, ktorý rozumie obrazovému vstupu — na automatické vygenerovanie textového popisu každého obrázka a tabuľky. Tento popis sa uloží spolu s textovým obsahom stránky a indexuje štandardným vektorovým retrieval-om.
Implementácia: Unstructured alebo Docling extrahuje obrázky a tabuľky z PDF. Pre každý obrázok zavoláte VLM (napr. GPT-4o, Gemini 2.5 Pro, alebo lokálne Qwen2.5-VL) s promptom „popíš presne, čo vidíš na tomto technickom výkrese, vrátane všetkých čísel, kódov a popisiek". Výsledný text sa indexuje.
Výhody: retrieval funguje so štandardným embeddingom, pipeline je jednoduchá, storage nároky sú mierné — rádovo desiatky GB na milióny stránok. Nevýhoda: kvalita závisí od toho, ako dobre VLM popíše obrázok. Komplexné P&ID diagramy s desiatkami komponentov a symbologiou podľa ISA-5.1 môžu byť popísané nepresne. Pre kľúčové dokumenty odporúčame human-in-the-loop review pri generovaní popisov.
2. Page-as-image s multi-vector retrieval (ColPali štýl)
Namiesto extrahovania textu z PDF sa celá stránka vyrenderuje ako obrázok a embeduje priamo cez vision-language embedding model — typicky modely z ColPali rodiny, aktuálne ColQwen2.5, ktorý drží popredné pozície na ViDoRe V2 leaderboard-e pre vizuálny document retrieval.
ColPali architektúra generuje pre každú stránku desiatky patch vektorov (nie jeden vektor), čo umožňuje jemnejšie zachytenie detailov. Pri retrieval-i sa používa late interaction — dotaz sa porovnáva s každým patch vektorom zvlášť a skóre sa agreguje (podobne ako ColBERT pre text). Výsledok: výrazne vyššia presnosť na stránkach so zmiešaným obsahom text-tabuľka-obrázok.
Nevýhoda je jednoznačná: storage. Tam kde caption-and-index potrebuje 1 vektor na stránku, ColPali potrebuje 100–1 000 vektorov. Na veľkých korpusoch (desiatky miliónov stránok) to znamená jednotky terabajtov vektorového úložiska. Qdrant má natívnu podporu pre multi-vector retrieval a ColBERT-style late interaction, čo zjednodušuje implementáciu. Pre väčšinu priemyselných korporusov (10 000–500 000 strán) je tento overhead akceptovateľný — veľmi veľké nasadenia si musia storage náklady kalkulovať explicitne.
3. Unified multimodal embeddings
Tretí prístup: embedding model, ktorý natívne spracúva text aj obrázky v jednom priestore. Príklady: Cohere Embed v4 (128 000-tokenové kontextové okno, text + obrázky, enterprise API), voyage-multimodal-3.5 (Voyage AI, podporuje video snímky). Celá stránka sa embeduje priamo bez generovania textu, výsledok je jeden vektor na stránku.
Výhody: jednoduchosť, mierne nároky na úložisko (porovnateľné s single-vector text embeddingmi), žiadna závislosť od kvality VLM-generovaných popisov. Nevýhoda: tieto modely sú momentálne dostupné len ako cloud API — pre on-prem alebo air-gapped prostredia nie sú vhodné. Retrieval presnosť je nižšia ako ColPali na najnáročnejších vizuálnych dokumentoch, ale pre väčšinu enterprise korporusov dostačujúca a výrazne lepšia ako text-only.
Parsing: Docling a Unstructured
Kým embedding architektúra rozhoduje o kvalite retrieval-u, parsing rozhoduje o tom, čo vôbec do indexu vstúpi. Dve open-source knižnice pokrývajú väčšinu potrieb:
`Docling` (IBM, Apache 2.0) konvertuje PDF na štruktúrovaný JSON. Rozpoznáva tabuľky, zachováva hierarchiu dokumentu (kapitola → podkapitola → obsah), extrahuje obrázky s odkazmi na polohu na stránke. Je rýchly aj na CPU a nevyžaduje GPU na bežné textové dokumenty. Pre väčšinu priemyselných PDF s tlačenými tabuľkami je to východiskový nástroj.
`Unstructured` má širší záber: rozumie viac formátom (DOCX, PPTX, HTML, e-maily, tabuľky v Exceli), má inferenčný mód pre klasifikáciu elementov pomocou modelu. Pre naskenované dokumenty použite hi_res mód, ktorý zapne OCR a rozloženie stránky analyzuje cez vision model. Nevýhoda: hi_res je pomalý bez GPU a generuje závislosť od Docker image s modelmi.
Pre priemyselné výkresy (P&ID, elektrické schémy) ani jeden nástroj neposkytuje sémantické pochopenie — extrahujú pixely alebo text, nie logiku zapojenia. Ak potrebujete Q&A nad logickým obsahom výkresu (nie len nad popískami), potrebujete špecializovaný VLM prompt s doménovými znalosťami alebo manuálne anotácie. Tejto téme sa podrobnejšie venujeme v článku LLM nad priemyselnou dokumentáciou.
Tabuľky: najčastejší problém v praxi
Tabuľky sú špeciálny prípad, ktorý si zaslúži vlastnú sekciu. V praxi vidíme tri typy tabuliek v priemyselných dokumentoch, každý s iným prístupom:
Parametrické tabuľky (typy zariadení × hodnoty) — dobre spracovateľné cez Docling alebo LlamaIndex table parser. Konvertujte do Markdown alebo JSON reprezentácie pred indexáciou. Zachovajte záhlavie ako súčasť každého riadku pri chunkovacom kroku — parent-child chunking kde parent = celá tabuľka a child = riadok s záhlavím je osvedčený vzor.
Naskenované tabuľky — vyžadujú VLM. Pošlite obrázok tabuľky modelu s explicitným promptom: „Extrahuj obsah tejto tabuľky do JSON formátu, zachovaj záhlavie stĺpcov, všetky hodnoty vrátane jednotiek a poznámok." Skontrolujte výsledok — VLM môže chybiť pri handwritten hodnotách alebo neštandardných symboloch.
Tabuľky s cross-references (napr. kód dielu odkazuje na výkres) — tu text-only prístup nestačí ani s dobrým parserom. Potrebujete explicitné prepojenie entít: id tabuľkového záznamu ↔ id výkresu, uložené v metadátach. Agentic RAG approach, kde agent vie vykonať druhý retrieval na základe nájdenej referencie, tu výrazne zlepšuje odpovede. O agentic RAG viac v článku Agentic RAG.
Kedy multimodálny RAG naozaj potrebujete
Multimodálny RAG pridáva komplexitu a náklady. Pred nasadením si úprimne odpovedzte na tieto otázky:
- Aké percento informácií, na ktoré sa vaši používatelia pýtajú, je viazaných na tabuľky alebo obrázky? Ak menej ako 20 %, riešte to cielene (manuálne popisy kľúčových výkresov) a nestavajte celý multimodálny pipeline.
- Sú vaše dokumenty primárne tlačené (digitálne PDF) alebo naskenované? Naskenované vyžadujú GPU pri ingestion, čo zvyšuje náklady na indexáciu.
- Potrebujete on-prem alebo cloud API je akceptovateľné? Najsilnejšie unified multimodal embeddings sú momentálne dostupné len cez API.
- Aká je frekvencia aktualizácie dokumentov? Caption-and-index pipeline je lacnejší pri prvom behu, ale pri každej aktualizácii korpusu musíte regenerovať popisy obrázkov — VLM volania nie sú zadarmo.
Pre väčšinu priemyselných nasadení s bežnými technickými manuálmi (tlačené, štruktúrované tabuľky, výkresy s popiskami) je caption-and-index s `Docling`/`Unstructured` parserom a silným VLM dostatočný a výrazne lacnejší ako ColPali.
ColPali alebo unified multimodal embeddings sa oplatia, keď máte vizuálne bohaté dokumenty kde textový popis nestačí zachytiť informáciu — napríklad komplexné hydraulické schémy s viacúrovňovým rozvetvením, alebo dokumenty kde layout stránky sám o sebe nesie informáciu.
Výzvy, ktoré nespomína žiadny tutorial
Z desiatok nasadení vyplývajú problémy, na ktoré narazia takmer všetci:
Ingestion cost: Ak máte 500 000 stránok a každá obsahuje priemerné 2 obrázky, generovanie popisov cez cloud VLM API môže stáť rádovo tisíce eur za jednorazovú indexáciu. Kalkulujte to vopred. Lokálne VLM (napr. Qwen2.5-VL 7B alebo 72B) znižujú tento náklad na cenu GPU hodín, ale vyžadujú dostatočnú VRAM — 72B model v 4-bitovej kvantizácii potrebuje rádovo 40+ GB VRAM.
Verzia dokumentov: Technická dokumentácia má revízie. Rev3 výkresu môže mať iné hodnoty ako Rev1. Multimodálny pipeline musí zachovávať verziu ako metadata a retrieval musí vedieť filtrovať podľa nej. Záleží na tom, či chcete aktuálne alebo konkrétnu revíziu.
Evalvačná slepá ulička: RAGAS metriky (Faithfulness, Context Recall, Answer Relevancy) fungujú dobre pre text. Pre multimodálny retrieval neexistuje štandardizovaný benchmark na vašich vlastných dokumentoch. Musíte manuálne vytvoriť gold dataset — 100–200 otázok s overenými odpoveďami — a merať na ňom. Bez tohto nevyhodnotíte, či zmena architektúry pomohla alebo uškodila.
Halucinácie sú tu stále: RAG výrazne znižuje halucinácie oproti pure LLM, ale neeliminuje ich. Ak VLM nepresne popísal tabuľku pri ingestion, model odpovie presvedčivo na základe nesprávneho popisu. Dôležité: faithfulness metrika meria konzistenciu odpovede s poskytnutým kontextom — nie faktickú správnosť kontextu samotného. Ak je popis obrázka zlý, faithfulness bude vysoká a odpoveď stále nesprávna. Viac o citáciách a groundingu v článku citácie a grounding v RAG.
Odporúčaná architektúra pre priemyselné PDF
Ak by sme mali zhrnúť skúsenosť z nasadení v strojárstve a energetike do konkrétneho odporúčania:
- 1.Parsing:
Doclingpre tlačené PDF,Unstructuredhi_respre naskenované. Extrahujte tabuľky ako samostatné entity, obrázky ako referencovateľné bloky. - 2.Tabuľky: konvertovať do Markdown alebo JSON, indexovať s parent-child chunking. Záhlavie musí byť súčasťou každého child chunku.
- 3.Obrázky a výkresy: pre bežné dokumenty caption-and-index s VLM promptom orientovaným na doménu (priemysel, elektrotechnika, hydraulika). Pre vizuálne intenzívne dokumenty zvažte unified multimodal embeddings (Cohere Embed v4 alebo Voyage) alebo ColQwen2.5 ak je storage akceptovateľný.
- 4.Embedding + retrieval:
BGE-M3ostáva spoľahlivou open-weight voľbou pre SK/CZ/PL priemyselné texty — kombinuje dense, sparse a multi-vector v jednom modeli. Hybrid search (BM25 + dense) je pri technickej dokumentácii takmer povinný kvôli presnej zhode kódov a označení zariadení. - 5.Reranking:
BGE-reranker-v2-m3(self-hosted) alebo Cohere Rerank API. Pridáva latenciu, ale pri komplexnej dokumentácii kde sa rovnaký termín objaví na stovkách miest je rozhodujúci. - 6.Storage:
Qdrantpre multi-vector prípady,pgvectorak máte existujúcu PostgreSQL infraštruktúru a objem pod 50 miliónov vektorov. - 7.Evaluácia: gold dataset 100–200 otázok z reálnych používateľských dotazov, RAGAS pre text metriky, manuálna anotácia pre multimodálne odpovede.
Časté otázky
Je ColPali vždy lepší ako caption-and-index?
Nie. ColPali dosahuje vyšší recall na vizuálne náročných dokumentoch, ale za cenu 100–1 000× väčšieho počtu vektorov na stránku. Pre väčšinu priemyselných korporusov s tlačenými tabuľkami a popisnými výkresmi je caption-and-index s dobrým VLM promptom dostačujúci za zlomok storage nákladov. ColPali sa oplatí tam, kde layout stránky sám o sebe nesie informáciu, ktorú textový popis nedokáže zachytiť.
Môžem použiť lokálne VLM modely, alebo musím platiť za cloud API?
Lokálne VLM sú plne funkčnou alternatívou. Qwen2.5-VL v 7B variante beží na consumer GPU s 16–24 GB VRAM, 72B variant v 4-bitovej kvantizácii potrebuje rádovo 40+ GB VRAM. Pre caption-and-index pipeline kde VLM beží pri ingestion (nie pri každom dotaze) je lokálny model ekonomicky výhodný pri väčšom korpuse. Nevýhoda: pomalší throughput pri indexácii. Cloud API (GPT-4o, Gemini) ponúka vyššiu kvalitu popisov, ale pri 500 000+ stranách môže byť cena výrazná.
Ako riešiť dokumenty vo viacerých jazykoch — slovenčina, angličtina, nemčina?
Pre embedding odporúčame BGE-M3 alebo Qwen3-Embedding-8B — oba modely pokrývajú slovenčinu, češtinu, poľštinu, nemčinu a angličtinu v rámci multilingual tréningu. Pre VLM captioning priemyselných dokumentov je angličtina stále odporúčaný jazyk popisov (modely sú v ňom výrazne silnejšie), ale retrieval funguje aj v slovenčine vďaka multilingual embeddingom.
Kedy má zmysel použiť vektorovú DB namiesto pgvector?
pgvector je legitímna produkčná voľba do 50 miliónov vektorov pri existujúcej PostgreSQL infraštruktúre. Pre multi-vector retrieval (ColPali štýl) s desiatkami vektorov na stránku a miliónom stránok je Qdrant s natívnou ColBERT podporou výrazne efektívnejší. Porovnanie databáz nájdete v článku vektorové databázy — porovnanie.
Aký je typický čas a cena indexácie priemyselného korpusu?
Závisí od prístupu. Caption-and-index na 100 000 stránok s mixom textu, tabuliek a obrázkov: pri cloud VLM API rádovo stovky eur, pri lokálnom 7B VLM rádovo GPU hodiny na jednom A100 ekvivalente. ColPali architektúra indexáciu zrýchľuje (nie je potrebné generovať popisy), ale retrieval infraštruktúra (multi-vector storage) je nákladnejšia. Text-only parsing s Docling bez VLM je rýdzo CPU záťaž a zvládne statisíce stránok za hodiny na bežnom serveri.
*Multimodálny RAG nie je „fancy feature" — je to predpoklad spoľahlivého systému pre akýkoľvek korpus, kde tabuľky a výkresy nesú kľúčové informácie. V priemysle to platí pre väčšinu technickej dokumentácie. Ak sa s podobným problémom stretávate — máte dokumenty, kde text-only pipeline dáva neuspokojivé odpovede — radi sa pozrieme na váš konkrétny prípad a navrhneme architektúru ušitú na váš korpus a infraštruktúrne požiadavky.*