13.07.2024 AI Engineering 5 Minuten Lesezeit

Strukturierte Dokumentenextraktion mit Vision-LLMs

Wie Rechnungen und Verträge 2024 mit Vision-LLMs zu schema-validiertem JSON werden: was GPT-4o, Claude 3.5 Sonnet und Gemini 1.5 Pro auf Dokumenten leisten, welche Genauigkeitsspannen in der Produktion realistisch sind, warum der Validator vor dem Prompt entsteht und wo menschliche Prüfung strukturell notwendig 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 ist ein dauerhafter Betriebsaufwand. Die eigentlich lohnende Aufgabe ist eine andere: beliebiges Dokument hinein, schema-validiertes JSON heraus — auch bei Layouts, die das System nie gesehen hat.

Wir definieren die Aufgabe präzise: Gegeben ein Dokumentbild und ein Zielschema, erzeuge ein JSON-Objekt, das dem Schema entspricht, nur im Dokument belegte Werte enthält und alles andere als null markiert. Jede Designentscheidung in diesem Artikel folgt aus dieser Definition.

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

Vision-Modelle lesen die Seite direkt

2024 wurde das 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. Der separate OCR-Schritt entfällt. Das Modell sieht, was ein Sachbearbeiter sieht: Tabellen, Stempel, Checkboxen, handschriftliche Randnotizen.

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

Benchmark und Produktion sind verschiedene Verteilungen. Produktionsdokumente sind schiefe Scans, Faxe und fotografiertes Papier; Produktionsschemata haben 20 bis 50 Felder pro Dokument statt einer Frage. Unsere Beobachtungen aus Projekten, bewusst als Spannen formuliert: Kopffelder digital erzeugter Rechnungen — Lieferant, Datum, Bruttobetrag — liegen über 95 Prozent; Positionszeilen, Handschrift und Stempel deutlich darunter; degradierte Scans noch einmal darunter.

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.

Eine fehlgeschlagene Validierung löst genau einen Retry aus, mit der Fehlermeldung des Validators im Kontext; der zweite Fehlschlag leitet das Dokument an einen Menschen weiter. Die Grenze gehört klar benannt: Validierung erkennt inkonsistente Werte, nicht falsche. Ein falsch gelesenes Lieferdatum besteht jede Regel. Validierung verkleinert den unentdeckten Fehlerraum. Sie schließt ihn 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 fällt der Preis pro Seite weiter. 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. Damit wird der Zwei-Modell-Abgleich zum Standard statt zum Luxus. Drittens verschwindet die menschliche Prüfung nicht. Sie rückt in der Wertschöpfung nach oben — vom Abtippen zum Schlichten markierter Abweichungen. Wir entwerfen Systeme für diese Rolle, nicht für ihre Abwesenheit.