Gescannte Dokumente und OCR für KI: Warum Scans scheitern und wie Sie sie reparieren

Gescannte Dokumente sind der Albtraum vieler RAG-Projekte: ein Vertrag als Foto vom alten Faxgerät, ein Formular mit handschriftlichen Vermerken, eine Tabelle, die beim Einscannen leicht schräg lag. Eine KI kann nur das finden und zitieren, was die OCR-Engine vorher korrekt aus dem Bild gelesen hat. Dieser Artikel zeigt, warum Scans scheitern, wie Sie OCR-Qualität objektiv bewerten, und wie Sie die Extraktion prüfen, bevor Sie überhaupt mit dem Indexieren beginnen.

Warum gescannte Dokumente eine eigene Kategorie sind

Ein normales PDF, das aus Word oder einer Textverarbeitung exportiert wurde, enthält echten Text: Buchstaben, die eine Maschine direkt auslesen kann. Ein Scan dagegen ist zunächst nur ein Bild, egal ob es wie ein PDF aussieht. Erst die optische Zeichenerkennung (OCR) verwandelt die Pixel in Buchstaben. Jeder Fehler, den die OCR dabei macht, wandert unbemerkt in die nächsten Schritte: Chunking, Embeddings, Suche und am Ende in die Antwort, die Ihre KI einem Nutzer präsentiert. Ein falsch erkanntes „1990“ statt „1999“ in einem Vertrag fällt niemandem auf, bis jemand sich auf die Antwort verlässt.

Das Problem betrifft praktisch jede Branche mit historisch gewachsenen Archiven: eingescannte Rechnungen, alte Gutachten, Behördenschreiben, unterschriebene Verträge, technische Zeichnungen mit Legenden. Wer eine Wissensdatenbank auf solchen Dokumenten aufbaut, muss OCR als eigenen Qualitätsschritt behandeln, nicht als Formalität nebenbei.

Warum Scans scheitern: die häufigsten Ursachen

• Schiefe oder gedrehte Scans: Die OCR-Engine liest Zeilen in die falsche Richtung oder vermischt Spalten.
• Niedrige Auflösung: Unter etwa 200-300 dpi werden Buchstaben wie „rn“ und „m“ oder „O“ und „0“ leicht verwechselt.
• Kopie von einer Kopie: Jede weitere Fotokopie verstärkt Kontrastverlust und Rauschen, besonders bei Faxarchiven.
• Handschriftliche Vermerke: Klassische OCR ist für Druckschrift trainiert, Handschrift wird oft ignoriert oder falsch gelesen.
• Mehrspaltige Layouts: Zeitungsartikel-ähnliche Spalten werden ohne Layout-Erkennung quer durcheinandergewürfelt.
• Stempel, Unterschriften und Wasserzeichen: Sie überlagern Text und erzeugen zufällige Zeichenketten.
• Tabellen mit Linien oder ohne Linien: Zellgrenzen gehen verloren, Zahlen rutschen in die falsche Spalte.
• Formulare mit Kästchen und Freitextfeldern: Die Struktur (Feldname, Wert) wird zu einem einzigen Textblock ohne Bedeutung.

OCR-Qualität bewerten, bevor Sie indexieren

Die meisten OCR-Engines liefern neben dem erkannten Text auch einen Konfidenzwert pro Wort oder Zeile. Dieser Wert ist Ihr wichtigstes Werkzeug, um Problemdokumente automatisch herauszufiltern, bevor sie in der Wissensdatenbank landen. Ein Dokument mit durchgehend niedriger Konfidenz braucht einen Rescan, eine bessere Vorlage oder manuelle Nachbearbeitung, keine blinde Indexierung.

Tabellen und Formulare: der Sonderfall

Fließtext ist für OCR vergleichsweise einfach. Tabellen und Formulare sind es nicht, weil die Bedeutung eines Werts von seiner Position abhängt, nicht nur vom Zeichen selbst. Eine Zahl in der Spalte „Nettobetrag“ bedeutet etwas anderes als dieselbe Zahl in der Spalte „Mehrwertsteuer“. Reine Texterkennung ignoriert diese Struktur und liefert eine Zeichenkette ohne Zusammenhang. Für belastbare Ergebnisse brauchen Sie entweder eine layoutbewusste Extraktion, die Zellen und Spalten erkennt, oder eine nachgelagerte Regel, die Tabellenwerte explizit mit ihrer Spaltenüberschrift verknüpft, bevor der Text gechunkt wird. Bei Formularen gilt Ähnliches: Feldname und Wert sollten als Paar erhalten bleiben, sonst verliert ein Modell später den Bezug zwischen „Geburtsdatum“ und dem danebenstehenden Datum.

Wenn Sie ohnehin über Chunking-Strategien nachdenken, lohnt sich ein Blick in unseren Artikel zu Chunking-Strategien für RAG: Tabellen und Formulare brauchen oft eine strukturbewusste Aufteilung statt fester Zeichenlängen, sonst reißt die OCR-Ausgabe an der falschen Stelle auseinander.

