Der blinde Fleck im RAG-Index: Wie Vision-to-Text Diagramme, Screenshots und Tabellen durchsuchbar macht

Ein typischer Enterprise-RAG-Fehler sieht nicht aus wie ein spektakulärer Modellfehler. Er sieht aus wie eine ganz normale Antwort, die eine entscheidende Information nicht kennt.

Nehmen wir einen Q3-Report. Der Bericht enthält fünf Seiten Text, ein Management Summary und auf Seite 7 eine eingebettete Abweichungstabelle als Screenshot aus dem Controlling-System:

Fragt später jemand: "Warum lag der Partner Channel in Q3 unter Plan?", kann ein klassisches RAG-System nur antworten, wenn diese Tabelle als Text im Index gelandet ist. Wenn sie als Bild, Screenshot oder eingebettete Excel-Vorschau im PDF steckt, sieht der Text-Extractor vielleicht nur die Bildunterschrift. Der wichtigste Befund bleibt außerhalb des Suchraums.

Das Problem entsteht also nicht erst, wenn das Sprachmodell antwortet. Es entsteht früher: Der Index ist unvollständig.

Wenn Diagramme, Screenshots, Charts und eingebettete Tabellen nicht als Wissensobjekte indexiert werden, kann Enterprise-RAG geschäftskritische Informationen nicht finden, nicht belegen und nicht auditieren. Vision-to-Text adressiert genau diesen blinden Fleck. Es ist mehr als OCR. OCR liest Zeichen. Vision-to-Text beschreibt Bedeutung, Struktur, Beziehungen und Kontext.

Vision-to-Text beschreibt visuelle Inhalte mit Hilfe eines Vision-Language-Models als suchbaren Text. Gute Beschreibungen nennen nicht nur sichtbare Wörter, sondern auch Diagrammtyp, Achsen, Trends, Beziehungen, Abweichungen, UI-Zustände und den Bezug zum umgebenden Dokument.

OCR steht für Optical Character Recognition. OCR extrahiert Zeichen aus Bildern. Das ist wichtig, aber zu eng: Eine rote Linie in einem Architekturdiagramm, ein fallender Balken in einem Chart oder eine deaktivierte Schaltfläche in einem Screenshot sind nicht nur Text.

VLM bedeutet Vision-Language-Model. Ein VLM verarbeitet Bild und Sprache gemeinsam. Es kann etwa einen Chart beschreiben, UI-Elemente erkennen oder ein Diagramm in semantische Aussagen übersetzen.

Visual Retrieval sucht direkt über visuelle Repräsentationen, etwa Seiten-Screenshots oder Bild-Embeddings. Ansätze wie ColPali und VisRAG umgehen klassische OCR-Pipelines teilweise oder ganz.

ColPali / VisRAG sind aktuelle Forschungsrichtungen für visuelles Dokument-Retrieval. ColPali nutzt visuelle Dokument-Embeddings mit Late Interaction. VisRAG argumentiert, dass direkte visuelle Kodierung Informationsverlust gegenüber reiner Texttranskription vermeiden kann. Für Enterprise-RAG sind sie wichtige Referenzpunkte, aber nicht automatisch Ersatz für auditierbare Textbeschreibungen.

Bounding Box ist ein Koordinatenbereich im Dokument oder Bild. Sie sagt, wo ein visuelles Objekt liegt: Seite, x/y-Position, Breite, Höhe. Für Nachvollziehbarkeit ist das entscheidend, weil ein Treffer nicht nur "im Dokument", sondern an einer konkreten Stelle belegt werden muss.

Warum der RAG-Index visuelle Informationen verliert

RAG-Pipelines sind historisch textzentriert. Sie lesen PDFs, DOCX-Dateien, Präsentationen, Wikiseiten oder Tickets, extrahieren Text, zerlegen ihn in Chunks, erzeugen Embeddings und suchen später semantisch danach. Diese Pipeline funktioniert gut, solange Wissen in Fließtext, Listen, Tabellen oder strukturierten Feldern vorliegt.

Enterprise-Dokumente sind aber selten so sauber.

