Wo in der eigenen Text­erken­nung das Modell sitzt

Ein Balkendiagramm mit vier Säulen, eingebettet in ein PDF. Was die eigene Texterkennung im Juni daraus machte, war diese Zeile:

120 180 150 210 Q1 Q2 Q3 Q4

Jedes Zeichen darin ist richtig gelesen. Die Zahlen stimmen, die Quar­tals­be­zeich­nungen stimmen, und trotzdem ist die Aussage des Bildes weg: Welcher Wert zu welchem Quartal gehört, sagt die Zeile nicht mehr. Das ist der Fall, den KI jenseits der Sprachmodelle, Kapitel 05 als offene Frage der Zeichenerkennung beschreibt. Ein Verfahren kann jedes Zeichen richtig lesen und die Struktur trotzdem verlieren.

Dieser Bericht ist die Messung dazu, an einer eigenen Verarbeitung, die seit Juni 2026 auf einem Mac Mini läuft. Ein PDF geht hinein, strukturiertes Markdown und eine Beschreibung des Layouts kommen heraus. Sie hat inzwischen 62 Läufe hinter sich, 113 Seiten und 1205 erkannte Blöcke.

Beim Bauen wurde eine Frage immer wichtiger als die nach der Erkennungsrate: An welcher Stelle im Weg von der Seite zur Struktur entscheidet eigentlich ein Modell? Die Antwort ist kürzer, als sie sein müsste.

Der Aufbau

Ein kleiner Dienst nimmt das PDF entgegen und legt es in eine Warteschlange, die genau einen Auftrag gleichzeitig bearbeitet. Je Auftrag startet ein eigener Prozess, der nach getaner Arbeit endet. Das ist die ganze Spei­cher­ver­wal­tung: Ein Modell, das nur während eines Laufs geladen ist, gibt seinen Speicher beim Ende des Prozesses zurück, ohne dass jemand ihn freigeben muss.

Fünf Bauteile treffen die Entscheidungen, vier davon sind Modelle:

Das Erkennungsmodell ist das jüngste der vier Modelle und stammt vom Februar 2026. Sein Anbieter gibt an, es habe nur 0,9 Milliarden Parameter, und nennt dazu Formelerkennung und Tabellenerkennung als Stärken. Das ist Selbstauskunft, und für die Auswahl war es trotzdem der Grund: Ein kleines Modell, das seine Aufgabe eng fasst, passt auf ein Gerät mit 24 Gigabyte Speicher, neben dem noch etwas anderes laufen soll.

Die beiden Sprachmodelle laufen über MLX (externe Seite, github.com), das Rechenwerk für Apple Silicon. Warum das Ganze lokal läuft, steht in Beurteilen und Einordnen, Kapitel 01 und wird hier nicht wiederholt. Was ein gemieteter Dienst an seiner Stelle leisten würde, steht am Ende dieses Berichts.

Drei Wege je Seite, und einer kostet nichts

Bevor irgendein Modell startet, wird jede Seite eingeordnet. Die Frage ist schlicht: Steht in ihr schon Text? Ein PDF, das aus einem Textprogramm kommt, enthält seine Zeichen, samt Position und Schriftgröße. Ein Scan enthält ein Bild.

Die Schwelle liegt bei 20 Zeichen. Alles darüber gilt als Seite mit eigenem Text und wird ausgelesen, alles darunter wird bei 200 Bildpunkten je Zoll gerendert und geht an das Layoutmodell. Die Schwelle ist bewusst niedrig, denn die beiden Fehler kosten Verschiedenes: Eine Textseite fälschlich als Bild zu behandeln kostet Modellzeit und womöglich Struktur. Den umgekehrten Fehler hielt der Aufbau für selten, weil ein Scan keinen Text-Layer mitbringt. Das gilt für einen Scan, den niemand nachbearbeitet hat; was im Bestand daraus geworden ist, steht unter „Was weiter fehlt“.

Der dritte Weg gilt Seiten, die beides haben, also eigenen Text und eingebettete Grafiken. Dort wird der Text ausgelesen und nur die Grafik einem Modell vorgelegt.

Wie viel dieser Weg spart, sagt die Statistik der 1205 Blöcke: 685 kommen aus dem Text-Layer, 513 aus dem gerenderten Bild. Einer ist das Diagramm, das ans große Modell ging. Die übrigen sechs stammen aus dem ersten Lauf im Juni, als der Katalog die Herkunft eines Blocks noch nicht festhielt. Für die 685 hat kein Modell gerechnet. Im Betriebsprotokoll steht das als kleinste gemessene Zeit je Seite, und die ist null.

seitlich verschiebbar

eigene Darstellung, Stand 08.09.2026

Woraus die Struktur entsteht

Auf einem Scan entscheidet ein Modell

Hier sitzt die eine Stelle. Das Layoutmodell bekommt das Seitenbild und liefert Rechtecke mit einer Klassenangabe: Dokumenttitel, Zwischentitel, Fließtext, Tabelle, Bild, Formel, Seitenzahl, Randnotiz. Eine Tabelle im Programm ordnet jeder Klasse zu, was daraus wird: welche Anweisung das Erkennungsmodell für diesen Ausschnitt bekommt, und welches Zeichen davor im Markdown steht.

