Wie OCR die Qualität von RAG-Systemen beeinflusst: Eine technische Analyse

Wenn Ihr RAG-System irrelevante Ergebnisse liefert oder konsequent halluziniert – der erste Ort, an dem Sie nach dem Problem suchen sollten, ist nicht das Modell, nicht die Chunking-Parameter und nicht die Vektordatenbank. Suchen Sie im Text, den Sie dort hochgeladen haben.

Ein OCR-Fehler ist kein lokaler Defekt. Es ist eine Rauschinjektion am Eingang der Pipeline, die sich bei jedem nachfolgenden Schritt multipliziert. Verzerrtes Token → falsche Satzgrenze → fehlerhafter Chunk → verschobener Vektor → verpasstes Retrieval → halluzinierte Antwort. Jeder Schritt verstärkt den vorherigen.

Dieser Artikel ist eine technische Analyse, wo und wie dies geschieht, mit realen Beispielen von Artefakten und konkreten Korrekturmethoden. Wenn Sie einen allgemeinen Überblick darüber benötigen, was OCR ist und warum es in RAG-Systemen benötigt wird – lesen Sie den vorherigen Artikel der Serie: „OCR in modernen KI-Systemen: von gescannten Dokumenten zu RAG“.

Pipeline zur Verarbeitung gescannter Dokumente: von PDF zu Embeddings

Bevor wir analysieren, wo etwas kaputt geht – lassen Sie uns die vollständige Pipeline abbilden. Jeder Schritt unten ist ein potenzieller Punkt der Qualitätsdegradation.

Die wichtigste Erkenntnis aus dieser Karte: Ein OCR-Fehler (Schritt 3) lokalisiert sich nicht in Schritt 3. Er driftet durch die gesamte Pipeline und manifestiert sich in Schritt 9 als Problem mit der Antwortqualität – weit weg von der Ursache.

Deshalb suchen die meisten Teams an der falschen Stelle: Sie optimieren das Chunking, wechseln das Embedding-Modell, konfigurieren den Reranker – aber das Problem bleibt, weil es in den Eingabedaten liegt.

Typische OCR-Artefakte: Was genau kaputt geht und warum

Unten finden Sie eine reale Taxonomie von Artefakten, denen Sie in typischen Unternehmensarchiven begegnen werden. Für jedes Artefakt gibt es ein Beispiel, wie es aussieht und was es in der weiteren Pipeline beschädigt.

1. Zusammengeklebte Wörter (word merging)

Ursache: ungleichmäßiger Kontrast zwischen Zeichen und Hintergrund, niedrige DPI, JPEG-Kompression.

Was es kaputt macht: Der Satzteiler findet keine Satzgrenzen; der Tokenizer des Embedding-Modells erhält ein OOV-Token anstelle von zwei bekannten Wörtern; die Suche nach „термін дії“ findet keinen Chunk mit „терміндіїдоговору“.

2. Zeichenersetzung (character substitution)

Ursache: Ähnlichkeit der Zeichenformen bei niedriger Auflösung oder schlechtem Kontrast. Besonders häufig – bei gemischten kyrillischen und lateinischen Schriftarten.

Was es kaputt macht: Numerische Werte werden zu Text; die Suche nach dem genauen Wert („доза 2,5 мг“) passt nicht zum Artefakt; in medizinischen und juristischen Dokumenten ist dies ein kritischer Fehler.

3. Phantomzeichen und -zeilen (hallucinated content)

Ursache: OCR versucht, jedes Pixelmuster als Zeichen zu erkennen. Umgedrehter Text, Scannerrauschen, Kompressionsartefakte – all das wird in „Text“ umgewandelt.

Was es kaputt macht: Müll gelangt als gültiger Inhalt in den Vektor; beim Retrieval erhält die LLM einen unlesbaren Kontext und halluziniert oder sagt „Ich weiß es nicht“.

4. Kaputte Tabellenstruktur

Ursache: Klassisches OCR versteht die räumlichen Beziehungen zwischen Zellen nicht. Es liest den Text linear: von oben nach unten, von links nach rechts, ignoriert die Spaltenstruktur.

