Document Intelligence Agent: OpenAI SDK vs LangGraph PDF

Pexon Consulting | 10 Min. Lesezeit | 01.06.2026

TL;DR

Ein Document Intelligence Agent ersetzt nicht OCR, sondern verbindet OCR mit Schema-Erkennung, Multi-Page-Reasoning und Spec-Validierung. Pexon Consulting hat zwei Cases produktiv im Manufacturing-Mittelstand: Materialzeugnis-Extractor (320k EUR Annual Value) und Frachtrechnungs-ROI-Tool (1-3% Kostenrückgewinnung). Wir vergleichen OpenAI Agents SDK und LangGraph für die typische PDF-Pipeline — und sagen, welcher Stack wann gewinnt.

Warum klassische OCR-Pipelines bei komplexen Dokumenten scheitern

Wir sehen das Muster in fast jedem Manufacturing-Wareneingang: Ein Team integriert Azure Document Intelligence, ABBYY oder Google Document AI, ist nach einer Woche stolz auf 95% OCR-Genauigkeit und meldet „Done“ — bis das ERP die ersten falschen Chargennummern in die Produktionsfreigabe schickt. Das eigentliche Problem ist nicht die Zeichenerkennung, sondern was danach passiert.

Ein Materialzeugnis nach EN 10204 ist nicht ein Dokument, sondern eine Familie von Layouts — jeder Stahlhersteller, jede Gießerei, jedes Schmiedewerk hat sein eigenes Template. Mal steht die Chargennummer oben rechts, mal in einer separaten Tabelle, mal als Stempel auf Seite 2. Klassische Template-basierte OCR kapituliert bei dieser Varianz nach drei bis fünf Wochen, weil jede neue Lieferantenversion ein neues Schema bedeutet. Eine Frachtrechnung von DHL sieht anders aus als eine von DSV, Kuehne+Nagel oder einem regionalen Spediteur — und alle drei können je nach Filiale unterschiedliche Spaltenlayouts haben.

Hier kommt ein Document Intelligence Agent ins Spiel: ein Agent-System, das OCR als Tool nutzt, aber selbst entscheidet, welche Felder relevant sind, wie sie zusammenhängen, welche Plausibilitätsregeln gelten und wann es einen Menschen fragen muss. Die Frage ist nicht „OCR oder Agent“, sondern „OCR und welcher Agent-Stack“. Wir bauen das standardmäßig mit OpenAI Agents SDK oder LangGraph — die Wahl hängt vom Workflow-Profil ab.

Schema-Erkennung: Das eigentliche Problem

Schauen wir uns das mit Code an. Ein Materialzeugnis enthält typischerweise 25-40 strukturierte Felder (Werkstoff, Norm, Charge, Schmelzanalyse, mechanische Eigenschaften, Wärmebehandlung), verteilt über 2-6 Seiten, mit zwei oder drei Tabellen. Naive Approach: 40 Felder einzeln durch OCR jagen, dann via Regex matchen — funktioniert für drei Lieferanten, bricht beim vierten.

Besser: Der Agent bekommt das Ziel-Schema als Pydantic-Modell, das Rohdokument als strukturiertes Layout-JSON (aus Azure Document Intelligence) und entscheidet selbst, wo welches Feld liegt.

from pydantic import BaseModel
from agents import Agent, function_tool

class Materialzeugnis(BaseModel):
    werkstoff: str
    norm: str
    charge: str
    schmelze: dict[str, float]
    zugfestigkeit_mpa: float
    streckgrenze_mpa: float
    haerte_hb: float | None
    waermebehandlung: str | None
    lieferant: str
    pruefer_signatur_vorhanden: bool

@function_tool
def azure_doc_intelligence(pdf_bytes: bytes) -> dict:
    """Layout-Extraktion mit Azure AI Document Intelligence."""
    return run_azure_layout(pdf_bytes)

extractor = Agent(
    name="MaterialzeugnisExtractor",
    instructions="Extrahiere Materialzeugnis nach EN 10204. Bei unklaren Feldern Confidence-Score zurückgeben.",
    tools=[azure_doc_intelligence],
    output_type=Materialzeugnis,
)