Quartalsberichte enthalten Charts. Prozesshandbücher enthalten Swimlane-Diagramme. Architekturentscheidungen enthalten Systemskizzen. Security-Dokumentationen enthalten Screenshots aus Admin-Konsolen. Produktanforderungen enthalten Wireframes. Audit-Unterlagen enthalten eingescannte Tabellen. Support-Wikis enthalten Fehlermeldungen als Screenshot. In solchen Dokumenten liegt ein erheblicher Teil der Bedeutung nicht im Textstrom, sondern in visuellen Objekten.

Der naive Weg lautet: Bilder ignorieren. Der etwas bessere Weg lautet: OCR anwenden. Der robuste Weg lautet: visuelle Objekte als eigene Wissensobjekte behandeln.

Das ist ein Architekturunterschied. Ein Bild ist nicht einfach "Anhang". Es hat eine Position im Dokument, einen Kontext, einen Typ, sichtbare Elemente, möglicherweise extrahierbare Werte, eine Unsicherheit, Berechtigungen und später eine Rolle in der Antwortbegründung.

OCR ist notwendig, aber nicht hinreichend

OCR beantwortet die Frage: Welche Zeichen stehen im Bild?

Vision-to-Text beantwortet eine andere Frage: Welche Information vermittelt dieses visuelle Objekt im Kontext dieses Dokuments?

Das klingt ähnlich, führt in der Praxis aber zu anderen Indexeinträgen.

Bei RAG geht es nicht darum, jedes Pixel perfekt zu verstehen. Es geht darum, die Information so zu repräsentieren, dass sie später gefunden, gerankt, zitiert und geprüft werden kann.

Die richtige Einheit: Das visuelle Wissensobjekt

Wer Vision-to-Text ernst nimmt, sollte nicht nur eine Bildbeschreibung in den Fließtext kippen. Besser ist ein explizites Objektmodell.

Ein visuelles Wissensobjekt kann zum Beispiel enthalten:

• Dokument-ID, Version, Seite und Position
• Objekt-Typ: Chart, Diagramm, Screenshot, Tabelle, Foto, Scan
• Bounding Box oder andere Positionsinformationen
• umgebender Text vor und nach dem Objekt
• OCR-Rohtext, falls vorhanden
• semantische Beschreibung des VLM
• strukturierte Extrakte, etwa Tabellenwerte oder Achseninformationen
• Confidence- und Unsicherheitsnotizen
• Modell- und Prompt-Version
• Berechtigungs- und Mandantenkontext
• Link oder Referenz auf das Originalbild für Audit und Review

Diese Metadaten sind kein Luxus. Sie entscheiden später darüber, ob ein Treffer erklärbar ist. Ohne Seite, Position und Originalreferenz kann eine Antwort zwar plausibel klingen, aber der Fachbereich kann sie nicht sauber nachprüfen.

Eine belastbare Vision-to-Text-Pipeline

Eine pragmatische Enterprise-Pipeline besteht aus vier Schritten: extrahieren, beschreiben, an der richtigen Stelle einbetten und danach wie normalen Text indexieren. Der letzte Schritt ist wichtig: Vision-to-Text soll die bestehende RAG-Infrastruktur nicht ersetzen, sondern sie um visuelle Wissensobjekte erweitern.

flowchart LR
    A["Quellen<br/>PDF, DOCX, PPTX, Wiki, Tickets"] --> B["Extract<br/>Bild, Seite, Position, Kontext"]
    B --> C["Describe<br/>VLM + OCR + Dokumentkontext"]
    C --> D["Visual Knowledge Object<br/>Beschreibung, Struktur, Bounding Box, Metadaten"]
    D --> E["Inline Replacement<br/>Marker an Originalposition"]
    E --> F["Chunk / Embed<br/>Textpipeline bleibt nutzbar"]
    F --> G["Retrieval<br/>semantisch + Metadatenfilter"]
    G --> H["Antwort<br/>mit Quellen, Seite, Objektbezug"]
    D --> I["Audit Store<br/>Originalbild, Modellversion, Prompt, Unsicherheit"]
    I --> H

