ms-ai-architect/skills/ms-ai-advisor/references/prompt-engineering/multi-turn-conversation-management.md

Multi-Turn Conversation and Context Management

Last updated: 2026-02 Status: GA Category: Prompt Engineering & LLM Optimization

---

Introduksjon

Multi-turn conversation management er evnen til å vedlikeholde kontekst og samtaleflyt over flere interaksjoner med en LLM. Dette er fundamentalt for å bygge naturlige, kontekstbevisste AI-applikasjoner som chatboter, assistenter og agenter.

Azure OpenAI Chat Completion API er designet spesifikt for samtaleformater hvor modellen mottar en komplett samtalehistorikk og genererer neste respons. Modellen har ingen intern hukommelse – all kontekst må eksplisitt sendes med hver request.

Kritiske konsepter:

• Modellen er stateless – ingen persistent hukommelse mellom requests
• Samtalehistorikk må inkluderes eksplisitt i hver API-call
• Token limits setter grenser for hvor lang samtalehistorikk kan være
• Context window management er essensielt for langvarige samtaler

Arkitektmessig betydning: Multi-turn management påvirker både brukeropplevelse, kostnad, latency og modellkvalitet. Feil strategi kan føre til konteksttap, høye kostnader eller dårlige responser.

---

Kjernekomponenter

1. Message Roles

Chat Completion API bruker tre primære roller:

Rolle	Formål	Plassering
system	Instruksjoner, kontekst, persona-definisjon	Første melding (anbefalt)
user	Brukerinput, spørsmål, kommandoer	Brukerens meldinger
assistant	Modellens svar, tidligere AI-responser	AI-genererte meldinger

System message: Definerer modellens oppførsel og rammeverk. Bevares typisk gjennom hele samtalen.

Eksempel:

[
  {"role": "system", "content": "Du er en hjelpsom assistent for teknisk support."},
  {"role": "user", "content": "Hvordan resetter jeg passordet mitt?"},
  {"role": "assistant", "content": "For å resette passordet ditt..."},
  {"role": "user", "content": "Hva hvis jeg ikke får e-posten?"}
]

2. Conversation History Management

Client-side storage: For Chat Completion services (GPT-4, GPT-4o, etc.) lagres samtalehistorikk på klientsiden og sendes med hver request.

Server-side storage: For Azure AI Agent service lagres historikk serversiden – kun en referanse sendes.

Viktige metrikker:

• Token count per message = prompt tokens + completion tokens
• Total token count = sum av alle meldinger + estimert respons
• Context window = maksimal token limit per modell (8K-128K avhengig av modell)

3. Token Counting

Token-telling er kritisk for å unngå context window overflow. Microsoft anbefaler tiktoken-biblioteket:

import tiktoken

def num_tokens_from_messages(messages, model="gpt-4o"):
    encoding = tiktoken.encoding_for_model(model)
    tokens_per_message = 3  # For GPT-4o, GPT-4.1, o-series
    tokens_per_name = 1

    num_tokens = 0
    for message in messages:
        num_tokens += tokens_per_message
        for key, value in message.items():
            num_tokens += len(encoding.encode(value))
            if key == "name":
                num_tokens += tokens_per_name
    num_tokens += 3  # Overhead for completion priming
    return num_tokens

Viktig: Token count for rate limiting (TPM) er et estimat basert på max_tokens-parameteren, ikke eksakt billing token count.

4. Session Management

Microsoft Agent Framework tilbyr strukturert session management:

C# (.NET):

AgentSession session = await agent.CreateSessionAsync();
await agent.RunAsync("First question", session);
await agent.RunAsync("Follow-up question", session);

Python:

thread = agent.get_new_thread()
result1 = await agent.run("First question", thread=thread)
result2 = await agent.run("Follow-up question", thread=thread)

Multiple conversations: Én agent kan håndtere flere uavhengige samtaler via separate session/thread-objekter.

---

Arkitekturmønstre

Mønster 1: Sliding Window (Anbefalt for lange samtaler)

Prinsipp: Behold system message + siste N meldinger. Fjern eldste meldinger når token limit nærmes.