Das gleiche Pattern in LangGraph sieht anders aus — du baust einen Graphen mit drei Nodes: ocr_node → schema_inference_node → validation_node, jedes mit eigenem State. Die Verbose-Tax ist real (etwa 60-80 Zeilen für nicht-trivialen Flow), aber du gewinnst etwas Wesentliches: Du kannst zwischen schema_inference_node und validation_node einen Checkpoint setzen. Wenn die Validierung scheitert, replayst du nicht das teure OCR-Tool — du gehst direkt zurück zur Schema-Inferenz mit verändertem Prompt. Bei 12.000 Dokumenten pro Monat sind das pro Iteration eingesparte Sekunden mal Skala.

Unsere klare Empfehlung: Wer 80% strukturell ähnliche Dokumente hat (klassische Lieferanten-Zeugnisse), kommt mit OpenAI Agents SDK schneller zum Ziel. Wer mit dem oberen Long-Tail kämpft (Schiffsmanifeste, internationale Zollpapiere, multilinguale Lieferanten), profitiert vom LangGraph-Checkpointer.

Multi-Page-Reasoning: Wo OpenAI und LangGraph divergieren

Bei einseitigen Rechnungen ist das Pipeline-Design trivial. Bei einem 47-seitigen technischen Materialzeugnis mit Anhängen wird es interessant.

Das Problem: Auf Seite 1 steht die Charge, auf Seite 2 die Schmelzanalyse, auf Seite 14 die Wärmebehandlungs-Kurve, auf Seite 31 die Bestätigung des Sachverständigen. Du musst diese Felder verbinden, ihre Plausibilität gegeneinander prüfen (gleiche Charge auf allen Seiten? gleicher Werkstoff?), und entscheiden, ob das Gesamtdokument valide ist.

OpenAI Agents SDK macht das mit Handoffs zwischen spezialisierten Agents:

schema_agent = Agent(name="SchemaInferrer", ...)
chemistry_agent = Agent(name="ChemistryValidator", instructions="Prüfe Schmelzanalyse gegen Werkstoff-Spec.")
mechanical_agent = Agent(name="MechanicalValidator", instructions="Prüfe Zugfestigkeit und Streckgrenze.")

triage = Agent(
    name="Triage",
    handoffs=[schema_agent, chemistry_agent, mechanical_agent],
    instructions="Verteile Prüfung an Spezialisten und konsolidiere.",
)

Der Triage-Agent ruft die Spezialisten als Tools, jeder hat eigenes Context-Window, am Ende kommen die Ergebnisse zusammen. Sauber, explizit, gut traceable.

LangGraph hat dafür Subgraphs — jeder Validator ist ein kompletter StateGraph, der als Node im Parent-Graph läuft. Vorteil: Jeder Subgraph kann eigenen State, eigenen Checkpointer, eigene Retry-Logic haben. Bei 47-Seiten-Dokumenten mit Wartezeit auf externe Labor-Bestätigungen ist das der ehrliche Pfad — du kannst stundenlang pausieren, der State liegt sicher in Postgres.

Wir bauen Multi-Page-Pipelines bei Pexon meist in einem Hybrid-Modell: LangGraph als äußere Orchestrierung (wegen Checkpointing), aber innerhalb der Nodes nutzen wir das Claude Agent SDK oder OpenAI Agents SDK für die eigentliche Schema-Inferenz. Mehr dazu im 3-way SDK-Vergleich.

Validierung und das Sperrlager-Pattern

Ein Document Intelligence Agent ohne Validierung ist gefährlich — er erzeugt Daten, die das ERP für valide hält, obwohl der Agent halluziniert haben könnte. Wir setzen drei Schichten:

Schicht 1: Confidence-Scoring pro Feld. Jedes extrahierte Feld bekommt einen Score 0-1. Felder unter 0,9 gehen automatisch in den Review-Stack. Das macht Azure Document Intelligence natively für OCR-Confidence — die LLM-Confidence baust du selbst.

Schicht 2: Domain-Regel-Engine. Hier liegt unser Pexon-Differenzierer. OCR-Modelle wissen nicht, dass ein S355J2-Stahl niemals Streckgrenze > 470 MPa hat, oder dass eine Frachtrechnung mit Maut-Position für eine reine Seefracht ein Fehler ist. Wir schreiben diese Regeln als Code (Python-Funktionen, ~150-300 Regeln pro Domain), nicht als Prompt — Regeln müssen auditierbar und versionierbar sein, nicht „vibes-based“ im LLM-Kontext.

