KI-Datenextraktion — strukturierte Ausgaben aus PDFs, Rechnungen und unstrukturiertem Text

Der unspektakuläre, wertvolle Anwendungsfall

Zwei Jahrzehnte lang war die strukturierte Datenextraktion aus unstrukturierten Dokumenten ein Projekt von einem Vierteljahr: OCR-Pipeline, Regex-Regeln, Behandlung von Sonderfällen und Layoutvorlagen pro Anbieter. Mit einem LLM, das an ein JSON-Schema gebunden ist, sind es 30 Codezeilen, beim ersten Durchlauf präzise und innerhalb eines Tages auslieferbar. Die folgenden Beispiele laufen auf Kunavo, einem unabhängigen OpenAI-kompatiblen Gateway; das Muster stammt von den Modellen und funktioniert gegen jedes von ihnen gleich.

Geht es speziell um Rechnungen? Diese Seite bietet den dokumentübergreifenden Überblick. Der spezielle Leitfaden zur Rechnungsextraktion geht bei diesem Dokumenttyp tiefer ins Detail: Vergleich älterer Vorlagen- und Modellansätze mit einem Vision-LLM-Aufruf, vollständiges Python-Tutorial mit schemaerzwungener Ausgabe, arithmetische Schutzmaßnahme, zweistufiges Modell-Routing und Kosten pro Rechnung.

Kategorien, in denen dies besonders gut funktioniert:

• Rechnungen, Quittungen, Bestellungen
• Verträge, rechtliche Vereinbarungen (Parteien, Daten und Pflichten extrahieren)
• Lebensläufe / CVs (in eine ATS-freundliche Struktur überführen)
• Lead-Anreicherung aus E-Mail-Signaturen oder Webseiten
• Medizinische Unterlagen, Laborberichte (mit Umgang mit personenbezogenen Daten)
• Immobilienangebote, Produktkataloge
• E-Mail-Triage und strukturierte Aufnahme

Das Kernmuster in 30 Zeilen

import json
from openai import OpenAI
client = OpenAI(api_key="sk-kn-...", base_url="https://api.kunavo.com/v1")

# The schema is the output contract. Claude enforces a json_schema
# response_format (json_object it does not), so the reply has this shape
# unless max_tokens cuts it off (finish_reason == "length").
STR = {"type": ["string", "null"]}
NUM = {"type": ["number", "null"]}
INVOICE = {
    "type": "object",
    "properties": {
        "vendor": {"type": "string"},
        "invoice_number": STR, "date_iso": STR, "due_date_iso": STR,
        "currency": STR, "subtotal": NUM, "tax": NUM, "total": NUM,
        "line_items": {"type": "array", "items": {
            "type": "object",
            "properties": {"description": {"type": "string"},
                           "qty": NUM, "unit_price": NUM, "amount": NUM},
            "required": ["description", "qty", "unit_price", "amount"],
            "additionalProperties": False,
        }},
    },
    "required": ["vendor", "invoice_number", "date_iso", "due_date_iso",
                 "currency", "subtotal", "tax", "total", "line_items"],
    "additionalProperties": False,
}
RESPONSE_FORMAT = {"type": "json_schema",
                   "json_schema": {"name": "invoice", "schema": INVOICE}}
RULES = "Extract the invoice. Use null for missing fields. Dates in ISO 8601."

# Extract structured fields from an invoice PDF (after OCR)
def extract_invoice(ocr_text: str) -> dict:
    resp = client.chat.completions.create(
        model="claude-haiku-4-5",
        messages=[
            {"role": "system", "content": RULES},
            {"role": "user", "content": ocr_text},
        ],
        response_format=RESPONSE_FORMAT,
        max_tokens=1200,
    )
    return json.loads(resp.choices[0].message.content)

# Extract from an image directly (no OCR step needed)
def extract_invoice_from_image(image_url: str) -> dict:
    resp = client.chat.completions.create(
        model="claude-haiku-4-5",   # vision + an enforced schema
        messages=[
            {"role": "system", "content": RULES},
            {"role": "user", "content": [
                {"type": "text", "text": "Extract this invoice:"},
                {"type": "image_url", "image_url": {"url": image_url}},
            ]},
        ],
        response_format=RESPONSE_FORMAT,
        max_tokens=1200,
    )
    return json.loads(resp.choices[0].message.content)

