# 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](#introduksjon)
- [Kjernekomponenter i RAG-arkitektur](#kjernekomponenter-i-rag-arkitektur)
- [Arkitekturmønstre](#arkitekturmønstre)
- [Beslutningsveiledning](#beslutningsveiledning)
- [In-Context Learning vs RAG](#in-context-learning-vs-rag)
- [Integrasjon med Microsoft-stakken](#integrasjon-med-microsoft-stakken)
- [Offentlig sektor (Norge)](#offentlig-sektor-norge)
- [Kostnad og lisensiering](#kostnad-og-lisensiering)
- [For arkitekten (Cosmo)](#for-arkitekten-cosmo)
- [Kilder og verifisering](#kilder-og-verifisering)

## 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)**

```python
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**

```python
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**

```python
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

- [What is Retrieval Augmented Generation with Azure AI Search?](https://learn.microsoft.com/en-us/azure/search/retrieval-augmented-generation-overview) (GA)
- [Hybrid search in Azure AI Search](https://learn.microsoft.com/en-us/azure/search/hybrid-search-overview) (GA)
- [Semantic ranking in Azure AI Search](https://learn.microsoft.com/en-us/azure/search/semantic-search-overview) (GA)
- [Integrate Azure OpenAI with Azure AI Search](https://learn.microsoft.com/en-us/azure/search/vector-search-integrated-vectorization-ai-studio) (GA)
- [Use generative answers in Copilot Studio](https://learn.microsoft.com/en-us/microsoft-copilot-studio/nlu-boost-conversations) (GA)
- [Semantic Kernel memory and embeddings](https://learn.microsoft.com/en-us/semantic-kernel/memories/) (GA)
- [Microsoft Foundry prompt flow for RAG](https://learn.microsoft.com/en-us/azure/ai-studio/how-to/flow-develop) (GA)

### 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:

```json
{
  "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.