Schicht 3: Sperrlager-Pattern. Dokumente, die alle automatischen Checks bestehen, gehen ins ERP. Dokumente unter 95% Gesamt-Confidence gehen ins „Sperrlager“ — eine Review-Queue für den Wareneingang oder die Buchhaltung. Das ist unverhandelbar. Wir haben in einem Pilot 2025 erlebt, was passiert ohne Sperrlager: Drei Wochen nach Go-Live entdeckte das QM-Team, dass falsche Chargennummern in 0,7% der Lieferungen bereits in der Produktion verbaut waren. Schadensumfang: hoher fünfstelliger Bereich. Seitdem ist Sperrlager Pflicht.

OpenAI Agents SDK implementiert das via Handoff zu einem „HumanAgent“, der ein Frontend triggert. LangGraph nutzt interrupt() — der Graph pausiert mitten in der Pipeline, der State liegt in Postgres, ein Mitarbeiter quittiert im Frontend, dann läuft der Graph mit Command(resume=...) weiter. Bei 12.000 Dokumenten pro Monat und durchschnittlich 4% Sperrlager-Quote sind das 480 Reviews monatlich — mit Postgres als Persistenz-Layer kein Problem.

Pexon-Case 1: Materialzeugnis-Extractor

Mittelständischer Defense-Manufacturer, 850 Mitarbeiter, 8.000 Wareneingangs-Materialzeugnisse pro Jahr. Vorher zwei vollständige FTE im Wareneingang gebunden, jedes Zeugnis manuell mit ERP-Spec verglichen, Fehlerquote 30-50% (in Stichproben gemessen — die unentdeckten waren das eigentliche Problem).

Was wir gebaut haben: Azure Document Intelligence für Layout-Extraktion, LangGraph als Orchestrierung mit Postgres-Checkpointer, Domain-Regel-Engine mit 280 EN-10204-spezifischen Plausibilitätsregeln, Sperrlager-Frontend in React mit ERP-Anbindung über REST.

Volle Story mit Architektur-Diagramm und EN-10204-Patterns: Materialzeugnis-Validierung mit Document-AI.

Pexon-Case 2: Frachtrechnungs-ROI-Tool

Logistik-Mittelständler, 1.200 Mitarbeiter, ~180.000 Frachtrechnungen pro Jahr von 60+ Spediteuren. Vorher Stichproben-Prüfung 10-20%, manuelle Prüfung 8-15 Minuten pro Rechnung, geschätzte Fehlererkennung 30-50%. Bekannt war: 8% aller Frachtrechnungen enthalten Fehler — Gewichtszuschläge, doppelte Mautgebühren, veraltete Tarife. Was nicht erkannt wurde, wurde bezahlt.

Was wir gebaut haben: Azure Document Intelligence für Layout, OpenAI Agents SDK für Schema-Inferenz (Spediteur-spezifisch via Handoff zu spezialisierten Sub-Agents), Konditionsabgleich gegen TMS-Stammdaten als Custom-Tool, automatische Reklamations-Mails an Spediteure bei klaren Fehlern, Sperrlager für unklare Fälle.

Bei einem 8-Mio-EUR-Frachtkosten-Budget bedeutet das 80.000-240.000 EUR Rückgewinnung pro Jahr. Volle Methodik: KI-Frachtrechnungsprüfung Logistik.

Was du in 6 Wochen erwarten kannst

Wir liefern Document-Intelligence-Piloten als 6-Wochen-Sprint mit festem Preis und festem Outcome. Kein „Discovery-Phase mit ungewissem Ende“.

Wochen 1-2: Schema-Definition für deine Top-3-Dokumenttypen, OCR-Provider-Auswahl (Azure Document Intelligence, Mistral OCR oder Open-Source je nach DSGVO-Profil), Architektur-Entscheidung OpenAI Agents SDK oder LangGraph. Setup der Pipeline-Skeleton.

