OCR mit KI: Warum unser Sprachmodell ein „nicht“ gestrichen hat

TL;DR: Zehn Testseiten, zwei Scanner, strenge Messung: Saubere Scans in Graustufen oder Farbe liest Tesseract zu rund 86 % aller Felder exakt, so gut wie eine digitale Vorlage. Jedes siebte Feld bleibt trotzdem falsch, bei Seriennummern fast jedes. Schwarzweiß oder ein Staubkorn im Einzug kosten je etwa 8 Punkte. Ein lokales Sprachmodell als „Galgenmännchen“ flickt einzelne Wörter, erfindet aber auch plausible falsche und hat in unserem Test ein „nicht“ aus einer Vertragsklausel gestrichen. Die Klausel bedeutete danach das Gegenteil. Faustregel: Wo der Satz die Lösung erzwingt, darf das Modell vorschlagen. Bei Beträgen, Nummern und Verneinungen prüft ein Algorithmus.

Drei Zahlen aus dem Test

~86 % Felder exakt richtig bei Farbe oder Graustufen: Niveau der digitalen Vorlage, aber jedes siebte Feld falsch.

~8 Punkte Verlust durch Schwarzweiß oder ein Staubkorn im Einzug.

1 Wort: Das Modell strich ein korrekt gelesenes „nicht“ und drehte damit eine Vertragsklausel um.

Gemessen an 387 Feldern, nur exakte Treffer zählen. Testsatz und richtige Texte zum Nachmachen finden Sie im Abschnitt zum Testaufbau.

Ohne Daten keine KI

Viele Unternehmen möchten KI nutzen, eine Wissensdatenbank aufbauen oder Agenten an ihre Dokumente lassen. Oft scheitert das an etwas Banalem: Die Dokumente liegen auf Papier, in Ordnern oder als Scans ohne lesbaren Text. Bevor eine KI etwas mit Rechnungen, Lieferscheinen oder Verträgen anfangen kann, muss jemand sie digitalisieren.

Das geht heute vollständig im eigenen Haus. Wir testen dafür paperless-ngx, ein freies Dokumentenmanagement, das Scans entgegennimmt, den Text erkennt, Dokumente zuordnet und durchsuchbar macht. Die Texterkennung (OCR) übernimmt dort das freie Programm Tesseract, in unserer Installation in Version 5.5. Kein Dokument verlässt dabei das Netz. Wie das zu unserer Sicht auf lokale KI im Unternehmen passt, steht dort.

Die Frage ist nur: Wie gut ist diese Texterkennung wirklich? Und kann eine KI die Fehler danach reparieren? Wir haben es gemessen.

Der Testaufbau

Wir haben einen Testsatz aus zehn Seiten erstellt, alle Inhalte frei erfunden:

• eine Rechnung mit Tabelle und Beträgen
• einen Lieferschein mit Artikelnummern in Schreibmaschinenschrift
• einen Geschäftsbrief mit Umlauten
• eine Preisliste in 7 Punkt Schriftgröße
• ein Formular mit Kästchen
• eine Buchungsliste mit Plus- und Minusbeträgen
• einen zweispaltigen Text
• eine Inventarliste mit Seriennummern, die 0 und O, 1, l und I mischen
• Kleingedrucktes in 6 Punkt
• eine Seite mit Handschrift

Für jede der 387 gedruckten Textzeilen und Tabellenzellen auf den neun Druckseiten wissen wir genau, was dort steht. Gemessen haben wir streng: Ein Feld zählt nur, wenn es exakt richtig erkannt wurde. Ein einziges falsches Zeichen, und das Feld gilt als falsch. Bei einer Rechnungsnummer oder IBAN ist das die einzige sinnvolle Messung. Zusätzlich haben wir gezählt, wie viele Wörter richtig ankamen.

Gescannt habe ich die ausgedruckten Seiten mit zwei Geräten: einem Multifunktionsgerät OKI MC363 und einem Dokumentenscanner Fujitsu fi-7260, beide über den automatischen Einzug. Dazu kamen verschiedene Modi (Farbe, Graustufen, Schwarzweiß), Auflösungen (200 und 300 dpi) und beim Fujitsu die Texterkennung aus der Herstellersoftware PaperStream Capture (Version 6.0.2.3).

