ms-ai-architect/skills/ms-ai-engineering/references/rag-architecture/self-reflective-rag.md
Kjell Tore Guttormsen 3a73eeafdc refactor(ms-ai-architect): R13 del 1 — nøytraliser Cosmo-personaen i ref-korpusets headinger, etter å ha rettet en gate som var målt usann to ganger
Ordre 20260912T193441Z-7358817909. Steg 1 var ikke transformen, men å rette
roadmapens R13-gate og få den ratifisert. Gaten `grep -rl "Cosmo"
skills/*/references -> 0` var usann på to uavhengige måter:

1. Ordren fanget den første: 451 av forekomstene er Azure Cosmos DB, ekte
   produktinnhold. Diskriminatoren er ikke bokstaven «s» — `Cosmos <norsk
   substantiv>` er genitiv av personaen (`### Cosmos tonalitet`), mens
   `Cosmos DB`/`CosmosClient`/`cosmos_ru` er produkt.
2. Denne økten fant den andre: 132 persona-forekomster ligger i prosa,
   tabeller, dialog-replikker og proveniens-linjer. Heading-nøytralisering
   kan ikke nå dem, så «0 persona» er uoppnåelig også under den ratifiserte
   formen. Operatøren ratifiserte alternativ A: gaten speiler formen, og de
   132 bokføres til R13b/R14.

Tre korreksjoner av premisser som sto i ordren og STATE:
  «ca 320 produkt»   -> 451 (case-sensitivt nett manglet 327 lowercase
                        TOC-ankre + 99 identifikatorer; sann nevner 1 638)
  «169 headinger»    -> 401. 169 var `^## For Cosmo`-prefikset (168) og var
                        internt inkonsistent med sin egen topp-variant (204)
  «417 matcher ingen
   populasjon»       -> 417 er cosmo-headinger utenfor kodefences; briefens
                        nevner var reell hele tiden

Fence-bevissthet er målt skadelig, ikke nødvendig: begge toggle-regler er
gale på dette korpuset (naiv toggle skjuler en ekte heading i
chain-of-thought-prompting.md, CommonMark-regelen ubalanserer
service-level-documentation-dr.md). Fence-agnostisk deteksjon finner 401
heading-linjer i nøyaktig de samme 40 variantene som fence-bevisst finner
400 i — ingen kodeblokk-linje er byte-identisk til en persona-heading. Derfor
nøkles transformen på 40 enumererte heading-tekster og ignorerer fences. En
ukjent variant kaster; en slug-kollisjon kaster. Ingenting auto-fikses.

TOC-en regenereres ikke, den rettes kirurgisk: alle 327 persona-lenker hadde
lenketekst lik én av de 40 heading-tekstene og anker lik slugify av den
(327/327, 0 avvik), så heading og TOC-entry skrives i samme operasjon og
ingen mellomtilstand etterlater en død lenke.

Ratifisert målform: `For Cosmo`, `For Cosmo Skyberg` og `For arkitekten
(Cosmo)` konvergerer på `For arkitekten`. To filer kolliderte og er adjudisert
ved å lese dem, ikke ved regel.

Verifisering (alle 7 kriterier fra ordren):
  G1 persona på heading-linjer   401 -> 0
  G2 døde fragmentlenker         1 -> 1 (pre-eksisterende, unntatt)
  G3 produkt-forekomster         451 -> 451; `Cosmos DB|Azure Cosmos` 308 = 308
  de 3 kun-produkt-filene        byte-identiske
  nettet validert begge veier    injisert persona feller G1; genitiv feller G1;
                                 produkt-heading og de 3 filene passerer
  hele diffen                    802 heading-linjer + 654 TOC-linjer, ANNET = 0
  linjeantall                    728 lagt til = 728 slettet
  suite                          1120/1120 (1097 + 23 nye)
  validate-plugin                250 PASS / 0 FAIL
  stikkprøve                     10 filer, alle 5 skills, inkl. de 3 mest
                                 produkt-tunge (26/20/19) — kun heading+TOC

