Output-Formatierung und JSON-Modus: Function-Calling, Pydantic, Instructor, Outlines

Was ist strukturierte Output-Formatierung?

Strukturierte Output-Formatierung erzwingt, dass ein Sprachmodell seine Antwort in einem maschinen-lesbaren Schema produziert – typischerweise JSON, manchmal XML oder eine spezifische Daten-Klasse. Statt Freitext "Der Mandant heisst Müller, hat 1500 CHF zu zahlen, fällig am 15.06.2026" liefert das Modell `{"client": "Müller", "amount": 1500, "due_date": "2026-06-15"}`.

Der Unterschied klingt klein, ist aber fundamental. Freitext muss durch fragile String-Parser oder ein zweites Modell-Aufrufen interpretiert werden. JSON-Output kann direkt in eine Datenbank, eine API-Schnittstelle oder ein Buchhaltungs-System eingespeist werden. Mai 2026 ist Structured Output Pflicht-Pattern für jede produktive LLM-Integration in Geschäftsprozesse.

Mehrere Techniken konkurrieren. Erstens: JSON-Mode – der Provider garantiert, dass die Antwort syntaktisch gültiges JSON ist (OpenAI, Anthropic, Mistral haben das seit 2024). Zweitens: Function-Calling oder Tool-Use – das Modell wird angewiesen, eine "Funktion" mit definierten Parametern aufzurufen, was effektiv das Schema erzwingt. Drittens: Pydantic-Output-Parsing – eine Python-Bibliothek validiert das Output gegen ein Pydantic-Modell und erzwingt Reparatur bei Fehlern. Viertens: Instructor – eine Wrapper-Library, die Pydantic-Modelle direkt in OpenAI/Anthropic-API-Aufrufe einbettet. Fünftens: Outlines – Library für lokale Modelle (Llama, Mistral), die Constrained Decoding auf Token-Ebene erzwingt.

Mai 2026 unterstützen die grossen Anbieter Structured Output natively: GPT-4.1 hat `response_format` mit JSON-Schema-Erzwingung, das aktuelle Claude-Spitzenmodell hat `tool_use` mit strengem Schema, Mistral hat `function_calling` seit 2024. Lokale Modelle können über Outlines, LMQL oder llama.cpp-Grammars zu strukturiertem Output gezwungen werden.

Warum es wichtig ist

Ohne strukturierte Outputs ist LLM-Integration ein Bastel-Projekt. Ein KMU-Treuhänder, der KI-Belegerfassung baut, braucht zuverlässig `{"datum": "...", "betrag": 0.0, "mwst_satz": 7.7, "kategorie": "..."}` – nicht "Der Beleg vom xx.xx.xxxx beträgt etwa ...". Ohne Schema-Garantie scheitert jeder zweite Beleg an einem Parsing-Fehler.

Produktiv-Pipeline-Stabilität: Vor JSON-Mode (vor Mitte 2024) lagen die Parsing-Fehler-Raten bei rund 15-25%, je nach Komplexität des Outputs. Mit OpenAI structured outputs Mai 2026: < 0.1%. Das ist der Unterschied zwischen "wir können das für Mandanten einsetzen" und "wir machen 30% Nacharbeit".

Daten-Integrität bei Pflicht-Feldern: Wenn der Beleg eine MWST-Nummer braucht und das Modell sie nicht ausweisen kann, soll das System eine klare Fehler-Meldung geben, nicht eine erfundene MWST-Nummer. Structured Output mit Required-Felder plus Pydantic-Validierung erzwingt das.

Kosten und Latenz: Modelle mit strikt erzwungenen Schemas produzieren oft kürzere Outputs (weniger Geblubber) und werden schneller "fertig". In unseren Treuhand-Pipelines reduziert sich der Output-Token-Verbrauch um 30-50% gegenüber Freitext-Antworten.

Fehler-Behandlung: Wenn ein Pflicht-Feld nicht ausgefüllt werden kann (z.B. unsicheres Datum), kann das Schema einen `confidence`-Score und ein `unsure_fields`-Array vorsehen. So weiss die Pipeline genau, wo Human-Review nötig ist.

