Redeneerstappen beoordelen bij reken- en logicataken

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

Bij het testen van grote taalmodellen vormen reken- en logicataken traditioneel de lakmoesproef voor analytisch vermogen. Verzamelingen zoals GSM8K (Grade School Math) en MATH worden breed gebruikt om te meten in hoeverre een model meerstapsvraagstukken correct opboort en oplost. In de praktijk blijkt een binaire beoordeling — waarbij alleen de einduitkomst als goed of fout wordt gemarkeerd — echter een veel te grof instrument. Deze benadering laat niet zien waarom een model faalt of juist slaagt, wat leidt tot een vertekend beeld van de werkelijke redeneerkwaliteit.

Om betrouwbare uitspraken te doen over de geschiktheid van een model voor complexe bedrijfsprocessen, financieel rekenwerk of logische planningsvraagstukken, is evaluatie van het gehele redeneerpad noodzakelijk. In dit artikel behandelen we de methodologische valkuilen van enkelvoudige antwoordevaluatie, de noodzaak van gestandaardiseerde normalisatie, een gedetailleerde foutentaxonomie, de rol van meervoudige pogingen en hoe je tussenstappen geautomatiseerd maar geijkt kunt beoordelen.

Het kernprobleem van eindantwoord-evaluatie

Het evalueren van reken- en redeneertaken op basis van uitsluitend het eindresultaat introduceert twee grote ruisbronnen in een testopstelling: fout-positieve en fout-negatieve beoordelingen.

Een fout-positieve uitkomst doet zich voor wanneer een model via een foutieve redenering toch op het juiste eindgetal uitkomt. Denk aan een situatie waarin een rekenfout in de tweede tussenstap toevallig wordt gecompenseerd door een tweede rekenfout of een verkeerd toegepaste formule in de vierde tussenstap. Ook komt het voor dat een model een getal uit de vraagstelling simpelweg herhaalt of gokt en daarmee toevallig de verwachte waarde raakt. Wie alleen naar de uitkomst kijkt, beloont in deze gevallen een defect redeneerproces.

Omgekeerd leidt een fout-negatieve uitkomst tot een onderschatting van de capaciteiten van het model. Wanneer een model gedurende zeven stappen een vlekkeloze logische afleiding en correcte formules formuleert, maar in de allerlaatste stap een tikfout maakt of een afrondingsverschil vertoont, krijgt de gehele respons een score van nul. In productieomgevingen kan de eerste zeven stappen aan logica echter uiterst waardevol zijn, terwijl de rekenkundige fout met een simpele reken-tool of validatiestap opgevangen had kunnen worden.

Antwoordnauwkeurigheid versus stapnauwkeurigheid

Om redeneerkwaliteit inzichtelijk te maken, hanteren we twee afzonderlijke metrieken: antwoordnauwkeurigheid (outcome accuracy) en stapnauwkeurigheid (process accuracy). Beide metrieken leveren sturingsinformatie voor een ander type beslissing.

Antwoordnauwkeurigheid

Antwoordnauwkeurigheid meet het percentage opgaven waarbij de uiteindelijke uitkomst na eventuele normalisatie exact overeenkomt met de referentiewaarde. Deze metriek is nuttig als eerste snelle triage van modellen en geeft aan in hoeverre een systeem zonder menselijke tussenkomst direct correcte waarden produceert. Het zegt echter weinig over de robuustheid van het model wanneer de inputwaarden licht veranderen.

Stapnauwkeurigheid

Stapnauwkeurigheid meet de logische en rekenkundige correctheid van elke individuele tussenstap in de redeneerketen. Hierbij wordt vastgesteld of stap n logisch en mathematisch volgt uit de gegevens en de voorafgaande stappen 1 tot en met n-1. Het gebruik van chain-of-thought technieken maakt deze tussenstappen expliciet zichtbaar, waardoor stapnauwkeurigheid meetbaar wordt.

