Wat is een AI-hallucinatie? Een zelfverzekerd maar onjuist antwoord. Waarom het gebeurt en hoe je het beperkt met bronnen, checks en evaluatie.
Een hallucinatie is een antwoord van een taalmodel dat vlot en overtuigend klinkt maar onjuist of verzonnen is: een bedacht artikel, een niet-bestaande afspraak, een regel die nergens staat. Het model signaleert niets. Er staat geen twijfel bij. Het is geen storing die je herstelt, maar een eigenschap van hoe taalmodellen werken, en je ontwerpt eromheen.
Een taalmodel is getraind om plausibele tekst voort te brengen, niet om waarheid te verifiëren. Vraag je iets waar het geen antwoord op heeft, dan produceert het meestal tóch een antwoord: het gaat door met voorspellen, in dezelfde vloeiende stijl als altijd. Wie erop vertrouwt dat onzekerheid herkenbaar is, merkt niets. En dat is precies wat dit soort fouten gevaarlijk maakt voor bedrijfsprocessen.
Beperken kan, wegnemen niet. De eerste rem is een bron: laat het model antwoorden uit jouw eigen documenten en vermeld waar elk antwoord vandaan komt. Zonder bron geen antwoord. De tweede rem is een instructie om te zeggen dat iets niet gevonden is, en die instructie ook echt te testen op lastige vragen. De derde rem is een mens of een controle op de momenten dat een fout duur is: verzending, betaling, juridische tekst.
De praktische les zit niet in de techniek maar in de taakkeuze. Gebruik een model waar fouten te vangen zijn en waar een controleur kijkt; gebruik het niet als enige rechter bij beslissingen met gevolgen. Elke werkstroom die we bouwen begint daarom met de vraag: wat gebeurt er als dit antwoord fout is, en wie merkt het?
Vertrouwen kan in taken waar het model op eigen kennis en tekstvaardigheid draait en een mens het resultaat ziet: samenvatten, herschrijven, concepten opstellen, tekst classificeren met voorbeelden erbij. Daar is een afwijking vervelend maar te vangen, en de tijdwinst overtreft de nazorg ruimschoots. Met een bronverplichting en een testset wordt het betrouwbaarheidsbereik nog ruimer.
Niet vertrouwen doe je waar een fout ongezien het bedrijf uitgaat: een antwoord aan een klant zonder mens ertussen, een berekening, een juridische of medische uitspraak, alles wat over personen oordeelt. Daar hoort óf een controle voor verzending, óf het antwoord wordt doorgezet naar iemand met de juiste kennis. Wie dit soort taken volledig automatiseert zonder vangnet, automatisert niet maar gokt. Met zijn reputatie als inzet.
We behandelen het niet als stigma maar als ontwerpeis: elke toepassing krijgt een bronverplichting waar dat kan, een instructie om 'niet gevonden' te mogen zeggen, en een doorzetting naar een mens bij twijfel. Vóór livegang draait een testset met lastige vragen, inclusief vragen waar het eerlijke antwoord luidt: dat weten we niet. Zo weet je bij oplevering hoe de toepassing zich gedraagt als het model het niet weet. Niet pas bij de eerste klacht.
Omdat het model is gebouwd om tekst voort te zetten, niet om te beslissen of iets waar is. Geen antwoord geven is geen optie die het model vanzelf kiest; het vervolgt de zin in dezelfde overtuigende stijl, ook als zijn kennis opraakt. Daarom werkt 'vraag gewoon netjes' als remedie slecht, en werkt een omgeving met bronnen, een expliciete toestemming om onbekendheid toe te geven, en controles erachter wél. De oplossing zit in het ontwerp, nooit in de hoffelijkheid van de vraag.
Alles waar een fout ongezien buiten de deur is of iemand er nadeel van ondervindt: antwoorden naar klanten, contract- en medische tekst, berekeningen die geld raken, beslissingen over personen. Daar staat óf een mens tussen die het resultaat beoordeelt, óf een technische controle op vaste regels. Wat juist wél kan: de voorbereiding van dat werk. Samenvatten, sorteren, concepten klaarzetten. De regel is simpel: het model stelt voor, iemand met verantwoordelijkheid beslist.
Nee, en wie dat belooft verkoopt iets dat niet bestaat. Nieuwere modellen maken minder fouten en beter aangeklede toepassingen vangen meer af, maar de eigenschap blijft in meer of mindere mate aanwezig, en nieuwe modellen brengen soms oude fouten terug. De betrouwbare strategie is daarom niet hopen op een foutloos model, maar een opzet bouwen waarin fouten gezien worden: bronnen, tests, en een mens op de momenten dat het ertoe doet.
Met een testset van echte vragen uit jouw praktijk, waarvan de goede antwoorden vaststaan. Die draaien we vóór livegang en na elke wijziging, zodat betrouwbaarheid in cijfers zichtbaar is in plaats van een gevoel. Ook de lastige gevallen zitten erin: vragen zonder antwoord, tegenstrijdige bronnen, verwarrende formuleringen. Pas als de toepassing die netjes afvangt (met een eerlijk 'weet ik niet') noemen we hem klaar voor productie.
EIGHTY8