doc_title        →  # Überschrift erster Ordnung
paragraph_title  →  ### Überschrift dritter Ordnung
table            →  Anweisung: als Markdown-Tabelle transkribieren

Diese Zuordnung ist der Kern der Strukturerkennung, und sie hat drei Monate lang zu einem anderen Modell gehört. Dazu unten mehr.

Auf einer Textseite entscheidet der Median

Kommt der Text aus dem PDF selbst, gibt es kein Modell und keine Klassen. Es gibt Schriftgrößen. Der Median über alle Blöcke der Seite gilt als Grundschriftgröße, und daran wird gemessen: Wer das Doppelte davon erreicht, wird Dokumenttitel; wer das Anderthalbfache erreicht, wird Zwischentitel; alles andere ist Fließtext.

Das ist eine Heuristik von drei Zeilen, und sie hält erstaunlich gut, weil sie eine Eigenschaft des Satzes benutzt, die fast jedes Dokument hat. Sie versagt dort, wo ein Dokument seine Hierarchie über Fettung oder Farbe ausdrückt statt über Größe.

Seit dem 08.09.2026 entscheidet auf einer solchen Seite noch etwas Zweites mit, und zwar über Tabellen. Warum das ein Modell sein muss und wieso von ihm trotzdem kein einziges Zeichen ins Ergebnis kommt, steht weiter unten in einem eigenen Abschnitt.

Die Reihenfolge entscheidet Geometrie

Ob eine Region vor einer anderen steht, klärt keine der beiden Stufen. Das macht Rechnerei mit Rechtecken, und zwar in zwei Schritten.

Zuerst fliegt heraus, was doppelt ist. Ein Layoutmodell liefert manchmal eine große Region, die kleinere vollständig enthält, etwa eine Tabelle, in der es zusätzlich einzelne Felder erkennt. Ohne Gegenmaßnahme erschiene der Text zweimal. Die Regel: Wer zu 70 Prozent seiner Fläche in einer größeren Region liegt, fällt weg.

Dann wird sortiert. Die Seite wird in waagerechte Bänder von einem Vierzigstel ihrer Höhe geteilt, und was im selben Band liegt, gilt als dieselbe Zeile und wird von links nach rechts gereiht. Bänder untereinander gehen von oben nach unten.

Das ist die gesamte Spaltenlogik. Es gibt keinen Detektor für Mehrspaltigkeit, keine Zerlegung der Seite in Blöcke, keine gelernte Lesereihenfolge. Bei einer einspaltigen Seite reicht das. Bei zwei Spalten greift dasselbe Band über beide, und die Reihenfolge springt zwischen links und rechts hin und her, sobald die Zeilen der Spalten nicht auf gleicher Höhe stehen.

Wie ein Balkendiagramm zu seinen Zahlen kommt

Zurück zu der Zeile vom Anfang. Sie ist an einer Seite entstanden, die ihren Text mitbringt und ein Diagramm enthält, also auf dem dritten Weg.

Eine Grafik zu finden ist dort eine geometrische Aufgabe, kein Erkennungsproblem. Ein PDF sagt selbst, wo eingebettete Bilder liegen. Ein gezeichnetes Diagramm dagegen besteht aus Hunderten einzelner Striche und Flächen. Für sich genommen weiß keines dieser Elemente, dass es zu einem Diagramm gehört. Deshalb werden alle gezeichneten Rechtecke eingesammelt und verschmolzen, sobald sie sich bis auf zwölf Punkte nahekommen. Was danach übrig bleibt und mindestens 40 Punkte Kantenlänge hat, gilt als Grafik. Ein Rechteck über fast die ganze Seite fällt weg, denn das ist ein Seitenrahmen.

Diese Regel hatte eine Lücke, und sie lag genau bei dem Diagramm vom Anfang. Zwischen den Säulen eines Balkendiagramms ist mehr als zwölf Punkte Luft. Verbunden sind sie durch die waagerechte Achse, und die fiel eine Zeile vorher durch einen Filter, der zu dünne Elemente aussortiert: In den Zeichendaten hat eine Linie die Höhe null. Aus vier Säulen wurden vier Regionen, und jede ging einzeln an das Modell, mit der Anweisung, eine Tabelle mit einer Zeile je Kategorie zu liefern. Vorgelegt bekam es eine einzelne Säule ohne Achse.

Der Filter selbst ist richtig, ohne ihn würde jede Trennlinie im Fließtext zur Grafik. Seit dem 07.09.2026 sammelt das Programm die Striche deshalb ein und gibt ihnen eine zweite Rolle. Für sich bleibt ein Strich weiterhin außen vor. Berührt er aber zwei oder mehr Regionen, gehört er zu ihnen und sie zueinander. Berührt er nur eine, bleibt er draußen und zieht ihren Rahmen nicht in die Breite. An der Testseite mit vier Säulen und dreißig Punkten Abstand wird aus vier Regionen eine, und die Achse liegt darin.

Eine Regel steht noch davor, und sie ist die interessanteste: Überdeckt eine gefundene Grafik einen Textblock zu mindestens 30 Prozent, fällt die Grafik weg. Der Grund steht als Halbsatz im Programm. Der Text ist exakt. Wo die Seite ihre Zeichen selbst mitbringt, wäre es ein Rückschritt, sie von einem Modell raten zu lassen, das dieselbe Stelle als Bild sieht.

