Tam et al. dokumentieren in ihrem EMNLP-2024-Paper einen unbequemen Befund: Wenn du in einem JSON-Schema das Antwortfeld vor das Reasoning-Feld setzt, fällt die Accuracy von GPT-3.5-Turbo auf dem GSM8K-Benchmark von 76,60 auf 49,25 Prozent. 27,35 Prozentpunkte. Dasselbe Modell, dasselbe Prompt, dieselben Aufgaben. Nur die Reihenfolge der Felder im Response-Schema verändert. Shrimal et al. zeigen im Amazon-Preprint vom Oktober 2025 das Gegenstück: LLM-optimierte Schemas erzielen auf dem SWDE-Datensatz 64,7 Prozent höhere Accuracy als human-readable Varianten und reduzieren Extraktionsfehler beim ersten Retry um 92 Prozent.
Beide Papers sagen dasselbe in unterschiedlicher Lautstärke. Constrained Decoding löst das Syntaxproblem. Das Schema, das du dem Modell vorlegst, löst es nicht.
Strict Mode garantiert Form, nicht Inhalt
Wer mit OpenAI Structured Outputs oder vergleichbaren Strict-Mode-Implementierungen arbeitet, kennt das Versprechen: 100 Prozent Schema-Compliance. Die Ausgabe ist garantiert ein gültiges JSON nach deinem Schema. Kein fehlendes Feld, kein falscher Typ, keine halluzinierten Zusatzschlüssel.
Das stimmt. Es ist eine ernsthafte Errungenschaft. Aber es deckt nur die syntaktische Ebene ab. Die Frage, ob die Werte in den Feldern sinnvoll sind, ob das Reasoning vor der Antwort steht, ob ein Freitextfeld ohne Längenbegrenzung in Prosa abdriftet — alles davon ist Schema-Design. Und Schema-Design ist die letzte Schicht, in der ein Mensch sitzt.
Genau dort sammeln sich jetzt die Fehler.
Property-Order ist kein Detail. Es ist Reasoning-Architektur.
Der Tam-et-al.-Befund ist auf den ersten Blick kontraintuitiv. JSON ist doch ein ungeordnetes Format. Spielt es wirklich eine Rolle, ob answer vor oder hinter reasoning steht?
Es spielt eine Rolle, weil das Modell Token für Token von links nach rechts dekodiert. Wenn das answer-Feld zuerst kommt, muss das Modell raten, bevor es gerechnet hat. Wenn reasoning zuerst kommt, baut das Modell den Lösungsweg auf und entnimmt ihm die Antwort. Der Effekt entspricht einer impliziten Chain-of-Thought-Erzwingung. Wer das Schema falsch sortiert, deaktiviert genau diese Fähigkeit.
Das ist kein Syntaxfehler. Kein Validator schlägt an. Keine Retry-Logik fängt das ab. Das Modell liefert valides JSON mit einer schlechteren Antwort, und du merkst es nur an einem Accuracy-Drop, den niemand auf das Schema zurückführt.
Die unsichtbaren Grenzen von Strict Mode
OpenAIs Strict Mode hat harte Schema-Limits, die in der offiziellen Dokumentation nur teilweise beschrieben sind. Die OpenAI Developer Community hat sie über Forum-Threads herausgearbeitet:
- Maximal 5 Verschachtelungsebenen
- Maximal 100 Objekt-Properties insgesamt
- Maximal 500 Enum-Werte über das gesamte Schema
- Maximal 15.000 Zeichen für die Summe aller Property-Namen plus Enum-Werte plus Konstantwerte
minLength,minimum,maximum,minItems,maxItemswerden nicht unterstützt
Wer eines dieser Limits überschreitet, bekommt keine Compliance bei 99 Prozent. Das Schema fliegt raus: Fehlermeldung Invalid schema for response_format. Aus 100 Prozent Compliance werden 0 Prozent. Ohne Vorwarnung.
Besonders perfide ist das 15.000-Zeichen-Limit. Drei Enum-Felder mit je 50 langen Werten reichen, um es zu reißen. Die offizielle Dokumentation erwähnt diese Grenze nicht prominent. Das Resultat: Teams glauben, sie laufen mit Strict Mode, sehen aber stillschweigend wieder die 93 Prozent Compliance des Standardmodus, weil ihr Schema im Hintergrund abgelehnt wurde und das System auf den Fallback gesprungen ist.
”Wir retrien doch einfach”
Das gängige Gegenargument lautet: Wir nutzen Pydantic mit Instructor, max_retries=2, und liegen bei nahezu 100 Prozent Erfolgsrate. Instructor verzeichnet laut PyPI über drei Millionen monatliche Downloads (Stand 2025), Self-Healing ist ein Kernfeature. Problem gelöst.
Nicht ganz. Retry kostet zwei Dinge: Latenz und Tokens. Ein zweiter Inference-Call addiert je nach Modell ein bis drei Sekunden, und du bezahlst die Input-Tokens komplett ein zweites Mal. Bei dem Volumen, in dem Strukturierte Ausgaben überhaupt erst sinnvoll sind, summiert sich das.
Schwerwiegender ist die zweite Schwachstelle. Retry behebt syntaktische Fehler — ein halluziniertes Feld, ein falscher Typ, ein abgeschnittenes JSON. Das fängt die zweite Runde ab. Ein Freitextfeld ohne Constraint halluziniert beim zweiten Versuch genauso konsistent wie beim ersten. Die 27-Prozentpunkte-Degradation durch falsche Property-Order ist kein Syntaxfehler. Du kannst beliebig oft retrien. Das Schema bleibt falsch sortiert, und das Modell rät weiter, bevor es rechnet.
Schema-Linting wird zur eigenen Disziplin
Der Markt hat das Signal verstanden. Was vor zwei Jahren noch Validator-Bibliotheken waren, entwickelt sich gerade zu Schema-Compilern mit statischer Analyse.
BAML von BoundaryML ist in Rust geschrieben und kompiliert Schemas vor dem ersten API-Call. Falsche Verschachtelung, ungültige Strict-Mode-Konstrukte, ungeschützte Freitextfelder: Schema-Fehler werden zur Compile-Zeit erkannt, nicht zur Runtime. Pydantic AI verschiebt sich von einer reinen Validierungsschicht zu einem Schema-Compiler mit Modell-Awareness. Amazon hat mit ARCHITECT/PARSE im selben Preprint einen vollautomatischen Schema-Optimierer veröffentlicht, der laut der Autoren cross-model generalisiert. Anthropic hat seine Structured Outputs am 14. November 2025 in die Public Beta entlassen und damit die letzte große API auf Strict-Mode-Niveau gehoben.
Der gemeinsame Nenner: Schemas sind Code, und Code wird gelintet, bevor er deployed wird. Wer 2026 ein Schema in einer Code-Review-PR ohne statische Prüfung einreicht, baut dieselbe Sorte Bugs ein, die in JavaScript vor TypeScript Standard waren.
Was du jetzt anders machen solltest
1. Reasoning-Felder kommen zuerst, Antwort-Felder zuletzt. Wenn dein Schema ein answer- oder result-Feld hat, gehört davor mindestens ein reasoning-, analysis- oder steps-Feld. Die Reihenfolge ist nicht kosmetisch. Sie ist die einzige Möglichkeit, Chain-of-Thought im Strict Mode zu erzwingen, ohne ein eigenes Reasoning-Modell zu betreiben.
2. Freitextfelder bekommen Constraints. Wenn Strict Mode keine zulässt, dann auf Validator-Ebene. OpenAI Strict Mode unterstützt kein minLength oder maxLength. Das heißt nicht, dass du sie weglässt. Es heißt, du baust die Längen- und Format-Validierung in der nachgelagerten Schicht ein, mit Pydantic-Validators oder einer eigenen Sanity-Check-Routine. Ein offenes description: string ohne irgendeine Begrenzung ist die Einladung an das Modell, in Prosa zu kippen.
3. Enum-Werte und Property-Namen kurz halten. Das 15.000-Zeichen-Budget ist global. Wer drei Klassifikator-Felder mit je 50 ausführlichen Enum-Werten schreibt, ist nahe am Limit. Lieber kurze Codes (status_a, status_b) plus ein Lookup im Code als sprechende, lange Strings im Schema. Wenn das Schema lautlos abgelehnt wird, fällst du auf 93 Prozent Compliance ohne Fehlermeldung zurück.
4. Schemas in CI lintern, nicht erst zur Runtime entdecken. Tools wie BAML oder Pydantic AI prüfen Schema-Konformität vor dem ersten Call. Wer das nicht nutzt, schreibt Tests, die exakt den Pre-Flight-Check ersetzen. Beides ist akzeptabel. Kein Pre-Flight-Check ist es nicht.
Die nüchterne Lesart
Constrained Decoding hat das gelöst, was 2023 noch das große Versprechen war: garantiert valides JSON. Das ist eine echte Errungenschaft, und niemand sollte zurück zu freier Prompt-Hoffnung. Aber die Lücke ist nicht weg. Sie ist eine Schicht nach oben gewandert, in das Schema selbst.
27 Prozentpunkte Accuracy durch Property-Order. 92 Prozent weniger Retry-Fehler durch optimierte Schemas. Stille Strict-Mode-Deaktivierung durch ein 15.000-Zeichen-Limit, das niemand auf dem Radar hat. Das sind keine Modellprobleme. Das sind Designprobleme, die ein Mensch in den Schema-Editor tippt und später in den Production-Logs sucht.
Die Felder in der richtigen Reihenfolge schreiben, Freitextfelder absichern, Schemas in CI lintern, dann holt man das Beste aus 100 Prozent Compliance heraus. Wer das nicht tut, hat valides JSON mit halluzinierten Werten und wundert sich, warum das Modell im Demo schlechter wirkt als im Paper.
Wer wissen will, welche Schema-Compiler sich gerade durchsetzen, wo die nächsten Strict-Mode-Limits öffentlich werden und welche Architekturentscheidungen sich gerade vom Experiment zur Convention verfestigen: Der KI-Syndikat Newsletter ordnet diese Verschiebungen einmal pro Woche ein, mit Quellen und ohne Schaumschlägerei.