Redeneermodellen: wat er verandert als denken een aparte stap wordt

Door Ivo Donker — samengesteld met AI-ondersteuning · Laatst bijgewerkt: 7 augustus 2026

Welkom bij module 5 van het leren-leerpad, getiteld "Onder de motorkap". In dit hoofdstuk behandelen we een fundamentele verschuiving in het ontwerp van kunstmatige intelligentie: het ontstaan van redeneermodellen. Klassieke taalmodellen genereren antwoorden in één enkele doorgang token voor token, waarbij de benodigde rekenkracht direct gekoppeld is aan de lengte van de geleverde uitvoer. Redeneermodellen voegen hier een expliciete, interne denkfase aan toe vóór het definitieve antwoord wordt gegenereerd. Door deze toepassing van zogeheten test-time compute verandert het verwerkingsproces ingrijpend: denken wordt een aparte, meetbare en vaak zichtbare tussenstap. In dit artikel ontleedt u wat er precies onder de motorkap verandert, hoe deze modellen worden getraind, wanneer de inzet van extra rekenkracht kostenefficiënt is en welke gevolgen dit heeft voor software-architecturen.

Wat je hiervoor moet weten

Om de werking van redeneermodellen goed te kunnen plaatsen, is het nuttig om vertrouwd te zijn met een aantal basisconcepten uit eerdere modules van dit leerpad. De volgende artikelen bieden hiervoor de noodzakelijke achtergrond:

• Chain-of-thought als prompttechniek — Lees dit artikel indien u wilt begrijpen hoe gebruikers via prompts handmatig tussenstappen opvragen, terwijl het huidige artikel behandelt hoe modellen deze stap intern automatiseren.
• Inference bij klassieke taalmodellen — Bekijk deze uitleg om de traditionele één-doorgang-generatie te begrijpen, wat dient als vergelijkingsbasis voor redeneermodellen.
• Speculatieve decoding uitgelegd — Raadpleeg deze gids als u wilt ontdekken hoe de verhoogde latentie van langere tokenreeksen met aanvullende technieken kan worden gecompenseerd.

Wat verandert er onder de motorkap?

Van single-pass inferentie naar test-time compute

In klassieke autoregressieve taalmodellen vindt de verwerking van een query plaats via een continue, enkelvoudige doorgang (single-pass inference). Wanneer een prompt wordt ingevoerd, berekent het netwerk voor elk volgend token de waarschijnlijkheidsverdeling over de gehele vocabulaire. Zodra het model een token selecteert, wordt dit token direct toegevoegd aan de uitvoerreeks en dient het als invoer voor de berekening van het volgende token. Dit proces herhaalt zich totdat het model een stop-token genereert. Het rekenbudget dat een klassiek model aan een taak besteedt, staat hierdoor in een lineaire verhouding tot de lengte van de gegenereerde tekst. Een korte vraag die een complex wiskundig antwoord vereist, krijgt in deze traditionele opzet exact evenveel rekenkracht per gegenereerd token als een vraag naar een eenvoudig feit.

Redeneermodellen breken met deze starre koppeling tussen uitvoerlengte en rekenkracht. Ze maken gebruik van het principe van test-time compute (rekenkracht tijdens inferentie). Voordat het model begint aan het definitieve, voor de gebruiker zichtbare antwoord, voert het een reeks interne berekeningen uit. Deze berekeningen nemen de vorm aan van tussenliggende 'denktokens' of 'redeneertokens'. Het model gebruikt deze interne tokens om het probleem te analyseren, mogelijke paden te verkennen, tussenresultaten te valideren en eventuele fouten te corrigeren voordat het definitieve antwoord wordt vastgesteld.

Het verwerken van een verzoek verschuift hiermee van een puur patroonherkenningsproces naar een hybride vorm van patroonherkenning en dynamische zoek- en rekenoperaties. Waar een klassiek model bij complexe vragen vaak struikelt omdat de eerste tokens direct correct moeten zijn om tot het juiste eindresultaat te komen, kan een redeneermodel verkeerde hypotheses binnen zijn denkfase schrappen en een nieuw pad inslaan.

Trainingsmethodiek: Reinforcement Learning op redeneertraces

Het vermogen om gestructureerd en efficiënt na te denken ontstaat niet spontaan. Het vereist een specifieke trainingsaanpak die sterk verschilt van de standaard pre-training en Supervised Fine-Tuning (SFT) die gebruikt worden voor generieke taalmodellen.