Was es kaputt macht: Beim Chunking gerät die gesamte Tabelle als linearer Textblock ohne Kennzeichnung in einen Chunk; die Anfrage „wie viel kostet das Kabel“ passt nicht zu einer strukturlosen Zeile; der Chunk überträgt die semantische Verbindung zwischen Artikel, Name und Preis nicht.

5. Falsche Silbentrennungen und Zeilenumbrüche

Ursache: OCR unterscheidet nicht immer zwischen Silbentrennung und Zeilenende in Texten mit Spalten oder engen Rändern.

Was es kaputt macht: „відповідаль-“ und „ність“ werden zu separaten Tokens; ein durch einen Bindestrich getrenntes Wort erzeugt ein OOV-Token; der Zahlenwert „38 400“ wird in zwei Zeilen aufgeteilt und als „38“ und „400,00“ geparst – getrennte Tokens ohne den Kontext der Summe.

Wie OCR-Fehler die Chunking-Strategie zerstören

Chunking ist die Aufteilung des Textes in Fragmente, die vektorisiert und im Index gespeichert werden. Die Qualität eines Chunks bestimmt die Qualität des Retrievals: Wenn ein Chunk semantisch inkorrekt ist, kann selbst ein perfektes Embedding die Situation nicht retten.

Betrachten wir drei Haupt-Chunking-Strategien und wie OCR-Artefakte jede von ihnen brechen.

Strategie 1: Fixed-size chunking (nach Token-Anzahl)

Die einfachste Strategie: Text in Chunks von N Tokens mit Überlappung aufteilen. Problem: Sie hängt vollständig von der korrekten Tokenisierung ab.

Strategie 2: Sentence-based chunking

Aufteilung nach Sätzen (spaCy, nltk sentence splitter). Erfordert korrekte Satzenden: Punkte, Fragezeichen, Ausrufezeichen mit einem Leerzeichen danach.

OCR-Artefakte brechen systematisch die Erkennung von Satzgrenzen:

Strategie 3: Semantic / recursive chunking

Fortgeschrittenere Ansätze (recursive character splitter, semantisches Chunking mit Embedding-Ähnlichkeit) sollten theoretisch widerstandsfähiger gegen oberflächliche Artefakte sein. In der Praxis – nein.

Semantisches Chunking definiert Grenzen durch die Änderung der Semantik zwischen benachbarten Sätzen. Wenn Sätze durch OCR-Artefakte verzerrt sind, wird das Embedding jedes Satzes verschoben – und der Algorithmus „sieht“ einen semantischen Bruch, wo keiner ist, oder sieht ihn nicht, wo er ist.

Ergebnis: Chunks werden an „semantisch korrekten“ Stellen für den verzerrten Text geschnitten – aber nicht für den ursprünglichen Inhalt.

Wie OCR-Fehler sich in der gesamten RAG-Pipeline ausbreiten

PDF Scan
   ↓
OCR (95%)
   ↓
Chunking
   ↓
Embeddings
   ↓
Retriever
   ↓
LLM
   ↓
Answer

Ich sehe oft, dass viele Entwickler sich auf die Wahl der LLM oder des Embedding-Modells konzentrieren, aber die Qualität der Antwort wird viel früher bestimmt – in der OCR-Phase. Wenn das System den Text falsch erkannt hat, gelangt dieser Fehler in die Chunks, dann in die Embeddings, beeinflusst das Retrieval und spiegelt sich schließlich in der endgültigen Antwort wider.

Deshalb kann sich ein Fehler in der OCR-Phase in der gesamten Dokumentenverarbeitungskette ausbreiten. Selbst die fortschrittlichste LLM kann keine Informationen finden, die bereits während der Texterkennung verloren gegangen oder verzerrt wurden.

In der Praxis führt die Verbesserung der OCR-Qualität oft zu einem größeren Genauigkeitsgewinn für das RAG-System als der Wechsel zu einer teureren LLM oder die Verwendung eines größeren Embedding-Modells. Wenn das Retrieval falsche Daten erhält, kann kein generatives Modell dieses Problem vollständig kompensieren.

Praktische Schlussfolgerung zum Chunking