Utenfor scope, urørt: de 4 SKILL.md, de 23 commands, CLAUDE.md, README.md,
NOTICE.md, docs/ (alt R14).

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-09-12 22:12:28 +02:00

12 KiB

Self-Reflective RAG — Selvevaluerende retrieval

Last updated: 2026-06-24 Status: GA (Microsoft Foundry evaluators), Preview (agentic retrieval) Category: RAG Architecture & Semantic Search Type: reference Source: https://learn.microsoft.com/azure/foundry/concepts/evaluation-evaluators/rag-evaluators


Innhold

Introduksjon

Self-Reflective RAG er en arkitektur der systemet evaluerer og raffinerer sine egne retrieval-beslutninger i en iterativ loop. I tradisjonell RAG aksepteres retrieved chunks ukritisk — selv når de er irrelevante eller utilstrekkelige. Self-reflective RAG innfører en evalueringsmekanisme som scorer retrieved dokumenter og trigger re-retrieval, query-reformulering eller fallback-strategier ved lav confidence.

To fremtredende forskningsbidrag definerer feltet: CRAG (Corrective RAG) bruker en lightweight evaluator som returnerer confidence-grader (Correct/Incorrect/Ambiguous) for å trigge korrektive handlinger, og Self-RAG der modellen kritiserer og verifiserer sine egne outputs under generering.

Microsoft Foundry tilbyr innebygde evaluatorer for RAG quality assessment (groundedness, relevance, coherence — alle 1-5 skala) som kan integreres i en feedback loop. Azure AI Search agentic retrieval (preview) forbedrer retrieval-relevans med opptil 40% gjennom LLM-assistert query planning.


Kjernekomponenter

CRAG-arkitektur

Komponent Beskrivelse Handling
Retrieval Evaluator Scorer retrieved dokumenter Confidence: Correct / Incorrect / Ambiguous
Correct (høy confidence) Dokumenter er relevante Gå direkte til generering
Ambiguous (middels) Delvis relevante Decompose-then-recompose: filtrer irrelevant innhold
Incorrect (lav confidence) Dokumenter er irrelevante Re-retrieve med reformulert query eller web search fallback

Microsoft Foundry evaluatorer

Evaluator Type Scoring Bruksområde
Retrieval Prosess 1-5 Likert Query-context relevans (uten ground truth)
Groundedness System 1-5 Likert Response alignment med context (precision)
Groundedness Pro System Binary Strikt consistency via Azure AI Content Safety
Relevance System 1-5 Likert Response adresserer query fullstendig
Response Completeness System 1-5 Likert Response dekker all kritisk info (recall)
Document Retrieval Prosess NDCG, XDCG Krever ground truth labels

Self-reflective loop

Query → Initial Retrieval → Evaluering
  ├─ Score ≥ threshold → Generer svar → Groundedness-check
  │   ├─ Grounded → Returner svar
  │   └─ Ikke grounded → Re-generate med justert prompt
  └─ Score < threshold → Query reformulering → Re-retrieval → Evaluering

Arkitekturmønstre

Mønster 1: CRAG med Microsoft Foundry evaluators

Arkitektur: Query → Azure AI Search → Retrieval Evaluator → [Correct: Generate] / [Ambiguous: Filter + Generate] / [Incorrect: Reformulate + Re-retrieve]

Implementering:

from azure.ai.evaluation import RetrievalEvaluator, GroundednessEvaluator

retrieval_eval = RetrievalEvaluator(model_config=model_config, threshold=3)
groundedness_eval = GroundednessEvaluator(model_config=model_config, threshold=3)

# Steg 1: Initial retrieval
results = search_client.search(query, vector_queries=[...], top=5)
context = "\n".join([r["chunk"] for r in results])

# Steg 2: Evaluer retrieval-kvalitet
retrieval_score = retrieval_eval(query=query, context=context)

