Dokumenten-Parser selber bauen vs. kaufen: Sechs Dateien, die unseren zuerst lahmgelegt haben

Ein Graustufen-TIFF hat einmal unsere Texterkennung zum Absturz gebracht. Es war eigentlich nichts daran auszusetzen: Es speicherte lediglich 16 Bits pro Pixel, während der meiste Bildverarbeitungscode nur 8 Bit erwartet.

Jeder produktive Parser sammelt mit der Zeit solche Dateien an. Wenn Sie vor der Entscheidung "Dokumenten-Parser selber bauen vs kaufen" stehen und planen, Ihren eigenen Dokumenten-Parser basierend auf einem LLM zu entwickeln, bietet Ihnen dieser Beitrag eine Vorschau auf Ihre zukünftige Support-Warteschlange.

Wichtige Erkenntnisse

• Ein Prototyp für einen Dokumenten-Parser auf Basis eines LLMs erfordert etwa ein Wochenende Arbeit. Ihn jedoch so zu entwickeln, dass er echte Kundendateien fehlerfrei verarbeitet, dauert Jahre.
• Die meisten Fehler passieren, bevor das LLM das Dokument überhaupt sieht: Schriftarten weisen Zeichen falsch zu, Seitenrahmen beginnen unter Null, Scans verwenden 16-Bit-Pixel und Wasserzeichen überlagern den Text.
• Ein besseres Modell behebt diese Fehler nicht. Es rät lediglich besser bei Eingaben, die bereits fehlerhaft sind.
• Die Codebasis von Parseur enthält schätzungsweise 150 bis 300 Korrekturen für ungewöhnliche Eingaben aus der realen Welt, die über 4.588 Commits seit 2015 erstellt und durch 294 Testdateien abgesichert wurden.
• Jeder Fix begann mit einer Kundendatei, die fehlschlug. Ein Team, das einen eigenen Parser baut, wird durch eigene Support-Tickets unweigerlich auf exakt dieselben Dateien stoßen.
• Selber bauen ist sinnvoll, wenn Dokumente aus wenigen bekannten Quellen stammen, deren Format sich nie ändert. Kaufen ist die bessere Wahl, wenn die Dokumente von verschiedenen Kunden und Lieferanten kommen.

Warum Ihr Wochenend-Parser an der ersten echten Kundendatei scheitert

Ein Wochenend-Dokumenten-Parser scheitert an echten Dateien, weil der schwierige Teil nicht die KI ist, sondern all das, was eine Datei erst in ein Format verwandelt, das die KI lesen kann. Das LLM erhält lediglich Text oder Pixel. Wenn die Schriftart lügt, der Seitenrahmen seltsam ist oder das Bildformat ungewöhnlich konfiguriert wurde, liest das Modell Müll und antwortet trotzdem voller Überzeugung.

Es hat bei Ihren Testdateien funktioniert, weil Ihre Testdateien einfach und aufgeräumt waren.

Echte Kundendateien sind jedoch komplex und fehleranfällig. Wir beheben diese Anomalien seit 2015. Unsere Codebasis zählt 4.588 Commits, und wir schätzen, dass 150 bis 300 davon ungewöhnliche Eingaben aus der realen Welt abfangen. 294 Testdateien stellen sicher, dass diese Fehler dauerhaft behoben bleiben – und bei vielen davon handelt es sich genau um das Kundendokument, das ursprünglich den Absturz verursacht hat.

Hier sind sechs unserer Favoriten.

Das PDF zeigt Text. Die Textebene ist da anderer Meinung.

Ein PDF, das Text auf dem Bildschirm anzeigt, speichert diesen Text nicht immer auf lesbare Weise. Drei Dateien haben dies eindrucksvoll bewiesen.

1. (cid:72) bedeutet "e", wenn man 29 addiert