Fordeler:

• Forhindrer context overflow
• Lavere kostnader ved lange samtaler
• Konsistent latency

Ulemper:

• Tap av tidlig kontekst
• Modellen "glemmer" tidligere i samtalen

Implementering:

max_response_tokens = 250
token_limit = 4096
conversation = [{"role": "system", "content": "..."}]

while True:
    user_input = input("Q: ")
    conversation.append({"role": "user", "content": user_input})

    conv_tokens = num_tokens_from_messages(conversation)
    while conv_tokens + max_response_tokens >= token_limit:
        del conversation[1]  # Bevarer system message (index 0)
        conv_tokens = num_tokens_from_messages(conversation)

    response = client.chat.completions.create(
        model="gpt-4o",
        messages=conversation,
        max_tokens=max_response_tokens
    )
    conversation.append({"role": "assistant", "content": response.choices[0].message.content})

Når bruke: Customer support chatbots, assistenter med uendelige samtaler.

Mønster 2: Summarization-Based Context

Prinsipp: Oppsummer eldre deler av samtalen, behold kun sammendrag + siste N meldinger.

Fordeler:

• Bevarer viktig kontekst fra hele samtalen
• Reduserer token count betydelig
• Bedre kontekstforståelse enn sliding window

Ulemper:

• Ekstra LLM-call for oppsummering (kostnad + latency)
• Potensielt informasjonstap i oppsummeringen

Implementering (konseptuell):

def summarize_conversation(messages):
    summary_prompt = {
        "role": "system",
        "content": "Oppsummer følgende samtale kort og presist."
    }
    summary_response = client.chat.completions.create(
        model="gpt-4o-mini",  # Billigere modell for oppsummering
        messages=[summary_prompt] + messages
    )
    return summary_response.choices[0].message.content

# Når token limit nærmes:
if token_count > threshold:
    old_messages = conversation[1:10]  # Skip system message
    summary = summarize_conversation(old_messages)
    conversation = [
        conversation[0],  # System message
        {"role": "assistant", "content": f"[Sammendrag av tidligere samtale: {summary}]"},
        *conversation[10:]  # Siste N meldinger
    ]

Når bruke: Komplekse problemløsningssesjoner, teknisk support med flere trinn.

Mønster 3: Responses API (Managed History)

Prinsipp: Bruk Azure OpenAI Responses API som automatisk håndterer kontekst-truncation.

Fordeler:

• Ingen manuell token management
• Microsoft håndterer best practices
• Enklere implementering

Ulemper:

• Mindre kontroll over hva som fjernes
• Kun tilgjengelig i nyere API-versjoner

Implementering:

# Responses API håndterer automatisk truncation
response = client.responses.create(
    model="gpt-4o",
    messages=conversation
)

Når bruke: Prototyper, enkle chatbots, applikasjoner uten spesialkrav til kontekstbevaring.

Mønster 4: Stored Completions (Audit & Fine-tuning)

Prinsipp: Lagre samtalehistorikk for senere evaluering eller fine-tuning.

Fordeler:

• Full audit trail
• Data for modell-forbedring
• Compliance-vennlig

Ulemper:

• Ekstra storage-kostnad
• Privacy-implikasjoner

Implementering:

response = client.chat.completions.create(
    model="gpt-4o",
    messages=conversation,
    store=True,  # Aktiver stored completions
    metadata={"user_id": "123", "session_id": "abc"}
)

Når bruke: Enterprise-applikasjoner med compliance-krav, continuous learning-scenarier.

Mønster 5: Vector Store Chat History

Prinsipp: Lagre samtalehistorikk i vector store (Azure AI Search, Cosmos DB) for persistent sessions.

Fordeler:

• Persistent på tvers av sesjoner
• Skalerbart for mange brukere
• Semantic search i historikk mulig

Ulemper:

• Ekstra infrastruktur
• Mer kompleks implementering

Implementering (Agent Framework):

VectorStore vectorStore = new InMemoryVectorStore();

