AI-hallucinaties opvangen: 3 vangrails voor B2B-teams

Hoe AI-hallucinaties eruitzien in echte B2B-workflows

Een hallucinatie is wanneer het model een zelfverzekerd klinkend maar fout antwoord geeft. In B2B duikt dit op in drie klassieke vormen: (1) een niet-bestaand ordernummer verzinnen voor een supportvraag, (2) bij het samenvatten "citeren" uit een datum die helemaal niet in het contract staat, (3) een nieuwe categorie verzinnen bij het classificeren van facturen buiten de gedefinieerde set.

Alle drie volgen hetzelfde patroon: zonder echt anker vult het model het gat. Het probleem is dat de output overtuigend lijkt — zelfs als die fout is. "De AI heeft het mis" is niet actionable; je moet weten waar en waarom. De drie vangrails hieronder doen dat.

Drie vangrails: bron, regel, mens

1) Broncitatie: het model retourneert elk antwoord met de id of regelnummer van het bronndocument. Geen bron → "ik weet het niet". Hallucinaties dalen ~80%.

2) Regel-vooraf-check: valideer de output tegen domeinregels vóórdat hij landt — heeft het ordernummer 8 cijfers? Staat de factuurcategorie op de lijst? Is het datumformaat geldig? Deze goedkope Python-checks vangen de meeste hallucinaties.

3) Menselijke voorgoedkeuring: risicovolle acties (terugbetalingen, contractondertekening) worden door AI voorgesteld en door een mens goedgekeurd. AI doet ~95% zelf; de 5% uitzonderingen komen bij u voor review.

De drie samen: in onafhankelijke audits zakt het hallucinatiepercentage onder 2%.

Een evaluatieproces opzetten voordat u live gaat

U kunt een hallucinatiepercentage niet vaststellen door output met het blote oog te beoordelen; u heeft een testset nodig. Bouw een gouden set van 50 tot 200 echte voorbeelden met bekende, correcte antwoorden, en zorg dat deze randgevallen dekt — ontbrekende data, dubbelzinnige vragen, verzoeken buiten de scope. Test het model hiertegen vóór elke wijziging van prompt of model, niet alleen bij de lancering.

Houd twee afzonderlijke cijfers bij: nauwkeurigheid (kreeg het model het juiste antwoord) en onthoudingspercentage (zei het model terecht "ik weet het niet" wanneer dat aan de orde was). Een model dat nooit onthouding toepast, oogt zelfverzekerd maar is riskanter; een model dat te vaak onthoudt, is vervelend maar veiliger. De juiste drempel hangt af van hoe kostbaar een fout antwoord is in vergelijking met een doorgeschoven antwoord.

Adversarial testing is net zo belangrijk als testen van normale gevallen — voed het model bewust met vragen die zijn ontworpen om hallucinatie uit te lokken: vragen over entiteiten die niet bestaan, verzoeken die twee records door elkaar mengen, prompts die vragen om te extrapoleren voorbij het brondocument. Als het model in een gecontroleerde test niet gracieus kan falen, zal het dat in productie ook niet doen.

Behandel dit als een levende pijplijn, niet als een eenmalige poortcontrole. Elke keer dat u de prompt wijzigt, van model wisselt, of een nieuwe documentbron toevoegt, draait u de evaluatieset opnieuw en vergelijkt u de nieuwe nauwkeurigheids- en onthoudingscijfers met uw uitgangswaarde voordat u implementeert. Het is dezelfde discipline als regressietesten in traditionele software — alleen test het hier beoordelingsvermogen in plaats van logica.

Welke taken het grootste hallucinatierisico met zich meebrengen

Niet elke AI-taak brengt hetzelfde risico met zich mee, dus uw budget voor waarborgen hoeft ook niet gelijk verdeeld te worden. Open generatie — een klant-e-mail opstellen, een vergadering samenvatten, marketingteksten schrijven — laat ruimte voor creativiteit, maar precies in die ruimte schuilt hallucinatie: verzonnen statistieken, bedachte citaten, beloftes die het bedrijf nooit heeft gedaan. Dit is de categorie met het hoogste risico, omdat er geen vaste "juiste" output is om tegen te toetsen, alleen een reeks aanvaardbare uitkomsten.

Numerieke en financiële extractie staat vlak daarachter. Een totaalbedrag uit een factuur halen, een korting berekenen, een btw- of fiscaal nummer extraheren — fouten hierin zijn stil (het getal oogt aannemelijk) en kostbaar (het voedt rechtstreeks geldstromen). Juridische en medisch-getinte claims — contractuele verplichtingen, compliance-uitspraken, dosering of veiligheidsformuleringen — horen in dezelfde hoogrisicocategorie thuis: één keer een fout en de resulterende schade is geen gêne, maar aansprakelijkheid.

Aan het andere uiteinde is gestructureerde extractie tegen een vast schema — dit cv verwerken tot naam/e-mail/vaardigheden, dit ticket classificeren in een van de 12 categorieën, deze transactie taggen met een handelaarscode — vergelijkenderwijs laagrisico. Het model heeft minder ruimte om te verzinnen omdat de outputruimte beperkt is en eenvoudig mechanisch te valideren: u kunt controleren of de categorie bestaat, of het e-mailadres een @-teken bevat, of de waarde een van de 12 opties is. Classificatie in een kleine, gesloten set gedraagt zich op dezelfde manier — zelfs als het model fout zit, faalt het binnen de grenzen die u heeft gedefinieerd, wat een fundamenteel goedkoper faalmechanisme is.

Gebruik dit spectrum om te bepalen waar u inspanning voor waarborgen inzet. Laagrisicotaken met een gesloten schema kunnen vaak volstaan met lichte validatie en steekproeven. Hoogrisicotaken die open, numeriek of juridisch van aard zijn, verdienen de volledige aanpak uit de vorige sectie — brongebaseerde verantwoording, regelcontroles en een mens in de lus — voordat u de automatisering een klant of een grootboek laat raken.