Het fundament van redeneermodellen rust op grootschalige Reinforcement Learning (RL) toegepast op redeneertraces. Tijdens de trainingsfase krijgt het model complexe vraagstukken voorgelegd op terreinen zoals wiskunde, formele logica en programmeren. Het model wordt niet alleen beloond voor het produceren van het correcte eindantwoord (Outcome-based Reward Models of ORM), maar via Process-Supervised Reward Models (PRM) ook voor de kwaliteit, correctheid en efficiëntie van de afzonderlijke tussenstappen.

Onder invloed van deze beloningssignalen leert het netwerk autonome redeneerstrategieën aan. Denk hierbij aan:

• Decompositie: Het opbreken van een omvangrijke vraag in kleine, afzonderlijk op te lossen deeldeelvragen.
• Self-Correction: Het herkennen van een inconsistentie of rekenfout in de eigen tussenstappen, waarna het model expliciet terugkeert naar een eerder punt in de redeneerfase.
• Verificatie: Het tussentijds controleren van een tussenresultaat door een tegenberekening of randvoorwaarde-check uit te voeren.
• Backtracking en MCTS-achtige verkenning: Het verkennen van meerdere mogelijke oplossingsrichtingen (vergelijkbaar met Monte Carlo Tree Search) om het meest veelbelovende pad te selecteren.

Een cruciaal inzicht bij deze trainingsmethode is dat de gegenereerde redeneertraces gedurende het trainingsproces veranderen. In het begin genereert het model vaak lange, onsamenhangende teksten om tot een conclusie te komen. Naarmate het RL-proces vordert, ontwikkelt het model een compactere en effectievere interne 'taal' voor logische stappen, waardoor de verhouding tussen de hoeveelheid denktokens en de uiteindelijke precisie van het antwoord wordt geoptimaliseerd.

Inference budget, thinking tokens en test-time scaling

De term test-time scaling laws verwijst naar het empirische gegeven dat de nauwkeurigheid van een model op complexe taken niet alleen schaalt met de omvang van de trainingsdataset en het aantal parameters, maar ook met de hoeveelheid rekenkracht die tijdens de inferentiefase beschikbaar wordt gesteld. Door het model toe te staan meer denktokens te genereren, stijgt het slagingspercentage op uitdagende logische en mathematische tests significant.

In de praktijk wordt deze rekenkracht beheerd via een inference budget. Dit budget bepaalt hoeveel denktokens een model maximaal mag aanmaken voor een individuele query. Denktokens verbruiken ruimte binnen het totale contextvenster van het model. Wanneer een model 4.000 denktokens genereert voordat het aan de uitvoer begint, betekent dit dat er 4.000 tokens minder beschikbaar zijn voor de invoercontext of voor vervolginteracties binnen dezelfde sessie.

De ontwikkelaar of gebruiker heeft hier doorgaans invloed op via instellingen die sturen hoe diep het model graaft naar een oplossing. Bij taken die een lage complexiteit kennen, is een hoog inference budget niet alleen onnodig, maar werkt het vertragend en kostenverhogend. Bij hoogcomplexe taken voorkomt een toereikend budget daarentegen dat het model voortijdig stopt met redeneren en vervalt in foutieve aannames.

Kostenspectrum en latentie: de prijs van diepdenken

Het toevoegen van een expliciete denkfase heeft directe consequenties voor de exploitatiekosten en de gebruikerservaring van AI-applicaties. In vergelijking met klassieke modellen spelen er twee voorname factoren:

1. Token-amplificatie: Voor een vraag die in een klassiek model 50 tokens invoer en 100 tokens uitvoer kost, kan een redeneermodel 50 tokens invoer, 2.000 denktokens en 100 tokens antwoord verbruiken. Aangezien API-providers kosten berekenen per verwerkt token (waarbij denktokens doorgaans tegen de normale uitvoerprijs worden afgerekend), kunnen de operationele kosten per aanvraag met een factor tien tot vijftig stijgen.
2. Verhoogde latentie (Time-To-First-Token en totale doorlooptijd): Doordat het model eerst honderden of duizenden denktokens moet genereren voor het eerste token van het daadwerkelijke antwoord aan de gebruiker wordt getoond, neemt de Time-To-First-Token (TTFT) aanzienlijk toe. Waar een klassiek model binnen enkele honderden milliseconden begint met streamen, kan een redeneermodel enkele seconden tot tientallen seconden 'stil' blijven staan terwijl het de interne redeneertrace afwerkt.

Deze eigenschappen maken redeneermodellen ongeschikt voor real-time toepassingen zoals spraakassistenten of interactieve autocomplete-functionaliteiten in gebruikersinterfaces, tenzij er specifieke maatregelen worden genomen om de wachttijd te overbruggen.