Diese Regel hat am selben Tag wie der Strich eine zweite Bedingung bekommen, und der Anlass war derselbe Aufbau. Nachdem die Achse die Säulen wieder verband, lag die gefundene Region über den Wert­be­schrif­tungen, und die stehen zu 100 Prozent in ihr. Ein einziges „120“ genügte, um das ganze Diagramm zu verwerfen. Die Regel fragte, wie viel des Textblocks in der Grafik liegt, und nie, wie viel der Grafik Text ist. Bei einem Diagramm mit drei Zahlen ist das ein Bruchteil, bei einem Absatz unter einer Farbfläche fast alles, und nur der zweite Fall ist der, für den die Regel gebaut wurde.

Die Schwelle dafür stammt aus einer Messung an fünf Aufbauten, nicht aus dem Gefühl:

quelle: eigene Messung, Stand 07.09.2026

Acht Prozent liegen in der Lücke. Der Abstand nach unten beträgt knapp zwei Prozentpunkte, und das ist wenig. Deshalb stehen beide Randfälle als Testfälle im Prüfstand: Wer die Zahl ändert, fällt über sie.

Die Zuordnung von Beschriftung zu Wert schließlich, also das, woran die Zeile vom Anfang scheiterte, macht kein Algorithmus. Sie macht ein Satz in der Anweisung an das Modell. Er verlangt eine Tabelle mit einer Zeile je Kategorie und die Werte von der Achse abgelesen, und er verbietet ausdrücklich, Werte zu erfinden, die nicht lesbar sind.

Dazu kam ein Wechsel des Modells. Die auf Texterkennung getrimmte Engine transkribiert einen Ausschnitt in Lesereihenfolge, und genau das ergab die Zeile vom Anfang. Für Grafiken läuft seither das allgemeine Modell, das eine Frage über ein Bild beantworten kann.

Ein Satz in der Anweisung reicht allerdings nur so weit, wie das Modell sehen kann. Beim ersten Lauf nach der Achsenreparatur kam eine Tabelle mit den Spalten „Category“ und „Value“ zurück, und darin stand eine 240, die es auf der Seite nirgends gibt. Der Grund lag am Ausschnitt. Die Kategorien stehen unter der Achse, der Wert über der Säule, beides also außerhalb der gezeichneten Fläche. Wer ohne Rand zuschneidet, legt ein Diagramm ohne seine Kategorien vor, und dann füllt das Modell die Lücke selbst. Eine Grafik bekommt seither 18 Punkte Rand, wo ein Textblock mit sechs Bildpunkten auskommt, gerechnet in Punkten und mit der Auflösung skaliert. Danach stand die Zuordnung.

Was dabei herauskommt, steht bis heute im Katalog. Aus derselben Grafik, die im Juni die Zeile vom Anfang ergab, wurde:

Dieselben acht Zahlen und Bezeichnungen, jetzt einander zugeordnet. Es ist ein Testdokument aus der Bauzeit, die Zahlen sind erfunden, und es ist zugleich der einzige Block im ganzen Bestand, der diesen Weg gegangen ist. Eine Messung ist das nicht. Es zeigt, dass der Weg funktioniert, und nicht, wie oft er gebraucht wird.

Dann stand alles zweimal da. Die Beschriftungen bringt die Seite selbst mit, und sie liegen zugleich im Ausschnitt, den das Modell bekommt. Sie erschienen also als eigene Absätze und noch einmal in der Tabelle daneben: vier Zeilen, die nur „Q1“ bis „Q4“ heißen, dazu eine „210“ ohne jeden Bezug.

Seit dem 07.09.2026 nachts fällt ein solcher Block aus dem Fließtext, wenn zwei Bedingungen zusammenkommen. Sein Mittelpunkt liegt im Ausschnitt, und jedes seiner Wörter steht in der Ausgabe der Grafik. Die zweite ist der Beleg: Für genau diesen Block ist damit gezeigt, dass die Abschrift ihn vollständig enthält. Schreibt das Modell 240 statt 210, findet der Block „210“ sich in der Ausgabe nicht wieder und bleibt stehen, und die falsche Zahl steht dann neben der richtigen. Aus dem Layout-Overlay verschwindet ohnehin nichts. Dort bleibt jeder Block mit Text und Koordinaten, mit einem Vermerk, in welcher Grafik er liegt.

Die erste Fassung dieser Regel war gebaut und wirkungslos. Sie verlangte den Block vollständig im Ausschnitt, und „Q1“ liegt zu 93 Prozent darin, weil der Rahmen einer Textzeile die Unterlänge mitnimmt. Aufgefallen ist das nur, weil die Testfälle die echten Koordinaten aus dem Lauf führen. Runde Zahlen hätten die Regel bestätigt.

Der größere Befund lag eine Stufe früher. Beim Nachmessen, woher die vier Werte eigentlich kommen, zeigte sich, dass drei von ihnen im Text der Seite stehen und trotzdem nirgends im Ergebnis auftauchten. Verantwortlich war eine Aufräumregel: Sie verwirft eine Region, sobald diese zu 70 Prozent in einer größeren liegt. Gebaut ist sie gegen verschachtelte Regionen eines Layoutmodells, und auf einer Seite mit eigenem Text trifft sie die Wert­be­schrif­tungen in einem Diagramm. 120, 150 und 180 waren damit still verschwunden, lange bevor ein Modell die Grafik überhaupt gesehen hatte, und übrig blieb allein die Abschrift. Seither schont diese Regel exakten Text, und die Frage, ob eine Beschriftung im Ergebnis erscheint, beantwortet eine Stelle statt zweier. Nach der Reparatur ist das Markdown fünf Zeilen kürzer und das Layout-Overlay drei Regionen länger.

