Structured Output

Structured Output bezeichnet die Antwort eines KI-Sprachmodells (Large Language Model, LLM), die einem festen Bauplan folgt: einer vorgegebenen Feld-Liste mit erlaubten Werten und Typen. Der Bauplan (technisch: Schema) wird direkt beim Modell-Aufruf mitgegeben, sodass die Antwort ohne Nachbearbeitung von einer anderen Software weiterverarbeitet werden kann. Anbieter wie [OpenAI](https://openai.com/index/introducing-structured-outputs-in-the-api/), Anthropic und Google erzwingen diesen Bauplan technisch, statt ihn nur per Text-Anweisung (Prompt) zu erbitten.

Was ist Structured Output?

Structured Output ist die Antwort-Ebene eines KI-Sprachmodells (LLM), bei der die Ausgabe einem maschinenlesbaren Schema (der technische Begriff für den Bauplan) entsprechen muss. Das Schema definiert Felder, ihre Datentypen (Text, Zahl, Wahrheitswert), erlaubte Werte aus einer festen Liste (Enums, kurz für Enumerations), Pflichtfelder und geschachtelte Objekte. Die Anwendung liefert das Schema mit dem Modell-Aufruf mit; das Modell erzeugt eine Antwort, die genau diesem Vertrag folgt. Das Ergebnis lässt sich direkt weiterverarbeiten, ohne dass ein zweiter Prüf-Schritt die Antwort erst reparieren muss.

Der Begriff existiert, weil LLM-Antworten ursprünglich freier Text waren. Sobald eine Anwendung die Antwort programmatisch weiterverarbeitet (Extraktion, Klassifikation, Datenbank-Insert, Orchestrierung von Tools), braucht sie einen Vertrag über das Antwort-Format. Ohne diesen Vertrag kostet jede Integration eine Validierungs- und Repair-Schleife: Antwort parsen, bei Formatfehler nachbessern oder erneut prompten, Enums prüfen, fehlende Felder ergänzen. Structured Output verlagert diese Prüfung von der Anwendung in die Modell-API und macht die Antwort zu einem verlässlichen Datentyp.

Vier Mechanismen realisieren das. JSON Mode garantiert syntaktisch gültiges JSON, ohne die Felder oder Datentypen zu erzwingen (frühe API-Variante bei OpenAI ab 2023). Structured Outputs mit Schema-Erzwingung ist die stärkere Form: Die API validiert die Antwort gegen ein JSON-Schema und beschränkt die Token-Wahl während der Generierung so, dass nur schema-konforme Antworten möglich sind. [OpenAI](https://openai.com/index/introducing-structured-outputs-in-the-api/) führte das Feature im August 2024 mit 100 % Schema-Adhärenz auf gpt-4o und neueren Modellen ein, Anthropic und Google bieten vergleichbare Mechanismen. Function Calling und Tool Use sind spezifische Ausprägungen: Das Modell erzeugt die Argumente eines Funktions-Aufrufs als strukturiertes JSON gegen ein Argument-Schema. Constrained Decoding ist die Umsetzungsebene und beschränkt die möglichen Tokens auf Basis einer Grammatik-Regel während der Generierung; Bibliotheken wie [Outlines](https://github.com/dottxt-ai/outlines), Guidance und LMQL implementieren das für Open-Weight-Modelle.

Die Anbieter-Terminologie ist uneinheitlich. OpenAI spricht von „Structured Outputs" für die Schema-Erzwingung und trennt sie vom älteren „JSON Mode". [Anthropic](https://docs.anthropic.com/en/docs/agents-and-tools/tool-use/overview) nutzt „Tool Use" für den gleichen Mechanismus im Function-Calling-Kontext, das JSON-Schema steht dort im input_schema-Feld der Tool-Definition. [Google](https://ai.google.dev/gemini-api/docs/structured-output) integriert Structured Output in die Gemini-API über das Feld responseSchema und über Function Calling. Der zugrunde liegende Vertrag ist bei allen drei gleich: Schema rein, Schema-konforme Antwort raus.

Abgrenzung zu Tool Use, Function Calling, JSON Mode und Prompt Engineering

Vier Begriffe werden regelmäßig mit Structured Output vermischt. Die relevanten Trennlinien:

Tool Use umfasst Structured Output als Teilmenge: Das Modell erzeugt ein strukturiertes Objekt, das die aufrufende Anwendung als Funktions-Aufruf interpretiert und ausführt. Structured Output allein muss keine externe Ausführung nach sich ziehen. Reine Extraktions-Anwendungen (Rechnungsdaten aus PDFs, Ticket-Felder aus E-Mails, Entitäten aus Freitext) nutzen Structured Output ohne Tool-Call: Das Schema beschreibt das Ausgabe-Objekt, die Anwendung schreibt es direkt in eine Datenbank.

Function Calling ist die OpenAI- und Google-Terminologie für den Mechanismus, mit dem das Modell Funktions-Argumente als JSON erzeugt. Es ist eine Ausprägung von Structured Output für den Tool-Use-Fall und keine eigenständige Kategorie. Structured Output für einen Funktions-Aufruf zu nutzen ist Function Calling; Structured Output für die reine Extraktion eines Rechnungsobjekts ist es nicht. Die Details des Mechanismus stehen im [Glossareintrag Function Calling](/insights/glossar/function-calling/).

JSON Mode und Structured Outputs unterscheiden sich in der Garantie-Stärke. JSON Mode liefert syntaktisch gültiges JSON, aber ohne Feld-Prüfung: Das Modell darf beliebige Felder erfinden oder Enum-Werte außerhalb des Schemas zurückgeben. Structured Outputs (die neuere API-Familie) erzwingt zusätzlich die Schema-Adhärenz auf Feld-Ebene. OpenAI hat JSON Mode mit der Einführung von Structured Outputs weitgehend abgelöst; wer heute neu integriert, greift zu Structured Outputs. JSON Mode bleibt für Fälle relevant, in denen kein Schema definierbar ist oder in denen Open-Weight-Modelle ohne Constrained-Decoding-Bibliothek genutzt werden.

Prompt Engineering und Structured Output greifen auf unterschiedlichen Ebenen. Ein [Prompt](/insights/glossar/prompt-engineering/) kann das Modell auffordern, JSON auszugeben, erzwingt die Struktur aber nicht. Die Wahrscheinlichkeit von Schema-Verletzungen liegt bei reinem Prompt Engineering im niedrigen einstelligen Prozentbereich, bei Structured Outputs bei nahezu null. Die zwei Techniken ergänzen sich: Der Prompt beschreibt weiterhin die Aufgabe, das Schema erzwingt die Form. Ein sauberer Structured-Output-Aufruf braucht beides zusammen: ein präzises Feld-Beschreibungs-JSON-Schema plus einen instruktiven Prompt, der dem Modell die semantische Bedeutung der Felder erklärt.

Beispiel: Ticket-Extraktion aus Support-Mails

Eine Anwendung verarbeitet eingehende Support-Mails und schreibt strukturierte Tickets in ein Zendesk-System. Ohne Structured Output läuft der Aufruf über einen Prompt der Art „Extrahiere Kategorie, Priorität und betroffenes Produkt aus der folgenden E-Mail und antworte als JSON". Das Modell liefert Antworten wie {"category": "Abrechnung", "priority": "hoch", "product": "Modul A"} in etwa 92 % der Fälle korrekt, bei 8 % kommt es zu Formatfehlern: Kategorie als Freitext („könnte Abrechnung sein"), Priorität als deutsches Wort statt Enum, fehlendes product-Feld. Die Anwendung braucht eine Repair-Schleife, die bei Format-Fehlern nachbessert oder eine zweite Modell-Anfrage stellt.

Mit Structured Output definiert die Anwendung ein JSON-Schema mit Enums für die kategorialen Felder:

{
  "type": "object",
  "properties": {
    "category": { "type": "string", "enum": ["billing", "technical", "shipping", "other"] },
    "priority": { "type": "string", "enum": ["low", "medium", "high"] },
    "product": { "type": "string" }
  },
  "required": ["category", "priority", "product"],
  "additionalProperties": false
}

Sie übergibt das Schema mit dem API-Aufruf. Das Modell erzeugt eine Antwort, die dem Schema entspricht: Enums werden garantiert eingehalten, Pflichtfelder sind vollständig, keine zusätzlichen Felder. Die Anwendung schreibt das Ergebnis direkt in die Ticket-Datenbank ohne Validierungs- oder Repair-Schleife. Die Fehler-Rate sinkt auf unter 0,1 %, die verbleibenden Fehler betreffen semantische Fehl-Klassifikationen (Kategorie richtig JSON-formatiert, aber falsch inhaltlich), nicht mehr Formatfehler.

Typische Einsatz-Gebiete sind Dokumenten-Extraktion (Rechnungen, Verträge, Formulare in strukturierte Datensätze überführen), Klassifikations-Pipelines mit definierten Label-Sets, Agenten-Orchestrierung (jeder Zwischen-Schritt liefert ein prüfbares Ergebnis-Objekt) und Data Enrichment aus unstrukturiertem Text. Die Zuverlässigkeit hängt an drei Faktoren: präzise Feld-Beschreibungen im Schema (was gehört in product: Produktname, SKU oder Kategorie?), Enums für begrenzte Wertebereiche statt Freitext-Feldern und ein Prompt, der die semantische Bedeutung der Felder erklärt, statt sich auf Feld-Namen zu verlassen.