Den Testsatz können Sie selbst verwenden: Testsatz als PDF und die richtigen Texte als JSON-Datei. Drucken, scannen, vergleichen.

Ergebnis 1: Der Modus schlägt das Gerät

Als Vergleichswert haben wir die Testseiten zusätzlich digital in ein Bild umgewandelt und ebenso auswerten lassen, also ohne Papier, Drucker und Scanner. Diesen Idealfall erreichen die Scans in Farbe und Graustufen praktisch vollständig, und zwar auf beiden Geräten: 86,3 % beim Multifunktionsgerät, 85,5 % beim Dokumentenscanner. Beim Dokumentenscanner in Graustufen kamen Fließtext, Formular und zweispaltiger Text zu 100 % richtig an, die Buchungsliste zu 99 %, die Preisliste in 7 Punkt zu 96 %.

Schwarzweiß kostet rund 8 Punkte. Im Schwarzweißmodus entscheidet der Scanner für jeden Bildpunkt hart zwischen schwarz und weiß. Dabei gehen die Zwischentöne verloren, aus denen die Texterkennung Buchstabenkanten rekonstruiert. Mehr Auflösung gleicht das nicht aus: 200 und 300 dpi lieferten in Schwarzweiß dasselbe Ergebnis.

Ein Staubkorn im Einzug kostet genauso viel. Beim ersten Scan zog sich ein feiner senkrechter Strich über alle zehn Seiten. Die Ursache: ein Staubkorn im Einzug, an der Stelle, an der das Papier am Sensor vorbeiläuft. Der Strich schnitt an derselben Stelle jeder Zeile Buchstaben durch.

Aus „vielen Dank“ wurde „vielen pene“, aus „Sicherungsläufe“ wurde „Siche ngsläufe“. Der gesamte Scan fiel von 86 auf 79 %. Niemand hätte das bemerkt, ohne nachzumessen.

Herstellersoftware und Tesseract liegen gleichauf, mit einer Ausnahme. In Graustufen erkannten PaperStream Capture und Tesseract praktisch gleich viele Felder. Bei den Seriennummern lag die Herstellersoftware aber klar vorn: 11 von 31 richtig, Tesseract nur 1 von 31. Langsamer wurde der Scanner durch die eingeschaltete Texterkennung bei unseren zehn Seiten übrigens nicht spürbar.

Die Grenzen sind bei allen gleich: Kennungen, die 0 und O oder 1, l und I mischen, Kleingedrucktes in 6 Punkt und Handschrift.

Unser eigener Messfehler: Beim ersten Durchgang des 300-dpi-Scans kamen wir auf nur 51 %. Die Ursache lag bei uns: Beim Herausziehen der Seitenbilder aus dem PDF ging die Angabe der Auflösung verloren, Tesseract schätzte die Schriftgröße falsch und zerlegte die Tabellen. Mit korrekter Auflösung waren es 77,5 %. paperless-ngx ist davon nicht betroffen, weil es die Auflösung direkt aus dem PDF liest. Wir erwähnen das trotzdem, denn genau solche Fehler im Testaufbau verfälschen Messungen, ohne dass man es merkt.

Ergebnis 2: Galgenmännchen mit einem Sprachmodell

Die naheliegende Idee: Die Texterkennung liefert Bruchstücke wie „vielen pene“, und ein Sprachmodell setzt die fehlenden Buchstaben ein, so wie beim Galgenmännchen. Sprachmodelle berechnen, welches Wort an einer Stelle am wahrscheinlichsten passt. Genau diese Eigenschaft, sonst als „Halluzination“ gefürchtet, soll hier helfen. Fachlich nennt man das Post-OCR-Korrektur.

Wir haben das mit einem kleinen, lokal laufenden Modell getestet: Qwen3.5-2B, auf einem gewöhnlichen Rechner ohne Grafikkarte, 40 Sekunden bis wenige Minuten pro Seite. Als Eingabe diente der Scan mit dem Staubkorn-Streifen, denn dort gab es am meisten zu reparieren.

