Dokumenten-Extraktion: OCR + LLM in der Praxis.

In fast jedem Unternehmen liegt wertvolle Information in unstrukturierter Form vor: Verträge, Lieferscheine, Formulare, Behördenbescheide, handschriftliche Notizen, gescannte Altakten. Diese Information manuell in Systeme zu übertragen, ist teuer und fehleranfällig. Die Kombination aus OCR und Sprachmodell macht aus diesen Dokumenten strukturierte Daten — wenn man die Pipeline sauber baut und ihre Grenzen kennt.

Zwei Werkzeuge, zwei Aufgaben.

Es lohnt sich, OCR und LLM klar auseinanderzuhalten, weil sie unterschiedliche Probleme lösen. OCR (Optical Character Recognition) wandelt Pixel in Text um — es liest, welche Buchstaben und Zahlen auf einem Bild stehen. Es versteht aber nicht, was sie bedeuten. Ein LLM dagegen versteht Bedeutung und Struktur — aber es braucht erst einmal Text, mit dem es arbeiten kann.

Die Reihenfolge ist deshalb meist: erst OCR (oder direkter Bild-Input bei vision-fähigen Modellen), dann LLM für die strukturierte Auswertung. Bei nativen PDFs mit eingebettetem Text entfällt OCR ganz — der Text ist schon da und muss nur extrahiert werden. Das ist wichtig, weil OCR die häufigste Fehlerquelle der gesamten Kette ist: Was hier falsch gelesen wird, kann auch das beste Modell danach nicht mehr korrigieren.

Die Pipeline im Überblick.

1. Dokumenttyp erkennen: Native PDF, gescanntes Bild-PDF, Foto, Office-Datei? Davon hängt der weitere Weg ab.
2. Text gewinnen: Bei nativem PDF direkte Textextraktion. Bei Scans und Fotos OCR oder direkter Bild-Input ins Vision-Modell.
3. Vorverarbeitung: Entzerrung schiefer Scans, Kontrastanhebung, Seitenrotation. Schlechte Bildqualität ist der häufigste Grund für schlechte Ergebnisse.
4. Strukturierte Extraktion: Das LLM zieht aus dem Text die gewünschten Felder nach einem festen Schema.
5. Validierung: Plausibilitätsregeln, Formatprüfungen, Abgleich mit Stammdaten — deterministisch, nicht durch die KI.
6. Übergabe: Strukturierte Daten ins Zielsystem, Originaldokument revisionssicher archiviert.

Native PDFs, Scans, Handschrift — sehr unterschiedliche Schwierigkeitsgrade.

Es ist wichtig, ehrlich zu unterscheiden, wie schwer ein Dokument ist:

Diese Unterscheidung verhindert die häufigste Enttäuschung: Wer ein System an sauberen nativen PDFs testet und dann mit schlechten Fotos verblasster Handschrift in Produktion geht, wird die Ergebnisse nicht wiedererkennen. Den Schwierigkeitsgrad der echten Dokumente ehrlich einzuschätzen, ist die halbe Miete.

Warum vision-fähige LLMs vieles vereinfachen.

Klassische Pipelines trennten OCR und Layout-Analyse in viele Einzelschritte. Moderne vision-fähige Sprachmodelle können ein Dokumentbild direkt entgegennehmen und in einem Schritt sowohl lesen als auch strukturieren. Das reduziert die Zahl der Fehlerquellen und funktioniert oft erstaunlich robust gegenüber unterschiedlichen Layouts.

Der Haken: Auch ein Vision-Modell kann sich verlesen, und es tut das auf eine besonders tückische Weise — es liefert eine flüssige, plausible Ausgabe, selbst wenn es geraten hat. Ein verschmierter Betrag wird nicht als „unleserlich“ gemeldet, sondern als konkrete Zahl ausgegeben, die einfach falsch sein kann. Deshalb ist auch hier die Validierung unverzichtbar.

Ein robustes Extraktions-Setup.

Der Kern jeder Extraktion ist ein klar definiertes Zielschema und die Anweisung, bei Unsicherheit ehrlich zu sein. Ein vereinfachtes Beispiel für die Extraktion aus einem gescannten Dokument:

import anthropic, base64, json

an = anthropic.Anthropic()

# Felder als Schema vorgeben, Konfidenz mitfordern
SYSTEM = """Du extrahierst Felder aus deutschen
Dokumenten. Gib NUR JSON zurueck:
{
  "felder": { "<name>": {"wert": str|null,
                          "konfidenz": "hoch|mittel|niedrig"} },
  "unleserliche_stellen": [str]
}
Wenn etwas nicht sicher lesbar ist:
konfidenz=niedrig und Stelle vermerken.
Erfinde NIEMALS Werte."""

