RAG – auf einem Auge blind? Warum Multimodal RAG die OCR-Hölle beendet 

Wie viel Zeit hast du in deinem letzten RAG-Projekt damit verbracht, PDFs zu parsen? Wie viele Python-Bibliotheken hast du jongliert, um Tabellen aus Geschäftsberichten zu kratzen oder Header von Footern zu trennen? Und wie oft war die Antwort des Chatbots am Ende trotzdem falsch, weil er ein Diagramm einfach ‚nicht sehen‘ konnte? 

Lass uns über den Elefanten im Raum reden – oder besser gesagt: über den Elefanten im PDF, den unser KI-System für einen Zeilenumbruch hält. 

Retrieval-Augmented Generation (RAG) ist im Enterprise-Umfeld angekommen. Es ist der Standard, um LLMs mit Firmenwissen zu füttern. Und wie kommen diese Daten in unser System? Die verbreitete Technik dafür könnte aus den 90er Jahren stammen: Text-Extraktion. 

Wir nehmen hochvisuelle Dokumente – PowerPoints, technische Zeichnungen, Finanzreports mit komplexen Charts – und jagen sie durch den Fleischwolf, den wir OCR (Optical Character Recognition) nennen. Das Ergebnis ist oft Datensalat. Wir verlieren Layout, Kontext und die visuelle Semantik. Wir machen unser RAG-System blind für alles, was kein ASCII-Zeichen ist. 

Mit dem Release von neuen Retrieval-Modellen, zuletzt Qwen3-VL-Embedding und dem passenden Reranker, ändert sich das gerade fundamental. Wir bewegen uns weg von ‚Text-Based RAG‘ hin zu echtem ‚Multimodal RAG‘ (oder Visual Retrieval). 

Warum das kein technisches Gimmick ist, sondern die Art und Weise verändert, wie wir Knowledge-Management-Architekturen bauen, schauen wir uns heute an. Und weil wir hier ‚mehr Engineering und weniger Magie‘ mögen, habe ich eine Demo-App gebaut, die du direkt ausprobieren kannst (aktueller Mac oder Nvidia GPU empfohlen). 

Das Problem mit dem ‚Blind RAG‘

Schauen wir uns den Status quo an. Ein typischer Ingestion-Prozess sieht heute so aus:

1. Ein PDF kommt rein (z. B. eine Anleitung für eine Industriemaschine). 
2. Wir nutzen Tools wie ‚PyPDF2‘, ‚Unstructured‘ oder ‚Azure Document Intelligence‘. 
3. Wir versuchen, den Text zu extrahieren. 
4. Wir verzweifeln an zweispaltigen Layouts (Liest das Tool jetzt Zeile für Zeile über beide Spalten oder spaltenweise?). 
5. Bilder? Diagramme? Warnhinweise in roten Boxen? Werden oft ignoriert oder durch ein anderes Modell in eine Bildunterschrift (Caption) umgewandelt. 
6. Tabellen? Brauchen oft eine Extrabehandlung und selbst die kommerziellen Tools verzweifeln regelmäßig daran, Spalten- und Zeilen-Header zu erkennen oder lassen Zeilen verrutschen.  
7. Dieser (fehleranfällige) Text wird in Vektoren umgewandelt.

Das Resultat: Ein riesiger Informationsverlust. 

Unternehmenswissen steckt selten in reinem Fließtext. Es steckt in der Beziehung zwischen einer Tabellenzeile und der Spaltenüberschrift. Es steckt in dem Screenshot, der zeigt, wo genau im Menü man klicken muss. Es steckt in der Farbe eines Warnsymbols. 

Wenn ein RAG-System nur Text liest, hat es eine harte ‚Performance Ceiling‘. Unternehmen können das beste LLM der Welt für die Antwortgenerierung nutzen – wenn der Kontext, den sie reinreichen, nur aus zerhackten Textfragmenten und verrutschten Zeilen besteht, wird die Antwort Müll sein. Garbage In, Garbage Out. Sieht aus wie eine Halluzination, ist aber die Schuld der ETL-Pipeline. 

Der Paradigmenwechsel: Visual Retrieval

Die Idee von Multimodal RAG ist simpel, aber radikal: Wir hören auf, Dokumente in Text zu zwingen. 

Stattdessen behandeln wir eine Seite in einem Dokument (oder einen Screenshot) als das, was sie ist: ein Bild. 

Das neue Paradigma sieht so aus: 

• Ingestion: Wir rendern die PDF-Seite als Bild. 
• Embedding: Ein Vision-Language Model (VLM) projiziert dieses Bild direkt in einen Vektorraum. 
• Retrieval: Wenn der User fragt „Wo sehe ich den Umsatzverlauf?“, sucht das System nicht nach dem Wort „Umsatzverlauf“, sondern nach einem Bild, das semantisch zu dieser Frage passt (z. B. ein Balkendiagramm). 