Daten bereinigen nach der OCR

Selbst eine gute OCR-Engine liefert Rohtext, der vor dem Indexieren eine Bereinigung braucht. Diese Schritte kosten wenig Aufwand, verbessern aber die Trefferqualität spürbar:

• Silbentrennungen am Zeilenende zusammenführen (z. B. „Ver-\ntrag“ wieder zu „Vertrag“).
• Wiederholte Kopf- und Fußzeilen entfernen, die sonst auf jeder Seite als Rauschen erscheinen.
• Doppelte Leerzeichen und überflüssige Zeilenumbrüche normalisieren.
• Seitenzahlen und Scan-Artefakte wie einzelne Sonderzeichen am Seitenrand herausfiltern.
• Sprachkonsistenz prüfen, besonders bei mehrsprachigen Archiven mit deutschen und fremdsprachigen Dokumenten.
• Erkannte Tabellen in ein konsistentes Format bringen, bevor sie gechunkt werden.

Diese Bereinigung entscheidet oft mehr über die spätere Antwortqualität als die Wahl des Embedding-Modells. Ein Modell kann nur mit dem arbeiten, was tatsächlich im Index steht, und bei hybrider Suche aus Volltext und semantischer Erweiterung schlagen Tippfehler aus der OCR doppelt zu Buche. Mehr dazu, warum beide Suchformen zusammen stabilere Treffer liefern, finden Sie in Hybrid Search: Warum BM25 und Vektorsuche gemeinsam RAG-Abrufe gewinnen.

Extraktion prüfen, bevor Sie live gehen

Eine Wissensdatenbank aus gescannten Dokumenten sollte nie ungeprüft live gehen. Die folgende Checkliste eignet sich für den letzten Schritt vor der Veröffentlichung, egal ob intern für ein Team oder öffentlich im Katalog:

1. Stichprobe ziehen: 10-20 Dokumente zufällig auswählen und den extrahierten Text gegen das Original lesen.
2. Problemdokumente gezielt prüfen: Die am schlechtesten gescannten Dokumente (Fax, alte Kopien) zuerst kontrollieren, nicht die saubersten.
3. Testfragen stellen: Konkrete Fragen formulieren, deren Antwort Sie aus dem Original kennen, und prüfen, ob die KI die richtige Passage zitiert.
4. Tabellen gezielt testen: Fragen stellen, die eine Tabellenzeile betreffen, und prüfen, ob Spalte und Wert korrekt zugeordnet werden.
5. Zahlen und Daten besonders kontrollieren: OCR verwechselt Ziffern häufiger als Buchstaben, Beträge und Fristen verdienen eine zweite Prüfung.
6. Monitoring einrichten: Auch nach dem Start regelmäßig Stichproben und Nutzerfeedback auswerten.

Von sauberer OCR zur durchsuchbaren Wissensdatenbank

Sobald die Extraktion stimmt, ist der nächste Schritt die eigentliche Indexierung für die Suche. Bei Kopik laden Sie Ihre Dokumente, auch gescannte PDFs, einfach hoch: Kopik extrahiert den Text, chunkt ihn sinnvoll und indexiert ihn für eine hybride Suche aus Volltext und semantischer Erweiterung. Sie können eine Wissensdatenbank kostenlos über die Datenbank-Erstellung anlegen, sie privat halten oder im Katalog veröffentlichen und pro Frage bezahlen lassen. Der Zugriff erfolgt wahlweise über die Website, eine REST-API mit API-Schlüsseln oder einen MCP-Server, den Sie direkt aus Cursor oder ChatGPT ansprechen können, Details dazu stehen in der Entwickler-Dokumentation.

Bei öffentlich bereitgestellten Archiven mit personenbezogenen Daten, etwa gescannten Personalakten oder Verträgen, lohnt sich zusätzlich ein Blick in unsere DSGVO-Checkliste für RAG, bevor Dokumente mit sensiblen Inhalten überhaupt hochgeladen werden.

Fazit: OCR ist ein Qualitätsschritt, kein Haken auf der Liste

Gescannte Dokumente sind in den meisten Unternehmen unvermeidbar, aber sie verdienen eine eigene Qualitätskontrolle, bevor sie in eine KI-Wissensdatenbank wandern. Wer Konfidenzwerte prüft, Tabellen und Formulare strukturbewusst behandelt, den Text bereinigt und vor dem Livegang gezielt testet, vermeidet die teuersten Fehler: falsche Zahlen, vertauschte Spalten und Antworten, die überzeugend klingen, aber auf einem Lesefehler beruhen. Mit KI-Halluzinationen vermeiden: So liefern Sprachmodelle belegte Antworten finden Sie ergänzend, wie Quellenangaben und Zitate solche Fehler auch für Nutzer sichtbar machen.