Der entscheidende Designpunkt liegt zwischen "Describe" und "Chunk / Embed". Wenn die Beschreibung nur irgendwo im Dokumentanhängsel steht, verliert sie ihren semantischen Ort. Wenn sie dagegen an der Originalposition ersetzt oder eingebettet wird, erbt sie den richtigen Kontext: Kapitel, Überschrift, Absatz, Seitennummer und Nachbarschaft zu den relevanten Aussagen.

Ein vereinfachter Inline-Marker kann so aussehen:

[IMAGE_START page=7 type=embedded_table bbox=112,180,924,612]
Die eingebettete Tabelle zeigt Q3-Abweichungen nach Bereich. Der Partner
Channel liegt mit 4,7 Mio. EUR Ist gegenüber 6,0 Mio. EUR Plan um 21,7 %
unter Plan. Als Kommentar wird eine Pipeline-Qualität unter Plan genannt.
Cloud Operations liegt über Plan; der Kommentar verweist auf einmalige
Migrationskosten. Die Tabelle dient im Abschnitt "Q3 Forecast Review" als
Begründung für Korrekturmaßnahmen im Vertrieb.
[IMAGE_END]

Das ist nicht nur eine Caption. Es ist eine suchbare, prüfbare Repräsentation eines visuellen Befunds.

Warum Kontext vor und nach dem Bild zählt

Ein Bild ohne Kontext ist mehrdeutig. Ein Screenshot kann eine Fehlermeldung zeigen, aber ohne den umgebenden Abschnitt ist unklar, ob er einen bekannten Workaround, ein Risiko oder eine abgeschlossene Migration dokumentiert. Ein Chart kann Umsatz, Marge oder Incident-Volumen zeigen; die Achsen allein reichen nicht immer.

Deshalb sollte der Vision-Schritt den umgebenden Dokumenttext mitbekommen: Überschrift, vorheriger Absatz, nachfolgender Absatz, Dateiname, Abschnitt, Folientitel oder Tabellenüberschrift. Dieser Kontext darf nicht blind in das Modell gekippt werden; er muss begrenzt, nachvollziehbar und gegen Prompt-Injection-Risiken behandelt werden. Aber ohne Kontext erzeugt Vision-to-Text oft generische Bildbeschreibungen, die für Retrieval wenig taugen.

Der Prompt sollte je nach Objektklasse variieren. Ein Chart braucht andere Fragen als ein UI-Screenshot:

• Chart: Welche Achsen, Werte, Trends, Ausreißer und Vergleiche sind sichtbar?
• Diagramm: Welche Komponenten, Beziehungen, Pfeilrichtungen und Grenzen sind dargestellt?
• Screenshot: Welche Oberfläche, welcher Zustand, welche Fehlermeldung und welche Aktion sind erkennbar?
• Tabelle: Welche Spalten, Zeilen, Werte, Hervorhebungen und Abweichungen sind relevant?
• Scan: Welche Textbereiche sind lesbar, welche Bereiche sind unsicher oder verdeckt?

Ein einziger generischer Prompt für alle Bildtypen ist meist zu flach. Er produziert Beschreibungen, die lesbar sind, aber nicht unbedingt als Retrieval-Artefakte funktionieren.

Auditierbarkeit: Was später nachweisbar sein muss

Bei Enterprise-RAG reicht es nicht, dass ein Treffer "irgendwie" gefunden wurde. Fachbereiche, Datenschutz, Revision und Security wollen wissen, warum die Antwort diese Quelle verwendet hat und ob der Kontext erlaubt war.

Eine Audit-Checkliste für Vision-to-Text sollte mindestens diese Punkte abdecken:

Diese Liste ist bewusst bodenständig. Vision-to-Text ist keine magische Compliance-Schicht. Es ist eine Indexierungs- und Nachvollziehbarkeitsschicht, die sauber betrieben werden muss.

ColPali, VisRAG und die Frage: Textbeschreibung oder Visual Retrieval?

Man sollte Vision-to-Text nicht so positionieren, als wäre es automatisch besser als visuelles Retrieval. Das wäre fachlich unsauber.

