Wie eine Maschine ein Dokument zerlegt

Ein gescanntes Blatt ist für einen Rechner eine Fläche mit hellen und dunklen Punkten. Daraus einen Text zu machen, klingt nach einer Aufgabe, und es sind zwei. Die erste heißt: Welche Zeichen stehen da? Die zweite heißt: In welcher Beziehung stehen sie zueinander?

Die erste gilt seit Jahren als gelöst, jedenfalls für gedruckte Zeilen in brauchbarer Aufnahme. Die zweite entscheidet darüber, ob das Ergebnis etwas wert ist. Eine Tabelle, deren Zellen richtig gelesen und in der falschen Spalte gelandet sind, ist schlechter als gar keine, weil sie überzeugend aussieht. KI-Wissen, Kapitel 05 stellt genau diese Frage und lässt sie offen. Hier steht, wer sie wie beantwortet.

Warum die Zeichen der leichtere Teil sind

Das älteste Programm, das noch im Einsatz steht, ist über vierzig Jahre alt. Tesseract entstand zwischen 1985 und 1994 (externe Seite, github.com) in zwei Laboren von Hewlett-Packard, in Bristol und in Greeley, Colorado. 2005 gab HP den Quelltext frei, und von 2006 bis 2017 lag die Entwicklung bei Google. Es läuft auf jedem Rechner, braucht keine Grafikeinheit und liefert neben reinem Text auch Formate, die Position und Struktur mitführen.

Was es liefert, beschreibt seine Dokumentation mit zwei Wörtern, die die Grenze markieren: gedruckter Text. Handschrift ist nicht gemeint, und die Fehlerrate steigt mit jedem Durchschlag, jedem Stempel über einer Zeile und jeder Vorlage, die schief im Einzug lag.

Die übliche Kennzahl dafür ist die Zeichenfehlerrate, und sie hat denselben Konstruktionsfehler wie ihre Verwandte in der Spracherkennung: Sie mittelt. Neun von zehn richtigen Zeichen klingen brauchbar und sind es nicht, sobald der zehnte regelmäßig in einer Kontonummer sitzt.

Für die Struktur gibt es diese Kennzahl gar nicht erst. Eine Zeile kann Zeichen für Zeichen richtig gelesen und trotzdem an der falschen Stelle im Ergebnis gelandet sein. Eine Fehlerrate über Zeichen bemerkt das nie.

Drei Bauformen

Die klassische Engine arbeitet in Stufen, die ein Mensch entworfen hat: Vorlage begradigen, Zeilen finden, Wörter trennen, Zeichen erkennen, gegen ein Wörterbuch prüfen. Jede Stufe ist nachvollziehbar, jede einzeln zu verbessern, und das Ganze läuft auf einem Prozessor ohne besondere Ausstattung. Sie ist deshalb dort erste Wahl, wo ein Ergebnis reproduzierbar sein muss, wo kein Netz erlaubt ist oder wo hunderttausend gleichartige Seiten durchlaufen.

Die zweistufige Bauform trennt die beiden Aufgaben vom Anfang dieses Textes. Zuerst sucht ein Modell auf dem Seitenbild die Bereiche und benennt sie: Dokumenttitel, Zwischentitel, Fließtext, Tabelle, Bild, Formel, Seitenzahl, Randnotiz. Erst danach liest ein zweites Modell jeden Bereich einzeln, und es weiß dabei, womit es zu tun hat.

Der Vorteil steckt in diesem Wissen. Ein Erkenner, dem man sagt, dass der Ausschnitt eine Tabelle ist, kann Zeilen und Spalten ausgeben statt einer Wortfolge. Ein Layoutmodell wie PP-DocLayout_plus-L (externe Seite, huggingface.co) unterscheidet nach eigener Angabe 20 Kategorien und wurde auf einem eigens gebauten Bestand aus Arbeiten, Präsentationen, Magazinen, Verträgen, Büchern, Prüfungen, alten Drucken und Forschungsberichten trainiert.

Das Bildmodell liest die ganze Seite auf einmal. Es handelt sich um ein allgemeines Modell für Bilder und Sprache, dem man eine Frage stellt. Qwen2.5-VL (externe Seite, huggingface.co) beschreibt seine Fähigkeit so, dass es Texte, Diagramme, Symbole, Grafiken und Layouts in Bildern auswertet, und nennt Scans von Rechnungen, Formularen und Tabellen als Fall, in dem es strukturierte Ergebnisse liefert.

