Vision RAG vs OCR 2026: Welcher Ansatz ist besser für die Dokumentenverarbeitung

Mit der Einführung von GPT-4V im Jahr 2023 und der weiteren Entwicklung multimodaler Modelle wird in technischen Diskussionen regelmäßig die Frage gestellt: Braucht man überhaupt OCR, wenn ein Vision-Modell ein Dokument direkt als Bild lesen kann? In den Jahren 2025–2026 ist diese Frage praktisch geworden – es gibt Tools, Benchmarks und reale Projekte. Es ist Zeit, die Kompromisse zu bewerten.

Dieser Artikel richtet sich an Architekten, die Dokumenten-RAG-Pipelines entwerfen oder optimieren und verstehen möchten, welcher Ansatz für ihr Szenario geeignet ist. Wenn Sie eine technische Aufschlüsselung benötigen, wie OCR-Fehler das Chunking und die Embeddings zerstören, lesen Sie den vorherigen Artikel der Serie: „Wie OCR die Qualität von RAG-Systemen beeinflusst: Eine technische Analyse“.

Warum die Dokumentenverarbeitung keine triviale Aufgabe für KI ist

„KI mit Unternehmensdokumenten verbinden“ klingt einfach. In der Praxis stehen zwischen diesem Satz und einem funktionierenden RAG-System mehrere nicht-triviale Probleme, die jeweils die Wahl des Architekturansatzes beeinflussen.

Problem 1: Dokumente sind kein reiner Text

70–80 % der Unternehmensdaten sind unstrukturiert: Scans, PDF-Bilder, Papierformulare. Selbst ein „digitales“ PDF kann Tabellen als Bilder, Seiten mit komplexen Layouts oder eingebettete Diagramme enthalten. Kein Text-Parser kann Pixel lesen.

Problem 2: Die Struktur des Dokuments trägt Bedeutung

In der Zeile einer Rechnung „50 | Kabel | 120 UAH“ wird der Inhalt durch die Position in der Tabelle bestimmt. Wenn die Tabelle in linearen Text zerfällt – „50 Kabel 120 UAH“ – geht die Verbindung zwischen Menge, Name und Preis verloren. OCR ignoriert traditionell die räumlichen Beziehungen zwischen Elementen.

Problem 3: Archivheterogenität

Ein echtes Unternehmensarchiv ist selten homogen. Es enthält saubere digitale PDFs, Scans unterschiedlicher Qualität, Dokumente mit komplexen Layouts, handschriftliche Notizen, gemischte Formulare. Eine Lösung, die für einen Typ perfekt funktioniert, kann bei einem anderen völlig versagen.

Gerade diese Heterogenität macht die Wahl zwischen OCR-first und Vision-first zu keiner akademischen Frage, sondern zu einer architektonischen Entscheidung mit realen Auswirkungen auf die Qualität und Kosten des Systems.

OCR-first Architektur: Der klassische Ansatz und seine Grenzen

OCR-first ist der Standardansatz für Dokumenten-RAG-Systeme der letzten 3–4 Jahre. Die Logik ist einfach: Wir konvertieren das Bild in Text und arbeiten dann mit einer Standard-Text-RAG-Pipeline.

OCR-first Architektur

Dokument (Scan / PDF)
  ↓
Bildvorverarbeitung (Schräglagenkorrektur, Entrauschen, Ausrichtung)
  ↓
OCR-Engine → reiner Text
  ↓
Nachbearbeitung (Normalisierung, Müllentfernung)
  ↓
Chunking
  ↓
Text-Embeddings (text-embedding-3-small, BGE, E5)
  ↓
Vektor-DB → Retrieval → LLM
  

Vorteile von OCR-first

Systemgrenzen von OCR-first

Eine detaillierte Analyse, wo und wie diese Einschränkungen das Chunking, die Embeddings und das Retrieval brechen, finden Sie im vorherigen Artikel der Serie: „Wie OCR die Qualität von RAG-Systemen beeinflusst“.

Vision-first Architektur: GPT-4o, Gemini, Qwen2.5-VL, olmOCR, Docling

Der Vision-first-Ansatz ersetzt oder umgeht den OCR-Schritt: Das Dokument wird als Bild an ein Vision-Language Model (VLM) übergeben, und das Modell extrahiert selbst Text, Struktur und Kontext.