Wanneer een model een hoge antwoordnauwkeurigheid heeft maar een lage stapnauwkeurigheid, is het systeem kwetsbaar voor onverwachte uitval bij kleine variaties in de vraagstelling. Een hoge stapnauwkeurigheid gecombineerd met incidentele rekenfouten wijst daarentegen op een sterk redeneerfundament dat simpelweg ondersteuning nodig heeft van een reken-plugin of Python-interpreter.

Antwoorden vergelijkbaar maken: de noodzaak van normalisatie

Een veelvoorkomende bron van ruis bij het evalueren van antwoordnauwkeurigheid is het ontbreken van een strikte normalisatieworkflow. Een taalmodel genereert vrije tekst. Indien de referentiewaarde 42 is, kan het model antwoorden met 42, 42.0, € 42,-, 42 km/h of Totaal: 42. Zonder voorafgaande opschoning meet de evaluatietool opmaakvoorkeuren in plaats van wiskundige kunde.

Een robuuste normalisatiepijplijn kent vier opeenvolgende fasen:

1. Isolatie van de kernwaarde: Het toepassen van reguliere expressies of parsing-instructies om de finale waarde uit een antwoordblok te filteren (bijvoorbeeld uit de bekende \boxed{...} notatie in MATH-benchmarks).
2. Eenheden en valuta strippen: Het verwijderen van tekstuele toevoegingen zoals valutasymbolen, procenttekens of maateenheden, mits de opgave niet expliciet om een specifieke eenheidsconversie vraagt.
3. Getalsnotaties harmoniseren: Het omzetten van breuken (zoals 1/2) naar standaard decimalen (0.5), het vervangen van komma's door punten bij decimale scheidingen, en het verwijderen van duizendtal-scheidingstekens.
4. Tolerantie en afronding instellen: Het toepassen van een relatieve of absolute foutmarge (epsilon) bij zweevende-kommagetallen. Een antwoord als 3.1415 moet bij een gevraagde nauwkeurigheid van twee decimalen niet als fout worden gerekend ten opzichte van 3.14.

Pas wanneer twee antwoorden door deze pijplijn zijn gehaald, kan een eerlijke vergelijking worden uitgevoerd. Zonder deze stap worden modellen die inhoudelijk correct redeneren onterecht afgestraft op hun syntactische stijl.

Foutsoorten die je wilt onderscheiden

Wanneer een tussenstap of eindantwoord onjuist is, levert een eenvoudige kwalificatie "fout" onvoldoende sturingsinformatie op. Om gerichte verbeteringen aan te brengen in prompts, fine-tuningdatasets of systeemarchitectuur, is het noodzakelijk om fouten te categoriseren in vier hoofdcategorieën.

1. Begripsfout (verkeerd begrepen opgave)

Het model interpreteert de uitgangssituatie of de voorwaarden van het probleem verkeerd. Het negeert bijvoorbeeld een expliciet genoemde beperking of verwisselt variabelen in de probleembeschrijving. De redenering die volgt kan intern logisch zijn, maar is gebaseerd op het verkeerde vertrekpunt. De oplossing hiervoor ligt meestal in betere instructies of meer heldere contextualisering in de prompt.

2. Rekenfout in een verder correcte aanpak

Het model kiest de juiste logische route en stelt de correcte vergelijkingen op, maar maakt een rekenkundige fout bij de uitvoering (bijvoorbeeld een optelfout of een fout bij het vermenigvuldigen van twee getallen). Dit is een bekend fenomeen bij pure taalmodellen. De oplossing voor dit type fout is het inschakelen van externe hulpmiddelen, zoals een Python-omgeving of een rekenmodule via tool calling.

3. Strategische ontsporing

