ktg-plugin-marketplace/plugins/ms-ai-architect/skills/ms-ai-engineering/references/rag-architecture/rag-hallucination-mitigation.md

RAG Hallucination Mitigation Strategies

Last updated: 2026-04 | Verified: MCP 2026-04 Status: GA Category: RAG Architecture & Semantic Search

---

Introduksjon

Hallusinasjoner — når en LLM genererer informasjon som er faktuelt feil eller ikke støttet av kildedataene — er en av de største utfordringene ved bruk av generative AI-modeller i produksjon. I RAG-systemer er målet å redusere hallusinasjoner ved å forankre modellens svar i faktiske dokumenter (grounding), men dette krever strukturerte teknikker for å sikre at modellen faktisk benytter kildematerialet korrekt.

Microsoft tilbyr flere lag med hallucination mitigation strategies på tvers av Azure AI-stakken, inkludert Azure AI Content Safety Groundedness Detection API, prompt engineering-teknikker, confidence scoring, og arkitektoniske mønstre for fact-checking og citation-backed responses. Disse teknikkene kan kombineres i et lagdelt forsvar som reduserer risikoen for at systemet genererer feilinformasjon.

En sentralt prinsipp er at hallusinasjoner ikke kan elimineres fullstendig — selv med grounding kan modellen feiltolke kilder eller konstruere svar som ikke er tilstrekkelig støttet. Derfor må man kombinere flere teknikker: grounding via RAG, groundedness detection via Content Safety, prompt engineering for å be om kildehenvisninger, og systematisk validering av output.

Kjernekomponenter

1. Grounding via RAG

RAG (Retrieval-Augmented Generation) er den primære teknikken for å redusere hallusinasjoner ved å gi modellen faktiske dokumenter som kontekst. Nøkkelprinsippet: modellen skal svare basert på hentet data, ikke kun sin trente kunnskap.

• Grounding sources: Dokumenter, metadata, eller strukturert data som sendes til modellen som del av promptet
• Strictness-parameter: I Azure OpenAI On Your Data kan du sette "strictness" for å kontrollere hvor strengt modellen skal holde seg til kildene
• "Limit responses to data content": Tvinger modellen til å kun svare basert på hentet data, ikke generell kunnskap

2. Groundedness Detection (Azure AI Content Safety)

Groundedness Detection API analyserer om en LLM-respons faktisk er forankret i de oppgitte kildene. Dette er en post-generation validation-teknikk.

Modus	Beskrivelse	Bruksområde
Non-Reasoning	Rask deteksjon, returnerer score uten forklaring	Sanntids-validering, lav latency-krav
Reasoning	Detaljert forklaring av ungrounded segments	Debugging, testing, forståelse av feilmønstre
Correction	Auto-korrigering av ungrounded tekst basert på kilder	Automatisk retting før output vises til bruker

Nøkkel-APIer:

• domain: MEDICAL eller GENERIC (påvirker sensitivitet)
• task: QnA eller Summarization (justerer deteksjonslogikk)
• groundingSources: Array av kildedokumenter
• reasoning: true/false for å få detaljert forklaring
• correction: true for auto-korrigering (krever Azure OpenAI GPT-4o)

3. Prompt Engineering for Grounding

Prompt design er kritisk for å redusere hallusinasjoner:

• Explicit grounding instructions: "Answer exclusively from the provided sources. If the answer is not found, say 'I don't know'."
• Citation requirements: Be modellen om å inkludere kildehenvisninger for hvert faktuelt påstand
• Output structure: Spesifiser format som tvinger modellen til å koble svar til kilder (f.eks. "CLAIM: [tekst] | SOURCE: [URL]")
• Refusal mechanism: Tillat modellen å si "I don't know" eller "not found in sources" i stedet for å gjette

4. Confidence Scoring og Refusal Thresholds

Modeller kan estimere sin egen konfidensgrad for svar, og systemet kan avvise svar under en viss terskel.

• Threshold-basert refusal: Hvis modellen er under X% sikker, returner "I cannot answer with confidence based on the provided data"
• Per-claim confidence: Vurder hvert faktisk påstand individuelt, ikke bare hele svaret
• User feedback loops: La brukere rapportere feil svar for å justere thresholds over tid

