Dokumente mit KI verstehen: OCR, Layout und visuelle Suche erklärt

01

Was auf dem Schreibtisch wirklich liegt

• Der Scan

  PDF aus dem Kopierer

  Grau, leicht schräg, manchmal mit einem Stempel genau über der wichtigsten Zeile.

• Das fotografierte Formular

  Handyfoto per Messenger

  Schatten, gekrümmtes Papier, Licht von der falschen Seite. Trotzdem soll ein Feld daraus einen Wert liefern.

• Die Tabelle im Bild

  Screenshot in einer E-Mail

  Für das Auge klar gegliedert. Für eine Maschine zunächst nur eine Fläche aus Pixeln.

• Der mehrspaltige Bericht

  Sauber gesetztes PDF

  Gut gedruckt, aber die Spalten laufen beim automatischen Lesen gern durcheinander.

Vier Beispiele, ein Problem: Keines davon ist ein sauberer Fließtext. Genau damit muss jede Dokumenten-KI zuerst zurechtkommen, lange bevor irgendein Sprachmodell überhaupt eine Antwort formuliert. Ein digital erzeugtes PDF enthält meist schon eine Textebene, ein Scan dagegen nur Pixel. Ob die Zahl 240 eine Menge oder ein Betrag ist, zeigt die Spalte, in der sie steht. Das Zeichen allein sagt es nicht.

In unseren Projekten sehen wir denselben Verlauf immer wieder: Ein Fehler unten wandert nach oben durch, bis er ganz oben als falsche Antwort wieder auftaucht. Deshalb lohnt sich der Blick auf jede einzelne Ebene, bevor überhaupt ein Werkzeug ausgewählt wird. Wie aus gefundenen Stellen eine belegte Antwort wird, erklärt der Leitfaden zu Retrieval-Augmented Generation, wie Dokumente ins größere Bild von Erfassen, Finden und Pflegen passen, die Übersicht Wissensmanagement mit KI.

02

Eine klassische OCR-Pipeline arbeitet in fünf Schritten

Eine OCR-Pipeline bereitet zuerst das Bild auf, findet dann das Layout, liest jede Zeile und prüft das Ergebnis gegen Wörterbücher und Formate. Am Ende steht Text mit Koordinaten, durchsuchbar und kopierbar.

1. Bild aufbereiten

   Entzerren, drehen, Kontrast anheben, bevor überhaupt ein Zeichen erkannt wird.

2. Layout finden

   Blöcke, Spalten und Zeilen abgrenzen, damit die Lesereihenfolge feststeht.

3. Zeilen erkennen

   Jede Zeile wird als Zeichenfolge gelesen, heute meist über ein neuronales Netz statt Zeichen für Zeichen.

4. Nachbearbeiten

   Wörterbuch, Zahlenformate und Konfidenzwerte gleichen das Rohergebnis ab.

5. Text mit Koordinaten ausgeben

   Das Ergebnis ist durchsuchbar, kopierbar und prüfbar. Jedes Zeichen kennt seine Position auf der Seite.

Moderne Engines lesen nicht mehr Buchstabe für Buchstabe. Die quelloffene Engine Tesseract nutzt seit Version 4 ein Erkennungssystem auf Basis rekurrenter Netze (LSTM), das laut Projektdokumentation als Zeilenerkenner arbeitet und in der Größenordnung zehnmal so viel Rechenzeit braucht wie der ältere, zeichenweise arbeitende Erkenner (Tesseract-Dokumentation). Mehr Genauigkeit kostet also Rechenzeit.

Die eigentliche Schwachstelle liegt selten in der Zeichenerkennung. Sie liegt im Schritt davor. Findet die Layoutanalyse zwei Spalten nicht, liest die Erkennung stur über die Spaltengrenze hinweg, und jede Zeile ergibt einen Satz, der grammatisch passt und inhaltlich Unsinn ist. Sieht sauber aus. Ist trotzdem falsch. Solche stillen Fehler sind laut dem Glossar zur Texterkennung die häufigste Fehlerquelle in Dokumentenprojekten.

03

Was leisten layoutbewusste Modelle, die Text und Position gemeinsam lesen?

