Multimodale RAG: documenten met tabellen, afbeeldingen en schema's

U ontvangt de technische documentatie bij een productielijn: 1.200 pagina's PDF. Ongeveer een derde bestaat uit parametertabellen, nog eens een derde uit hydraulische en elektrische schema's, de rest is doorlopende tekst. U configureert een RAG-pipeline, indexeert de documenten, test de eerste twintig vragen — en driekwart krijgt een verkeerd of onvolledig antwoord. Een technicus vraagt naar de stroombelasting van een specifieke aandrijving in de tabel op pagina 847. Het model antwoordt overtuigend en onjuist, omdat het de tabel nooit heeft gezien — de naïeve pipeline parseerde die als versnipperde tekst en gooide tijdens het chunking-stap de relatie tussen waarden en kolomkoppen weg.

Dit is geen theoretisch probleem. In industriële omgevingen — productie, energie, machinebouw — is 40–60 % van de informatiewaarde van documenten gebonden aan niet-tekst: tabellen, tekeningen, P&ID-diagrammen, bekabelingsschema's, fabricagetoleransen in grafieken. Text-only RAG verliest deze informatie structureel. Multimodale RAG lost deze problemen op — maar niet gratis en niet op dezelfde manier voor elk type inhoud. Dit artikel bepaalt wanneer u er gebruik van maakt, welke tools u inzet en waar de echte uitdagingen liggen.

Waar text-only RAG faalt en waarom

Voordat we naar oplossingen gaan, is het belangrijk precies te begrijpen waarom een naïeve pipeline faalt op niet-tekstuele inhoud. Er zijn drie faalmechanismen:

Tabellen: Klassieke chunking op basis van tokenaantallen snijdt een tabel in fragmenten. De kolomkoppen blijven in één chunk, de waarden in een volgende. Samengevoegde cellen gaan verloren. Het resultaat: retrieval vindt een fragment met een getal, maar zonder de context van wat dat getal betekent. Het model hallucineert ofwel, of zegt terecht "ik weet het niet" — beide uitkomsten zijn onaanvaardbaar voor technische documentatie.

Afbeeldingen en schema's: Een PDF-parser extraheert tekst en afbeeldingen afzonderlijk. Als een afbeelding niet door omringende tekst wordt beschreven, negeert de pipeline die. De meeste industriële tekeningen hebben zeer summiere tekstuele context — componentnummers, een legenda — en de inhoudelijke informatie zit in de visuele opmaak. Dat ziet een text-only model niet.

Gescande documenten: Een ouder productiedocument is een gescande afbeelding. OCR converteert die naar tekst, maar verliest de 2D-layout. Een tabel in doorlopende tekst ziet eruit als een betekenisloze reeks getallen. Tekeningen blijven als afbeeldingen zonder tekst, die de pipeline negeert.

Drie architecturen voor multimodale RAG

Er bestaat niet één oplossing. In de praktijk hebben zich drie benaderingen uitgekristalliseerd, elk met een andere trade-off tussen kwaliteit, kosten en complexiteit.

1. Caption-and-index (beschrijving en indexering)

De eenvoudigste route naar multimodale RAG. Tijdens de ingestion-pipeline gebruikt u een vision-language model (VLM) — een model dat visuele invoer begrijpt — om automatisch een tekstbeschrijving te genereren van elke afbeelding en tabel. Die beschrijving wordt samen met de tekstinhoud van de pagina opgeslagen en geïndexeerd via standaard vector retrieval.

Implementatie: Unstructured of Docling extraheert afbeeldingen en tabellen uit de PDF. Voor elke afbeelding roept u een VLM aan (bijv. GPT-4o, Gemini 2.5 Pro, of lokaal Qwen2.5-VL) met de prompt "beschrijf exact wat u ziet op deze technische tekening, inclusief alle cijfers, codes en aanduidingen". De resulterende tekst wordt geïndexeerd.

Voordelen: retrieval werkt met standaard embedding, de pipeline is eenvoudig, de opslagvereisten zijn bescheiden — in de orde van tientallen GB voor miljoenen pagina's. Nadeel: de kwaliteit hangt ervan af hoe goed het VLM de afbeelding beschrijft. Complexe P&ID-diagrammen met tientallen componenten en symbologie volgens ISA-5.1 kunnen onnauwkeurig worden beschreven. Voor kritieke documenten raden wij human-in-the-loop review aan bij het genereren van beschrijvingen.

2. Page-as-image met multi-vector retrieval (ColPali-stijl)

In plaats van tekst uit een PDF te extraheren, wordt de volledige pagina als afbeelding gerenderd en direct geëmbedded via een vision-language embedding model — doorgaans modellen uit de ColPali-familie, momenteel ColQwen2.5, dat topprestaties levert op de ViDoRe V2-leaderboard voor visuele document retrieval.

