Wenn Dokumente zurückschlagen

Seite 1: Kontoübersicht, zwei Spalten. Seite 15: Dasselbe Konto, drei Spalten, andere Überschriften. Seite 47: Ein Scan mit einem Kaffeefleck. Seite 89: Die Seite mit den Summen, die sich auf Transaktionen beziehen, die Sie vor 70 Seiten extrahiert haben.

Das ist ein einzelnes „Dokument“.

Ihre Extraktions-Pipeline funktioniert wunderbar damit. Seite für Seite landet jede Transaktion in der richtigen Spalte. Beträge werden sauber geparst. Daten sehen korrekt aus. Sie liefern es aus.

Dann ruft die Buchhaltung an. Haben und Soll gehen nicht auf. Es fehlen 3.200 €. Nicht, weil eine einzelne Seite falsch war, sondern weil Seite 12 Kommas für Dezimalstellen verwendet und Seite 68 Punkte. Ihr Parser hat beides korrekt behandelt, isoliert betrachtet. Zusammen ergaben sie zwei unterschiedliche Interpretationen von „1.234“ und niemand bemerkte es, bis die Saldengleichung zusammenbrach.

Die Extraktion einzelner Seiten kann perfekt sein, während das Dokument als Ganzes Müll ist.

Ein Dokument, fünfzehn Persönlichkeiten

Lange Dokumente sind nicht monolithisch. Es sind zusammengestückelte Abschnitte mit unterschiedlichen Layouts, unterschiedlichen Scan-Qualitäten und unterschiedlichen Vorstellungen davon, wie Zahlen aussehen sollten.

Ein echter 120-seitiger Kontoauszug, den wir verarbeitet haben, hatte:

Layout-Wechsel: - Seiten 1-10: Hochformat, zweispaltige Transaktionstabelle - Seiten 11-50: Querformat, drei Spalten mit laufendem Saldo - Seiten 51-80: Zurück zum Hochformat, völlig andere Überschriften - Seiten 81-120: Zusammenfassungsseiten mit aggregierten Summen

Qualitätsunterschiede: - Seiten 1-40: Natives PDF, saubere Textebene - Seiten 41-60: Irgendwann gescannt, benötigt OCR - Seiten 61-80: Gescannt mit handschriftlichen Anmerkungen an den Rändern - Seiten 81-120: Wieder natives PDF

Semantische Überraschungen: - Drei separate Konten in einem Auszug gebündelt - Unter-Auszüge, die im Hauptauszug verschachtelt sind - Summen auf Seite 118, die sich auf eine Transaktion auf Seite 3 beziehen

Jedes Extraktionssystem, das dies als „ein Dokument, ein Durchlauf“ behandelt, wird Probleme bekommen. Das Layout auf Seite 11 macht Annahmen von Seite 1 ungültig. Die Scan-Qualität auf Seite 45 erfordert eine völlig andere Extraktionsstrategie als das saubere PDF auf Seite 5.

Die Frage ist nicht „haben wir jede Seite korrekt extrahiert?“. Sie lautet: „Haben wir das ganze Ding konsistent extrahiert?“

Was passiert, wenn man nicht aufteilt

Der naive Ansatz ist, das gesamte Dokument in einen Extraktionsdurchlauf zu werfen und auf das Beste zu hoffen. Hier ist, was tatsächlich passiert:

Kontextfenster laufen voll. Selbst große Modelle verschlucken sich an 120 Seiten Transaktionsdaten. Sie fangen an, Zeilen um Seite 40 herum fallen zu lassen, stillschweigend. Kein Fehler, keine Warnung. Einfach fehlende Transaktionen, die erst auftauchen, wenn jemand eine Abstimmung durchführt.

Layout-Verwirrung summiert sich. Das Modell lernt das zweispaltige Layout von den Seiten 1-10 und stößt dann auf Seite 11 auf drei Spalten. Manchmal passt es sich an. Manchmal führt es zwei Spalten zusammen und produziert Phantom-Transaktionen mit verketteten Beschreibungen. Auf Seite 51, wenn sich das Layout erneut ändert, ist alles möglich.

Eine schlechte Seite vergiftet alles. Dieser kaffeefleckige Scan auf Seite 47? In einer Single-Pass-Extraktion kaskadiert ein falsch gelesener Betrag. Der laufende Saldo verschiebt sich, das Modell „korrigiert“ nachfolgende Transaktionen, damit sie passen, und jetzt haben Sie plausibel aussehende Daten, die auf eine Weise falsch sind, die Sie nicht leicht erkennen können.

Die Lösung ist Segmentierung: Teilen Sie das Dokument in kohärente Stücke auf, extrahieren Sie jedes unabhängig und setzen Sie es dann mit segmentübergreifender Validierung wieder zusammen.

