Multimodales RAG: Dokumente mit Tabellen, Bildern und Schemata

Sie erhalten die technische Dokumentation einer Fertigungslinie: 1.200 Seiten PDF. Etwa ein Drittel davon sind Parametertabellen, ein weiteres Drittel hydraulische und elektrische Schemata, der Rest zusammenhängender Text. Sie richten eine RAG-Pipeline ein, indexieren die Dokumente, testen die ersten zwanzig Fragen — und drei Viertel davon erhalten falsche oder unvollständige Antworten. Ein Techniker fragt nach der Strombelastung eines bestimmten Antriebs in der Tabelle auf Seite 847. Das Modell antwortet überzeugend und falsch, weil es die Tabelle nie gesehen hat — die naive Pipeline hat sie als zerstreuten Text geparst und beim Chunking-Schritt die Verbindung zwischen Werten und Spalten verloren.

Das ist kein theoretisches Problem. In industriellen Umgebungen — Fertigung, Energie, Maschinenbau — sind 40–60 % des Informationswerts von Dokumenten an Nicht-Text gebunden: Tabellen, Zeichnungen, P&ID-Diagramme, Schaltpläne, Fertigungstoleranzen in Grafiken. Text-only RAG verliert diese Informationen systematisch. Multimodales RAG löst diese Probleme — aber nicht kostenlos und nicht für jeden Inhaltstyp gleich. Dieser Artikel entscheidet, wann es sich lohnt, welche Werkzeuge einzusetzen sind und wo die realen Herausforderungen liegen.

Wo Text-only RAG versagt und warum

Bevor wir zu Lösungen kommen, ist es wichtig, genau zu verstehen, warum die naive Pipeline bei Nicht-Text-Inhalten versagt. Es gibt drei Versagensmechanismen:

Tabellen: Klassisches Chunking nach Token-Anzahl zerschneidet eine Tabelle in Fragmente. Die Spaltenüberschriften landen in einem Chunk, die Werte im nächsten. Merged Cells gehen verloren. Das Ergebnis: Retrieval findet ein Fragment mit einer Zahl, aber ohne Kontext, was diese Zahl bedeutet. Das Modell halluziniert entweder oder antwortet korrekt mit „Ich weiß es nicht" — beide Ergebnisse sind für technische Dokumentation inakzeptabel.

Bilder und Schemata: Der PDF-Parser extrahiert Text und Bilder getrennt. Wenn ein Bild nicht durch umgebenden Text beschrieben ist, ignoriert die Pipeline es. Die meisten industriellen Zeichnungen haben sehr knappen Textkontext — Komponentennummern, Legende — und die inhaltliche Information liegt im visuellen Layout. Das sieht ein Text-only-Modell nicht.

Gescannte Dokumente: Ein älteres Fertigungsdokument ist ein gescanntes Bild. OCR konvertiert es in Text, verliert aber das 2D-Layout. Eine Tabelle in fließendem Text sieht aus wie eine sinnlose Zahlenreihe. Zeichnungen bleiben als Bilder ohne Text übrig, die die Pipeline ignoriert.

Drei Architekturen für multimodales RAG

Es gibt keine Einheitslösung. In der Praxis haben sich drei Ansätze etabliert, jeder mit einem anderen Trade-off zwischen Qualität, Kosten und Komplexität.

1. Caption-and-Index (Beschreibung und Indexierung)

Der einfachste Weg zu multimodalem RAG. In der Ingestion-Pipeline verwenden Sie ein Vision-Language-Modell (VLM) — ein Modell, das Bildeingaben versteht — um automatisch eine Textbeschreibung für jedes Bild und jede Tabelle zu generieren. Diese Beschreibung wird zusammen mit dem Textinhalt der Seite gespeichert und mit standardmäßigem Vektor-Retrieval indexiert.

Implementierung: Unstructured oder Docling extrahiert Bilder und Tabellen aus dem PDF. Für jedes Bild rufen Sie ein VLM auf (z. B. GPT-4o, Gemini 2.5 Pro oder lokal Qwen2.5-VL) mit dem Prompt „Beschreibe exakt, was du auf dieser technischen Zeichnung siehst, einschließlich aller Zahlen, Codes und Beschriftungen". Der resultierende Text wird indexiert.

