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

287 lines
12 KiB
Markdown

# 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](#introduksjon)
- [Kjernekomponenter](#kjernekomponenter)
- [Arkitekturmønstre](#arkitekturmønstre)
- [Beslutningsveiledning](#beslutningsveiledning)
- [Integrasjon med Microsoft-stakken](#integrasjon-med-microsoft-stakken)
- [Offentlig sektor (Norge)](#offentlig-sektor-norge)
- [Kostnad og lisensiering](#kostnad-og-lisensiering)
- [For arkitekten](#for-arkitekten)
- [Kilder og verifisering](#kilder-og-verifisering)
## 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:**
```python
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#):**
```csharp
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](https://learn.microsoft.com/en-us/azure/foundry/concepts/evaluation-evaluators/rag-evaluators) |
| RAG LLM Evaluation Phase | **Verified** | [learn.microsoft.com](https://learn.microsoft.com/en-us/azure/architecture/ai-ml/guide/rag/rag-llm-evaluation-phase) |
| Semantic Kernel Agent RAG | **Verified** | [learn.microsoft.com](https://learn.microsoft.com/en-us/semantic-kernel/frameworks/agent/agent-rag) |
| Corrective RAG (CRAG) paper | **Verified** | [arxiv.org](https://arxiv.org/abs/2401.15884) |
| Evaluating RAG Agents (MS Tech Community) | **Verified** | [techcommunity.microsoft.com](https://techcommunity.microsoft.com/blog/azure-ai-foundry-blog/the-future-of-ai-evaluating-and-optimizing-custom-rag-agents-using-azure-ai-foun/4455215) |
| Azure AI Search agentic retrieval (40% improvement) | **Baseline** | [infoq.com](https://www.infoq.com/news/2025/05/azure-ai-search-agent-retrieval/) |