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>
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
- Kjernekomponenter
- Arkitekturmønstre
- Beslutningsveiledning
- Integrasjon med Microsoft-stakken
- Offentlig sektor (Norge)
- Kostnad og lisensiering
- For arkitekten
- 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:
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:
- Definer golden metrics (XDCG, Fidelity, NDCG)
- Opprett ground truth labels (human eller LLM-basert)
- Kjør parameter sweep over re-ranker thresholds, target indices, knowledge sources
- 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
- "Hva er konsekvensen av feil svar?" — Høy konsekvens (helse, jus) → self-reflective RAG
- "Har dere ground truth-data?" — Ja → parameter sweep, nei → LLM-basert evaluering
- "Hva er akseptabel ekstra latency?" — Self-reflection = 1-3 ekstra LLM-kall
- "Trenger dere audit trail for beslutninger?" — Evaluator-logger dekker dette
- "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 |