Het model begint correct en voert de eerste stappen juist uit, maar neemt halverwege een foutieve afslag. Het past bijvoorbeeld een wiskundige regel toe die in deze specifieke context niet geldig is, of vergeet een tussenresultaat mee te nemen naar de volgende stap. Dit duidt op een gebrek aan diepgaand logisch inzicht en kan worden aangepakt door gericht trainingsmateriaal of meerstapscontroles.

4. Ongefundeerde conclusie (hallucinatie van de finale stap)

De tussenstappen en de logische opbouw zijn aanwezig, maar het uiteindelijke antwoord volgt op geen enkele wijze uit de voorafgaande redenering. Het model "springt" naar een willekeurige waarde. Dit wijst op een verstoring in het generatieproces en kan vaak worden gereduceerd door de temperatuurinstelling te verlagen of te dwingen tot gestructureerde uitvoerformaatvoorschriften.

Contaminatie omzeilen met eigen varianten

Publieke verzamelingen zoals GSM8K en MATH zijn reeds jaren beschikbaar en zijn op grote schaal opgenomen in de trainingsdata van moderne taalmodellen. Dit leidt tot data-contaminatie: het model genereert het antwoord niet op basis van redeneervermogen, maar op basis van patroonherkenning of het herinneren van de exacte tekst uit de trainingsreeks.

Voor een diepgaande analyse van de algemene mechanismen achter dit probleem verwijzen we naar onze analyse over het fenomeen benchmark-contaminatie. Specifiek voor reken- en logicataken kan contaminatie het beste worden omzeild door het construeren van eigen varianten op basis van bestaande opgaven. Drie methoden zijn hiervoor uitermate effectief:

• Getallen wisselen en schaal aanpassen: Vervang alle numerieke waarden in een vraagstuk door ongebruikelijke getallen, decimalen of grotere waarden. Een model dat de oplossing heeft gememoriseerd, faalt zodra de rekenkundige uitkomst niet meer overeenkomt met de getrainde tekst.
• Context en entiteiten herschrijven: Pas de narratieve omhulling van het vraagstuk aan. Verander een opgave over het verdelen van appels in een kist naar een logistiek vraagstuk over containers op een schip, terwijl de onderliggende vergelijkingen identiek blijven.
• Een extra redeneerstap toevoegen: Breid een bestaand vraagstuk uit met een aanvullende voorwaarde. Voeg bijvoorbeeld een belastingpercentage, een kortingsstaffel of een tijdsbeperking toe aan een bestaande rekenopgave. Dit dwingt het model om actieve logica toe te passen bovenop het basisschema.

Meerdere pogingen en variantie in redeneergedrag

Taalmodellen genereren tekst op basis van probabilistische bemonstering. Wanneer de temperatuurinstelling hoger is dan nul, levert eenzelfde vraagstuk bij meerdere uitvoeringen verschillende uitkomsten en redeneerpaden op. Het beoordelen van een model op basis van slechts één enkele poging per opgave levert daardoor een onbetrouwbaar beeld op.

Om de betrouwbaarheid van een redeneermodel vast te stellen, maken we gebruik van meervoudige steekproeven per vraagstuk. Hierbij zijn twee evaluatiemetrieken leidend:

Pass@k

De pass@k metriek geeft het percentage opgaven aan waarbij het model in ten minste één van de k gegenereerde pogingen het correcte antwoord vindt. Deze maatstaf is waardevol wanneer het systeem wordt ingezet in een omgeving waar meerdere antwoorden parallel gegenereerd mogen worden en een externe verificateur de beste optie selecteert.

Spreiding en stabiliteit

Door de uitkomsten van 10 of 20 pogingen per opgave te vergelijken, wordt de interne variabiliteit van het model zichtbaar. Als een model bij 9 van de 10 pogingen op exact dezelfde wijze redeneert en tot hetzelfde antwoord komt, is het redeneerpad stabiel. Als het model bij 10 pogingen 5 verschillende eindantwoorden produceert via 5 inhoudelijk afwijkende redeneringen, is het systeem onbetrouwbaar — zelfs als toevallig 2 van die pogingen het juiste antwoord bevatten.