5. Multi-Step Verification (Chain-of-Thought + Fact-Checking)

I stedet for å generere svar direkte, bryt ned oppgaven i flere steg:

1. Ekstraher faktiske påstander fra brukerens spørsmål
2. Søk etter relevante dokumenter for hver påstand
3. Verifiser hver påstand mot kildematerialet
4. Kombiner verifiserte fakta til et svar
5. Generer kildehenvisninger for hvert punkt

Dette reduserer risikoen for compound errors (flere feil i samme svar).

Arkitekturmønstre

Mønster 1: Pre-Generation Grounding (Standard RAG)

Beskrivelse: Hent relevante dokumenter før generering, send dem som kontekst til modellen, instruer modellen til å kun svare basert på disse kildene.

Fordeler:

• Enklest å implementere
• Lavest latency (ett kall til LLM)
• Fungerer med alle modeller

Ulemper:

• Ingen garanti for at modellen faktisk bruker kildene
• Vanskelig å detektere hallusinasjoner uten post-validation
• Modellen kan velge å ignorere grounding hvis prompten er uklar

Når bruke:

• Ikke-kritiske use cases
• Høye latency-krav
• Godt definerte domener med høy datakvalitet

Mønster 2: Post-Generation Validation (Groundedness Detection)

Beskrivelse: Generer svar først, kjør deretter Groundedness Detection API for å verifisere at svaret er grounded. Hvis ikke, kast svaret eller korriger det.

Fordeler:

• Fanger opp hallusinasjoner automatisk
• Gir detaljert feedback om hvilke deler av svaret som er ungrounded
• Kan auto-korrigere med correction-funksjonen

Ulemper:

• Økt latency (to API-kall: generering + validering)
• Krever ekstra Azure AI Content Safety-ressurs
• Correction-funksjonen krever GPT-4o (økt kostnad)

Når bruke:

• Kritiske use cases (helse, finans, juridisk)
• Når feilinformasjon har alvorlige konsekvenser
• Når man trenger audit trail av groundedness

Mønster 3: Citation-Backed Response

Beskrivelse: Krev at modellen inkluderer inline citations for hvert faktisk påstand. Valider deretter at hver citation faktisk støtter påstanden.

Fordeler:

• Gjør det lettere å verifisere fakta manuelt
• Tvinger modellen til å "tenke" om hvor informasjonen kommer fra
• Reduserer sannsynlighet for hallusinasjoner (modellen må gjøre to feil: hallusinere + lage falsk citation)

Ulemper:

• Modellen kan fortsatt lage falske citations
• Krever citation validation-logikk (regex, semantic similarity)
• Økt token-bruk (citations øker outputlengde)

Når bruke:

• Når sluttbrukere skal kunne verifisere fakta selv
• Når transparens er kritisk (offentlig sektor, akademia)
• Når man har ressurser til å implementere citation validation

Beslutningsveiledning

Beslutningstabell: Hvilken teknikk skal jeg bruke?

Use Case	Anbefalt Strategi	Supplerende Teknikker
Kundesupport chatbot (ikke-kritisk)	Pre-generation grounding + strictness-parameter	Refusal mechanism ("I don't know")
Medisinsk QnA	Pre-generation grounding + Post-generation validation (Reasoning mode)	Citation-backed response + manual review
Juridisk dokumentsamfatning	Post-generation validation (Correction mode)	Multi-step verification + confidence scoring
Finansiell rapportering	Citation-backed response + Groundedness Detection	Multi-step verification + audit logging
Intern FAQ-system	Pre-generation grounding	Strictness-parameter + refusal mechanism

Vanlige Feil (Anti-Mønstre)

❌ "Jeg stoler på at modellen ikke hallusinerer" → Alle LLM-er hallusinerer. Selv med grounding. Du må ha validering.

❌ "Jeg prompter bare 'don't make things up'" → Generic instructions alene er ikke nok. Du må gi strukturerte grounding sources og be om citations.

❌ "Jeg bruker groundedness detection uten å faktisk lese resultatet" → API-et returnerer score og reasoning. Du må faktisk bruke denne informasjonen til å avvise eller korrigere svar.

❌ "Jeg setter strictness til max og tror det eliminerer hallusinasjoner" → Strictness reduserer risiko, men garanterer ikke korrekthet. Du trenger fortsatt validering.

❌ "Jeg ber om citations, men validerer dem ikke" → Modellen kan lage falske citations. Du må verifisere at [2] faktisk finnes og støtter påstanden.

Røde Flagg (Når du MÅ ha streng validering)

🚩 Medisinsk rådgivning: Feil kan føre til helseskade 🚩 Juridiske vurderinger: Feil kan føre til juridiske konsekvenser 🚩 Finansiell rådgivning: Feil kan føre til økonomisk tap 🚩 Offentlig forvaltning: Feil kan bryte lover (AI Act, GDPR) 🚩 Sikkerhetskritiske systemer: Feil kan føre til fysisk skade

Integrasjon med Microsoft-stakken

Azure AI Content Safety

Groundedness Detection API:

# POST til /contentsafety/text:detectGroundedness
{
  "domain": "Medical",
  "task": "QnA",
  "text": "The patient should take 500mg daily.",
  "groundingSources": ["Patient prescription: 250mg twice daily"],
  "reasoning": true,
  "correction": true,
  "llmResource": {
    "resourceType": "AzureOpenAI",
    "azureOpenAIEndpoint": "https://your-endpoint.openai.azure.com",
    "azureOpenAIDeploymentName": "gpt-4o"
  }
}

Response:

{
  "ungroundedDetected": true,
  "ungroundedPercentage": 1.0,
  "ungroundedDetails": [{
    "text": "500mg daily",
    "reason": "Source says 250mg twice daily, not 500mg once daily",
    "correctedText": "250mg twice daily"
  }]
}

Azure OpenAI On Your Data

Grounding-parametere:

• strictness: 1-5 (hvor strengt modellen skal holde seg til kilder)
• inScope: true/false (om modellen kun skal svare innenfor datasettet)
• top_n_documents: Antall dokumenter å hente (mer ≠ bedre; irrelevante docs øker hallusinasjoner)

System message-eksempel:

You are an AI assistant that helps users find information.
You will answer questions ONLY based on the provided documents.
If the answer is not in the documents, respond with "I don't have that information in the available data."
For every claim you make, cite the source document using [doc_id].

Azure AI Foundry

GroundednessEvaluator (Python SDK):

from azure.ai.evaluation import GroundednessEvaluator, AzureOpenAIModelConfiguration

model_config = AzureOpenAIModelConfiguration(
    azure_endpoint=os.environ["AZURE_ENDPOINT"],
    api_key=os.environ["AZURE_API_KEY"],
    azure_deployment=os.environ["AZURE_DEPLOYMENT_NAME"]
)

groundedness_eval = GroundednessEvaluator(model_config)

result = groundedness_eval(
    query="What is the capital of France?",
    response="The capital of France is Paris.",
    context="Paris is the capital city of France, located in the northern part of the country."
)

print(result["groundedness"])  # Score 1-5
print(result["groundedness_reason"])  # Forklaring

Copilot Studio

Built-in grounding:

• Copilot Studio-bots har automatisk grounding til konfigurerte datakilder (SharePoint, Dataverse, etc.)
• Du kan sette "confidence threshold" for når boten skal svare vs. eskalisere til menneske
• Limitation: Mindre kontroll over grounding-logikk enn med Azure OpenAI direkte

Best practice:

• Bruk "escalate to agent"-trigger når groundedness score er lav
• Aktiver "show sources" i bot-konfigurasjon for å vise kildehenvisninger til brukere

Offentlig Sektor (Norge)

Krav til Korrekthet i Forvaltningsvedtak

Hvis en AI-generert tekst inngår i et forvaltningsvedtak (f.eks. søknadsbehandling, saksutredning), gjelder forvaltningsloven § 17 (utredningsplikten). Feil informasjon kan føre til ugyldige vedtak.

Implikasjoner:

• Du MÅ ha post-generation validation (Groundedness Detection) for alle AI-genererte vedtakstekster
• Menneske må alltid gjøre final review før vedtak sendes
• Audit trail: logg grounding sources, groundedness scores, og eventuelle korreksjoner

AI Act (EU AI-forordningen)

High-risk AI-systemer (inkludert systemer som påvirker individers rettigheter) har krav om:

• Article 15: Accuracy, robustness, and cybersecurity
• Article 13: Transparency and provision of information to users

Praktisk betydning:

• Dokumenter hvilke hallucination mitigation-teknikker som brukes
• Ha målbare metrics (f.eks. "95% av svar har groundedness score > 4")
• Kunne vise til brukere hvilke kilder et svar er basert på

Ansvar for Feil (Personvern og Erstatning)

Hvis AI-systemet gir feil informasjon som fører til skade:

• GDPR Article 22: Automatiserte avgjørelser krever menneske-in-the-loop
• Erstatningsansvar: Virksomheten er ansvarlig for feil fra AI-systemer (AI er et "verktøy")

Risikoreduksjon:

• Bruk "human review" for alle high-stakes decisions
• Implementer confidence thresholds som tvinger menneskelig review ved usikkerhet
• Logg alle AI-genererte svar med grounding sources for eventuell ettergranskning

Kostnad og Lisensiering

Azure AI Content Safety (Groundedness Detection)

Prismodell (estimat basert på standard Azure AI Services-priser):

• Basispris: ~$0.002 per transaktion (1000 tokens analysert)
• Med Reasoning: ~$0.004 per transaksjons (krever GPT-4o-kall i bakgrunnen)
• Med Correction: ~$0.006 per transaksjon (krever GPT-4o for re-generering)

Optimalisering:

• Bruk Non-Reasoning mode for sanntids-validering (50% billigere)
• Batch-prosesser validering hvis ikke latency-kritisk
• Valider kun "high-stakes" svar, ikke alle (kombiner med confidence scoring)

Azure OpenAI (Grounding via RAG)

Token-kostnad:

• Grounding sources øker input tokens (typ. 500-2000 tokens ekstra per request)
• Citations øker output tokens (typ. +20% hvis inline citations)
• GPT-4o: ~$0.005 per 1K input tokens, ~$0.015 per 1K output tokens

Kostnad-eksempel (1000 requests/dag):

• Uten grounding: $15-20/dag
• Med grounding (1500 tokens ekstra input): $22-28/dag
• Med grounding + groundedness detection (reasoning): $40-50/dag

Optimaliseringstips:

• Bruk GPT-4o-mini for ikke-kritiske use cases (80% billigere)
• Optimaliser chunk size for grounding sources (mindre chunks = færre tokens, men kan miste kontekst)
• Implementer caching av grounding sources hvis samme kilder brukes ofte

Lisensiering

Nødvendige Azure-ressurser:

• Azure OpenAI: E0-tier (GPT-4o anbefalt for Correction-funksjon)
• Azure AI Content Safety: Standard tier (Groundedness Detection inkludert)
• Azure AI Search: S1 eller høyere (for RAG-indexing)

Microsoft 365 Copilot-lisenser:

• Copilot Studio har innebygd grounding, men begrenset kontroll over hallucination mitigation
• Vurder å bruke Azure OpenAI direkte hvis du trenger fin-grained kontroll

For arkitekten (Cosmo)

Spørsmål å Stille Kunden

1. "Hva er konsekvensen hvis systemet gir feil informasjon?" → Bestemmer om du trenger Post-Generation Validation eller Pre-Generation Grounding er nok.

2. "Må sluttbrukere kunne verifisere hvor informasjonen kommer fra?" → Hvis ja: Citation-Backed Response er nødvendig.

3. "Har dere ressurser til manuell review av AI-genererte svar?" → Hvis nei: Du MÅ ha automatisk groundedness detection + correction.

4. "Er dette et high-risk AI-system under AI Act?" → Hvis ja: Du må ha målbare accuracy-metrics og dokumenterte mitigations.

5. "Hva er akseptabel latency for svar?" → Groundedness Detection (Reasoning mode) legger til ~500-1000ms latency. Vurder Non-Reasoning mode hvis kritisk.

6. "Har dere et etablert quality assurance-team for AI-output?" → Hvis ja: Implementer QA-feedback loops for å justere thresholds over tid.

7. "Hvilke typer feil er mest kritiske å unngå?" → Medisin: Feil dosering. Juss: Feil rettskilder. Finansiell: Feil beløp. Design validation deretter.

8. "Hva er budsjett for API-kostnader?" → Groundedness Detection + Correction kan doble kostnadene. Vurder selective validation.

