JSONSchemaBench: Complexiteit van real-world schema's doorbreekt garanties voor gestructureerde LLM-output

De meeste teams beschouwen beperkte decodering (constrained decoding) als een opgelost probleem — voeg een JSON-schema toe en ontvang valide JSON terug. JSONSchemaBench (arXiv:2501.10868) is de eerste systematische poging om die aanname te testen tegen 9.558 real-world schema's, en de resultaten zijn minder geruststellend dan de marketing doet vermoeden.

Het onderzoeksartikel

Saibo Geng, Hudson Cooper, Michał Moskal en collega's bij Microsoft Research introduceren JSONSchemaBench, een benchmark van 9.558 schema's afkomstig uit echte productiebronnen: GlaiveAI-functiesignaturen, GitHub-repositories gestratificeerd op complexiteit van triviaal tot ultra, Kubernetes API-configuraties, Snowplow event-analytics-schema's en de JSONSchemaStore-collectie. Ze evalueren zes beperkte decoderingsframeworks — Guidance, Outlines, Llamacpp, XGrammar, OpenAI Structured Outputs en Gemini — op drie assen: dekking (coverage, welk deel van de schema's het framework überhaupt aankan), efficiëntie (tokens-per-seconde overhead vergeleken met onbeperkte generatie) en kwaliteit (nauwkeurigheid van de daaropvolgende taak). Het evaluatierooster bevat ook de officiële JSON Schema Test Suite, die 45 functiecategorieën documenteert die elke conforme engine zou moeten ondersteunen.

De kernclaim is dat schemacomplexiteit de beslissende variabele is die capabele frameworks scheidt van kwetsbare, en dat geen enkel framework domineert op alle drie de assen.

Belangrijke inzichten

• Dekking stort in onder schemacomplexiteit. Bij eenvoudige GlaiveAI-schema's scoren alle frameworks boven de 86%. Maar bij GitHub-Hard schema's — met nestingen op meerdere niveaus, recursieve definities en complexe patroonbeperkingen — daalt Guidance naar 41%, Llamacpp naar 39%, XGrammar naar 28% en Outlines naar een catastrofale 3%. OpenAI bereikt slechts 9% op GitHub-Hard, en Gemini produceert helemaal geen valide outputs bij schema's van gemiddelde complexiteit of hoger.
• Kubernetes legt een specifieke zwakte in XGrammar bloot. Ondanks de claims van XGrammar over snelheid, behaalt het slechts 7% dekking op Kubernetes-schema's. Dit komt waarschijnlijk doordat deze schema's afhankelijk zijn van contextafhankelijke patronen die de contextonafhankelijke precomputatie van XGrammar niet aankan. Dekking tegen een benchmark die Kubernetes-configs bevat, is niet optioneel voor productie-agents.
• Onder-beperking is gevaarlijker dan een compilatiefout. XGrammar vertoont 38 "under-constrained" fouten tegen de JSON Schema Test Suite — wat betekent dat het JSON genereert die het gedeclareerde schema schendt, terwijl het stilletjes succes rapporteert. Guidance heeft slechts 1 dergelijke fout. Voor een write-back agent wordt een compilatiefout opgemerkt tijdens de ontwerpfase; een onder-beperkte fout corrumpeert gegevens tijdens runtime zonder enig signaal.
• De "fast-forwarding" van Guidance levert een echte versnelling van 50% op. Wanneer er lange deterministische sequenties aanwezig zijn (bijv. veldnamen in een vaste objectstructuur), kan Guidance meerdere tokens per decoderingsstap vooruitspoelen. Op Llama-3.1-8B op een A100 draait Guidance op 6–9 ms per outputtoken, terwijl onbeperkte generatie op 15–16 ms draait. Outlines is met 30–46 ms langzamer dan onbeperkte generatie, grotendeels doordat de voorafgaande compilatie van de automaat 3–8 seconden per schema in beslag neemt.
• Beperkte decodering verbetert de nauwkeurigheid van redeneren enigszins. Op GSM8K (wiskunde) verhoogt Guidance de nauwkeurigheid van 80,1% (onbeperkt) naar 83,8%. Op Last Letter en Shuffle Objects liggen de winsten in de range van 1–3 punten. Dit spreekt de veelgehoorde vrees tegen dat het afdwingen van het JSON-formaat de kwaliteit van de antwoorden verslechtert — maar het effect is klein genoeg dat de keuze voor een formaat niet de drijfveer moet zijn voor frameworkselectie.
• Geen enkel framework dekt alle 45 JSON-schema functiecategorieën. Guidance dekt er 13, Llamacpp en XGrammar elk 1, en Outlines dekt er 0. De praktische implicatie is dat elk schema dat gebruikmaakt van if/then/else, unevaluatedProperties of recursieve $ref-definities onvoorspelbaar zal gedragen, afhankelijk van welke engine er onder de motorkap zit.