Vorteile: Retrieval funktioniert mit Standard-Embeddings, die Pipeline ist einfach, der Speicherbedarf ist moderat — in der Größenordnung von Dutzenden GB für Millionen von Seiten. Nachteil: Die Qualität hängt davon ab, wie gut das VLM das Bild beschreibt. Komplexe P&ID-Diagramme mit Dutzenden von Komponenten und ISA-5.1-Symbolik können ungenau beschrieben werden. Für kritische Dokumente empfehlen wir Human-in-the-Loop-Review bei der Beschreibungsgenerierung.

2. Page-as-Image mit Multi-Vector Retrieval (ColPali-Stil)

Anstatt Text aus dem PDF zu extrahieren, wird die gesamte Seite als Bild gerendert und direkt über ein Vision-Language-Embedding-Modell eingebettet — typischerweise Modelle aus der ColPali-Familie, aktuell ColQwen2.5, das auf dem ViDoRe-V2-Leaderboard für visuelles Document Retrieval führende Positionen hält.

Die ColPali-Architektur generiert für jede Seite Dutzende von Patch-Vektoren (nicht einen einzigen Vektor), was eine feinere Erfassung von Details ermöglicht. Beim Retrieval wird Late Interaction verwendet — die Anfrage wird mit jedem Patch-Vektor einzeln verglichen und das Score aggregiert (ähnlich wie ColBERT für Text). Das Ergebnis: deutlich höhere Präzision auf Seiten mit gemischtem Inhalt aus Text, Tabellen und Bildern.

Der Nachteil ist eindeutig: Speicher. Wo Caption-and-Index 1 Vektor pro Seite benötigt, braucht ColPali 100–1.000 Vektoren. Bei großen Korpora (Dutzende von Millionen Seiten) bedeutet das Terabytes an Vektorspeicher. Qdrant hat native Unterstützung für Multi-Vector-Retrieval und ColBERT-Style Late Interaction, was die Implementierung vereinfacht. Für die meisten industriellen Korpora (10.000–500.000 Seiten) ist dieser Overhead akzeptabel — sehr große Deployments müssen die Speicherkosten explizit kalkulieren.

3. Unified Multimodal Embeddings

Der dritte Ansatz: ein Embedding-Modell, das Text und Bilder nativ in einem einzigen Raum verarbeitet. Beispiele: Cohere Embed v4 (128.000-Token-Kontextfenster, Text + Bilder, Enterprise-API), voyage-multimodal-3.5 (Voyage AI, unterstützt Video-Frames). Die gesamte Seite wird direkt eingebettet, ohne Text zu generieren — das Ergebnis ist ein einziger Vektor pro Seite.

Vorteile: Einfachheit, moderater Speicherbedarf (vergleichbar mit Single-Vector-Text-Embeddings), keine Abhängigkeit von der Qualität VLM-generierter Beschreibungen. Nachteil: Diese Modelle sind derzeit nur als Cloud-API verfügbar — für On-Prem- oder Air-Gapped-Umgebungen sind sie nicht geeignet. Die Retrieval-Präzision ist auf den anspruchsvollsten visuellen Dokumenten geringer als bei ColPali, aber für die meisten Enterprise-Korpora ausreichend und deutlich besser als Text-only.

Parsing: Docling und Unstructured

Während die Embedding-Architektur über die Retrieval-Qualität entscheidet, bestimmt das Parsing, was überhaupt in den Index eingeht. Zwei Open-Source-Bibliotheken decken den Großteil des Bedarfs ab:

`Docling` (IBM, Apache 2.0) konvertiert PDFs in strukturiertes JSON. Es erkennt Tabellen, bewahrt die Dokumenthierarchie (Kapitel → Unterkapitel → Inhalt) und extrahiert Bilder mit Positionsreferenzen auf der Seite. Es ist auch auf CPUs schnell und benötigt für normale Textdokumente keine GPU. Für die meisten industriellen PDFs mit gedruckten Tabellen ist das das Werkzeug der Wahl.

`Unstructured` hat einen breiteren Anwendungsbereich: Es versteht mehr Formate (DOCX, PPTX, HTML, E-Mails, Excel-Tabellen) und hat einen Inferenzmodus zur Elementklassifizierung mit einem Modell. Für gescannte Dokumente verwenden Sie den hi_res-Modus, der OCR aktiviert und das Seitenlayout über ein Vision-Modell analysiert. Nachteil: hi_res ist ohne GPU langsam und erzeugt eine Abhängigkeit von einem Docker-Image mit Modellen.

