feat(ultraplan-local): v1.6.0 — /ultraresearch-local deep research command

Add /ultraresearch-local for structured research combining local codebase analysis with external knowledge via parallel agent swarms. Produces research briefs with triangulation, confidence ratings, and source quality assessment. New command: /ultraresearch-local with modes --quick, --local, --external, --fg. New agents: research-orchestrator (opus), docs-researcher, community-researcher, security-researcher, contrarian-researcher, gemini-bridge (all sonnet). New template: research-brief-template.md. Integration: --research flag in /ultraplan-local accepts pre-built research briefs (up to 3), enriches the interview and exploration phases. Planning orchestrator cross-references brief findings during synthesis. Design principle: Context Engineering — right information to right agent at right time. Research briefs are structured artifacts in the pipeline: ultraresearch → brief → ultraplan --research → plan → ultraexecute. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
2026-04-08 08:58:35 +02:00 · 2026-04-08 08:58:35 +02:00 · baa2d0220b
commit baa2d0220b
488 changed files with 213221 additions and 0 deletions
--- a/skills/ms-ai-engineering/references/rag-architecture/rag-query-understanding.md
+++ b/skills/ms-ai-engineering/references/rag-architecture/rag-query-understanding.md
@ -0,0 +1,578 @@
+# Query Understanding and Expansion
+
+**Last updated:** 2026-02
+**Status:** GA
+**Category:** RAG Architecture & Semantic Search
+
+---
+
+## Introduksjon
+
+Query understanding er den kritiske fasen i en RAG-løsning som transformerer brukerens spørsmål til optimaliserte søkespørringer før retrieval-steget. Mens direkte bruk av brukerens originale spørsmål kan fungere for enkle queries, gir query understanding betydelig forbedring av retrieval-kvalitet gjennom teknikker som query expansion, intent classification, query rewriting og sub-query decomposition.
+
+Målet med query understanding er tredelt: (1) **forstå brukerens intensjon** gjennom kontekstuell analyse, (2) **reformulere spørringen** til å treffe den terminologien som faktisk brukes i dokumentene, og (3) **utvide søkerommet** gjennom synonymer, relaterte termer og hypoteser. Dette steget er spesielt viktig i multi-turn conversations hvor kontekst fra tidligere meldinger må integreres, og i domener med spesialisert terminologi hvor brukerens ordvalg ikke matcher dokumentenes språk.
+
+Microsoft-stakken tilbyr flere verktøy for å implementere query understanding: Azure OpenAI for LLM-basert reformulering, Azure AI Search med innebygd fuzzy search og synonym mapping, og Semantic Kernel for orchestration av multi-step query pipelines. Kostnaden varierer basert på tilnærming — regelbaserte transformasjoner er gratis, mens LLM-basert query expansion krever ekstra tokens per spørring (typisk 200-500 input tokens + 100-300 output tokens per reformulering).
+
+## Kjernekomponenter
+
+Query understanding består av flere teknikker som kan kombineres i en pipeline:
+
+### 1. Intent Classification
+
+Klassifisering av brukerens intensjon i forhåndsdefinerte kategorier for å velge riktig retrieval-strategi.
+
+| Kategori | Eksempel | Handling |
+|----------|----------|----------|
+| **Factual lookup** | "Hva er hovedstaden i Frankrike?" | Single-shot keyword search |
+| **Complex analysis** | "Sammenlign økonomiske effekter av X og Y" | Query decomposition + multi-source retrieval |
+| **Troubleshooting** | "Feilen ORA-12154 i produksjon" | Entity extraction → filter på feilkode |
+| **Conversational followup** | "Hva med kostnaden?" | Context integration fra chat history |
+
+**Implementering:** Bruk Azure OpenAI med strukturert output (JSON mode) for å klassifisere intent. Alternativt: lightweight classification model (fine-tuned BERT) for lavere latency.
+
+### 2. Query Expansion
+
+Utviding av spørringen med synonymer, relaterte termer og alternative formuleringer for bredere coverage.
+
+**Teknikker:**
+
+- **Synonym mapping:** Azure AI Search støtter synonym maps — definer f.eks. `"AI, kunstig intelligens, maskinlæring"` for automatisk expansion ved indexing-tid
+- **LLM-basert expansion:** Be GPT om "generer 3-5 alternative formuleringer av dette spørsmålet"
+- **Domain-specific thesaurus:** Bruk bransjespesifikke ordbøker (f.eks. medisinsk terminologi)
+
+**Trade-off:** Økt recall (finner flere relevante dokumenter), men potensielt lavere precision (mer støy). Kombiner med reranking.
+
+### 3. Query Rewriting
+
+Reformulering av spørringen for å adressere problemer som vaghet, manglende keywords, unødvendige ord eller uklar semantikk.
+
+**Anvendelser:**
+
+| Problem | Originalt spørsmål | Rewritten query |
+|---------|-------------------|-----------------|
+| **Vagueness** | "Vis meg skjemaet" | "Vis medarbeider onboarding request form" (fra chat context) |
+| **Stavefeil** | "Azur AI serch" | "Azure AI Search" |
+| **Missing context** | "Hva med kostnaden?" | "Hva er kostnaden for Azure OpenAI GPT-4 i Norge?" |
+| **Unnecessary words** | "Jeg lurer virkelig på om kanskje..." | "Hvilke lisenser trengs for Power Automate AI Builder?" |
+
+**Implementering:** Multi-turn chat med `create_history_aware_retriever` i LangChain/Semantic Kernel — dette genererer standalone queries fra conversation history.
+
+### 4. Sub-query Decomposition
+
+Dekomponering av komplekse spørsmål i flere enkle sub-queries som kjøres uavhengig, deretter aggregering av resultater.
+
+**Eksempel:**
+
+```
+Original: "Hvordan fungerer elbiler, og hvordan sammenlignes de med fossile biler?"
+
+Sub-queries:
+1. "Hvordan fungerer elektriske kjøretøy? Forklar motor og batteri."
+2. "Hva er fordeler og ulemper med elbiler vs bensin/diesel?"
+3. "Sammenlign total eierkostnad for elbil og fossil bil over 5 år"
+```
+
+**Decomposition-strategi:**
+
+1. **Klassifiser** spørringen som "simple" eller "complex" (via LLM prompt)
+2. **Dekomponér** komplekse spørsmål i ordered sub-queries (minst → mest avhengig)
+3. **Kjør** hver sub-query parallelt mot vector store
+4. **Aggregér** top-N resultater fra alle sub-queries som accumulated context
+5. **Kjør** original query med accumulated context til LLM
+
+**Når bruke:** Multi-part questions, sammenligninger, "hvordan X og hva er effekten av Y"-spørsmål.
+
+### 5. Filter Extraction
+
+Identifisering og ekstraksjon av strukturerte filtre fra naturlig språk for metadata-filtrering.
+
+**Eksempler:**
+
+| Spørring | Ekstraherte filtre |
+|----------|-------------------|
+| "Artikler om AI fra siste 6 måneder" | `date >= 2025-08-01` |
+| "Power Automate-dokumentasjon på norsk" | `language = 'no', product = 'Power Automate'` |
+| "Sikkerhetspolicyer for helsesektoren" | `sector = 'healthcare', category = 'security'` |
+
+**Krav:** Metadata må være tilgjengelig i search index (konfigureres ved indexing). Kombiner med Azure AI Search `$filter` parameter.
+
+### 6. HyDE (Hypothetical Document Embeddings)
+
+Teknikk hvor LLM genererer hypotetiske svar på spørringen, deretter brukes embedding av disse svarene (ikke spørringen) til vector search.
+
+**Hvorfor fungerer det:** Answer-to-answer similarity er ofte høyere enn question-to-answer similarity i embedding space.
+
+**Implementering:**
+
+```python
+# 1. Generer hypotetisk svar
+hypothetical_answer = llm.generate(f"Answer this: {user_query}")
+
+# 2. Embed svaret (ikke spørringen)
+answer_embedding = embedding_model.embed(hypothetical_answer)
+
+# 3. Søk mot vector store
+results = vector_store.similarity_search_by_vector(answer_embedding, k=5)
+```
+
+**Trade-off:** Ekstra LLM-kall (kostnad + latency), men potensielt bedre retrieval for ambiguous queries.
+
+## Arkitekturmønstre
+
+### Mønster 1: Single-LLM Query Rewriting
+
+**Beskrivelse:** Én LLM-prompt tar originalspørring + chat history → genererer optimalisert søkequery.
+
+**Fordeler:**
+
+- Enkel å implementere
+- Lavere latency (ett LLM-kall)
+- Kostnadseffektiv
+
+**Ulemper:**
+
+- Kan feile ved komplekse multi-step logic
+- Mindre kontroll over individuelle steg
+
+**Når bruke:** Simple chatbots, enkle FAQs, begrenset domene.
+
+### Mønster 2: Multi-step Pipeline (Intent → Extract → Rewrite)
+
+**Beskrivelse:** Tre sekvensielle LLM-kall: (1) klassifiser intent, (2) ekstraher entities/filters, (3) rewrite basert på (1) og (2).
+
+**Fordeler:**
+
+- Finere kontroll over hvert steg
+- Bedre debugging (kan inspisere output fra hvert steg)
+- Høyere kvalitet for komplekse scenarios
+
+**Ulemper:**
+
+- Høyere latency (3x LLM-kall)
+- Høyere kostnad
+- Mer kompleks kode
+
+**Når bruke:** Support bots, komplekse B2B applications, multi-intent queries.
+
+### Mønster 3: Hybrid (Rules + LLM)
+
+**Beskrivelse:** Regelbaserte transformasjoner for common cases, LLM for edge cases.
+
+```
+IF query matches regex "Hva er <term>?"
+  THEN: Simple keyword search on <term>
+ELSE IF query contains "sammenlign X og Y"
+  THEN: Decompose into [query about X, query about Y]
+ELSE:
+  THEN: LLM-based rewriting
+```
+
+**Fordeler:**
+
+- Optimalt cost/performance ratio
+- Raskere for common patterns (ingen LLM-kall)
+- Deterministisk oppførsel for kjente cases
+
+**Ulemper:**
+
+- Krever vedlikehold av rule set
+- Fallback til LLM kan gi inkonsistens
+
+**Når bruke:** High-volume production systems, kostnadsoptimalisering, deterministic requirements.
+
+## Beslutningsveiledning
+
+### Beslutningstabell: Hvilken teknikk når?
+
+| Scenario | Anbefalt teknikk | Hvorfor |
+|----------|-----------------|---------|
+| Multi-turn chat | Query rewriting med chat history | Kontekstualisering av "Hva med X?" |
+| Stavefeil og typos | Fuzzy search (Azure AI Search innebygd) | Ingen LLM-kostnad, rask |
+| Vage spørsmål | Query expansion + reranking | Bredere coverage → rerank for precision |
+| Komplekse sammenligninger | Sub-query decomposition | Parallell retrieval fra multiple sources |
+| Spesialisert terminologi | Domain-specific synonym maps | Fast, deterministisk |
+| Ambiguous queries | HyDE | Bedre embedding similarity |
+| Filter-baserte spørsmål | Filter extraction + metadata filtering | Direkte $filter på index |
+
+### Vanlige feil
+
+1. **Over-rewriting:** Endrer brukerens intensjon ved aggressiv reformulering
+   - **Løsning:** Behold original query i parallel search, rerank combined results
+2. **Expansion without reranking:** For bredt søk uten prioritering
+   - **Løsning:** Alltid kombiner expansion med cross-encoder reranker
+3. **Missing context in multi-turn:** Glemmer tidligere chat history
+   - **Løsning:** Bruk `ConversationBufferMemory` (LangChain) eller Semantic Kernel chat history
+4. **LLM hallucination i query rewriting:** Legger til fakta som ikke er i original query
+   - **Løsning:** Instruer LLM eksplisitt: "Do NOT add facts not present in the original query"
+5. **Sub-query decomposition for simple queries:** Unødvendig overhead
+   - **Løsning:** Klassifiser query først (simple vs complex) før decomposition
+
+### Røde flagg
+
+- 🚩 **Høy kostnad:** > 1000 tokens per query for rewriting (optimaliser prompts)
+- 🚩 **Latency > 2s:** For mange sekvensielle LLM-kalls (vurder parallelisering eller caching)
+- 🚩 **Retrieval precision < 60%:** Query understanding hjelper ikke hvis underliggende chunks er dårlige
+- 🚩 **User frustration:** Brukere reformulerer spørsmål 3+ ganger → query understanding feiler
+
+## Integrasjon med Microsoft-stakken
+
+### Azure OpenAI
+
+**Query rewriting med chat history:**
+
+```python
+from langchain.chains import create_history_aware_retriever
+from langchain_openai import AzureChatOpenAI
+
+llm = AzureChatOpenAI(
+    azure_deployment="gpt-4",
+    temperature=0
+)
+
+retriever_chain = create_history_aware_retriever(
+    llm=llm,
+    retriever=vector_store.as_retriever(),
+    prompt=ChatPromptTemplate.from_messages([
+        ("system", "Given chat history and latest user question, formulate a standalone question."),
+        MessagesPlaceholder("chat_history"),
+        ("human", "{input}")
+    ])
+)
+```
+
+**Intent classification med structured output:**
+
+```python
+completion = client.chat.completions.create(
+    model="gpt-4",
+    messages=[
+        {"role": "system", "content": "Classify user intent. Return JSON: {\"category\": \"factual|complex|troubleshooting\"}"},
+        {"role": "user", "content": user_query}
+    ],
+    response_format={"type": "json_object"}
+)
+intent = json.loads(completion.choices[0].message.content)["category"]
+```
+
+### Azure AI Search
+
+**Fuzzy search for typos (innebygd):**
+
+```http
+POST https://{search-service}.search.windows.net/indexes/{index-name}/docs/search?api-version=2024-07-01
+{
+  "search": "Azur AI Serch~2",  // ~2 = max 2 edit distance
+  "queryType": "full"
+}
+```
+
+**Synonym mapping:**
+
+```json
+{
+  "name": "ai-synonyms",
+  "format": "solr",
+  "synonyms": [
+    "AI, kunstig intelligens, maskinlæring, machine learning",
+    "RAG, retrieval augmented generation, retrieval-basert generering",
+    "embedding, vektor, vector"
+  ]
+}
+```
+
+Koble til index via `synonymMaps` property på searchable fields.
+
+### Semantic Kernel
+
+**Multi-step query pipeline:**
+
+```csharp
+var kernel = Kernel.CreateBuilder()
+    .AddAzureOpenAIChatCompletion(deploymentName, endpoint, apiKey)
+    .Build();
+
+// Step 1: Intent classification
+var intentPlugin = kernel.ImportPluginFromPromptDirectory("IntentPlugin");
+var intent = await kernel.InvokeAsync(intentPlugin["ClassifyIntent"],
+    new() { ["query"] = userQuery });
+
+// Step 2: Query rewriting based on intent
+var rewritePlugin = kernel.ImportPluginFromPromptDirectory("RewritePlugin");
+var rewrittenQuery = await kernel.InvokeAsync(rewritePlugin[$"Rewrite{intent}"],
+    new() { ["query"] = userQuery, ["history"] = chatHistory });
+
+// Step 3: Execute search with rewritten query
+var results = await vectorStore.SearchAsync(rewrittenQuery.ToString());
+```
+
+### Copilot Studio
+
+**Bruk "Create search query" node:** Automatisk query rewriting med conversation history — no-code løsning.
+
+**Konfigurasjon:**
+
+1. Legg til "Create search query" node i topic
+2. Input: Current user message + conversation history
+3. Output: Rewritten standalone query
+4. Bruk output i "Search" eller "Custom connector" node
+
+### Power Automate med AI Builder
+
+**GPT-vurdering for query classification:** Bruk "Create text with GPT" action til å klassifisere intent før conditional branching.
+
+## Offentlig sektor (Norge)
+
+### Flerspråklige spørsmål
+
+**Utfordring:** Brukere spør på norsk, nynorsk, samisk — dokumenter kan være på engelsk eller blandede språk.
+
+**Løsninger:**
+
+1. **Query translation:** Oversett spørring til engelsk før vector search (hvis dokumenter primært engelsk)
+   ```python
+   translated_query = azure_translator.translate(user_query, to="en")
+   ```
+2. **Multilingual embeddings:** Bruk `text-embedding-3-large` (støtter 100+ språk) — spørring og dokumenter i ulike språk matcher i samme vector space
+3. **Language-specific indexes:** Separate indexes per språk med language-specific analyzers
+
+**Tilgjengelighet:**
+
+- **Klarspråk:** Query rewriting bør forenkle, ikke komplisere — sjekk WCAG 2.1 readability guidelines
+- **Voice input:** Håndter ASR-feil (stavefeil) via fuzzy search
+
+### GDPR og personvern
+
+**Filter ut PII i queries:** Bruk Azure AI Language PII detection på user query FØR logging eller videre prosessering.
+
+```python
+from azure.ai.textanalytics import TextAnalyticsClient
+
+pii_result = text_analytics_client.recognize_pii_entities([user_query])
+redacted_query = pii_result[0].redacted_text  # Bruk denne videre
+```
+
+## Kostnad og lisensiering
+
+### Prismodell
+
+**Query understanding kostnader (per 1000 queries):**
+
+| Tilnærming | Kostnad (NOK) | Latency | Kvalitet |
+|------------|---------------|---------|----------|
+| **Regelbasert (fuzzy, synonyms)** | 0 | ~50ms | Middels |
+| **Single LLM rewrite (GPT-4o-mini)** | ~2 NOK | ~300ms | Høy |
+| **Multi-step pipeline (3x GPT-4o-mini)** | ~6 NOK | ~800ms | Svært høy |
+| **HyDE (GPT-4 Turbo)** | ~15 NOK | ~1.5s | Variabel |
+
+**Antagelser:**
+- GPT-4o-mini: 0.45 NOK / 1M input tokens, 1.80 NOK / 1M output tokens
+- 250 input tokens + 150 output tokens per LLM-kall
+
+### Optimaliseringstips
+
+1. **Cache rewrites:** For common queries, cache rewritten version (Redis/Azure Cache)
+2. **Batch processing:** Ved bulk-queries (f.eks. analytics), batch LLM-calls med `max_tokens` limit
+3. **Fallback til billigere modeller:** GPT-4o-mini for simple rewrites, GPT-4 for complex decomposition
+4. **Prompt optimization:** Reduser system prompt lengde — hver token repeteres per query
+
+### Lisenser
+
+| Komponent | Lisens/SKU |
+|-----------|-----------|
+| **Azure OpenAI** | Pay-as-you-go eller Provisioned Throughput Units (PTU) |
+| **Azure AI Search** | Basic tier støtter synonym maps, Standard+ for semantic ranker |
+| **Semantic Kernel** | Open-source (MIT) — ingen lisenskostnad |
+| **Copilot Studio** | Per user/session (inkludert i M365 Copilot eller standalone) |
+
+**ROI-vurdering:** Query understanding øker retrieval precision med 15-30% (typisk) → færre irrelevante svar → høyere user satisfaction → lavere support cost. Bryt-even oftest ved 5000+ queries/måned.
+
+## For arkitekten (Cosmo)
+
+### Spørsmål å stille kunden
+
+1. **"Hva er typiske brukerqueries i løsningen deres? Kan jeg få 20-50 eksempler?"**
+   - Analysér for common patterns (multi-turn, typos, vage spørsmål)
+2. **"Finnes det bransjespesifikk terminologi eller forkortelser brukerne bruker?"**
+   - Vurdér domain-specific synonym maps eller custom entity extraction
+3. **"Hvor lang chat history er relevant? 3 messages? 10 messages?"**
+   - Påvirker context window size for query rewriting
+4. **"Hva er budsjettet for retrieval per måned? Antall forventede queries?"**
+   - Bestemmer LLM-taktikk (GPT-4 vs GPT-4o-mini vs regelbasert)
+5. **"Hva er akseptabel latency for et søk? 500ms? 2s? 5s?"**
+   - Single-step vs multi-step pipeline trade-off
+6. **"Støtter løsningen kun norsk, eller multiple språk?"**
+   - Multilingual embeddings vs translation-basert approach
+7. **"Hva er konsekvensen av feil retrieval? Kritisk (medical) eller informasjonell?"**
+   - Høy confidence threshold + decomposition for kritiske domener
+8. **"Har dere eksisterende analytics på søkeadferd? Click-through rates?"**
+   - Evaluer current baseline før implementering av query understanding
+
+### Fallgruver
+
+- ❌ **Over-engineering:** Ikke bruk HyDE + decomposition + expansion for enkle FAQ-bots
+- ❌ **Ignoring baseline:** Implementer alltid A/B test: query understanding ON vs OFF
+- ❌ **LLM-avhengighet:** Regelbasert løser 60-70% av cases billigere
+- ❌ **No reranking:** Query expansion uten reranker gir mer støy, ikke bedre svar
+- ❌ **Context loss:** Å "reformulere" kan miste nyanser i original query
+- ❌ **Token bloat:** System prompts på 1000+ tokens repeteres per query — optimaliser
+- ❌ **Single evaluation metric:** Ikke kun precision — vurder recall, MRR, user satisfaction
+
+### Anbefalinger per modenhetsnivå
+
+**Nivå 1 — Starter (MVP):**
+
+- Azure AI Search fuzzy search (innebygd, gratis)
+- Synonym maps for top 10-20 vanlige termer
+- Ingen LLM-basert query understanding (hold kostnad lav)
+
+**Nivå 2 — Etablert (Production):**
+
+- Single LLM rewrite med chat history (GPT-4o-mini)
+- Filter extraction for common metadata (dato, kategori)
+- A/B testing query understanding ON/OFF
+
+**Nivå 3 — Optimert (Enterprise):**
+
+- Multi-step pipeline: Intent → Extract → Rewrite
+- Sub-query decomposition for komplekse spørsmål
+- Cross-encoder reranking
+- Continuous evaluation med precision@k, recall@k, MRR
+
+**Nivå 4 — Avansert (Innovation):**
+
+- HyDE for ambiguous queries
+- Fine-tuned query classifier (BERT) for lavere latency
+- Custom embedding model fine-tuned på domain data
+- Real-time feedback loop (user clicks → retraining signal)
+
+## Multi-Query RAG
+
+### Konsept
+
+Multi-Query RAG genererer *multiple spørringsvariasjoner* fra én brukerquery og kjører dem parallelt mot søkeindeksen. Resultatene dedupliseres og fusjoneres via **Reciprocal Rank Fusion (RRF)** for å gi bredere dekning enn en enkelt query.
+
+### Forskjell fra Query Expansion
+
+| Aspekt | Query Expansion | Multi-Query RAG |
+|--------|----------------|-----------------|
+| **Output** | Én beriket query | Multiple separate queries |
+| **Søk** | Ett søk med utvidet query | Parallelle søk per variant |
+| **Fusjon** | Ikke nødvendig | RRF / set union |
+| **Dekning** | Dypere på ett konsept | Bredere over flere konsepter |
+| **Kostnad** | 1 søk + 1 LLM-kall | N søk + 1 LLM-kall |
+
+### Implementering i Azure
+
+**Steg 1: Generer query-variasjoner med LLM**
+
+```python
+from openai import AzureOpenAI
+
+client = AzureOpenAI(...)
+
+def generate_query_variants(original_query: str, n: int = 3) -> list[str]:
+    response = client.chat.completions.create(
+        model="gpt-4o-mini",
+        messages=[{
+            "role": "system",
+            "content": f"""Generate {n} different search queries that capture
+different aspects of the user's question. Return one query per line.
+Original question: {original_query}"""
+        }],
+        temperature=0.7
+    )
+    variants = response.choices[0].message.content.strip().split("\n")
+    return [original_query] + variants[:n]
+```
+
+**Steg 2: Parallelle søk + RRF-fusjon**
+
+```python
+import asyncio
+from collections import defaultdict
+
+async def multi_query_search(queries: list[str], k: int = 5):
+    # Kjør parallelle søk
+    tasks = [search_async(q, top=k*2) for q in queries]
+    all_results = await asyncio.gather(*tasks)
+
+    # Reciprocal Rank Fusion
+    rrf_scores = defaultdict(float)
+    rrf_constant = 60
+
+    for results in all_results:
+        for rank, doc in enumerate(results):
+            rrf_scores[doc["id"]] += 1.0 / (rank + rrf_constant)
+
+    # Sorter og returner top-k
+    sorted_docs = sorted(rrf_scores.items(), key=lambda x: x[1], reverse=True)
+    return sorted_docs[:k]
+```
+
+### RRF-algoritmen
+
+Azure AI Search bruker allerede RRF internt for hybrid search (BM25 + vektor). Multi-Query RAG legger til et ekstra lag:
+
+```
+RRF_score(d) = Σ_i (1 / (rank_i(d) + k))
+
+hvor:
+  i = indeks over alle queries (original + varianter)
+  rank_i(d) = dokumentets posisjon i query i
+  k = konstant (typisk 60)
+```
+
+### Når bruke Multi-Query RAG
+
+| Scenario | Bruk multi-query? | Begrunnelse |
+|----------|-------------------|-------------|
+| Brede, tematiske spørsmål | Ja | Dekker flere aspekter |
+| Presise, fakta-baserte queries | Nei | Single query er tilstrekkelig |
+| Tvetydig intent | Ja | Varianter fanger ulike tolkninger |
+| Høyt volum (>10K queries/dag) | Vurder kostnad | N×søk-kostnad |
+| Lav recall i eksisterende system | Ja | Øker sannsynlighet for relevante treff |
+
+### Kostnad
+
+Multi-Query RAG med 3 varianter = ~3x søkekostnad + 1 LLM-kall for generering.
+- LLM-kall (gpt-4o-mini): ~0.01 NOK per query
+- Ekstra søk: ~0.03 NOK per ekstra søk
+- **Total ekstra kostnad:** ~0.10 NOK per query (for 3 varianter)
+
+---
+
+## Kilder og verifisering
+
+**Microsoft Learn (Verified — hentet via MCP 2026-02):**
+
+1. [Azure Databricks: Improve RAG chain quality — Query understanding](https://learn.microsoft.com/en-us/azure/databricks/generative-ai/tutorials/ai-cookbook/quality-rag-chain#query-understanding)
+   **Konfidens:** Verified — Multi-step query understanding (intent, entity extraction, rewriting)
+
+2. [Azure Architecture: RAG Information retrieval — Query translation](https://learn.microsoft.com/en-us/azure/architecture/ai-ml/guide/rag/rag-information-retrieval#query-translation)
+   **Konfidens:** Verified — Query augmentation, decomposition, rewriting, HyDE
+
+3. [Azure AI Search: Fuzzy search to correct misspellings and typos](https://learn.microsoft.com/en-us/azure/search/search-query-fuzzy)
+   **Konfidens:** Verified — Fuzzy query expansion med Damerau-Levenshtein distance
+
+4. [Azure AI Search: Simple query syntax](https://learn.microsoft.com/en-us/azure/search/query-simple-syntax)
+   **Konfidens:** Verified — Keyword search, phrase search, boolean operators
+
+5. [Azure Arc Edge RAG: Search type parameters](https://learn.microsoft.com/en-us/azure/azure-arc/edge-rag/search-types#search-type-parameters)
+   **Konfidens:** Verified — Query expansion, sub-query generation, hypothetical answer generation
+
+6. [Copilot Studio: Create search query](https://learn.microsoft.com/en-us/microsoft-copilot-studio/authoring-create-search-query)
+   **Konfidens:** Verified — No-code query rewriting med conversation history
+
+**RAG Experiment Accelerator (GitHub — Microsoft):**
+
+7. [microsoft/rag-experiment-accelerator](https://github.com/microsoft/rag-experiment-accelerator)
+   **Konfidens:** Verified — Query classification, decomposition, rewriting prompts (Python)
+
+**Seksjoner med baseline-kunnskap (modellkunnskap, ikke MCP-verifisert):**
+
+- **Semantic Kernel C# eksempel:** Baseline — ikke funnet i MCP-søk, basert på SK pattern library
+- **Token cost estimater:** Baseline — basert på Azure OpenAI pricing (januar 2026)
+- **ROI-tall (15-30% precision improvement):** Baseline — industry benchmarks, ikke Microsoft-spesifikk data
+
+**Totalt antall kilder:** 7 Microsoft Learn URLer (Verified) + 1 GitHub repo (Verified) = 8 kilder