Aber das Layout ist nicht das Einzige, das über 120 Seiten variiert. Die physische Qualität der Seiten schlägt ebenfalls zurück.

Der Scanner gewinnt immer

Layout-Änderungen sind zumindest logisch. Jemand hat ein dreispaltiges Format für die Seiten 11-50 und ein zweispaltiges Format für den Rest entworfen. Man kann darüber nachdenken.

Scan-Qualität ist Chaos.

Ein 120-seitiger Kontoauszug kommt an. Seiten 1-40 sind natives PDF: saubere Textebene, perfekte Koordinaten, extrahierbar bis auf das Glyphen-Level. Dann kommt Seite 41 und die Textebene verschwindet. Jemand hat den Auszug ausgedruckt, wieder eingescannt und das Ergebnis zusammengeführt. Sie machen jetzt OCR auf Pixeln, anstatt Text aus einem strukturierten Dokument zu lesen.

Das ist der einfache Fall. Hier ist, was tatsächlich durch die Tür kommt:

Das Handyfoto. Jemand hat sein Handy über den Auszug gehalten, anstatt einen Scanner zu benutzen. Der Kamerablitz überstrahlt die obere rechte Ecke, genau dort, wo der Endsaldo steht. Das Bild ist in der Mitte scharf und an den Rändern unscharf. Überbelichtete Highlights erzeugen weiße Flecken, die Ziffern verschlucken. Wir erkennen dies, indem wir das Verhältnis überbelichteter Pixel und spiegelnde Highlight-Flecken messen. Wenn mehr als 15 % einer Seite ausgebrannt sind, sehen Sie auf ein Foto, nicht auf einen Scan.

Das 75-DPI-Fax-Relikt. Ein Auszug, der irgendwann in seinem Leben durch ein Faxgerät gelaufen ist. Die Auflösung ist so niedrig, dass eine „8“ und eine „6“ nicht zu unterscheiden sind. Eine „3“ könnte eine „8“ sein. Die OCR-Konfidenz fällt unter 50 %, und jetzt raten Sie bei Beträgen. Bei 75 DPI bricht die Kantenschärfe zusammen. Die Sobel-Gradienten-Magnitude, die bei einem sauberen Scan 15+ anzeigt, fällt unter 2,5. Einzelne Zeichen haben überhaupt keine Kanten mehr.

Das Hintergrund-Durchscheinen. Eine abgenutzte Walze im Dokumenteneinzug des Scanners hinterlässt einen grauen Streifen auf jeder Seite. Oder schlimmer: Tinte von der vorherigen Seite wurde beim Einzug übertragen, und jetzt hat Seite 47 Geistertext von Seite 46, der durchscheint. OCR weiß nicht, welche Textebene die echte ist. Es extrahiert beide, und plötzlich haben Sie Phantom-Transaktionen, die nicht existieren.

Der rotierte Abschnitt. Die Seiten 51-60 wurden im Querformat gescannt, aber die PDF-Metadaten sagen Hochformat. Der Text steht seitwärts. OCR kann manchmal mit 90-Grad-Rotation umgehen, aber 2-3 Grad Schräglage durch eine falsch ausgerichtete Seite im Einzug? Das verwandelt gerade Tabellenlinien in leicht gekrümmte, und die Spaltenausrichtung, das, worauf Ihre Extraktionslogik angewiesen ist, wird weich.

Die Qualitätsklippe innerhalb eines einzigen Dokuments:

Das ist das eigentliche Problem. Es ist nicht so, dass manche Dokumente schlechte Scans sind. Es ist so, dass Seite 40 makellos ist und Seite 41 schrecklich, in derselben Datei. Ihre Pipeline muss beide Extreme und alles dazwischen bewältigen, und sie muss pro Seite wissen, wie sehr sie dem vertrauen kann, was sie extrahiert hat.

Hier verdienen sich visuelle ML-Modelle ihr Geld. Traditionelle OCR starrt auf einzelne Zeichen und rät. Ein Vision-Modell sieht die ganze Seite: die Tabellenstruktur, die Spaltenausrichtung, den Kontext um diese kaffeefleckige Ziffer. Es kann „12.345,67 €“ lesen, selbst wenn das Dezimalkomma verdeckt ist, weil es versteht, wie ein Kontoauszug aussieht, nicht nur, was einzelne Glyphen bedeuten.

Der Wechsel von textbasierter OCR zu seitenweitem visuellen Verständnis macht degradierte Scans überlebbar. Ein Fax-Relikt, das die Zeichenerkennung besiegt, hat immer noch eine sichtbare Struktur: Zeilen, Spalten, Beträge an vorhersehbaren Positionen. Ein Vision-Modell, das Tausende von Kontoauszügen gesehen hat, kann aus dem Muster extrahieren, selbst wenn die Pixel grob sind.