Ich bin überzeugt, dass keine Chunking-Strategie systematisch einen „verschmutzten“ Eingabetext kompensieren kann. Die Nachbearbeitung nach OCR ist ein obligatorischer Schritt vor jedem Chunking. Ohne dies verschwindet der Unterschied zwischen Fixed-Size und Semantic Chunking praktisch: Beide Ansätze beginnen, mit inkorrekten Chunks zu arbeiten, nur auf unterschiedliche Weise.

Einfluss von Rauschen auf die Qualität von Embedding-Vektoren

Ein Embedding-Modell wandelt einen Text-Chunk in einen numerischen Vektor in einem n-dimensionalen Raum um. Semantisch ähnliche Texte haben nahe Vektoren (hohe Kosinus-Ähnlichkeit). Die semantische Suche sucht genau nach dieser Nähe.

OCR-Rauschen beeinflusst den Vektor über zwei Mechanismen:

Mechanismus 1: OOV-Tokens (Out-of-Vocabulary)

Wenn ein Wort in den Trainingsdaten des Modells nicht vorkommt, kodiert es dieses „nach seiner Form“: es zerlegt es in Subword-Tokens, von denen jedes ein schwaches oder gar kein semantisches Signal hat. Der Vektor des Chunks verschiebt sich von seiner korrekten semantischen Position.

Mechanismus 2: Verdünnungseffekt (Signalverdünnung)

Das Embedding-Modell mittelt das Signal über alle Tokens eines Chunks (vereinfacht). Wenn 15–20 % der Tokens in einem Chunk Müll ohne semantische Bedeutung sind, wird der Vektor „verdünnt“: er wird zu einer weniger genauen Darstellung des eigentlichen Inhalts.

Praktisches Beispiel: Ein Chunk mit 400 Tokens, von denen 80 Artefakte sind (zusammengewachsene Wörter, Rauschsymbole, falsche Zeilenumbrüche). Das effektive semantische Signal beträgt nicht 100 %, sondern ca. 80 %. Die Kosinus-Ähnlichkeit mit einer korrekten Anfrage sinkt proportional.

Sie sinkt nicht auf Null – kann aber unter den Schwellenwert für das Top-k-Retrieval fallen. Wenn Sie nach den Top-5-Chunks suchen, kann ein verschobener Chunk auf Position 6 oder 7 landen – und nie in den Kontext der LLM gelangen.

Anschauliche Illustration: Fall eines Anwalts mit AskYourDocs

Wir kehren zum Fall aus dem vorherigen Artikel der Serie zurück, analysieren ihn aber auf Vektorebene.

Der Mandant – ein Anwalt mit Spezialisierung auf Baurecht – schickte 21 Seiten aus einem gescannten Archiv. Die meisten Seiten waren um 90°, 180° oder 270° gedreht gescannt. Standard-OCR ohne Ausrichtungskorrektur las sie wie folgt:

аМЫМ "9a18 40 S¥3IAVT ONIHLY3HS N33ML3E NOILD¥¥LSNOO

Dieser Müll gelangte als gültiger Text in die Vektordatenbank. Was mit den Vektoren geschah:

Von den 21 Seiten wurden 5–6 normal indiziert. Der Rest existierte in der Vektordatenbank als statistisches Rauschen – er belegte Platz, lieferte aber kein nützliches Retrieval. Gleichzeitig meldete das System kein Problem: Es gab Ergebnisse zurück, nur von 5–6 Seiten statt von 21.

Genauigkeit der Antworten auf Testfragen: 17 %. Nach der Einführung von Vision OCR mit automatischer Ausrichtungskorrektur: 50 % – auf demselben problematischen Dokument.

Warum ein semantisch relevanter Chunk nicht im Retrieval landet

Selbst wenn ein Chunk semantisch korrekt ist – er kann aufgrund mehrerer mit OCR-Rauschen verbundener Mechanismen nicht in den Retrieval-Ergebnissen erscheinen.

Szenario 1: Schlüsselwort verfälscht – Suche stimmt nicht überein

Anfrage: „Welche Haftung für die Verletzung von Fristen?“
Chunk in der Datenbank: „...Haftung für die Verletzung von Fristen – eine Strafe von 0,1 % für jeden Tag...“

