13.07.2024 AI Engineering5 Minuten Lesezeit

Strukturierte Dokumentenextraktion mit Vision-LLMs

Vision-LLMs können Rechnungen und Verträge 2024 direkt in schema-validiertes JSON überführen. Wir prüfen, was GPT-4o, Claude 3.5 Sonnet und Gemini 1.5 Pro auf Dokumenten leisten, welche Genauigkeitsspannen in Produktion realistisch sind, warum der Validator vor dem Prompt entsteht und an welchen Stellen menschliche Prüfung unverzichtbar bleibt.

Rechnungen kommen als Pixel

Eine Rechnung ist kein Text. Sie ist ein Layout: Lieferantenblock oben links, Betragstabelle in der Mitte, Zahlungsziel in der Fußnote. Reine PDF-Textextraktion verwirft diese Geometrie. Gescannte Seiten und Smartphone-Fotos enthalten gar keine Textebene. Verträge fügen ein zweites Problem hinzu: Die relevante Klausel steht irgendwo auf dreißig Seiten Standardtext.

Die klassische Antwort ist OCR plus Templates — Regeln pro Lieferant, die Seitenkoordinaten auf Felder abbilden. Templates funktionieren, bis ein Lieferant sein Layout ändert; Hunderte davon zu pflegen verursacht dauerhaften Betriebsaufwand. Die lohnendere Aufgabe lautet deshalb: ein beliebiges Dokument hinein, schema-validiertes JSON heraus — selbst bei Layouts, die das System noch nie gesehen hat.

Die Aufgabe lässt sich präzise formulieren: Aus einem Dokumentbild und einem Zielschema entsteht ein JSON-Objekt, das dem Schema entspricht, ausschließlich belegte Werte enthält und alle übrigen Felder als null markiert. Diese Definition ist keine Formalität; aus ihr folgen sämtliche Designentscheidungen des Artikels.

Ein Dokument kommt an — Scan, Mail oder Upload. 1/4

Vision-Modelle lesen die Seite direkt

Im Jahr 2024 wurde dieser Ansatz praktikabel. GPT-4o (13. Mai 2024), das aktualisierte Gemini 1.5 Pro (allgemein verfügbar seit Mai 2024) und Claude 3.5 Sonnet (20. Juni 2024) akzeptieren Seitenbilder direkt. Damit entfällt der separate OCR-Schritt: Das Modell sieht Tabellen, Stempel, Checkboxen und handschriftliche Randnotizen so, wie sie auch einem Sachbearbeiter vorliegen.

DocVQA (Mathew et al., 2021) ist der Standard-Benchmark für Dokumentverständnis: 50.000 Fragen zu 12.767 Dokumentbildern, bewertet per ANLS. Die Zahlen unten stammen aus dem Model-Card-Addendum von Anthropic vom Juni 2024. Ein Vorbehalt: DocVQA stellt Einzelfragen. Ein vollständiges Schema mit Dutzenden voneinander abhängigen Feldern zu extrahieren ist schwieriger, und kein Benchmark-Wert überträgt sich eins zu eins darauf.

Modell	Release	DocVQA (test, ANLS)
Claude 3.5 Sonnet	Jun 2024	95,2 %
Gemini 1.5 Pro	Mai 2024 (GA)	93,1 %
GPT-4o	Mai 2024	92,8 %
GPT-4 Turbo	Apr 2024	87,2 %

Schema zuerst statt Prompt zuerst

Wir empfehlen eine feste Reihenfolge: erst das Schema, dann der Prompt. Das Zielschema ist JSON Schema — Typen, Enums, Formatvorgaben, Pflichtfelder. Ein Feld, das das Dokument nicht enthält, muss null sein, niemals eine Schätzung; diese Regel gehört in die Schemabeschreibung und in den Prompt. Das Schema ist zugleich der Vertrag, gegen den das nachgelagerte System testet — und damit der natürliche Ort für Domänenwissen wie zulässige Währungscodes.

Die APIs von 2024 helfen, schließen die Lücke aber nicht. Der JSON-Modus von OpenAI (November 2023) garantiert syntaktisch gültiges JSON — nicht die Konformität zu Ihrem Schema. Function Calling (Juni 2023) und Tool Use von Anthropic (allgemein verfügbar seit Ende Mai 2024) nehmen ein Schema entgegen und lenken die Ausgabe stark dorthin. Keines davon garantiert Konformität. Jede Antwort muss durch einen Validator; das ist keine Paranoia, sondern das Design.

Genauigkeit im Benchmark und in der Produktion

