JSONSchemaBench: Reale Schema-Komplexität bricht Garantien für strukturierten LLM-Output

Die meisten Teams betrachten eingeschränktes Dekodieren (constrained decoding) als gelöstes Problem – füge ein JSON-Schema hinzu, erhalte valides JSON zurück. JSONSchemaBench (arXiv:2501.10868) ist der erste systematische Versuch, diese Annahme anhand von 9.558 realen Schemata zu testen, und die Ergebnisse sind weniger beruhigend, als das Marketing vermuten lässt.

Das Paper

Saibo Geng, Hudson Cooper, Michał Moskal und Kollegen von Microsoft Research stellen JSONSchemaBench vor, einen Benchmark aus 9.558 Schemata aus realen Produktionsquellen: GlaiveAI-Funktionsaufruf-Signaturen, nach Komplexität geschichtete GitHub-Repositories von trivial bis ultra, Kubernetes-API-Konfigurationen, Snowplow-Event-Analytics-Schemata und die JSONSchemaStore-Sammlung. Sie bewerten sechs Frameworks für eingeschränktes Dekodieren – Guidance, Outlines, Llamacpp, XGrammar, OpenAI Structured Outputs und Gemini – anhand von drei Achsen: Abdeckung (welchen Anteil der Schemata das Framework überhaupt verarbeiten kann), Effizienz (Overhead der Token pro Sekunde im Vergleich zur uneingeschränkten Generierung) und Qualität (Genauigkeit der nachgelagerten Aufgaben). Das Evaluierungsgitter umfasst auch die offizielle JSON Schema Test Suite, die 45 Funktionskategorien dokumentiert, die jede konforme Engine unterstützen sollte.

Die Kernbehauptung ist, dass die Schema-Komplexität die entscheidende Variable ist, die fähige Frameworks von fragilen trennt, und dass kein einzelnes Framework über alle drei Achsen hinweg dominiert.

Kernideen

• Die Abdeckung bricht bei Schema-Komplexität zusammen. Bei einfachen GlaiveAI-Schemata erreichen alle Frameworks Werte über 86 %. Aber bei GitHub-Hard-Schemata – mit mehrstufiger Verschachtelung, rekursiven Definitionen und komplexen Muster-Constraints – fällt Guidance auf 41 %, Llamacpp auf 39 %, XGrammar auf 28 % und Outlines auf katastrophale 3 %. OpenAI erreicht bei GitHub-Hard nur 9 %, und Gemini liefert bei Schemata mit mittlerer Komplexität oder höher überhaupt keine validen Ausgaben mehr.
• Kubernetes offenbart eine spezifische Schwäche in XGrammar. Trotz der Geschwindigkeitsversprechen von XGrammar erreicht es nur eine Abdeckung von 7 % bei Kubernetes-Schemata. Dies liegt wahrscheinlich daran, dass diese Schemata auf kontextabhängigen Mustern basieren, die die kontextunabhängige Vorberechnung von XGrammar nicht verarbeiten kann. Eine Abdeckung gegenüber einem Benchmark, der Kubernetes-Konfigurationen enthält, ist für Produktions-Agenten nicht optional.
• Unzureichende Einschränkung ist gefährlicher als ein Kompilierungsfehler. XGrammar weist 38 Fehler durch unzureichende Einschränkung (under-constrained) gegenüber der JSON Schema Test Suite auf – das bedeutet, es gibt JSON aus, das das deklarierte Schema verletzt, meldet aber fälschlicherweise Erfolg. Guidance hat nur einen solchen Fehler. Für einen Write-Back-Agenten wird ein Kompilierungsfehler zur Designzeit abgefangen; ein Under-constrained-Fehler korrumpiert Daten zur Laufzeit ohne jegliches Signal.
• Das Fast-Forwarding von Guidance liefert eine echte Geschwindigkeitssteigerung von 50 %. Wenn lange deterministische Sequenzen vorhanden sind (z. B. Feldnamen in einer festen Objektstruktur), kann Guidance mehrere Token pro Dekodierungsschritt überspringen. Auf einem Llama-3.1-8B auf einem A100 läuft Guidance mit 6–9 ms pro Output-Token, während die uneingeschränkte Generierung 15–16 ms benötigt. Outlines ist mit 30–46 ms langsamer als die uneingeschränkte Generierung, was hauptsächlich an der anfänglichen Automaten-Kompilierung liegt, die 3–8 Sekunden pro Schema beansprucht.
• Eingeschränktes Dekodieren verbessert die Argumentationsgenauigkeit leicht. Bei GSM8K (Mathematik) steigert Guidance die Genauigkeit von 80,1 % (uneingeschränkt) auf 83,8 %. Bei "Last Letter" und "Shuffle Objects" liegen die Gewinne im Bereich von 1–3 Punkten. Dies widerspricht der weit verbreiteten Sorge, dass das Erzwingen des JSON-Formats die Antwortqualität verschlechtert – der Effekt ist jedoch so gering, dass die Formatwahl nicht die Entscheidung für ein Framework bestimmen sollte.
• Kein Framework deckt alle 45 JSON-Schema-Funktionskategorien ab. Guidance deckt 13 ab, Llamacpp und XGrammar jeweils eine und Outlines null. Die praktische Implikation ist, dass sich jedes Schema, das if/then/else, unevaluatedProperties oder rekursive $ref-Definitionen verwendet, unvorhersehbar verhält, je nachdem, welche Engine im Hintergrund arbeitet.