Instellingen: reasoning effort, temperatuur en top-p

Het aansturen van redeneermodellen vereist een andere benadering van hyperparameters dan bij traditionele LLM's.

Bij klassieke modellen zijn de instellingen temperature en top_p de primaire knoppen om de creativiteit of stelligheid van het antwoord te regelen. Een hogere temperatuur zorgt voor meer variatie in de token-selectie. Bij redeneermodellen ligt dit anders. Aangezien de interne denkfase gebaseerd is op strakke logische stappen, kan een te hoge temperatuur tijdens het redeneren leiden tot hallucinaties binnen de tussenstappen, waardoor het gehele redeneerpad ontspoort.

Veel API-providers zetten de temperatuur voor de interne denkfase daarom vast op een lage waarde, of adviseren ontwikkelaars om de temperatuur op de standaardwaarde (vaak 1.0 of 0.0, afhankelijk van het specifieke model) te laten staan. In plaats daarvan introduceren API's een nieuwe parameter: reasoning effort (vaak in te stellen als low, medium, of high). Deze parameter stelt een grens aan het aantal denktokens dat het model mag gebruiken, waardoor ontwikkelaars een directe balans kunnen instellen tussen kosten/latentie en redeneerdiepte.

Evalueer en kies de juiste architectuur

Voor een doordacht ontwerp van uw applicatielandschap is het van belang om redeneermodellen af te wegen tegen generieke modellen en op de hoogte te blijven van de laatste stand der techniek. Raadpleeg de volgende bronnen binnen het llmnet-netwerk voor verdieping:

• Overzicht van redeneermodellen — Gebruik deze vergelijking om te bepalen welke specifieke redeneermodellen momenteel beschikbaar zijn en welke eigenschappen zij bezitten.
• Benchmark van redeneerkwaliteit op GSM8K en MATH — Bestudeer deze benchmarks als u wilt zien hoe de nauwkeurigheid op complexe wiskundige opgaven gestandaardiseerd wordt gemeten.
• Model-routing in API-omgevingen — Raadpleeg deze handleiding wanneer u wilt leren hoe u via logica in uw code aanvragen dynamisch naar redeneermodellen of standaardmodellen stuurt.
• Marktontwikkelingen rond redeneermodellen — Lees dit overzicht om op de hoogte te blijven van de nieuwste commerciële en open-source introducties op het gebied van redeneerarchitecturen.

Wanneer wel en wanneer niet inzetten?

Het is een veelgemaakte denkfout om te veronderstellen dat redeneermodellen superieur zijn voor elk type taak. Omdat test-time compute extra kosten en latentie met zich meebrengt, is een strikte scheiding van taken noodzakelijk.

Geschikte toepassingen (Wel inzetten):

• Meerstaps reken- en wiskundevraagstukken: Opgaven waarin tussentijdse variabelen moeten worden bijgehouden en berekeningen afhankelijk zijn van eerdere resultaten.
• Complexe logische puzzels en planning: Taken met veel randvoorwaarden, zoals het opstellen van een ingewikkeld rooster of het analyseren van afhankelijkheden in software-architecturen.
• Code-generatie en refactoring: Situaties waarin de syntaxis niet alleen correct moet zijn, maar waar ook rekening gehouden moet worden met edge cases, geheugenbeheer en algoritme-efficiëntie.
• Fiscale en juridische regeltoepassing: Het interpreteren van complexe wetgeving op een specifieke casus waarbij meerdere uitzonderingsregels en drempelbedragen gelijktijdig een rol spelen.

Ongeschikte toepassingen (Niet inzetten):

• Eenvoudige feitenprompts: Vragen zoals "Wat is de hoofdstad van Frankrijk?" vereisen geen denkfase. Het model kan dit direct uit zijn parametrisch geheugen ophalen.
• Tekstverwerking en creatief schrijven: Het samenvatten van een korte tekst, het herformuleren van een e-mail of het schrijven van een gedicht profiteert niet van wiskundige logica en wordt door denktokens enkel trager en duurder.
• Klassificatie en entiteitherkenning: Het categoriseren van klantvragen of het opsporen van merknamen in een tekst kan efficiënter worden afgehandeld door lichtere, klassieke taalmodellen.

Concreet Nederlands praktijkvoorbeeld: Btw- en kortingsberekening met uitzonderingen

Om het verschil tussen een klassieke één-doorgang-benadering en een redeneermodel inzichtelijk te maken, bekijken we een casus uit de Nederlandse handelspraktijk. Het betreft een orderberekening met gestapelde regels, staffelkortingen en verschillende btw-tarieven.