Erster Versuch, mit Vorsicht: „Korrigiere nur offensichtliche Fehler, erfinde nichts.“ Ergebnis: Das Modell hat im Fließtext kein einziges Feld repariert. „vielen pene“ blieb stehen. Die Bitte, nichts zu erfinden, verhindert eben auch das Galgenmännchen. Und mehr als eine Bitte ist eine Anweisung im Prompt nicht: Dass das Modell sie hier so strikt befolgt hat, ist eher Zufall, darauf kann man sich nicht verlassen. Wie wenig, zeigt das „nicht“ weiter unten: Dasselbe Modell hat mit genau dieser Bitte einen Satz verändert, der schon richtig war.

Zweiter Versuch, ohne diese Bremse: „Ergänze fehlende Buchstaben, setze zerschnittene Wörter zusammen.“ Jetzt wurde es interessant:

Wo der Satz genau eine Lösung zulässt, trifft das Modell. Wo mehrere Wörter passen könnten, erfindet es ein plausibles, und das klingt so richtig, dass beim Lesen niemand stutzt.

Das „nicht“

Auf der Seite mit dem Kleingedruckten stand eine Abnahmeklausel: Leistungen gelten als abgenommen, „wenn der Auftraggeber nicht binnen 14 Tagen schriftlich widerspricht“. Die Texterkennung hatte diesen Satz richtig gelesen.

Das Sprachmodell hat das „nicht“ gestrichen, in beiden Varianten, auch in der vorsichtigen. Übrig blieb: „wenn der Auftraggeber binnen 14 Tagen schriftlich widerspricht“. Damit bedeutet die Klausel das Gegenteil.

Ein Wort, fünf Buchstaben, und aus einer Abnahme durch Schweigen wird eine Abnahme durch Widerspruch. Das Modell hat nicht nur Lücken gefüllt, sondern auch einen Satz „geglättet“, der schon richtig war.

Serien- und Artikelnummern hat das Modell praktisch gar nicht repariert: 1 von 43 Kennungen. Bei einer Seriennummer gibt es keinen Satz, aus dem sich das fehlende Zeichen ergibt. Insgesamt stieg der Anteil exakt richtiger Felder auf den getesteten Seiten von 54 auf 60 %. Der Anteil richtiger Wörter sank dagegen von 84 auf 65 %, weil das Modell auf unruhigen Seiten Inhalte weglässt oder umbaut.

Überrascht hat uns ein Gegentest. Wir haben den Brief und den zweispaltigen Text zusätzlich ins Englische übertragen und denselben Streifen an fünf Stellen eingefügt, in beiden Sprachen an exakt derselben Position. Erwartet hatten wir, dass das Modell im Englischen deutlich besser repariert, schließlich sind englische Texte in den Trainingsdaten solcher Modelle stark vertreten. Das war nicht so: In beiden Sprachen reparierte es rund jede vierte kaputte Zeile, 24 % auf Deutsch, 23 % auf Englisch. Den Unterschied machte nicht die Sprache, sondern die Seltenheit der Wörter. Seltene Wörter, vor allem lange deutsche Zusammensetzungen wie „Wiederherstellungsprobe“ oder „Sicherungsläufe“, hat das Modell in unseren Läufen kein einziges Mal repariert, häufige Wörter dagegen in etwa jedem zweiten Fall. Woran genau das liegt, lässt sich von außen nicht klären. Die Modellkarte nennt Unterstützung für 201 Sprachen, aber nicht, mit welchen Daten und Verfahren das Modell trainiert wurde. Die Gewichte sind frei verfügbar, das Training dahinter ist es nicht.

Eine Einschränkung gehört dazu: Wir haben ein kleines Modell mit rund 2 Milliarden Parametern getestet, das auf einem gewöhnlichen Rechner läuft. Große Modelle würden wahrscheinlich deutlich mehr Lücken richtig füllen. Das Grundproblem bleibt aber auch bei ihnen: Was sie einsetzen, ist das Wahrscheinliche, nicht zwingend das Richtige, und ein plausibles falsches Wort fällt beim Lesen nicht auf.

Ergebnis 3: Handschrift