Compliance: Bei automatisierten Einzelentscheidungen ist Reproduzierbarkeit wichtig. Strukturierte Outputs lassen sich einfach in Audit-Logs schreiben und nachverfolgen, wer wann was entschieden hat. Freitext-Antworten sind dafür schlechter geeignet.

Wie es funktioniert – Methoden und Tools Mai 2026

OpenAI Structured Outputs. Seit November 2024 garantiert OpenAI bei `response_format: {"type": "json_schema", "json_schema": ...}` 100% Schema-Konformität. Das Modell wird auf Token-Ebene constrained – Tokens, die das Schema verletzen würden, werden gar nicht erst gesampelt. Mai 2026 mit GPT-4.1: Schema-Validierung 100% reliable, Performance-Hit unter 5%.

Claude Tool Use. Anthropic hat keinen direkten "JSON-Mode", aber `tool_use` mit `input_schema` erfüllt denselben Zweck. Sie definieren ein Tool mit JSON-Schema, das Modell muss das Tool mit valide-formatierten Parametern aufrufen. Mai 2026 mit Claude Opus: hohe Schema-Konformität (98-99%), seltene Fälle, in denen das Modell das Tool verweigert und stattdessen Text zurückgibt.

Mistral Function Calling. Mistral Large 2.1 und Mistral Small 3 unterstützen Function Calling im OpenAI-kompatiblen Format. Schema-Konformität 95-97%, etwas schwächer als OpenAI/Anthropic, dafür EU-gehostet (Frankreich).

Pydantic + Output-Parser. Python-Pattern: Sie definieren ein Pydantic-Modell (`class Receipt(BaseModel): date: date; amount: float; vat_rate: float`) und nutzen es als Schema-Quelle. Bei Modell-Output ohne strikten JSON-Modus parst Pydantic, validiert und wirft `ValidationError` bei Fehler. Ihre Pipeline triggert Repair-Logik oder Human-Review.

Instructor (jxnl/instructor). Open-Source-Library, die Pydantic-Modelle direkt in OpenAI- und Anthropic-API-Aufrufe einbettet. Sehr beliebt Mai 2026 (über 8000 GitHub-Stars). Drei Zeilen Code: `client.chat.completions.create(model="gpt-current", response_model=Receipt, messages=[...])`. Wir nutzen Instructor in fast jedem Fairlane-Projekt für Receipt-Parsing, Mahn-Klassifizierung, Mandanten-Routing.

Outlines (dottxt-ai/outlines). Library für lokale Modelle. Constrained Decoding auf Token-Ebene erzwingt reguläre Ausdrücke, JSON-Schema oder CFG (kontext-freie Grammatiken). Funktioniert mit Llama, Mistral, Qwen lokal über Hugging Face. Mai 2026 die Standard-Lösung für EU-Souveränitäts-Setups mit lokalem Modell.

LMQL (Language Model Query Language). ETH Zürich. Domain-spezifische Sprache für Prompts mit eingebauten Constraints. Eher Forschungs-orientiert, aber mächtig – erlaubt z.B. "Antwort muss exactly 3 Bullet-Points haben, jeder zwischen 10 und 30 Wörtern".

llama.cpp Grammars. Wenn Sie llama.cpp lokal betreiben, können Sie via GBNF (Grammar in Bachus-Naur Form) den Output erzwingen. Effizient, low-level, sehr schnell. Nichts für Fast-Prototyping aber gut für Production-Setups.

Mai-2026-Praxis-Empfehlung. Für OpenAI: native structured outputs. Für Anthropic: tool_use mit strict_input_schema. Für Mistral: function_calling. Wrapper-Layer: Instructor in Python, oder eigene Pydantic-Adapter in TypeScript (z.B. zod-to-json-schema). Für lokale Modelle: Outlines.

Structured Output einführen in 6 Schritten

