Strukturierte Outputs mit JSON Schema: Zuverlässige Agent-Antworten erzwingen

Strukturierte Outputs mit JSON Schema sind eine Technik, bei der ein LLM gezwungen wird, seine Antwort exakt nach einem vorgegebenen JSON-Schema auszugeben. Statt freien Text liefert das Modell ein maschinenlesbares, validierbares Objekt. Das macht Agent-Pipelines verlässlich, weil nachgelagerte Programmschritte sich auf eine garantierte Datenstruktur verlassen können statt fehleranfälligen Freitext zu parsen.

• Was? Das Modell gibt JSON nach festem Schema aus, nicht freien Text. Felder, Typen und erlaubte Werte sind definiert.
• Warum? Programme können das Ergebnis ohne brüchige Regex- oder String-Logik direkt weiterverarbeiten. Das ist die Grundlage zuverlässiger Agenten.
• Wie? Über Anbieter-Funktionen wie die Structured Outputs von OpenAI und Anthropic oder constrained decoding bei Open-Weight-Modellen, ergänzt um Validierung und Retry.

Warum Freitext-Parsing in Agent-Pipelines scheitert

Ein Sprachmodell erzeugt standardmäßig Text für menschliche Leser. Das ist für einen Chatbot ideal, für eine automatisierte Pipeline aber ein Problem. Sobald ein Programm aus der Antwort einen Wert extrahieren muss, etwa eine Kategorie, ein Datum, einen Betrag oder eine Liste, beginnt das brüchige Geschäft des Parsens. Das Modell schreibt mal "Die Kategorie ist Rechnung.", mal "Kategorie: Rechnung", mal packt es eine Erklärung davor. Jede dieser Varianten bricht eine naive Extraktionslogik.

In Multi-Step-Agenten verschärft sich das dramatisch, weil sich Unzuverlässigkeit über die Kette multipliziert. Ein Rechenbeispiel: Hat jeder einzelne Schritt eine Parsing-Erfolgsquote von 95 Prozent, liegt die End-to-End-Erfolgsquote bei einer Kette aus zehn Schritten nur noch bei 0,95 hoch 10, also rund 60 Prozent. Steigert man jeden Schritt durch strukturierte Outputs auf 99,5 Prozent, landet dieselbe Kette bei rund 95 Prozent. Aus diesem Multiplikationseffekt folgt die zentrale These dieses Artikels: Strukturierte Outputs sind kein Komfort-Feature, sondern die Voraussetzung dafür, dass Agent-Pipelines überhaupt produktionsreif werden.

Die drei Garantiestufen im Überblick

Nicht jede Methode, die JSON verspricht, liefert dieselbe Garantie. Drei Stufen sind zu unterscheiden, und der Unterschied entscheidet über die Zuverlässigkeit.

Prompt-only. Man bittet das Modell höflich, JSON auszugeben. Das funktioniert oft, aber nicht immer. Das Modell kann Markdown-Codefences hinzufügen, Felder weglassen oder bei Unsicherheit doch in Fließtext zurückfallen. Keine Garantie.

JSON-Mode. Der Anbieter garantiert, dass die Ausgabe syntaktisch gültiges JSON ist. Das beseitigt Syntaxfehler, sagt aber nichts über die Struktur: Felder können fehlen, falsche Typen haben oder zusätzlich auftauchen. Teilgarantie.

Constrained decoding / Structured Outputs. Hier wird der Generierungsprozess auf Token-Ebene so eingeschränkt, dass nur Tokens erzeugt werden können, die dem Schema entsprechen. Das Modell kann ein Schema-konformes Ergebnis gar nicht mehr verlassen. Pflichtfelder, Typen und erlaubte Enum-Werte sind garantiert. Diese Technik liegt OpenAI Structured Outputs (strict-Modus) und den Structured Outputs von Anthropic zugrunde, also den JSON Outputs über output_config.format und dem Strict Tool Use mit strict: true. Normaler Tool-Use ohne strict garantiert das Schema nicht. Bei Open-Weight-Modellen übernehmen Bibliotheken und Inference-Stacks die gleiche Aufgabe per Grammar-Constraints.

