AI mest selvsikker når den tager fejl - eval

Opgaven i sagen lød enkel. Et system havde brug for at forklare årsagen bag driftshændelser, fejl i en pipeline eller afvigelser i et resultat, i naturligt sprog, til mennesker der skulle handle på forklaringen. En LLM fik til opgave at læse logdata og komme med en årsagsforklaring.

Den slags værktøjer bliver typisk vurderet ved, at nogen læser et udsnit af svarene og nikker eller ryster på hovedet. Det er kvalitativ gennemgang, og jeg har selv brugt den metode nok gange til at vide, hvad den fanger: tydelige fejl, sludder, åbenlyse selvmodsigelser. Den fanger derimod sjældent et mønster, der kun viser sig statistisk, når man sammenligner tusindvis af svar mod et facit, man faktisk kender.

Det var netop det, udvikleren gjorde anderledes. I stedet for at stole på stikprøver og fornemmelse blev der bygget et syntetisk datasæt, hvor den sande årsag til hver hændelse var kendt på forhånd. Modellen blev derefter bedt om at forklare de samme hændelser, og hvert svar blev holdt op mod facit, systematisk og i stor skala.

Med en evalueringsharness kan man måle to ting samtidig: om modellen har ret, og hvor sikker den selv siger, den er. Det er kombinationen, der gør forskellen. Uden det andet mål ligner et forkert, selvsikkert svar præcis et rigtigt, selvsikkert svar, når man bare læser det.

Harnessen kørte modellen igennem hundredvis af scenarier med kendt facit og loggede både nøjagtighed og modellens egen tillidsscore for hver forklaring. Det gjorde det muligt at se noget, ingen kvalitativ gennemgang ville have opdaget: en klar, negativ korrelation mellem, hvor sikker modellen lød, og hvor ofte den faktisk havde ret.

Jeg genkender fundet. Et velformuleret, selvsikkert forkert svar læses ofte som mere troværdigt end et korrekt svar, der er formuleret med forbehold. Det er præcis den slags fælde, jeg selv har siddet i, når jeg har bygget agenter, der skulle forklare deres egne beslutninger.

Mønsteret var ikke tilfældigt støj. Når modellen forklarede en hændelse forkert, brugte den ofte et sprog med mere bestemthed, færre forbehold og en klarere kausal fortælling end når den ramte rigtigt. De rigtige svar var, ironisk nok, oftere formuleret med en vis usikkerhed, fordi de sande årsager i virkeligheden ofte er sammensatte og ikke lader sig reducere til én ren linje.

Det giver god mening, når man tænker over, hvordan sprogmodeller genererer tekst. En model, der mangler et klart signal i data, fylder hullet med den mest sandsynlige, sammenhængende historie den kan konstruere. Den historie lyder ofte overbevisende, fordi den er bygget til at lyde overbevisende, ikke fordi den er korrekt. Når den derimod har et reelt signal at arbejde med, er virkeligheden sjældnere lige så ren, og sproget afspejler det.

For en organisation, der læner sig op ad AI-genererede forklaringer i incident-reviews eller kundesupport, er det her det farligste scenarie, der findes. Det er ikke de usikre, tøvende svar, der gør skade. Det er de skarpe, selvsikre, forkerte svar, som ingen tænker at dobbelttjekke, fordi de ikke lyder som noget, der kræver dobbelttjek.

Fejlraten var ikke jævnt fordelt. Modellen klarede sig markant dårligere i de scenarier, hvor flere plausible årsager overlappede, altså der, hvor to eller tre faktorer hver især kunne forklare en del af hændelsen, men hvor kun én eller en kombination var den reelle driver.

Det er præcis den type situation, mennesker også finder svær, men mennesker har typisk en indbygget bremse: usikkerhed. Vi siger "det kan være A eller B, det kræver mere undersøgelse". Modellen i testen gjorde det modsatte. Jo mere tvetydigt scenariet var, desto mere insisterede den på én, ren forklaring, formuleret med samme selvsikkerhed som i de entydige tilfælde.

Det peger på en strukturel svaghed, der ikke løses ved bedre prompt-formulering alene. Problemet sidder i, hvordan modellen håndterer flertydighed internt, ikke i, hvordan man spørger den. En bedre prompt kan bede modellen om at nævne alternative forklaringer, men det ændrer ikke ved, at dens indre tillidssignal er upålideligt netop dér, hvor det betyder mest.

Det er her fundet bliver relevant for enhver virksomhed, der overvejer at flytte et AI-forklaringsværktøj fra pilot til drift. En pilot, der er blevet valideret ved, at et par medarbejdere har læst svarene og syntes, de lød fornuftige, har ikke testet det, der faktisk betyder noget: om modellen har ret, når den er sikrest.

Jeg ser det samme mønster igen og igen, når jeg hjælper virksomheder med at gå fra proof of concept til drift. Den kvalitative gennemgang, der fik piloten til at se lovende ud, er sjældent bygget til at afsløre systematiske skævheder. Det kræver et facit at teste imod, en måde at måle tillid separat fra korrekthed, og nok volumen til at se mønstre, der ikke er synlige i tyve håndplukkede eksempler.

Mit praktiske svar er ikke at droppe AI-forklaringer. Det er at bygge evaluering ind som en fast del af driftssætningen, ikke som en engangsøvelse før lancering. Et syntetisk datasæt med kendt facit, løbende målt tillid mod nøjagtighed, og særlig opmærksomhed på de tvetydige scenarier, hvor modellen historisk klarer sig dårligst men lyder bedst. Den kombination er det, jeg har set adskille et værktøj, man kan stole på i drift, fra et, der bare lyder overbevisende i en demo.