De ColPali-architectuur genereert voor elke pagina tientallen patch-vectoren (niet één vector), wat een fijnmaziger vastlegging van details mogelijk maakt. Bij retrieval wordt late interaction gebruikt — de query wordt per patch-vector vergeleken en de scores worden geaggregeerd (vergelijkbaar met ColBERT voor tekst). Het resultaat: aanzienlijk hogere precisie op pagina's met gemengde inhoud tekst-tabel-afbeelding.

Het nadeel is eenduidig: opslag. Waar caption-and-index 1 vector per pagina nodig heeft, heeft ColPali er 100–1.000 nodig. Op grote corpora (tientallen miljoenen pagina's) betekent dat units terabytes aan vectoropslag. Qdrant heeft native ondersteuning voor multi-vector retrieval en ColBERT-stijl late interaction, wat de implementatie vereenvoudigt. Voor de meeste industriële corpora (10.000–500.000 pagina's) is deze overhead acceptabel — zeer grote deployments moeten de opslagkosten expliciet berekenen.

3. Unified multimodal embeddings

De derde benadering: een embedding-model dat tekst én afbeeldingen natief verwerkt in één ruimte. Voorbeelden: Cohere Embed v4 (128.000-token contextvenster, tekst + afbeeldingen, enterprise API), voyage-multimodal-3.5 (Voyage AI, ondersteunt videoframes). De volledige pagina wordt direct geëmbedded zonder tekstgeneratie, het resultaat is één vector per pagina.

Voordelen: eenvoud, beperkte opslagvereisten (vergelijkbaar met single-vector text embeddings), geen afhankelijkheid van de kwaliteit van VLM-gegenereerde beschrijvingen. Nadeel: deze modellen zijn momenteel alleen beschikbaar als cloud-API — voor on-premises of air-gapped omgevingen zijn ze niet geschikt. Retrieval-precisie is lager dan ColPali op de meest veeleisende visuele documenten, maar voor de meeste enterprise-corpora toereikend en aanzienlijk beter dan text-only.

Parsing: Docling en Unstructured

Terwijl de embedding-architectuur de kwaliteit van de retrieval bepaalt, bepaalt de parsing wat er überhaupt in de index terechtkomt. Twee open-source bibliotheken dekken de meeste behoeften:

`Docling` (IBM, Apache 2.0) converteert PDF naar gestructureerde JSON. Het herkent tabellen, behoudt de documenthiërarchie (hoofdstuk → subhoofdstuk → inhoud), en extraheert afbeeldingen met verwijzingen naar hun positie op de pagina. Het is snel, ook op CPU, en vereist geen GPU voor gewone tekstdocumenten. Voor de meeste industriële PDF's met gedrukte tabellen is dit het standaardgereedschap.

`Unstructured` heeft een bredere reikwijdte: het begrijpt meer formaten (DOCX, PPTX, HTML, e-mails, Excel-tabellen) en heeft een inferentiemodus voor elementclassificatie via een model. Voor gescande documenten gebruikt u de hi_res-modus, die OCR inschakelt en de pagina-indeling analyseert via een vision model. Nadeel: hi_res is traag zonder GPU en genereert een afhankelijkheid van een Docker-image met modellen.

