Wie LLMs die OCR-basierte Dokumentenanalyse revolutionieren

Einleitung

Unter OCR (Optical Character Recognition) versteht man einen bestimmten Prozess zur Digitalisierung von Texten, der Name rührt daher, dass der Computer anhand der Form (Optical) einzelner Zeichen (Character) erkennt, um welches Symbol es sich handelt und diese zu einem String zusammenfügt.
Dieser Prozess liegt den meisten offenen und kommerziellen Softwarelösungen für die Digitalisierung von Texten zugrunde. Zur Frustration eines Großteils der Entwickler und Anwender führt dieser Ansatz immer wieder zu Problemen: Ein nicht perfekter Scan, eine ungewöhnliche Schriftart oder gar eine schlechte Handschrift und die Ergebnisse lassen zu wünschen übrig.
Möchte man mehr einlesen als puren Fließtext, so ist ein nicht unerheblicher Entwicklungsaufwand notwendig, damit der Text entsprechend dem Layout oder der Struktur der Daten eingelesen wird. Eine weitere Quelle für Frustration ist, dass jedes Zeichen unabhängig von seinem Kontext verarbeitet wird. So ist es beispielsweise für jeden Leser offensichtlich, welches Zeichen hier fehlt:

für eine OCR Engine allerdings nicht.
Ist das Zeichen unklar geschrieben, wird es nicht richtig erkannt, egal in welchem Kontext es steht. Genau dieses kontextbezogene Verarbeiten ist seit der Entwicklung von LLMs auch für Computer möglich.
Moderne LLMs können zudem längst nicht mehr nur Text verarbeiten: Sogenannte Multimodale Modelle interpretieren eine Vielzahl von Formaten gleichzeitig.
Diese Umstände haben es ermöglicht, dass Modelle speziell dafür entwickelt und trainiert wurden, um Text zu digitalisieren. Diese Modelle teilen die Unzulänglichkeiten von klassischen OCR-Engines nicht, wie wir uns im Folgenden genauer ansehen werden.

Für unseren Vergleich stellen wir zwei Ansätze gegenüber:

1. Die 'klassische' Pipeline: Wir nutzen Tesseract, kombiniert mit den essenziellen Vorverarbeitungsschritten (via OpenCV), die es für eine saubere Texterkennung benötigt – primär die Umwandlung in ein klares Schwarz-Weiß-Bild (Binarisierung).
2. Die 'moderne' Pipeline: Wir verwenden das multimodale Modell dots.ocr, das wir auf einem unserer Server ausgerollt haben (Eine Anleitung dazu folgt in unserem nächsten Blogbeitrag).

Für beide Methoden werden die Roh-Ergebnisse nicht nachbearbeitet, um einen unverfälschten Vergleich zu ermöglichen. Die genauen Implementierungen sind zur Einsicht auf unserem GitHub hinterlegt.

Historische Daten

Bild generiert von Google Gemini

Beschädigte Dokumente

Eines der größten Probleme für Historiker sind gealterte Dokumente, die in vielen Fällen nicht einmal im Original vorliegen, um Beschädigungen zu vermeiden. Es ist für Historiker also durchaus üblich, mit nicht optimalen Fotografien von schlecht erhaltenen Dokumenten zu arbeiten. Das Beispiel, das wir hier verwenden werden, ist gut erhalten, das Alter des Dokuments ist allerdings deutlich erkennbar.

Historisches Dokument – Frankfurter Dokumente (Original Scan)

In diesem Beispiel ist der Unterschied zwischen der klassischen und der modernen Pipeline relativ gering,es ist aber bereits erkennbar, dass das LLM Fehler nicht macht, die wir bei der klassischen OCR finden. Beispielsweise finden wir im Ergebnis der klassischen OCR Stellen wie Gi ET In, DOKUMENT? NO" I oder &ine Verfanzunggebende, diese Stellen werden von dots.ocr korrekt als Frankfurt am Main, # DOKUMENT NO I und eine Verfassunggebende erkannt. Trotz des Alters des Dokuments ist der Scan von guter Qualität. Wenn wir nun, um einen schlechteren Scan zu simulieren, das Dokument um ein paar Grad drehen, verändert sich das Ergebnis drastisch.

Historisches Dokument – Frankfurt (Verdrehter Scan)

Die klassische Pipeline ist hier nicht mehr in der Lage, den Text zu erkennen und gibt eine leere Datei aus. Die moderne Pipeline allerdings liefert noch ein Ergebnis, das sich im Vergleich zu dem guten Scan zwar etwas verschlechtert hat, aber die Nacharbeit, die an dieser Datei zu leisten wäre, steht in keinem Vergleich zu dem Aufwand, den es bereiten würde, die klassische Pipeline so anzupassen, dass sie auch mit verdrehten Scans umgehen kann.

Kaufmännische Daten & Behördliche Prozesse

Bild generiert von Google Gemini