Deze benadering sluit nauw aan bij geavanceerde prompting-methoden, zoals self-consistency prompting bij redeneringsstappen, waarbij de meest frequente redeneerlijn als definitief antwoord wordt gekozen. Voor de statistische onderbouwing van de benodigde steekproefgrootte bij dit type metingen raadpleeg je onze gids over statistiek voor evaluaties.

Beoordeling van tussenstappen via een evaluatiemodel

Het handmatig beoordelen van honderden redeneerstappen per opgave is voor grote benchmarks praktisch onhaalbaar. Een pragmatische methode is het inzetten van een krachtig taalmodel als geautomatiseerde beoordelaar (LLM-as-a-Judge) om de tussenstappen te controleren.

Bij geautomatiseerde stapbeoordeling krijgt het beoordelaarmodel per stap de volgende informatie aangeboden:

1. De oorspronkelijke opgave en de gestelde randvoorwaarden.
2. De tot dan toe als correct gecertificeerde stappen 1 tot en met i-1.
3. De te beoordelen stap i.

Het beoordelaarmodel krijgt de specifieke taak om vast te stellen of stap i logisch en rekenkundig volgt uit de voorafgaande context. Is dat niet het geval, dan moet de beoordelaar aangeven welk type fout er gemaakt is.

Het ijken van de geautomatiseerde beoordelaar gebeurt door een representatieve steekproef van redeneerstappen (bijvoorbeeld 200 stappen) handmatig door menselijke experts te laten beoordelen. Vervolgens vergelijk je de oordelen van de automatische beoordelaar met de menselijke annotaties. Pas wanneer de precisie en recall van de automatische beoordelaar op deze controle-set voldoende hoog zijn, kan het evaluatieproces op grote schaal worden geautomatiseerd.

Wat dit betekent voor je eigen toepassing

De belangrijkste les voor organisaties en ontwikkelaars is dat openbare scoreborden (leaderboards) op basis van GSM8K of MATH hooguit een eerste indicatie geven van algemene capaciteiten. Ze voorspellen niet hoe een model presteert op de specifieke logica, rekenregels en randvoorwaarden van jouw eigen domein.

Voor een vergelijking van de fundamentele redeneerarchitecturen van moderne modellen kun je terecht bij onze vergelijkingen tussen redeneermodellen. Om de prestaties voor jouw eigen organisatie concreet te maken, is het raadzaam om niet te leunen op publieke benchmarks, maar zelf een interne evaluatieset op te bouwen.

Een effectieve aanpak voor een eigen evaluatieset omvat de volgende stappen:

• Stel een verzameling op van 50 tot 100 realistisch geformuleerde praktijkproblemen uit jouw domein.
• Annoteer per opgave niet alleen het verwachte eindantwoord, maar ook de verplichte tussenstappen of logische mijlpalen.
• Richt een normalisatiescript in dat de uitvoer van het model opschoont en vergelijkbaar maakt.
• Voer meerdere pogingen uit per opgave om de stabiliteit van de uitkomsten en redeneerpaden te meten.
• Categoriseer optredende fouten volgens een vaste foutentaxonomie om te bepalen of de oplossing ligt in betere prompting, tool-integratie of modelselectie.

Voor een gedetailleerd stappenplan over de opzet van een dergelijke testomgeving bekijk je ons stappenplan voor een eigen benchmark opzetten.

Lees ook

• Chain-of-thought technieken en meerstaps redeneren
• Benchmark-contaminatie uitgelegd: oorzaken en oplossingen
• Self-consistency prompting bij redeneringsstappen
• Statistiek voor evaluaties: steekproeven en betrouwbaarheid
• Redeneermodellen vergeleken: architectuur en prestaties
• Stappenplan voor het opzetten van een eigen benchmark