Hallucinationer og bias forklaret uden teknisk jargon

Et AI-svar kan være grammatisk sikkert og faktuelt forkert. Det kan også være faktuelt korrekt, men systematisk skævt. Eller det kan gengive noget, der engang var rigtigt, men ikke længere gælder. De tre fejl ser ens ud i en pæn tekstboks, men de har forskellige årsager og kræver forskellige kontroller.

Den vigtigste vane er derfor ikke at spørge modellen, om den er sikker. Det er at gøre påstandene synlige, koble dem til originale kilder og beslutte på forhånd, hvornår et menneske skal stoppe eller eskalere opgaven. Denne artikel giver en arbejdsgang til netop det.

Tre fejltyper i almindeligt sprog

Hallucination: en påstand uden tilstrækkeligt belæg

En sprogmodel producerer tekst ved at beregne sandsynlige fortsættelser ud fra mønstre og den kontekst, den får. Den har ikke automatisk en indbygget faktatjekker, der standser hver sætning og spørger, om verden er sådan. Når et navn, tal, citat eller en kilde passer sprogligt ind, kan modellen skrive det, selv om belægget mangler.

»Hallucination« er et populært ord, men »ubegrundet eller forkert påstand« er ofte mere nyttigt i en arbejdsgang. Det flytter fokus fra en forestilling om, hvad modellen »oplever«, til det, organisationen kan kontrollere: Findes kilden? Understøtter den påstanden? Er forbehold og modstridende information gengivet?

En søge- eller dokumentfunktion kan reducere nogle fejl ved at give modellen relevante tekster. Den garanterer ikke korrekthed. Modellen kan citere det forkerte sted, blande to dokumenter, overse en undtagelse eller skrive mere, end kilden bærer. Derfor skal den vigtige påstand stadig kontrolleres mod materialet.

Bias: et mønster, der systematisk favoriserer eller skader

Bias er ikke bare en enkelt forkert detalje. Det er en systematisk skævhed i data, design, opgaveformulering, måling, udrulning eller menneskelig brug. Et værktøj kan for eksempel stille forskellige forventninger til sammenlignelige personer, udelade bestemte perspektiver eller fungere dårligere for sprog og grupper, der er svagt repræsenteret i udvikling og test.

Skævheden behøver ikke komme fra modellen alene. Et historisk datasæt kan afspejle tidligere forskelsbehandling. En prompt kan indeholde en skjult antagelse. En bedømmer kan acceptere AI-output mere ukritisk, når det bekræfter en forventning. Og en ens gennemsnitsnøjagtighed kan skjule store forskelle mellem relevante undergrupper.

Original forskning som BBQ-benchmarken viser, hvordan sprogmodeller i underbestemte spørgsmål kan læne sig mod sociale stereotyper. Benchmarken er udviklet til en amerikansk-engelsk kontekst og kan ikke bare kopieres som dansk facit. Det illustrerer en vigtig metodepointe: Bias skal testes i den konkrete sprog-, kultur- og anvendelseskontekst.

Forældet viden: korrekt før, forkert nu

En dato, leder, pris, lovregel eller produktfunktion kan have ændret sig siden modellens træningsdata, den tilsluttede søgning eller organisationens dokumenter blev opdateret. Det er ikke nødvendigvis en hallucination i snæver forstand. Fejlen ligger i aktualiteten eller versionsstyringen.

Kontrollen er derfor en anden: Sæt en »gyldig pr.«-dato på svaret, brug den gældende originalkilde, og kontrollér dokumentversionen. Et ældre officielt dokument kan være autentisk og stadig være forkert grundlag for dagens beslutning.

Hvorfor et selvsikkert svar ikke er et bevis

Modellen kan formulere både sikkerhed og usikkerhed som tekst. »Jeg er 95 procent sikker« er ikke en kalibreret måling, medmindre den konkrete løsning er dokumenteret og evalueret til at levere en sådan sandsynlighed for den konkrete opgave. At bede om kilder er nyttigt, fordi kontrollen bliver mulig, men en genereret litteraturliste kan selv indeholde opdigtede eller irrelevante henvisninger.

Forskning som TruthfulQA og NISTs profil for generativ AI dokumenterer, at sandhed, informationsintegritet, confabulation og automation bias skal måles og håndteres; de følger ikke automatisk af et mere flydende svar. Resultater fra et bestemt benchmark er ikke en permanent rangliste over alle nutidige modeller. De viser, hvorfor lokale test og kildekontrol er nødvendige.

Arbejdsgangen: fra påstand til kilde

1. Del outputtet i kontrollerbare påstande

Markér alt, der kan være sandt eller falsk: navne, datoer, tal, årsager, citater, regler, sammenligninger og anbefalinger, der bygger på fakta. En lang sætning kan indeholde fire påstande. Del den op, så én korrekt del ikke skjuler en forkert.

Skeln mellem fakta, vurdering og forslag. »Bekendtgørelsen trådte i kraft den 1. juli« er en faktapåstand. »Reglen er vanskelig at bruge« er en vurdering. »Vi bør ændre formularen« er et forslag, som kræver både fakta og et valg. De skal ikke kontrolleres på samme måde.

2. Giv hver påstand et risikoniveau

• Lav konsekvens: intern idé eller formulering, som let kan ændres, og som ikke påvirker en person.
• Mellem konsekvens: offentlig tekst, kundekommunikation, undervisningsmateriale eller beslutningsoplæg.
• Høj konsekvens: helbred, sikkerhed, jura, økonomi, rettigheder, ansættelse eller en vurdering af et konkret menneske.

Risikoniveauet bestemmer kildekravet og kontrollens omfang. En idé til en overskrift kræver ikke samme dokumentation som en påstand om en borgers rettigheder. Men et lavrisikoudkast kan blive højrisiko, når det kopieres ind i et brev eller en afgørelse. Vurdér den endelige anvendelse, ikke kun prompten.

3. Definér en acceptabel kilde før søgningen

Vælg kildehierarki efter emnet: gældende retsakt og myndighedsvejledning til en regel; original artikel og datasæt til et forskningsresultat; årsrapport eller register til et virksomhedstal; organisationens godkendte procedure til en intern arbejdsgang. En søgemaskines uddrag, en chatbot-citation eller en artikel, der refererer en anden artikel, er en vejviser – ikke nødvendigvis dokumentationen.

4. Åbn originalen og find det bærende sted

Kontrollér titel, afsender, dato, version og gyldighed. Find derefter det konkrete afsnit, tabelgrundlag eller datasæt, der understøtter påstanden. Læs omkring citatet, så undtagelser, målgruppe og metode kommer med. Hvis du ikke kan pege på stedet, er påstanden ikke verificeret.

Kontrollér også om kilden siger mindre end AI-svaret. »Kan være forbundet med« må ikke blive til »fører til«. Et studie i én population må ikke blive til en universel sandhed. En myndighedsanbefaling må ikke omtales som et lovkrav. Kildekontrol handler lige så meget om rækkevidde som om eksistens.

5. Registrér resultatet

Markér påstanden som understøttet, delvist understøttet, modstridt eller uafklaret. Gem URL, dokumentversion, dato og eventuelt side eller afsnit. Omskriv eller fjern det, kilden ikke bærer. Ved modstridende autoritative kilder skal forskellen fremgå; modellen skal ikke vælge den mest bekvemme i stilhed.

Et eksempel på en påstandskontrol

Tænkt eksempel: En kommunikationsmedarbejder beder et AI-værktøj resumere et nyt regelsæt. Outputtet siger, at reglerne »gælder alle virksomheder fra 1. januar«, at en bestemt myndighed fører tilsyn, og at manglende efterlevelse altid giver en fast bøde.

Medarbejderen deler teksten i mindst fire påstande: målgruppe, startdato, tilsynsmyndighed og sanktion. Den gældende retsakt og myndighedens implementeringsside åbnes. Det viser sig, at datoen afhænger af anvendelsen, at flere myndigheder kan have roller, og at sanktionen er en maksimumsramme med betingelser – ikke en automatisk fast bøde. Resuméet omskrives, og links indsættes ved de konkrete påstande.

Fejlen opdages ikke ved at stille samme spørgsmål igen. Den opdages ved at gøre påstandene mindre og sammenholde dem med originalkilder. Samme metode kan bruges på en rapport, et mødereferat eller en produktbeskrivelse.

Sådan bygger I en lokal evalueringsprøve

En generel leverandørbenchmark fortæller ikke, hvordan jeres dokumenter, sprog og fejlkonsekvenser ser ud. Lav derfor en lille, risikostyret prøve før udrulning og gentag den, når model, prompt, datakilde eller arbejdsgang ændres.

1. Saml virkelighedsnære opgaver uden at bruge persondata eller fortroligt materiale unødigt. Medtag almindelige tilfælde, grænsetilfælde og de fejl, der vil være dyrest.
2. Lav et godkendt facit eller klare vurderingskriterier fra originale kilder, før AI-svarene bedømmes.
3. Mål særskilt: faktuelle fejl, manglende oplysninger, forkerte kilder, forældet viden, skævhed, afvisninger og variation mellem gentagelser.
4. Del resultater på relevante undergrupper og opgavetyper. Et gennemsnit kan skjule, at én vigtig type fejler.
5. Lad mindst én fagperson bedømme blindt i forhold til, om svaret kommer fra AI, når det er praktisk, og dobbeltbedøm en delmængde for at se, om kriterierne forstås ens.
6. Fastlæg tærskler og stopregler før resultatet ses. Ellers bliver det let at acceptere den fejlrate, værktøjet tilfældigvis leverer.

