Een model beantwoordt met vertrouwen een vraag die het feitelijk niet correct kan beantwoorden. Het verzint een citaat, vult een ontbrekend getal in, bevestigt een aanname in de vraag — en het hele antwoord klinkt overtuigend. Dit noemen we hallucinatie (uit het Engels *hallucination*): het genereren van geloofwaardige maar feitelijk onjuiste uitvoer. In een experimentele omgeving is dat irritant. In productie — bij het werken met documentatie, contracten, technische normen of klantvereisten — veroorzaakt het echte schade.
De praktijk laat zien dat de basishallucinatierate van frontier-modellen in de orde van enkele tot tientallen procenten ligt bij vakinhoudelijke vragen waarbij het model onvoldoende grounding heeft. Het doel van dit artikel is niet een hallucinatievrij systeem beloven — dat bestaat niet. Het doel is vijf technieken laten zien die dit probleem in productie aanzienlijk kunnen verminderen, en uitleggen waarom elke techniek anders werkt en waarom geen enkele op zichzelf volstaat.
Waarom hallucinaties nooit volledig verdwijnen
Voordat we de technieken bespreken, is het belangrijk de onderliggende oorzaak te begrijpen. LLM's zoeken geen feiten op — ze genereren tokens op basis van wat statistisch waarschijnlijk is in de gegeven context. Een model maakt geen onderscheid tussen "ik weet het" en "ik weet het niet": als het niet expliciet getraind of geïnstrueerd is om onzekerheid te uiten, genereert het standaard een vloeiend en geloofwaardig antwoord.
Modelgrootte lost het probleem op zichzelf niet op — een groter model kan zelfverzekerder hallucineren, omdat zijn taalcapaciteiten beter zijn en de uitvoer overtuigender klinkt. Zonder een grounding-strategie verlaagt modelgroei het risico dus niet, in sommige gevallen vergroot het dat zelfs.
Gevolg voor productie-deployments: hallucinaties moeten architectonisch beheerd worden, niet alleen door een beter model te kiezen.
Techniek 1: Grounding via RAG met citeerbare bronnen
RAG (*Retrieval-Augmented Generation*) is tegenwoordig het meestgebruikte mechanisme om hallucinaties bij feitelijke vragen te verminderen. Het principe is eenvoudig: in plaats van dat het model antwoordt vanuit parametrisch geheugen (wat het tijdens training heeft geleerd), krijgt het relevante passages uit geverifieerde documenten in de context. Het antwoord moet vervolgens uit die context voortkomen.
Documenten simpelweg aan de prompt toevoegen is niet genoeg. Een kwalitatief goed grounding-systeem heeft drie lagen:
- Retrieval — vectorzoekopdracht (bijv. via
Qdrantofpgvector) aangevuld met hybride zoeken (BM25 + vectoren), zodat niet alleen semantisch vergelijkbare maar ook op trefwoorden relevante passages worden gevonden - Reranking — een cross-encoder model herordent de resultaten; zonder reranking geeft retrieval zowel relevante als minder relevante chunks terug, een reranker verbetert de selectieprecisie aanzienlijk
- Citeerbaarheid — het model krijgt de instructie: elke bewering moet onderbouwd zijn door een specifieke bron met verwijzing naar document en pagina; als die bron niet bestaat, verzint het niets
Citeerbaarheid is niet alleen cruciaal voor nauwkeurigheid maar ook voor verifieerbaarheid: de gebruiker ziet waar de informatie vandaan komt en kan die controleren. In de praktijk vergroot dit het vertrouwen aanzienlijk en onthult het gevallen waarin het model een citaat heeft genegeerd of verzonnen. Meer over het evalueren van een RAG-pipeline leest u in het artikel Hoe RAG evalueren (RAGAS), waar we de metrieken faithfulness en answer relevance beschrijven.
Belangrijke kanttekening: RAG lost niet alles op. Als retrieval verkeerde chunks teruggeeft (embedding mismatch, slechte chunking, verouderde database), kan het model ook met context hallucineren — of, wat erger is, met een valse citaat hallucineren. RAG is een noodzakelijke, geen voldoende voorwaarde.
Techniek 2: Gestructureerde uitvoer en programmatische validatie
Vrije tekst is moeilijk te controleren. Als het model antwoordt in een precies gedefinieerde structuur — JSON-schema, Pydantic-model, opsomming van toegestane waarden — kunnen we de uitvoer machinaal valideren voordat die bij de gebruiker of het volgende systeem terechtkomt.
Moderne modellen en frameworks ondersteunen structured outputs (*gestructureerde uitvoer*): het model wordt gedwongen tokens te genereren die overeenkomen met het opgegeven schema. Een hallucinatie kan dus geen veld verzinnen dat het schema niet bevat. Als het toegestane veld risk_level de waarden ["low", "medium", "high"] heeft, kan het model geen "critical" of onzin teruggeven.
In de praktijk combineren we drie stappen:
- 1.Het definiëren van een uitvoerschema (bijv. JSON-schema of Pydantic-model)
- 2.Het gebruik van
structured outputs/JSON modein de API-aanroep - 3.Programmatische validatie van de uitvoer — als de uitvoer niet overeenkomt met het schema, wordt de aanroep herhaald of geëscaleerd naar een menselijke review
Deze aanpak werkt het beste voor afgebakende taken: entiteitsextractie, classificatie, het invullen van formulieren, het omzetten van een document naar een structuur. Voor vrije tekst (samenvatting, interpretatie) is de toepasbaarheid beperkt, maar ook hier kunnen we op zijn minst de aanwezigheid van verplichte velden valideren (bijv. de sectie "Bronnen" of "Waarschuwingen").
Techniek 3: "Ik weet het niet" toestaan — kalibratie van onzekerheid
Een van de eenvoudigste en meest effectieve stappen is het model expliciet toestaan "ik weet het niet" te antwoorden, of "op basis van de beschikbare informatie kan ik dat niet beoordelen". Dit klinkt triviaal, maar de meeste productie-prompts vergeten dit — en het model genereert dan standaard een antwoord, ook als het de informatie niet heeft.
In de systeemprompt (Engels: *system prompt*) adviseren we een formulering in de trant van:
- Als het antwoord niet uit de beschikbare documenten volgt, geef dan expliciet aan dat de informatie niet beschikbaar is.
- Leid geen feiten af die niet in de context staan.
- Als u onzeker bent, geef de mate van onzekerheid aan met woorden ("waarschijnlijk", "op basis van de beschikbare informatie").
Belangrijk: kalibratie van onzekerheid moet een actieve instructie zijn, niet alleen de afwezigheid van een hallucinatieverbod. "Halluciner niet" is niet genoeg — het model begrijpt die instructie wel, maar heeft geen mechanisme om dat uit te voeren zonder een expliciet kader voor het uiten van onzekerheid.
In gereguleerde domeinen (juridische documenten, technische documentatie, veiligheidsnormen) adviseren we ook een escalatieregel te definiëren: als het model niet in staat is met voldoende zekerheid te antwoorden, moet het antwoord een verzoek bevatten om bij een bevoegde persoon te verifiëren. Dit verlaagt direct het risico van een stille fout — de situatie waarin het systeem met zekerheid antwoordt en de fout onopgemerkt blijft.
Techniek 4: LLM-as-Judge — automatische verificatie van uitvoer
LLM-as-Judge (*LLM als rechter*) is een techniek waarbij een tweede taalmodel de uitvoer van het eerste beoordeelt. In productie wordt dit gebruikt voor automatische detectie van hallucinaties, het controleren van consistentie met de context en het beoordelen van de antwoordkwaliteit — zonder dat bij elke response een menselijke reviewer nodig is.
Een typische flow ziet er als volgt uit:
- 1.Het primaire model genereert een antwoord
- 2.Het verificatiemodel ontvangt een drievoud: vraag + broncontext + gegenereerd antwoord
- 3.Het verificatiemodel beoordeelt: bevat het antwoord beweringen die niet door de context worden ondersteund? Is het antwoord feitelijk consistent met de bronnen?
- 4.Op basis van de score wordt het antwoord ofwel afgeleverd, tegengehouden of doorgestuurd voor menselijke review
Voor het verificatiemodel adviseren we een gelijkwaardig of sterker model te gebruiken dan het primaire model — een zwakkere verificator kan fouten van een sterkere niet betrouwbaar detecteren. In de praktijk zien we goede resultaten bij de combinatie van een lokaal draaiend primair model en een frontier-verificator (bijv. Claude Sonnet of GPT-4o-klasse) voor kritieke antwoorden.
Frameworks zoals Langfuse of Arize Phoenix maken het mogelijk deze flow te integreren in een productiepipeline met logging, alerting en retrospectieve analyse. Meer over de totaalaanpak voor kwaliteitsmeting vindt u in het artikel Hoe de kwaliteit van een LLM-applicatie meten (evals).
Beperking: LLM-as-Judge is niet onfeilbaar — ook het verificatiemodel kan "instemmen" met een gehallucineerd antwoord als beide consistent zijn maar feitelijk onjuist. Daarom combineren we het met grounding (techniek 1) en regelmatige menselijke audits van een steekproef van de uitvoer.
Techniek 5: Temperatuur, sampling en prompt engineering
De laatste techniek is het goedkoopst te implementeren, maar heeft het kleinste effect zonder de andere lagen. Toch is het belangrijk.
Temperatuur (*temperature*) beïnvloedt de willekeurigheid van de generatie. Een lage temperatuur (bijv. 0.0–0.2) produceert meer deterministische, consistente uitvoer — het model kiest het meest waarschijnlijke token, niet een willekeurig. Voor feitelijke taken (extractie, classificatie, antwoorden op vragen uit documenten) adviseren we een lage temperatuur. Voor creatieve of generatieve taken is een hogere temperatuur wenselijk, maar die verhoogt ook het risico op afwijkingen.
Prompt engineering om hallucinaties te verminderen kent een aantal bewezen principes:
- Few-shot voorbeelden — toon het model voorbeelden van correct gedrag, inclusief voorbeelden waarbij het antwoord "ik weet het niet" is; het model leert dit gedrag in de context
- Expliciete formaatspecificatie — "antwoord uitsluitend op basis van de volgende documenten, sluit elke bewering af met een genummerd citaat"
- Negatieve instructies — "leid geen informatie af die niet expliciet in de context staat"
- Chain-of-thought (*stapsgewijs redeneren*) — bij complexe vragen het model vragen de stappen te doordenken vóór de definitieve uitvoer; bij gevoelige taken vermindert dit het "kortsluitingsgedrag" naar een gehallucineerd antwoord aanzienlijk
Let op: prompts zijn kwetsbaar — ze werken voor een specifiek model en versie. Bij een model- of versiewijziging moeten prompts opnieuw geëvalueerd worden. Prompt engineering is dus een doorlopende activiteit, geen eenmalige output. Meer hierover: Prompt engineering voor productie.
Vijf technieken gecombineerd
Geen enkele techniek volstaat op zichzelf. In de praktijk combineren we ze in lagen:
- Basislaag — RAG met citaten + "ik weet het niet" toegestaan in de systeemprompt
- Uitvoerlaag — gestructureerde uitvoer + programmatische validatie
- Verificatielaag — LLM-as-Judge voor kritieke antwoorden
- Kalibratielaag — lage temperatuur + few-shot prompt voor consistentie
Het effect van de combinatie is aanzienlijk groter dan de som van de afzonderlijke technieken. Productiesystemen waarbij we alle vier lagen hebben geïmplementeerd, bereiken een aanzienlijk lagere feitelijke foutrate dan systemen met één laag — in de orde van tienden van procenten versus enkele procenten bij vakinhoudelijke vragen. De exacte cijfers zijn afhankelijk van het domein, de kwaliteit van de brondocumenten en de evaluatiemethode.
Wat de technieken niet helpt
Voor de volledigheid: wat hallucinaties onbetrouwbaar vermindert:
- Een groter model — kan zelfverzekerder hallucineren; zonder grounding-strategie helpt het niet
- Langere context — meer data in de context betekent niet minder hallucinaties; het model kan relevante context negeren of verkeerd interpreteren
- Een eenvoudig verbod op hallucineren in de prompt — het model begrijpt het begrip "hallucineren" niet op een manier waardoor het dat actief kan voorkomen; het heeft positieve instructies nodig om onzekerheid uit te drukken
- Benchmarkscores van een model — MMLU en vergelijkbare benchmarks zijn verzadigd en meten geen productiegedrag in vakdomeinen; een resultaat op een leaderboard correleert niet betrouwbaar met de hallucinatierate in uw specifieke applicatie
Veelgestelde vragen
Is het mogelijk een systeem te maken dat nooit hallucineert?
Nee. LLM's zijn stochastische generatieve modellen — er is altijd een niet-nul kans op gehallucineerde uitvoer. Het doel is niet nul fouten, maar verlaging tot een acceptabel niveau voor het gegeven gebruik en het invoeren van mechanismen om fouten te detecteren en op te vangen voordat ze schade veroorzaken. Voor kritieke beslissingen (juridisch, medisch, veiligheid) blijft menselijke review onmisbaar.
Helpt fine-tuning op bedrijfsgegevens hallucinaties te verminderen?
Slechts gedeeltelijk en niet direct. Fine-tuning (*het verfijnen van het model* op eigen data) verbetert de antwoordstijl, terminologie en het formaat — maar verbetert de feitelijke nauwkeurigheid niet als het model bij inference niet de relevante context ontvangt. Voor het verminderen van hallucinaties is RAG doorgaans een effectievere en goedkopere aanpak. Fine-tuning en RAG sluiten elkaar niet uit — hun combinatie is zinvol in meer geavanceerde deployments. De beslissing tussen beide beschrijven we in het artikel RAG vs. fine-tuning — beslissingskader.
Hoe achterhaal ik hoeveel onze LLM-applicatie hallucineert?
Systematische evaluatie vereist een eval-dataset — een set vragen met correcte antwoorden of brondocumenten — en een evaluatieframework zoals RAGAS (voor RAG-pipelines) of Langfuse (voor algemene LLM-applicaties). Geautomatiseerde evaluatie via LLM-as-Judge kan grote volumes verwerken, maar moet gekalibreerd worden ten opzichte van menselijke beoordeling, tenminste op een steekproef. Periodieke menselijke audits van productie-uitvoer adviseren we altijd, niet alleen bij de eerste uitrol.
Verhoogt een lage temperatuur het risico op stereotiepe of onvolledige antwoorden?
Ja, dat is een reële afweging. Een lage temperatuur vermindert variabiliteit — het model kiest consequent de meest waarschijnlijke tokens, wat in extreme gevallen kan leiden tot herhalende zinnen of het weglaten van minder waarschijnlijke maar relevante informatie. In de praktijk adviseren we een temperatuur van 0.1–0.3 voor feitelijke taken, niet de absolute nul, en die te combineren met expliciete instructies voor volledigheid van het antwoord.
Wat zijn de kosten van het invoeren van deze technieken?
De kosten zijn primair implementatie- en operationeel. Een RAG-pipeline vereist een vectordatabase, een embedding-model en retrieval-logica — bij een self-hosted oplossing (bijv. Qdrant + open-weight embedding-model) gaat het om enkele euro's per maand voor infrastructuur. LLM-as-Judge verdubbelt het aantal LLM-aanroepen voor kritieke uitvoer, wat de API-kosten verhoogt. Structured outputs zijn praktisch zonder extra kosten. De totale investering hangt af van het volume, maar bij typische bedrijfsapplicaties (tientallen tot honderden queries per dag) is de kostenstijging verwaarloosbaar ten opzichte van het risico van een stille fout in productie.
*Als u van plan bent LLM in te zetten in een omgeving waar feitelijke nauwkeurigheid direct van invloed is op beslissingen — van technische documentatie tot klantenondersteuning of compliance — helpen we u graag beoordelen welke combinatie van technieken zinvol is voor uw specifieke geval. MP Industrial Solutions heeft ervaring met productie-deployments in zowel industriële als gereguleerde omgevingen.*