Ein Riegel, der beim Bauen entstand, ist dabei wieder gefallen, und zwar mit einer falschen Begründung. Der Gedanke: Auf einer Seite mit eigenem Text steht jedes sichtbare Zeichen auch im Text, also müsste jede Zahl der Modellausgabe sich dort wiederfinden lassen, und was fehlt, wäre erfunden. Am richtigen Lauf gemessen meldete dieser Riegel 120, 150 und 180 als Erfindung. Die Deutung lautete damals, beschriftet sei allein die 210 über der höchsten Säule, und die anderen drei lese das Modell an der Säulenhöhe ab. Sie war falsch. Die drei Zahlen stehen beschriftet auf der Seite, und es waren genau die drei, die die Aufräumregel aus dem vorigen Absatz gelöscht hatte; die 210 hatte sie nicht getroffen. Der Riegel zeigte also auf die richtige Stelle und wurde als Fehlalarm verworfen. Ob er nach der Reparatur der Aufräumregel etwas findet oder nur noch Fehlalarme gibt, ist nicht gemessen.

Verankert wird das Ergebnis über dieselbe Reihenfolge wie jeder andere Block. Die Tabelle steht im Markdown an der Stelle, an der die Grafik auf der Seite steht. Eine Bindung an eine Bildunterschrift gibt es nicht, und das war der Einstieg in den unangenehmeren Teil dieses Berichts.

Die Tabellen, die niemand vermisst hat

Der Weg ohne Modell aus dem Abschnitt über die Struktur kennt genau drei Klassen: Dokumenttitel, Zwischentitel, Fließtext. Eine Tabelle steht in keiner davon. Sie zerfällt also in ihre Zellen, und die stehen im Ergebnis untereinander, jede als eigener Absatz. Wer das liest, sieht Zahlen ohne ihre Spalte.

Drei Monate lang ist das niemandem aufgefallen, und der Grund ist derselbe wie bei der Label-Tabelle weiter unten: Es gab keine Messung, die danach gefragt hätte. Der Abschnitt „Was weiter fehlt“ nannte bis zum 08.09.2026 zwei Lücken, und diese war keine davon.

Seit macOS 26 bringt das Betriebssystem eine Doku­men­ten­er­ken­nung mit, die auf einem Seitenbild Absätze, Listen und Tabellen (externe Seite, developer.apple.com) findet, auf dem Gerät und ohne Modellkosten. Damit standen zwei Fragen im Raum. Die naheliegende: Findet sie etwas, das der eigene Weg übersieht? Die unangenehme: Ihre Abschrift entsteht aus einem gerenderten Bild, während die Seite ihre Zeichen selbst mitbringt. Struktur zu gewinnen und dafür exakten Text gegen eine Abschrift zu tauschen wäre ein schlechter Handel.

Was diese Erkennung sonst noch kann, wie sie sich zu den drei Bauformen der Dokumentzerlegung verhält und woran deren Ranglisten kranken, steht im Fachartikel dazu. Hier geht es um die eine Frage, die für diesen Aufbau zählt.

Beide Fragen beantwortet ein Detail. Hat eine Zelle einen eigenen Rahmen oder nur Text? Sie hat einen. Damit lässt sich die Struktur von der Erkennung nehmen und jede Zelle aus dem Text-Layer füllen, über den Mittelpunkt des Textstücks, das in ihrem Rahmen liegt.

Wie viel dieser Umweg wert ist, sagt die Gegenprobe über den Bestand. In 544 Zellen füllen beide Seiten etwas ein, und in 68 davon steht etwas anderes. 36 Abweichungen betreffen allein den Leerraum. Die übrigen 32 sind Text, und in fünf von ihnen stehen andere Ziffern. Dazu kommen sieben Zellen, in denen allein der Text-Layer etwas findet.

Zwei Bibliotheken, eine Seite

Gebaut ist das als kleiner Helfer in Swift, den die Verarbeitung einmal je Dokument aufruft. Swift deshalb, weil die ältere Schnittstelle desselben Frameworks die Struktur nicht durchreicht: Der Aufruf gelingt, das Ergebnis kennt weder Absätze noch Tabellen.

Die erste Fassung bekam das PDF und rendert die Seite selbst. Damit entschieden zwei Bibliotheken darüber, wie eine Seite aussieht, und beim ersten gedrehten Dokument gingen sie auseinander. 13 der 65 Seiten sind gedreht, elf um 90 und zwei um 180 Grad. Das Auslesewerkzeug liefert seinen Text im ungedrehten Koordinatensystem, die Seitengröße und das gerenderte Bild dagegen im gedrehten. Auf den elf Seiten des um 90 Grad gedrehten Dokuments landeten 5 bis 18 Prozent der Zellinhalte am richtigen Ort, und die Schutzregeln verwarfen daraufhin elf Tabellen, die in Ordnung waren.

