Omgaan met hallucinaties in een productiesysteem
Waarom taalmodellen dingen verzinnen, welke ontwerpregels dat beheersbaar houden, en hoe u merkt dat uw systeem achteruitgaat voordat een klant het merkt.
7 min leestijd
Een model dat negenennegentig vragen goed beantwoordt en de honderdste verzint, is geen systeem met een klein mankement. Het is een systeem waarvan de uitvoer zonder controle niet te vertrouwen is, en dat verandert waar u het veilig voor kunt zetten.
Het goede nieuws is dat dit een technisch vraagstuk is met bekende antwoorden. U schaft hallucinatie niet af, u houdt hem binnen de perken, en dat beheersen is waar het meeste werk aan een AI-productiesysteem feitelijk uit bestaat.
Waarom het gebeurt, kort
Een taalmodel produceert het meest plausibele vervolg op de tekst die het heeft gekregen. Het heeft geen aparte feitenopslag om te raadplegen en geen intern signaal dat zegt "deze weet ik niet". Een zelfverzekerd fout antwoord en een zelfverzekerd goed antwoord komen uit precies hetzelfde proces rollen, en daarom zegt de toon u niets.
Daar volgen twee dingen uit. Een model vragen om zorgvuldiger te zijn helpt een beetje en is geen beheersmaatregel. Vlot geformuleerd is geen bewijs van juist, en elk proces dat erop leunt dat een lezer het verschil opmerkt, faalt op de dag dat die lezer haast heeft.
Zes regels die het werk doen
1. Laat het model nooit de bron zijn van een feit dat het kan opzoeken. Prijzen, voorwaarden, voorraad, openingstijden, contractbepalingen en klantgegevens horen in een bronsysteem. De taak van het model is de juiste passage vinden en het antwoord formuleren, met een verwijzing die de lezer kan openen. Levert het zoeken niets op, dan is "niets gevonden" de juiste uitvoer en niet een samenvatting van wat er waarschijnlijk in zo'n document zou staan.
2. Leg de vorm van de uitvoer vast. Voor alles dat machinaal verwerkt wordt, eist u een vast schema: gedefinieerde velden, vaste keuzelijsten en validatie op de uitgang. Een model dat uit acht categorieën moet kiezen, faalt op manieren die u kunt vangen. Een model dat de categorie mag beschrijven, faalt op manieren die u niet kunt vangen.
3. Maak "ik weet het niet" een volwaardig antwoord. Het moet toegestaan zijn, getest worden en ergens naartoe worden gestuurd. Een systeem zonder nooduitgang vult het gat, want gaten vullen is wat het onderliggende model doet.
4. Scheid opstellen van uitvoeren. Versturen, betalen, verwijderen, publiceren en vastleggen zijn onomkeerbaar. Zet daar ofwel een deterministische controle ofwel een mens tussen. Dit is het ene ontwerpbesluit dat het vaakst het verschil maakt tussen een systeem dat netjes faalt en een systeem dat in het openbaar faalt.
5. Controleer tegen de bron, niet tegen het model. Vraag het model niet of zijn antwoord klopte. Toets het uitgelezen totaal aan de rekensom, de geciteerde voorwaarde aan het document en het klantnummer aan de database. Zelfbeoordeling meet zekerheid, en zekerheid is nu juist het kapotte deel.
6. Meet het, anders gokt u. Bouw een set van vijftig tot honderd echte gevallen waarvan u het antwoord kent, en draai die opnieuw zodra de prompt, het model of het zoeken verandert. Log elke invoer en uitvoer, en controleer wekelijks een steekproef. Zonder dat komt niemand erachter dat de kwaliteit is gezakt, behalve een klant.
Voor een uitgewerkt voorbeeld van regel één, vier en vijf in een systeem dat geld raakt, ziet u hoe de controles werken bij geautomatiseerde factuurverwerking: de toets is een rekensom, de bron zijn uw eigen leveranciersgegevens, en het model mag nooit zelf akkoord geven.
Het scenario om voor ogen te houden
In 2024 deed een Canadees tribunaal uitspraak in een zaak tegen Air Canada, aangespannen door een passagier die het advies had gevolgd van de chatbot op de website over het achteraf aanvragen van een rouwtarief. Het advies klopte niet, de luchtvaartmaatschappij betoogde dat zij niet verantwoordelijk was voor wat de chatbot zei, en het tribunaal was het daar niet mee eens. De passagier kreeg een schadevergoeding toegewezen.
Het bedrag was klein. Het principe niet: een uitspraak die uw systeem tegen een klant doet, is een uitspraak van uw organisatie. Dat is de norm om tegen te ontwerpen, en die geldt net zo goed voor een offerte, een levertoezegging, een garantieantwoord of een samenvatting van uw voorwaarden.
Denk ook aan de interne variant. Een assistent beantwoordt een vraag over een korting die vorig kwartaal is verlopen, omdat de zoekindex de oude pagina nog bevat en niets heeft verteld welke versie actueel is. Niemand controleert het antwoord, want de vorige tweehonderd klopten. De kosten zitten niet in het foute antwoord. Ze zitten erin dat u nu moet uitzoeken welke andere antwoorden uit datzelfde verouderde document kwamen.
Wanneer een taalmodel niet het juiste gereedschap is
Is uw eis honderd procent juist en kan er tegen redelijke kosten geen mens tussen, dan wilt u geen taalmodel. Dan wilt u een formulier, een opzoektabel of een regelmotor. Deterministische systemen falen voorspelbaar, en voorspelbaar falen is een eigenschap zodra de inzet hoog is.
Sommige categorieën horen simpelweg buiten klantgerichte automatisering te blijven: medische, juridische en fiscale oordelen, beslissingen over krediet of toelating, en alles waarbij een fout antwoord niet te herstellen is met excuses. Bij de gereguleerde categorieën is een fout antwoord niet alleen duur, maar kan het u bovendien in een categorie plaatsen die de AI-verordening veel strenger behandelt.
De versie die een leverancier u niet vertelt: is het eerlijke antwoord op de vraag "wat gebeurt er als het fout is" dat niemand het zou merken, dan is beter prompten niet de oplossing. Dan is de oplossing een kleinere scope, met een mens op het punt waar het ertoe doet, en met de optie om het niet te bouwen nog gewoon op tafel.
Wat dit kost
Beheersen is niet gratis, en het is de moeite waard om vooraf te begroten. De testset moet geschreven en onderhouden worden, de beoordelingswachtrij kost iemand tijd, de verwijzingen moeten gebouwd worden en de zoekindex moet actueel blijven. Dat is gewoon techniek, en het is de reden dat een demo een middag kost en een productiesysteem niet.
Het is ook het deel van de rekening dat blijft lopen. Een systeem met evaluatie eraan vertelt u wanneer het achteruitgaat. Een systeem zonder evaluatie gaat even hard achteruit en vertelt het niemand. Die twee systemen hebben in jaar twee heel verschillende kosten, en dat is het eerlijke argument om naar drie jaar te kijken in plaats van naar één.
Deze discipline zit ingebouwd in de maatwerksystemen die wij opleveren, en de overige begrippen leggen de onderdelen eronder uit.
Veelgestelde vragen
Lost RAG het hallucineren op?
Nee, het vermindert het. Antwoorden baseren op uw eigen documenten haalt de meest voorkomende oorzaak weg, namelijk een model dat een gat opvult met wat het ooit heeft gelezen. Een model kan een passage nog steeds verkeerd lezen, twee bronnen door elkaar halen of antwoorden uit een verouderd document. Verwijzingen zijn belangrijk omdat een lezer ze kan controleren.
Lost een beter model dit op?
Betere modellen hallucineren minder vaak, en dat verhoogt de inzet in plaats van het probleem weg te nemen: zeldzame fouten worden minder gecontroleerd. De modelkeuze is een paar procentpunten waard. Ontwerpbesluiten over bronnen, uitvoervorm en de plek van de mens zijn aanzienlijk meer waard.
Hoe weten we of ons systeem achteruitgaat?
Houd een vaste set echte gevallen bij waarvan u het antwoord kent, en draai die opnieuw bij elke wijziging van prompt, model of zoekindex. Zonder stabiele testset zijn kwaliteitsveranderingen onzichtbaar, want het enige signaal zijn klachten, en klachten lopen weken achter.
Zijn wij aansprakelijk voor wat onze chatbot een klant vertelt?
Behandel alles wat hij zegt als een uitspraak van uw organisatie, want zo heeft een rechter het al behandeld. In de praktijk betekent dat: beperken wat hij mag beweren, die beweringen baseren op documenten die u beheert, en vastleggen wat er tegen wie is gezegd.