Voor industriële tekeningen (P&ID, elektrische schema's) biedt geen van beide tools semantisch begrip — ze extraheren pixels of tekst, niet de verbindingslogica. Als u Q&A nodig heeft over de logische inhoud van een tekening (niet alleen over de aanduidingen), hebt u een gespecialiseerde VLM-prompt met domeinkennis of handmatige annotaties nodig. We gaan dieper op dit onderwerp in het artikel LLM over industriële documentatie.

Tabellen: het meest voorkomende probleem in de praktijk

Tabellen zijn een speciaal geval dat een eigen sectie verdient. In de praktijk zien we drie typen tabellen in industriële documenten, elk met een andere aanpak:

Parametrische tabellen (apparaattypen × waarden) — goed te verwerken via Docling of LlamaIndex table parser. Converteer naar Markdown- of JSON-representatie vóór indexering. Bewaar de koptekst als onderdeel van elke rij tijdens het chunking-stap — parent-child chunking waarbij parent = de volledige tabel en child = rij met koptekst is een bewezen patroon.

Gescande tabellen — vereisen een VLM. Stuur de tabelafbeelding naar het model met een expliciete prompt: "Extraheer de inhoud van deze tabel naar JSON-formaat, bewaar de kolomkoppen, alle waarden inclusief eenheden en noten." Controleer het resultaat — het VLM kan fouten maken bij handgeschreven waarden of niet-standaard symbolen.

Tabellen met kruisverwijzingen (bijv. onderdeelcode verwijst naar tekening) — hier volstaat een text-only aanpak niet, zelfs niet met een goede parser. U hebt expliciete entiteitskoppeling nodig: id van het tabelrecord ↔ id van de tekening, opgeslagen in metadata. Een agentic RAG-aanpak, waarbij een agent een tweede retrieval kan uitvoeren op basis van de gevonden referentie, verbetert de antwoorden hier aanzienlijk. Meer over agentic RAG in het artikel Agentic RAG.

Wanneer u multimodale RAG echt nodig hebt

Multimodale RAG voegt complexiteit en kosten toe. Beantwoord eerlijk de volgende vragen vóór implementatie:

• Welk percentage van de informatie waarover uw gebruikers vragen, is gebonden aan tabellen of afbeeldingen? Als dat minder dan 20 % is, pak het dan gericht aan (handmatige beschrijvingen van kritieke tekeningen) en bouw geen volledige multimodale pipeline.
• Zijn uw documenten primair gedrukt (digitale PDF) of gescand? Gescande documenten vereisen GPU bij ingestion, wat de indexeringskosten verhoogt.
• Hebt u on-premises nodig, of is een cloud-API acceptabel? De sterkste unified multimodal embeddings zijn momenteel alleen beschikbaar via API.
• Hoe vaak worden documenten bijgewerkt? Een caption-and-index pipeline is goedkoper bij de eerste run, maar bij elke corpus-update moet u afbeeldingsbeschrijvingen opnieuw genereren — VLM-aanroepen zijn niet gratis.

Voor de meeste industriële implementaties met gangbare technische handleidingen (gedrukt, gestructureerde tabellen, tekeningen met aanduidingen) is caption-and-index met `Docling`/`Unstructured` parser en een sterk VLM toereikend en aanzienlijk goedkoper dan ColPali.

ColPali of unified multimodal embeddings zijn de moeite waard wanneer u visueel rijke documenten heeft waarbij een tekstbeschrijving de informatie onvoldoende vastlegt — bijvoorbeeld complexe hydraulische schema's met meerlaagse vertakkingen, of documenten waarbij de pagina-indeling zelf informatie draagt.

Uitdagingen die geen enkele tutorial noemt

Uit tientallen implementaties komen problemen naar voren waar bijna iedereen tegenaan loopt:

Ingestion cost: Als u 500.000 pagina's heeft en elke pagina gemiddeld 2 afbeeldingen bevat, kan het genereren van beschrijvingen via een cloud-VLM-API bij een eenmalige indexering in de orde van duizenden euro's kosten. Bereken dit van tevoren. Lokale VLM's (bijv. Qwen2.5-VL 7B of 72B) reduceren deze kosten tot GPU-uren, maar vereisen voldoende VRAM — het 72B-model in 4-bits kwantisatie heeft in de orde van 40+ GB VRAM nodig.

Documentversies: Technische documentatie kent revisies. Rev3 van een tekening kan andere waarden hebben dan Rev1. Een multimodale pipeline moet de versie als metadata bewaren, en retrieval moet op basis daarvan kunnen filteren. Het maakt uit of u de meest actuele versie of een specifieke revisie wilt ophalen.

Evaluatieblinde vlekken: RAGAS-metrics (Faithfulness, Context Recall, Answer Relevancy) werken goed voor tekst. Voor multimodale retrieval bestaat er geen gestandaardiseerde benchmark op uw eigen documenten. U moet handmatig een gold dataset aanmaken — 100–200 vragen met geverifieerde antwoorden — en daarop meten. Zonder dit kunt u niet beoordelen of een architectuurwijziging heeft geholpen of geschaad.

Hallucinaties zijn er nog steeds: RAG vermindert hallucinaties aanzienlijk ten opzichte van pure LLM, maar elimineert ze niet. Als het VLM een tabel bij ingestion onnauwkeurig heeft beschreven, antwoordt het model overtuigend op basis van de onjuiste beschrijving. Belangrijk: de faithfulness-metric meet de consistentie van het antwoord met de aangeleverde context — niet de feitelijke juistheid van de context zelf. Als de afbeeldingsbeschrijving klopt niet, is de faithfulness hoog en het antwoord toch onjuist. Meer over citaties en grounding in het artikel citaties en grounding in RAG.

Aanbevolen architectuur voor industriële PDF's

Als we de ervaring uit implementaties in de machine- en energiesector samenvatten in een concreet advies:

1. 1.Parsing: Docling voor gedrukte PDF's, Unstructured hi_res voor gescande. Extraheer tabellen als zelfstandige entiteiten, afbeeldingen als refereerbare blokken.
2. 2.Tabellen: converteren naar Markdown of JSON, indexeren met parent-child chunking. De koptekst moet deel uitmaken van elke child-chunk.
3. 3.Afbeeldingen en tekeningen: voor gewone documenten caption-and-index met een domeingerichte VLM-prompt (industrie, elektrotechniek, hydraulica). Voor visueel intensieve documenten overweeg unified multimodal embeddings (Cohere Embed v4 of Voyage) of ColQwen2.5 als de opslag acceptabel is.
4. 4.Embedding + retrieval: BGE-M3 blijft een betrouwbare open-weight keuze voor SK/CZ/PL industriële teksten — combineert dense, sparse en multi-vector in één model. Hybrid search (BM25 + dense) is bij technische documentatie vrijwel verplicht vanwege exacte overeenkomst van codes en apparaataanduidingen.
5. 5.Reranking: BGE-reranker-v2-m3 (self-hosted) of Cohere Rerank API. Voegt latency toe, maar is doorslaggevend bij complexe documentatie waarbij dezelfde term op honderden plaatsen voorkomt.
6. 6.Opslag: Qdrant voor multi-vector gevallen, pgvector als u bestaande PostgreSQL-infrastructuur heeft en het volume onder 50 miljoen vectoren blijft.
7. 7.Evaluatie: gold dataset van 100–200 vragen uit echte gebruikersqueries, RAGAS voor tekstmetrics, handmatige annotatie voor multimodale antwoorden.

Veelgestelde vragen

Is ColPali altijd beter dan caption-and-index?

Nee. ColPali bereikt hogere recall op visueel veeleisende documenten, maar tegen de prijs van 100–1.000× meer vectoren per pagina. Voor de meeste industriële corpora met gedrukte tabellen en beschrijvende tekeningen is caption-and-index met een goede VLM-prompt toereikend voor een fractie van de opslagkosten. ColPali loont daar waar de pagina-indeling zelf informatie draagt die een tekstbeschrijving niet kan vastleggen.

Kan ik lokale VLM-modellen gebruiken, of moet ik betalen voor een cloud-API?

Lokale VLM's zijn een volledig functioneel alternatief. Qwen2.5-VL in de 7B-variant draait op een consumer-GPU met 16–24 GB VRAM; de 72B-variant in 4-bits kwantisatie heeft in de orde van 40+ GB VRAM nodig. Voor een caption-and-index pipeline waarbij het VLM draait bij ingestion (niet bij elke query) is een lokaal model economisch voordelig bij een groter corpus. Nadeel: tragere throughput bij indexering. Cloud-API's (GPT-4o, Gemini) bieden hogere beschrijvingskwaliteit, maar bij 500.000+ pagina's kunnen de kosten aanzienlijk zijn.

Hoe omgaan met documenten in meerdere talen — Slowaaks, Engels, Duits?

Voor embedding raden wij BGE-M3 of Qwen3-Embedding-8B aan — beide modellen dekken Slowaaks, Tsjechisch, Pools, Duits en Engels binnen hun meertalige training. Voor VLM-captioning van industriële documenten is Engels nog steeds de aanbevolen taal voor beschrijvingen (modellen zijn daarin aanzienlijk sterker), maar retrieval werkt ook in het Slowaaks dankzij meertalige embeddings.

Wanneer is het zinvol een vector-DB te gebruiken in plaats van pgvector?

pgvector is een legitieme productiekeuze tot 50 miljoen vectoren bij bestaande PostgreSQL-infrastructuur. Voor multi-vector retrieval (ColPali-stijl) met tientallen vectoren per pagina en een miljoen pagina's is Qdrant met native ColBERT-ondersteuning aanzienlijk efficiënter. Een vergelijking van databases vindt u in het artikel vectordatabases — vergelijking.

Wat zijn typische indexeringstijd en -kosten voor een industrieel corpus?

Dat hangt af van de aanpak. Caption-and-index op 100.000 pagina's met een mix van tekst, tabellen en afbeeldingen: bij cloud-VLM-API in de orde van honderden euro's, bij een lokale 7B VLM in de orde van GPU-uren op één A100-equivalent. ColPali-architectuur versnelt de indexering (er hoeven geen beschrijvingen te worden gegenereerd), maar de retrieval-infrastructuur (multi-vector opslag) is duurder. Text-only parsing met Docling zonder VLM is puur CPU-belasting en verwerkt honderdduizenden pagina's in uren op een gewone server.

*Multimodale RAG is geen "fancy feature" — het is een voorwaarde voor een betrouwbaar systeem voor elk corpus waarbij tabellen en tekeningen cruciale informatie dragen. In de industrie geldt dat voor de meeste technische documentatie. Als u met een vergelijkbaar probleem te maken heeft — documenten waarbij een text-only pipeline onbevredigende antwoorden geeft — kijken we graag naar uw specifieke geval en stellen we een architectuur voor die is afgestemd op uw corpus en infrastructuurvereisten.*