Das Minenfeld der Saldengleichung

Für Kontoauszüge gibt es eine unerbittliche Gleichung: start_balance + credits - debits = end_balance.

Vier Wörter. Unendliche Möglichkeiten, sie zu brechen.

Seitenübergreifende Referenzen. Der Eröffnungssaldo steht auf Seite 1. Der Endsaldo steht auf Seite 120. Die Gleichung überspannt jedes Segment, jeden Lauf, jeden Layout-Wechsel dazwischen. Wenn irgendein Segment falsch extrahiert wird, bricht die Gleichung. Aber welches? Bei 7 Segmenten und 4.000 Transaktionen ist das Finden der schlechten Daten ein Problem für sich.

Transaktionen am Seitenumbruch. Eine Transaktionsbeschreibung erstreckt sich über die Seiten 47-48: - Seite 47: „ÜBERWEISUNG AN ACME CORP“ - Seite 48: „REF: 12345 - RECHNUNGSZAHLUNG“

Eine Transaktion oder zwei? Zählen Sie sie doppelt, und der Saldo weicht um genau einen Transaktionsbetrag ab. Die Art von Fehler, die plausibel aussieht, bis jemand prüft. Die Lösung ist Überlappung: Wenn wir das Dokument in Segmente aufteilen, werden Grenzseiten zwischen benachbarten Läufen geteilt. Beide Läufe sehen die Transaktion, aber der Aggregator dedupliziert beim Wiederzusammensetzen anhand der Seitenkoordinaten. Nur eine Kopie überlebt.

Gebietsschema-Roulette. Gleiche Bank, gleicher Auszug: - Segment 1: 1.234,56 € (Komma als Dezimaltrenner) - Segment 2: 1,234.56 € (Punkt als Dezimaltrenner)

Parsen Sie beide „korrekt“ nach ihrer lokalen Konvention und Sie erhalten zwei verschiedene Zahlen. Der Saldengleichung sind Konventionen egal. Sie sieht nur, dass die Summe falsch ist.

Vorzeichen-Konventions-Chaos. Bank A: Soll ist negativ. Bank B: alle Beträge positiv, mit einer separaten S/H-Spalte. Bank C: Soll in Klammern, (1.234,56). Die Gleichung geht von konsistenten Vorzeichen aus. Wenn die Extraktion vor dem Summieren nicht normalisiert, heben Haben und Soll sich gegenseitig auf und der Auszug sieht leer aus.

Die 0,02 € Toleranz-Falle. Ein 120-seitiger Auszug kann Tausende von Transaktionen haben, jede aus gerendertem Text geparst und mit dem Risiko von Rundungsfehlern auf Quellebene behaftet. Eine exakte Übereinstimmung zu verlangen, weist gültige Dokumente zurück. Zu viel Toleranz verbirgt echte Fehler. 0,02 € ist das, worauf wir uns nach dem Betrieb mit Produktionsdaten geeinigt haben. Eng genug, um Fehler zu fangen, locker genug, um Rundungen zu überstehen.

Strikt, dann schlau, dann verzweifelt

Als wir Holofins Validierungs-Pipeline bauten, versuchten wir, alle Korrekturen auf einmal laufen zu lassen. Das verschleierte Datenqualitätsprobleme. Dokumente, die hätten markiert werden sollen, rutschten durch. Also bauten wir sie in drei Stufen um. Die Reihenfolge ist das Design.

Stufe 1: Strikt. Jede Transaktion muss ein Wertstellungsdatum haben. Jeder Betrag muss parsbar sein. Die Saldengleichung muss innerhalb der Toleranz halten. Wenn strikt besteht, ist die Datenqualität hoch und wir sind fertig. Die meisten sauberen Dokumente stoppen hier.

Wenn strikt fehlschlägt, notieren wir, was fehlgeschlagen ist, und machen weiter.

Stufe 2: Normalisierung. Die Daten wurden sauber extrahiert, aber Konventionen kollidieren über Segmente hinweg. Gemischte Dezimaltrennzeichen: Kommas in Segment 1, Punkte in Segment 3. Mehrdeutige Daten: 01/02/2024 könnte der 1. Februar oder der 2. Januar sein, je nach Gebietsschema der Bank. Vorzeichenkonventionen, die zwischen Segmenten wechseln. Normalisierung vereinheitlicht diese, bevor die Saldenprüfung erneut durchgeführt wird.