Zwischen Benchmark und Produktion liegt ein Verteilungswechsel. Reale Dokumente sind schiefe Scans, Faxe und fotografiertes Papier; reale Schemata umfassen 20 bis 50 Felder pro Dokument statt einer einzelnen Frage. Unsere Projektbeobachtungen formulieren wir deshalb bewusst als Spannen: Kopffelder digital erzeugter Rechnungen — Lieferant, Datum, Bruttobetrag — liegen über 95 Prozent; Positionszeilen, Handschrift und Stempel deutlich darunter, degradierte Scans nochmals niedriger.

Die dominante Fehlerklasse sind lange Identifikatoren: IBANs, Rechnungsnummern, Bestellreferenzen. Ein einzelner Zeichendreher ist in flüssiger Ausgabe unsichtbar. Vision-LLMs scheitern zudem anders als OCR. Sie produzieren keine verstümmelten Zeichen — sie produzieren plausible falsche Werte, gelegentlich auch einen Wert für ein Feld, das im Dokument gar nicht vorkommt. Ein plausibler Fehler ist schlimmer als ein offensichtlicher, weil er korrekt aussieht.

Validierung vor Vertrauen

Wir bauen diese Pipelines validation-first: Der Validator existiert, bevor der erste Prompt geschrieben wird. Drei Ebenen. Syntaktisch — die Ausgabe parst und entspricht dem JSON Schema. Semantisch — IBAN-Prüfziffern nach ISO 13616, USt-IdNr.-Muster, parsbare Datumsangaben, bekannte Währungscodes. Arithmetisch — Netto plus Steuer gleich Brutto, Positionen summieren sich zum Rechnungsbetrag, Vertragsdaten sind zeitlich geordnet.

Schlägt die Validierung fehl, erlauben wir genau einen Retry und geben dem Modell die Fehlermeldung des Validators mit. Ein zweiter Fehlschlag leitet das Dokument an einen Menschen weiter. Dabei bleibt die Grenze klar: Validierung erkennt inkonsistente, nicht zwangsläufig falsche Werte. Ein falsch gelesenes Lieferdatum kann jede Regel bestehen. Validierung verkleinert den unentdeckten Fehlerraum, schließt ihn aber nicht.

Menschliche Prüfung bei niedriger Konfidenz

Vision-LLMs liefern keine kalibrierte Konfidenz pro Feld. Der technische Bericht zu GPT-4 (März 2023) zeigte, dass die Kalibrierung nach RLHF nachlässt; Token-Logprobs sind auf Feldebene bestenfalls ein schwacher Proxy. Spezialisierte Dienste — Amazon Textract, Azure AI Document Intelligence — liefern dagegen Konfidenzwerte pro Feld. Das bleibt ein reales Argument für hybride Pipelines.

Ein brauchbarer Ersatz ist Übereinstimmung. Extrahieren Sie jedes Dokument zweimal — zwei Läufe oder zwei verschiedene Modelle — und vergleichen Sie pro Feld. Übereinstimmung plus bestandene Validierung: automatische Übernahme. Abweichung, ein Validierungsfehler oder ein geschäftskritisches Feld wie die Empfänger-IBAN: eine Review-Queue, in der ein Mensch Dokument und extrahierten Wert nebeneinander sieht. Ziel ist, dass Prüfer markierte Felder bearbeiten, nicht jedes Dokument. Welcher Anteil markiert wird, hängt von der Dokumentqualität ab — ehrliche Projekte messen das, statt es zu versprechen.

Ausblick im Juli 2024

Drei Erwartungen vom Stand Juli 2024. Erstens wandert Schemakonformität auf die Serverseite. Constrained Decoding ist in Open Source erprobt — llama.cpp-Grammatiken, die Outlines-Bibliothek — und wir erwarten harte Schemagarantien von den großen API-Anbietern, die Retry-Schleifen auf der syntaktischen Ebene ablösen. Die semantische und die arithmetische Ebene bleiben unsere Aufgabe.

Zweitens wird der Preis pro Seite weiter fallen. GPT-4o kostet in der API bereits die Hälfte von GPT-4 Turbo; Gemini 1.5 Flash und Claude 3 Haiku markieren die Richtung der kleinen Modelle. Dadurch dürfte der Zwei-Modell-Abgleich vom Luxus zum Standard werden. Drittens verschwindet die menschliche Prüfung nicht, sondern wandert in der Wertschöpfung nach oben — vom Abtippen zum Schlichten markierter Abweichungen. Wir entwerfen Systeme für genau diese Rolle, nicht für ihre Abschaffung.