Hallucination i LLM'er — Hvad det er og hvordan du håndterer det

Hallucination er en af de mest misforståede egenskaber ved LLM’er. Det er ikke et tegn på at modellen er “dum” eller “løgner”. Det er en matematisk konsekvens af hvad en sprogmodel gør: forudsige det næste token baseret på sandsynlighed. Og nogle gange er det sandsynligste næste token faktamæssigt forkert.

At forstå hallucination korrekt giver dig et bedre grundlag for at designe workflows der håndterer det intelligent — frem for at enten stole blindt på modellen eller afvise den som ubrugelig.

Hvad hallucination faktisk er

En LLM er ikke en database. Den har ikke “gemt” fakta i opslagsbar form — den har komprimerede statistiske mønstre fra træningsdata. Når du spørger om et specifikt faktum, genererer modellen det mest sandsynlige svar baseret på disse mønstre.

Det sandsynligste svar er normalt rigtigt. Men:

• For sjældne fakta er det statistiske signal svagt og fejlraten højere
• For modsatrettede fakta i træningsdata (f.eks. en person der har skiftet stilling flere gange) kan modellen blande dem
• For fakta der ændrer sig over tid, og som ligger efter trænings-cutoff, ved modellen ikke at den ikke ved det

Klassiske hallucination-mønstre:

Opfundne citater: Modellen genererer et citat fra en rigtig person der lyder plausibelt men ikke eksisterer.

Forkerte statistikker: “68% af brugere…” — et tal der ser ud som en rigtig statistik fra en rigtig undersøgelse, men er genereret.

Forkerte datoer og navne: Specifikt og faktarigt indhold med detaljer der er forkerte.

Confident uvidende: Modellen ved ikke hvad den ikke ved. Den siger ikke “det er jeg usikker på” — den fortsætter med samme selvtillid som for korrekt output.

Hallucination i SEO-konteksten

For SEO-arbejde er hallucination et praktisk problem i specifikke kontekster:

Statistikker og facts: Brug aldrig en LLM som kilde til statistikker du vil publicere. Modellen kan generere tal der ser officielle ud men ikke er verificerbare.

Person- og virksomhedsinformation: Specifikke detaljer om enkeltpersoner, virksomhedshistorik og produktdetaljer er hallucination-risiko-zoner.

Teknisk korrekthed: Når du beder en LLM om teknisk SEO-viden, kan den producere teknisk-lydende men forkerte svar. Verificér altid mod autoritative kilder.

Hvad det ikke er et problem for: Teksttransformation, struktur, format, tone, opsummering af materiale du har givet den som kontekst. Her er hallucination-risikoen minimal fordi modellen arbejder med verificeret materiale.

RAG som primær løsning

RAG (Retrieval-Augmented Generation) er den tekniske løsning på hallucination-problemet for faktabaserede use cases. I stedet for at stole på hvad modellen “husker”, retriever du dokumenter der indeholder den relevante information og sender dem som kontekst.

Konkret: du spørger “hvad er conversion rate for vores landingssider i Q1 2026?” Uden RAG gætter modellen. Med RAG: analytics-data retrieves og sendes som kontekst, og modellen svarer baseret på de faktiske tal.

RAG kræver infrastructure: en datakilde, et retrieval-system (vektordatabase eller traditionel søgning) og en pipeline der bringer data i kontekst. Det er ikke plug-and-play, men det er den korrekte løsning for faktaintensive use cases.

Praktiske mitigerings-strategier

Uden et fuldt RAG-system er der enklere strategier der reducerer hallucination-risiko:

Giv data, bed om analyse: Send de faktiske data og bed modellen om at analysere dem. Det er fundamentalt anderledes end at bede modellen om at huske fakta.

Bed om kildehenvisning: Bed modellen om at specificere hvorfra en information kommer. Det tvinger den til at kalibrere sin usikkerhed — og klare markeringer på “jeg er ikke sikker” er et signal.

Verifikationspass: I en to-trins workflow sender du først modellens output til en verifikationsrunde: “Identificer alle faktapåstande i denne tekst og vurder om de er verificerbare.” Ikke perfekt, men bedre end ingenting.

Temperaturstyring: Lavere temperature (0.0-0.3) giver mere forudsigelige, konservative svar. Relevant for faktabaserede opgaver. Højere temperature giver mere varieret output — godt til kreative opgaver, dårligt til fact-heavy indhold.

Design af hallucination-robuste workflows

Det vigtigste design-princip: adskil hvad modellen kan gøre pålideligt fra hvad den ikke kan.

Modellen kan pålideligt: transformere, strukturere, opsummere og analysere indhold du giver den. Det kan den ikke pålideligt: generere fakta, statistikker og specifikke detaljer fra sin træning uden ekstern grounding.

Byg workflows der matchet opgave til kapacitet. Brug LLM til transformation og analyse. Brug databaser, APIs og verificerede sources til fakta. Det er ikke en begrænsning — det er god systemdesign.