Repariert ist das über eine Zuständigkeit. Wer rendert, entscheidet über das Koordinatensystem, also rendert jetzt dasselbe Werkzeug, das auch die Textstücke misst. Seit dem 23.09.2026 rechnet es jeden Rahmen gleich beim Auslesen in das angezeigte System um, und alles danach kennt nur noch dieses eine.

Die Lesereihenfolge richtet sich dabei nach der Schrift. Die zwei um 180 Grad gedrehten Seiten enthalten ungedrehten Text und stehen in der Anzeige auf dem Kopf; nach der Anzeige sortiert, liefe ihr Text von unten nach oben. Auf den elf anderen stimmt die Reihenfolge seither auf zehn Seiten genau mit der überein, in der der Text in der Datei steht. Vorher war sie kaum besser als eine zufällige.

Gefunden hätte das keine selbst gezeichnete Testseite. Die sind nie gedreht.

Was dabei herauskommt

Über die 65 Seiten mit eigenem Text findet die Doku­men­ten­er­ken­nung 15 Tabellen mit 598 Zellen. 551 davon füllt der Text-Layer, also 92 Prozent; die übrigen sind leere Felder. 178 Textblöcke fallen dabei aus dem Fließtext, weil ihr Inhalt vollständig in einer Tabelle wieder auftaucht.

Der Rest ist Nachrechnen. 646 Textstücke sind in eine Zelle gewandert, und 591 von ihnen stehen danach allein dort. Die anderen 55 stehen zusätzlich im Fließtext, und das kostet die Schutzregel: Ein Block fällt nur, wenn jedes seiner Wörter in der Tabelle steht, und ein Block, der über den Rand der Tabelle hinausreicht, bleibt vollständig stehen. Zweimal gelesen zu werden ist der kleinere Schaden.

Das Ergebnis wächst dabei um 3,2 Prozent, und eine Seite kostet 0,40 Sekunden statt keiner. Eine der 15 Tabellen nimmt keinen einzigen Block auf: ein schmales Formularraster, dessen Textblöcke breiter sind als es selbst. Dort steht der Inhalt danach zweimal da.

Zwei Schutzregeln halten fern, was keine Tabelle ist: mindestens zwei Zeilen und zwei Spalten, und mindestens die Hälfte der Zellen mit Text aus der Datei. Am reparierten Bestand hat keine von beiden gegriffen, der nächste Fall lag bei 70 Prozent gegen die Schwelle 50 und bei drei mal zwei gegen zwei mal zwei. Ihr Wert steht trotzdem fest, denn genau so sah der Renderfehler oben aus: Füllquoten um zehn Prozent.

Beinahe wäre der Einbau an derselben Stelle gescheitert wie das Diagramm einen Abschnitt weiter oben. Eine Tabellenregion enthält ihre Textblöcke vollständig, also hätte die Aufräumregel mit den 70 Prozent genau den exakten Text verworfen, aus dem die Tabelle gefüllt wurde. Sie fragt seither allgemein, ob eine Region exakten Text hat, statt eine Grafik beim Namen zu nennen. Über alle 109 gespeicherten Seiten des Bestands gerechnet ändert das an Reihenfolge und Ergebnis nichts.

Was 113 Seiten ergeben haben

Die Zeiten stammen aus dem Betriebsprotokoll, Stand 07.09.2026, über 62 Läufe seit Juni. Das Protokoll führt die Zeit je Lauf und je Seite, und was sie aussagt, hängt am Weg, den die Seiten genommen haben:

Seit dem 08.09.2026 kommen auf eine Seite mit eigenem Text 0,40 Sekunden für die Tabellenstruktur aus dem Betriebssystem dazu; die Tabelle ist ein Stand von davor.

Die letzte Zeile ist ein Vergleich, denn alle fünf Läufe gingen über dieselbe Seite, am selben Tag im Juni. Es ist ein gedrucktes Formular mit handschriftlich ausgefüllten Feldern:

Ein erster Lauf mit dem Erkennungsmodell dauerte 63,5 Sekunden und lieferte sechsmal so viel Text wie die beiden späteren.

Das kleine Modell ist auf dieser Seite knapp viermal schneller als das allgemeine, und es liest die Handschrift praktisch nicht. Es gibt wieder, was es als Druck erkennt, und die ausgefüllten Felder fehlen im Ergebnis. Das war der Befund, aus dem die Verarbeitung zwei Modelle bekam.

KI jenseits der Sprachmodelle, Kapitel 10 empfiehlt dafür eine Stufung: das kleine Modell zuerst, das große für die Fälle, an denen es scheitert. Die Verarbeitung hat einen Modus genau dafür. Er reicht eine Region an das große Modell weiter, wenn das kleine sie leer lässt. An einem Formular greift er nicht, denn dort steht die Handschrift in derselben Region wie die gedruckte Feldbezeichnung. Das kleine Modell liefert die Bezeichnung, und die Region ist nicht leer. Scheitern sieht hier aus wie ein plausibles Teilergebnis, und eine Weiche, die auf ein leeres Ergebnis wartet, bemerkt es nie. Für Formulare bleibt deshalb nur der Modus, der jede Region dem großen Modell gibt.