Stufe 3: Menschliche Überprüfung. Wenn Automatisierung es nicht lösen kann, wird das Dokument für einen Operator markiert. Nicht „etwas ist falsch, viel Glück“, sondern „Segment 4, Seiten 41-60, die Haben-Beträge sind 3,20 € höher als erwartet. Fang dort an.“

Warum diese Reihenfolge wichtig ist: Strikt zuerst bewahrt die Datenqualität. Wir normalisieren nur, wenn strikt fehlschlägt. Wir schalten nur einen Menschen ein, wenn Normalisierung nicht ausreicht.

Alles auf einmal laufen zu lassen, würde Probleme maskieren. Ein Dokument, das menschliche Überprüfung benötigte, sollte anders behandelt werden als eines, das strikt bestanden hat. Die Reihenfolge ist das Qualitätssignal.

Wenn der Großteil des Dokuments in Ordnung ist

Sie haben das 120-Seiten-Monster segmentiert. Jedes Segment wurde unabhängig extrahiert. Qualitätsbewertungen pro Seite angehängt. Was nun?

Die Segmente müssen wieder zu einem Dokument werden. Eröffnungssaldo aus dem ersten Segment, Endsaldo aus dem letzten, jedes Haben und Soll über alle hinweg summiert. Dann läuft die Saldengleichung ein letztes Mal, nicht pro Segment, sondern über das ganze Ding.

Wenn es besteht, sind Sie fertig. Wenn es fehlschlägt, ist die interessante Frage, wo.

Hier treffen die meisten Pipelines die falsche Entscheidung. Der Saldo weicht um 3,20 € ab, also wird das gesamte Dokument abgelehnt. Der Operator lädt neu hoch, extrahiert neu, validiert neu, alle 120 Seiten, weil ein Segment gestolpert ist.

Das ist die falsche Antwort. In der Produktion sind die meisten Dokumente größtenteils korrekt.

Sagen wir, Segment 4 von 7 hat die Abweichung. Die anderen sechs Segmente sind sauber, validiert, abgestimmt, exportierbar. Wir werfen sie nicht weg. Wir markieren Segment 4, heben die Diskrepanz hervor und lassen den Operator den Konflikt mit dem Quell-PDF Seite an Seite lösen. Die gute Arbeit bleibt gut. Das schlechte Segment bekommt menschliche Aufmerksamkeit.

Die Quelle: ein echter Kontoauszug-Scan mit Qualitätswechseln mitten im Dokument

Die Extraktion: Bounding Boxes verfolgen jeden Wert zurück zu seiner Quelle, selbst auf beschädigten Seiten

Der Operator sieht genau, was repariert werden muss. Nicht „Ihr Dokument ist fehlgeschlagen“, sondern „Segment 4, Seiten 41-60, die Haben-Beträge sind 3,20 € höher als erwartet, und Seite 47 hatte eine niedrige OCR-Konfidenz (34 %). Fang dort an.“

Das ist der Unterschied zwischen einer Pipeline, die Dokumente verarbeitet, und einer, die die Zeit des Operators respektiert.

Die Prinzipien, die die Produktion überleben

Wenn Sie etwas Ähnliches bauen, sind dies die Lektionen, die hängen geblieben sind:

• Segmentieren vor dem Extrahieren. Behandeln Sie Layout-Änderungen als Grenzen, nicht als Rauschen.
• Messen vor dem Vertrauen. Qualitätsbewertungen pro Seite sagen Ihnen, wo die Extraktion fragil ist.
• Segmentübergreifend validieren, nicht nur innerhalb. Eine Seite kann korrekt sein, während das Dokument falsch ist.
• Geordnetes Rückfallen, der Reihe nach. Strikte Validierung zuerst. Normalisierung als Zweites. Menschliche Überprüfung zuletzt. Die Reihenfolge kodiert Qualität.
• Alles loggen, wonach der Benutzer nicht gefragt hat. Systemkorrekturen sind in der UI unsichtbar und im Audit-Trail sichtbar.

Kontoauszüge sind der Stresstest, Tausende von Transaktionen, mehrere Layouts, Scan-Qualität, die sich mitten im Dokument ändert, und eine Saldengleichung, die Perfektion über all das hinweg verlangt. Wenn Ihre Pipeline das überlebt, sind einseitige Rechnungen ein Rundungsfehler.

Extraktion ist auf Seite 1 gelöst. Konsistenz ist auf Seite 120 gelöst. Und der Raum dazwischen, die Layout-Wechsel, die Kaffeeflecken, die Fax-Relikte, die Vorzeichenkonventionen, ist dort, wo naive Pipelines sterben und sorgfältiges Engineering sich bezahlt macht.

Bauen Sie für das 120-Seiten-Monster vom ersten Tag an. Die Einseiter kümmern sich um sich selbst.