Für industrielle Zeichnungen (P&ID, Schaltpläne) bietet keines der beiden Werkzeuge semantisches Verständnis — sie extrahieren Pixel oder Text, nicht die Schaltungslogik. Wenn Sie Q&A über den logischen Inhalt einer Zeichnung benötigen (nicht nur über Beschriftungen), brauchen Sie spezialisierte VLM-Prompts mit Domänenwissen oder manuelle Annotationen. Diesem Thema widmen wir uns ausführlicher im Artikel LLM über industrielle Dokumentation.

Tabellen: das häufigste Problem in der Praxis

Tabellen sind ein Sonderfall, der einen eigenen Abschnitt verdient. In der Praxis sehen wir drei Tabellentypen in industriellen Dokumenten, jeder mit einem anderen Ansatz:

Parametertabellen (Gerätetypen × Werte) — gut verarbeitbar über Docling oder den LlamaIndex-Table-Parser. Konvertieren Sie in eine Markdown- oder JSON-Darstellung vor der Indexierung. Bewahren Sie den Header als Teil jeder Zeile beim Chunking-Schritt — Parent-Child-Chunking, bei dem Parent = gesamte Tabelle und Child = Zeile mit Header, ist ein bewährtes Muster.

Gescannte Tabellen — erfordern ein VLM. Senden Sie das Tabellenbild mit einem expliziten Prompt an das Modell: „Extrahiere den Inhalt dieser Tabelle im JSON-Format, bewahre die Spaltenüberschriften, alle Werte einschließlich Einheiten und Anmerkungen." Überprüfen Sie das Ergebnis — VLMs können bei handgeschriebenen Werten oder nicht standardmäßigen Symbolen Fehler machen.

Tabellen mit Cross-References (z. B. ein Teilecode verweist auf eine Zeichnung) — hier reicht selbst ein guter Parser nicht aus. Sie benötigen eine explizite Entitätsverknüpfung: ID des Tabelleneintrags ↔ ID der Zeichnung, gespeichert in den Metadaten. Ein Agentic-RAG-Ansatz, bei dem der Agent auf Basis einer gefundenen Referenz einen zweiten Retrieval-Schritt ausführen kann, verbessert die Antworten hier erheblich. Mehr zu Agentic RAG im Artikel Agentic RAG.

Wann Sie multimodales RAG wirklich brauchen

Multimodales RAG fügt Komplexität und Kosten hinzu. Beantworten Sie vor dem Deployment diese Fragen ehrlich:

• Welcher Prozentsatz der Informationen, nach denen Ihre Nutzer fragen, ist an Tabellen oder Bilder gebunden? Wenn weniger als 20 %, lösen Sie es gezielt (manuelle Beschreibungen der wichtigsten Zeichnungen) und bauen Sie keine vollständige multimodale Pipeline.
• Sind Ihre Dokumente primär gedruckt (digitale PDFs) oder gescannt? Gescannte Dokumente erfordern eine GPU bei der Ingestion, was die Indexierungskosten erhöht.
• Benötigen Sie On-Prem, oder ist eine Cloud-API akzeptabel? Die stärksten Unified-Multimodal-Embeddings sind derzeit nur per API verfügbar.
• Wie häufig werden Dokumente aktualisiert? Eine Caption-and-Index-Pipeline ist beim ersten Durchlauf günstiger, aber bei jeder Korpusaktualisierung müssen Sie die Bildbeschreibungen neu generieren — VLM-Aufrufe sind nicht kostenlos.

Für die meisten industriellen Deployments mit gängigen technischen Handbüchern (gedruckt, strukturierte Tabellen, beschriftete Zeichnungen) ist Caption-and-Index mit `Docling`/`Unstructured`-Parser und einem starken VLM ausreichend und deutlich günstiger als ColPali.

ColPali oder Unified-Multimodal-Embeddings lohnen sich, wenn Sie visuell reichhaltige Dokumente haben, bei denen eine Textbeschreibung die Information nicht vollständig erfassen kann — etwa komplexe hydraulische Schemata mit mehrstufiger Verzweigung oder Dokumente, bei denen das Seitenlayout selbst Information trägt.