Was das Layoutmodell erkannt hat, und wie sicher es sich dabei war, zeigt die folgende Tabelle mit Stand 25.09.2026. Gezählt sind die 539 Blöcke aus gerenderten Seiten. Blöcke aus dem Text-Layer haben fest den Wert 1,0, weil über sie kein Modell entschieden hat, und fehlen deshalb darin. Seitenzahlen verwirft die Verarbeitung seit der Reparatur weiter unten, von ihnen steht nur noch eine im Katalog.

Die letzte Zeile ist die schlechteste der Tabelle, und sie war der Faden, an dem sich der Rest aufzog.

Zwei Layout-Modelle am selben Dokument

Vor dem Bauen standen zwei Kandidaten für die Layout-Stufe nebeneinander, und die Entscheidung fiel im Juni an einem gemeinsamen Testdokument. Das gewählte Modell erkannte am selben Blatt vier Strukturblöcke, wo der andere zwei fand, und es liefert feinere Klassen: Kopfzeile, Fußzeile und Zwischentitel getrennt statt einer Sammelkategorie.

Ein dritter Kandidat schied aus, und der Grund ist lehrreicher als die Entscheidung. Er kippte bei ganzen Seiten in eine Wie­der­ho­lungs­schleife und produzierte denselben Satzteil bis zum Abbruch. Die Deutung damals lautete, das Modell sei ungeeignet. Sie war falsch. Seine strukturierte Ausgabe entsteht aus derselben zweistufigen Verarbeitung, die hier gebaut wurde. Über die ganze Seite auf einmal war er nie gedacht. Der Kandidat taugte, die Benutzung war der Fehler.

Aus derselben Messreihe stammt eine Zahl, die eine naheliegende Idee erledigte. Höhere Auflösung sollte die Erkennung verbessern, also lief dasselbe Dokument mit 200 und mit 350 Bildpunkten je Zoll. Das Ergebnis: 63,1 gegen 64,2 Sekunden je Seite, und die Qualität blieb gleich. Was dagegen half, war eine Wie­der­ho­lungs­strafe beim Erzeugen, die den Modelllauf um 15 Prozent verkürzte, weil sie die Schleifen bricht.

Der Vergleich sah auf die Zahl der erkannten Klassen. Wie gut eine einzelne Klasse erkannt wird, stand nicht auf dem Zettel, und es hat drei Monate gedauert, bis das auffiel.

Was hier reiner Text war und wie ein Bild behandelt wurde

Die 0,570 in der Tabelle oben gehört den Bild­un­ter­schriften. Der Wert ist niedrig, weil das Layoutmodell dort unsicher ist. Beim Nachsehen, was aus diesen fünf Blöcken geworden war, stand in allen fünfen dasselbe:

[figure_title]

Also nichts. Eine Bildunterschrift ist reiner Text, und zwar genau der Text, der einem Leser sagt, was die Grafik daneben zeigt. Sie stand in der Liste der Klassen, die als Bild gelten und einen Platzhalter bekommen, statt in der Liste, die gelesen wird. Dasselbe galt für Formeln: Sie wurden erkannt, gezählt und nie gelesen.

Das ließ sich reparieren, aber vorher fehlte etwas Grundsätzlicheres. Das Repo dieser Verarbeitung hatte keinen einzigen Prüfstand, und der Grund dafür stand im Programm selbst: Der gesamte Ablauf lag auf der obersten Ebene der Datei. Wer die Datei einliest, um eine einzelne Funktion daraus zu prüfen, startet damit einen vollständigen Verarbeitungslauf. Es gab keine Möglichkeit, irgendetwas einzeln zu messen.

Also zuerst eine reine Umordnung: Der Ablauf wandert in eine Funktion, die Zusammensetzung des Markdown wird eine eigene Funktion, und die Tabellen und Rechenschritte bleiben oben und werden einzeln aufrufbar. Der Beleg dafür, dass sich dabei nichts geändert hat, ist eine Gegenprobe. Derselbe Lauf über eine Seite mit eigenem Text und über einen echten Scan, davor und danach, und die Ergebnisse müssen Zeichen für Zeichen gleich sein. Sie waren es.

Erst danach der Prüfstand, und er misst den Teil, für den es kein Modell braucht: Label-Zuordnung, Lesereihenfolge, das Aussortieren doppelter Regionen, das Verschmelzen von Zeichnungen, die Kollisionsregel, die Schriftgrößen und das fertige Markdown. Die Testfälle bauen ihre PDFs selbst, es läuft kein Modell mit.

Eine Entscheidung darin hat mehr gefunden als der Rest zusammen. Die Liste der Klassen, gegen die geprüft wird, ist nicht abgetippt. Sie wird aus der Kon­fi­gu­ra­ti­ons­datei des Layoutmodells gelesen, die seine 20 Klassen aufzählt. Der erste Lauf meldete daraufhin:

• Sechs Klassen liefert das Modell, und die Zuordnung kannte sie nicht. Seitenzahlen, Randnotizen, Fußnoten, Formelnummern und zwei weitere fielen auf den Vorgabewert und landeten als Fließtext im Ergebnis. Seitenzahlen standen also mitten im Text.
• Sechs Einträge der Zuordnung liefert dieses Modell nie. Sie stammen von einem anderen Layoutmodell, das im Juni zur Wahl stand und verloren hat.