Der Preis dafür steht in Grundkurs, Kapitel 13: Ein Bildmodell rechnet in Fläche. Eine Seite kostet je nach Auflösung mehrere hundert bis über tausend Token, bevor ein einziges Wort gelesen ist.

Zwischen den drei Formen verläuft die Grenze weniger nach Güte als nach Fall. Die dritte Form kann etwas, das die ersten beiden nicht können: eine Frage über ein Bild beantworten. Wer aus einem Balkendiagramm die Werte samt ihren Kategorien zurückhaben will, braucht ein Modell, das versteht, was ein Balkendiagramm ist. Abtippen genügt dafür nicht.

Die Lesereihenfolge ist das schwerere Problem

Angenommen, alle Bereiche einer Seite sind gefunden und benannt. In welcher Reihenfolge kommen sie ins Ergebnis?

Bei einer einspaltigen Seite ist die Antwort langweilig: von oben nach unten. Bei allem anderen wird sie zu einem eigenen Problem, und die Fälle sind Alltag. Zwei Spalten, deren Zeilen nicht auf gleicher Höhe stehen. Eine Randnotiz, die neben dem dritten Absatz beginnt und über den vierten hinausreicht. Eine Fußnote, die im Ergebnis unter den Text gehört, auf dem Blatt aber vor der letzten Zeile steht. Eine Tabelle, die über den Seitenumbruch läuft.

Bis vor kurzem war das eine geometrische Aufgabe mit Schwellenwerten. Man teilt die Seite in waagerechte Bänder, sortiert innerhalb eines Bandes von links nach rechts, und wählt die Bandhöhe so, dass sie für die üblichen Zeilenabstände passt. Das ist billig und funktioniert bei einer Spalte zuverlässig. Bei zwei Spalten greift dasselbe Band über beide, und die Reihenfolge springt.

Die neueste Fassung des oben genannten Layoutmodells geht einen anderen Weg. PP-DocLayoutV3 (externe Seite, huggingface.co) sagt nach eigener Angabe Mehrpunkt-Rahmen für die Bereiche voraus, und bestimmt dabei die logische Lesereihenfolge (externe Seite, huggingface.co) für schiefe und gewölbte Flächen in einem einzigen Durchlauf. Die Begründung dafür nennt der Anbieter gleich mit: Es geht darum, Folgefehler zu vermeiden, die entstehen, wenn jede Stufe die Fehler der vorigen erbt.

Bemerkenswert daran ist die Richtung. Die Reihenfolge war eine Sache von Regeln, die jemand geschrieben hat, und wird zu einem gelernten Ergebnis. Wer heute einen eigenen Aufbau pflegt und die Reihenfolge noch selbst rechnet, pflegt eine Stufe, die ein Modell nebenbei mitliefert.

Und die Tabelle ist der Härtefall

Eine Tabelle hat zwei Strukturen übereinander. Die eine ist sichtbar: Linien, Abstände, Ausrichtung. Die andere ist gemeint: Zeilen, Spalten, Kopfzeilen, verbundene Zellen.

Der Ärger fängt dort an, wo beide auseinanderfallen. Eine Tabelle ohne Linien gibt es oft, und dann trennt nur der Abstand die Spalten. Eine verbundene Zelle über drei Spalten sieht aus wie eine Überschrift. Eine Zahl, die rechtsbündig steht, während der Rest der Spalte linksbündig steht, kann eine Summenzeile sein oder ein Formatierungsunfall.

Deshalb wird die Tabellenerkennung getrennt gemessen und getrennt gebaut. Die Modelle, die es hier gibt, geben ihr Ergebnis in einer Auszeichnungssprache aus, in der die Zellstruktur ausdrücklich steht. GLM-OCR (externe Seite, huggingface.co) nennt Formelerkennung, Tabellenerkennung und Informationsextraktion nebeneinander als die drei Richtungen, in denen es antritt, und das ist die übliche Aufteilung des Fachs.

Wer das Ergebnis weiterverarbeitet, sollte die Frage stellen, die keine Fehlerrate beantwortet: Ist die Zelle in der richtigen Zeile gelandet? Bei einer Rechnung entscheidet das darüber, ob eine Summe zu einem Posten gehört oder zum nächsten.