Auf der letzten Seite habe ich fünf Zeilen von Hand abgeschrieben. Tesseract und die Scanner-Software lieferten daraus nur Zeichensalat. Das ist erwartbar, beide sind für Druckschrift gebaut.

Das Sprachmodell kann auch Bilder lesen. Unser erster Versuch ergab fünf von fünf Zeilen exakt richtig, verdächtig gut. Die Erklärung: Über jeder handschriftlichen Zeile stand die gedruckte Vorlage, und das Modell hatte schlicht die Druckschrift abgelesen. Beweis: Ich hatte von Hand „14.30 Raum 3“ geschrieben, das Modell lieferte „14:30 Uhr, Raum 3“, wie im Druck. Ein Test, bei dem die Antwort im Bild liegt, misst Abschreiben, nicht Lesen.

Im zweiten Versuch bekam das Modell nur die handschriftlichen Zeilen zu sehen:

Die Zahlen las das Modell fast fehlerfrei: Angebotsnummer, Datum, Uhrzeit, Betrag. Die Wörter dagegen hat es teils durch plausible andere ersetzt. Bei Handschrift dreht sich die Faustregel also teilweise um: Ziffern haben eine eindeutige Form, Wörter werden aus Bruchstücken erraten. Ein größeres Modell, das mehr deutsche Wörter kennt, dürfte hier wahrscheinlich besser abschneiden.

Die Faustregel: Kontext entscheidet

flowchart LR
    S["Scan<br/>Graustufen"] --> O["OCR"] --> K{"Art der<br/>Stelle"}
    K -->|"Fließtext"| M["Modell<br/>schlägt vor"] --> V{"nicht oder<br/>Ziffer geändert?"}
    V -->|"ja"| X["verwerfen"]
    K -->|"Betrag, IBAN"| A["Algorithmus<br/>prüft"]
    K -->|"Seriennummer"| N["Formatregel,<br/>Stammdaten"]
    style V stroke:#cc171a,stroke-width:2.5px
    style X stroke:#cc171a,stroke-width:2.5px

Wie gut solche langweiligen Algorithmen sind, zeigt die IBAN: Ihre Prüfziffern ergeben sich aus einer Rechnung modulo 97. Wir haben in der Beispiel-IBAN unseres Testsatzes jede Ziffer einzeln durch jede andere ersetzt, 180 Varianten. Die Prüfung hat alle 180 als falsch erkannt. Ein Sprachmodell kann das nicht leisten, eine Zeile Code schon.

Wichtig ist, wo die Grenzen gezogen werden. Im Prompt haben sie in unserem Test entweder alles verhindert oder nichts. Verlässlich sind Grenzen im Code: Das Modell darf nur Wörter ersetzen, die nicht im Wörterbuch stehen. Verneinungen wie „nicht“ und „kein“ sowie alle Ziffern sind tabu. Jede Änderung wird als Unterschied angezeigt, statt still übernommen zu werden. Dasselbe Prinzip beschreiben wir für KI-Agenten in KI-Agenten an der eigenen Infrastruktur: So setzen Sie Grenzen. Warum ein Modell grundsätzlich das Wahrscheinliche statt des Richtigen wählt, zeigt Deterministisch oder probabilistisch: Wann KI, wann Algorithmus?

Welche Stellen Ihrer Dokumente darf ein Modell anfassen, welche prüft Code?

Wir richten die Texterkennung für Ihre Ablage ein und legen fest, wo ein Sprachmodell vorschlagen darf und wo Prüfziffern, Formatregeln und Stammdaten entscheiden. So landet kein still geändertes „nicht“ in Ihrem Archiv.

Sprechen Sie uns an

Praxistipps fürs Digitalisieren