Sowohl im kaufmännischen Bereich als auch bei Behörden ist Struktur häufig genauso wichtig wie der Inhalt selbst. Im Kontext einer Excel-Tabelle beispielsweise liegt die Bedeutung nicht nur im Text, sondern auch in der Anordnung der Daten in Zeilen und Spalten. In abgeschwächter Form ist das auch bei Formularen wie Anträgen der Fall. Für diese Umstände existieren spezialisierte OCR-Engines, die den Arbeitsaufwand, eine Pipeline für ein spezifisches Tabellenformat oder ein spezifisches Formular aufzubauen, deutlich erleichtern. Dennoch ist der Arbeitsaufwand nicht trivial. Unsere moderne Lösung muss hier nicht angepasst werden, um einen Output zu generieren, der von ausreichender Qualität ist, um an anderer Stelle weiter verarbeitet zu werden. Wie im folgenden Beispiel einer Rechnung.

Beispielrechnung – Kaufmännische Struktur

Die Struktur der Daten geht bei der klassischen Lösung beinahe vollständig verloren. Für einen Menschen mag es noch nachvollziehbar sein, wie die Struktur in der Originaldatei einmal gewesen ist, aber für einen Computer ist die Ausgabe so nur mit erheblichem Programmieraufwand verarbeitbar. Zudem müsste man berücksichtigen,, dass das Layout von Rechnung zu Rechnung häufig variiert. Das Resultat der modernen Pipeline ist für einen Menschen schwerer zu lesen, behält aber die Struktur durch die Verwendung von HTML-Elementen vollständig bei. Damit ist sie im weiteren Verlauf der Pipeline deutlich einfacher zu bearbeiten.

Handschriftliche Notizen

Handschriftliche Notizen eine der größten Herausforderungen für OCR-Systeme.Die Variabilität von Handschriften ist enorm und selbst für Menschen manchmal schwer zu entziffern. Klassische OCR-Engines stoßen hier schnell an ihre Grenzen. Moderne LLM-basierte Systeme hingegen können durch ihr Training auf vielfältigen Datensätzen oft deutlich bessere Ergebnisse erzielen.

Handschriftliches Beispiel – Kreuzprodukt vollständig

Wo die klassische OCR schon an der klaren Trennung von Symbolen scheitert und semantische Zeichen wie das Kreuzprodukt nur als einfaches "x" behandelt, rekonstruiert das moderne Modell Struktur und Bedeutung in vielen Fällen. Sollte die Erkennungsgenauigkeit für einen bestimmten Einsatzzweck nicht ausreichend sein, kann bei einem OpenSource Modell natürlich auch noch ein Finetuning auf diesen speziellen Use-Case durchgeführt werden

In diesem Beispiel erkennt die klassische Pipeline die handschriftlichen Teile nicht im Ansatz. Die moderne Pipeline hingegen erkennt nicht nur die handschriftlichen Teile, sondern interpretiert auch die mathematischen Symbole korrekt und gibt eine semantisch sinnvolle Ausgabe zurück.

Technische Daten

Bild generiert von Google Gemini

Eine häufig auftretende Problemstellung ist es, technische Zeichnungen sinnvoll digitalisiert zu archivieren. Hier bietet das Auslesen der Daten auf der Zeichnung enormes Potenzial für Zeitersparnisse sowie nützliche Datenbankstrukturen. Dabei treffen allerdings alle Schwächen von klassischer OCR aufeinander: Text ist in unterschiedlichen Ausrichtungen auf der Zeichnung, Metadaten befinden sich in tabellarischer Form auf dem Dokument und Position spielt eine entscheidende Rolle. Dazu kommen zum Teil ungewöhnliche Schriftbilder und alterndes Papier. Betrachten wir als Beispiel diese Zeichnung eines Wasserrads:

https://berlin.museum-digital.de/singleimage?imagenr=8978

Wie vorausgesagt, liefert die klassische Pipeline hier kein im Ansatz brauchbares Ergebnis. Die moderne Variante allerdings erkennt, was als Text ausgelesen werden kann und was nicht, und gibt ein brauchbares Ergebnis zurück.

Weiterverarbeitung

Bild generiert von Google Gemini

Noch wichtiger als das bloße Auslesen von Daten ist ihre Verarbeitung. Neben den Vorteilen, die Sprachmodelle bei der OCR bieten, gibt es auch in der weiteren Pipeline noch Möglichkeiten, das Meiste aus den digitalisierten Daten herauszuholen. So können sie nicht nur in ihrer Gesamtheit als Text gespeichert werden, sondern mit wenig Aufwand auf bestimmte Inhalte durchsucht und zur weiteren Verarbeitung in sinnvollen Formaten (z.B. .json) extrahiert werden. Ohne die Verwendung dieser Technologien ist das Arbeiten mit OCR-Ergebnissen meist zeitintensiv und fehleranfällig.

Zusammenfassung

Der Vergleich macht deutlich: Die Integration von LLMs in die OCR-Pipeline ist mehr als nur ein technisches Upgrade – es ist ein Paradigmenwechsel. Durch die multimodale Verarbeitung werden aus bloßen Pixeln direkt strukturierte, verständliche Daten.
Am Ende zählt dabei vor allem die Robustheit: Während klassische Ansätze oft schon bei minimalen Abweichungen wie einem schiefen Scan scheitern, verzeiht die moderne Pipeline Fehler im Ausgangsmaterial und liefert verlässliche Ergebnisse. Damit wandelt sich OCR von einer oft frustrierenden Fehlerquelle zu einer stabilen Basis für jede moderne Softwarearchitektur.

Einen Guide zur Implementierung von LLM-basierter OCR-Pipelines wird in unserem nächsten Artikel verfügbar sein.