Die Tabelle, die die Struktur des Ergebnisses bestimmt, gehörte also zum falschen Modell. Melden konnte das keine Prüfung, weil es keine gab. Eine abgeschriebene Liste im Prüfstand hätte denselben Fehler wiederholt.

Repariert ist das jetzt, und die Reihenfolge war die vorgeschriebene: erst der Test, der fällt, dann der Eingriff. Der Prüfstand stand beim ersten Lauf auf 17 Befunden und steht heute auf null. Bild­un­ter­schriften und Formeln werden gelesen, Formeln bekommen dabei eine Anweisung, die eine mathematische Auszeichnung verlangt. Seitenzahlen werden verworfen, Randnotizen bleiben stehen, und diese beiden Entscheidungen stützen sich auf eine Auszählung der neun Blöcke jeder Sorte im Bestand.

Am echten Dokument gemessen, sechs Seiten, 75 Regionen: Aus dem Platzhalter wurde die Bildunterschrift, und fünf Seitenzahlen sind aus dem Fließtext verschwunden.

Ein Nachspiel hatte die Formel noch. Die Anweisung an das Modell verlangt ausdrücklich nur den Formelrumpf ohne Auszeichnung, weil die Auszeichnung beim Zusammensetzen gesetzt wird. Das Modell lieferte sie trotzdem mit, und im ersten echten Lauf stand eine vierfach geklammerte Formel im Ergebnis. Drei Zeilen darüber steht ein Kommentar, der genau davor warnt. Eine Anweisung an ein Modell ist eine Bitte, und der Riegel dagegen gehört in den Code.

Ob der Prüfstand wirklich misst, sagt ein zweiter Lauf daneben, der siebenunddreißig gezielte Veränderungen in das Programm setzt und prüft, dass jede einzelne gemeldet wird. Beim ersten Durchgang blieben zwei unbemerkt, und beide Male lag es am Testfall. Einer suchte einen Textausschnitt im Ergebnis, den das falsche Ergebnis ebenfalls enthält, konnte also gar nicht fallen. Der andere legte eine Grafik über einen Textblock, den sie vollständig überdeckte, und eine vollständige Überdeckung berührt keine Schwelle zwischen null und eins. Beide sind seither anders gebaut.

Die fünf Veränderungen für die Achsenregel brachten eine dritte Spielart. Eine davon brachte das Programm zum Hängen: Sie senkte die Schwelle von zwei berührten Regionen auf eine, und dann verschmolz derselbe Strich immer wieder mit dem Ergebnis seiner eigenen Verschmelzung. Eine Veränderung, die das Programm hängen lässt, misst nichts. Der eigentliche Befund war aber, dass die Schleife überhaupt an dieser Zahl endete. Ein Strich, der einmal verbunden hat, wird seither aus der Liste genommen, womit das Ende in der Bauform steckt statt in einer Bedingung. Jetzt fallen siebenunddreißig von siebenunddreißig.

Was weiter fehlt

Zwei Lücken stehen benannt da. Auf einem gescannten Blatt geht eine Grafik nie an ein Modell, sie bleibt ein Platzhalter; den Weg dorthin gibt es nur für Seiten mit eigenem Text. Die Mehrspaltigkeit bleibt bei dem Zeilenband aus dem Abschnitt über die Reihenfolge.

Die Regel gegen die doppelte Beschriftung greift aus demselben Grund nur auf Seiten mit eigenem Text. Auf einem Scan gibt es keinen exakten Text, gegen den sich eine Abschrift halten ließe, und damit auch keine Doppelung. Für die Tabellenstruktur gilt dasselbe: Ohne Zeichen in der Datei bleibt nichts, womit sich eine Zelle füllen ließe.

Eine Lücke ist am 08.09.2026 dazugekommen. Eine verbundene Zelle lässt sich im Ausgabeformat nicht abbilden; ihr Inhalt steht in der ersten Spalte, die überdeckten bleiben leer.

Die größte ist am 25.09.2026 beim Nachzählen aufgefallen. Die Einordnung am Anfang zählt die Zeichen einer Seite, ihre Herkunft bleibt ungeprüft. Damit sich ein Scan durchsuchen lässt, legen Scanprogramme über das Bild eine unsichtbare Textschicht aus ihrer eigenen Erkennung. Eine solche Seite hat Zeichen im Text-Layer und geht den Weg ohne Modell. Von den 66 Seiten, die im Bestand als Seiten mit eigenem Text gelten, sind acht in drei Dokumenten genau das: ein Bild über die ganze Seite und darüber zwischen 316 und 3726 Zeichen, von denen keines sichtbar ist. Was die Verarbeitung dort als exakten Text behandelt, ist die Abschrift eines fremden Programms, die niemand gegengelesen hat. Die Datei verrät das selbst, denn ein PDF kennzeichnet unsichtbaren Text als solchen. Gezählt sind die acht Seiten über genau diese Kennzeichnung; in die Einordnung eingebaut ist sie noch nicht.

Was ein gemieteter Dienst anders macht

Die naheliegende Gegenfrage lautet, warum man so etwas selbst baut. Die großen Cloud-Anbieter vermieten dieselbe zweistufige Bauform als fertigen Dienst, bei Microsoft etwa als Layoutmodell von Document Intelligence.