Herausforderungen, die kein Tutorial erwähnt

Aus Dutzenden von Deployments ergeben sich Probleme, auf die fast jeder stößt:

Ingestion-Kosten: Wenn Sie 500.000 Seiten haben und jede durchschnittlich 2 Bilder enthält, kann die Beschreibungsgenerierung über eine Cloud-VLM-API in der Größenordnung von Tausenden Euro für eine einmalige Indexierung kosten. Kalkulieren Sie das im Voraus. Lokale VLMs (z. B. Qwen2.5-VL 7B oder 72B) reduzieren diese Kosten auf den Preis von GPU-Stunden, erfordern aber ausreichend VRAM — das 72B-Modell in 4-Bit-Quantisierung benötigt in der Größenordnung 40+ GB VRAM.

Dokumentenversionen: Technische Dokumentation hat Revisionen. Rev3 einer Zeichnung kann andere Werte haben als Rev1. Die multimodale Pipeline muss die Version als Metadaten bewahren, und das Retrieval muss danach filtern können. Es kommt darauf an, ob Sie die aktuelle Version oder eine bestimmte Revision benötigen.

Evaluierungs-Sackgasse: RAGAS-Metriken (Faithfulness, Context Recall, Answer Relevancy) funktionieren gut für Text. Für multimodales Retrieval gibt es keinen standardisierten Benchmark für Ihre eigenen Dokumente. Sie müssen manuell einen Gold-Datensatz erstellen — 100–200 Fragen mit verifizierten Antworten — und daran messen. Ohne das können Sie nicht beurteilen, ob eine Architekturänderung geholfen oder geschadet hat.

Halluzinationen sind weiterhin präsent: RAG reduziert Halluzinationen gegenüber reinem LLM deutlich, eliminiert sie aber nicht. Wenn das VLM eine Tabelle bei der Ingestion ungenau beschrieben hat, antwortet das Modell überzeugend auf Basis der falschen Beschreibung. Wichtig: Die Faithfulness-Metrik misst die Konsistenz der Antwort mit dem bereitgestellten Kontext — nicht die faktische Korrektheit des Kontexts selbst. Ist die Bildbeschreibung falsch, ist Faithfulness hoch und die Antwort trotzdem falsch. Mehr zu Quellenangaben und Grounding im Artikel Quellenangaben und Grounding in RAG.

Empfohlene Architektur für industrielle PDFs

Wenn wir die Erfahrung aus Deployments in Maschinenbau und Energiebranche in eine konkrete Empfehlung destillieren:

1. 1.Parsing: Docling für gedruckte PDFs, Unstructured hi_res für gescannte. Extrahieren Sie Tabellen als eigenständige Entitäten, Bilder als referenzierbare Blöcke.
2. 2.Tabellen: in Markdown oder JSON konvertieren, mit Parent-Child-Chunking indexieren. Der Header muss Teil jedes Child-Chunks sein.
3. 3.Bilder und Zeichnungen: für gängige Dokumente Caption-and-Index mit VLM-Prompt orientiert an der Domäne (Industrie, Elektrotechnik, Hydraulik). Für visuell intensive Dokumente ziehen Sie Unified-Multimodal-Embeddings (Cohere Embed v4 oder Voyage) oder ColQwen2.5 in Betracht, wenn der Speicheraufwand akzeptabel ist.
4. 4.Embedding + Retrieval: BGE-M3 bleibt eine zuverlässige Open-Weight-Wahl für SK/CZ/PL-Industrietexte — kombiniert Dense, Sparse und Multi-Vector in einem Modell. Hybrid Search (BM25 + Dense) ist bei technischer Dokumentation nahezu obligatorisch wegen der genauen Übereinstimmung von Codes und Gerätebezeichnungen.
5. 5.Reranking: BGE-reranker-v2-m3 (self-hosted) oder Cohere Rerank API. Fügt Latenz hinzu, ist aber bei komplexer Dokumentation, wo derselbe Begriff auf Hunderten von Seiten auftaucht, entscheidend.
6. 6.Storage: Qdrant für Multi-Vector-Fälle, pgvector wenn Sie eine bestehende PostgreSQL-Infrastruktur haben und das Volumen unter 50 Millionen Vektoren liegt.
7. 7.Evaluierung: Gold-Datensatz mit 100–200 Fragen aus realen Nutzeranfragen, RAGAS für Text-Metriken, manuelle Annotation für multimodale Antworten.