1. Graustufen statt Schwarzweiß. Das brachte in unserem Test rund 8 Punkte, die Dateien werden etwas größer.
2. 200 bis 300 dpi reichen für normale Schriftgrößen.
3. Den Einzug regelmäßig reinigen. Ein Staubkorn reicht für einen Strich über jede Seite.
4. Mit einer Handvoll Testseiten selbst messen. Ein Scan sieht auch dann gut aus, wenn die Texterkennung schlecht ist. Unseren Testsatz können Sie dafür verwenden.
5. Kennungen nicht blind übernehmen. Seriennummern und Artikelnummern mit 0/O und 1/l/I sind die Schwachstelle aller getesteten Verfahren.
6. Sprachmodelle nur mit Prüfung einsetzen. Vorschläge markieren, nicht still übernehmen.
7. Die Textebene prüfen, bevor eine KI sie liest. Text aus dem PDF kopieren und mit dem Bild vergleichen, vor allem bei Beträgen, Fristen und Nummern. Viele KI-Werkzeuge lesen nur diese Textebene, nicht das Bild.

Häufige Fragen

Brauche ich einen Dokumentenscanner, oder reicht ein Multifunktionsgerät? Für die Qualität der Texterkennung kaum ein Unterschied, wenn der Modus stimmt: Beide Geräte erreichten in Farbe bzw. Graustufen das Niveau einer digitalen Vorlage. Ein Dokumentenscanner lohnt sich vor allem für Tempo, große Stapel und zuverlässigen Einzug.

Schwarzweiß oder Graustufen? Graustufen. Schwarzweiß kostete in unserem Test auf beiden Geräten rund 8 Punkte, auch bei 300 dpi.

Kann KI Handschrift lesen? Teilweise. Ein kleines lokales Modell las Zahlen in Handschrift fast fehlerfrei, ersetzte aber Wörter durch plausible andere. Für Notizen zum Durchsuchen hilfreich, für Verbindliches nur mit Kontrolle.

Darf eine KI OCR-Fehler automatisch korrigieren? Mit Kontext und Markierung ja. Bei Beträgen, Nummern und Verneinungen nur mit Prüfung, denn ein plausibles falsches Wort fällt beim Lesen nicht auf.

Fazit

Lokale Texterkennung liest saubere Scans in Graustufen so gut wie eine digitale Vorlage. Das heißt aber auch: Selbst im besten Fall war rund jedes siebte Feld nicht exakt richtig, bei Seriennummern fast jedes. Für die Volltextsuche in einer Ablage reicht das, für die ungeprüfte Übernahme von Rechnungsdaten nicht.

Ein Sprachmodell als Galgenmännchen hat in unserem Test nur wenige Lücken richtig gefüllt. Dafür hat es plausible falsche Wörter eingesetzt, Inhalte weggelassen und ein „nicht“ gestrichen, das die Texterkennung richtig gelesen hatte. Besondere Vorsicht ist bei KI-Werkzeugen geboten, denen man einfach ein PDF hochlädt, gerade bei kostenlosen. Viele davon schauen sich nicht das Bild der Seite an, sondern verarbeiten nur die Textebene, die eine Texterkennung zuvor erzeugt hat. Ist diese fehlerhaft, arbeitet die KI mit falschen Daten, obwohl das PDF auf dem Bildschirm einwandfrei aussieht. Wer mit gescannten Dokumenten arbeitet, sollte die Texterkennung deshalb stichprobenartig prüfen, bevor eine KI darauf aufbaut.

Unterm Strich: Texterkennung ja, Sprachmodell höchstens als markierter Vorschlag, und die Prüfung bleibt Pflicht.

Die Idee, das nächste Zeichen aus Wahrscheinlichkeiten vorherzusagen, ist übrigens über hundert Jahre alt. Der Mathematiker Andrei Markow beschrieb 1906 die nach ihm benannten Ketten und zählte 1913 in Puschkins „Eugen Onegin“ von Hand aus, wie oft auf einen Vokal ein Konsonant folgt. Heutige Sprachmodelle schauen auf viel mehr als den letzten Buchstaben, aber das Prinzip ist dasselbe: Sie wählen das Wahrscheinliche. Ob es auch das Richtige ist, muss jemand anderes prüfen.

Sie möchten Ihre Papierablage digitalisieren und danach mit lokaler KI durchsuchbar machen? Mehr zu lokaler KI für Unternehmen, oder sprechen Sie uns direkt an.

Quellen: paperless-ngx (Projektseite) · Tesseract OCR (GitHub) · Qwen3.5-2B (Hugging Face) · Wolfram Blog – Centennial of Markov Chains