Structured Output
Structured Output ist eine Funktion, die ein LLM dazu zwingt, Antworten zurückzugeben, die einem festgelegten Schema entsprechen, typischerweise einem JSON-Schema. Statt zu hoffen, dass das Modell parsebares JSON erzeugt, beschränkt die Inferenz-Engine die Token-Stichprobe, sodass die Ausgabe garantiert valide ist.
Structured Output ist eine Funktion, die ein LLM dazu zwingt, Antworten zurückzugeben, die einem festgelegten Schema entsprechen, typischerweise einem JSON-Schema. Statt zu hoffen, dass das Modell parsebares JSON erzeugt, beschränkt die Inferenz-Engine die Token-Stichprobe, sodass die Ausgabe garantiert valide ist.
Warum es wichtig ist
LLMs, die Freitext zurückgeben, sind programmatisch schwer zu verarbeiten. Selbst wenn man "gib JSON zurück" verlangt, fügen Modelle gelegentlich Fließtext hinzu, lassen Felder aus oder halluzinieren Typen. Das bricht nachgelagerten Code und erzwingt defensives Parsen. Structured Output löst das Problem auf der Decoding-Ebene: Sie erhalten valides JSON in 100 % der Fälle, nicht in 95 %. OpenAI, Anthropic, Google sowie Open-Source-Engines wie vLLM und Outlines unterstützen es nun nativ und machen es zur Standardweise, zuverlässige LLM-Pipelines zu bauen.
Wie es funktioniert
Constrained Decoding: Bei jedem Generierungsschritt kann das Modell nur Tokens auswählen, die die Ausgabe mit dem Schema kompatibel halten. Tokens, die das Schema verletzen würden, werden auf die Wahrscheinlichkeit null maskiert.
Schema-Spezifikation: Sie geben ein JSON-Schema (oder ein Pydantic-Modell, ein Zod-Schema, einen TypeScript-Typ) an, das erforderliche Felder, Typen und Enums beschreibt.
Validierungsfreies Parsen: Der Aufrufer kann das Ergebnis mit JSON.parse verarbeiten, ohne try/catch um fehlerhafte Ausgaben zu legen.
JSON-Modus vs Structured Output
| Aspekt | JSON-Modus | Structured Output |
|---|---|---|
| Garantie | Valide JSON-Syntax | Valides JSON, das Ihrem Schema entspricht |
| Schema-Durchsetzung | Keine | Vollständig |
| Vorhandensein der Felder | Nicht garantiert | Garantiert |
| Halluzinierte Felder | Möglich | Unmöglich |
| Latenz-Mehraufwand | ~0 | Gering (Kompilieren der Constraints) |
Der JSON-Modus stellt nur sicher, dass die Ausgabe parsbar ist. Structured Output stellt sicher, dass sie parsbar ist und der exakten Form entspricht, die Sie benötigen. Für produktive Systeme sollten Sie stets Structured Output verwenden, wenn verfügbar.
Wann man es einsetzt
Daten aus Text extrahieren: Namen, Daten, Adressen aus unstrukturierter Eingabe ziehen.
Agenten bauen, die Tools aufrufen: Die Argumente des Tool-Aufrufs müssen exakt dem Parameter-Schema des Tools entsprechen.
In Enums klassifizieren: Das Modell zwingen, eines aus einer festen Menge von Labels zu wählen.
Mehrfeld-Antworten erzeugen: Titel, Zusammenfassungen, Tags, Bewertungen in einem Durchgang.
Überall, wo Sie derzeit Modellausgaben per Regex parsen: Das ist ein Fehler, der nur darauf wartet zu passieren.
Kompromisse
Leichter Latenz-Mehraufwand: Der Decoder muss den Grammatikzustand verfolgen. Meist vernachlässigbar.
Verringerte Kreativität: Starke Schema-Einschränkungen können die Generierung mechanisch wirken lassen. Für kreatives Schreiben ist Freitext vorzuziehen.
Schema-Design ist entscheidend: Übermäßig strenge Schemata (erforderlich: alle 20 Felder) zwingen das Modell, Werte zu halluzinieren. Machen Sie das optional, was wirklich optional ist.
Nicht alle Modelle unterstützen es: Ältere Modelle und einige Open-Source-Modelle haben noch keine native Unterstützung. Outlines und ähnliche Bibliotheken können es nachrüsten.
Beispiel
Schema:
{
"type": "object",
"properties": {
"title": { "type": "string" },
"tags": { "type": "array", "items": { "type": "string" } },
"sentiment": { "enum": ["positive", "negative", "neutral"] }
},
"required": ["title", "tags", "sentiment"]
}
Garantierte Ausgabe:
{ "title": "Launch recap", "tags": ["product", "Q2"], "sentiment": "positive" }
Keine Parse-Fehler. Keine fehlenden Felder. Keine erfundenen Enum-Werte.
Sources: