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

Broncontrole: toon het document en de passage waarop het antwoord steunt; controleer of de passage de bewering onderbouwt. Alleen een verwijzing is niet genoeg. Ontbrekende of tegenstrijdige informatie gaat naar een beoordelaar.

Regelcontrole: verifieer in de applicatie of de order bestaat, de gebruiker bevoegd is en bedrag en categorie geldig zijn. Een geldig formaat bewijst geen juistheid.

Menselijke goedkeuring: vóór een betaling, terugbetaling of bindend bericht beoordeelt een bevoegde persoon de exacte uitvoer. Wijzigingen vragen nieuwe goedkeuring. Er is geen universeel succespercentage. Test juiste, onjuiste en onbewezen antwoorden: ongeldige uitvoer moet stoppen en de beoordelingswachtrij moet de verantwoordelijke bereiken.

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

Risico hangt niet alleen af van vrije of gestructureerde tekst. Een verkeerde boeking in een geldige categorie kan ook schade veroorzaken. Beoordeel impact, herstelbaarheid, gegevensgevoeligheid en ontvangers. Een conceptworkflow hoort niet dezelfde rechten te hebben als een workflow die klanten benadert of geld verplaatst.