Chain-of-Verification: Hallucinaties Zelf Opsporen

Generatieve taalmodellen voorspellen tokens op basis van statistische patronen in hun trainingsdata. Hoewel moderne LLM's vloeiende en overtuigende zinnen construeren, leidt die probabilistische aard onvermijdelijk tot hallucinaties: het model verzint feiten, verwisselt jaartallen, introduceert fictieve wetenschappelijke publicaties of koppelt personen aan gebeurtenissen waar zij nooit bij betrokken waren. In productieomgevingen vormen deze subtiele onwaarheden een aanzienlijk risico, juist doordat de toon van het model autoritair en consistent blijft.

Waar veel toepassingen leunen op externe validatielagen of statische filters, pakt Chain-of-Verification (CoVe) dit probleem aan bij de kern van de promptarchitectuur. CoVe dwingt het model om zijn eigen gegenereerde beweringen stapsgewijs te ontleden in controleerbare feiten, deze onafhankelijk te onderzoeken en vervolgens de concepttekst te herzien. In deze handleiding ontleden we de mechanismen achter Chain-of-Verification, bekijken we concrete implementatiesjablonen en analyseren we de afwegingen rond latency, tokendichtheid en rekenkosten. Voor wie zoekt naar alternatieve methoden om contextuele ruis te onderdrukken, legt het artikel over hallucinaties beperken met context-grounding uit hoe brondocumenten direct als ankerpunt fungeren.

Het fundamentele probleem: autoregressieve confirmation bias

Waarom faalt een eenvoudige instructie zoals "Wees kritisch en controleer je eigen antwoord"? Dit heeft te maken met de manier waarop autoregressieve modellen werken. Wanneer een taalmodel een tekst genereert, vormen de reeds gegenereerde tokens de context voor elk volgend token. Heeft het model halverwege een alinea een onjuist jaartal neergezet, dan conditioneert die fout de resterende output. Vraagt men het model in dezelfde dialoogsessie of het antwoord klopt, dan zal het model zijn eerdere tokens als 'waarheid' meewegen.

Dit fenomeen staat bekend als confirmation bias binnen de autoregressieve context. Het model probeert een coherent verhaal voort te zetten in plaats van een kritische externe audit uit te voeren. Om een model daadwerkelijk zijn eigen fouten te laten ontdekken, moeten we de verificatievragen isoleren van de gegenereerde tekst. Chain-of-Verification structureert dit in vier afzonderlijke, deterministische stappen:

Door het proces op te splitsen in deze discrete componenten, ontstaat een workflow die structureel betrouwbaarder is dan een standaard zero-shot respons. Wie op zoek is naar patronen om omvangrijke taken op te splitsen in modulaire deelstappen, vindt in de handleiding over complexe taken opknippen met prompt-chaining aanvullende architecturen voor samengestelde pipelines.

Stap 1: Baseline Generatie (De conceptversie)

De eerste fase van CoVe is eenvoudig: het model krijgt de ruwe gebruikersvraag en genereert een initieel antwoord (de draft). Er worden in deze fase geen bijzondere restricties of complexe Chain-of-Thought instructies meegegeven. Het doel is niet om in één keer perfectie te bereiken, maar om een representatieve tekst te verkrijgen waarin de relevante entiteiten, jaartallen, relaties en beweringen aanwezig zijn.

In de praktijk dient de baseline als het 'ruwe materiaal' dat in de volgende fasen geauditeerd wordt. Zelfs als deze conceptversie grove fouten bevat, is dat geen probleem; het stelt de verificatieplanner in staat exact die punten te markeren die validatie vereisen.

Stap 2: Verificatieplanning (Atomaire vragen formuleren)

In de tweede stap analyseert het model zijn eigen concept-antwoord met als doel alle feitelijke aannames te identificeren. De instructie dwingt het model om voor elke concrete claim een onafhankelijke verificatievraag op te stellen. Hierbij gelden twee cruciale ontwerpregels:

• Neutraliteit: De vraag mag de veronderstelde claim niet als feit presenteren. Fout: "Waarom werd het verdrag in 1648 in Münster getekend?" Goed: "In welk jaar en op welke locatie werd het verdrag getekend?"
• Atomariteit: Elke vraag moet betrekking hebben op exact één controleerbare entiteit of relatie, zodat het antwoord niet verzandt in een nieuwe lange redenering.

Hieronder staat een concreet prompt-sjabloon voor de planningsfase:

### INSTRUCTIE: VERIFICATIEPLANNING
Je bent een feitenanalist. Analyseer het onderstaande concept-antwoord op de
oorspronkelijke vraag. Identificeer alle feitelijke beweringen over data,
personen, locaties, specificaties of historische gebeurtenissen.

Formuleer voor elke bewering een neutrale, atomaire verificatievraag.
Regels:
1. De vraag mag het antwoord niet suggereren of bevatten.
2. Splits samengestelde beweringen op in meerdere losse vragen.
3. Vraag uitsluitend naar objectiveerbare feiten.

Oorspronkelijke vraag:
{{GEBRUIKERSVRAAG}}

Concept-antwoord:
{{BASELINE_ANTWOORD}}

Lever de output uitsluitend als JSON:
{
  "claims": [
    {
      "geextraheerde_claim": "string",
      "verificatie_vraag": "string"
    }
  ]
}

Stap 3: Verificatie-executie — Joint versus Factorized

Het hart van Chain-of-Verification zit in de executie van de verificatievragen. Binnen de literatuur en praktische implementaties worden twee varianten gehanteerd: Joint Verification en Factorized Verification. Het verschil tussen beide bepaalt in grote mate of een hallucinatie daadwerkelijk wordt opgelost.

Variant A: Joint Verification (Alles in één context)

Bij Joint Verification worden de oorspronkelijke vraag, het concept-antwoord, de verificatievragen en de antwoorden in één enkel contextvenster gegenereerd. Het model ziet dus zijn eigen eerdere tekst terwijl het de vragen beantwoordt. Dit bespaart API-aanroepen, maar introduceert opnieuw het risico op conditionering: het model leest zijn eigen eerdere hallucinatie en gebruikt die als rechtvaardiging voor het verificatie-antwoord.

Variant B: Factorized Verification (Volledige isolatie)

Bij Factorized Verification wordt elke verificatievraag via een afzonderlijke, schone API-aanroep verwerkt. Het model krijgt uitsluitend de specifieke verificatievraag te zien, zonder de context van de oorspronkelijke gebruikersvraag en zonder het concept-antwoord. Hierdoor kan het model niet terugvallen op de foutieve context van de baseline.

import asyncio
from typing import List, Dict

async def voer_factorized_verificatie_uit(
    vragen: List[str], 
    llm_client
) -> List[Dict[str, str]]:
    """
    Voert verificatievragen parallel en in geïsoleerde contexten uit.
    """
    async def verifieer_enkele_vraag(vraag: str):
        prompt = (
            "Beantwoord de onderstaande vraag direct, feitelijk en beknopt. "
            "Geef alleen het geverifieerde feit zonder inleiding.\n\n"
            f"Vraag: {vraag}"
        )
        # Context is volledig leeg: geen baseline aanwezig
        respons = await llm_client.generate(prompt=prompt, temperature=0.0)
        return {"vraag": vraag, "feit": respons.strip()}

    taken = [verifieer_enkele_vraag(v) for v in vragen]
    return await asyncio.gather(*taken)

Uit empirische evaluaties blijkt dat Factorized Verification significant beter presteert dan Joint Verification bij het corrigeren van hardnekkige parametrische hallucinaties. De isolatie dwingt het model om direct uit zijn gewichten te putten zonder beïnvloed te worden door eerder gegenereerde tokenreeksen.

Stap 4: Finale Synthese en Feitelijke Revisie

In de vierde fase worden alle draden samengebracht. Het model ontvangt de oorspronkelijke vraag, het concept-antwoord uit stap 1 en de verzameling geverifieerde vraag-antwoordparen uit stap 3. De taak is nu zuiver redactioneel: herschrijf de baseline zodat deze volledig in overeenstemming is met de vastgestelde feiten.