Vision-first Architektur (TextRAG durch Vision-Parsing)

Dokument (Scan / PDF / Bild)
  ↓
Rendern von Seiten als Bilder (pdf2image / PyMuPDF)
  ↓
VLM-Parsing → strukturierter Text (Markdown / JSON)
  ↓
Chunking (basierend auf gespeicherter Struktur)
  ↓
Text-Embeddings → Vektor-DB → Retrieval → LLM
  

VisRAG Architektur (Embeddings aus Bildern)

Dokument → Seiten als Bilder
  ↓
Visuelle Embeddings (ColPali, ColQwen2, MuRAG-ähnliche Modelle)
  ↓
Multimodale Vektor-DB (Bilder + Textanfragen)
  ↓
Retrieval → relevante Seitenbilder
  ↓
VLM-Generierung der Antwort basierend auf den gefundenen Bildern
  

Im VisRAG-Ansatz wird das Embedding nicht aus Text, sondern aus dem Bild der Seite selbst berechnet. Das Retrieval erfolgt in einem multimodalen Raum: Eine Textanfrage wird mit Bildvektoren abgeglichen. Die VisRAG-Forschung (ICLR 2025) zeigt, dass dieser Ansatz bei multimodalen Dokumenten einen **20–40 %igen Anstieg des End-to-End-Ergebnisses** im Vergleich zu traditionellem TextRAG liefert – dank der Beibehaltung von Layout-Informationen, die eine Text-OCR-Pipeline verliert.

Übersicht über aktuelle Vision-Tools (2025–2026)

Wo OCR an Struktur verliert: Tabellen, Spalten, Header

Um zu verstehen, wo Vision gewinnt, muss man konkret sehen, wo OCR verliert. Betrachten wir drei der häufigsten Fehlerarten.

Fehlerart 1: Tabellen mit verbundenen Zellen

Die Anfrage „Wie hoch ist der Gewinn für Q1–Q2 2024?“ passt im OCR-Fall nicht: „Q1–Q2 2024“ und „1 100 000“ befinden sich an verschiedenen Positionen im linearen Text ohne strukturelle Verbindung. Im Vision-Fall ist die Tabelle erhalten geblieben, das Retrieval findet die richtige Zeile.

Fehlerart 2: Mehrspaltiges Layout

Ein zweiseitiges Dokument (z. B. eine medizinische Akte oder ein wissenschaftlicher Artikel) wird von OCR von links nach rechts über die gesamte Seitenbreite gelesen. Ergebnis: Sätze aus der linken und rechten Spalte wechseln sich in einem einzigen Textstrom ab. Der Satzteiler schneidet an falschen Stellen. Chunks enthalten gemischten Kontext aus zwei nicht zusammenhängenden Themen.

Das Vision-Modell identifiziert Spalten als separate Textblöcke und liest jede unabhängig. Laut dem Vergleichs-Benchmark von Procycons (2025) verarbeitet Docling mit TableFormer komplexe Tabellen korrekt, wo Unstructured (OCR-basiert) Spaltenverschiebungen und eine unvollständige ToC liefert.

Fehlerart 3: Hierarchische Header und Lesereihenfolge

Eine technische Spezifikation mit den Abschnitten H1 → H2 → H3 → Absatz wird nach OCR in einen fortlaufenden Text ohne Hierarchie umgewandelt. Semantisches Chunking „weiß“ nicht, dass dieser Absatz zum Abschnitt „4.2.1 Sicherheitsanforderungen“ gehört – da die strukturelle Markierung verloren gegangen ist. Das Retrieval für die Anfrage „Sicherheitsanforderungen“ kann den richtigen Chunk verpassen oder einen irrelevanten zurückgeben.

olmOCR und Docling behalten die Lesereihenfolge und die Hierarchie der Überschriften in der Ausgabe bei – dies ermöglicht es den Chunk-Strategien, sich an den strukturellen Grenzen des Dokuments zu orientieren und nicht nur an der Textgröße.

Wo Vision-Modelle gewinnen: komplexe Layouts, Diagramme, handschriftlicher Text

Fallstudie: medizinische Dokumentation mit gemischtem Inhalt