Häufige Fragen

Ist ColPali immer besser als Caption-and-Index?

Nein. ColPali erzielt höheren Recall bei visuell anspruchsvollen Dokumenten, aber zum Preis von 100–1.000× mehr Vektoren pro Seite. Für die meisten industriellen Korpora mit gedruckten Tabellen und beschrifteten Zeichnungen ist Caption-and-Index mit einem guten VLM-Prompt ausreichend — zu einem Bruchteil der Speicherkosten. ColPali lohnt sich dort, wo das Seitenlayout selbst Information trägt, die eine Textbeschreibung nicht erfassen kann.

Kann ich lokale VLM-Modelle verwenden, oder muss ich für eine Cloud-API zahlen?

Lokale VLMs sind eine vollwertige Alternative. Qwen2.5-VL in der 7B-Variante läuft auf einer Consumer-GPU mit 16–24 GB VRAM, die 72B-Variante in 4-Bit-Quantisierung benötigt in der Größenordnung 40+ GB VRAM. Für Caption-and-Index-Pipelines, bei denen das VLM bei der Ingestion läuft (nicht bei jeder Anfrage), ist ein lokales Modell bei größeren Korpora wirtschaftlich vorteilhaft. Nachteil: langsamerer Durchsatz bei der Indexierung. Cloud-APIs (GPT-4o, Gemini) bieten höhere Beschreibungsqualität, können aber bei 500.000+ Seiten erhebliche Kosten verursachen.

Wie geht man mit mehrsprachigen Dokumenten um — Slowakisch, Englisch, Deutsch?

Für Embeddings empfehlen wir BGE-M3 oder Qwen3-Embedding-8B — beide Modelle decken Slowakisch, Tschechisch, Polnisch, Deutsch und Englisch im Rahmen des multilingualen Trainings ab. Für VLM-Captioning industrieller Dokumente ist Englisch weiterhin die empfohlene Sprache der Beschreibungen (Modelle sind darin deutlich stärker), aber das Retrieval funktioniert auch auf Slowakisch dank multilingualer Embeddings.

Wann macht eine Vektor-Datenbank mehr Sinn als pgvector?

pgvector ist eine legitime Produktionswahl bis 50 Millionen Vektoren bei bestehender PostgreSQL-Infrastruktur. Für Multi-Vector-Retrieval im ColPali-Stil mit Dutzenden von Vektoren pro Seite und einer Million Seiten ist Qdrant mit nativer ColBERT-Unterstützung deutlich effizienter. Einen Datenbankvergleich finden Sie im Artikel Vektordatenbanken — Vergleich.

Was ist typische Indexierungszeit und -kosten für einen industriellen Korpus?

Das hängt vom Ansatz ab. Caption-and-Index für 100.000 Seiten mit einem Mix aus Text, Tabellen und Bildern: bei einer Cloud-VLM-API in der Größenordnung von Hunderten Euro, bei einem lokalen 7B-VLM in der Größenordnung von GPU-Stunden auf einem A100-Äquivalent. Die ColPali-Architektur beschleunigt die Indexierung (keine Beschreibungsgenerierung notwendig), aber die Retrieval-Infrastruktur (Multi-Vector-Storage) ist kostspieliger. Text-only Parsing mit Docling ohne VLM ist rein CPU-last und verarbeitet Hunderttausende von Seiten in Stunden auf einem normalen Server.

*Multimodales RAG ist kein „schickes Feature" — es ist die Voraussetzung für ein zuverlässiges System für jeden Korpus, in dem Tabellen und Zeichnungen kritische Informationen tragen. In der Industrie gilt das für den Großteil der technischen Dokumentation. Wenn Sie mit einem ähnlichen Problem konfrontiert sind — Dokumente, bei denen eine Text-only-Pipeline unbefriedigende Antworten liefert — analysieren wir gerne Ihren konkreten Fall und schlagen eine Architektur vor, die auf Ihren Korpus und Ihre Infrastrukturanforderungen zugeschnitten ist.*