AIAgent agent = new AzureOpenAIClient(new Uri("..."), new AzureCliCredential())
    .GetChatClient("gpt-4o-mini")
    .AsAIAgent(new ChatClientAgentOptions
    {
        ChatHistoryProviderFactory = (ctx, ct) => new ValueTask<ChatHistoryProvider>(
            new VectorChatHistoryProvider(
                vectorStore,
                ctx.SerializedState,
                ctx.JsonSerializerOptions))
    });

AgentSession session = await agent.CreateSessionAsync();
JsonElement serializedSession = session.Serialize();  // Lagres i database
AgentSession resumedSession = await agent.DeserializeSessionAsync(serializedSession);

Når bruke: Multi-device applikasjoner, enterprise chatbots med persistent history.

---

Beslutningsveiledning

Velg strategi basert på scenario

Scenario	Anbefalt mønster	Begrunnelse
Customer support chatbot (kort varighet)	Sliding Window	Enkel, kostnadseffektiv
Teknisk problemløsning (kompleks)	Summarization-Based	Bevarer viktig kontekst
Enkel FAQ-bot	Responses API	Minimal kompleksitet
Enterprise compliance	Stored Completions	Audit trail nødvendig
Multi-device applikasjon	Vector Store	Persistent på tvers av devices
Prototype/MVP	Responses API eller Sliding Window	Rask implementering

Token limit per modell (Azure OpenAI)

Modell	Context Window	Anbefalt max conversation tokens
gpt-4o	128K tokens	120K (buffer for respons)
gpt-4o-mini	128K tokens	120K
gpt-4.1	128K tokens	120K
gpt-4.1-mini	128K tokens	120K
gpt-4 Turbo	128K tokens	120K
gpt-35-turbo	16K tokens	14K
o1, o3-mini, o4-mini	128K-200K	Varierer per modell

Viktig: Sjekk alltid models page for oppdaterte limits.

Truncation-strategi

Strategi	Kompleksitet	Kontekstbevaring	Kostnad	Brukscase
FIFO (First In, First Out)	Lav	Lav	Lav	Enkle chatbots
Sliding Window	Lav	Medium	Lav	Generell bruk
Summarization	Medium	Høy	Medium	Komplekse samtaler
Semantic Pruning	Høy	Høy	Medium	Spesialiserte use cases
Responses API	Minimal	Medium	Lav	Prototyper

Rate Limiting og TPM

TPM (Tokens-Per-Minute) er basert på estimert token count:

• Prompt tokens + max_tokens parameter + best_of parameter
• Ikke identisk med billing token count

RPM (Requests-Per-Minute) er koblet til TPM: 6 RPM per 1K TPM.

Best practices:

• Implementer exponential backoff ved 429-errors
• Fordel requests jevnt over tid (unngå bursts)
• Sett max_tokens konservativt for å unngå false rate limits
• Bruk batch-prosessering for store volumes

---

Integrasjon med Microsoft-stakken

Azure OpenAI Chat Completion API

Standard integrasjon:

from openai import OpenAI
from azure.identity import DefaultAzureCredential, get_bearer_token_provider

token_provider = get_bearer_token_provider(
    DefaultAzureCredential(),
    "https://cognitiveservices.azure.com/.default"
)

client = OpenAI(
    base_url="https://<resource>.openai.azure.com/openai/v1/",
    api_key=token_provider
)

conversation = [{"role": "system", "content": "You are a helpful assistant."}]
response = client.chat.completions.create(
    model="gpt-4o",
    messages=conversation
)

Streaming support: Bruk stream=True for real-time responser.

Microsoft Agent Framework

Fordeler:

• Abstraherer conversation management
• Støtter både client-side og server-side history
• Innebygd session serialization
• Multi-conversation support out-of-the-box

Når bruke: Enterprise-applikasjoner med kompleks agent-logikk.

Copilot Studio

Innebygd conversation management:

• Automatisk context tracking
• Slot filling for multi-turn information gathering
• State management via Topics

Relevant for: Low-code/no-code scenarios, Power Platform-integrasjoner.

Semantic Kernel

Chat History i SK:

using Microsoft.SemanticKernel;
using Microsoft.SemanticKernel.ChatCompletion;

var chatHistory = new ChatHistory();
chatHistory.AddSystemMessage("You are a helpful assistant.");
chatHistory.AddUserMessage("What is Azure AI?");

var response = await chatCompletionService.GetChatMessageContentAsync(
    chatHistory,
    executionSettings,
    kernel
);

chatHistory.AddAssistantMessage(response.Content);

Fordeler: Plugin-integrasjon, function calling, planlegging.

Microsoft Foundry (tidligere Azure AI Studio)

Stored Completions: Synliggjøres automatisk i AI Foundry portal under "Stored Completions" pane.

Playground: Interaktiv testing av multi-turn samtaler med visuell chat interface.

Power Automate + Azure OpenAI

Pattern: Lagre conversation state i Dataverse eller SharePoint:

1. Hent tidligere meldinger fra storage
2. Legg til ny brukermelding
3. Call Azure OpenAI
4. Lagre assistant-respons tilbake til storage
5. Truncate hvis token limit nærmes

Utfordring: Ingen innebygd token counting – bruk custom connector med Azure Function.

---

Offentlig sektor (Norge)

Personvern og GDPR

Samtalehistorikk inneholder potensielt persondata:

• Navn, personnummer, adresser i brukerinput
• Sensitive samtaler (helse, økonomi, juridiske spørsmål)

Krav:

• Sletting: Implementer mekanisme for å slette samtalehistorikk på forespørsel
• Lagringstid: Definer og håndhev maksimal lagringstid
• Anonymisering: Vurder å anonymisere historikk før langtidslagring
• Stored Completions: Vær obs på at store=True lagrer data i Microsoft-infrastruktur

Anbefaling:

• Unngå store=True for sensitive use cases
• Implementer client-side history med egen storage-løsning
• Bruk Azure Private Link for data i transit

Schrems II og dataoverføring

Azure OpenAI data residency:

• Regional deployment mulig (Norway East, West Europe)
• Datazone Standard: Garanterer data forblir i EU/EØS
• Global Standard: Data kan traversere regioner (unngå for sensitive data)

Multi-turn impact: Samtalehistorikk sendes ved hver request – velg regional deployment for compliance.

Tilgjengelighetskrav (WCAG)

Multi-turn conversation påvirker UU:

• Context awareness: Brukere med kognitive utfordringer trenger klar referanse til tidligere i samtalen
• Timeout: Lange pauser i samtale skal ikke føre til konteksttap
• Recap-funksjon: Tilby oppsummering av samtale så langt

Anbefaling: Implementer visuell samtalehistorikk i UI + "Hva har vi snakket om?"-funksjon.

Sikkerhet og autorisasjon

Per-bruker conversation isolation:

• Implementer streng autorisasjon på session/thread-objekter
• Aldri la én bruker få tilgang til en annens samtalehistorikk
• Vurder Entra ID-integrasjon for autentisering

Agent Framework pattern:

// Lagre session med user-knytning
var userId = httpContext.User.FindFirst(ClaimTypes.NameIdentifier).Value;
var sessionId = $"{userId}_{Guid.NewGuid()}";
// Valider at bruker har tilgang ved gjenopptak

---

Kostnad og lisensiering

Kostnadsmodell for multi-turn

Token-basert prising: Du betaler for alle tokens sendt i hver request, inkludert full samtalehistorikk.

Eksempel (gpt-4o i Norway East):

• Input: $0.005 per 1K tokens
• Output: $0.015 per 1K tokens

Scenario: 10-turn samtale hvor hver turn inkluderer hele historikken:

• Turn 1: 100 tokens (system) + 50 (user) + 100 (response) = 250 tokens
• Turn 2: 100 + 50 + 100 + 50 + 100 = 400 tokens
• Turn 3: 100 + 50 + 100 + 50 + 100 + 50 + 100 = 550 tokens
• ...
• Total over 10 turns: ~15 000 tokens (voksende lineært)

Kostnad: ~$0.10-0.15 per 10-turn samtale (avhengig av input/output ratio)