Fallgruver (Cosmo Har Sett Før)

🕳️ "Vi gjør grounding, så vi trenger ikke validering" → Grounding reduserer hallusinasjoner, men eliminerer dem ikke. Du trenger begge lag.

🕳️ "Vi bruker groundedness detection, så vi kan droppe prompt engineering" → Prompt engineering er det første forsvaret. Groundedness detection er backup. Bruk begge.

🕳️ "Vi setter strictness til 5 og tror det fikser alt" → Høy strictness kan føre til at modellen nekter å svare på legitime spørsmål. Start med 3, tuner basert på data.

🕳️ "Vi bruker Correction-funksjonen uten å logge original response" → Du mister verdifull data om hva modellen faktisk genererte. Logg både original og korrigert tekst.

🕳️ "Vi validerer bare final output, ikke intermediate steps" → I multi-step RAG (f.eks. agentic retrieval), valider hvert steg. En feil tidlig forplanter seg.

Anbefalinger per Modenhetsnivå

Nivå 1 (POC / Pilot):

• Pre-generation grounding (Azure OpenAI On Your Data)
• System message med "answer only from sources" + refusal mechanism
• Manuell review av sample av output (10-20%)

Nivå 2 (Produksjon, ikke-kritisk):

• Pre-generation grounding + strictness-parameter
• Citation-backed response (inline citations)
• Spot-check med Groundedness Detection (Non-Reasoning mode, 10% sample)
• User feedback-mekanisme ("var dette svaret nyttig?")

Nivå 3 (Produksjon, kritisk):

• Pre-generation grounding + Multi-step verification
• Post-generation validation (Groundedness Detection Reasoning mode, 100% av svar)
• Automatic correction eller human review ved groundedness score < 4
• Audit logging (grounding sources, scores, corrections)
• Continuous monitoring av hallucination rate

Nivå 4 (High-Risk AI System, AI Act-compliant):

• Alle teknikker fra Nivå 3
• Red-team testing av hallucination-scenarios
• Documented mitigation strategy + risk assessment
• Regular re-evaluation av accuracy metrics (månedlig/kvartalsvis)
• Transparent disclosure til brukere ("dette svaret er AI-generert basert på [kilder]")

Kilder og Verifisering

Microsoft Learn (Verified via MCP):

• Groundedness Detection Concepts — Verified
• Groundedness Detection Quickstart — Verified
• Groundedness Detection Filter — Verified
• Prompt Engineering Techniques — Verified
• Transparency Note: Azure OpenAI — Verified
• RAG Solution Design Guide — Verified
• Secure Multitenant RAG — Verified

Konfidensnivå per Seksjon:

• Kjernekomponenter: Verified (direkte fra Microsoft Learn API-dokumentasjon)
• Arkitekturmønstre: Baseline (basert på established RAG patterns + Microsoft guidance)
• Integrasjon med Microsoft-stakken: Verified (code samples fra microsoft_code_sample_search)
• Kostnad og Lisensiering: Baseline (prismodeller kan endre seg; verifiser i Azure Pricing Calculator)
• Offentlig Sektor (Norge): Baseline (juridisk tolkning; konsulter juridisk ekspert for endelig vurdering)

Sist verifisert: 2026-02-03 Neste revisjon: 2026-05 (eller ved oppdatering av Azure AI Content Safety API)

Azure AI Content Safety — Groundedness Detection (oppdatert 2026-04)

Breaking change: API-feltnavn er endret:

• correction → mitigating (deteksjons-modus)
• correctedText → correctionText (output-felt med korrigert tekst)

Deteksjonsmoduser:

• Non-Reasoning mode — rask binær deteksjon (grounded/ungrounded), lav latency for produksjon
• Reasoning mode — detaljerte forklaringer på ungrounded segmenter, bruk under utvikling/debugging

Domenestøtte: MEDICAL (medisinsk/vitenskapelig) og GENERIC (generelt formål)

Task typer: Summarization og QnA

Grounding correction (preview): API kan automatisk korrigere ikke-grounded tekst basert på dine grounding sources. Respons inkluderer correctionText-felt med korrigert innhold.

Begrensninger: Kun engelsk tekst støttes. Tilgjengelig i utvalgte Azure-regioner.