De casus

Een groothandel hanteert de volgende regels voor een bestelling:

• Artikel A (elektronica) kost € 150,00 exclusief btw (standaardtarief 21%).
• Artikel B (vakboeken) kost € 40,00 exclusief btw (verlaagd tarief 9%).
• Bij een totale orderwaarde boven € 500,00 exclusief btw krijgt de klant 10% volumekorting over het gehele goederenbedrag vóór btw. Deze korting wordt evenredig naar rato van de goederenwaarde verdeeld over de twee artikeltypen om de juiste btw-grondslag te bepalen.
• De verzendkosten bedragen € 25,00 exclusief btw (belast tegen het hoge tarief van 21%). Verzendkosten tellen niet mee voor het bereiken van de drempel van € 500,00 voor volumekorting.

De vraag aan het model: De klant bestelt 3 stuks van Artikel A en 3 stuks van Artikel B. Wat is het exacte totale factuurbedrag inclusief btw, en hoeveel btw wordt er per tariefstroom (21% en 9%) berekend?

Klassieke aanpak versus redeneeraanpak

Een klassiek taalmodel begint direct met het formuleren van de tekst. Het rekent "al schrijvend" en heeft neiging om kortingspercentages direct toe te passen op het totaalbedrag inclusief verzendkosten, of om het lage en hoge btw-tarief verkeerd te wegen over de gekorte bedragen. Dit komt doordat het model de tussenresultaten niet kan valideren voordat de tekst op het scherm staat.

Een redeneermodel start daarentegen met een afgeschermde of zichtbare denkfase. Hieronder ziet u een getrouwe weergave van wat het model in zijn denktokens berekent voordat het aan het uiteindelijke antwoord begint:

[Denktokens / Redeneertrace]
Stap 1: Bereken de bruto goederenwaarde exclusief btw.
- Artikel A: 3 * € 150,00 = € 450,00.
- Artikel B: 3 * € 40,00 = € 120,00.
- Totale goederenwaarde excl. btw = € 450,00 + € 120,00 = € 570,00.

Stap 2: Controleer de kortingsvoorwaarde.
- Is goederenwaarde excl. btw > € 500,00? Ja (€ 570,00 > € 500,00).
- Volumekorting is 10% over € 570,00 = € 57,00.
- Netto goederenwaarde excl. btw = € 570,00 - € 57,00 = € 513,00.

Stap 3: Verdeel de korting naar rato over Artikel A en Artikel B om btw-grondslagen vast te stellen.
- Aandeel Artikel A in bruto totaal = 450 / 570 = 0.78947368 (78,95%).
- Aandeel Artikel B in bruto totaal = 120 / 570 = 0.21052632 (21,05%).
- Netto grondslag Artikel A (21% btw) = € 450,00 - (0.78947368 * € 57,00) = € 450,00 - € 45,00 = € 405,00.
- Netto grondslag Artikel B (9% btw) = € 120,00 - (0.21052632 * € 57,00) = € 120,00 - € 12,00 = € 108,00.
- Controle: € 405,00 + € 108,00 = € 513,00. Klopt.

Stap 4: Verzendkosten toevoegen.
- Verzendkosten = € 25,00 excl. btw (belast tegen 21%).
- Totale grondslag voor 21% btw = Netto Artikel A + Verzendkosten = € 405,00 + € 25,00 = € 430,00.
- Totale grondslag voor 9% btw = Netto Artikel B = € 108,00.

Stap 5: Btw-bedragen berekenen.
- Btw 21% over € 430,00 = € 430,00 * 0,21 = € 90,30.
- Btw 9% over € 108,00 = € 108,00 * 0,09 = € 9,72.
- Totale btw = € 90,30 + € 9,72 = € 100,02.

Stap 6: Eindbedrag berekenen en verifiëren.
- Totaal excl. btw = € 513,00 (goederen) + € 25,00 (verzending) = € 538,00.
- Totaal incl. btw = € 538,00 + € 100,02 = € 638,02.
- Verificatie via afzonderlijke incl. btw bedragen:
* Artikel A incl. btw: € 405,00 * 1,21 = € 490,05.
* Artikel B incl. btw: € 108,00 * 1,09 = € 117,72.
* Verzending incl. btw: € 25,00 * 1,21 = € 30,25.
* Som = € 490,05 + € 117,72 + € 30,25 = € 638,02. Alles sluit exact aan.
[/Denktokens / Redeneertrace]

Na deze interne verificatie genereert het model de definitieve reactie richting de gebruiker. Doordat alle tussenstappen en randvoorwaarden al in het denkproces zijn gecontroleerd, is het uiteindelijke antwoord vrij van rekenfouten en verkeerde aannames.

