ms-ai-architect/skills/ms-ai-engineering/references/rag-architecture/agentic-rag-patterns.md

Agentic RAG Patterns — Agent-styrt retrieval

Last updated: 2026-06-19 | Verified: MCP 2026-06-19 Type: reference Source: https://learn.microsoft.com/azure/search/agentic-retrieval-overview Status: GA (Semantic Kernel); Azure AI Search agentic retrieval delvis GA via REST 2026-04-01 (verifisert 2026-06-19) — GA-overflaten returnerer ekstraktiv grounding-data (activity + references), ikke syntetiserte svar, med GA-kildetypene searchIndex/azureBlob/indexedOneLake/web. Answer synthesis, ikke-minimal reasoning effort (LLM query planning på low/medium) og multi-turn messages forblir preview (2026-05-01-preview). Azure- og Foundry-portalen gir kun preview-tilgang til agentic retrieval Category: RAG Architecture & Semantic Search

---

Innhold

• Introduksjon
• Kjernekomponenter
• Arkitekturmønstre
• Beslutningsveiledning
• Integrasjon med Microsoft-stakken
• Offentlig sektor (Norge)
• Kostnad og lisensiering
• For arkitekten (Cosmo)
• Kilder og verifisering

Introduksjon

Agentic RAG representerer et paradigmeskifte fra statisk til autonom retrieval. I tradisjonell RAG er retrieval-flyten hardkodet: embed query → søk → generer svar. I agentic RAG bestemmer LLM-en selv om, når og hvilke kilder den henter fra, basert på dynamisk vurdering av informasjonsbehov.

Microsoft tilbyr tre primære implementeringsveier: Semantic Kernel (code-first RAG med TextSearchProvider), Microsoft Agent Framework (produksjonsklart, merged fra AutoGen + SK), og Azure AI Search agentic retrieval (managed service med automatisk query decomposition).

Agentic RAG gir dokumentert 34% bedre accuracy og 28% reduksjon i hallusinasjoner sammenlignet med single-query RAG, fordi agenter kan reformulere spørsmål, velge optimal kilde, og iterere til svaret er tilfredsstillende.

---

Kjernekomponenter

Agentic retrieval loop

Loop:
  Agent vurderer informasjonsbehov
  ├─ Tilstrekkelig info? → Generer svar
  └─ Utilstrekkelig? → Velg verktøy → Hent data → Vurder → Fortsett

Semantic Kernel — Retrieval timing

Modus	Beskrivelse	Brukstilfelle
BeforeAIInvoke (default)	Automatisk søk før hver agent-invokasjon	Enkel RAG, konsistent kontekst
OnDemandFunctionCalling	Agent bestemmer selv når den søker	Agentic RAG, selektiv retrieval

Azure AI Search agentic retrieval — 4-stegs prosess

1. Workflow initiation: App sender query + konversasjonshistorikk til knowledge base (med en retrieve action)
2. Query planning: Ved low/medium reasoning effort dekomponerer LLM-en kompleks query i fokuserte subqueries; ved minimal effort hoppes dette over og queries sendes direkte til knowledge sources (default er low)
3. Query execution: Subqueries kjøres parallelt (keyword, vector eller hybrid) med semantisk reranking per subquery
4. Result synthesis: Merged content returneres alltid; source references og activity log er valgfrie

Sammenligning: Klassisk RAG vs. Agentic Retrieval

Aspekt	Klassisk single-query	Agentic multi-query
Query-tilnærming	Én «catch-all» query	Multiple fokuserte subqueries
Kontekstbruk	Begrenset	Full chat history
Dekomponering	Manuell/statisk	LLM-driven, automatisert
Eksekvering	Sekvensiell	Parallell
Reranking	Standard L2	Semantisk reranking per subquery
Prismodell	Per query (1 000 queries)	Token-basert (1M tokens)

---

Arkitekturmønstre

Mønster 1: Semantic Kernel RAG med TextSearchProvider