Wochen 3-4: Schema-Inferenz live auf deinen echten Dokumenten, Domain-Regel-Engine mit den ersten 50-100 Plausibilitätsregeln, Sperrlager-Frontend mit ERP-Sandbox-Anbindung. Erste Confidence-Messung auf Validierungs-Set.

Wochen 5-6: Produktive Anbindung an dein ERP/TMS, Sperrlager-Workflow mit deinem Fachbereich, Monitoring (Token-Cost, Confidence-Verteilung, Sperrlager-Quote), Übergabe inkl. Code, Architektur-Doku, Regel-Set. Du kannst danach selbst weiterbauen.

Investment: 55.000-85.000 EUR je nach Dokumenttyp-Komplexität, Anzahl Lieferanten/Spediteure und ERP-Integrations-Tiefe.

Häufig gestellte Fragen

Brauche ich Azure Document Intelligence oder reicht ein einzelnes LLM?

Kommt drauf an, aber meistens ja. Aktuelle Vision-Language-Modelle (Claude Opus 4.7, GPT-4o) lesen PDFs zwar direkt — bei einseitigen Standardrechnungen funktioniert das ordentlich. Sobald du 5+ Seiten, gescannte Dokumente mit Stempeln, Tabellen mit verschachtelten Zellen oder schlechte Scan-Qualität hast, gewinnt der Hybrid: OCR-Spezialist plus LLM. Azure AI Document Intelligence kostet 1,50-3 EUR pro 1.000 Seiten, ist DSGVO-konform in Frankfurt verfügbar. Wir nutzen es als Default.

Was unterscheidet einen Document Intelligence Agent von klassischer RPA?

RPA folgt einem fixen Skript: „extrahiere Feld X aus Position Y“. Funktioniert für konstante Layouts, bricht bei Varianz. Ein Document Intelligence Agent versteht das Ziel („ich brauche die Charge“), nicht die Position — er findet die Charge auch, wenn der Lieferant das Layout ändert. Praktischer Unterschied: RPA-Pipelines brauchen Pflege bei jedem neuen Lieferanten, Agent-Pipelines lernen mit.

Funktioniert das auch on-prem ohne Cloud-Modell?

Ja, mit Einschränkungen. Open-Source-Modelle (Qwen 3, Llama 3.3 Vision, Mistral) erreichen bei strukturierten Dokumenten 80-90% der GPT-4o-Qualität — bei schlecht gescannten Dokumenten oder seltenen Layouts brechen sie ein. Für Defense, Banking oder Healthcare mit strengen On-Prem-Anforderungen bauen wir den Hybrid: Open-Source-OCR plus Open-Source-LLM, mit klar definiertem Quality-Gate für Eskalation an menschliche Reviewer. Kostet typisch 30-50% mehr Sperrlager-Quote als der Cloud-Stack.

Was passiert, wenn der Agent halluziniert und das ERP falsche Daten bekommt?

Genau dafür ist das Sperrlager-Pattern Pflicht. Wir setzen Auto-Freigabe-Schwellen konservativ — typisch 95% Gesamt-Confidence über alle extrahierten Felder plus Pass auf allen Plausibilitätsregeln. Alles darunter geht in den Review. Im Materialzeugnis-Case lag die Auto-Freigabe-Quote nach drei Monaten bei 78%, im Frachtrechnungs-Case bei 91%. Die Sperrlager-Quote sinkt durch Regel-Verfeinerung über die ersten 6-8 Wochen kontinuierlich.

Wie viele Dokumente pro Monat lohnen sich für die Automatisierung?

Die Faustregel aus unseren Projekten: ab etwa 2.000 strukturell ähnlichen Dokumenten pro Monat rechnet sich der 6-Wochen-Pilot innerhalb von 9-15 Monaten. Bei 5.000+ Dokumenten ist das Payback typisch unter 6 Monaten. Bei weniger als 1.000 pro Monat ist ein vorgefertigtes SaaS-Tool (ABBYY, Kofax, oder ein Vertical wie Klippa für Spesen) meist die bessere Wahl.

Nächster Schritt

Wenn dein Wareneingang oder deine Buchhaltung jeden Tag mit PDFs ringt: Wir machen einen 30-Minuten-Call, du zeigst uns drei typische Dokumente, wir sagen, was wir bauen würden und nennen einen Festpreis. Keine Folien.

Verwandte Themen