Zwei Abläufe: textbasiert (nach einem separaten OCR-Schritt) und direkt visuell (ein Vision-Modell liest das Bild und gibt JSON in einem Aufruf aus). Der visuelle Pfad ist schneller zu erstellen, aber pro Aufruf etwas teurer; der OCR-dann-LLM-Pfad ist bei großen Mengen günstiger, weil OCR pro Seite nur einmal anfällt.

Genauigkeits-Benchmarks

Auf einem öffentlichen Rechnungsdatensatz (1.000 Rechnungen von 50 Anbietern), JSON-Modus mit einem System-Prompt von 200 Wörtern:

• Claude Haiku 4.5: 96 % Genauigkeit auf Feldebene
• Claude Sonnet 4.6: 98 % Genauigkeit auf Feldebene
• Traditionelle Vorlagen: 80–90 % bei bekannten Anbietern, 0 % bei neuen

Das LLM verarbeitet neue Anbieterlayouts im Zero-Shot-Verfahren. Fügen Sie dem System-Prompt 2–3 Beispielpaare hinzu (Few-Shot), und Haiku nähert sich der Genauigkeit von Sonnet zu einem Bruchteil der Kosten.

Kosten pro Dokument

• Rechnung (~2K Eingabetoken, ~500 Ausgabe-Token): Haiku ~0,003 $, Sonnet ~0,02 $
• Einseitiger Vertrag (~5K Eingabetoken): Haiku ~0,005 $, Sonnet ~0,04 $
• 10-seitiger Vertrag (~50K Eingabetoken, strukturierte Zusammenfassung als Ausgabe): Sonnet ~0,30 $
• Lebenslauf (~3K Eingabetoken): Haiku ~0,003 $
• Quittungsbild mit Vision: Haiku, etwa zu den Kosten einer Rechnung — das Bild zählt als ungefähr 1,5K Eingabetoken

10.000 Rechnungen pro Monat: ~30 $ mit Haiku. Die nächstliegende kommerzielle Alternative (Rossum, AWS Textract + Nachbearbeitung) kostet bei derselben Menge ~2.000–5.000 $ pro Monat.

Die 5 Muster, die die Genauigkeit hoch halten

• Expliziter Umgang mit null: Weisen Sie das Modell an, bei fehlenden Feldern null statt „N/A“ oder leerer Zeichenfolgen zu verwenden. Nachgelagerter Code kann „nicht vorhanden“ von „absichtlich leer“ unterscheiden.
• Datumsangaben im Format ISO 8601: ausdrücklich vorgeben. Andernfalls wählt das Modell regionale Formate und das nachgelagerte Parsen schlägt fehl.
• Währung als ISO-Code: „USD“ statt „$“; „EUR“ statt „€“. Vermeiden Sie Mehrdeutigkeit ($ für USD gegenüber CAD oder AUD).
• JSON validieren: Verwenden Sie Pydantic / Zod, um Ihr Schema durchzusetzen. Bei ungültigem Ergebnis mit dem Fehler erneut anfragen.
• Eine Woche lang 1 % manuell stichprobenprüfen, danach laufend 0,1 %. Genauigkeit auf Feldebene messen, nicht nur auf Datensatzebene.

Welches Modell wann verwenden

Compliance-Aspekte

Bei Dokumenten mit personenbezogenen Daten (Rechnungen enthalten Namen und Adressen; medizinische Unterlagen enthalten alles) pseudonymisieren Sie vor der Extraktion oder verwenden Sie vorgelagert Zero Data Retention. Siehe den Compliance-Leitfaden für regionsspezifische Muster und den DSGVO-Tiefgang für die deutsche Vorgehensweise.

Start: /app/signup — Bei nutzungsabhängiger Abrechnung deckt eine Aufladung von 10 $ etwa 3.000 Rechnungsextraktionen ab, und Ihr Guthaben verfällt nie. Lesen Sie die Chat-Dokumentation unter /docs/chat, um zu erfahren, was response_format für jede Modellfamilie durchsetzt, und um Muster zur Tool-Nutzung kennenzulernen.

FAQ