Layoutbewusste Modelle verarbeiten Text zusammen mit seiner Position auf der Seite, oft zusätzlich mit dem Bild dazu. Ein Wert rechts neben „Datum" wird so als Datum erkannt, eine Zahl in der dritten Spalte als Betrag. Bei Formularen und Tabellen liegen sie deutlich vor Modellen, die nur die Zeichenfolge sehen.

Den Grundstein legte LayoutLM (Xu et al., KDD 2020): erstmals gemeinsam auf Text und Layoutpositionen vortrainiert, verbesserte es laut Veröffentlichung den Wert beim Formularverständnis von 70,72 auf 79,27. Ein Sprung, kein Rundungsfehler. Nachfolger wie LayoutLMv3 (Huang et al., ACM Multimedia 2022) verarbeiten Text und Bildausschnitte in einem einzigen Transformer und lernen, welche Bildstellen zu welchen Wörtern gehören.

Ein zweiter Zweig verzichtet ganz auf vorgeschaltete Texterkennung. Donut (Kim et al., ECCV 2022) liest das Seitenbild direkt und erzeugt strukturierte Ausgabe. Die Autoren nennen drei Nachteile klassischer Ketten als Grund dafür: Rechenkosten der OCR, wenig Flexibilität bei Sprachen und Dokumenttypen, und die Fortpflanzung von OCR-Fehlern durch alle folgenden Schritte. Heutige multimodale Sprachmodelle, die Bild und Text gemeinsam verarbeiten, setzen diese Linie fort (Multimodales Modell).

Layoutanalyse als eigene Aufgabe

Wie gut ein System Blöcke erkennt, hängt stark von den Dokumenten ab, an denen es gelernt hat. Der Datensatz DocLayNet (Pfitzmann et al., KDD 2022) wurde von Menschen annotiert, unterscheidet 11 Layoutklassen und deckt bewusst unterschiedliche Dokumenttypen ab. Modelle, die darauf trainiert wurden, verhalten sich laut den Autoren über Dokumenttypen hinweg stabiler als Modelle, die nur wissenschaftliche Artikel gesehen haben.

04

Wie ColPali eine Seite ohne vorherige Texterkennung durchsucht

ColPali (Faysse et al., arXiv 2024, veröffentlicht auf der ICLR 2025) bettet laut Paper Bilder von Dokumentseiten direkt ein und gleicht sie über späte Interaktion (Late Interaction) ab. Die Autoren stellten dazu den Benchmark ViDoRe vor, weil bestehende Suchsysteme vor allem den extrahierten Text auswerten und visuelle Hinweise wie Tabellen, Diagramme und Schriftgrößen übergehen. Nach ihren Messungen schlägt der Ansatz klassische Pipelines, und er ist dabei einfacher aufgebaut.

1. Seiten als Bilder aufnehmen

   Jede Seite wird gerendert oder gescannt. Eine Texterkennung ist für die Suche nicht nötig.

2. Ausschnitte einbetten

   Das Modell teilt die Seite in ein Raster kleiner Ausschnitte und erzeugt für jeden einen Vektor, eine Seite wird also durch viele Vektoren beschrieben.

3. Anfrage einbetten

   Die Frage wird in Wortteile (Token) zerlegt, und jedes erhält einen eigenen Vektor.

4. Spät vergleichen

   Für jedes Wortteil der Frage zählt nur der ähnlichste Seitenausschnitt. Die Summe dieser Bestwerte ergibt die Punktzahl der Seite. Das Verfahren heißt MaxSim und stammt aus ColBERT (Khattab und Zaharia, SIGIR 2020).

5. Kandidaten nachbewerten

   In der Praxis grenzt oft eine schnellere Suche die Kandidaten ein, und der aufwendige Vergleich läuft nur über diese Seiten.

