Updates across all 5 skills: ms-ai-advisor, ms-ai-engineering, ms-ai-governance, ms-ai-security, ms-ai-infrastructure. Key changes: - Language Services (Custom Text Classification, Text Analytics, QnA): retirement warning 2029-03-31, migration guides to Foundry/GPT-4o - Agentic Retrieval: 50M free reasoning tokens/month (Public Preview) - Computer Use: Claude Sonnet 4.5 (preview) + OpenAI CUA models - Agent Registry: Risks column (M365 E7), user-shared/org-published types - Declarative agents: schema v1.5 → v1.6, Store validation requirements - MLflow 3: 13 built-in LLM judges, production monitoring, Genie Code - AG-UI HITL: ApprovalRequiredAIFunction (C#) + @tool(approval_mode) (Python) - Entra ID Ignite 2025: Agent ID Admin/Developer RBAC roles, Conditional Access - Security Copilot: 400 SCU/month per 1000 M365 E5 licenses, auto-provisioned - Fast Transcription API: phrase lists, 14-language multi-lingual transcription - Azure Monitor Workbooks: Bicep support, RBAC specifics - Power Platform Copilot: data residency (Norway/Europe → EU DB, Bing → USA) - RAG security-rbac: 4-approach table (GA + 3 preview access control methods) - IaC MLOps: Well-Architected OE:05 principles, Bicep/Terraform patterns - Translator: image file batch translation Preview (JPEG/PNG/BMP/WebP) All 106 files: Last updated 2026-04 | Verified: MCP 2026-04 Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
20 KiB
Iterative RAG and Multi-Turn Refinement
Last updated: 2026-04 | Verified: MCP 2026-04 Status: GA Category: RAG Architecture & Semantic Search
Introduksjon
Iterative RAG (Retrieval-Augmented Generation) med multi-turn refinement representerer en avansert tilnærming til samtalebaserte AI-systemer der kontekst og relevans forbedres progressivt over flere interaksjoner. I motsetning til single-shot RAG, hvor ett spørsmål fører til én retrieval og ett svar, tillater iterative RAG-systemer at brukeren kan forfine, utdype eller endre retning på spørsmål basert på tidligere svar — samtidig som systemet vedlikeholder kontekst og akkumulerer kunnskap gjennom samtalen.
Dette mønsteret er spesielt viktig for komplekse scenarioer hvor brukeren ikke kan formulere hele informasjonsbehovet i ett spørsmål, eller hvor forståelsen av domenet utvikler seg underveis. Eksempler inkluderer research-assistenter, teknisk support, saksbehandling i offentlig sektor, og beslutningsstøttesystemer hvor flere iterasjoner er nødvendig for å finne riktig løsning.
Multi-turn refinement innebærer ikke bare å huske historikk, men å aktivt bruke tidligere samtalekontext til å forbedre både retrieval-kvalitet og response-generering. Dette kan inkludere coreference resolution (å forstå "den første" som referanse til pizza i tidligere svar), query refinement basert på feedback, og akkumulering av strukturert kontekst som beslutninger, krav og handlinger på tvers av mange meldinger.
Kjernekomponenter
Iterative RAG-systemer består av flere integrerte komponenter som jobber sammen for å vedlikeholde context og forbedre svar over tid:
| Komponent | Funksjon | Microsoft-implementering |
|---|---|---|
| Conversation History Management | Lagrer og organiserer samtalehistorikk (bruker-, assistent- og systemmeldinger) | ChatHistory (Semantic Kernel), AgentSession (Agent Framework) |
| Context Persistence | Vedlikeholder state mellom requests, enten in-memory, i database eller i service | Azure Cosmos DB, AgentSession, Azure AI Agent Service |
| Refinement Loops | Tillater iterativ forbedring av queries basert på feedback og tidligere svar | create_history_aware_retriever() (LangChain), Semantic Kernel chat history reduction |
| Relevance Feedback | Samler eksplisitt (thumbs up/down) eller implisitt (follow-up questions) feedback | Azure Cosmos DB feedback collection, telemetri via Azure Monitor |
| Session State | Holder session-spesifikk metadata som bruker-ID, preferences, og kort-/langtidsminne | AgentSession.Serialize(), WhiteboardProvider (Semantic Kernel) |
| Query Rewriting | Omskriver brukerens oppfølgingsspørsmål til standalone queries som inkluderer context | History-aware retriever chains, prompt engineering med chat history |
| Context Window Management | Håndterer token limits ved truncation, summarization, eller sliding window | ChatHistoryTruncationReducer, ChatHistorySummarizationReducer |
Stateful vs. Stateless Services
Microsoft-stakken tilbyr to fundamentalt ulike tilnærminger til multi-turn conversations:
Stateless (client-managed history):
- Chat history lagres på klientsiden eller i app-lag
- Hele historikken sendes til service ved hver request
- Gir full kontroll over historikk og state
- Eksempler: Azure OpenAI Chat Completions, Semantic Kernel
ChatCompletionAgent
Stateful (service-managed history):
- Chat history lagres i servicen (Azure AI Agent Service, Copilot Studio)
- Kun en referanse (conversation ID) sendes ved hver request
- Reduserer payload size og token usage
- Automatisk state management og persistering
- Eksempler: Azure AI Agent Service, Copilot Studio topics
Valg mellom stateless og stateful avhenger av krav til kontroll, compliance (datalagring), og skaleringsscenario.
Arkitekturmønstre
1. Sliding Window with Summarization
Konsept: Behold de N siste meldingene i full form, og komprimer eldre meldinger til en oppsummering.
Fordeler:
- Balanserer kontekstrikhet med token-effektivitet
- Bevarer nylig kontekst i detalj mens eldre kontekst komprimeres
- Fungerer godt for lange samtaler (>20 turns)
Ulemper:
- Summarization kan miste viktige detaljer
- Krever ekstra LLM-kall for å generere sammendrag
- Vanskeligere å debugge enn ren truncation
Microsoft-implementering:
// Semantic Kernel ChatHistorySummarizationReducer
var reducer = new ChatHistorySummarizationReducer(
chatCompletionService,
targetCount: 10, // Behold 10 meldinger
thresholdCount: 15 // Trigger reduction ved 15 meldinger
);
var reducedHistory = await reducer.ReduceAsync(chatHistory);
Når bruke:
- Lange support-samtaler eller research sessions
- Når token cost er en concern
- Scenarioer med mange context switches
2. Whiteboard Memory (Selective Context Extraction)
Konsept: Ekstraherer og vedlikeholder kun de mest kritiske elementene fra samtalen (requirements, decisions, actions) i et separat "whiteboard" som alltid inkluderes.
Fordeler:
- Bevarer kun det som er viktig for oppgaven
- Reduserer token usage drastisk
- Fungerer godt sammen med truncation (whiteboard + siste N meldinger)
Ulemper:
- Krever AI-modell for å identifisere viktig informasjon
- Kan miste kontekstuell nyanse
- Kompleks implementering
Microsoft-implementering:
// Semantic Kernel WhiteboardProvider
var whiteboardProvider = new WhiteboardProvider(
chatCompletionService,
options: new WhiteboardProviderOptions
{
MaxWhiteboardMessages = 5
}
);
// Whiteboard oppdateres automatisk når meldinger legges til AgentThread
Når bruke:
- Task-orienterte conversations (booking, form filling)
- Når chat history må truncates aggressivt
- Multi-agent scenarios hvor state må deles
3. History-Aware Retrieval Chain
Konsept: Omskriver oppfølgingsspørsmål til standalone queries som inkluderer nødvendig context fra historikk før retrieval.
Fordeler:
- Forbedrer retrieval-kvalitet for follow-up questions
- Løser coreference ("the first one", "that approach")
- Ingen manuell query rewriting nødvendig
Ulemper:
- Ekstra latency (query rewrite før retrieval)
- Krever god prompt engineering
- Kan feiltolke intent ved komplekse samtaler
Microsoft-implementering:
# LangChain med Azure DocumentDB
from langchain.chains import create_history_aware_retriever
retriever_chain = create_history_aware_retriever(
llm=azure_openai_chat,
retriever=vector_store_retriever,
prompt=history_prompt # Prompt som lager standalone query fra history
)
Når bruke:
- RAG-systemer med multi-turn questions
- Research assistants og exploratory search
- Når brukere ofte følger opp med "tell me more" eller "what about X?"
Beslutningsveiledning
Valg av Context Persistence Strategy
| Scenario | Anbefalt Mønster | Begrunnelse |
|---|---|---|
| Chat-bot med <10 turns per session | In-memory history (stateless) | Enkel implementering, lav latency |
| Long-running support sessions (>20 turns) | Cosmos DB + summarization | Persistering + token efficiency |
| Multi-agent orchestration | Whiteboard memory + shared state | Agents trenger felles context |
| RAG med follow-up questions | History-aware retrieval | Bedre retrieval for contextual queries |
| Compliance-kritisk (offentlig sektor) | Cosmos DB med audit log | Full sporbarhet og GDPR compliance |
| High-volume, low-cost | Truncation + stateful service | Minimal state footprint |
Vanlige Feil
| Feil | Symptom | Løsning |
|---|---|---|
| Ubounded history growth | Token limits, høy cost, latency | Implementer truncation eller summarization |
| System messages ikke preservert | Inconsistent agent behavior | Bruk reducers som alltid beholder system messages |
| Context loss ved truncation | Agent "glemmer" viktige detaljer | Bruk whiteboard memory eller summarization |
| Dårlig retrieval for follow-ups | "The first option" gir irrelevante docs | Implementer history-aware retrieval |
| State ikke persistert | Samtale ikke resumable | Lagre session state i Cosmos DB |
| Overhead fra full history | Høy latency, dyre API calls | Vurder stateful service (AI Agent Service) |
Røde Flagg
- ❌ Sender hele conversation history (1000+ messages) til LLM uten reduction
- ❌ Ingen strategi for token limit overskridelse
- ❌ Lagrer chat history uten GDPR-compliant retention policy
- ❌ Ignorerer coreference i follow-up queries (retrieval feiler)
- ❌ In-memory state uten persistering (sessions lost ved restart)
- ❌ Ingen user feedback loop for relevance tuning
Integrasjon med Microsoft-stakken
Semantic Kernel
ChatHistory Management:
// Opprett og vedlikehold chat history
var chatHistory = new ChatHistory();
chatHistory.AddSystemMessage("You are a helpful assistant.");
chatHistory.AddUserMessage("What's available to order?");
// Send til chat completion med full history
var response = await chatCompletionService.GetChatMessageContentAsync(
chatHistory,
kernel: kernel
);
chatHistory.Add(response);
Chat History Reduction:
// Truncation reducer
var truncationReducer = new ChatHistoryTruncationReducer(
targetCount: 10,
thresholdCount: 15
);
// Summarization reducer
var summarizationReducer = new ChatHistorySummarizationReducer(
chatCompletionService,
targetCount: 10,
thresholdCount: 15
);
// Begge preserverer alltid system messages
var reducedHistory = await reducer.ReduceAsync(chatHistory);
Agent Framework
Multi-turn Conversations:
// Opprett session for state management
AgentSession session = await agent.CreateSessionAsync();
// Multi-turn conversation - session holder state
var response1 = await agent.RunAsync("Tell me a joke about a pirate.", session);
var response2 = await agent.RunAsync("Now add some emojis.", session);
// Serializer session for persistering
JsonElement serializedSession = session.Serialize();
// Deserialiser for å resume conversation
AgentSession resumedSession = await agent.DeserializeSessionAsync(serializedSession);
Multiple Independent Conversations:
// Én agent, to uavhengige sessions
AgentSession session1 = await agent.CreateSessionAsync();
AgentSession session2 = await agent.CreateSessionAsync();
await agent.RunAsync("Tell me a joke about a pirate.", session1);
await agent.RunAsync("Tell me a joke about a robot.", session2);
// Sessions er helt uavhengige
Azure Cosmos DB
Chat History Storage:
// Azure OpenAI Web App environment variables
{
"AZURE_COSMOSDB_ACCOUNT": "myaccount",
"AZURE_COSMOSDB_DATABASE": "db_conversation_history",
"AZURE_COSMOSDB_CONTAINER": "conversations"
}
Feedback Collection:
{
"AZURE_COSMOSDB_ENABLE_FEEDBACK": "True"
}
Fordeler:
- Global distribution for lav latency
- Automatic scaling
- GDPR-compliant data retention policies
- Integration med Azure OpenAI Web App
Copilot Studio
- Topics holder conversation state automatisk
- Entities ekstraheres og persisteres på tvers av turns
- Conversation variables lagrer user preferences og context
- Multi-turn dialogs styres via topic flow med branching
Offentlig Sektor (Norge)
GDPR og Samtalehistorikk
Art. 6 - Rettslig grunnlag:
- Behandling av chat history må ha lovlig grunnlag (samtykke, avtale, eller offentlig myndighetsutøvelse)
- Offentlige etater: Ofte behandling for å utføre oppgave i allmennhetens interesse (Art. 6(1)(e))
Art. 17 - Rett til sletting:
- Brukere skal kunne slette conversation history på forespørsel
- Implementer
DELETEendpoint for session data i Cosmos DB - Vurder automatisk sletting etter X dager (dataminimering)
Art. 5 - Dataminimering:
- Ikke lagre mer chat history enn nødvendig for formålet
- Bruk summarization/truncation ikke bare for token efficiency, men også for compliance
- Vurder anonymisering av chat logs for analytics
Teknisk implementering:
// GDPR-compliant session management
public async Task DeleteUserConversationHistoryAsync(string userId)
{
var container = cosmosClient.GetContainer(databaseId, containerId);
// Slett alle conversations for user
var query = container.GetItemLinqQueryable<ConversationSession>()
.Where(s => s.UserId == userId);
await foreach (var session in query.ToFeedIterator())
{
await container.DeleteItemAsync<ConversationSession>(
session.Id,
new PartitionKey(session.UserId)
);
}
}
// Automatisk retention policy (30 dager)
public async Task ApplyRetentionPolicyAsync()
{
var cutoffDate = DateTime.UtcNow.AddDays(-30);
var query = container.GetItemLinqQueryable<ConversationSession>()
.Where(s => s.LastUpdated < cutoffDate);
// Slett gamle sessions
}
Data Processor Agreement (DPA):
- Azure Cosmos DB og Azure OpenAI er dekket av Microsofts DPA
- Verifiser at data residency er EU (Norway East / West Europe)
Tilgjengelighetskrav
- Chat history UI må være skjermleservennlig (WCAG 2.1 AA)
- Brukere må kunne eksportere conversation history i lesbart format (PDF/JSON)
- Feedback-mekanismer må være tilgjengelige for alle brukere
Kostnad og Lisensiering
Prismodell-oversikt (NOK, estimert)
Token Costs - Akkumulert bruk:
| Scenario | Gjennomsnittlig tokens per turn | 10 turns cost | 50 turns cost | Optimalisering |
|---|---|---|---|---|
| No reduction (full history) | 500 (turn 1) → 5000 (turn 10) | ~300 NOK | ~3000 NOK | ❌ Uholdbart |
| Truncation (last 5 messages) | 500 → 2500 (steady state) | ~150 NOK | ~750 NOK | ✅ 75% saving |
| Summarization | 500 → 1500 (summary + recent) | ~100 NOK | ~500 NOK | ✅ 83% saving |
| Whiteboard memory | 500 → 1000 (whiteboard + last 3) | ~60 NOK | ~300 NOK | ✅ 90% saving |
Basert på GPT-4 pricing (~0.6 NOK per 1000 tokens, både input og output)
Cosmos DB Storage:
- ~10 NOK per GB per måned (autoscale)
- Typical chat session: 10-50 KB
- 10 000 sessions: ~300 NOK/måned
Azure AI Agent Service:
- Stateful service inkluderer hosting av conversation state
- Pricing er per request + token usage (varierer etter region)
- Kan være mer kostnadseffektivt enn self-hosted Cosmos DB for high-volume scenarios
Optimaliseringstips
- Kombiner truncation og summarization: Behold last 3 messages full + summary av resten
- Bruk streaming for bedre UX: Latency føles kortere selv om token cost er lik
- Implementer user feedback tidlig: Tuning basert på feedback reduserer unødvendige refinement loops
- Vurder Haiku/Sonnet for summarization: GPT-3.5 for summaries, GPT-4 for response generation
- Sett session TTL i Cosmos DB: Auto-delete etter X dager sparer storage cost
For arkitekten (Cosmo)
Spørsmål til kunden
- Hvor lange forventer dere at conversations vil være? (Påvirker valg av reduction strategy)
- Må conversation history være resumable på tvers av sessions/enheter? (Cosmos DB ja/nei)
- Hvor viktig er det å bevare full historikk for audit/compliance? (Påvirker retention policy)
- Har dere brukere som ofte stiller follow-up questions i RAG-scenarioer? (History-aware retrieval)
- Hva er budsjettet for token usage per session? (Påvirker aggressivitet i reduction)
- Trenger dere multi-agent orchestration med shared context? (Whiteboard memory anbefalt)
- Skal brukere kunne gi feedback på svar-kvalitet? (Cosmos DB feedback collection)
- Er dette et high-volume scenario (>10k samtidige users)? (Vurder stateful service)
Fallgruver
- Anti-pattern: "Vi tar full history så lenge det er innenfor token limit" → Fører til ustabil oppførsel når limit nås, og høye kostnader.
- Anti-pattern: "Vi bruker in-memory state for production" → Sessions lost ved restart/scale-out.
- Anti-pattern: "Vi truncater vilkårlig uten å preservere system messages" → Agent behavior blir inkonsistent.
- Undervurdere compliance-krav: Offentlig sektor må ha GDPR-compliant retention og deletion fra dag 1.
- Overse coreference resolution: RAG-systemer fungerer dårlig uten history-aware retrieval.
Anbefalinger per modenhetsnivå
Pilot / POC:
- Start med in-memory
ChatHistory(stateless) - Bruk enkel truncation (last 10 messages)
- Ikke optimaliser for cost ennå
- ✅ Rask time-to-value
Production MVP:
- Implementer Cosmos DB for persistering
- Legg til
ChatHistoryTruncationReducer - Sett opp retention policy (30-90 dager)
- Implementer user feedback collection
- ✅ Compliant og skalerbart
Mature / High-Scale:
- Kombiner whiteboard memory + summarization
- Implementer history-aware retrieval for RAG
- Vurder stateful service (Azure AI Agent Service) for cost efficiency
- Advanced telemetri og tuning basert på user behavior
- ✅ Optimalisert for cost og kvalitet
Kilder og verifisering
Microsoft Learn (Verified - fra MCP research)
| URL | Tema | Confidence |
|---|---|---|
| Multi-turn conversations with an agent | Agent Framework session management | Verified |
| Chat history (Semantic Kernel) | ChatHistory API, reduction strategies | Verified |
| Using memory with Agents | Whiteboard memory, memory providers | Verified |
| Use the Azure OpenAI web app | Cosmos DB chat history enablement | Verified |
| RAG with Azure DocumentDB | History-aware retrieval chains | Verified |
| Storing Chat History in 3rd Party Storage | Custom ChatHistoryProvider | Verified |
| IChatClient documentation | Stateless vs stateful clients | Verified |
Confidence per seksjon
| Seksjon | Confidence | Kilde |
|---|---|---|
| Kjernekomponenter | Verified | Microsoft Learn + kodeeksempler |
| Arkitekturmønstre | Verified | Microsoft Learn (ChatHistoryReducer, WhiteboardProvider, LangChain) |
| Beslutningsveiledning | Baseline | Modellkunnskap + Microsoft patterns |
| Microsoft-integrasjon | Verified | Microsoft Learn API docs |
| GDPR/offentlig sektor | Baseline | GDPR-regler + Azure compliance docs |
| Kostnad | Baseline | Azure pricing calculator (estimater) |
Forfatter: Cosmo Skyberg (AI Architect) For: KTG Microsoft AI Architect Plugin MCP Research: microsoft-learn (4 searches, 2 fetches), microsoft-code-samples (1 search)
.NET AI IChatClient-interface (oppdatert 2026-04)
IChatClient er .NET-standarden for interaksjon med AI chat services (Microsoft.Extensions.AI). Støtter stateless og stateful samtaler, tool calling, streaming, caching, og OpenTelemetry.
// Stateful iterativ RAG med IChatClient
List<ChatMessage> history = [];
while (true) {
history.Add(new(ChatRole.User, userInput));
ChatResponse response = await client.GetResponseAsync(history);
history.AddMessages(response); // akkumulerer kontekst
}
Viktige egenskaper:
ConversationIdstøtter stateful tjenester (slipper å sende full historikk)FunctionInvokingChatClientgir automatisk tool invocation for agentic loopsDistributedCachingChatClientwrapper cacher identiske historikkerChatHistoryTruncationReducer/ChatHistorySummarizationReducerhåndterer context window limits- Pipeline-komposisjon:
ChatClientBuilderstacker cache, tool invocation, og telemetri