In der Praxis von AskYourDocs haben wir ein Archiv eines medizinischen Zentrums verarbeitet: gescannte Patientenakten, bei denen jede Seite eine gedruckte Vorlage, handschriftliche Notizen des Arztes, einen Abteilungsstempel und eingefügte Analyseergebnisse in Form von Bildern enthielt.

Die OCR-Pipeline lieferte nur für den gedruckten Teil (~60 % der Seite) ein zufriedenstellendes Ergebnis. Die handschriftlichen Notizen des Arztes (entscheidend für den klinischen Kontext) wurden mit einer CER von ca. 8–12 % erkannt – schlechter als der Durchschnitt aufgrund der Spezifität medizinischer Terminologie in handschriftlicher Form. Eingefügte Analyseergebnisse als Bilder waren vollständig unzugänglich.

Nach dem Wechsel zu GPT-4o-mini mit detailliertem Prompt für medizinische Dokumentation: Die Genauigkeit bei handschriftlichen Feldern stieg auf ein akzeptables Niveau, die Analyseergebnisse wurden für das Retrieval zugänglich. Der allgemeine Recall@5 auf dem Testdatensatz klinischer Fragen stieg von 0,34 auf 0,71.

Einschränkungen: Die Kosten stiegen um das ~15-fache; die Verarbeitung erforderte eine DPA mit OpenAI und eine separate rechtliche Genehmigung. Für ein kleines Archiv (3.000 Karten) war dies akzeptabel. Für 50.000+ ist eine Self-Hosted-Lösung erforderlich.

Vergleich der Retrieval-Qualität: TextRAG vs VisRAG

Beide Ansätze unterscheiden sich prinzipiell nicht nur auf der Ebene des Parsings, sondern auch auf der Ebene dessen, was vektorisiert wird und wie das Retrieval abläuft.

TextRAG: Text-Embeddings nach OCR oder Vision-Parsing

In der TextRAG-Pipeline (unabhängig davon, ob der Text über OCR oder Vision-Parsing erhalten wurde) wird der Text vektorisiert. Das Embedding-Modell (text-embedding-3-small, BGE, E5) wandelt einen Text-Chunk in einen Vektor um. Retrieval ist eine ANN-Suche im Textraum.

Problem: Wenn Layout-Informationen (Position von Elementen auf der Seite, Hierarchie, Tabellenstruktur) nicht im Text erhalten bleiben, gehen sie für das Retrieval verloren. OCR → Text-Embeddings sind zwei Schritte mit Informationsverlust.

VisRAG: Embeddings von Seitenbildern

VisRAG (arXiv 2410.10594, ICLR 2025) schlägt einen prinzipiell anderen Ansatz vor: Das Embedding wird nicht aus Text, sondern aus dem Seitenbild selbst über ein Vision-Language Model (ColPali, ColQwen2 und ähnliche) berechnet. Retrieval ist eine Suche in einem multimodalen Raum: Eine Textanfrage wird mit Bildvektoren abgeglichen.

Vorteil: Layout, Farbe, Position, Schriftart, Tabellenstruktur – all das ist im Bildvektor kodiert. Kein Schritt mit Informationsverlust zwischen dem Originaldokument und den Embeddings.

ICLR 2025 Ergebnisse: VisRAG übertrifft traditionelles TextRAG sowohl bei der Retrieval- als auch bei der Generierungsphase und erzielt eine **end-to-end Steigerung von 20–40 %** bei multimodalen Dokumenten. VisRAG 2.0 (Oktober 2025) zeigt zusätzlich eine Verbesserung von 27 % bei visuellen QA-Benchmarks durch evidenzbasierte Multi-Image-Reasoning.

Vergleich der Ansätze nach Schlüsselmetriken

Praktische Schlussfolgerung: VisRAG ist eine vielversprechende Richtung für multimodale Dokumente, aber im Jahr 2026 ist es für die meisten Unternehmensszenarien noch nicht produktionsreif. Vision → TextRAG (Parsing über VLM + Text-Embeddings) ist ein ausgereifterer Kompromiss, der die Qualität des Vision-Parsings mit der Vorhersehbarkeit eines Standard-RAG-Stacks kombiniert.

Kosten: Token, Latenz, Infrastruktur

