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>
287 lines
12 KiB
Markdown
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/) |
|