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 OpenAI Structured Outputs, Anthropic Tool-Use-Schema 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 dem Tool-Use mit input_schema bei Anthropic Claude zugrunde; 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 führenden Anbieter unterstützen strukturierte Ausgaben mit unterschiedlichen, aber konvergierenden Ansätzen. Laut der Research-Quelle (Stand 2026) ist Claude Opus 4.7 (Pricing 5 US-Dollar Input / 25 US-Dollar Output pro Million Tokens) explizit für agentische Workloads und Tool-Orchestrierung positioniert; bei Claude läuft strukturierte Ausgabe primär über Tool-Use mit JSON-Schema. OpenAI GPT-5.5 ist in derselben Quelle als stark auf Terminal- und Agent-Workloads ausgerichtet beschrieben. Google Gemini 3.1 Pro (2 US-Dollar / 12 US-Dollar pro Million Tokens, Stand 2026) ergänzt das Feld mit sehr großem Kontextfenster.

Auf der Open-Weight-Seite sind nach derselben Quelle (Stand 2026) Mistral Large 3 (Apache 2.0, 0,50 / 1,50 US-Dollar), DeepSeek V4 sowie Kimi K2.6 verfügbar, die auf agentischen und Coding-Benchmarks nahe an die Frontier-Modelle heranreichen. Der praktische Vorteil bei Open-Weight: Wer den Inference-Stack selbst kontrolliert, kann constrained decoding über Grammar-Constraints frei konfigurieren, unabhängig von einer Anbieter-API. Ausgeliefert werden diese Modelle laut Quelle über Inference-Provider wie Together AI, Fireworks AI, DeepInfra (mit Frankfurt-Region für DSGVO-relevante Workloads) oder Groq.

Wichtig für die Praxis: Auch wenn die meisten Provider OpenAI-kompatible Endpunkte anbieten, ist die Unterstützung für strukturierte Outputs nicht über alle Provider hinweg identisch. 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:

```
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 Pruefung
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.

Für Agenten-Frameworks und Multi-Provider-Routing nennt die Research-Quelle (Stand 2026) Werkzeuge wie LiteLLM und OpenRouter. Sie erlauben es, dieselbe strukturierte Anfrage gegen verschiedene Modelle zu routen, was sowohl die Anbieter-Abhängigkeit reduziert als auch ein Fallback auf ein zweites Modell ermöglicht, 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. Sprechen Sie uns an, wenn Ihr RAG- oder Agent-Projekt verlässliche, maschinenlesbare Outputs braucht statt geratenem Freitext.