### INSTRUCTIE: FINALE SYNTHESE
Hieronder vind je een oorspronkelijke gebruikersvraag, een eerste concept-antwoord
en een lijst met onafhankelijk geverifieerde feiten.

Herschrijf het concept-antwoord naar een definitief, accuraat antwoord.

Regels voor de synthese:
1. Vergelijk elke claim in het concept-antwoord met de geverifieerde feiten.
2. Verbeter eventuele feitelijke onjuistheden direct op basis van de feitenlijst.
3. Verwijder claims die in tegenspraak zijn met de verificatie of waarvoor geen
   bevestiging is gevonden.
4. Behoud een natuurlijke, vloeiende schrijfstijl.
5. Verwijs in de uiteindelijke tekst NIET naar het verificatieproces, de conceptversie
   of de feitenlijst.

Oorspronkelijke vraag:
{{GEBRUIKERSVRAAG}}

Eerste concept-antwoord:
{{BASELINE_ANTWOORD}}

Geverifieerde feiten:
{{GEVERIFIEERDE_FEITEN}}

Wanneer een systeem niet alleen individuele feiten moet herstellen, maar over meerdere iteratieve stappen autonoom zijn plannen moet bijstellen op basis van runtime-uitkomsten, sluiten reflexion-patronen voor agents naadloos aan op dit validatieconcept.

Vergelijking: CoVe versus Alternatieve Redeneertechnieken

Om te bepalen waar Chain-of-Verification gepositioneerd moet worden in een productie-architectuur, vergelijken we de techniek met Chain-of-Thought (CoT), Self-Consistency en Retrieval-Augmented Generation (RAG):

Het cruciale onderscheid tussen Chain-of-Thought en Chain-of-Verification is dat CoT de kans op redeneerfouten verkleint, maar feitelijke hallucinaties juist kan versterken: een model verzint met CoT simpelweg een uiterst overtuigende, stapsgewijze onderbouwing voor een onwaar feit. CoVe daarentegen breekt de redenering af tot losse claims.

Concrete doorrekening: een praktijkvoorbeeld

Laten we het effect van CoVe illustreren aan de hand van een klassiek voorbeeld waarin parametrische drift optreedt.

Gebruikersvraag: "Noem drie Nederlandse natuurkundigen die de Nobelprijs hebben gewonnen en vermeld het jaartal en hun ontdekking."

Fase 1 (Baseline): Het model noemt Hendrik Lorentz (1902), Pieter Zeeman (1902) en per abuis Christiaan Huygens (1925, voor de golftheorie van het licht). Huygens leefde in de 17e eeuw; de Nobelprijs bestond toen nog niet. Dit is een typische historische hallucinatie.

Fase 2 (Planning): De verificatiemodule ontleedt de claims en genereert de volgende vragen:

• Vraag 1: "In welk jaar ontving Hendrik Lorentz de Nobelprijs voor de Natuurkunde?"
• Vraag 2: "In welk jaar ontving Pieter Zeeman de Nobelprijs voor de Natuurkunde?"
• Vraag 3: "Heeft Christiaan Huygens ooit een Nobelprijs gewonnen en in welke periode leefde hij?"
• Vraag 4: "Welke andere Nederlandse natuurkundigen hebben een Nobelprijs gewonnen?"

Fase 3 (Factorized Executie): Elke vraag wordt afzonderlijk beantwoord. Vraag 3 levert op: "Nee, Christiaan Huygens leefde van 1629 tot 1695. De Nobelprijzen werden pas ingesteld in 1901." Vraag 4 levert alternatieven op zoals Heike Kamerlingh Onnes (1913) en Johannes Diderik van der Waals (1910).

Fase 4 (Synthese): De synthese-instructie herkent de discrepantie tussen de baseline en het antwoord op vraag 3. Het model verwijdert Huygens uit de lijst en vervangt hem door Kamerlingh Onnes, inclusief het correcte jaartal (1913) en onderwerp (vloeibaar helium en supergeleiding).

Meetmethoden en Evaluatie van CoVe-Pipelines