Was Bestand hat – und was nicht

Der stärkste Beitrag des Benchmarks ist die Auswahl der Schemata. Frühere Evaluierungen verwendeten Spielzeug-Schemata oder Sammlungen aus einer einzigen Quelle. Die Einbeziehung von Kubernetes-Konfigurationen neben Funktionsaufruf-Signaturen bietet die richtige Art von adverser Vielfalt. Die Komplexitätsschichtung (von trivial bis ultra) bietet Praktikern zudem eine Kalibrierungskurve: Wenn Ihre Schemata wie GlaiveAI-Funktionsaufrufe aussehen, sind XGrammar oder Guidance beide in Ordnung; wenn sie wie Kubernetes-Manifeste aussehen, werden Ihre Optionen schnell dünner.

Die Hauptschwäche ist die Single-Sample-Greedy-Evaluierung. Die Messung der Abdeckung mit nur einer Generierung pro Schema unterschätzt die wahre Leistungsfähigkeit – ein Framework könnte in 20 % der Fälle scheitern, aber bei einem erneuten Versuch erfolgreich sein. Das Paper räumt dies ein, berichtet jedoch keine Pass@k-Zahlen mit Temperature-Sampling, die für Produktionssysteme, die bei Fehlern einen Retry durchführen, wichtig wären.

Der Vergleich mischt zudem unvergleichbare Modelle. Open-Source-Frameworks (Guidance, Outlines, Llamacpp, XGrammar) wurden auf Llama-3.2-1B getestet, während OpenAI und Gemini ihre eigenen, nicht offengelegten Modelle verwenden. Die 9 % Abdeckung von OpenAI bei GitHub-Hard könnte ebenso sehr die Modellfähigkeit wie die Architektur des eingeschränkten Dekodierens widerspiegeln. Ein fairer Vergleich würde kontrollierten Modellzugriff erfordern – was die Autoren von proprietären Anbietern offensichtlich nicht erzwingen können.

Warum dies für Finanz-KI wichtig ist

Jeder Beancount-Write-Back-Agent erzeugt strukturierten Output. Wenn der Agent Beancount-Direktiven als JSON ausgibt, bevor er sie in die .beancount-Syntax konvertiert, oder wenn er Tools über JSON-Schemata aufruft, ist die Zuverlässigkeit dieser JSON-Generierung kein Detail – sie ist das entscheidende Element. Das FinTrace-Paper zeigte, dass Spitzenmodelle bei der Argumentation über Tool-Ausgaben scheitern; JSONSchemaBench offenbart ein orthogonales Problem: Schon vor der Argumentation kann die Formatierungsschicht unbemerkt nicht-konforme Ausgaben erzeugen.

Das Kubernetes-Ergebnis ist für Beancount besonders aufschlussreich. Ledger-Schemata sind keine flachen Key-Value-Listen. Kontohierarchien, Transaktionsmetadaten und Tag-Strukturen erzeugen verschachtelte rekursive Muster ähnlich wie Kubernetes-API-Objekte. Ein Framework, das bei Kubernetes nur 7 % erreicht, ist nicht bereit für komplexe Hauptbuch-Schemata, egal wie gering sein Overhead pro Token ist.

Der Fehlermodus der unzureichenden Einschränkung (under-constrained failure) ist das, was mir schlaflose Nächte bereiten würde. Ein Beancount-Agent, der XGrammar verwendet, könnte eine Transaktion ausgeben, die die interne Validierung des Frameworks besteht, aber das tatsächliche Schema verletzt – und der Agent hätte keinen Grund für einen erneuten Versuch. Stille Datenkorruption ist schlimmer als ein sichtbarer Fehler.

Was man als Nächstes lesen sollte

• XGrammar (arXiv:2411.15100, Dong et al.) – das technische Paper hinter einem der schnellsten getesteten Frameworks, das den Split in kontextunabhängige/abhängige Token erklärt und warum Kubernetes-Schemata diesen belasten.
• Grammar-Aligned Decoding / ASAp (NeurIPS 2024) – zeigt, dass Token-Maskierung beim eingeschränkten Dekodieren die Wahrscheinlichkeitsverteilung des Modells verzerren kann, und schlägt einen korrigierten Sampling-Algorithmus vor; die theoretische Grundlage für Qualitätsbedenken, die der Benchmark nur indirekt misst.
• XGrammar-2 (arXiv:2601.04426) – ein Follow-up, das XGrammar auf dynamische Schemata in agentischen Umgebungen ausweitet, in denen sich das Schema selbst während einer Multi-Turn-Sitzung ändert; direkt relevant für Beancount-Agenten, die ihr Ausgabeformat basierend auf den aktiven Kontotypen anpassen.