Wat standhoudt — en wat niet

De sterkste bijdrage van de benchmark is de bronvermelding van de schema's. Eerdere evaluaties gebruikten speelgoedschema's of collecties uit één bron. Het opnemen van Kubernetes-configs naast functiesignaturen biedt de juiste soort "adversarial diversity". De gelaagdheid in complexiteit (van triviaal tot ultra) geeft professionals bovendien een ijkpunt: als je schema's lijken op GlaiveAI-functieaanroepen, zijn zowel XGrammar als Guidance prima; als ze lijken op Kubernetes-manifesten, worden je opties snel beperkt.

De belangrijkste zwakte is de "single-sample greedy" evaluatie. Het meten van dekking met slechts één generatie per schema onderschat de werkelijke capaciteit — een framework kan 20% van de tijd falen, maar slagen bij een herpoging. Het artikel erkent dit, maar rapporteert geen "temperature-sampled pass@k" getallen, wat cruciaal zou zijn voor productiesystemen die herpogingen doen bij falen.

De vergelijking mengt ook onvergelijkbare modellen. Open-source frameworks (Guidance, Outlines, Llamacpp, XGrammar) zijn getest op Llama-3.2-1B, terwijl OpenAI en Gemini hun eigen, niet-openbare modellen draaien. De dekking van 9% van OpenAI op GitHub-Hard kan net zo goed de capaciteit van het model weerspiegelen als de architectuur van de beperkte decodering. Een eerlijke vergelijking zou gecontroleerde toegang tot het model vereisen — iets wat de auteurs uiteraard niet kunnen afdwingen bij propriëtaire aanbieders.

Waarom dit belangrijk is voor finance AI

Elke Beancount write-back agent genereert gestructureerde output. Als de agent Beancount-instructies genereert als JSON voordat deze worden geconverteerd naar .beancount-syntaxis, of als hij tools aanroept via JSON-schema's, is de betrouwbaarheid van die JSON-generatie geen detail — het is de kern van de zaak. Het FinTrace-artikel liet zien dat geavanceerde modellen moeite hebben met redeneren over tool-outputs; JSONSchemaBench onthult een ander probleem: nog voordat er geredeneerd wordt, kan de formatteringslaag stilletjes niet-conforme output genereren.

Het Kubernetes-resultaat is bijzonder veelzeggend voor Beancount. Grootboekschema's zijn geen platte verzamelingen van sleutel-waardeparen. Account-hiërarchieën, transactie-metadata en tag-structuren creëren geneste recursieve patronen die vergelijkbaar zijn met Kubernetes API-objecten. Een framework dat 7% scoort op Kubernetes is niet klaar voor complexe grootboekschema's, ongeacht hoe laag de overhead per token is.

De "under-constrained" foutmodus is degene waar ik wakker van zou liggen. Een Beancount-agent die XGrammar gebruikt, zou een transactie kunnen genereren die de interne validatiecontrole van het framework passeert, maar het daadwerkelijke schema schendt — en de agent zou geen reden hebben om het opnieuw te proberen. Stille corruptie is erger dan een zichtbare fout.

Wat je hierna kunt lezen

• XGrammar (arXiv:2411.15100, Dong et al.) — het technische artikel achter een van de snelste geteste frameworks, waarin de splitsing tussen contextonafhankelijke en contextafhankelijke tokens wordt uitgelegd en waarom Kubernetes-schema's dit onder druk zetten.
• Grammar-Aligned Decoding / ASAp (NeurIPS 2024) — toont aan dat token-maskering bij beperkte decodering de kansverdeling van het model kan vervormen en stelt een gecorrigeerd sampling-algoritme voor; de theoretische basis voor kwaliteitszorgen die de benchmark slechts indirect meet.
• XGrammar-2 (arXiv:2601.04426) — een vervolg dat XGrammar uitbreidt naar dynamische schema's in agent-omgevingen waar het schema zelf verandert tijdens een sessie met meerdere beurten, direct relevant voor Beancount-agents die hun outputformaat aanpassen op basis van welke accounttypen actief zijn.