Methode, Garantie, Tradeoff im Vergleich

Die entscheidende Erkenntnis aus dieser Tabelle: Constrained decoding garantiert die Form, nicht den Inhalt. Das Modell liefert garantiert ein gültiges Objekt mit dem Feld rechnungsdatum, aber ob der dort eingetragene Wert tatsächlich dem Datum auf dem Dokument entspricht, kann kein Decoding-Verfahren sicherstellen. Deshalb bleiben fachliche Validierung und Retry-Strategie unverzichtbar.

Anbieter-Realität Stand 2026

Die großen Anbieter binden die Antwort inzwischen an ein JSON-Schema, unterscheiden sich aber in Parametern und Grenzen.

• OpenAI: Structured Outputs mit strict: true, als Antwortformat vom Typ json_schema oder beim Function Calling. Der JSON-Mode (json_object) liefert dagegen nur gültiges JSON, ohne das Schema einzuhalten.
• Anthropic Claude: JSON Outputs über output_config.format oder Strict Tool Use mit strict: true, beide per grammatikbeschränktem Sampling. Ohne strict kann Claude beim Tool-Use falsche Typen liefern ("2" statt 2) oder Pflichtfelder weglassen. Rekursive Schemas und Grenzen wie minimum oder maxLength unterstützt die API nicht. Längengrenzen wie im Beispiel unten gehören deshalb in die description und in die Validierung.
• Google Gemini: Die API nimmt ein JSON-Schema samt MIME-Typ application/json als Antwortformat entgegen. Google rät selbst dazu, die Werte trotzdem in der Anwendung zu prüfen.
• Open-Weight-Modelle: Hier erzwingt der Inference-Stack das Schema per Grammatik. vLLM nimmt ein JSON-Schema direkt im OpenAI-kompatiblen Server an, llama.cpp übersetzt einen Teil von JSON Schema in GBNF-Grammatiken. Wer den Stack selbst betreibt, konfiguriert constrained decoding unabhängig von einer Anbieter-API.

Wichtig für die Praxis: Viele Inference-Provider bieten OpenAI-kompatible Endpunkte an, setzen strukturierte Outputs aber unterschiedlich um. Vor einer Festlegung gilt es zu prüfen, ob der konkrete Provider den strict-Modus oder Schema-Constraints tatsächlich durchsetzt oder nur JSON-Mode bietet.

Beispiel-Schema und Retry-Strategie

Ein konkretes Beispiel macht das Prinzip greifbar. Ein Agent soll eingehende Support-Anfragen klassifizieren und die wichtigsten Felder extrahieren. Das JSON-Schema (vereinfacht) sieht so aus:

```json
{
"type": "object",
"properties": {
"kategorie": {
"type": "string",
"enum": ["rechnung", "technik", "vertrag", "sonstiges"],
"description": "Hauptkategorie der Anfrage"
},
"dringlichkeit": {
"type": "string",
"enum": ["niedrig", "mittel", "hoch"]
},
"kundennummer": {
"type": ["string", "null"],
"description": "Kundennummer falls im Text genannt, sonst null"
},
"zusammenfassung": {
"type": "string",
"description": "Ein Satz, maximal 200 Zeichen"
}
},
"required": ["kategorie", "dringlichkeit", "kundennummer", "zusammenfassung"],
"additionalProperties": false
}
```

Zwei Designentscheidungen sind hier zentral. Erstens Enums statt Freitext für kategorie und dringlichkeit: Damit ist ausgeschlossen, dass das Modell "Rechnungswesen" oder "sehr hoch" erfindet, was eine nachgelagerte Weiterleitungslogik bräche. Zweitens additionalProperties: false, damit keine ungewollten Zusatzfelder auftauchen. Die description-Felder wirken dabei wie eine implizite Anweisung an das Modell.