Optimeringsstrategier

Teknikk	Kostnadsbesparing	Trade-off
Sliding Window (behold 5 siste meldinger)	40-60%	Konteksttap
Summarization	30-50%	Ekstra LLM-call
Bruk gpt-4o-mini for oppsummering	80% på summary-calls	Marginalt kvalitetstap
Aggressive truncation (3 siste meldinger)	60-70%	Betydelig konteksttap
Responses API	20-40% (Microsoft-managed)	Mindre kontroll

Anbefalt strategi for offentlig sektor:

1. Start med Sliding Window (5-7 siste meldinger)
2. Implementer summarization for samtaler >10 turns
3. Bruk gpt-4o-mini for summarization og enkle spørsmål
4. Monitor token usage via Azure Monitor + custom metrics

Lisensiering

Azure OpenAI: Ingen spesifikk lisens for multi-turn – samme TPM quota gjelder.

Quota management:

• Default tier: 450K TPM (gpt-4o Global Standard)
• Enterprise tier: 30M TPM (gpt-4o Global Standard)

Multi-turn påvirkning på quota:

• Lange samtaler kan raskt fylle TPM-quota hvis mange brukere samtaler samtidig
• Vurder Provisioned Throughput for høy concurrency

Copilot Studio:

• Multi-turn inkludert i standard message quota (ikke ekstra kostnad per turn)
• Relevant for offentlig sektor: Copilot for M365 krever E3/E5-lisens

---

For arkitekten (Cosmo)

Confidence markers

Aspekt	Confidence	Kommentar
Token counting metoder	Høy	Verifisert mot offisiell Microsoft docs
Sliding Window pattern	Høy	Standard best practice
Responses API	Medium	Nyere feature, mindre dokumentert
Stored Completions privacy	Medium	Begrenset docs på data residency
TPM/RPM relationship	Høy	Offisiell Microsoft spec
Cost estimates	Medium	Basert på jan 2026 priser (kan endre)

Når anbefale hva

Enkel chatbot (FAQ, customer support): → Sliding Window + gpt-4o-mini → NOK 500-2000/mnd for 1000 samtaler

Kompleks assistent (teknisk support, legal advice): → Summarization + gpt-4o + Vector Store → NOK 5000-15000/mnd for 1000 samtaler

Enterprise multi-device app: → Agent Framework + Azure AI Search (vector store) + Datazone Standard → NOK 20000-50000/mnd

Prototype/POC: → Responses API + minimal logging → NOK 200-1000/mnd for testing

Arkitektur decision points

Spørsmål å stille kunde:

1. Hvor lange er typiske samtaler? (5 turns vs 50 turns)

   • <10 turns → Sliding Window
   • 10-30 turns → Sliding Window med summarization fallback

   • 30 turns → Summarization eller managed history

2. Hvor viktig er tidlig kontekst? (kan modellen "glemme"?)

   • Ikke kritisk → FIFO truncation
   • Moderat viktig → Sliding Window
   • Svært viktig → Summarization eller semantic pruning

3. Trenger dere audit trail? (compliance, training data)

   • Ja → Stored Completions eller egen logging
   • Nei → In-memory history

4. Multi-device support? (fortsett samtale på annen enhet)

   • Ja → Vector Store eller Dataverse storage
   • Nei → In-memory med session serialization

5. Volum og concurrency? (hvor mange samtidige brukere?)

   • <100 concurrent → Standard TPM quota
   • 100-1000 concurrent → Provisioned Throughput

   • 1000 concurrent → Multi-region deployment

Integration patterns

Pattern A: Serverless (Azure Functions + Cosmos DB)

User → API Management → Function App → Azure OpenAI
                            ↓
                        Cosmos DB (conversation history)

• Fordel: Auto-scaling, lav vedlikeholdskostnad
• Ulempe: Cold start latency

Pattern B: Container-based (AKS + Redis)

User → Application Gateway → AKS Pods → Azure OpenAI
                                ↓
                            Redis Cache (history)

• Fordel: Lav latency, høy throughput
• Ulempe: Høyere vedlikeholdskostnad