if retrieval_score["retrieval"] >= 4:  # Correct
    response = generate_response(query, context)
elif retrieval_score["retrieval"] >= 2:  # Ambiguous
    filtered = filter_relevant_passages(context, query)
    response = generate_response(query, filtered)
else:  # Incorrect
    reformulated = reformulate_query(query)
    new_results = search_client.search(reformulated, ...)
    response = generate_response(reformulated, new_results)

# Steg 3: Groundedness-check
grounded = groundedness_eval(
    query=query, context=context, response=response
)
if grounded["groundedness_result"] == "fail":
    response = regenerate_with_stricter_prompt(query, context)

Fordeler:

  • Managed evaluators — ingen custom modelltrening
  • Integrert med Microsoft Foundry observability
  • Støtter reasoning-modeller (o-series) med is_reasoning_model=True

Anbefalt for: Produksjonssystemer der svarkvalitet er kritisk.

Mønster 2: Iterativ query refinement med Semantic Kernel

Arkitektur: Agent med OnDemandFunctionCalling → Søk → Evaluer → Reformuler → Søk igjen

Implementering (C#):

var options = new TextSearchProviderOptions
{
    SearchTime = RagBehavior.OnDemandFunctionCalling,
    Top = 5,
    PluginFunctionName = "SearchKnowledge"
};

ChatCompletionAgent agent = new()
{
    Name = "ReflectiveAssistant",
    Instructions = """
    Before answering, search for relevant information.
    After retrieving results, assess if they are sufficient.
    If not, reformulate your search query and try again.
    Maximum 3 search attempts per question.
    Always cite your sources.
    """,
    Kernel = kernel,
    UseImmutableKernel = true
};

Fordeler:

  • Agent styrer iterativ loop naturlig via instruksjoner
  • Fleksibel — kan tilpasses domene-spesifikke evalueringskriterier
  • Integrert med Semantic Kernel ecosystem

Anbefalt for: Code-first teams som vil ha full kontroll over refleksjon-logikken.

Mønster 3: Parameter sweep-optimalisering

Arkitektur: Systematisk testing av retrieval-parametere mot golden metrics

Prosess:

  1. Definer golden metrics (XDCG, Fidelity, NDCG)
  2. Opprett ground truth labels (human eller LLM-basert)
  3. Kjør parameter sweep over re-ranker thresholds, target indices, knowledge sources
  4. Velg optimal konfigurasjon basert på groundedness + relevance scores

Microsoft Foundry-støtte:

Metric Formål
Max Relevance N Maks relevans-score i top-k chunks
XDCG Resultatkvalitet innenfor top-k dokumenter
Fidelity Hvor nøyaktig retrieval matcher ground truth

Anbefalt for: Enterprise-teams med ground truth-data og kapasitet til systematisk evaluering.


Beslutningsveiledning

Beslutningstabell

Scenario Anbefalt mønster Begrunnelse
Kritisk svarkvalitet (helse, jus) Mønster 1 (CRAG + evaluators) Systematisk kvalitetssikring
Code-first team Mønster 2 (SK iterativ) Full kontroll, fleksibelt
Ground truth tilgjengelig Mønster 3 (parameter sweep) Kvantitativ optimalisering
Kostnadsbevisst Mønster 2 med max 2 iterasjoner Begrens LLM-kall

Vanlige feil

Feil Konsekvens Løsning
Uendelig refleksjon-loop Høy kostnad, timeout Sett maks iterasjoner (2-3)
Threshold for lav Alle retrievals trigges som «incorrect» Start med threshold=3, kaliber
Kun groundedness uten relevance Grounded men irrelevante svar Kombiner groundedness + relevance
Ingen baseline-metrics Umulig å vite om refleksjon hjelper Mål metrics FØR og ETTER

Røde flagg

  • Self-reflective RAG for enkle FAQ-systemer (overkill)
  • Ingen logging av evaluator-scorer over tid
  • Refleksjon uten mål (ingen metrics å optimalisere mot)
  • Groundedness Pro i produksjon uten fallback (avhengig av Content Safety API)

Integrasjon med Microsoft-stakken

Tjeneste Integrasjonspunkt
Microsoft Foundry Innebygde evaluatorer (Groundedness, Relevance, Retrieval)
Azure AI Search Retrieval backend + agentic retrieval (preview)
Semantic Kernel OnDemandFunctionCalling for iterativ retrieval
Azure OpenAI GPT-4o for evaluering og generering
Application Insights Logging av evaluator-scorer, iterasjoner, latency
Azure AI Content Safety Groundedness Pro (binary consistency check)

Offentlig sektor (Norge)

Dataplassering

  • Microsoft Foundry evaluators: Kjøres via Azure OpenAI (Sweden Central) — data i EU/EØS
  • Azure AI Content Safety: Sjekk regional tilgjengelighet for Groundedness Pro

Relevante vurderinger

Krav Implikasjon
AI Act Self-reflective mekanismer støtter krav om robusthet og pålitelighet
Forvaltningsloven Evaluator-logger dokumenterer beslutningsgrunnlag
GDPR Evaluator-kall behandler brukerdata — databehandleravtale
NSM Grading-krav → on-premises evaluering for gradert info

Kostnad og lisensiering

Kostnadskomponenter

Komponent Kostnad per query Notat
Initial retrieval ~0.5 NOK Standard search + embedding
Retrieval evaluator (GPT-4o) ~0.3 NOK LLM-basert scoring
Groundedness evaluator ~0.3 NOK LLM-basert scoring
Re-retrieval (ved feil) ~0.5 NOK Trigges i ~20-30% av queries
Gjennomsnittlig total ~1.5-2.5 NOK vs. ~1 NOK for standard RAG

ROI-vurdering

Hvis self-reflective RAG reduserer feilaktige svar fra 15% til 5%:

  • Kostnad: +50-150% per query
  • Gevinst: 10% færre feilaktige svar → redusert manuell korreksjon, høyere tillit

For arkitekten

Spørsmål å stille kunden

  1. "Hva er konsekvensen av feil svar?" — Høy konsekvens (helse, jus) → self-reflective RAG
  2. "Har dere ground truth-data?" — Ja → parameter sweep, nei → LLM-basert evaluering
  3. "Hva er akseptabel ekstra latency?" — Self-reflection = 1-3 ekstra LLM-kall
  4. "Trenger dere audit trail for beslutninger?" — Evaluator-logger dekker dette
  5. "Har dere kapasitet til å kalibrere thresholds?" — Krever iterativ tuning

Fallgruver

  • Evaluator som gospel: LLM-baserte evaluatorer har selv feilrate — bruk som signal, ikke absolutthet
  • Over-refleksjon: Mer enn 3 iterasjoner gir sjelden bedre svar, men øker kostnad drastisk
  • Glemmer menneske-i-loopen: Self-reflective er ikke det samme som feilfri

Anbefalinger per modenhetsnivå

Modenhet Anbefaling
Prototyp Standard RAG. Mål baseline groundedness og relevance.
Pilot Legg til Groundedness evaluator post-generation. Logg scores.
Produksjon CRAG-mønster med retrieval + groundedness evaluering. Max 2 iterasjoner.
Enterprise Full parameter sweep + automated threshold-kalibrering + A/B-testing.

Kilder og verifisering

Kilde Konfidens URL
RAG Evaluators (Microsoft Foundry) Verified learn.microsoft.com
RAG LLM Evaluation Phase Verified learn.microsoft.com
Semantic Kernel Agent RAG Verified learn.microsoft.com
Corrective RAG (CRAG) paper Verified arxiv.org
Evaluating RAG Agents (MS Tech Community) Verified techcommunity.microsoft.com
Azure AI Search agentic retrieval (40% improvement) Baseline infoq.com