Wanneer we dezelfde vraag vereenvoudigen naar: "Hoeveel is 21% btw over € 150,00?", is het inschakelen van een dergelijk redeneerproces overbodig. Een klassiek model levert direct de uitkomst (€ 31,50) zonder extra rekentijd of tokenverbruik. Het nodeloos inzetten van denktokens bij eenvoudige sommen veroorzaakt vertraging zonder dat de nauwkeurigheid toeneemt.

Vergelijkingstabel: Klassieke modellen versus Redeneermodellen

Onderstaande tabel geeft een overzicht van de technische en operationele verschillen tussen klassieke taalmodellen en redeneermodellen.

Architecturale impact op software-integraties

De introductie van redeneermodellen veranderd niet alleen hoe prompts geschreven worden, maar heeft ook gevolgen voor de opbouw van software-applicaties die gebruikmaken van AI-API's.

1. Aanpassing van timeouts en asynchrone patronen

Traditionele HTTP REST-integraties gaan vaak uit van een snelle respons. Bij het aanroepen van een redeneermodel met een hoge reasoning_effort kan de verwerkingstijd oplopen tot meer dan een minuut. Client-bibliotheken en API-gateways die standaard timeouts van 10 of 30 seconden hanteren, zullen hierdoor stuiten op netwerkfouten.

Ontwikkelaars dienen hun architectuur aan te passen door:

• Het instellen van ruimere HTTP-timeouts op API-verbindingen.
• Het overstappen op asynchrone verwerkingspatronen (zoals message queues of WebSockets) waarin de gebruikersinterface de status van het redeneerproces bijhoudt zonder de verbinding te blokkeren.
• Het tonen van specifieke statusindicatoren in de UI ("Model analyseert het probleem...") om te voorkomen dat de gebruiker de applicatie als onresponsief ervaart.

2. Kostenbeheersing via dynamische routering

Omdat denktokens het totale tokenvolume sterk verhogen, is het financieel onrendabel om alle inkomende verzoeken standaard naar een redeneermodel te sturen. Een effectieve architectuur maakt gebruik van een routeringslaag (model router).

Deze routeringslaag beoordeelt de inkomende vraag op basis van een lichtgewicht classificatiemodel of heuristische regels. Eenvoudige vragen (zoals het herschrijven van een zin of het opzoeken van een feit) worden doorgestuurd naar een standaard, goedkoop taalmodel. Alleen wanneer de vraag kenmerken vertoont van complexe wiskunde, meerstaps logica of uitgebreide code-analyse, wordt de aanvraag doorgestuurd naar het redeneermodel.

3. Zichtbaarheid en afhandeling van denktokens

API's van redeneermodellen bieden vaak de mogelijkheid om de gegenereerde denktokens mee te sturen in de respons (sommige aanbieders verbergen deze om intellectueel eigendom te beschermen of tonen slechts een geanonimiseerde samenvatting). Wanneer denktokens wel beschikbaar zijn, moeten ontwikkelaars beslissen hoe hiermee wordt omgegaan:

• Opslag: Het opslaan van denktokens in de database kan waardevol zijn voor auditability (bijvoorbeeld om te verifiëren hoe een fiscaal advies tot stand is gekomen).
• Sessiecontext: Denktokens moeten zorgvuldig worden gefilterd voordat ze weer als historische context worden meegestuurd in vervolgvragen, om te voorkomen dat het contextvenster onnodig snel volloopt.

Conclusie

Redeneermodellen markeren een belangrijke evolutie in de opbouw van taalmodellen. Door denken te transformeren tot een expliciete, meetbare tussenstap op basis van test-time compute, worden de beperkingen van traditionele single-pass modellen bij complexe, meerstaps vraagstukken grotendeels weggenomen. Deze winst in nauwkeurigheid gaat echter gepaard met een hoger tokenverbruik en een langere latentie. Een succesvolle toepassing vereist dan ook een doordachte afweging van taken, aangepaste software-architecturen en een effectieve kostenbeheersing.

Hierna verder met

Vervolg uw leertraject over AI-architecturen en redeneermodellen via de volgende verdiepende artikelen:

• Bekijk het overzicht van redeneermodellen — Vergelijk de actuele prestaties en specificaties van diverse redeneermodellen om een geschikte keuze voor uw toepassingen te maken.
• Implementeer dynamische model-routing — Leer hoe u kostenefficiëntie optimaliseert door eenvoudige vragen naar klassieke modellen en complexe taken naar redeneermodellen te leiden.