def extrahiere(bild_png: bytes, gesuchte_felder: list[str]):
    img = base64.standard_b64encode(bild_png).decode()
    msg = an.messages.create(
        model="claude-sonnet-4-5",
        max_tokens=2000,
        system=SYSTEM,
        messages=[{"role": "user", "content": [
            {"type": "image", "source": {
                "type": "base64",
                "media_type": "image/png",
                "data": img}},
            {"type": "text", "text":
                "Extrahiere: " + ", ".join(gesuchte_felder)}]}])
    return json.loads(msg.content[0].text)

def zur_pruefung(ergebnis: dict) -> bool:
    # Mensch pruefen lassen, wenn Unsicherheit vorliegt
    if ergebnis["unleserliche_stellen"]:
        return True
    for f in ergebnis["felder"].values():
        if f["konfidenz"] != "hoch":
            return True
    return False

Das Muster ist immer dasselbe: Das Modell extrahiert und meldet seine Unsicherheit. Felder mit niedriger Konfidenz oder unleserliche Stellen lösen automatisch eine menschliche Prüfung aus. So wird die Schwäche der KI — gelegentliche Fehler — in eine kontrollierbare Eigenschaft des Systems verwandelt.

Validierung gegen die Realität.

Über die Konfidenz-Selbstauskunft hinaus sollte jede Extraktion gegen harte Regeln laufen, wo immer das möglich ist:

• Formatprüfungen: Datum als valides Datum, IBAN mit Prüfziffer, Postleitzahl mit passender Stellenzahl, Steuernummer im richtigen Muster.
• Wertebereiche: Beträge plausibel? Datum nicht in der Zukunft, wo es nicht sein darf?
• Stammdatenabgleich: Existiert die genannte Firma, Kundennummer, Vertragsnummer im System?
• Quervergleiche: Summieren sich Teilbeträge zur Gesamtsumme? Passen zusammengehörige Felder zueinander?
• Vier-Augen bei Hochrisiko: Bei verbindlichen Dokumenten (Verträge, Bescheide) menschliche Bestätigung als feste Regel.

Die wichtigste Grundregel bleibt: Was deterministisch prüfbar ist, prüft Code, nicht die KI. Das LLM ist für das Lesen und Strukturieren zuständig, die harte Korrektheitsprüfung gehört in normale Programmlogik.

Datenschutz, Aufbewahrung, Nachvollziehbarkeit.

Dokumente enthalten oft personenbezogene Daten oder Geschäftsgeheimnisse. Wer sie über eine Cloud-API verarbeitet, braucht eine saubere Rechtsgrundlage, einen Auftragsverarbeitungsvertrag und Klarheit über den Datenstandort. Originaldokumente müssen je nach Art und gesetzlicher Vorgabe unveränderbar und revisionssicher archiviert werden; der Verarbeitungsweg sollte protokolliert sein, damit nachvollziehbar bleibt, wie ein Datensatz zustande kam. Für besonders sensible Bestände kann ein lokal betriebenes Modell die richtige Wahl sein. Dies ist keine Rechtsberatung — die konkrete Ausgestaltung gehört mit Datenschutz- und Rechtsexpertise abgestimmt.

Kosten und Aufwand realistisch.

Die reinen Modellkosten pro Dokument sind in der Regel gering, weil ein einzelnes Dokument wenig Text umfasst. Der eigentliche Aufwand steckt anderswo: in der Vorverarbeitung schlechter Scans, in der Anbindung an die Zielsysteme, im Berechtigungskonzept, im Aufbau der Validierungsregeln und im Monitoring. Diese Einmal-Investition entscheidet über den Erfolg, nicht der Token-Preis. Belastbare Zahlen ergeben sich nur aus einem echten Pilot mit den tatsächlichen Dokumenten des Unternehmens — Pauschalwerte führen hier regelmäßig in die Irre.

Was ich aus Projekten mitgebe.

• Erst die echten Dokumente ansehen. Qualität und Vielfalt der realen Belege bestimmen, was überhaupt machbar ist.
• Konfidenz erzwingen. Ein Modell, das seine Unsicherheit meldet, ist mehr wert als eines, das immer eine Antwort liefert.
• Validierung ist das System. Die Extraktion ist der einfache Teil. Die Prüfung macht den Unterschied zwischen Spielzeug und Werkzeug.
• Handschrift und Altakten mit Vorsicht. Hier immer menschliche Kontrolle einplanen.
• Genauigkeit messen, nicht behaupten. Stichprobe gegen Handarbeit halten, Fehlerquote ehrlich erheben.

Sie wollen aus Verträgen, Formularen oder Scans strukturierte Daten gewinnen — zuverlässig und nachvollziehbar? Unverbindlich anfragen — wir sehen uns Ihre echten Dokumente an, klären Datenschutz und definieren einen sinnvollen Pilot.