Das klingt logisch, war aber bis vor Kurzem in der Praxis kaum machbar. Die Modelle waren proprietär, zu teuer, nicht mehrsprachig, zu langsam oder konnten Text und Bild nicht gut genug in denselben mathematischen Raum mappen. Ansätze wie ColPali waren vielversprechend, aber architektonisch oft komplex (Stichwort: Multi-Vector Retrieval), was spezielle Datenbank-Setups erforderte. 

Hier kommt Qwen3 ins Spiel. 

Warum Qwen3-VL ein Gamechanger ist (und die Zukunft von RAG einläutet)

Das Qwen-Team (Alibaba Cloud) hat mit dem Release von Qwen3-VL-Embedding und Qwen3-VL-Reranker (Apache 2.0 Lizenz!) zwei Bausteine geliefert, die uns fehlten, um das Ganze produktionstauglich zu machen. 

1. Das Embedding Modell

Normalerweise haben wir Text-Embedding-Modelle (wie ‚text-embedding-3-large‘) und Bild-Modelle (wie ‚CLIP‘). Sie sprechen unterschiedliche Sprachen. Qwen3-VL-Embedding mappt beides in denselben Vektorraum. 

Wir können eine reine Text-Frage stellen („Wie hoch war die Latenz?“) und der Vektor landet im mathematischen Raum direkt neben dem Bild des Latenz-Diagramms. Das System ‚versteht‘, was auf dem Bild zu sehen ist, ohne dass wir jemals OCR laufen lassen mussten. 

2. Der Reranker

Das ist der eigentliche Star. Vektorsuche (ANN) ist unscharf. Wir bekommen oft 50 Ergebnisse zurück, von denen 40 irrelevant sind. Ein Reranker sortiert diese Ergebnisse neu, indem er Query und Dokument paarweise genau prüft. 

Der Qwen3-VL-Reranker ist ein Cross-Encoder, der Bilder und Text versteht. Er schaut sich unsere Frage und das gefundene Bild an und gibt einen Score zurück, wie relevant das Bild wirklich ist. Das steigert die Präzision massiv. 

Beide Modelle sind klein genug (2B bis 8B Parameter), um sie lokal oder kostengünstig in der Cloud zu hosten. Datenschutz? Check! 

Implikationen: mehr als nur ‚bessere Suche‘

Was bedeutet das für Unternehmen? 

Erstens: Die ETL-Pipeline schrumpft. 

Wir brauchen keine komplexen Parsing-Regeln mehr für jedes neue Dokumentenformat. PDF? Screenshot? Powerpoint? Einfach als Bild rendern, embedden, fertig. Das reduziert den ‚Custom Code‘, den Developer warten müssen, drastisch. Es ist ein Shift von ‚Data Engineering Heavy‘ zu ‚Model Heavy‘. 

Zweitens: Wir erschließen ‚Dark Data‘. 

Viele Unternehmen haben Terabytes an gescannten Verträgen oder technischen Zeichnungen, die bisher für RAG unbrauchbar waren, weil OCR an der schlechten Scan-Qualität oder Handschrift scheiterte. Ein VLM ist wesentlich robuster gegenüber Rauschen als klassische OCR-Engines. 

Drittens: neue Query-Typen 

Der User kann jetzt auch ein Foto von einem defekten Bauteil hochladen und fragen: „Was ist das und wie repariere ich es?“. Da Bild und Text im selben Vektorraum liegen, funktioniert Image-to-Document Retrieval ‚out of the box‘. 

Natürlich gibt es auch Trade-offs: 

• Speicher & Compute: Bilder zu speichern und zu verarbeiten braucht mehr Platz und GPU-Power als reiner Text. 
• Latenz: Die Ingestion dauert länger (Inference auf einem VLM ist teurer als ein ‚split()‘ string operation). 
• Halluzinationen: VLMs sind mächtig, neigen bei sehr feinen visuellen Details (z. B. „steht da 1.25 oder 1.26?“) aber teilweise noch zu Fehlern, wenn die Auflösung nicht stimmt. 

Hands-on: der Showcase

Genug Theorie. Ich wollte wissen, ob das wirklich so gut funktioniert wie behauptet und habe eine kleine Demo gebaut. 

Das Ziel: ein längeres PDF indizieren und Fragen beantworten, die man ohne visuelles Verständnis nicht beantworten kann. 

Die Architektur: 

• Ingest: Ein PDF wird Seite für Seite in Bilder (75 DPI) umgewandelt. Text bleibt Text. 
• Embed: Jedes Bild und jeder Text-Chunk wird durch ‚Qwen3-VL-Embedding‘ in einen Vektor verwandelt und in einer Vektordatenbank (hier: in-memory, disk-backed) gespeichert. 
• Query: Der User stellt eine Textfrage und/oder lädt ein Bild hoch. 
• Retrieve: Wir suchen die top-k ähnlichsten Bilder und Text-Chunks. 
• Rerank: Der ‚Qwen3-VL-Reranker‘ sortiert die Treffer. 
• Synthesize: Ein generatives VLM (z.B. ‚Qwen3-VL-2B-Instruc‘ oder ‚GPT-5-mini‘) bekommt die Frage und die relevantesten Bilder und schreibt die Antwort.

