Waarom een hallucinatie niet «opgelost» wordt met een prompt
Voordat je aan configuratie begint, is het verstandig een ongemakkelijke realiteit te accepteren: hallucinaties zijn geen bug die je met een strengere instructie wegneemt. Het zijn een emergent gedrag van de probabilistische werking van het model. Een LLM genereert het meest waarschijnlijke token gegeven een sequentie; hij raadpleegt geen feitendatabase. Wanneer de context het antwoord niet bevat, stopt het model niet: het vult aan met wat statistisch gezien past. Dat betekent dat elke configuratie die je «nul hallucinaties» belooft, je lucht verkoopt.
Wat je wél kunt doen, is het oppervlak verkleinen waar ze opduiken, ze detecteren voordat ze de gebruiker bereiken en het systeem gecontroleerd laten degraderen wanneer het vertrouwen daalt. Dit artikel is een echte configuratiereeks, met concrete parameters, drempels en verificaties, voor teams die al een LLM in productie hebben of op het punt staan er een te lanceren.
Stap 1: scheid de soorten hallucinaties voordat je iets configureert
Niet alle hallucinaties worden op dezelfde manier gemitigeerd. Configureren zonder classificatie leidt ertoe dat je de verkeerde plek patch. Onderscheid ten minste deze vier, want elk vraagt een andere laag:
- Feitelijk: het model beweert een onwaar gegeven (een datum, een cijfer, een wet). Dit bestrijd je met contextretrieval en externe verificatie.
- Van toeschrijving: het verzint een bron, een auteur of een citaat. Dit is de gevaarlijkste in redactionele content, omdat het verifieerbaar lijkt.
- Van instructie: het negeert een systeembeperking (antwoordt in een andere taal, breekt het formaat). Dit bestrijd je met outputvalidatie.
- Van redenering: de tussenstappen zijn plausibel, maar de conclusie volgt er niet uit. Dit bestrijd je met decompositie en controle van elke stap.
Een geval dat ik herhaaldelijk zie bij contentteams: ze zetten de temperatuur op 0 in de veronderstelling dat dat een einde maakt aan verzonnen bronnen. Het verlaagt de variabiliteit, ja, maar een model met temperatuur 0 blijft referenties verzinnen als het het gegeven niet heeft. Temperatuur vermindert de spreiding, niet de onwetendheid.
Stap 2: stel de temperatuur en sampling in op basis van de taak
De samplingconfiguratie is de eerste echte knop. Er bestaat geen universele waarde; er bestaat een waarde per taaktype. Laat je leiden door deze tabel:
| Taak | Temperatuur | top_p | Opmerking |
|---|---|---|---|
| Gegevensextractie uit een document | 0 – 0,1 | 1 | Je wilt determinisme, geen creativiteit |
| Antwoorden over interne documentatie | 0,1 – 0,3 | 0,9 | Minimale marge om zinnen niet te herhalen |
| Ondersteund schrijven met menselijke verificatie | 0,4 – 0,7 | 0,95 | Verificatie achteraf is verplicht |
| Brainstormen, naming | 0,8 – 1,0 | 1 | Hier is hallucinatie een feature, geen bug |
Expertwaarschuwing: top_p verlagen naar 0,5 snijdt de staart van onwaarschijnlijke tokens af, wat zeldzame verzinsels vermindert, maar de tekst ook vlakker en repetitiever maakt. Bij gestructureerde extractietaken is het verstandig dit te combineren met constrained decoding (grammatica’s of geforceerde JSON-schema’s), wat effectiever is dan welke temperatuuraanpassing dan ook om verzonnen velden te voorkomen.
Stap 3: bouw retrieval met een afwijzingsdrempel
De krachtigste hefboom tegen feitelijke hallucinatie is het model niet uit het geheugen laten antwoorden. Configureer een RAG-pipeline (retrieval-augmented generation) met deze expliciete beslissingen:
- Chunking: fragmenten van 300 tot 600 tokens met 10-15% overlap. Te grote fragmenten verdunnen het signaal; te kleine verliezen de context die foutieve interpretaties voorkomt.
- Hybride retrieval: combineer semantisch zoeken (embeddings) met lexicaal zoeken (BM25). Semantiek faalt bij identificatoren, codes en eigennamen; lexicaal faalt bij parafrasering. Samen dekken ze meer.
- Similariteitsdrempel: definieer een minimale score (bijvoorbeeld 0,75 in cosinusgelijkenis, aangepast na meting met je eigen corpus) waaronder het systeem het model niet aanroept en een bericht teruggeeft als «ik heb onvoldoende informatie».
- Gesloten-contextprompt: instrueer het model alleen te antwoorden met de opgehaalde fragmenten en expliciet aan te geven wanneer de context de vraag niet dekt. Deze instructie is niet onfeilbaar, maar in combinatie met de drempel vermindert ze verzonnen antwoorden drastisch.
Hier is de praktische fout die bijna iedereen de eerste keer maakt: de retrievaldrempel te hoog instellen. Het systeem begint legitieme vragen af te wijzen en het team verlaagt hem gefrustreerd naar nul. De juiste drempel raad je niet: die kalibreer je met een set van 50 tot 100 echte vragen, waarbij je meet hoe vaak hij een vraag afwijst die wél een antwoord had, tegenover hoe vaak hij antwoordt zonder context. Zonder die kalibratieset is elke drempel een gok.
Stap 4: systeeminstructies die wél werken (en die niet)
Zinnen als «verzin niets» hebben beperkte effectiviteit. Operationele en verifieerbare instructies werken beter:
- In plaats van «wees precies», gebruik «citeer het contextfragment waaruit elke bewering voortkomt; als er geen fragment is, antwoord ‘niet vermeld'».
- In plaats van «hallucineer niet», gebruik «als de vraag gegevens vereist die later zijn dan je kennis of niet in de context staan, zeg dat voordat je antwoordt».
- Voeg een uitvoerformaat toe met verplichte velden: antwoord, bronnen (lijst van gebruikte fragmenten), vertrouwen (hoog/midden/laag). Het bronnenveld dwingt het model zich te committeren en vergemakkelijkt automatische verificatie.
Wat niet werkt: tien negatieve beperkingen stapelen in de systeemprompt. Vanaf een bepaald aantal begint het model de eerste te negeren of zichzelf te veel te beperken en geldige verzoeken af te wijzen. Prioriteer drie of vier kritieke regels en valideer elk met tests.
Stap 5: outputverificatie voordat je aan de gebruiker toont
De configuratie eindigt niet bij het model. Voeg een laag programmatische validatie toe tussen het antwoord en de gebruiker:
- Schemavalidatie: als je JSON verwacht, wijs elke output af die niet aan het schema voldoet. Probeer het niet te repareren met een andere prompt zonder de fout te markeren.
- Entiteitscontrole: extraheer namen, datums en cijfers uit het antwoord en vergelijk ze met de opgehaalde context. Als een entiteit in geen enkele bron voorkomt, markeer haar.
- Citaatverificatie: als het model een document citeert, controleer dat dat document in je index bestaat en dat het geciteerde fragment erin staat. Verzonnen citaten worden zo met hoge betrouwbaarheid gedetecteerd.
- Tweede pass met een ander model of een andere prompt: een kleiner model dat als verificateur optreedt, kan niet-onderbouwde beweringen aanwijzen. Het is niet onfeilbaar en voegt latentie toe, maar in redactionele contentstromen weegt dat op.
Belangrijke nuance: automatische verificatie heeft fout-positieven. Een te strenge verificateur wijst correcte antwoorden af die de context parafraseren in plaats van letterlijk te citeren. Configureer de verificateur om betekenis te vergelijken, niet exacte stringovereenkomst, anders heb je een systeem dat alles afwijst.
Stap 6: definieer het degradatiegedrag
Een volwassen systeem weet wat het moet doen als het niet zeker is. Configureer deze toestanden expliciet:
- Hoog vertrouwen: direct antwoord met bronnen.
- Midden vertrouwen: antwoord met zichtbare waarschuwing en links naar de bronnen voor menselijke verificatie.
- Laag vertrouwen: niet antwoorden; aanbieden de vraag te herformuleren of door te verwijzen naar een mens.
- Validatiefout: het volledige geval loggen (prompt, opgehaalde context, output, reden van afwijzing) voor latere analyse.
Logging is het deel dat het vaakst vergeten wordt en het meest waardevol is. Zonder foutenlog kun je drempels noch prompts verbeteren; dan kun je alleen hopen. Volgens de documentatie van de belangrijkste modelaanbieders is continue evaluatie met eigen testsets de enige betrouwbare manier om te meten of je wijzigingen hallucinaties verminderen of alleen verplaatsen.
Stap 7: meet met een eigen testset, niet met publieke benchmarks
Generieke benchmarks weerspiegelen je domein niet. Stel een evaluatieset samen met drie soorten cases: vragen die je systeem correct moet beantwoorden, vragen buiten bereik die het moet afwijzen en strikvragen (valse premissen) die het moet corrigeren. Voer die set uit telkens wanneer je temperatuur, prompt, model of retrievaldrempel wijzigt.
Twee minimale metrieken: verzinsratio (antwoorden met niet-onderbouwde beweringen gedeeld door gegeven antwoorden) en correcte afwijzingsratio (afgewezen vragen buiten bereik gedeeld door vragen buiten bereik). Als je alleen de eerste optimaliseert, zal het systeem uiteindelijk alles afwijzen; als je alleen de tweede optimaliseert, zal het antwoorden door te verzinnen. Ze bewegen in spanning en je moet ze samen in het oog houden.
Wat deze configuratie niet oplost
Volledige transparantie: zelfs met alles hierboven goed opgezet blijven er resterende hallucinaties. De gevallen die het slechtst te beheersen zijn, zijn hallucinaties van redenering bij vragen die meerdere opeenvolgende stappen vereisen, die ontstaan uit ambigue opgehaalde context (documenten die elkaar tegenspreken) en die opduiken wanneer de gebruiker het model blijft duwen met hardnekkige valse premissen. In gereguleerde domeinen (gezondheid, juridisch, financieel) vervangt geen enkele configuratie menselijke beoordeling; het systeem kan assisteren, maar de verantwoordelijkheid voor de uiteindelijke bewering is niet delegeerbaar aan het model.
De realistische verwachting is niet nul hallucinaties, maar hallucinaties die gedetecteerd worden voordat ze schade aanrichten, met een systeem dat weet wanneer het moet zwijgen. Dat is de configuratie die je kunt verdedigen tegenover een klant of een auditor.