Einige PDFs speichern keine Buchstaben. Sie speichern die Nummer der Zeichnung jedes Buchstabens innerhalb der Schriftart, ein bisschen wie eine Sitzplatznummer in einem Theater. pdfminer, die Bibliothek, die wir verwenden, um PDF-Text auszulesen, kann diese Nummer nicht wieder in einen Buchstaben umwandeln und gibt daher einen Code wie (cid:72) zurück.

Der Trick: Viele dieser Schriftarten listen ihre Zeichnungen in der gleichen Reihenfolge auf, nämlich der Standard-Mac-Reihenfolge. In dieser Liste ist das Leerzeichen die Zeichnung Nummer 3. In ASCII, den Zahlen, die Computer für Buchstaben verwenden, ist das Leerzeichen 32. Jeder Buchstabe weicht also um dieselben 29 ab. Addieren Sie 29 zu 72 und Sie erhalten 101, die ASCII-Zahl für "e".

Ohne diese Korrektur liest sich eine Rechnungssumme wie eine Reihe von (cid:...)-Codes. Das LLM sieht Rauschen und muss raten.

2. TToottaall

Einige PDF-Tools zeichnen jedes Zeichen zweimal an genau derselben Stelle, wahrscheinlich um eine fette Schriftart vorzutäuschen. Auf dem Bildschirm sieht es gut aus. In der Textebene wird aus "Total" jedoch "TToottaall".

Unsere Lösung entfernt jedes Zeichen, das an exakt derselben Position wie ein anderes sitzt. Einfach, sobald man weiß, dass es passiert.

3. Die Schriftart, die über ihre eigene Kodierung lügt

Der PDF-Standard besagt, dass eine TrueType-Schriftart ihre Zeichen in UTF-16BE abbildet. Einige Schriftarten in der Praxis behaupten in ihrer Zeichentabelle jedoch, sie seien UTF-8. pdfminer glaubt ihnen und liest Müll aus.

Wir haben pdfminer selbst gepatched, um diese Behauptung zu ignorieren und diese Schriftarten so zu dekodieren, wie sie tatsächlich geschrieben wurden. Eine Open-Source-Bibliothek deckt eben nur den Standard ab. Für die Patches darüber hinaus sind Sie selbst verantwortlich.

Wo beginnt eine Seite? Nicht immer bei Null

4. Eine gültige A4-Seite, die 0 pt hoch ist

Ein PDF-Seitenrahmen besteht aus zwei Ecken: unten links und oben rechts. Die meisten PDFs beginnen am Punkt (0, 0), sodass die letzten beiden Zahlen praktischerweise der Breite und Höhe entsprechen. Code, der nur diese beiden Zahlen liest, funktioniert bei fast jeder Datei.

Dann kam ein PDF mit einem Seitenrahmen von [0, -841.89, 595.28, 0] an. Das ist eine normale A4-Seite, die unter Null beginnt. Wenn man sie auf die einfache Art ausliest, ist sie 0 pt hoch. Unsere Auflösungsprüfung lehnte das Dokument daher als ungültig ab. Jeder PDF-Viewer öffnet es hingegen, ohne mit der Wimper zu zucken.

Bilder mit mehr Bits, als Sie eingeplant haben

5. Der 16-Bit-Scan

Zurück zum TIFF aus der Einleitung. Seine Pixel verwendeten 16 Graustufen-Bits, und die Konvertierung vor der OCR-Texterkennung schlug fehl. Unsere Lösung konvertiert das Bild nun aus seinem eigenen Wertebereich sicher in 8 Bits. Dieses Detail ist wichtig: Einige Scanner schreiben 12-Bit-Daten in eine 16-Bit-Datei, und bei einer simplen Konvertierung würde der gesamte Scan schwarz werden.

Rauschen, das sich wie Text liest

6. Das ENTWURF-Wasserzeichen, das sich in den Satz einfügt