Selbst wenn das Embedding-Modell verfälschte Wörter über Subword-Tokens teilweise „versteht“ – die Kosinus-Ähnlichkeit zwischen dem Anfragevektor und dem Chunk-Vektor wird niedriger sein als ideal. Wenn Ihr Index 50 andere Chunks über „Haftung“ mit sauberem Text enthält – wird der verfälschte Chunk unter dem Schwellenwert landen und nicht in die Top-k gelangen.

Szenario 2: Chunk durch Müll zu Irrelevanz „verdünnt“

Chunk B enthält dieselbe Information, aber: „ЗО“ statt „30“ (Kyrillisch statt Ziffer), ein zusammengewachsener Zeilenumbruch „змо-менту“, Müll „..;;..“ am Ende. Sein Vektor unterscheidet sich vom Vektor von Chunk A. Die Anfrage „Frist der Erfüllung 30 Tage“ wird besser mit A als mit B übereinstimmen – obwohl beide denselben Inhalt tragen.

Szenario 3: Das richtige Dokument ist vorhanden, aber nicht in den Top-k

Das gefährlichste Szenario. Ein relevanter Chunk existiert im Index – aber aufgrund eines verschobenen Vektors befindet er sich auf Position 8 oder 12, nicht in den Top-5. Die LLM erhält 5 weniger relevante Chunks und antwortet entweder auf Basis unvollständiger Informationen oder halluziniert.

Dabei sehen die Logs korrekt aus: Das Retrieval hat k Ergebnisse zurückgegeben, die LLM hat eine Antwort generiert. Es gibt kein Signal für das Problem – nur eine falsche Antwort.

Szenario 4: False-Positive-Retrieval – Müll mit hoher Ähnlichkeit

Das Gegenteil: Ein Müll-Chunk von einer umgedrehten Seite gelangt aufgrund zufälliger Token-Übereinstimmungen in die Top-k. Die LLM erhält einen unlesbaren Kontext und ignoriert ihn entweder (gutes Szenario) oder versucht, eine Antwort auf Basis des Mülls zu erstellen (schlechtes Szenario).

Recall und Precision in RAG nach schlechtem OCR: Metriken und Beispiele

Zur Bewertung der Retrieval-Qualität werden zwei grundlegende Metriken verwendet:

• Recall@k – der Anteil relevanter Dokumente, die in die Top-k-Ergebnisse gelangt sind. Wenn es 3 relevante Chunks gibt und alle 3 in den Top-5 sind, ist Recall@5 = 1.0.
• Precision@k – der Anteil relevanter unter den zurückgegebenen. Wenn in den Top-5 2 relevante und 3 irrelevante sind, ist Precision@5 = 0.4.

Wie OCR-Rauschen diese Metriken beeinflusst

Beispielmessung: Test mit realen Fragen

Eine praktische Methode zur Messung des Einflusses von OCR auf den Recall ist die Vorbereitung eines Satzes von Fragen, deren Antworten Sie genau kennen, und die Überprüfung, ob die benötigten Chunks im Retrieval erscheinen.

20–30 solcher Fragen auf einer repräsentativen Stichprobe des Archivs liefern ein weitaus genaueres Bild als jeder synthetische Benchmark.

Praktische Verbesserungsmethoden: Vorverarbeitung, Nachbearbeitung, Auswahl der OCR-Engine

Im Folgenden sind konkrete Aktionen aufgeführt, die einen messbaren Effekt haben. Unterteilt nach Einflussstufen.

Stufe 1: Bildvorverarbeitung (vor OCR)

Stufe 2: Textnachbearbeitung (nach OCR, vor Chunking)

Dies ist die effektivste und am meisten unterschätzte Stufe. Die Nachbearbeitung ist günstiger als ein erneuter OCR-Lauf und hat einen messbaren Effekt auf das Retrieval.

Garbage Detector: Praktische Implementierung

Der Garbage Detector ist eine einfache, aber sehr effektive Komponente. Logik:

Stufe 3: Auswahl der OCR-Engine

Auswahlstrategie: Entscheidungsbaum

Wann OCR nicht ausreicht und ein Vision-Ansatz benötigt wird

Selbst eine perfekt konfigurierte OCR-Pipeline hat systemische Einschränkungen. Es gibt eine Klasse von Dokumenten, bei denen keine Vorverarbeitungsverbesserung ein zufriedenstellendes Ergebnis für RAG liefert.