Beispiel:

Wir nutzen den „The state of enterprise AI“-Report von OpenAI als Beispiel, ein sehr visuelles PDF-Dokument mit 24 Seiten, vielen Grafiken, Boxen und teils mehrspaltigem Text; Dazu mein CamundaCon 2023 Slidedeck mit 38 Slides. Unter „Ingest Files“ können die PDFs hochgeladen werden und werden direkt indiziert. Zusätzlich können wir noch ein belangloses Textdokument zum Test des textuellen Retrievals hochladen. 

Ich frage: „How is the growth of business customers of ChatGPT in Germany?“ 

Ein Text-RAG würde hier möglicherweise scheitern, da im Text nur der globale Mittelwert genannt wird, die Zahlen für die einzelnen Länder befinden sich nur in einem Balkendiagramm. Das multimodale System findet die Seite, weil es die Struktur eines Diagramms und den Kontext der Zahlen als ‚paying business customers‘ erkennt. 

Oder: „Which page has the pink, violet, and blue pixel art that looks a bit like a sunset on the horizon?“ 

Hier beschreibe ich eine künstlerische Grafik rein visuell. Das System liefert exakt die richtige Seite. Dieses Beispiel zeigt die Relevanz des Rerankers: Embeddings müssen alle Informationen einer Seite im Vorfeld in einen begrenzten Vektor quetschen, ohne zu wissen, welche Informationen später bei Abfragen tatsächlich gebraucht werden. Durch Begriffe wie „sunset“ und „horizon“ in der Query erzielt die Slide mit dem Foto eines Sonnenuntergangs einen sogar leicht höheren Embedding-Score als die gesuchte Slide. Wenn der Reranker aber jedes vorselektierte Bild und die Query nebeneinanderhält, fällt es ihm leicht, zu erkennen, dass nur eine Slide für die Query wirklich relevant ist und sie rutscht von unten in der Rangliste nach ganz oben – mit großem Abstand. 

Letztes Beispiel, diesmal lade ich ein Foto von mir hoch und suche die Vorstellungs-Slide in meinem CamundaCon-Deck. Auf dem Bild habe ich eine ganz andere Pose und eine Brille auf. Zusätzlich zu dem Bild schreibe ich „Find the slide with a portrait of this person on it.“.

Hier musste ich die per Default sehr ressourcenschonend eingestellten Hyperparameter etwas anpassen, um erfolgreich zu sein. Denn das Embedding allein scheitert hier erneut, die meisten Slides aus dem Deck werden ähnlich bewertet (dafür taucht nicht eine Seite des OpenAI Reports in den top-25 auf, vermutlich weil dessen A4-Format nicht zu „slide“ passt). Wenn der Reranker durch ein groß genug ausgelegtes top-k (hier: top-25) die korrekte Slide zu Gesicht bekommt, fällt es ihm wie im vorherigen Beispiel sehr leicht, sie als die richtige zu identifizieren.  

Die Pipeline aus Embedding und Reranker in Kombination erfüllt also ihren Zweck! Die Embedding-Ähnlichkeitssuche selektiert grob vor, der Reranker bewertet die Details und findet die Nadel im Heuhaufen. 

Du kannst das Ganze hier selbst ausprobieren: Demo Repo auf GitHub

Das Repo nutzt ‚uv‘ für das Dependency Management. Wenn du ‚uv‘ installiert hast, reicht ein ‚uv run qwen3vl_multimodal_rag_server.py‘ für die reine Suche ohne Antwortgenerierung. Letztere kann auf verschiedene Arten aktiviert werden, die Readme gibt Auskunft. 

Fazit: Wann lohnt sich der Umstieg? 

Multimodal RAG ist keine Zukunftsmusik mehr. Die Tools sind da, sie sind Open Source, und sie sind leistungsfähig. 

Sollten Unternehmen jetzt all ihre Text-RAGs wegwerfen? Nein. 

Wenn sie hauptsächlich saubere Markdown-Dateien, Wikis oder reine Textverträge durchsuchen müssen, sollten sie bei Text-RAG bleiben. Es ist schneller und günstiger. 

Aber wenn ihr Use-Case: 

• Technische Dokumentationen, 
• Finanzreports mit vielen Charts, 
• Präsentationen (PPTX), 
• oder gescannte Alt-Akten 

beinhaltet, dann ist Visual Retrieval der Weg. Sie sparen sich Monate an Entwicklungszeit für fragile OCR-Parser und liefern den Nutzern ein Sucherlebnis, das sich ‚natürlich‘ anfühlt. 

Wir bewegen uns weg von Systemen, die lesen, hin zu Systemen, die sehen. Und das ist gut so. 

Probier die Demo aus, wirf deine eigenen PDFs rein und sag mir, was du denkst.