Was ein Benchmark misst, und was nicht

Der Maßstab, auf den sich das Fach derzeit einigt, heißt OmniDocBench (externe Seite, github.com). Er misst an 1651 PDF-Seiten über zehn Dokumentarten, fünf Layout-Arten und fünf Sprachen, und er wertet getrennt aus: durchgängig, Layout-Erkennung, Tabellen, Formeln, Text. Ausdrücklich enthalten sind wissenschaftliche Arbeiten, Finanzberichte, Zeitungen, Lehrbücher und handschriftliche Notizen.

Das ist gründlich, und trotzdem sind die Zahlen daraus mit Vorsicht zu lesen. Drei Gründe stehen dafür in der Quelle selbst.

Der Maßstab wandert. Er wechselte am 25.09.2025 auf die Fassung 1.5, am 10.04.2026 auf 1.6 (externe Seite, github.com) und am 30.04.2026 auf 1.7 (externe Seite, github.com). Zwischen diesen Ständen kamen Seiten dazu, und das Verfahren, mit dem Ergebnis und Vorgabe einander zugeordnet werden, hat sich geändert. Eine Punktzahl ohne Fassungsnummer ist damit wertlos.

Die Bestwerte hängen an der alten Fassung. GLM-OCR gibt 94,62 Punkte auf OmniDocBench V1.5 (externe Seite, huggingface.co) an und dazu den ersten Platz. Beides bezieht sich auf einen Maßstab, der seither zweimal geändert wurde. Das entwertet die Zahl nicht, es datiert sie.

An der Spitze liegen Zehntelpunkte. Wenn die vorderen Modelle sich um weniger als einen Punkt unterscheiden, sagt die Reihenfolge mehr über die Auswahl der Prüfseiten als über die Modelle. Ein Maßstab, an dem alle über 94 Punkte erreichen, misst nicht mehr, wofür er gebaut wurde.

Dazu eine Eigenart, die in diesem Fach häufiger vorkommt als anderswo: Die Bestenliste stammt von den Betreibern des Maßstabs, die die Modelle selbst haben laufen lassen. Das ist weder eine Herstellerangabe noch eine unabhängige Prüfung, es ist eine dritte Kategorie. Sie ist besser als eine Selbstauskunft und schlechter als eine Wiederholung durch Dritte.

Was das Betriebssystem inzwischen mitbringt

Die Frage, ob man so etwas selbst bauen muss, hat seit macOS 26 eine neue Antwort. Apples Vision-Framework kennt einen Aufruf, dessen Beschreibung eine Bildanalyse verspricht, die ein Dokument abtastet und Auskunft über dessen Aufbau gibt (externe Seite, developer.apple.com).

Was das im Einzelnen heißt, sagt die Dokumentation deutlich. Der Aufruf trennt Text und Strichcodes in Gruppen (externe Seite, developer.apple.com) und ist für strukturierte Texte gedacht, ausdrücklich genannt sind Kassenbons, Nährwerttabellen, Lehrbuchseiten und Formulare (externe Seite, developer.apple.com). Über das Ergebnis lassen sich Wörter, Zeilen und Absätze abfragen, und Tabellen und Listen (externe Seite, developer.apple.com) ebenso.

Drei Eigenschaften machen das zu mehr als einer Randnotiz. Es rechnet auf dem Gerät, es kostet keine Modellzeit, und es steht in 26 Sprachen zur Verfügung, ohne dass jemand ein Modell auswählen, herunterladen oder aktuell halten muss.

Die Einschränkungen liegen auf der Hand und sind trotzdem zu nennen. Es läuft nur auf Apple-Geräten. Es liefert, was Apple für nützlich hält, und nicht mehr. Und wer das Ergebnis in einer Verarbeitungskette braucht, die auf einem Server läuft, kann damit wenig anfangen.

Drei Eigenschaften kommen dazu, die in der Dokumentation nicht stehen und am 08.09.2026 gemessen wurden. Jede Zelle einer Tabelle hat einen eigenen Rahmen, nicht nur Text. Damit lässt sich die Struktur weiterverwenden, ohne die Abschrift zu übernehmen, und das ist der Unterschied zwischen einer Ergänzung und einem Austausch. Verbundene Zellen kommen mit ihrer Spannweite an, waagerecht wie senkrecht. Eine Kopfzeile weist die Schnittstelle nicht aus, wer eine braucht, nimmt die erste Zeile und weiß, dass er eine Annahme trifft.