Tredive velvalgte opgaver kan være en praktisk første prøve, men tallet er ikke en certificeringsgrænse og kan være utilstrækkeligt til sjældne eller alvorlige fejl. Højrisikoanvendelser kræver mere omfattende, repræsentativ og løbende evaluering. Dokumentér modelversion, indstillinger, datakilder og dato, så en senere test kan sammenlignes meningsfuldt.

Bias-test uden symbolsk navnebytning

At skifte ét navn i en prompt kan være en hurtig sondering, men det er ikke en fuld fairness-vurdering. Begynd med at definere den skade, I vil opdage: dårligere service, forskellig tone, forkert prioritering, udeladelse eller systematisk fejl. Vælg derefter relevante grupper og sammenlignelige tilfælde ud fra den konkrete anvendelse og gældende krav.

Test både tvetydige og tydelige eksempler, flere formuleringer og realistiske sprogvariationer. Se på forskelle i fejl, anbefaling, begrundelse og afvisning – ikke kun på gennemsnitlig nøjagtighed. Inddrag faglig og berørt viden, når testen designes. En teknisk test kan vise et mønster; den afgør ikke alene, om anvendelsen er retfærdig eller lovlig.

Stop- og eskaleringsregler

• Stop outputtet: En bærende påstand mangler originalkilde, en citation findes ikke, eller kilden siger noget andet.
• Eskalér fagligt: Autoritative kilder er uenige, dokumentet er udløbet, eller spørgsmålet kræver fortolkning uden for kontrollørens kompetence.
• Stop automatiseringen: En fejl kan direkte påvirke helbred, sikkerhed, rettigheder, ansættelse eller økonomi, og der findes ikke en reel menneskelig kontrol før virkning.
• Pause udrulningen: Evalueringsprøven overskrider de aftalte fejltærskler, viser væsentlige gruppeskævheder eller kan ikke gentages efter en modelændring.
• Eskalér sikkerhed og databeskyttelse: Outputtet afslører data, som ikke burde være tilgængelige, eller arbejdsgangen kræver oplysninger, der ikke er vurderet og godkendt.

En stopregel skal beskrive både udløser og næste skridt. »Brug sund fornuft« fordeler ikke ansvar. »Ved manglende primærkilde må teksten ikke publiceres; fagansvarlig afgør, om påstanden fjernes eller undersøges« kan bruges i praksis.

En enkel ansvarsmatrix

• Opgaveejer: beskriver formål, anvendelse, fejlkonsekvens og acceptkriterier.
• Kildeejer eller fagansvarlig: udpeger gældende originalkilder og afgør faglige konflikter.
• Kontrollør: gennemgår påstande efter den aftalte metode og dokumenterer afvigelser; bør ikke være presset til blot at godkende.
• Systemejer: registrerer model, version, adgang, ændringer, logning og evalueringsresultater.
• Risiko-, sikkerheds- og databeskyttelsesfunktion: inddrages efter anvendelse og risiko, ikke som en ceremoniel underskrift til sidst.
• Beslutningstager: ejer den endelige handling og kan forklare, hvorfor outputtet blev brugt eller afvist.

Rollerne kan ligge hos få personer i en lille organisation, men de må ikke forsvinde. Den, der skriver prompten, kan ikke automatisk godkende sin egen kildekontrol ved en højkonsekvensopgave.

Vælg opgaver efter fejlens pris

AI er mest håndterbar, når outputtet er et reversibelt udkast, fejl er synlige, kilder er tilgængelige, og et menneske har reel tid til kontrol. Den er sværere at forsvare, når informationen er skjult, konsekvensen er høj, og modtageren ikke kan anfægte resultatet. Guiden Hvad AI ikke kan hjælper med at afgrænse arbejdsdelingen.

Hvis I vil skabe et fælles sprog for kildekontrol og ansvar, kan foredraget Kan man stole på AI? bruges som start. Undervisere kan også se kurset om AI i undervisningen, hvor elevens egen tænkning og kontrol står centralt.

Konklusion: Et AI-output bliver ikke pålideligt af at lyde sikkert eller have fodnoter. Pålideligheden kommer fra en synlig kæde: påstand, risikoniveau, originalkilde, kontrolresultat, ansvarlig person og stopregel. Den kæde gør også bias og forældet viden lettere at opdage, fordi fejlene ikke længere gemmer sig i flydende tekst.

Kilder og videre læsning

• NIST: Generative AI Profile til AI Risk Management Framework, herunder confabulation, harmful bias, automation bias og informationsintegritet.
• Lin, Hilton og Evans: TruthfulQA – originalt benchmarkstudie af modellers sandfærdighed.
• Parrish m.fl.: BBQ – originalt benchmarkstudie af social bias i question answering.
• Bouyamourn: Why LLMs Hallucinate, and How to Get Evidential Closure.