Gegen die Lücken oben gehalten, bringt es laut Dokumentation einiges mit, das hier fehlt. Absätze bekommen eine Rolle, darunter Titel, Zwischentitel, Kopf- und Fußzeile (externe Seite, learn.microsoft.com), Fußnote und Seitenzahl. Zu jeder Tabellenzelle gibt es eine Angabe, ob sie zum Tabellenkopf gehört (externe Seite, learn.microsoft.com), und die fehlt in der Doku­men­ten­er­ken­nung des Betriebssystems. Verbundene Zellen stehen im Markdown als HTML-Tabelle (externe Seite, learn.microsoft.com), damit ist die Lücke aus dem vorigen Abschnitt dort geschlossen. Eine Grafik bekommt ihre Bildunterschrift als eigenes Feld, und zu jeder Textzeile gibt das Modell an, ob sie handschriftlich aussieht (externe Seite, learn.microsoft.com). Wie gut das an diesem Bestand abschneiden würde, zeigt keine Messung; alles Genannte sind Herstellerangaben.

Zwei Dinge liefert der Dienst in anderer Form, als dieser Aufbau sie braucht. Eine Grafik ist dort eine Region mit Rahmen und Bildunterschrift. Eine Tabelle mit einem Wert je Kategorie entsteht erst in einem zweiten Dienst, der mit generativer KI arbeitet (externe Seite, learn.microsoft.com) und zu jedem Wert die Stelle im Dokument (externe Seite, learn.microsoft.com) nennt, aus der er stammt. Und ob das Layoutmodell bei einem PDF die Zeichen der Datei übernimmt oder die Seite neu liest, sagt die Dokumentation nicht. Den eingebetteten Text übernimmt es ausdrücklich bei Word, Excel, PowerPoint und HTML (externe Seite, learn.microsoft.com), für PDF steht dazu weder auf der Seite zum Layoutmodell etwas noch auf der zum Lesemodell. Genau daran hängt die Arbeitsteilung, mit der dieser Bericht schließt.

Bleibt der Grund, aus dem der Aufbau lokal läuft. Den Dienst gibt es auch als Container für das eigene Rechenzentrum, in der aktuellen Fassung für das Lese- und das Layoutmodell (externe Seite, learn.microsoft.com). Ein solcher Container schickt laut Microsoft keine Dokumentinhalte (externe Seite, learn.microsoft.com) nach draußen, muss für die Abrechnung aber ständig mit Azure verbunden (externe Seite, learn.microsoft.com) sein. Ein Gerät ohne Verbindung nach draußen, wie der Mac Mini hier, kommt dafür nicht in Frage.

Wie die Dienste der anderen Anbieter gebaut sind, steht im Fachartikel zur Dokumentzerlegung.

Die Reichweite dieser Messung

Ein Gerät, ein Bestand, 113 Seiten aus einer Menge, die niemand nach statistischen Gesichtspunkten gewählt hat. Es gibt keinen Referenzsatz mit hinterlegter Wahrheit, gegen den sich eine Fehlerrate rechnen ließe.

Auch die 15 Tabellen sind eine Selbstauskunft, diesmal die des Betriebssystems. Ob eine Fläche mit Zeilen und Spalten wirklich eine Tabelle ist, entscheidet dort ein Modell, und gegengeprüft hat das niemand. Eine der 15 ist ein Formularraster.

Die Erkennungswerte in der Tabelle sind die Selbstauskunft des Layoutmodells. Geprüft hat sie niemand gegen eine Vorgabe. Sie sagen, wie sicher das Modell war, und sagen nichts darüber, ob es recht hatte. Die Frage aus KI jenseits der Sprachmodelle, Kapitel 05, ob eine Zelle in der richtigen Spalte gelandet ist, misst hier gar nichts.

Auch die Auflösungsmessung ist schwächer, als sie aussieht. 63,1 gegen 64,2 Sekunden sind ein Unterschied von unter zwei Prozent, und die eigene Streuung zwischen zwei gleichen Läufen wurde nie erhoben. Der Unterschied kann Rauschen sein. Wie man das richtig macht, steht in einem früheren Bericht: erst die Streuung messen, dann die Wirkung.

Zwei Befunde zum Schluss, die zusammengehören. Die Dokumentation dieser Verarbeitung behauptete an drei Stellen, PyTorch sei nach dem Auswahltest wieder entfernt worden. Es liegt heute wieder da, als Abhängigkeit zweier anderer Pakete. Gemeldet hat das keine Messung. Und der Auswahltest selbst beruhte auf einer Rangliste, die inzwischen als ausgereizt gilt, mit Abständen von Zehntelpunkten an der Spitze.

Was daraus folgt, ist eine Beobachtung. Zwei Stellen dieser Verarbeitung entscheiden mit einem Modell, und die Fehler der letzten Monate lagen an keiner von beiden: in einer Zuordnungstabelle, in einer Schwelle, in einem Filter für dünne Linien, in einer Seitendrehung, in einer Annahme über Scans.

Die zweite Stelle ist dabei die interessantere. Sie liefert allein die Struktur, ihre Abschrift bleibt ungefragt. Wo eine Datei die Zeichen enthält, mit denen sie gesetzt wurde, ist das die bessere Arbeitsteilung: Das Modell sagt, wo die Felder liegen, und die Datei sagt, was darin steht.