Ein diagonales "DRAFT"-Wasserzeichen (Entwurf) besteht ebenfalls aus Text. Seine Buchstaben landen genau zwischen den echten Wörtern, und der extrahierte Text kann sich leicht in "Total DR 1,250.00 AFT" verwandeln. Ihr LLM wird sich sehr anstrengen müssen, um daraus einen Sinn zu machen.

Der Fix verwirft gezielt Zeichen, die leicht gedreht sind. Echter Text sitzt flach auf der Linie. Ein Wasserzeichen ist geneigt.

Die wahren Kosten des Selberbauens: Ihre Kunden werden zu Ihrer Test-Suite

Jeder der oben genannten Fixes begann mit einer Kundendatei, die fehlschlug, und keiner dieser Fehler lässt sich durch reines Lesen der PDF-Spezifikation vorhersehen. Ein Team, das seinen eigenen Dokumenten-Parser baut, wird durch eigene Support-Tickets unweigerlich in seiner eigenen Reihenfolge auf genau dieselben Dateien stoßen.

Jedes Mal wird dieselbe Schleife durchlaufen: ein verwirrter Benutzer, eine Beispieldatei, stundenlange Suche nach der Ursache, ein Fix und ein Test, damit der Fehler nie wiederkehrt. Multiplizieren Sie diesen Aufwand nun mit ein paar Hundert.

Ein LLM überspringt diese Schleife nicht. Es liest exakt das, was die Extraktion ihm übergibt. Wenn die Extraktion falsch ist, liegt das Modell trotz hoher Zuversicht falsch, und niemand bemerkt es, bis eine Summe in der falschen Spalte landet. Unser Artikel über LLMs für die Dokumentenverarbeitung behandelt die Modellseite dieser Geschichte, und der Kostenvergleich zwischen Selberbauen und Kaufen liefert Zahlen für die technische Seite bei Rechnungen.

Wird das nächste Modell das nicht beheben?

Modelle verbessern sich alle paar Monate. Dadurch verschwindet jedoch keiner der sechs oben genannten Fehler. Ein intelligenteres Modell, das (cid:72) anstelle von "e" oder "DR 1,250.00 AFT" anstelle einer Summe erhält, kann nur besser raten. Ihr Modellanbieter liefert besseres logisches Denken. Er liefert jedoch keine verbesserte PDF-Pipeline.

Dokumenten-Parser selber bauen vs. kaufen: Wann sich welche Entscheidung lohnt

Ein eigener Parser ist sinnvoll, wenn Ihre Dokumente aus einigen wenigen bekannten Quellen stammen und sich ihr Format nie ändert. Ein fester Export aus Ihrem eigenen System ist ein gutes Beispiel. Der Wochenend-Prototyp könnte hierbei alles sein, was Sie jemals brauchen werden.

Entscheiden Sie sich für den Kauf, wenn Dateien von externen Kunden, Lieferanten und deren Scannern kommen. In diesem Fall wird jeder Grenzfall, den sie senden können, zu Ihrem eigenen Problem – und er trifft verlässlich als Support-Ticket bei Ihnen ein.

Bringen Sie uns Ihre schlimmste Datei

Ja, wir verkaufen einen Dokumenten-Parser, also lesen Sie diesen Beitrag ruhig mit diesem Gedanken im Hinterkopf. Die sechs oben genannten Dateien sind dennoch real, ebenso wie die mühsamen Support-Tickets dahinter.

Wir haben über 100 Millionen Dokumente verarbeitet, und sie überraschen uns immer noch. Die nächste merkwürdige Datei in Ihrem Posteingang hat gute Chancen, eine zu sein, der wir bereits begegnet sind und die wir erfolgreich gelöst haben.

Senden Sie uns also die Datei, an der Ihr bisheriges Tool gescheitert ist. Wenn sie Parseur ebenfalls lahmlegt, ist die Behebung fortan unser Problem.

Zuletzt aktualisiert am 11. November 2026