Wenn die Seite ein Bild ist, verliert die Textextraktion die Tabelle
Der Scan war sauber, die Erkennung genau, und die Ausgabe war falsch. Eine Tabelle über eine dreispaltige Seite hinweg von links nach rechts zu lesen erzeugt eine Folge korrekter Wörter in einer Reihenfolge, die etwas völlig anderes bedeutet.
Richtige Zeichen, falsche Daten
Ein Lieferschein kam mit einer dreispaltigen Tabelle herein: Artikel, Menge, Einheit. Der Scan war sauber, und die Zeichenerkennung machte keinen auffindbaren Fehler. Die extrahierten Mengen hingen trotzdem an den falschen Artikeln, durchgängig, bei jedem Dokument dieses Layouts.
Die Ursache ist, dass Textextraktion einen Strom erzeugt und eine Tabelle eine zweidimensionale Anordnung ist. Das eine in das andere zu plätten verwirft genau die Information, die die Tabelle zur Tabelle machte — und ein Modell, das den geplätteten Strom liest, kann sie nicht zurückgewinnen.
Warum es uns nicht früher auffiel
Jeder einzelne Wert war plausibel. Mengen waren Mengen, Artikelnummern waren Artikelnummern, und eine Validierungsregel für Typen und Wertebereiche ließ alle durch. Der Fehler lag in der Zuordnung zwischen Feldern — und genau die kann eine feldweise Prüfung nicht sehen.
Das gehört deutlich gesagt, weil es sich verallgemeinert. Eine Validierung, die jedes Feld für sich prüft, lässt einen Datensatz durch, in dem jeder Wert echt und die Kombination erfunden ist. Das ist einer der teureren Fehlermodi in der Dokumentverarbeitung.
Stattdessen das Bild schicken
Für diesen Dokumenttyp haben wir aufgehört, in Text zu wandeln, und schicken das Seitenbild an ein Modell, das Bilder annimmt — mit derselben Schema-Anforderung. Die Spalten sind im Bild sichtbar, die Zuordnung bleibt erhalten, und dasselbe Layout, das die Text-Pipeline zerlegte, ist für die visuelle unauffällig.
Das ist keine kostenlose Verbesserung. Bildeingabe kostet mehr je Dokument, ist langsamer, und die Fehlermodi sind andere statt abwesend: Ein Modell, das eine Seite liest, kann eine handschriftliche Notiz oder einen Stempel über einer Zahl weiterhin falsch lesen — und tut es dann ohne die Ausrede des Layouts.
Die Forschung hinter der Umstellung
McKinzie und Kollegen veröffentlichten in jenem Frühjahr MM1, eine Untersuchung dazu, worauf es beim Vortraining multimodaler Modelle tatsächlich ankommt — mit Befunden zur Bildauflösung, zur Zusammensetzung der Trainingsmischung und zum Aufbau der Verbindung zwischen visuellem Encoder und Sprachmodell.
Der Befund, den wir in die Praxis übernommen haben, betraf die Auflösung. Wenn der verfügbare Bilddetailgrad begrenzt, was ein Modell lesen kann, dann sind unsere Scan-Einstellungen Teil des Systems und kein Vorverarbeitungsdetail — und wir behandeln Auflösung seitdem als zu prüfenden Parameter statt als übernommene Voreinstellung.
| Merkmal des Dokuments | Was wir einsetzen |
|---|---|
| Fließtext, einspaltig | Textextraktion. Günstiger und ausreichend |
| Tabellen, mehrspaltiges Layout | Seitenbild an ein multimodales Modell |
| Formulare mit Kästchen oder Stempeln | Seitenbild, plus Prüfschwelle |
| Digitale Dokumente mit echter Struktur | Keines von beidem. Struktur direkt auslesen |
Die Zeile, die man nicht verlieren sollte
Die letzte Zeile dieser Tabelle wiegt schwerer als die anderen. Ein großer Teil dessen, was Kunden gescannte Dokumente nennen, sind digital erzeugte Dateien, die nie gedruckt wurden — und die tragen ihre Tabellenstruktur in der Datei.
Sie sauber auszulesen ist unspektakuläre Arbeit ganz ohne Modell und genauer als beide Alternativen. Wir prüfen das bei jedem neuen Dokumenttyp zuerst, und bei etwa einem Drittel hat es das Problem vollständig beseitigt.
Die Prüfung, die beide Wege absichert
Feldvalidierung reichte nicht, also haben wir eine dokumentspezifische Querprüfung ergänzt. Auf einem Lieferschein müssen Mengen mal Einzelpreise gegen die ausgewiesene Summe aufgehen, und ein Datensatz, in dem jedes Feld für sich gültig ist und die Rechnung nicht schließt, geht in die Prüfung.
Diese Prüfung hätte den ursprünglichen Fehler beim ersten Dokument gefangen statt beim vierzigsten. Sie ist auch das Stück, auf dem wir vor jeder unbeaufsichtigten Extraktion bestehen, gleich ob die Eingabe Text oder Bild ist — denn beide Wege können einen wohlgeformten Datensatz erzeugen, der falsch ist.
Was die Umstellung gekostet hat
Etwa das Vierfache je Dokument für die betroffenen Layouts und einen langsameren Schritt in einer Pipeline, in der niemand darauf wartete — die Latenz war also gleichgültig. Dem stand gegenüber, dass die Korrekturen eine Person rund zwei Stunden pro Woche kosteten und die Fehler, die den Kunden erreichten, erheblich mehr.
Wir haben nicht alles umgestellt. Zwei Drittel der Dokumenttypen laufen weiter über Textextraktion, weil sie Fließtext oder einfache Schlüssel-Wert-Layouts sind, wo sie genau und deutlich günstiger ist. Je Dokumenttyp zu entscheiden statt pauschal ist die gesamte Ersparnis.
Was wir nicht behaupten
Wir behaupten nicht, visuelle Modelle machten Textextraktion überflüssig. Für die meisten unserer Dokumente bleibt sie das richtige Werkzeug, und einen günstigen genauen Schritt durch einen teuren zu ersetzen, weil dieser einen Fall abdeckt, den man nicht hat, ist keine Verbesserung.
Wir behaupten auch nicht, ein Bild zu schicken erübrige die Kontrolle. Es ändert, welche Fehler auftreten, nicht ob sie auftreten — und genau deshalb ist die Abstimmprüfung geblieben.