Een nieuwe benchmark van 12 large-language-model (LLM) API's laat zien dat bijna elke dienst JSON retourneert dat overeenkomt met het gevraagde schema, maar dat een aanzienlijke minderheid feitelijk onjuiste waarden uitspuugt. De tokenkosten van hetzelfde schema variëren van enkele tientallen tokens tot bijna vijfduizend. Ontwikkelaars die extractie-pipelines of datagestuurde agents bouwen, kunnen "schema-valide" niet langer vertrouwen als een graadmeter voor "correctheid".

Waarom de test belangrijk is

API-aanbieders prijzen "structured output" aan als een manier om parseerfouten te elimineren. De belofte is simpel: geef het model een JSON-schema en het zal de velden invullen zonder dat je kwetsbare post-processing code hoeft te schrijven. In de praktijk vertrouwen veel productiesystemen al op deze garantie om crashes te voorkomen en downstream analytics-pipelines schoon te houden. Wanneer de garantie slechts deels waar is, sluipen er stilletjes bugs in en lopen kostenberekeningen op basis van tokenverbruik volledig uit de hand.

Het goede nieuws: schema's worden nu grotendeels afgedwongen

  • De meeste modellen in de testsuite produceerden JSON die een strikte validator doorstond.
  • Constrained decoding – modellen die de decoder vastzetten aan het schema kunnen geen losse karakters produceren, waardoor slecht geformatteerde payloads vrijwel uitgestorven zijn.
  • Parse-foutpercentages – ontwikkelaars hoeven calls niet langer in try-catch-blokken te wikkelen voor JSON-syntaxfouten.

Het slechte nieuws: validiteit ≠ nauwkeurigheid

Een valide vorm garandeert geen valide waarde. Vier van de twaalf modellen — DeepSeek V4, Qwen en GLM-5.2 (de laatste twee verschijnen onder twee verschillende namen in het rapport) — produceerden perfect geformatteerde JSON die de verkeerde getallen bevatte wanneer de "thinking" (of chain-of-thought) modus aanstond.

  • Bij het Qwen-model ging een eenvoudige rekenkundige extractie van 1 correct antwoord op 16 met ingeschakelde redenering naar 8 correct op 8 wanneer redenering was uitgeschakeld.
  • DeepSeek V4 Pro vertoonde een vergelijkbare schommeling: de extractienauwkeurigheid steeg van 1/8 naar 7/8 zodra het model stopte met het proberen uit te leggen van zijn stappen.

De extra redeneerstap verstoort de constrained decoder, waardoor het model in hallucinaties kan vervallen terwijl het nog steeds de buitenste haakjes respecteert.

De minder mooie kant: verrassingen in tokenkosten en genegeerde parameters

  • Claude's response format – wanneer via OpenAI-compatibele endpoints benaderd, negeerde Claude de response_format flag volledig, wat resulteerde in 0 % schema-conforme output. Het model ondersteunt wel gestructureerde calls, maar alleen via de native tool-call interface van Anthropic.
  • Schema token-inflatie – een bescheiden schema van 12 KB kost 30 tokens op DeepSeek, terwijl dezelfde payload 4.959 tokens opslokte op Claude.
  • Facturatie-inconsistenties – sommige aanbieders tellen het schema mee als onderdeel van de prompt en rekenen voor elke verbruikte token; anderen behandelen het als een gratis overlay. Op grote schaal kunnen de kosten voor het schema de kosten van de gegenereerde inhoud van het model overstijgen.

Wat ontwikkelaars nu moeten doen

  1. Valideer waarden, niet alleen vormen – een schema-validator zal een onjuist numeriek antwoord niet oppikken, zelfs niet als het voldoet aan het verwachte type. Voeg domeinspecifieke controles toe (bereik, eenheid, consistentie tussen velden).
  2. Schakel chain-of-thought uit voor extractie op DeepSeek, Qwen en GLM wanneer je betrouwbare veldinvulling nodig hebt. De extra redeneerstap is optioneel en niet vereist voor correctheid.
  3. Audit het tokenverbruik – log hoeveel tokens elke aanvraag verbruikt, inclusief het schema-gedeelte, en vergelijk de facturen van verschillende leveranciers voordat je overgaat tot grootschalige implementaties.
  4. Test de portabiliteit – een schema dat werkt op OpenAI kan stilletjes worden genegeerd op Gemini of Claude. Voer een snelle sanity check uit op elk doelplatform voordat je code publiceert.

Tegenargument van de leveranciers

Sommige aanbieders voeren aan dat de "thinking" modus een keuze van de ontwikkelaar is, bedoeld voor taken waarbij uitleg belangrijker is dan pure extractienauwkeurigheid. Claude negeert de response_format flag en suggereert om in plaats daarvan de native tool calls van Anthropic te gebruiken. Die verklaringen zijn technisch gezien correct, maar ze leggen de verantwoordelijkheid bij de ontwikkelaar om te weten welke modus gekozen moet worden en hoe er budget moet worden vrijgemaakt voor verborgen tokencosten.

Conclusie

Een JSON-schema is geen vangnet meer; het is slechts een vorm. Zorg ervoor dat de gegevens binnenin overeenkomen met de werkelijkheid, houd de verborgen tokencosten in de gaten en onthoud dat het "denken" van een model zelfs de meest overzichtelijke output kan corrumperen.