Pattern C: Power Platform (Copilot Studio + Dataverse)

User → Copilot Studio → Azure OpenAI
            ↓
        Dataverse (managed history)

• Fordel: No-code/low-code, innebygd compliance
• Ulempe: Mindre fleksibilitet

Red flags å se etter

❌ Ingen token management → System vil feile ved lange samtaler ❌ Hardkodet max_tokens=4096 → Kan spise opp context window ❌ Ingen retry logic → 429-errors vil ødelegge brukeropplevelse ❌ Samtalehistorikk i local storage → Privacy-risiko, ingen server-side validering ❌ Manglende session isolation → Sikkerhetsrisiko (bruker A ser bruker B's samtale) ❌ Global Standard for sensitive data → Schrems II-problemstikk

Anbefalte metrics å tracke

- Gjennomsnittlig tokens per request (input + output)
- Gjennomsnittlig samtale-lengde (antall turns)
- 95th percentile conversation token count
- Andel samtaler som treffer token limit
- Token count distribution (histogram)
- Cost per conversation
- Rate limit errors (429) per time window
- Latency per turn (påvirkes av conversation length)

Implementering: Bruk Azure Monitor + Application Insights custom metrics.

Teknisk gjeld å unngå

1. Hardkoding av modellnavn i token counting → Bruk dynamic model detection
2. Ingen versjonering av samtaleformat → Umulig å migrere senere
3. Manglende conversation timeout → Infinite growth av history
4. Ingen graceful degradation → System crasher ved token limit

---

Kilder og verifisering

Microsoft Learn (offisiell dokumentasjon)

1. Work with chat completions models https://learn.microsoft.com/en-us/azure/foundry/openai/how-to/chatgpt Kjernereferanse for Chat Completion API, conversation loop patterns, token management

2. Multi-turn conversations with an agent https://learn.microsoft.com/en-us/agent-framework/tutorials/agents/multi-turn-conversation Agent Framework session management, stateless architecture

3. Azure OpenAI stored completions & distillation https://learn.microsoft.com/en-us/azure/foundry-classic/openai/how-to/stored-completions Stored completions feature, metadata enrichment

4. Azure OpenAI quotas and limits https://learn.microsoft.com/en-us/azure/foundry/openai/quotas-limits Token limits per modell, TPM/RPM relationship, rate limiting

5. Manage Azure OpenAI quota https://learn.microsoft.com/en-us/azure/foundry-classic/openai/how-to/quota Rate limit mechanics, best practices, token counting for rate limits

6. Azure OpenAI Assistants API context window management https://learn.microsoft.com/en-us/azure/foundry-classic/openai/concepts/assistants Truncation strategies, max_prompt_tokens, max_completion_tokens

7. CLU multi-turn conversations https://learn.microsoft.com/en-us/azure/ai-services/language-service/conversational-language-understanding/concepts/multi-turn-conversations Entity slot filling, conversational continuity patterns

8. Semantic Kernel chat completion https://learn.microsoft.com/en-us/semantic-kernel/concepts/ai-services/chat-completion ChatHistory API, connector-specific patterns

Code samples

• OpenAI Cookbook: Token counting reference implementation https://github.com/openai/openai-cookbook/blob/main/examples/How_to_format_inputs_to_ChatGPT_models.ipynb

• Azure AI samples: Multi-turn conversation patterns Microsoft Learn code snippets (embedded i dokumentasjon)

Confidence assessment

Kilder brukt: 8 offisielle Microsoft Learn-artikler + 17 code samples MCP calls: 5 (search + fetch) Siste oppdatert: Dokumentasjon datert 2025-2026 Confidence på innhold: 90% (høy – basert på førstepartskilde)

Gaps identifisert:

• Begrenset dokumentasjon på Responses API-internals (nyere feature)
• Sparse info på Stored Completions data residency ved multi-region
• Mangler offisiell cost calculator for multi-turn scenarios

Anbefaling: Verifiser Responses API-oppførsel i pilot før produksjon. Kontakt Microsoft for detaljert Stored Completions compliance-dokumentasjon.