Der größte Nachteil ist Speicher. Viele Vektoren je Seite brauchen ein Vielfaches des Index eines einzelnen Textvektors, und das summiert sich bei tausenden Seiten schnell zu spürbaren Größenordnungen. Kleinere Modelle verschieben diese Rechnung: ModernVBERT (Teiletche et al., arXiv 2025) kommt mit 250 Millionen Parametern aus und schlägt laut Paper nach Feinabstimmung auf Dokumentensuche Modelle, die bis zu zehnmal größer sind. Die Bausteine ordnet der Beitrag Der OCR-freie Dokumenten-Stack ein, das Prinzip der späten Interaktion vertieft Late Interaction erklärt.

05

Extraktion oder Suche: zwei verschiedene Aufgaben

Extraktion überträgt Werte in ein festes Schema und braucht dafür exakte Zeichen. Suche soll zu einer Frage die richtige Seite finden und verzeiht kleine Zeichenfehler, solange die Seite dabei ist. Wer die Aufgabe vorher benennt, wählt die passende Technik und misst das Richtige.

Viele Vorhaben brauchen beides. Ein bewährtes Muster teilt die Arbeit auf: Die visuelle Suche findet zuerst die wenigen relevanten Seiten, und nur auf diesen läuft danach eine gründliche Texterkennung, deren Ergebnis zitiert oder weiterverarbeitet wird. Das hält die aufwendige Stufe klein und verhindert, dass OCR-Fehler schon die Suche verderben. Der Beitrag Klassische Texterkennung neben visueller Suche beschreibt diese Aufteilung an einem konkreten Modell.

06

Warum scheitern Tabellen, Scans und Handschrift so oft?

Die Autoren von OmniDocBench (Ouyang et al., CVPR 2025) finden, dass klassische Pipelines und durchgängige Bild-Sprach-Modelle je nach Dokumenttyp eigene Stärken und Schwächen haben. Ranglistenplätze allein reichen als Auswahlkriterium nicht. Am Ende entscheidet der Test am eigenen Bestand.

07

Wann klassische OCR weiterhin die bessere Wahl ist

Klassische OCR bleibt die bessere Wahl, wenn Sie die tatsächlichen Zeichen brauchen: für Volltextsuche über ein Archiv, zum Zitieren und Kopieren, als Prüfspur, für die Übergabe exakter Werte an andere Systeme. Visuelle Suche liefert eine Seite, keinen Text, und ersetzt diese Aufgaben nicht.

• Volltext und Zitate: Ein Treffer, den ein Mensch kopieren oder wörtlich zitieren soll, braucht erkannten Text.
• Prüfspur: Wer nachweisen muss, aus welchem Wort an welcher Position ein Wert stammt, braucht Zeichen mit Koordinaten.
• Fließtext ohne Layout: Bei Berichten, Protokollen oder Verträgen mit einfacher Gestaltung ist Textsuche günstiger und genügt.
• Weitergabe an Systeme: Datenbanken und Fachanwendungen erwarten Werte, keine Seitenbilder.

08

Wie prüft man die Qualität einer Dokumenten-KI?

Man prüft Qualität je Ebene getrennt: Zeichenfehlerrate für die Texterkennung, Strukturtreue für Tabellen, Feldgenauigkeit für die Extraktion, Trefferquote für die Suche. Grundlage ist ein Testsatz aus eigenen, schwierigen Dokumenten mit geprüften Sollwerten. Eine einzige Gesamtnote verdeckt, auf welcher Ebene der Fehler entsteht.

Wie man die Antworten eines Systems auf Basis gefundener Dokumente bewertet, also Treue zur Quelle und Relevanz, vertieft der Leitfaden KI-Antworten prüfen.

09

Welcher Ansatz zum eigenen Dokumentenbestand passt

Die dritte Frage, ob Dokumente das Haus verlassen dürfen, verändert die Auswahl stärker als jede Rangliste. Texterkennung, Layoutmodelle und kompakte visuelle Suchmodelle laufen heute auf eigener Hardware. Was lokaler Betrieb von Modellen verlangt, erklärt Lokale Sprachmodelle.

iiterate Technologies GmbH entwickelt KI-Anwendungen und Individualsoftware von der Architektur bis zum Betrieb, auf Kundeninfrastruktur oder in EU-Hosting, mit Schwerpunkt auf RAG, lokalen Sprachmodellen und der Anbindung an Bestandssysteme (Leistungen).