Auf dieses Schema setzt eine bounded Retry-Strategie auf. Der Pseudocode ruft das LLM höchstens dreimal auf:

```
versuch = 0
while versuch < 3:
antwort = llm.call(prompt, schema=support_schema) # strukturierte Ausgabe
objekt = parse_json(antwort) # Form ist garantiert
fehler = validiere(objekt) # semantische Prüfung
if not fehler:
return objekt
prompt += f"\nKorrigiere: {fehler}" # Fehler-Feedback
versuch += 1
eskaliere_an_mensch(antwort) # Fallback nach 3 Versuchen
```

Der Punkt: Selbst mit garantiert Schema-konformer Form prüft validiere() die Semantik, etwa ob die kundennummer dem erwarteten Format entspricht oder ob die zusammenfassung die Längengrenze einhält. Schlägt das fehl, geht der konkrete Fehler als Feedback zurück ins Modell. Drei Versuche sind eine sinnvolle Obergrenze; danach wird an einen Menschen eskaliert, statt endlos zu schleifen und Kosten zu verbrennen.

Validierung mit Pydantic und Zod als Praxis-Standard

In der Praxis schreibt niemand JSON-Schemas von Hand. In Python definiert man ein Pydantic-Modell, in TypeScript ein Zod-Schema; beide erzeugen das JSON-Schema für die LLM-Anfrage und übernehmen direkt die Validierung der Antwort. Das hat einen doppelten Nutzen: Dieselbe Definition steuert die Generierung und prüft das Ergebnis, was Inkonsistenzen vermeidet. Typfehler, fehlende Pflichtfelder oder verletzte Wertebereiche werden beim Parsen sofort als klare Fehlermeldung sichtbar, die sich als Retry-Feedback wiederverwenden lässt.

Frameworks wie Pydantic AI bauen diese Schleife bereits ein: Sie prüfen die Antwort gegen das Pydantic-Modell und fordern das Modell bei einem Validierungsfehler zu einem neuen Versuch auf, mit einstellbarer Obergrenze. Für Multi-Provider-Routing gibt es Werkzeuge wie LiteLLM und OpenRouter. Damit läuft dieselbe strukturierte Anfrage gegen verschiedene Modelle. Das senkt die Abhängigkeit von einem Anbieter und erlaubt einen Fallback auf ein zweites Modell, falls ein Provider den strukturierten Output nicht zuverlässig liefert.

Häufige Stolperfallen

• Zu komplexe Schemas. Tief verschachtelte Strukturen mit vielen optionalen Feldern erhöhen Fehlerquote und Latenz. So streng wie nötig, so einfach wie möglich.
• Form mit Inhalt verwechseln. Ein Schema-konformes Objekt ist nicht automatisch fachlich korrekt. Halluzinierte, aber gültig getypte Werte sind die gefährlichste Fehlerklasse, weil sie unauffällig durchrutschen.
• Unbegrenzte Retries. Ohne Obergrenze drohen Endlosschleifen und Kostenexplosion. Immer bounded Retries mit Eskalations-Fallback.
• Provider-Unterschiede ignorieren. Nicht jeder OpenAI-kompatible Endpunkt erzwingt das Schema wirklich strikt. Vor dem Go-live testen.

Für Agenturen und B2B-Entscheider

Wer in Wien oder im DACH-Raum einen produktiven Agenten oder eine RAG-Anwendung plant, sollte strukturierte Outputs von Beginn an als Architektur-Prinzip verankern, nicht als nachträgliche Reparatur. Genau hier entscheidet sich, ob ein KI-Projekt ein verlässliches Werkzeug wird oder ein unberechenbares Demo bleibt. Als Agentur in Wien begleitet Blck Alpaca DACH-Unternehmen beim Aufbau robuster RAG- und Agenten-Pipelines, von der Schema-Definition über Validierung und Retry-Logik bis zur Anbieter- und Souveränitäts-Entscheidung. Sprich uns an, wenn dein RAG- oder Agent-Projekt verlässliche, maschinenlesbare Outputs braucht statt geratenem Freitext.