Ein Vorbehalt gehört zur Bauform. Wer die Schnittstelle aus einer anderen Sprache anspricht, bekommt die Struktur unter Umständen gar nicht: Über die ältere Objective-C-Brücke gelingt der Aufruf, das zurückgegebene Ergebnis kennt dort aber weder Absätze noch Tabellen. Ein Helfer in Swift löst das, kostet aber eine weitere Sprache im Aufbau.

Wann ein eigener Aufbau noch lohnt

Für die meisten Fälle gilt: Er lohnt nicht. Wer gedruckte Seiten in guter Aufnahme durchsuchbar machen will, nimmt ein fertiges Werkzeug. Wer auf einem Mac arbeitet und Absätze, Tabellen und Listen braucht, nimmt seit macOS 26 das Betriebssystem.

Vier Gründe bleiben, und sie sind alle eng.

Das Material verlässt das Haus nicht. Sobald Dokumente inhaltlich schutzbedürftig sind, wird ein Dienst, der auf dem eigenen Gerät rechnet, zur Bedingung. Bequemlichkeit ist dabei die falsche Kategorie.

Die Ausgabe soll eine bestimmte Form haben. Fertige Werkzeuge liefern, was sie liefern. Wer aus einem Diagramm eine Tabelle mit einer Zeile je Kategorie braucht, muss die Frage selbst stellen können.

Ein Sonderfall wiederholt sich. Ein Formular, das immer gleich aussieht, lässt sich mit Wissen über genau dieses Formular besser lesen als mit einem allgemeinen Verfahren. Das ist derselbe Gedanke wie in KI-Wissen, Kapitel 10: Ein spezialisiertes Modell schlägt in seiner Aufgabe ein größeres allgemeines.

Man will wissen, warum etwas herauskommt. Ein Aufbau aus benannten Stufen lässt sich an jeder Stufe messen. Ein Modell, das die ganze Seite auf einmal liest, liefert ein Ergebnis, und wenn es falsch ist, bleibt die Frage, an welcher Stelle.

Beides zusammen ist oft die beste Antwort. Die Aufzählung oben liest sich wie eine Wahl zwischen fertigem Werkzeug und Eigenbau, und für Tabellen aus einem PDF, das seinen Text mitbringt, ist sie keine. Das Betriebssystem sagt, wo die Zellen liegen. Die Datei sagt, was darin steht. Wer beides nimmt, bekommt die Struktur eines Modells und die Zeichen des Originals, und die Frage nach der Erkennungsgüte stellt sich für diesen Teil nicht mehr.

Der Gedanke lässt sich verallgemeinern. Ein Modell ist gut darin zu sagen, wo etwas liegt und wozu es gehört. Wo die Zeichen ohnehin exakt vorliegen, ist seine Abschrift der schwächste Teil seines Ergebnisses und der einzige, den man weglassen kann, ohne etwas zu verlieren.

Wie ein solcher Aufbau in der Praxis aussieht, welche Fehler er nach drei Monaten Betrieb zeigt und was die Verbindung aus beidem an einem echten Bestand bringt, steht im Werkstattbericht dazu. Die kürzeste Auskunft daraus: Von den Fehlern der ersten drei Monate lag keiner im Modell.

Was dieser Text nicht hergibt

Hier steht kein Vergleich. Keines der genannten Modelle ist für diesen Artikel gegen ein anderes gemessen worden, und die Zahlen stammen sämtlich von den Anbietern oder von den Betreibern des Maßstabs.

Die Einteilung in drei Bauformen ist eine Ordnung zum Verstehen. Die Programme selbst ziehen diese Grenze nicht. Die Übergänge sind fließend, und das lässt sich an einem Beispiel zeigen: GLM-OCR, oben als Erkenner der zweiten Bauform genannt, benutzt in seiner eigenen Verarbeitung PP-DocLayoutV3 (externe Seite, huggingface.co) für die Layout-Analyse. Wer es einsetzt, bekommt eine zweistufige Verarbeitung, auch wenn er nur ein Modell aufruft.

Und die Frage, wie gut die drei Bauformen bei Handschrift abschneiden, ist hier gar nicht behandelt. Sie hat eine eigene Literatur und eigene Maßstäbe, und die Werte liegen durchweg deutlich unter denen für Druck.