Hur jag testar hallucinationer systematiskt
Det är lätt att hitta en hallucination genom att chatta med en modell tills den säger något dumt. Det är mycket svårare att veta om systemet hallucinerar mindre efter en förändring. För det behöver jag ett återkörbart test, inte magkänsla.
Det är lätt att hitta en hallucination genom att chatta med en modell tills den säger något dumt. Det är mycket svårare att veta om systemet hallucinerar mindre efter en förändring. För det behöver jag ett återkörbart test, inte magkänsla. Jag försöker därför göra hallucination till en uppsättning observerbara feltyper.
Börja med feldefinitionen
"Hallucination" används ofta som samlingsord för allt som är fel. Jag delar hellre upp det:
- påhittat faktapåstående,
- påhittad källa,
- påhittad first-hand-erfarenhet,
- felaktig extrapolering från en riktig källa,
- för stark säkerhetsgrad,
- svar trots att nödvändigt underlag saknas,
- sammanblandning av två entiteter eller versioner.
Det spelar roll eftersom lösningen kan skilja sig. En fabricerad URL är inte samma fel som att korrekt källa används men ett undantag tappas bort.
Bygg golden cases från riktiga misslyckanden
Jag vill att eval-setet kommer från verkliga problem. Om en investeringsagent tidigare försökte bedöma ett case utan aktuell kursdata blir det ett testfall. Om en CV-agent lade till en kompetens som inte stod i CV:t blir det ett annat. Om en writer skrev ett first-person-påstående utan FH-underlag blir det ett tredje.
Ett testfall kan vara enkelt:
Sedan kör jag samma fall mot ny prompt, ny modell eller ny pipeline.
Testa abstention separat
En modell som alltid svarar kan se hjälpsam ut men vara farlig. Därför mäter jag om systemet avstår när det ska. Jag använder explicita utfall som UNRESOLVED, BLOCKED, NOT READY eller KAN INTE BEDÖMA. Ett test ska kunna kräva ett sådant utfall.
Det gör två fel mätbara:
Båda är viktiga. Ett överförsiktigt system kan vara lika oanvändbart som ett övermodigt.
Gradera claims, inte bara hela svaret
På faktatunga uppgifter vill jag bryta ned svaret i materiella claims. Varje claim får status ungefär SUPPORTED, QUALIFIED, UNSUPPORTED eller CONTRADICTED. Det ger bättre signal än "svar 7/10". En lång text kan vara 95 procent korrekt men innehålla ett enda felaktigt belopp som gör artikeln opublicerbar.
Lägg in adversariala luckor
Bra testdata ska inte bara innehålla rena frågor. Jag lägger med fall där:
- en källa saknas,
- två källor motsäger varandra,
- input innehåller ett lockande men obekräftat tal,
- användaren ber modellen "bara uppskatta",
- en gammal modell/version nämns som om den vore aktuell,
- filnamn antyder något som innehållet inte stödjer.
Det här testar om modellen undersöker underlaget eller bara fortsätter berättelsen. Anthropics aktuella promptguidance använder samma grundidé för kod: modellen ska undersöka relevanta filer innan den gör påståenden om kod den inte har läst. Jag generaliserar den principen: inga materiella claims om underlag som systemet inte faktiskt har öppnat eller verifierat.
Kör regression efter varje systemförändring
När jag ändrar prompt, modell, tool permissions eller retrieval vill jag köra samma eval-set igen. OpenAI:s eval-ramverk bygger på just detta: definiera testdata, kriterier och graders och jämför systemvarianter systematiskt. Jag vill åtminstone följa:
Totalpoängen är mindre viktig än att jag ser vilken feltyp som förbättrades eller försämrades.
Produktionsfel ska tillbaka till eval-setet
Det viktigaste steget är feedbackloopen. När ett nytt verkligt fel hittas blir det ett nytt testfall. Då kan exakt samma regression inte smyga tillbaka tre versioner senare. Det är så jag försöker gå från "modellen verkar bättre" till något mer ingenjörsmässigt: ett växande bibliotek av saker systemet bevisligen har gjort fel och inte får börja göra igen.
Relaterade artiklar
- Så designar jag en AI-driven investeringsanalys utan att låta LLM:n hitta på siffror
- Så sätter jag guardrails runt AI utan att döda användarupplevelsen
- Så bygger jag golden datasets för mina egna AI-evals
- Vad jag lärde mig av att bygga CVpiloten
- Så prioriterar jag feltyper innan jag optimerar en AI-agent