# Self-consistency prompting voor betere redeneerstappen
Door Ivo Donker — samengesteld met AI-ondersteuning (Claude & Gemini) · Laatst bijgewerkt: 6 augustus 2026
Grote taalmodellen (LLMs) presteren uitstekend bij taken die vragen om creatieve teksten, samenvattingen en eenvoudige informatie-extractie. Zodra we deze systemen echter inzetten voor complexe logische, wiskundige of programmatische vraagstukken, lopen we tegen de fundamentele grenzen van autoregressieve tokenvoorspelling aan. Een model genereert tekst woord voor woord, waarbij elk volgend token statistisch afhankelijk is van alle voorgaande tokens.
Wanneer een model een complex probleem in een enkele doorgang probeert op te lossen, is de kans groot dat er halverwege de redenering een kleine fout insluipt. Omdat het model gedwongen is om door te bouwen op zijn eigen eerdere output, sleept deze initiële fout de rest van de berekening mee. Dit fenomeen staat bekend als foutaccumulatie of fouten-cascadering. Om dit probleem op te lossen, is de techniek van self-consistency prompting ontwikkeld. Dit artikel behandelt de werking, implementatie, kosten en valkuilen van deze geavanceerde prompt-engineering-methode.
## Het probleem van het enkele redeneerspoor
Bij het gebruik van basale prompt-technieken vraagt een gebruiker om een direct antwoord. Om de redeneerkapaciteit te vergroten, wordt vaak gebruikgemaakt van de bekende [chain-of-thought](https://leren.llmnet.nl/chain-of-thought) methodiek. Hierbij wordt het model gestimuleerd om stapsgewijs naar het eindantwoord toe te werken. Hoewel dit de prestaties aanzienlijk verbetert, blijft het onderliggende probleem bestaan: het gegenereerde antwoord is gebaseerd op één enkel pad door de waarschijnlijkheidsverdeling van de modeluitvoer.
Zie het genereren van een antwoord door een LLM als een wandeling door een beslissingsboom. Bij elk token kiest het model een vertakking. Als er bij stap 3 van een 12-staps redenering een verkeerd getal of een onjuiste aanname wordt gekozen, bevindt het model zich op een foutief pad. Zelfs als alle daaropvolgende redeneerstappen logisch volstrekt coherent zijn binnen de context van die fout, zal het uiteindelijke antwoord incorrect zijn. Een enkel redeneerspoor is in feite een willekeurige steekproef uit een complexe kansverdeling. Vertrouwen op één steekproef voor kritieke beslissingen brengt grote risico's met zich mee.
## Het basisidee van self-consistency
Self-consistency lost dit probleem op door niet één, maar meerdere onafhankelijke redeneersporen parallel te genereren. In plaats van te zoeken naar het meest waarschijnlijke pad (zoals greedy decoding doet), verkent deze techniek de breedte van de oplossingsruimte. Dit proces verloopt in drie opeenvolgende fasen:
- Genereren van diverse sporen: We sturen dezelfde prompt meerdere keren naar het model. Hierbij maken we gebruik van een specifieke configuratie van de [sampling parameters](https://leren.llmnet.nl/sampling-parameters), waarbij de temperatuur boven nul wordt gezet (meestal tussen 0.5 en 0.7). Dit zorgt ervoor dat het model bij elke run een uniek redeneerpad kiest.
- Extractie van de eindantwoorden: Uit elk gegenereerd redeneerspoor filteren we het uiteindelijke, concrete antwoord. De complexe tussenstappen laten we hierbij buiten beschouwing.
- Marginalisatie via stemming (voting): We tellen hoe vaak elk uniek eindantwoord voorkomt. Het antwoord dat de meeste stemmen krijgt (de modus van de verdeling), selecteren we als het definitieve antwoord.
Belangrijk onderscheid: We stemmen expliciet over het eindantwoord, en niet over de stappen die tot dat antwoord hebben geleid. Twee totaal verschillende redeneersporen kunnen immers op hetzelfde correcte antwoord uitkomen. Door te stemmen op het eindresultaat, marginaliseren we de verschillende manieren waarop het model tot dat resultaat is gekomen.
## Verschil met gerelateerde technieken
Om de waarde van self-consistency te begrijpen, moeten we het afzetten tegen andere benaderingen. Sommige ontwikkelaars denken dat het simpelweg herhalen van dezelfde prompt met een temperatuur van 0 vergelijkbaar is. Dit is niet het geval: bij een temperatuur van 0 zal het model telkens exact hetzelfde redeneerspoor en dus exact hetzelfde antwoord opleveren. Er is geen variatie en dus geen mogelijkheid tot stemming.
Ook verschilt het wezenlijk van methoden zoals [prompt chaining](https://community.llmnet.nl/prompt-chaining). Waar chaining zich richt op het opknippen van een taak in opeenvolgende deeltaken om de context overzichtelijk te houden, richt self-consistency zich op het parallel uitvoeren van dezelfde taak om de betrouwbaarheid van een specifieke redeneerstap te verifiëren. In de onderstaande tabel worden de eigenschappen van deze methoden vergeleken:
Techniek |
Decoderingstype |
Aantal runs |
Evaluatie-eenheid |
Doelstelling |
Standaard CoT |
Greedy (Temp = 0) |
1 |
Geen (directe uitvoer) |
Logische stappen tonen |
Herhaalde prompt (Temp 0) |
Greedy (Temp = 0) |
N |
Geen (identieke runs) |
Redundantie testen |
Self-Consistency |
Stochastisch (Temp > 0) |
N |
Eindantwoord (modus) |
Fouttolerantie verhogen |
## Het cruciale proces van antwoordnormalisatie
Een van de grootste praktische uitdagingen bij het implementeren van self-consistency is de normalisatiefase. Wanneer we het model de vrijheid geven om in natuurlijke taal te redeneren, zullen de eindantwoorden er vaak net iets anders uitzien. Zonder grondige opschoning mislukt het stemproces volledig.
Stel dat we een wiskundig probleem voorleggen waarbij de uitkomst 10 meter is. De verschillende redeneersporen kunnen eindigen met de volgende fragmenten:
- "...daarom is het antwoord 10 meter."
- "De totale lengte bedraagt 10m."
- "Het resultaat is 10.0."
- "We komen uit op tien meter."
Als we hier een exacte string-match op loslaten, hebben we vier unieke antwoorden met elk één stem. Er treedt dan geen consensus op. Om dit op te lossen moeten we de outputs normaliseren voordat we de stemmen tellen. Dit kan op de volgende manieren worden ingericht:
### 1. Structured output forceren
De meest robuuste methode is om het model via systeemprompts of json-schemas te dwingen het eindantwoord in een specifiek formaat te gieten aan het einde van de redenering. We kunnen het model bijvoorbeeld vragen om het antwoord af te sluiten met een specifieke XML-tag:
[Stapsgewijze berekening...]
10
Met een reguliere expressie (zoals /(.*?)<\/antwoord>/) kunnen we de waarde binnen de tag eenvoudig extraheren en parseren.
### 2. Programmatische opschoning
Wanneer we ruwe tekst analyseren, moeten we een parser bouwen die de volgende stappen doorloopt:
- Tekst naar kleine letters omzetten (lowercasing): Voorkomt dat "Antwoord A" en "antwoord a" als verschillend worden gezien.
- Numerieke eenheden gelijktrekken: Het strippen van eenheden zoals "meter", "kg", "$" of "euro".
- Getallen converteren en afronden: Zorgen dat "10", "10.0" en "10,00" allemaal worden geconverteerd naar de float-waarde 10.0. Tevens moeten we zwevende-kommagetallen afronden op een vooraf gedefinieerd aantal decimalen om afrondingsverschillen tussen modelruns te elimineren.
- Tekstantwoorden canoniek maken: Bij ja/nee-vragen of meerkeuzevragen moeten synoniemen (zoals "true", "ja", "yes", "correct") mapping-technisch naar één enkele boolean of categorie worden vertaald.
## Wanneer loont self-consistency?
Het inzetten van self-consistency is niet voor elke taak zinvol. Het mechanisme leunt zwaar op de aanname dat er een beperkt en consistent antwoordbereik is. We kunnen de geschiktheid categoriseren op basis van de aard van de taak:
### Geschikte taken
- Wiskundige berekeningen: Taken waarbij er slechts één correct numeriek antwoord is, hoewel er verschillende manieren zijn om er te komen.
- Logische puzzels en code-analyse: Vragen waarbij de uitkomst binair is (bijvoorbeeld: compileert deze code wel of niet?) of waarbij de output een specifieke syntax-constructie betreft.
- Classificatie onder tijdsdruk: Het toekennen van labels uit een vaste set aan documenten, waarbij fouten in individuele beslissingen direct impact hebben op de downstream-applicatie.
### Ongeschikte taken
- Open schrijfopdrachten: Het genereren van een blogpost, e-mail of creatieve tekst leent zich niet voor self-consistency. Omdat de oplossingsruimte oneindig is en er geen sprake is van een 'correct' antwoord, zal elk gegenereerd spoor uniek zijn. Stemmen is hierbij onmogelijk.
- Samenvattingen: Hoewel bepaalde feiten consistent moeten blijven, is de formulering van een samenvatting te variabel om te aggregeren via een meerderheidsstem.
## De kostenkant van parallelle paden
Hoewel self-consistency de nauwkeurigheid en betrouwbaarheid van antwoorden drastisch kan verhogen, hangt er een flink prijskaartje aan deze methode. Als we besluiten om $N$ onafhankelijke redeneersporen te genereren, stijgt het aantal benodigde outputtokens ruwweg met een factor $N$. Aangezien outputtokens bij commerciële API-aanbieders vaak aanzienlijk duurder zijn dan inputtokens, heeft dit een directe impact op de operationele kosten van een applicatie.
Bij het ontwerpen van een systeem moet je daarom de afweging maken tussen modelgrootte en het aantal runs. Soms presteert een kleiner, goedkoper model (zoals een 8B-parameter model) met een self-consistency factor van $N=8$ beter en goedkoper dan een groter frontier-model (zoals een 400B+ parameter model) met een enkele run ($N=1$). Deze balans moet per use-case empirisch worden vastgesteld door middel van gestructureerd testen.
## Praktische varianten en optimalisaties
Om de kosten te drukken en de efficiëntie te verhogen, zijn er in de praktijk verschillende geavanceerde varianten van self-consistency ontwikkeld:
### Vroegtijdig stoppen (Early Stopping)
In plaats van altijd star $N$ runs uit te voeren, kunnen we de runs sequentieel genereren. Zodra een specifiek antwoord een absolute meerderheid heeft bereikt die niet meer ingehaald kan worden door andere opties, stoppen we met het genereren van nieuwe paden. Stel dat we $N=10$ hebben ingesteld. Als de eerste 6 runs allemaal antwoord "A" opleveren, kan geen enkel ander antwoord de meerderheid nog behalen. We kunnen de resterende 4 runs annuleren, wat een directe besparing van 40% op de outputtokens oplevert.
### Gewogen stemmen (Weighted Voting)
Niet elk redeneerspoor is even overtuigend. Bij gewogen stemmen koppelen we de stem van een run aan de gemiddelde log-waarschijnlijkheid (logprob) van de gegenereerde tokens in dat spoor. Een run waarin het model met zeer hoge zekerheid (lage perplexiteit) redeneert, weegt zwaarder mee in de eindtelling dan een run waarin het model twijfelt en wankele stappen zet.
### Combineren met een aparte controlestap
Een krachtige hybride vorm is het combineren van self-consistency met een daaropvolgende verificatiestap. Nadat de modus van de antwoorden is bepaald, voeden we het winnende antwoord samen met de bijbehorende redeneersporen aan een apart (vaak kleiner) model met de vraag om te controleren of de stappen logisch consistent zijn met het gekozen antwoord. Dit filtert scenario's uit waarin het model weliswaar consistent is, maar collectief dezelfde fout maakt.
## Valkuilen en hoe ze te vermijden
Hoewel de logica achter self-consistency eenvoudig oogt, zijn er cruciale valkuilen waar ontwikkelaars in de praktijk tegenaan lopen:
### 1. Systematische bias en misconcepties
Self-consistency corrigeert willekeurige fouten die ontstaan door stochastische sampling. Het corrigeert echter geen systematische fouten. Als een model een fundamenteel verkeerd mentaal model heeft van een concept (bijvoorbeeld een hardnekkige misvatting over een natuurkundige wet), zal het in alle $N$ runs op basis van diezelfde misvatting redeneren. Het model zal dan met een zeer hoge consistentie het verkeerde antwoord kiezen. Consensus is niet gelijk aan correctheid.
### 2. Te lage temperatuur
Als de temperatuur te dicht bij nul ligt (bijvoorbeeld 0.1 of 0.2), zullen de gegenereerde paden nauwelige variatie vertonen. De runs worden nagenoeg identiek, waardoor het stemproces zijn waarde verliest. Zorg voor voldoende entropie in de sampling-fase om daadwerkelijk alternatieve routes door de beslissingsruimte te forceren.
### 3. Te kleine steekproefomvang
Bij een te lage waarde van $N$ (bijvoorbeeld $N=3$) is de kans op toevallige consensus tussen twee foutieve antwoorden reëel. Hoewel academische papers vaak waarden tussen $N=10$ en $N=40$ gebruiken, ligt het optimum voor productieomgevingen meestal tussen de $N=5$ en $N=10$, afhankelijk van de complexiteit van de taak.
## Het effect meten in je eigen opstelling
Ontwikkelaars maken vaak de fout om te veronderstellen dat self-consistency blindelings overgenomen kan worden op basis van academische benchmarks. De effectiviteit is echter sterk afhankelijk van je specifieke prompts, het gekozen model en de aard van de data. Het is daarom essentieel om dit effect zelfstandig door te meten.
Dit doe je door een representatieve testset (evaluatie-set) op te zetten van minimaal 100 handmatig geverifieerde cases. Vervolgens draai je twee testruns: één met een standaard single-path chain-of-thought en één met de self-consistency pipeline bij wisselende waarden van $N$ en verschillende temperaturen. Door dit proces te structureren, conform de principes beschreven in het artikel over [prompt testen voor productie](https://community.llmnet.nl/prompt-testen-voor-productie), kun je de exacte ROI van de extra tokenkosten berekenen en bepalen of de nauwkeurigheidswinst de kosten rechtvaardigt.
## Relatie tot moderne redeneermodellen
Sinds de introductie van geavanceerde redeneermodellen (zoals OpenAI's o-serie en vergelijkbare deep-thinking modellen) rijst de vraag of handmatige self-consistency prompting nog wel nodig is. Deze moderne modellen voeren intern al zoekpaden uit (zoals Monte Carlo Tree Search of A*-zoekalgoritmen) en wegen intern verschillende redeneersporen tegen elkaar af voordat ze een definitief antwoord tonen.
Wanneer je werkt met dergelijke native redeneermodellen, is het handmatig opzetten van een self-consistency loop vaak redundant en onnodig duur, aangezien het model deze complexiteit al op het niveau van de architectuur afhandelt. Echter, voor ontwikkelaars die gebruikmaken van standaard API's van reguliere LLMs (zoals GPT-4o, Claude 3.5 Sonnet of opensource-modellen zoals Llama 3) blijft self-consistency een van de meest krachtige instrumenten in de gereedschapskist om betrouwbaarheid af te dwingen op applicatieniveau. Hoe deze modellen zich in de breedte verhouden, is nader uitgewerkt in het overzicht van [redeneermodellen vergeleken](https://hub.llmnet.nl/redeneermodellen-vergeleken).
## Lees ook
- [Chain-of-Thought: De basis van logisch redeneren in LLMs](https://leren.llmnet.nl/chain-of-thought)
- [Sampling parameters: Invloed van temperatuur en top-p op modeloutput](https://leren.llmnet.nl/sampling-parameters)
- [Prompt chaining: Complexe workflows opdelen in stappen](https://community.llmnet.nl/prompt-chaining)
- [Prompt testen voor productie: Evals inrichten en meten](https://community.llmnet.nl/prompt-testen-voor-productie)
- [Redeneermodellen vergeleken: Architecturen en prestaties](https://hub.llmnet.nl/redeneermodellen-vergeleken)
llmnet.nl — prompt-engineering en developer-community