Hybride Pipeline: Praktische Architektur

Die optimale Strategie für die meisten realen Archive ist nicht „OCR oder Vision“, sondern Routing:

Eingehendes Dokument
  │
  ├─► Textschicht? ──► Ja ──► Nativer Parser (PyMuPDF) ──► Chunking
  │
  └─► Nein (Scan)
        │
        ├─► Vorverarbeitung (Ausrichtung, Schräglagenkorrektur, Rauschunterdrückung)
        │
        ├─► OCR (Tesseract / PaddleOCR)
        │
        ├─► Garbage Detector
        │        │
        │        ├─► Qualität OK ──► Nachbearbeitung ──► Chunking
        │        │
        │        └─► Qualität niedrig ──► Vision OCR (GPT-4o-mini)
        │                                    │
        │                                    └─► Nachbearbeitung ──► Chunking
        │
        └─► Protokollierung: Seite, CER-Schätzung, Verarbeitungspfad
  

Dieser Ansatz ermöglicht die Verarbeitung von 80–90 % der Dokumente über eine kostengünstige, selbst gehostete OCR und leitet nur problematische Seiten an Vision OCR weiter. Die Kosten für Vision OCR sinken bei dieser Strategie um das 5- bis 10-fache im Vergleich zu einem vollständigen Übergang.

Was Vision OCR nicht löst

Der Vision-Ansatz ist keine universelle Lösung. Einschränkungen:

• Kosten bei großen Volumina: 100.000 Seiten über GPT-4o-mini – ca. 1.500–3.000 $.
• Latenz: API-Aufrufe dauern 2–10 Sekunden pro Seite. Für Echtzeitsysteme inakzeptabel.
• Rate Limits: Ohne Enterprise-Zugang ist die parallele Verarbeitung eines großen Archivs eingeschränkt.
• DSGVO: Dokumente werden an einen externen Anbieter gesendet. Erfordert DPA und kann durch Compliance-Richtlinien blockiert werden.
• VLM-Halluzinationen: Bei stark beschädigten Dokumenten kann VLM nicht lesbaren Inhalt „erfinden“. Erfordert Validierung.

Ein detaillierter Vergleich von OCR-first und Vision-first Architekturen mit Trade-off-Analyse finden Sie im nächsten Artikel der Serie: „Vision RAG vs OCR: Vergleich von Dokumentenverarbeitungsansätzen“.

Schlussfolgerungen

Die Verschlechterung von RAG durch schlechte OCR ist kein Problem des Modells. Es ist ein technisches Problem der Eingabedaten, das konkrete Korrekturpunkte hat.

Wo genau bricht die Pipeline – und was ist dagegen zu tun

Priorisierte Reihenfolge der Maßnahmen

Wenn Sie jetzt RAG auf gescannten Dokumenten starten oder optimieren – hier ist die Reihenfolge mit dem größten ROI:

1. Archiv-Audit – welcher Anteil sind Scans? Gibt es umgedrehte Seiten? Was ist die typische Qualität?
2. Ausrichtungskorrektur hinzufügen – auch wenn die meisten Seiten normal sind, kostet eine umgedrehte Seite in einem kritischen Dokument viel.
3. Basis-Nachbearbeitung hinzufügen – Leerzeichen-Normalisierung, Zusammenfügen von Zeilenumbrüchen, Entfernen von Müllzeilen. Lässt sich in wenigen Stunden implementieren, hat einen messbaren Effekt auf das Retrieval.
4. Testdatensatz mit Fragen erstellen – 20–30 Fragen mit bekannten Antworten. Messen Sie Recall@5 vor und nach jeder Änderung.
5. Garbage Detector hinzufügen und Weiterleitung an Vision OCR für problematische Seiten.
6. Erst danach – Chunking-Parameter, Embedding-Modelle, Reranker optimieren.

Schritte 1–3 bringen mehr Effekt als die Änderung eines Embedding-Modells von 1536 auf 3072 Dimensionen. Aber die meisten Teams beginnen mit Schritt 6 – und wundern sich, warum sich das Ergebnis nicht verbessert.