Om vast te stellen of een CoVe-implementatie daadwerkelijk meerwaarde levert binnen een productie-omgeving, is een gestructureerde evaluatiemethode noodzakelijk. Het simpelweg steekproefsgewijs inspecteren van outputs levert te weinig statistische zekerheid op. Een robuuste meetopstelling hanteert drie kernstatistieken:

1. Fact Extraction Precision (FEP): Het percentage geëxtraheerde verificatievragen dat daadwerkelijk betrekking heeft op een feitelijke bewering (en geen overbodige stijlvraag is).
2. Hallucination Resolution Rate (HRR): Het aandeel feitelijke fouten in de baseline dat na de synthesefase succesvol is gecorrigeerd of verwijderd.
3. Over-Correction Rate (OCR): Het percentage gevallen waarin een oorspronkelijk correcte bewering in de baseline door de verificatiestap ten onrechte is aangepast of verwijderd.

Voor het opzetten van geautomatiseerde testsets en kwantitatieve scoringsmethoden biedt het overzicht over hallucinaties meten en feitelijkheid testen gedetailleerde protocollen om betrouwbaarheidsscores te benchmarken.

Kosten, Latency en Resource-allocatie

De invoering van Chain-of-Verification brengt duidelijke operationele trade-offs met zich mee. Waar een standaard LLM-aanroep bestaat uit één request, transformeert een factorized CoVe-patroon dit in een reeks interacties:

In een geoptimaliseerde architectuur waarin de verificatievragen in stap 3 parallel via async-workers worden verwerkt, bedraagt de totale doorlooptijd doorgaans 1,5 tot 2,5 seconden. Voor synchrone chatbots kan dit een drempel vormen; voor asynchrone rapportgeneratie, data-extractie, juridische samenvattingen en medische documentverwerking is deze extra wachttijd echter ruimschoots acceptabel gezien de significante winst in nauwkeurigheid.

Structurele Beperkingen en Randgevallen

Hoewel Chain-of-Verification een krachtig patroon is, kent de methode duidelijke grenzen die ontwikkelaars moeten meewegen in hun systeemontwerp:

1. De grens van parametrische kennis (Unknown Unknowns)

CoVe kan alleen feiten verifiëren die op een of andere manier aanwezig zijn in de gewichten van het model. Wanneer een model fundamenteel geen kennis heeft over een niche-onderwerp of over gebeurtenissen die plaatsvonden na de trainingsdatum, zal het ook tijdens de factorized verificatiestap hallucineren. CoVe lost stochastische drift op (waarbij het model de kennis wel heeft maar ontspoort door eerdere tokens), maar dicht geen structurele kennishiaten. Voor actuele of bedrijfsinterne data blijft koppeling met RAG of web-retrieval noodzakelijk.

2. Complexe relationele afhankelijkheden

Wanneer een bewering rust op een keten van vijf onderling afhankelijke variabelen, kan het opsplitsen in atomaire vragen ertoe leiden dat de overkoepelende context verloren gaat. In zulke situaties kan het model tijdens stap 3 alle individuele vragen correct beantwoorden, maar tijdens stap 4 falen om de synthese logisch sluitend te maken.

3. Gevoeligheid voor prompt-drift in stap 2

Als de instructie voor verificatieplanning te laks is geformuleerd, neigen modellen ertoe triviale vragen te genereren (zoals "Is de toon van de tekst professioneel?") in plaats van harde feitelijke toetsen. Strikte JSON-schema's en expliciete few-shot voorbeelden in de planningsprompt zijn vereist om dit gedrag te beteugelen.

Conclusie

Chain-of-Verification maakt van kwaliteitscontrole een expliciet, programmeerbaar onderdeel van de promptpipeline. Door het genereren van een concept strikt te scheiden van de verificatieplanning, en door die verificatie via geïsoleerde factorized aanroepen uit te voeren, wordt de confirmation bias van autoregressieve modellen effectief doorbroken. Voor applicaties waar feitelijke betrouwbaarheid zwaarder weegt dan minimale latency, biedt CoVe een robuuste en direct toepasbare methodiek.