# JSON Schema Output Validator & Benchmark Tool

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

Het structureel afdwingen van gestructureerde uitvoer bij taalmodellen vraagt om nauwkeurige validatie. Wanneer je grote volumes aan modeloutputs genereert, wil je direct kunnen toetsen of de gegenereerde data voldoet aan een vooraf opgesteld contract. Deze client-side tool biedt een direct inzicht in de syntactische parseerbaarheid en de structurele geldigheid van modeloutputs op basis van een zelfgedefinieerd JSON-schema.

Volledig client-side: Alle validaties en berekeningen vinden uitsluitend plaats in jouw eigen browser. Er wordt geen data naar externe servers verzonden, er worden geen cookies geplaatst en er is geen sprake van externe API-aanroepen.

JSON Schema (ondersteunt type, required, properties, items, enum, minLength/maxLength):

{
 "type": "object",
 "required": ["id", "status", "scores"],
 "properties": {
 "id": { "type": "string", "minLength": 3 },
 "status": { "type": "string", "enum": ["actief", "inactief", "in_behandeling"] },
 "scores": {
 "type": "array",
 "items": { "type": "number" }
 }
 }
}

Modeloutputs (een per regel of gescheiden door lege regels):

{
 "id": "abc_123",
 "status": "actief",
 "scores": [10, 20, 30]
}
{
 "id": "xy",
 "status": "onbekend",
 "scores": [5, "tien"]
}
ongeldige json string zonder accolades

Valideer outputs

## Wat deze tool berekent en waarom dit ertoe doet

In de praktijk van grootschalige AI-evaluaties lopen onderzoekers en ontwikkelaars tegen een fundamenteel probleem aan: taalmodellen produceren soms tekst die zich op het oog voordoet als gestructureerde data, maar die bij nadere inspectie niet voldoet aan de syntax of de semantische randvoorwaarden van een applicatie. Deze tool is ontworpen om dat proces meetbaar te maken zonder dat je ingewikkelde scripts hoeft te schrijven of externe dependencies hoeft te installeren.

De werking is opgebouwd rondom twee kernelementen: een flexibel te definiëren JSON-schema en een reeks modeloutputs. Je kunt de tool gebruiken voor zowel enkelvoudige controle als voor een volledige benchmark-modus waarin je tientallen of honderden regels tegelijk importeert. De tool berekent automatisch de verhouding tussen geldige en ongeldige resultaten, verdeelt fouten over logische categorieën en presenteert het totaalplaatje in een helder dashboard.

