ms-ai-architect/skills/ms-ai-engineering/references/rag-architecture/rag-core-patterns.md
Kjell Tore Guttormsen ddce43d8b2 feat(ms-ai-architect): Spor 1 — Port-1-substrat migrert på 4 ikke-advisor-skills (243 Source + 327 Type + 325 TOC + stale-verified poison fjernet) [skip-docs]
Steg 9 (R4): unified migrate-corpus.mjs --write over engineering/governance/
infrastructure/security. 327 filer mutert, verified=null, prosa byte-identisk
(fra første ## seksjon), advisor urørt (0 endringer).

To applier-fixes oppdaget under kjøring (TDD, RED→GREEN):
- insertHeaderFields: anker faller nå tilbake når en meta-linje selv passerer
  500B (2 filer pakket et avsnitt i **Status:** → Type/Source landet utenfor
  scan-vinduet, applierens post-write-assertion fanget + restaurerte).
- normalizeStaleVerified: fjerner nå ALLE stale non-date **Verified:** i
  500B-vinduet, inkl. stray body-dup rett under --- (9 mlops-genaiops-filer var
  ellers falskt "verified"/fresh, droppet fra worklist). Operatør-godkjent
  utvidelse av carve-out; kun stray metadata-linjer, aldri prosa.

test-transform-criterion: precondition oppdatert til post-migrasjons-sannhet
(fila bærer nå Source). Suite 728/728 grønn.
2026-07-04 10:19:11 +02:00

20 KiB

RAG Core Patterns and Architecture

Last updated: 2026-06-19 | Verified: MCP 2026-06-19 Status: GA Category: RAG Architecture & Semantic Search Type: reference Source: https://learn.microsoft.com/azure/search/retrieval-augmented-generation-overview


Innhold

Introduksjon

Retrieval-Augmented Generation (RAG) er en arkitektonisk tilnærming som kombinerer informasjonshenting med generativ AI for å produsere faktagrunnede, domene-spesifikke svar. I stedet for å stole utelukkende på en language models forhåndstrente kunnskap, henter RAG-systemer relevant kontekst fra eksterne kunnskapsbaser i sanntid og bruker denne som grunnlag for generering. Dette reduserer hallusinasjoner, tillater kontinuerlig oppdatering av kunnskap uten retrening, og muliggjør svar basert på proprietær eller fersk data.

For enterprise-organisasjoner representerer RAG en praktisk vei til produksjon av AI-løsninger som er både presise og etterprøvbare. Microsoft-økosystemet tilbyr en komplett stack for RAG: Azure AI Search for indeksering og søk, Azure OpenAI Service for generering, Microsoft Foundry for orkestrering, og Copilot Studio for low-code RAG-agenter. RAG brukes i alt fra kunnskapssøk og dokumentanalyse til kundeservice og beslutningsstøtte.

Det finnes tre hovedarkitekturer: Naive RAG (enkel retrieve-then-generate), Advanced RAG (med pre/post-processing og reranking), og Agentic RAG (autonome agenter som planlegger og itererer). Valg av mønster avhenger av use case-kompleksitet, krav til presisjon, og tilgjengelig modenhet.


Kjernekomponenter i RAG-arkitektur

En RAG-pipeline består av følgende byggeklosser:

Komponent Ansvar Microsoft-tjenester
Document Ingestion Laste inn, parse og chunke dokumenter Azure AI Document Intelligence, Azure Functions
Embedding Generation Konvertere tekst til vektorer Azure OpenAI (text-embedding-3-large, text-embedding-ada-002)
Vector Store Lagre og indeksere embeddings Azure AI Search, Azure Cosmos DB (MongoDB vCore)
Retrieval Søke etter relevante chunks basert på query Azure AI Search (vector, hybrid, semantic search)
Reranking Sortere resultater etter relevans Azure AI Search Semantic Ranker, custom models
Context Assembly Bygge prompt med retrieved chunks Semantic Kernel, LangChain, Prompt flow
Generation Generere svar basert på context Azure OpenAI Service (GPT-4, GPT-4o)
Citation Tracking Spore kilder og gi referanser Custom logic, Azure AI Search metadata

Typisk RAG-flyt:

  1. Indexing (offline): Dokumenter lastes inn → chunkes → embeddes → lagres i vector store
  2. Query (runtime): User query → embedding → vector search → reranking → top-k chunks
  3. Generation: Chunks + query → prompt template → LLM → response + citations

Eksempel: Enkel RAG-flyt i Python (Semantic Kernel)

from semantic_kernel import Kernel
from semantic_kernel.connectors.ai.open_ai import AzureChatCompletion, AzureTextEmbedding
from semantic_kernel.connectors.memory.azure_cognitive_search import AzureCognitiveSearchMemoryStore

# Setup
kernel = Kernel()
kernel.add_chat_service("chat", AzureChatCompletion(...))
kernel.add_text_embedding_generation_service("embedding", AzureTextEmbedding(...))
memory = AzureCognitiveSearchMemoryStore(...)

# Index (offline)
await memory.save_information_async("docs", id="1", text="Microsoft Copilot Studio allows...")

# Retrieve + Generate (runtime)
results = await memory.search_async("docs", "What is Copilot Studio?", limit=3)
context = "\n".join([r.text for r in results])
prompt = f"Context:\n{context}\n\nQuestion: What is Copilot Studio?\nAnswer:"
response = await kernel.invoke_semantic_async(prompt)

Arkitekturmønstre

1. Naive RAG

Beskrivelse: Enkel retrieve-then-generate pipeline uten pre/post-processing.

Flyt:

  1. Embed user query
  2. Vector search → top-k chunks
  3. Inject chunks i prompt
  4. Generate response

Når bruke:

  • MVP/proof-of-concept
  • Enkle kunnskapssøk med begrenset datamengde
  • Lavt krav til presisjon

Fordeler:

  • Rask implementering (dager)
  • Lav kompleksitet
  • Enkel feilsøking

Ulemper:

  • Dårlig håndtering av komplekse queries
  • Ingen optimalisering av chunk-relevans
  • Begrensede citation capabilities

Typisk bruk: Intern FAQ-bot, proof-of-concept for ledelse, enkel dokumentsøk.


2. Advanced RAG

Beskrivelse: Forbedret pipeline med query processing, hybrid search, reranking, og post-processing.

Flyt:

  1. Pre-retrieval: Query expansion, intent detection, filter inference
  2. Retrieval: Hybrid search (vector + BM25) + metadata filtering
  3. Post-retrieval: Reranking (semantic ranker), deduplication, chunk selection
  4. Generation: Context-optimized prompt + citation tracking

Når bruke:

  • Produksjonsløsninger med krav til presisjon
  • Store kunnskapsbaser (>10,000 dokumenter)
  • Behov for verifiable citations

Fordeler:

  • Høyere relevans (20-40% forbedring vs naive)
  • Bedre håndtering av komplekse queries
  • Citation tracking og source attribution
  • Robusthet mot ambiguity

Ulemper:

  • Høyere latency (2-5x vs naive)
  • Mer kompleks pipeline å vedlikeholde
  • Høyere kostnader (reranking, query expansion)

Typisk bruk: Enterprise kunnskapssøk, regulatory compliance bots, kundeservice med SLA-krav.


3. Agentic RAG

Beskrivelse: Autonome agenter som planlegger, itererer, og velger retrieval-strategi dynamisk.

Flyt:

  1. Planning: Agent analyserer query → dekomponerer i sub-tasks
  2. Tool Selection: Agent velger search-strategi (vector, keyword, multi-index, web)
  3. Iterative Retrieval: Agent henter data → evaluerer relevans → henter mer hvis nødvendig
  4. Self-Reflection: Agent vurderer om nok kontekst er samlet
  5. Generation: Syntetiserer svar basert på aggregert kontekst

Når bruke:

  • Komplekse, multi-hop reasoning tasks
  • Cross-domain queries (søk i flere databaser)
  • Research-assistenter og analytical agents

Fordeler:

  • Høyest presisjon for komplekse queries
  • Selvkorrigerende (kan omformulere og re-query)
  • Kan kombinere multiple sources (docs, web, APIs)

Ulemper:

  • Høy latency (10-60 sekunder)
  • Høy token-kostnad (multiple LLM calls)
  • Kompleks debugging og observability

Typisk bruk: Research assistants, regulatory analysis, cross-domain intelligence.

Eksempel: Agentic RAG med Microsoft Agent Framework

from semantic_kernel.agents import ChatCompletionAgent
from semantic_kernel.agents.strategies import TerminationStrategy

# Define retrieval tool
@kernel_function(name="search_docs", description="Search knowledge base")
async def search_docs(query: str) -> str:
    results = await memory.search_async("docs", query, limit=5)
    return "\n".join([r.text for r in results])

# Create agent with tools
agent = ChatCompletionAgent(
    kernel=kernel,
    name="ResearchAgent",
    instructions="You are a research assistant. Use search_docs to find information, then synthesize.",
    tools=[search_docs]
)

# Run
result = await agent.invoke_async("What are the compliance requirements for AI in Norwegian public sector?")

Beslutningsveiledning

Mønster-valg: Når bruke hva?

Kriterium Naive RAG Advanced RAG Agentic RAG
Use case-kompleksitet Enkel FAQ, direktesøk Enterprise kunnskapssøk, compliance Multi-hop reasoning, research
Datamengde <1,000 dokumenter 1,000-100,000+ Ubegrenset (multi-source)
Latency-krav <1s 1-3s 10-60s
Presisjonskrav Lav (70-80% recall) Høy (90%+ recall) Kritisk (95%+ recall)
Citation-krav Valgfri Påkrevd Påkrevd + traceability
Kostnadssensitivitet Lav (få tokens) Moderat Høy (mange LLM calls)
Modenhet i org MVP-fase Produksjon Advanced AI-team

Vanlige feil og misforståelser

Misforståelse Realitet
"RAG eliminerer hallusinasjoner" RAG reduserer, men eliminerer ikke hallusinasjoner. LLM kan fortsatt generere feil basert på dårlig kontekst.
"Større chunks gir bedre svar" Større chunks gir mer kontekst, men reduserer presisjon. Optimal chunk size: 512-1024 tokens med 10-20% overlap.
"Vector search er nok" Vector search alene misser keyword matches. Hybrid search (vector + BM25) gir 15-30% bedre recall.
"RAG fungerer out-of-the-box" RAG krever tuning: chunk size, embedding model, retrieval-k, reranking, prompt engineering.
"Long-context models erstatter RAG" Long-context (128K tokens) er dyrt og tregere. RAG er mer kostnadseffektivt for store kunnskapsbaser.

Røde flagg

  • Ingen metadata-strategi: Uten metadata (source, date, category) er filtrering og citation umulig.
  • Hardkodet chunk size: Ulike dokumenttyper (tabeller, prosatekst, kode) krever ulike chunk-strategier.
  • Manglende reranking: Vector search alene gir ofte irrelevante chunks i top-3. Reranking er kritisk.
  • Ingen evaluation metrics: Uten retrieval recall/precision og generation fidelity er tuning blindflyvning.
  • Token overflow: Uten context window management risikerer du truncation og tap av relevante chunks.

In-Context Learning vs RAG

In-Context Learning (ICL): Gi LLM all kontekst i prompten (few-shot examples, dokumenter, data).

Når bruke ICL:

  • Liten kunnskapsbase (<10 dokumenter, <50K tokens)
  • Statisk data som sjeldent endres
  • Behov for rask prototyping uten infrastruktur

Når bruke RAG:

  • Stor kunnskapsbase (>50K tokens)
  • Dynamisk data som oppdateres hyppig
  • Behov for citation og source tracking
  • Kostnadsoptimalisering (vector search er billigere enn å sende 100K tokens per query)

Long-Context Models (GPT-4 Turbo 128K):

  • Tillater større ICL-windows
  • Men: Høyere latency, høyere kostnad, "lost-in-the-middle" problem (LLM prioriterer start/slutt av context)
  • Hybrid-tilnærming: Bruk RAG for retrieval → inject top-k chunks i long-context model

Integrasjon med Microsoft-stakken

Azure AI Search (kjernen i RAG)

Funksjon Bruk i RAG
Vector search Embedding-basert retrieval (cosine similarity, HNSW indexing)
Hybrid search Kombinerer vector + BM25 for bedre recall
Semantic Ranker L2 reranking basert på cross-encoder (20-30% relevance boost)
Metadata filtering Filtrering på dato, category, access control
Skillset API Document cracking, OCR, entity extraction pre-indexing

Eksempel: Hybrid search query

from azure.search.documents import SearchClient

results = search_client.search(
    search_text="What is Copilot Studio?",  # BM25
    vector_queries=[VectorQuery(
        vector=query_embedding,  # Vector
        k_nearest_neighbors=50,
        fields="contentVector"
    )],
    select=["id", "content", "sourcePage", "category"],
    top=10
)

Microsoft Foundry

  • Prompt flow: Visuell orkestrasjon av RAG-pipelines (indexing → retrieval → generation) — ⚠️ pensjoneres 2027-04-20, migrer til Microsoft Agent Framework (MAF)
  • Evaluation: Built-in metrics (groundedness, relevance, coherence)
  • Tracing: End-to-end observability av RAG-calls

Semantic Kernel

  • Memory connectors: Abstraksjon over Azure AI Search, Cosmos DB, Qdrant
  • Plugins: Modulær arkitektur for retrieval functions
  • Planner: Agent-basert orkestrering for Agentic RAG

Copilot Studio

  • Generative answers: Low-code RAG med Azure AI Search + SharePoint
  • Knowledge sources: Drag-and-drop indexing av docs, websites
  • Conversation boosting: Automatisk faller tilbake på RAG hvis intent ikke matches

Offentlig sektor (Norge)

Datasuverenitet og residency

Krav RAG-implikasjon
GDPR Art. 32 (sikkerhet) Embeddings kan inneholde PII. Krypter vector store, bruk Managed Identity for autentisering.
Schrems II (dataoverføring) Bruk Azure Norway regions (Norway East/West). Sjekk at embeddings ikke sendes utenfor EU.
Forvaltningsloven § 11a (innsyn) RAG må kunne vise kilder for svar. Citation tracking er obligatorisk.
AI Act (høyrisiko-AI) Hvis RAG brukes i forvaltningsvedtak, krev menneske-i-loop og dokumentasjon av retrieval-logikk.

Compliance-sjekkliste

  • Document-level RBAC: Filtrer søkeresultater basert på brukers AD-gruppe.
  • Audit logging: Logg alle queries, retrieved chunks, og genererte svar (Azure Monitor).
  • PII detection: Skann og rediger PII i indexing og output (Azure AI Content Safety).
  • Data retention: Definer retention policy for embeddings og logs (6 måneder standard).
  • Explainability: Vis alltid kilder, confidence score, og retrieval-logikk.

Typetilfeller for offentlig sektor

Use case RAG-mønster Compliance-fokus
Regelverksøk (lovdata, forskrifter) Advanced RAG + metadata filtering Citation, audit logging
Saksbehandler-assistent Agentic RAG + document-level RBAC GDPR, Forvaltningsloven § 11a
Kundeservice chatbot Naive RAG (FAQ) PII redaction, data residency
Policy-analyse Agentic RAG + multi-index AI Act transparency krav

Kostnad og lisensiering

Prismodell (per 1,000 brukere/måned, Norge, 2026)

Komponent Kostnad (NOK) Merk
Azure AI Search (S1, 10M vectors) 15,000 Semantic Ranker: +5,000 NOK
Azure OpenAI embeddings (text-embedding-3-large, 1B tokens) 1,500 Batching reduserer kostnad 50%
Azure OpenAI generation (GPT-4o, 10M tokens output) 60,000 Input tokens: 20,000 NOK
Azure AI Document Intelligence (10K pages) 1,200 For document cracking
Azure Monitor (logging) 2,000 For audit trails
Total (Advanced RAG) ~83,700 NOK/mnd Naive RAG: ~50,000 (uten reranking/DI)

Kostnadsoptimaliseringstips

  1. Caching: Cache embeddings for repeterte queries (50-70% kostnadskutt).
  2. Batching: Batch embedding-generering (50% rabatt via Azure OpenAI batch API).
  3. Chunk reuse: Generer embeddings én gang, ikke per user session.
  4. Model downgrade: Bruk text-embedding-ada-002 (10x billigere) for non-critical use cases.
  5. Semantic Ranker on-demand: Aktiver kun for complex queries (identifiser via query length/complexity).
  6. Hybrid caching: Cache både retrieval results og generated responses (LLM cache hit = gratis).

For arkitekten (Cosmo)

Nøkkelspørsmål å stille kunden

  1. Datakilde: Hvor ligger kunnskapsbasen? (SharePoint, Dataverse, SQL, filshare, ekstern API?)
  2. Data-dynamikk: Hvor ofte endres dataen? (Sanntid, daglig, månedlig, statisk?)
  3. Query-kompleksitet: Enkle spørsmål ("Hva er...") eller multi-hop reasoning ("Sammenlign X og Y basert på Z")?
  4. Citation-krav: Må systemet vise kilder? Hvor granulært (dokument, side, paragraf)?
  5. Latency-toleranse: Akseptabel responstid? (<1s, 1-3s, >5s?)
  6. Compliance: GDPR, Schrems II, AI Act? Offentlig sektor?
  7. Volum: Hvor mange dokumenter? Hvor mange queries per dag?
  8. Tilgangskontroll: Trenger brukere ulik tilgang til dokumenter? (RBAC, document-level filtering?)

Vanlige fallgruver

Fallgruve Hvordan unngå
For store chunks Test chunk sizes (256, 512, 1024 tokens). Mål retrieval recall.
Manglende metadata Alltid legg til source, date, category, access_control ved indexing.
Ingen reranking Semantic Ranker gir 20-30% bedre relevans. Alltid inkluder i prod.
Hardkodet prompts Bruk parametriserte prompt templates. Test med ulike query-typer.
Token overflow Monitor context window usage. Implementer chunk truncation-logikk.
Ingen evaluation Definer retrieval recall/precision targets. Bruk Microsoft Foundry evaluation.

Anbefalinger per modenhetsnivå

Modenhet RAG-mønster Tooling Tidsestimat
Pilot (MVP) Naive RAG Copilot Studio generative answers 1-2 uker
Produksjon (scale) Advanced RAG Microsoft Agent Framework (MAF) + Semantic Kernel ⚠️ (erstatter Prompt Flow, som pensjoneres 2027-04-20) 6-8 uker
Advanced (complex) Agentic RAG Microsoft Agent Framework + custom agents 12-16 uker

Quick-start playbook

Uke 1-2: Indexing

  1. Document cracking (Azure AI Document Intelligence)
  2. Chunking (512 tokens, 10% overlap)
  3. Embedding generation (text-embedding-3-large)
  4. Indexing i Azure AI Search

Uke 3-4: Retrieval

  1. Hybrid search setup (vector + BM25)
  2. Semantic Ranker aktivering
  3. Metadata filtering (source, date, category)
  4. Retrieval evaluation (recall@10)

Uke 5-6: Generation

  1. Prompt engineering (system prompt + context injection)
  2. Citation tracking (source attribution i output)
  3. Hallucination mitigation (grounding prompts)
  4. Output evaluation (groundedness, relevance)

Uke 7-8: Produksjonisering

  1. Caching (query results + LLM responses)
  2. Observability (Azure Monitor + Application Insights)
  3. RBAC enforcement (document-level filtering)
  4. Load testing (concurrent users, latency targets)

Kilder og verifisering

Microsoft Learn-referanser

Konfidensnivå

  • Verified: Arkitekturmønstre, Azure AI Search features, Azure OpenAI embeddings, Semantic Kernel patterns (basert på Microsoft Learn + GA-tjenester)
  • Baseline: Kostnadsestimater (basert på Azure pricing januar 2026, kan variere per region)
  • Assumed: Agentic RAG adoption timeline (basert på current preview status i Microsoft Agent Framework)

For Cosmo: Når kunde spør om RAG, start med "Naive vs Advanced vs Agentic"-beslutningstreet. Identifiser data source, query complexity, og latency-krav først. Hvis offentlig sektor: alltid spør om GDPR/Schrems II/AI Act compliance før du foreslår arkitektur. Hvis customer mangler evaluation strategy: stopp og definer retrieval recall/precision targets før du går videre med implementation.

Hybrid Search — Kjernemønster (oppdatert 2026-04)

Hybrid search er standardmønsteret for RAG i Azure AI Search:

{
  "search": "historisk hotell nær restauranter",
  "vectorQueries": [{"kind": "vector", "vector": [...], "k": 50, "fields": "DescriptionVector"}],
  "queryType": "semantic",
  "semanticConfiguration": "my-semantic-config"
}

Hvorfor hybrid:

  • Vector search: finner konseptuelt like dokumenter uten nøyaktige nøkkelord-treff
  • Full-text search: presis matching for produktkoder, navn, datoer
  • RRF merger: normaliserer scores fra BM25 og HNSW/eKNN
  • Semantic ranker (L2): re-ranker opp til 50 resultater med maskinlesningsforståelse

Best practice: Sett k=50 ved bruk av semantic ranker.