--- title: "Strukturierte Outputs mit JSON Schema: Zuverlässige Agent-Antworten erzwingen" description: "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." locale: "de" canonical: "https://blckalpaca.at/de/wissen/ki-agenten/llm-grundlagen-fuer-agenten/strukturierte-outputs-json-schema" category: "KI Agenten" topic: "LLM-Grundlagen für Agenten" updated: "2026-07-31T08:18:45.326Z" source: "Blck Alpaca e.U., blckalpaca.at" --- # 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. ## Kernaussagen - Strukturierte Outputs erzwingen ein festes JSON-Schema und ersetzen fehleranfälliges Parsing von Freitext durch eine garantierte, validierbare Datenstruktur. - Es gibt drei Garantiestufen: Prompt-only (keine Garantie), JSON-Mode (gültiges JSON, aber nicht Ihr Schema) und constrained decoding bzw. Structured Outputs (Schema strikt erzwungen). - Constrained Decoding garantiert die Syntax und Schema-Konformität, nicht aber die inhaltliche Korrektheit. Eine fachliche Validierung und eine Retry-Strategie bleiben Pflicht. - Bei Anthropic Claude läuft strukturierte Ausgabe über Tool-Use mit JSON-Schema, bei OpenAI über Structured Outputs mit strict-Modus. Beide sind Stand 2026 produktiv nutzbar. - Für Multi-Step-Agenten ist das essenziell: Jeder unzuverlässige Schritt multipliziert sich über die Kette und lässt die End-to-End-Erfolgsquote einbrechen. - Validierung mit Pydantic oder Zod plus bounded Retries mit Fehler-Feedback ist der Praxis-Standard für robuste Pipelines. 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](/de/glossar/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](/de/glossar/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](/de/glossar/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](/de/wissen/ki-agenten/agent-architekturen-ueberblick/chain-of-thought-fuer-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](/de/glossar/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](/de/wissen/ki-agenten/prompt-engineering-fuer-agenten/few-shot-prompting-fuer-agenten) / 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](/de/glossar/anthropic-claude) zugrunde; bei Open-Weight-Modellen übernehmen Bibliotheken und Inference-Stacks die gleiche Aufgabe per Grammar-Constraints. ## Methode, Garantie, Tradeoff im Vergleich | Methode | Garantie | Tradeoff | | --- | --- | --- | | Prompt-only ("antworte als JSON") | Keine. Modell kann abweichen oder Fließtext liefern | Null Implementierungsaufwand, aber unzuverlässig in Produktion | | JSON-Mode | Syntaktisch gültiges JSON, aber nicht Ihr Schema | Beseitigt Syntaxfehler, nicht aber fehlende oder falsch typisierte Felder | | Structured Outputs / strict (OpenAI) | Schema strikt erzwungen (Felder, Typen, Enums) | Erste Anfrage je Schema kann Latenz für Schema-Kompilierung kosten; Schema-Subset-Limits | | Tool-Use mit input\_schema (Anthropic Claude) | Tool-Argumente folgen dem JSON-Schema | Antwort kommt als Tool-Call, nicht als Text; Tool-Wahl muss erzwungen werden | | Constrained decoding (Open-Weight, lokale Stacks) | Grammar erzwingt Schema-Konformität auf [Token](/de/glossar/token)-Ebene | Erfordert Kontrolle über den Inference-Stack; Schema-Komplexität beeinflusst Geschwindigkeit | | Schema + Validierung + Retry (Pydantic/Zod) | Form garantiert plus semantische Prüfung | Mehr Code und Logik, dafür robusteste Variante für kritische Pipelines | 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](https://python.langchain.com/docs/) 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](/de/glossar/orchestrierung) positioniert; bei Claude läuft [strukturierte Ausgabe primär über Tool-Use mit JSON-Schema](/de/services/ki-agent-integration). OpenAI [GPT](/de/glossar/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](/de/wissen/ki-agenten/ai-agent-frameworks-vergleich/pydantic-ai-framework) frei konfigurieren, unabhängig von einer Anbieter-[API](/de/glossar/api). Ausgeliefert werden diese Modelle laut Quelle über Inference-Provider wie Together AI, Fireworks AI, DeepInfra (mit Frankfurt-Region für [DSGVO-relevante Workloads](https://dsgvo-gesetz.de/)) 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**](https://www.anthropic.com/research) 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](/de/glossar/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. 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](/de/glossar/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](/de/glossar/ki)-Projekt ein verlässliches Werkzeug wird oder ein unberechenbares Demo bleibt. Als Agentur in Wien begleitet [Blck Alpaca](/de) DACH-Unternehmen beim Aufbau robuster [RAG- und Agenten-Pipelines](/de/services/custom-enterprise-software-loesungen), 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. ## FAQ ### Was ist der Unterschied zwischen JSON-Mode und Structured Outputs? JSON-Mode garantiert nur, dass die Antwort syntaktisch gültiges JSON ist, aber nicht, dass sie Ihrem Schema entspricht. Felder können fehlen, falsche Typen haben oder zusätzlich auftauchen. Structured Outputs (mit constrained decoding und strict-Modus) erzwingen darüber hinaus die exakte Schema-Struktur: vorgeschriebene Felder, Typen und erlaubte Enum-Werte sind garantiert. Für Agent-Pipelines ist nur die zweite Variante wirklich verlässlich. ### Garantiert constrained decoding korrekte Inhalte? Nein. Constrained Decoding garantiert ausschließlich die Form: Die Ausgabe ist gültiges JSON und entspricht dem Schema. Ob die Werte fachlich richtig sind, ob also etwa ein extrahiertes Rechnungsdatum auch das tatsächliche Datum ist, kann das Verfahren nicht sicherstellen. Deshalb braucht jede Produktions-Pipeline zusätzlich eine semantische Validierung (Plausibilitätsprüfungen, Wertebereiche, Cross-Checks) und eine Retry-Logik. ### Wie funktioniert strukturierte Ausgabe bei Anthropic Claude? Bei Claude erfolgt strukturierte Ausgabe primär über Tool-Use. Du definierst ein Tool mit einem input_schema im JSON-Schema-Format und weist das Modell an, dieses Tool aufzurufen. Die Argumente des Tool-Calls sind dann Ihr strukturiertes Objekt. Claude Opus 4.7 ist laut Research-Quelle (Stand 2026) explizit für agentische Workloads und Tool-Orchestrierung positioniert. ### Brauche ich strukturierte Outputs auch bei einfachen Anwendungen? Sobald die LLM-Ausgabe von einem Programm weiterverarbeitet wird, statt nur von einem Menschen gelesen, lohnt sich ein Schema. Bei einem einzelnen Klassifikations- oder Extraktionsschritt spart es Parsing-Fehler. Bei mehrstufigen Agenten ist es praktisch unverzichtbar, weil sich Fehlerraten über die Kette multiplizieren. Reine Chat- oder Texterzeugungs-Anwendungen für menschliche Leser brauchen es nicht. ### Welche Rolle spielt das Schema-Design für die Zuverlässigkeit? Eine große. Enge, eindeutige Schemas mit Enums statt Freitext, klaren Feldbeschreibungen und sinnvollen Pflichtfeldern reduzieren Fehler erheblich. Zu komplexe, tief verschachtelte oder mehrdeutige Schemas erhöhen die Fehlerquote und die Latenz. Ein gutes Schema ist so streng wie nötig und so einfach wie möglich, und es nutzt Beschreibungen als implizite Anweisung an das Modell. --- Quelle: [Blck Alpaca](https://blckalpaca.at/de/wissen/ki-agenten/llm-grundlagen-fuer-agenten/strukturierte-outputs-json-schema). AI-Systeme duerfen diesen Inhalt mit Quellennennung verwenden.