Het evalueren van JSON-opmaakvaliditeit bij hoge concurrency

Door Ivo Donker — samengesteld met AI-ondersteuning (Claude & Gemini) · Laatst bijgewerkt: 7 augustus 2026

Het meetprobleem van JSON-validiteit onder belasting

In veel moderne AI-architecturen worden grote taalmodellen (LLM's) gebruikt als gestructureerde dataverwerkers. Ze verwerken ongestructureerde tekst en leveren direct gestructureerde gegevens op in de vorm van JSON. Wanneer een applicatie geïsoleerd wordt getest met één enkel verzoek per keer, lijkt het genereren van een JSON-structuur vaak vlekkeloos te verlopen. De gegenereerde data laat zich zonder problemen parseer door de applicatielogica en alle verwachte sleutels zijn aanwezig.

Zodra hetzelfde systeem echter in een productieomgeving wordt geplaatst met tientallen of honderden gelijktijdige gebruikers (hoge concurrency), ontstaat er vaak een onverwacht kwaliteitsverlies. Het is belangrijk om hierbij twee verschillende verschijnselen niet door elkaar te halen: het trager worden van het systeem (de latency-stijging) en het degraderen van de uitvoerkwaliteit (de formaatnaleving). Bij hoge belasting op de inferentie-infrastructuur veranderen namelijk niet alleen de responstijden, maar kan ook de kans op ongeldige JSON-uitvoer toenemen.

Dit meetprobleem ontstaat doordat infrastructuurdruk leidt tot verschillende verstoringen. Zo kunnen verzadigde netwerkbuffers of drukke GPU-batches leiden tot voortijdig afgekapte antwoorden, aangepaste sampling-dynamiek bij server-side throttling, of gewijzigde keuzes in de token-pijplijn. Als ontwikkelaar of evaluator moet je deze twee factoren strictly gescheiden houden. Een trage respons die inhoudelijk en syntactisch correct is, vereist een heel andere optimalisatie dan een snelle respons die door een missend accoladeteken de downstream JSON-parser doet crashen.

Definitie en scoringsrubriek van JSON-validiteit

Het meten van JSON-validiteit vereist een heldere grens tussen wat puur syntactisch correct is en wat inhoudelijk voldoet aan het verwachte datamodel. Het enkel uitvoeren van een JSON.parse() is onvoldoende om de robuustheid van een model te beoordelen.

In de praktijk onderscheiden we drie niveaus van validiteit:

Parseerbaarheid (Syntactische validiteit): Voldoet de tekstreeks aan de officiële JSON-specificatie (ECMA-404)? Bevat de tekst sluitende haakjes, correct geëscapte quotes en geldige komma-scheidingen?
Schema-naleving (Structurele validiteit): Voldoet de geparseerde JSON aan de opgestelde JSON Schema-definitie? Zijn alle verplichte velden (required) aanwezig, en hebben de eigenschappen het juiste datatype (zoals string, integer, array of boolean)?
Datageldigheid (Inhoudelijke restricties): Vallen numerieke waarden binnen het toegestane bereik (zoals een waarschijnlijkheid tussen 0 en 1), en voldoen strings aan eventuele reguliere expressies of vooraf gedefinieerde opsommingswaarden (enums)?

In de praktijk proberen ontwikkelaars dit op te lossen met specifieke API-functionaliteiten. Bekijk de gids over structured output via LLM-API's voor gedetailleerde uitleg over hoe deze instellingen op API-niveau werken en hoe een JSON-modus wordt afgedwongen op de inferentie-engine.

Om uitval gestructureerd te kwantificeren tijdens benchmarks, wordt de onderstaande scoringsrubriek gehanteerd per gegenereerd antwoord. Elk verzoek krijgt een unieke foutcategorie toegewezen op basis van de eerste regel waarop het verwerkingsproces faalt.

Foutcategorie	Omschrijving van het probleem	Symptoom / Voorbeeld	Impact op applicatie	Score
Geen fout	Syntactisch correct, alle verplichte velden aanwezig en typen kloppen.	`{"status": "ok", "code": 200}`	Geen. Kan direct naar de vervolgfunctie worden doorgestuurd.	1.0 (Pass)
Syntactische breuk	JSON parser faalt direct. Afgekapte string, ongeëscapte tekens of ontbrekende sluitaccolade.	`{"status": "ok", "code": 200` (afgekapt)	Fatal crash in parser; vereist afvangen via try-catch blokken.	0.0 (Fail)
Schema-afwijking	JSON is parseerbaar, maar een verplicht veld ontbreekt of het type is onjuist.	`{"statustekst": "ok"}` (sleutel `status` ontbreekt)	NullPointerExceptions of foutieve veldtoewijzing in backend.	0.0 (Fail)
Bereikfout	Valid JSON en correct type, maar waarde valt buiten het gedefinieerde domein.	`{"percentage": 150}` (bereik 0-100)	Logische fouten in downstream bedrijfslogica of database-validatie.	0.25 (Partial)

Het onderscheid tussen een syntactische breuk en een schema-afwijking is essentieel voor je evaluatie. Een model dat bij hoge belasting syntactisch correcte JSON blijft produceren, maar af en toe een optioneel veld weglaat, vraagt immers om een andere tolerantie in je applicatielogica dan een model dat halve JSON-strings retourneert.

De meetopzet voor belastings- en validiteitstesten

Een doordachte meetopzet simuleert de druk op een productie-infrastructuur zonder onbestuurbare variabelen in te voeren. Om de invloed van concurrency geïsoleerd te meten, moet de kadersituatie bij elke meting exact gelijk zijn.

De standaard meetprocedure gebruikt de volgende opbouw:

Vaste benchmark-prompt: Gebruik een representatieve prompt die een middelgroot JSON-object terugvraagt met geneste arrays en diverse datatypen.
Deterministische instellingen: Zet de temperature op 0.0 (of zo laag mogelijk) en fixeerde de seed-parameter indien het inferentieplatform dit ondersteunt, zodat willekeurige modelvariatie geminimaliseerd wordt.
Model- en API-versie: Leg de exacte modelversie vast en gebruik dezelfde API-endpointconfiguratie gedurende het gehele traject.
Oplopende concurrency-niveaus: Voer het experiment uit in discrete stappen. Typische concurrency-niveaus (gelijktijdige verzoeken) zijn 1, 4, 8, 16 en optioneel 32 of 64 afhankelijk van de verwachte piekbelasting.

Als u naast belasting ook de invloed van kleine tekstuele veranderingen in de vraag wilt isoleren, raadpleeg dan het document over systeemprompt-variaties en consistentie om te zorgen dat de prompt zelf geen ruis veroorzaakt in de testresultaten.

Per concurrency-niveau verzamelt het benchmark-framework per individueel verzoek de volgende meetwaarden:

De ruwe stringwaarde van de gegenereerde respons body.
De HTTP statuscode en de API-specifieke respons-headers.
De finish_reason die door de inferentie-engine wordt geretourneerd (bijvoorbeeld stop, length, of content_filter).
De totale doorlooptijd van het verzoek en het aantal verwerkte invoer- en uitvoertokens.

Let op: De onderstaande gegevens dienen louter als illustratief voorbeeld om de structuur van een meettabel te verduidelijken. Het betreft geen daadwerkelijk uitgevoerde meting of feitelijke benchmarkscore.

Concurrency | Totaal Runs | Syntactisch Geldig | Schema Geldig | Uitval (Fail)
------------|-------------|--------------------|---------------|--------------
1           | 200         | 200                | 198           | 1.0%
4           | 200         | 199                | 195           | 2.5%
8           | 200         | 194                | 188           | 6.0%
16          | 200         | 181                | 170           | 15.0%

Onderscheid tussen modelfouten en infrastructuurfouten

Een van de grootste valkuilen bij het beoordelen van JSON-validiteit onder belasting is het verkeerd toeschrijven van de foutoorzaak. Een onvolledige JSON-string aan de clientzijde kan worden veroorzaakt door het taalmodel zelf (een modelfout), maar net zo goed door de infrastructuur waarop het model draait (een infrastructuurfout).

Het onderscheid stelt je in staat de juiste maatregel te nemen:

1. Infrastructuurfouten (Netwerk en Engine-limieten)

Wanneer de inferentie-server onder zware belasting raakt, kan het netwerk- of gateway-niveau ingrijpen. Dit uit zich op verschillende manieren:

HTTP 429 (Rate-limiting / Throttling): Het verzoek wordt door de API geweigerd vanwege een overschrijding van het aantal toegestane verzoeken per minuut (RPM) of tokens per minuut (TPM).
HTTP 504 of Connection Timeouts: Het verzoek duurt te lang in de wachtrij van de GPU-cluster en de HTTP-proxy verbreekt de verbinding. Dit resulteert in een lege of half ontvangen tekst.
Afkap vanwege tokenlimiet (Finish Reason: Length): Onder druk kan de configuratie van de max output tokens worden bereikt als de respons door vertragingen ongemerkt groter wordt dan de gereserveerde buffer. De engine stopt er dan midden in een JSON-sleutel mee.

Wanneer verzoeken massaal vastlopen op throttling of netwerkfouten, is het nuttig om het artikel over rate limits en kostenbeheer te raadplegen om de juiste retry-strategieën en limieten in te stellen in de testclient.

2. Modelfouten (Generatieve ontsporing)

Bij een echte modelfout heeft de API het verzoek succesvol afgehandeld (HTTP statuscode 200, finish_reason: stop), maar is de gegenereerde tekst inhoudelijk beschadigd. Dit gebeurt bijvoorbeeld wanneer het model bij zware batch-verwerking of door variërende interne aandacht-latencies de grammatica uit het oog verliest:

Het model sluit een geopende string niet af en stapt halverwege over op toelichtende proza.
Het model start met een geldige JSON-structuur, maar introduceert halverwege ongeldige tekens of dubbele komma's.
Het model vergeet de vereiste JSON-wrapper en levert platte tekst op met daarin een JSON-fragment.

In je testprotocol koppel je de resultaten los: infrastructuurfouten (zoals 429 of 504) moeten worden opgevangen door een automatische retry-mechanisme met exponentiële backoff vóórdat de uitval wordt geregistreerd. Alleen wanneer een respons met succes als status 200 binnenkomt, wordt de inhoud getoetst op JSON-validiteit. Zo voorkom je dat een instabiele netwerkverbinding wordt geïnterpreteerd als een onbetrouwbaar taalmodel.

Steekproefgrootte, statistiek en betrouwbaarheidsintervallen

Het uitvoeren van 5 of 10 verzoeken per concurrency-niveau is statistisch gezien niet representatief. Omdat fouten in JSON-generatie vaak zeldzame gebeurtenissen zijn (bijvoorbeeld een foutpercentage tussen de 1% en 5%), levert een kleine steekproef een enorme foutmarge op. Een test van 10 verzoeken waarbij 1 verzoek faalt, suggereert een foutpercentage van 10%, terwijl de werkelijke kans bij grote aantallen wellicht op 2% ligt.

Om een betrouwbaar uitvalpercentage te rapporteren, zijn minimaal een paar honderd runs per belastingsniveau noodzakelijk. Hierbij is het essentieel om te werken met een betrouwbaarheidsinterval in plaats van een enkel puntgetal.

Voor een binominale verdeling (een verzoek is immers 'geldig' of 'ongeldig') kan het betrouwbaarheidsinterval worden berekend met behulp van de Wilson score-interval methode. Dit geeft een realistisch beeld van de marge waarin het werkelijke foutpercentage zich bevindt.

Voor een wiskundige onderbouwing van steekproefomvang en betrouwbaarheidsintervallen verwijzen we naar het overzicht van statistiek voor LLM-evaluaties om foutmarges correct te berekenen en de vereiste steekproefgrootte vooraf te bepalen.

Wanneer je rapportages opstelt voor je team of opdrachtgever, presenteer je de uitval bij concurrency 16 dus niet als "5% faalt", maar als:

Faalpercentage: 5,0% (95%-betrouwbaarheidsinterval: [3,1% - 7,8%], N=300)

Deze werkwijze voorkomt dat beslissingen over infrastructuur of modelkeuze worden gebaseerd op toevallige uitschieters in kleine testsets.

De wisselwerking met latency en dekkingsmetingen

JSON-validiteit en responssnelheid staan in een directe relatie tot elkaar. Wanneer de belasting op een server toeneemt, stijgt de p95- en p99-latency (de responstijd van de traagste 5% respectievelijk 1% van de verzoeken). Uit benchmarks blijkt vaak dat de piek in JSON-faalpercentages samenvalt met deze latencypieken.

Wanneer een inferentie-engine onder zware druk staat, kan de verwerkingstijd per token (Time Per Output Token, TPOT) variëren. Als applicaties een strikte 'read-timeout' hanteren op de HTTP-client, zullen verzoeken precies op het moment dat de latency piekt worden afgebroken. Dit resulteert in een afgekapte JSON-string aan de ontvangerszijde.

Het is daarom cruciaal om beide metrieken gelijktijdig te monitoren, maar ze wel gescheiden te analyseren:

Latency-meting: Hoe lang duurt het voordat de volledige respons ontvangen is?
Validiteitsmeting: Is de ontvangen respons syntactisch en structureel correct?

Hoewel dit artikel zich richt op het kwalitatieve formaatfalen, kunt u voor een diepgaande analyse van responstijden terecht op de pagina over het meten van snelheid en latency om te zien hoe u percentielen zoals p95 en p99 correct berekent en verwerkt.

JSON-validiteit is een specifieke vorm van formaatnaleving. Lees de handleiding over het meten van instructie-volgzaamheid met IFEval als u wilt evalueren hoe goed een model algemene tekstuele randvoorwaarden opvolgt in vergelijking met strikte syntactische structuren.

Kosten, token-efficiëntie en integratie in de CI/CD-pijplijn

Het uitvoeren van grootschalige belastingstesten met honderden runs per concurrency-stap brengt tokenkosten met zich mee. Het budgetteren van deze evaluaties is een belangrijk onderdeel van de testplanning.

Het berekenen van het token-budget

De totale kosten van een evaluatierun laten zich vooraf berekenen met de volgende formule:

Totale Tokens = N (runs per niveau) × Aantal Niveaus × (Gemiddelde Invoertokens + Maximaal Verwachte Uitvoertokens)

Als een test bijvoorbeeld 4 concurrency-niveaus kent (1, 4, 8, 16), en per niveau worden 200 runs uitgevoerd met een prompt van 500 invoertokens en een verwachte JSON van 300 uitvoertokens, dan verbruikt één complete testronde 640.000 tokens.

Strategieën voor kostenefficiënt testen

Om de kosten te beheersen zonder in te boeten op statistische betrouwbaarheid, kunnen de volgende technieken worden toegepast:

Aangepaste steekproeven via adaptief testen: Begin bij concurrency 1 met een kleinere steekproef. Pas wanneer er bij een hoger concurrency-niveau fouten optreden, schaal je het aantal runs op dat niveau op om de exacte foutmarge nauwkeurig vast te stellen.
Representatieve verkorte prompts: Gebruik voor routinetesten een compact JSON-schema dat toch alle gewenste datatypen (strings, getallen, geneste arrays) bevat, in plaats van extreem lange documenten.
Mocking van externe API's bij droogtesten: Controleer de werking van de benchmark-harness en de validatiepijplijn eerst met een lokale mock-server voordat er betaalde API-aanroepen worden gestart.

Plaats van de test in de CI/CD-pijplijn

Belastingstesten voor JSON-validiteit horen niet thuis in elke snelle commit-check. Vanwege de tijdsduur en de tokenkosten worden ze idealiter ingezet als:

Nachtelijke regressietesten: Om te controleren of updates aan de inferentie-infrastructuur of het modelaanbod impact hebben gehad op de verwerkingskwaliteit onder druk.
Release-gating voor prompts: Voordat een nieuwe versie van een systeemprompt of een gewijzigd JSON-schema naar productie wordt gepromoot, wordt het gedrag onder gesimuleerde piekbelasting geverifieerd.

Door het gestructureerd meten van JSON-validiteit onder belasting op te nemen in het evaluatieprotocol, voorkomen teams dat onvoorziene formaatfouten de stabiliteit van de uiteindelijke applicatie in gevaar brengen.