ColPali zeigt, wie stark direkte visuelle Dokument-Repräsentationen sein können. Der Ansatz arbeitet mit Seitenbildern und Late Interaction und wurde auf dem ViDoRe-Benchmark prominent eingeordnet. Der Vorteil liegt auf der Hand: Layout, visuelle Dichte, räumliche Beziehungen und nicht sauber transkribierbare Signale bleiben näher am Original.

VisRAG geht in eine ähnliche Richtung und argumentiert, dass die Übersetzung multimodaler Informationen in Text unvermeidlich Informationen verlieren kann. Das ist ein wichtiger Einwand. Wer ein komplexes Schaltbild, ein dichtes Bauplan-PDF oder ein layoutlastiges Formular nur beschreiben lässt, verliert möglicherweise visuelle Details, die für Retrieval entscheidend sind.

Trotzdem hat Vision-to-Text im Unternehmen einen starken Platz. Der Grund ist nicht rohe Benchmark-Dominanz, sondern Betriebsfähigkeit:

• Die Beschreibung ist menschenlesbar.
• Sie lässt sich reviewen, korrigieren und versionieren.
• Sie funktioniert mit bestehenden Text-Embedding- und Suchsystemen.
• Sie kann in klassische Audit- und Exportformate überführt werden.
• Sie macht die Begründung einer Antwort leichter nachvollziehbar.

Die ehrliche Architekturfrage lautet also nicht: "Was ist immer besser?" Sondern: "Welche Repräsentation braucht dieser Use Case?"

Entscheidungsmatrix: Vision-to-Text, Visual Retrieval oder Hybrid

Für viele Enterprise-Szenarien ist Hybrid mittelfristig der interessanteste Zielzustand: visuelle Repräsentationen für hohe Trefferqualität, textuelle Beschreibungen für Erklärbarkeit, Audit und klassische Suche. Aber Hybrid ist kein Freifahrtschein. Es braucht Metriken, Kostenkontrolle, Berechtigungslogik und klare Regeln, welche Repräsentation wann in den Modellkontext darf.

Die häufigsten Architekturfehler

Der erste Fehler ist, Vision-to-Text als nachgelagertes Nice-to-have zu behandeln. Wenn visuelle Objekte erst nach der Indexierung irgendwo separat abgelegt werden, fehlen sie beim Chunking, beim Ranking und bei der Quellenlogik.

Der zweite Fehler ist, OCR mit Verstehen zu verwechseln. Eine OCR-Ausgabe aus einem Chart kann viele Zahlen enthalten und trotzdem die eigentliche Aussage verpassen: Welche Reihe fällt ab? Welche Region ist Ausreißer? Welche Annahme ist im Diagramm rot markiert?

Der dritte Fehler ist, Bildbeschreibungen ohne Position zu speichern. Dann kann eine Antwort zwar sagen, "im Report steht eine Q3-Abweichung", aber nicht zeigen, wo. Für Enterprise-Nutzung ist das zu wenig.

Der vierte Fehler ist, Berechtigungen nur auf Dokumentebene zu denken, obwohl visuelle Inhalte eigene Risiken haben. Ein eingebetteter Screenshot kann personenbezogene Daten, Kundennamen, Konfigurationsdetails oder interne Margen enthalten. Die Beschreibung dieses Screenshots ist ein abgeleitetes Artefakt und muss mindestens so geschützt werden wie das Original.

Der fünfte Fehler ist, VLM-Ausgaben als Wahrheit zu behandeln. Vision-Modelle können Zahlen falsch lesen, Achsen verwechseln, UI-Zustände überinterpretieren oder fehlende Werte plausibel ergänzen. Deshalb gehören Unsicherheitsmarker, Originalreferenzen und Review-Möglichkeiten in die Pipeline.

Was gute Antworten später können sollten

Ein RAG-System mit sauberem Vision-to-Text sollte nicht nur eine Antwort geben. Es sollte erklären können, welche visuellen Wissensobjekte es verwendet hat.

Bei der Frage nach dem Partner-Channel aus dem Q3-Beispiel wäre eine gute Antwort nicht:

"Der Partner Channel lag vermutlich wegen geringerer Nachfrage unter Plan."

Eine bessere Antwort wäre:

"Im Q3 Forecast Review zeigt die eingebettete Abweichungstabelle auf Seite 7 für den Partner Channel 4,7 Mio. EUR Ist gegenüber 6,0 Mio. EUR Plan. Als Kommentar ist 'Pipeline-Qualität unter Plan' angegeben. Die Aussage stammt aus einem als Tabelle klassifizierten visuellen Objekt; die Originalstelle ist Seite 7, Tabelle im Abschnitt 'Q3 Forecast Review'."

Der Unterschied ist erheblich. Die zweite Antwort nennt Quelle, Objektart, Wert, Kontext und Grenze der Aussage. Sie behauptet nicht mehr, als die Quelle hergibt.

Worauf CTOs und AI-Teams bei der Umsetzung achten sollten

Vision-to-Text ist kein einzelner API-Call. Es ist ein Teil der Wissensarchitektur.

Für die technische Bewertung helfen diese Fragen:

• Welche Dateiformate werden wirklich unterstützt: PDF, DOCX, PPTX, HTML, Wiki, Tickets?
• Werden Bilder extrahiert oder ganze Seiten gerendert?
• Wird der umgebende Dokumentkontext in die Beschreibung einbezogen?
• Gibt es objektklassenspezifische Prompts für Charts, Screenshots, Diagramme und Tabellen?
• Werden Originalposition, Bounding Box und Seite gespeichert?
• Werden OCR-Rohtext, VLM-Beschreibung und strukturierte Werte getrennt?
• Gibt es Confidence- oder Unsicherheitsfelder?
• Wie werden Berechtigungen auf abgeleitete Beschreibungen übertragen?
• Wie werden Modell- und Prompt-Versionen dokumentiert?
• Wie wird bei Dokumentversionen, Löschungen und Rechteänderungen re-indexiert?
• Wie wird evaluiert: Trefferqualität, Beschreibungstreue, Fehlerklassen, Audit-Nachvollziehbarkeit?

Wer diese Fragen nicht beantworten kann, hat wahrscheinlich keine Vision-to-Text-Architektur, sondern nur eine Caption-Funktion.

Fazit: Erst der vollständige Index, dann die intelligente Antwort

Enterprise-RAG scheitert selten daran, dass ein Sprachmodell gar nichts kann. Es scheitert oft daran, dass der relevante Kontext nie im Modell ankommt.

Der blinde Fleck liegt im Index. Wenn Diagramme, Screenshots, Charts und eingebettete Tabellen fehlen, sieht das Modell nur einen Ausschnitt der Organisation. Bei unkritischen Dokumenten ist das ärgerlich. Bei Forecasts, Vertriebssteuerung, Compliance-Nachweisen, Incident-Analysen oder Architekturentscheidungen kann es geschäftskritisch werden.

Vision-to-Text schließt diese Lücke nicht perfekt, aber systematisch. Es macht visuelle Informationen suchbar, nachvollziehbar und anschlussfähig an bestehende RAG-Pipelines. OCR bleibt ein Baustein. Visual Retrieval bleibt ein starker Forschungs- und Architekturpfad. Der robuste Enterprise-Ansatz behandelt visuelle Inhalte jedoch als eigene Wissensobjekte: mit Kontext, Position, Beschreibung, Berechtigung und Audit-Spur.

TensorFive hat diesen Punkt in der RAG API sauber aufgenommen: visuelle Inhalte werden nicht als Randfall behandelt, sondern als Bestandteil einer Enterprise-RAG-Pipeline, die Suche, Kontextbildung und Nachvollziehbarkeit zusammendenkt. Wer eine bestehende Wissensbasis um Diagramme, Screenshots und eingebettete Tabellen erweitern möchte, kann die TensorFive RAG API dafür nutzen, ohne die eigene Architektur auf aggressive Produktlogik oder Black-Box-Versprechen zu bauen.

Weiterführende Quellen

• TensorFive: RAG API - Enterprise RAG-as-a-Service
• Faysse et al.: ColPali: Efficient Document Retrieval with Vision Language Models
• VisRAG Team: VisRAG: Vision-based Retrieval-augmented Generation on Multi-modality Documents