1. 01Schema definieren mit Pydantic (Python) oder Zod (TypeScript): erforderliche Felder, optionale Felder, Typen, Validierungen.
2. 02API-Methode wählen: OpenAI structured_outputs, Claude tool_use, Mistral function_calling, oder Instructor-Wrapper.
3. 03Confidence- und Unsure-Felder einbauen: `confidence_score: float`, `unsure_fields: list[str]` für Human-Review-Trigger.
4. 04Edge-Cases im Test-Set abdecken: leere Felder, mehrdeutige Eingaben, falsche Formate – Schema muss damit umgehen.
5. 05Fallback-Logik für Validation-Errors: Repair-Aufruf (Modell sieht Fehler und korrigiert) oder Human-Review-Eskalation.
6. 06CI-Test: Pydantic-Validierung gegen 100+ Test-Outputs, Schema-Konformität >= 99% als Pass-Schwelle.

Wann strukturierte Outputs sinnvoll sind

In jedem Use Case, wo der Output in ein Daten-System fliesst, sind strukturierte Outputs Pflicht. Beispiele:

Belegerfassung (Datum, Betrag, MWST, Kategorie → Buchhaltungs-DB), Mandanten-Mail-Klassifizierung (Priorität, Kategorie, Sachbearbeiter → Workflow-System), Vertrags-Klausel-Extraktion (Klausel-Typ, Risiko-Score, Empfehlung → Vertrags-Reviewer), Mahn-Tier-Bestimmung (Tier 1/2/3, Tonalität, Fälligkeit → Mahn-System), Lead-Scoring (Score 0-100, Reasoning, nächste Aktion → CRM).

Für Function-Calling-Setups (Agent-Architekturen): immer strukturierte Outputs, weil das Tool-Schema das vorgibt.

Für Audit-Trail-Anforderungen (Art. 957a OR, EU AI Act): strukturierte Outputs sind Voraussetzung, weil Audit-Logs maschinen-lesbar sein müssen.

Für mehrsprachige Pipelines: das Schema kann sprach-unabhängig sein (Felder auf Englisch), die Werte sprach-abhängig (Inhalte in DE/FR/IT). Erleichtert Cross-Sprach-Auswertung.

Für A/B-Tests verschiedener Prompts: vergleichbare Output-Strukturen erlauben automatisches Diff-Testing.

Für JSON-Mode konkret: überall, wo die Antwort in einer Datenbank, API oder einem strukturierten Buchhaltungs-System landet. Das ist Mai 2026 die Mehrheit aller produktiven LLM-Pipelines im KMU-Bereich.

Wann Freitext besser ist

Reine Generations-Tasks ohne Maschine-zu-Maschine-Verarbeitung profitieren von Freitext. Beispiel: ein KI-generierter Briefentwurf an einen Mandanten. Hier soll natürliche Sprache fliessen, nicht in Felder gepresst werden.

Kreative Tasks (Slogan-Generierung, Bildkonzepte, narrative Zusammenfassungen) brauchen Freitext. Wer einen Slogan in JSON erzwingt, bekommt schlechtere Slogans.

Vorsicht bei zu strengen Schemas: Ein extrem detailliertes Schema mit 50 Feldern, von denen 80% Optional sind, kann das Modell überfordern. Es vergisst Felder, halluziniert Werte oder verweigert die Antwort. Faustregel: ein Schema mit über 15 Feldern braucht hierarchische Struktur (nested objects) oder muss auf mehrere LLM-Aufrufe aufgeteilt werden.

Auch problematisch: Felder, die "fast immer leer" sind. Wenn ein Feld in 95% der Fälle Null ist, halluziniert das Modell oft etwas hinein. Lösung: Feld als optional kennzeichnen oder mit einem expliziten `is_missing` Boolean-Flag arbeiten.

Kostengründe: bei sehr einfachen Tasks (z.B. "ist der Text deutsch oder französisch?") ist ein voll-strukturiertes Schema Overhead. Ein einfacher Boolean-Return oder ein One-Word-Output reicht.

Vor- und Nachteile

Häufige Fragen

Verwandte Themen

Quellen

1. OpenAI – Structured Outputs (response_format json_schema) · 2026-04
2. Anthropic – Tool Use and Strict Input Schemas (the current top Claude model) · 2026-04
3. Mistral – Function Calling Guide · 2026-03
4. Instructor – Pydantic-first LLM library (docs) · 2026-05
5. Outlines – Structured generation for local LLMs · 2026-05
6. ETH Zurich – LMQL: Language Model Query Language · 2026-02