Betrouwbare JSON uit AI: dwing het formaat af

Je denkt waarschijnlijk dat je betrouwbare JSON uit een AI krijgt door het netjes te vragen: zet in je prompt "antwoord alleen met geldige JSON, geen uitleg" en klaar. Dat werkt niet. De ene keer krijg je keurige JSON, de andere keer "Zeker! Hier is de data:" met een codeblok eromheen, of een datum die het model als "3 mei" schreef in plaats van "2026-05-03". Je parser klapt eruit, en je weet nooit vooraf wélke keer.

Neem een concreet geval. Je wilt uit binnenkomende e-mails drie velden halen, de naam van de afzender, een bedrag en een datum, en die automatisch in je systeem zetten. Vraag je het model gewoon in je prompt om JSON, dan gok je bij elke e-mail opnieuw of het formaat klopt. Bij een rommelige mail plakt het model er net zo makkelijk een beleefde inleiding voor, of het levert de datum in een vorm die je code niet verwacht. Kijk wat er gebeurt als je twee routes naast elkaar legt.

In de bovenste route hangt alles af van de goede wil van het model: soms geldige JSON, soms proza of markdown eromheen, soms iets wat je parser niet leest. In de onderste route geef je een schema mee (naam als tekst, bedrag als getal, datum als tekst) en wordt de vorm afgedwongen. Dat tweede heet gestructureerde uitvoer.

Gestructureerde uitvoer (structured output) is een functie van de AI-aanbieder die een taalmodel dwingt zijn antwoord in een vast, machine-leesbaar formaat te geven, meestal JSON volgens een schema dat jij meegeeft. Het werkt via constrained decoding: bij elke token-stap worden alle tokens die het schema zouden breken gemaskeerd voordat het model er een trekt, zodat de uitvoer gegarandeerd geldige JSON volgens jouw schema is.

Om te snappen waaróm dat een garantie is en geen hoop, moet je terug naar hoe een model tekst maakt. Een taalmodel bouwt bij elk token een kansverdeling en trekt daar een token uit. Gestructureerde uitvoer grijpt precies op dat trek-moment in.

De kern in gewone woorden: het model werkt token voor token, en gestructureerde uitvoer zet vlak voor elke trekking de kans op nul voor elke token die je schema zou breken. Wat overblijft om uit te trekken is per definitie geldig, dus er kán geen kapotte JSON uitkomen. De prijs zit in de randen. De eerste aanroep met een nieuw schema is trager omdat de grammatica eerst gecompileerd wordt (Anthropic cachet die 24 uur), de garantie sneuvelt als het model weigert of de max-tokens-limiet raakt, en waarde-grenzen zoals een minimum of een maximale lengte worden niet bewaakt.

Beide grote aanbieders bieden dit inmiddels als native functie. Bij OpenAI heet het Structured Outputs, en alleen de strikte variant garandeert dat het antwoord je schema volgt; het oudere json-mode levert wel geldige JSON maar niet per se jouw velden. Anthropic biedt het inmiddels breed aan en garandeert schema-conforme antwoorden via constrained decoding, met een json_schema-uitvoerformaat plus strikte tool-invoer. De exacte parameternamen verschillen en veranderen; het idee is bij beide hetzelfde. Vraag je alleen om "geldige JSON" zonder schema, dan zit je in de lossere json-mode: wel parseerbaar, maar zonder garantie dat het jouw velden zijn.

Waarom je code nog steeds een verkeerd bedrag kan binnenkrijgen

Hier zit de valkuil, en het is de belangrijkste zin van deze les: gestructureerde uitvoer garandeert de vorm, niet de inhoud. Het schema dwingt af dat "bedrag" een getal is en dat het veld bestaat. Het dwingt niet af dat het het júiste bedrag is. Het model kan nog steeds een verzonnen of verkeerd bedrag in een verder geldig veld zetten, en omdat de vorm klopt, glijdt dat zo je database in. Je hebt betrouwbare structuur, geen betrouwbare waarheid. Dat laatste borg je met validatie (klopt het bedrag met de bron?) en door achteraf te meten of het echt klopt.

Dezelfde machinerie zit onder een heel andere functie die je misschien al kent. Als een model de argumenten van een tool-aanroep invult, vult het net zo goed een schema in, met dezelfde constrained decoding eronder. Gestructureerde uitvoer en de argumenten van function calling zijn twee gezichten van hetzelfde idee: het model een vast formulier laten invullen in plaats van vrije tekst laten schrijven. Gebruik het overal waar de uitvoer een machine in gaat, een database, een API, of een volgende stap in een agent. Laat het model waar nuttig eerst kort redeneren en pas daarna het schema invullen, dan combineer je een goede afweging met een vaste vorm.

Dat is de brug van een taalmodel dat mooie tekst maakt naar een onderdeel waar je software op durft te leunen. Niet omdat je het netjes vroeg, maar omdat je het formaat hebt afgedwongen, en de inhoud daarna zelf hebt gecontroleerd.