Het meten van deze percentages vormt een essentieel onderdeel van een robuuste teststrategie. Als een model in negentig procent van de gevallen correct formatteert, maar in tien procent ongeldige velden oplevert, weet je direct of je prompt-aanpassingen nodig hebt of dat je middleware moet inzetten om de uitvoer te corrigeren. Wie dieper wil duiken in hoe je dit soort formaten op systeemniveau kunt afdwingen, kan terecht bij de handleiding over [output formaten afdwingen](https://community.llmnet.nl/output-formaten-afdwingen), waar praktische handvatten voor developers worden behandeld.

## Het verschil tussen parseerbaarheid en data-kwaliteit

Een cruciaal inzicht bij het evalueren van modeluitvoer is het onderscheid tussen puur syntactische geldigheid (kunnen we de tekst parsen als JSON?) en structurele geldigheid (voldoet de JSON aan de regels van het schema?). Veel eenvoudige scripts controleren enkel of JSON.parse() geen foutmelding oplevert. Dat schiet echter te kort.

Een model kan immers perfect geldige accolades en komma's genereren, maar vervolgens vergeten om een verplicht veld mee te nemen, of een tekstreeks invullen op een plek waar het schema een getal verwacht. Omgekeerd kan een model een tekst genereren die door kleine syntaxfouten — zoals een ontbrekend aanhalingsteken of een trailing comma — volledig onleesbaar is voor de parser, terwijl de inhoudelijke kwaliteit van de gegenereerde data op zich prima had kunnen zijn.

Deze tool splitst die aspecten op in duidelijke categorieën:

 
- Syntaxis-fouten: De output is geen legitieme JSON-structuur en faalt al bij de eerste parseer-stap.
 
- Type-fouten: De structuur is parseerbaar, maar een veld heeft een verkeerd gegevenstype (bijvoorbeeld een string waar een getal vereist is).
 
- Ontbrekende velden: Een verplicht veld uit het schema ontbreekt volledig in de objecten.
 
- Waardebereik-fouten: Veldwaarden voldoen niet aan beperkingen zoals een enum-lijst of een minimale lengte (minLength/maxLength).

Door deze fouten categorie voor categorie te tellen, krijg je een veel scherper beeld van de specifieke zwaktes van een taalmodel dan wanneer je alleen een binair goed/fout-oordeel velt. Wie meer wil lezen over bredere evaluatiemethodes voor instructies, kan ook de documentatie over [IFEval instructie volgzaamheid meten](https://benchmark.llmnet.nl/ifeval-instructie-volgzaamheid-meten) raadplegen.

## Beperkingen en de rol van aannames in benchmarks

Geen enkele benchmarktool is feilloos, en het is belangrijk om te begrijpen waar de grenzen van dit systeem liggen. Ten eerste valideert deze tool uitsluitend de structurele geldigheid op basis van de subset aan JSON Schema-regels die lokaal is geïmplementeerd. Complexe logische verbanden tussen verschillende velden (conditional required fields) of geavanceerde reguliere expressies vallen buiten deze scope.

Ten tweede zegt een succesvolle schema-validatie absoluut niets over de feitelijke juistheid of de inhoudelijke kwaliteit van de gegenereerde data. Een model kan een keurig gestructureerd JSON-object opleveren dat voldoet aan alle regels, maar waarin feitelijke onjuistheden, hallucinaties of tegenstrijdige gegevens staan. Schema-validatie garandeert uitsluitend de technische bruikbaarheid voor je downstream software, niet de waarheidsgetrouwheid van de inhoud.

Wanneer je eigen getallen of resultaten invoert die afkomstig zijn van specifieke modelanbieders of externe experimenten, werk je per definitie met aannames. De uitkomsten die de tool toont, zijn daarom altijd een momentopname op basis van de door jou ingevoerde dataset en het geselecteerde schema. Presenteer dergelijke uitkomsten in je eigen publicaties of rapportages nooit als universele feiten, maar nadrukkelijk als schattingen en resultaten van een specifieke testrun.

Voor het testen van andere specifieke eigenschappen van taalmodellen binnen het netwerk kun je gebruikmaken van complementaire hulpmiddelen. Zo is de [tool needle haystack generator](https://benchmark.llmnet.nl/tool-needle-haystack-generator) beschikbaar voor het testen van informatiereterentie in lange contexten, en kun je via de [prompt a/b test tool](https://benchmark.llmnet.nl/prompt-ab-test-tool) varianten van prompts systematisch tegen elkaar afwegen.

## Lees ook

 
- [Tool needle haystack generator](https://benchmark.llmnet.nl/tool-needle-haystack-generator): Genereer testomgevingen om te controleren hoe goed taalmodellen specifieke feiten terugvinden in enorme lappen tekst.
 
- [Prompt a/b test tool](https://benchmark.llmnet.nl/prompt-ab-test-tool): Vergelijk de prestaties van verschillende prompt-varianten direct naast elkaar om kwalitatieve verbeteringen meetbaar te maken.
 
- [IFEval instructie volgzaamheid meten](https://benchmark.llmnet.nl/ifeval-instructie-volgzaamheid-meten): Ontdek de methodologie achter het evalueren van complexe instructies en constraints bij moderne taalmodellen.
 
- [Structured output](https://api.llmnet.nl/structured-output): Lees technische achtergronden over hoe API's van grote taalmodellen native omgaan met het afdwingen van vaste schema's.
 
- [Output formaten afdwingen](https://community.llmnet.nl/output-formaten-afdwingen): Praktische ervaringen en discussies uit de community over het betrouwbaar parsen van modelresultaten in productie.

llmnet.nl - benchmarks en evaluatie van taalmodellen