Für einen Architekten sind die Kosten nicht nur API-Preise. Sie sind eine Kombination aus Rechenleistung, Latenz, betrieblicher Komplexität und Skalierungsmerkmalen. Betrachten wir jede Dimension.

Parsing-Kosten: OCR vs. Vision API

Der Unterschied zwischen self-hosted OCR und GPT-4o für 100.000 Seiten beträgt das 60- bis 600-fache. Bei einem täglichen Durchsatz von 10.000 neuen Dokumenten pro Jahr sind das Millionen von Seiten. In diesem Maßstab werden die Kosten der Vision API zum wichtigsten architektonischen Limit.

Latenz: Was bedeutet das für verschiedene Szenarien

Für Echtzeitsysteme – automatische Verarbeitung eingehender Rechnungen, Indizierung von Dokumenten zum Zeitpunkt des Eingangs – ist die Vision API praktisch unbrauchbar ohne Enterprise-Level-Zugang.

Infrastrukturkomplexität

Hybridansatz: Wann und wie man OCR + Vision kombiniert

Ich glaube, dass für die meisten Unternehmensarchive der beste Ansatz nicht darin besteht, OCR zugunsten von Vision-Modellen vollständig aufzugeben, sondern sie zu kombinieren. In der Praxis ermöglicht dies eine deutliche Kostenreduzierung – manchmal um das 5- bis 10-fache – und bewahrt gleichzeitig eine hohe Verarbeitungsqualität für Dokumente mit komplexem Layout, Tabellen und Grafiken.

Architektur einer hybriden Pipeline

Eingehendes Dokument
  │
  ├─► Textschicht? → Ja → Nativer Parser (PyMuPDF / Docling)
  │                                    ↓
  │                              Strukturierter Text
  │
  └─► Nein (Scan oder Bild)
          │
          ├─► Klassifikator des Dokumententyps
          │         │
          │         ├─► Standarddokument (Vertrag, Rechnung, Bericht)
          │         │         ↓
          │         │   Self-hosted OCR (PaddleOCR / Tesseract)
          │         │         ↓
          │         │   Müllerkennung (Alphabetanteil, Langdetect)
          │         │         │
          │         │         ├─► Qualität OK → Nachbearbeitung → Chunking
          │         │         └─► Qualität niedrig → Vision-Fallback
          │         │
          │         └─► Komplexes Dokument (Tabellen, Diagramme, Handschrift)
          │                   ↓
          │             Vision OCR (GPT-4o-mini / olmOCR-2 / Docling)
          │                   ↓
          │             Strukturiertes Markdown → Chunking
          │
          └─► Protokollierung: Typ, Verarbeitungspfad, CER-Bewertung
  

Routing-Kriterien: Was an Vision weiterleiten

Self-hosted Vision als DSGVO-konforme Alternative

Für Organisationen, bei denen Daten nicht an Cloud-APIs gesendet werden dürfen, die Qualität der klassischen OCR jedoch nicht ausreicht – olmOCR-2 (82,4 auf olmOCR-Bench) und Docling mit TableFormer bieten produktionsreife Qualität bei vollständigem Self-Hosting. Qwen2.5-VL-7B ist eine weitere Option für einen mittleren Qualitäts-/Compute-Kompromiss (benötigt GPU mit ca. 16 GB VRAM).

Granite-Docling-258M von IBM ist eine kompakte Alternative für ressourcenbeschränkte Umgebungen: 258 Millionen Parameter bei einer Genauigkeit auf Augenhöhe mit Modellen, die um ein Vielfaches größer sind (Apache 2.0, Self-hosted).

Empfehlungen: Auswahlmatrix nach Dokumententyp und Budget

Kurzer Entscheidungsbaum für den Architekten

Schlussfolgerungen

Die Wahl zwischen OCR und Vision im Jahr 2026 ist keine Wahl zwischen alt und neu. Es ist eine Wahl von Kompromissen, die von einem bestimmten Archiv, Budget und Compliance-Anforderungen abhängen.

Wichtige Schlussfolgerungen

Die nächste Frage nach der Wahl der Parsing-Architektur ist, wie der erhaltene Text optimal vektorisiert werden kann. Die Dimensionalität des Embedding-Vektors, die Wahl des Modells und der Einfluss auf die Abrufqualität sind Themen des nächsten Artikels der Serie.