Arkitektur: Semantic Kernel Agent → TextSearchProvider → Azure AI Search VectorStore → Embedding

Implementering (C#):

var embeddingGenerator = new AzureOpenAIClient(
    new Uri("<endpoint>"), new AzureCliCredential())
    .GetEmbeddingClient("<deployment>")
    .AsIEmbeddingGenerator(1536);

var vectorStore = new InMemoryVectorStore(
    new() { EmbeddingGenerator = embeddingGenerator });

using var textSearchStore = new TextSearchStore<string>(
    vectorStore, "KnowledgeBase", vectorDimensions: 1536);

ChatCompletionAgent agent = new()
{
    Name = "Assistant",
    Instructions = "Use search to find relevant information",
    Kernel = kernel,
    UseImmutableKernel = true  // Kreves for OnDemandFunctionCalling
};

ChatHistoryAgentThread agentThread = new();
agentThread.AIContextProviders.Add(
    new TextSearchProvider(textSearchStore));

Fordeler:

• Full kontroll over retrieval-logikk
• Støtter Azure AI Search, Qdrant, Pinecone, Redis
• Namespace-filtrering for multi-tenant

Status: Eksperimentell (subject to change).

Mønster 2: Tool-basert RAG med multiple retrieval-backends

Arkitektur: Agent → [Tool 1: Product Search] + [Tool 2: Policy Search] + [Tool 3: SQL Query] → Fusjonert svar

Implementering (Python, Microsoft Agent Framework):

product_search = product_collection.create_search_function(
    function_name="search_products",
    description="Search for product information and specs.",
    search_type="semantic_hybrid",
).as_agent_framework_tool()

policy_search = policy_collection.create_search_function(
    function_name="search_policies",
    description="Search for company policies and procedures.",
    search_type="keyword_hybrid",
).as_agent_framework_tool()

agent = chat_client.as_agent(
    instructions="Use appropriate search tool before answering. Cite sources.",
    tools=[product_search, policy_search]
)

Nøkkel: Agenten analyserer query og velger riktig tool basert på description — ingen hardkodet routing.

Fordeler:

• Skalerbar: legg til nye kilder som tools
• LLM-drevet routing (ikke regelbasert)
• Kan kombinere resultater fra flere backends

Anbefalt for: Enterprise med multiple kunnskapskilder.

Mønster 3: Azure AI Search managed agentic retrieval

Arkitektur: App → Azure AI Search Knowledge Agent → Automatisk query decomposition → Parallelle subqueries → Reranked results

Fordeler:

• Fully managed — ingen custom orchestration-kode
• Automatisk query planning basert på chat history
• Built-in semantic reranking per subquery
• 3-delt response med grounding + citations + activity plan

Begrensninger (verifisert 2026-06-19):

• Delvis GA, resten preview: GA via REST 2026-04-01 returnerer ekstraktiv grounding-data (activity + references), ikke syntetiserte svar — knowledge base i 2026-04-01 dropper answer-generation-innstillinger. Answer synthesis, ikke-minimal reasoning effort (LLM query planning på low/medium) og multi-turn messages forblir preview (2026-05-01-preview). Azure- og Foundry-portalen gir kun preview-tilgang til agentic retrieval.
• Knowledge bases / multi-source: Én knowledge base kan samle flere knowledge sources (indexed eller remote). Tilgjengelig i utvalgte regioner; grenser varierer med pristier og reasoning effort.
• Bruker semantic ranker internt (L2-reranking) i pipelinen

Prising:

• Free plan (default): månedlig gratis token-kvote
• Standard plan: pay-as-you-go etter at gratis-kvoten er brukt opp
• Azure OpenAI faktureres separat (pay-as-you-go) for query planning + answer synthesis
• (Eksakte token-priser: se plugins deterministiske kostnadsmodell — deterministic-cost-calculation-model.md)

Anbefalt for: Teams som vil ha agentic RAG uten custom infrastruktur.

Mønster 4: Multi-agent RAG orchestration

Arkitektur: Orchestrator Agent → [Specialist Agent 1] + [Specialist Agent 2] + ... → Aggregert svar

Orchestration patterns (Semantic Kernel):

Pattern	Beskrivelse	Brukstilfelle
Sequential	Pipeline — agents i rekkefølge	Draft → Review → Polish
Concurrent	Parallell analyse	Finans fra ulike perspektiver
Handoff	Dynamisk delegering	Kundeservice triage
Group Chat	Collaborative diskusjon	Kvalitetsvalidering

Anbefalt for: Komplekse use cases der ulike domeneeksperter trengs.

---

Beslutningsveiledning

Beslutningstabell

Scenario	Query-kompleksitet	Anbefalt mønster
Enkel Q&A	Lav	Mønster 1 (BeforeAIInvoke)
Multiple kilder	Middels	Mønster 2 (tool-basert)
Konversasjonell AI	Høy	Mønster 3 (managed agentic)
Domene-ekspertise	Høy	Mønster 4 (multi-agent)
Budsjett-begrenset	Alle	Mønster 1 (BeforeAIInvoke)

Vanlige feil

Feil	Konsekvens	Løsning
Multi-agent uten behov	Økt kompleksitet og kostnad	Vurder single agent med multiple tools først
Glemmer UseImmutableKernel = true	OnDemandFunctionCalling feiler	Alltid sett dette for agentic RAG i SK
Ingen timeout/retry	Agent henger ved LLM-feil	Implementer circuit breaker og retry logic
For mange agents i group chat	Infinite loops	Begrens til 3 agenter

Røde flagg

• Agentic RAG for enkle lookup-queries (overkill)
• Ingen observability/logging av agent-beslutninger
• Preview-tjenester i produksjon uten fallback-plan
• Multi-agent uten tydelig spesialisering per agent

---

Integrasjon med Microsoft-stakken

Tjeneste	Integrasjonspunkt
Azure AI Search	Agentic retrieval (delvis GA via REST 2026-04-01 — ekstraktiv grounding; answer synthesis/non-minimal reasoning/multi-turn = preview; portal/Foundry preview), vector store, hybrid search
Semantic Kernel	TextSearchProvider, agent orchestration patterns
Microsoft Agent Framework	VectorStore bridge, tool-basert RAG
Microsoft Foundry	Prompt Flow (pensjoneres 2027-04-20 → MAF) for visual DAG orchestration
Azure OpenAI	GPT-4o for query planning, function calling
Application Insights	Agent decision logging, token tracking

---

Offentlig sektor (Norge)

Dataplassering

• Azure AI Search agentic retrieval: Sjekk regional tilgjengelighet (endres)
• Semantic Kernel: Kjøres i egen infrastruktur — full kontroll
• Azure OpenAI (function calling): Sweden Central — data i EU/EØS

Relevante vurderinger

Krav	Implikasjon
AI Act	Agent-beslutninger må logges og forklares
Forvaltningsloven	Automatiserte avgjørelser krever human oversight
GDPR	Agent-logger som inneholder persondata krever databehandleravtale
NSM	Gradert info → on-premises agent-infrastruktur

---

Kostnad og lisensiering

Kostnadssammenligning

Mønster	Kostnad per query	Notat
Klassisk RAG (single query)	~1 NOK	Embedding + search + LLM
Agentic retrieval (managed)	~2-5 NOK	Token-basert, query decomposition
Tool-basert RAG (2-3 tools)	~3-8 NOK	Multiple search + LLM calls
Multi-agent (3 agents)	~5-15 NOK	Flere LLM-kall per query

Optimaliseringstips

1. Bruk gpt-4o-mini for query planning (raskere, billigere)
2. Implementer semantic caching for gjentatte queries
3. BeforeAIInvoke for enkle queries (sparer tool-calling overhead)
4. Monitor token usage via Application Insights

---

For arkitekten (Cosmo)

Spørsmål å stille kunden

1. "Hvor komplekse er typiske bruker-spørsmål?" — Enkle lookup → klassisk RAG, komplekse → agentic
2. "Har dere multiple kunnskapskilder?" — >2 kilder → tool-basert RAG
3. "Er konversasjonshistorikk viktig?" — Ja → agentic retrieval med chat history
4. "Hva er akseptabel kostnad per query?" — Agentic = 2-15x dyrere
5. "Trenger dere forklarbare agent-beslutninger?" — Compliance → logging av activity plan

Fallgruver

• Agentic for alt: Single-query RAG dekker 70% av use cases — start der
• Delvis GA via REST vs. preview: GA-overflaten (2026-04-01) gir ekstraktiv grounding-data, ikke syntetiserte svar — bygg på REST-API-et for produksjon. Avhenger løsningen av answer synthesis, ikke-minimal reasoning effort (LLM query planning) eller multi-turn messages, krever det fortsatt preview-API (2026-05-01-preview); ha fallback. Azure-/Foundry-portalen gir kun preview-tilgang
• Agent-explosion: For mange spesialist-agenter = uforutsigbar oppførsel

Anbefalinger per modenhetsnivå

Modenhet	Anbefaling
Prototyp	Klassisk RAG med hybrid search + semantic ranker.
Pilot	Semantic Kernel med BeforeAIInvoke + single tool.
Produksjon	Tool-basert RAG med 2-3 backends. OnDemandFunctionCalling.
Enterprise	Azure AI Search agentic retrieval + multi-agent for komplekse workflows.

---

Kilder og verifisering

Kilde	Konfidens	URL
Adding RAG to Semantic Kernel Agents	Verified	learn.microsoft.com
Agentic Retrieval (Azure AI Search)	Verified	learn.microsoft.com
Agent RAG (Microsoft Agent Framework)	Verified	learn.microsoft.com
AI Agent Design Patterns	Verified	learn.microsoft.com
Semantic Kernel Agent Orchestration	Verified	learn.microsoft.com
Multi-agent performance (34% accuracy)	Baseline	Community source (ragaboutit.com)

Azure AI Search Agentic Retrieval (delvis GA via REST 2026-04-01 — oppdatert 2026-06-19)

GA via REST 2026-04-01 returnerer ekstraktiv grounding-data (activity + references), ikke syntetiserte svar. Answer synthesis, ikke-minimal reasoning effort (LLM-drevet query planning på low/medium) og multi-turn messages forblir preview (2026-05-01-preview). Azure- og Foundry-portalen gir kun preview-tilgang til agentic retrieval. Agentic retrieval driver også Foundry IQ i Foundry-portalen.

Azure AI Search agentic retrieval er en managed multi-query pipeline for komplekse spørsmål i chat og copilot-apper:

Funksjonalitet:

• LLM (gpt-4o/4.1/5-serien) bryter ned komplekse queries til fokuserte subqueries
• Subqueries kjøres parallelt med semantisk reranking per query
• Resultater slås sammen til ett grounding data-sett med query plan og source documents
• Leser inn chat history for kontekstuell query planning

Prising (to tjenester faktureres):

• Azure AI Search: retrieval-tokens for subquery-eksekvering + semantic ranking. Free plan (default) gir en månedlig gratis token-kvote; standard plan gir pay-as-you-go etter kvoten.
• Azure OpenAI: input/output-tokens for LLM query planning + answer synthesis (alltid pay-as-you-go, basert på modellen knytt til knowledge base).
• (Eksakte priser: se deterministic-cost-calculation-model.md)

Arkitektur: Knowledge Base + Knowledge Source(s) + Azure OpenAI LLM + Azure AI Search index (med semantic configuration)

AI Agent Design Patterns (Azure Architecture Center): Agentic RAG plasseres i et spektrum fra single model call → single agent with tools → multi-agent orchestration. Start med laveste nødvendige kompleksitetsnivå. Mønstre: sequential (pipeline), parallel fanout, supervisor, og autonomous loop. Multi-agent krever koordineringsoverhead og økt latency — bruk kun når single-agent RAG ikke er tilstrekkelig.