Kjell Tore Guttormsen 8d080b8527 docs(ms-ai-architect): KB-refresh MEDIUM 9/33 — role-playing: header-bump (TRYGT: system message-teknikker + strictness uendret)

2026-06-24 11:38:23 +02:00

23 KiB

Raw Blame History

Role-Playing and Persona-Based Prompting

Last updated: 2026-06-24 | Verified: MCP 2026-06 Status: GA Category: Prompt Engineering & LLM Optimization

Introduksjon

Role-playing og persona-basert prompting er en av de mest effektive teknikkene for å styre oppførselen til store språkmodeller (LLMs) i Microsoft AI-stakken. Ved å definere en eksplisitt rolle, personlighet og kontekst i system messages, kan du forme hvordan modellen kommuniserer, hvilken kunnskap den vektlegger, og hvordan den håndterer edge cases og sikkerhetsbegrensninger.

I Azure OpenAI Service, Copilot Studio og Microsoft 365 Copilot brukes system messages (også kalt metaprompts eller system prompts) som det primære verktøyet for å etablere en persona. Denne teknikken går utover enkel instruksjon – den skaper en konsistent "karakter" som modellen inntar gjennom hele samtalen.

Hvorfor dette er viktig:

Konsistens: En veldefinert persona gir mer forutsigbare og konsistente responser
Domenespesialisering: Modellen kan "spille" rollen som ekspert innen spesifikke fagområder
Sikkerhet: Persona-grenser definerer hva modellen skal og ikke skal gjøre
Brukeropplevelse: Riktig tone og stil øker tillit og effektivitet

Confidence: HIGH – Dokumentasjonen er omfattende og godt validert i Microsoft Learn.

Kjernekomponenter

1. System Message Struktur

En system message for persona-design består av flere lag:

Komponent	Formål	Eksempel
Role definition	Hvem/hva assistenten er	"You are a technical support specialist for Azure AI services"
Scope & boundaries	Hva assistenten kan og ikke kan gjøre	"You answer questions about Azure OpenAI. You do not provide medical advice."
Tone & style	Kommunikasjonsstil	"Respond professionally and concisely"
Output format	Strukturering av svar	"Always return JSON with keys: analysis, recommendation, confidence"
Safety constraints	Responsible AI-grenser	"If asked about protected characteristics, decline politely"
Fallback behavior	Hva gjør modellen når usikker	"If you don't know, say 'I don't know' and suggest alternatives"

2. Persona-Teknikker i Praksis

a) Eksplisitt rolletildeling

Bruk andre person ("you") når du definerer personas:

You are an AI assistant that helps people find information and responds in rhyme.
If the user asks you a question you don't know the answer to, say so.

Dette er mer effektivt enn:

The assistant is a helpful AI... (tredje person)

b) Domenekontekst

Gi modellen forståelse av sitt ekspertiseområde:

You are a technical support assistant for an internal product.
You have access to:
- Product documentation from 2024-2026
- Known issues database
- Configuration best practices

If you don't have enough information to answer, ask a clarifying question.
If you still can't answer, say you don't know.

c) Strukturert entitetsekstraksjon

For strukturert output, definer persona + output contract:

You extract entities from user text.
Return only JSON, using this schema:
{
   "name": "",
   "company": "",
   "phone_number": ""
}

3. Authoring Techniques for Personas

Microsoft dokumenterer flere høyt-presterende teknikker:

Teknikk	Definisjon	Bruksområde	Eksempel
Always / Should	Direktiver som alltid følges	Beste praksis, etiske retningslinjer	`Always respect authentication protocols when providing information`
Never / Don't	Eksplisitte forbudd	Sikkerhet, scope-begrensninger	`Never make assumptions about a person's identity`
Conditional (If-Then)	Betinget logikk	Håndtering av edge cases	`If user asks about emotions, respond: "I can't help with that"`
Emphasis on harm	Definere hovedrisiko	Prioritere sikkerhet	`You are allowed to answer when there is no direct harm`
Example-based	Vise gode/dårlige eksempler	Lære modellen kontekst	`Example (harmful): "..." Example (benign): "..."`

4. Best Practices for Persona Design

Design Checklist:

✅ Start med assistentens jobb – State rolle og forventet resultat
✅ Definer grenser – List topics/actions å unngå
✅ Spesifiser output-format – Vær eksplisitt om struktur
✅ Legg til "when unsure" policy – Hva gjør modellen når den ikke vet?
✅ Test, mål, iterer – Bruk både normale og adversarial prompts

Språk og Stil:

Bruk klart språk – Unngå kompleksitet og misforståelser
Vær konsis – Kortere system messages = bedre ytelse, lavere latency
Uthev nøkkelord med **word** – Spesielt for skal/skal ikke
Bruk andre person – "You are..." vs "Assistant is..."
Implementer robusthet – Performer konsistent på tvers av datasets

Common Pitfalls:

❌ Motstridende instruksjoner – eks. "be brief" og "be comprehensive" samtidig ❌ For lange system messages – Tar opp context window ❌ Skjulte krav – Hvis output-format er viktig, si det eksplisitt

Arkitekturmønstre

Mønster 1: Teknisk Support Persona

Scenario: Intern support-chatbot for et produkt

System Message:

You are a technical support assistant for [Product Name].

## Your role:
- Answer technical questions about [Product Name]
- Help troubleshoot common issues
- Guide users to documentation when appropriate

## Your boundaries:
- Do not provide advice on competing products
- Do not share internal roadmap information
- Do not guess about undocumented features

## When unsure:
1. Ask clarifying questions to narrow the issue
2. If still unable to help, say: "I don't have information on this. Please contact support@company.com"

## Tone:
Professional, patient, and solution-oriented.

Mønster 2: Data Extraction Persona

Scenario: Strukturert parsing av kundehenvendelser

System Message:

You extract customer information from support emails.

Return ONLY valid JSON using this schema:
{
   "customer_name": "",
   "company": "",
   "email": "",
   "issue_category": "",  // One of: technical, billing, feature_request
   "urgency": ""  // One of: low, medium, high
}

If a field cannot be determined, use null.
Do not add explanatory text outside the JSON structure.

Mønster 3: Multi-Persona Agent (Copilot Studio)

Scenario: Agent som bytter persona basert på intent

I Copilot Studio kan du bruke prompt nodes med ulike personas:

# Topic: Technical Support
Persona:
  You are a technical expert. Provide detailed, accurate solutions.
  Use technical terminology. Be precise.

# Topic: General Inquiry
Persona:
  You are a friendly customer service representative.
  Use simple language. Be warm and welcoming.

Mønster 4: Safety-First Persona

Scenario: Offentlig-tilgjengelig chatbot med strenge sikkerhetskrav

System Message:

You are a helpful assistant for [Organization Name].

## Core behavior:
- Provide information about [approved topics]
- Be respectful and inclusive
- Maintain user privacy

## Safety guidelines:
**Never** make assumptions about:
- A person's identity, background, or protected characteristics
- Sensitive topics outside your scope

If a user asks about emotions, mental health, or personal identity:
Respond: "I can't help with that. Try asking about [approved topics] instead."

**Always** decline requests that:
- Promote harm or harassment
- Violate privacy or security
- Are outside your defined scope

Beslutningsveiledning

Når bruke Role-Playing Personas?

Scenario	Anbefalt?	Hvorfor
Domenespesifikk chatbot	✅ Ja	Gir konsistens og ekspertise-preg
Multi-turn samtaler	✅ Ja	Holder tone og kontekst over tid
Strukturert data-ekstraksjon	✅ Ja	Output contract + persona = pålitelig format
Generell Q&A uten kontekst	⚠️ Kanskje	Kan være overkill hvis ingen spesialisering trengs
Enkel completion (ikke chat)	❌ Nei	System messages er chat-spesifikke

Valg av Persona-Kompleksitet

graph TD
    A[Trenger du persona?] --> B{Hvor spesialisert?}
    B -->|Enkel assistent| C[Basic role + tone]
    B -->|Domenekspert| D[Role + scope + fallback]
    B -->|Høy-risiko/offentlig| E[Role + scope + safety + examples]
    C --> F[1-3 linjer system message]
    D --> G[5-15 linjer system message]
    E --> H[15-50 linjer system message + testing]

Tommelfingerregel:

1-3 linjer: Generell assistent, lav risiko
5-15 linjer: Domenespesifikk, medium risiko
15-50 linjer: Høy-risiko, offentlig-tilgjengelig, regulert

Testing og Iterasjon

Evalueringsstrategi:

Benign test cases – Normale bruksscenarier
Adversarial test cases – Forsøk å "hacke" personaen
Edge cases – Uklare/tvetydige forespørsler
Out-of-scope requests – Ting modellen skal nekte

Metrics:

Consistency score – Hvor ofte holder modellen rollen?
Boundary adherence – Respekterer den scope-begrensninger?
Safety leakage – Hvor ofte feiler sikkerhetskontroller?
User satisfaction – Føles personaen naturlig og nyttig?

Integrasjon med Microsoft-stakken

Azure OpenAI Service

Chat Completions API:

from openai import OpenAI
import os

client = OpenAI(
    api_key=os.getenv("AZURE_OPENAI_API_KEY"),
    base_url="https://YOUR-RESOURCE.openai.azure.com/openai/v1/"
)

response = client.chat.completions.create(
    model="gpt-4o",
    messages=[
        {
            "role": "system",
            "content": """You are an Azure AI architect assistant.

Your role:
- Provide guidance on Azure AI services
- Recommend architectures based on requirements
- Explain trade-offs between services

Your boundaries:
- Do not provide pricing estimates without disclaimers
- Do not recommend services outside Azure ecosystem
- Do not share confidential roadmap information

When unsure:
Say "I need more context" and ask clarifying questions."""
        },
        {
            "role": "user",
            "content": "Should I use Azure OpenAI or Cognitive Services for sentiment analysis?"
        }
    ]
)

print(response.choices[0].message.content)

Azure OpenAI On Your Data:

Når du bruker RAG (Retrieval-Augmented Generation), kombineres system message med retrieved documents:

System message: You are an AI assistant for [Company].
Answer questions using ONLY the retrieved documents.

Strictness: 3 (default) - Balanse mellom relevans og fullstendighet

Tip: Bruk strictness-parameter (1-5) for å kontrollere hvor aggressivt systemet filtrerer dokumenter.

Copilot Studio

Instructions Field:

I Copilot Studio konfigurerer du persona i Settings > AI capabilities > Instructions:

Name: Technical Support Bot
Description: Helps users with product issues

Instructions:
You are a friendly technical support specialist for [Product].

# Your personality:
- Patient and understanding
- Solution-focused
- Never dismissive of user concerns

# How to respond:
1. Acknowledge the user's issue
2. Ask clarifying questions if needed
3. Provide step-by-step solutions
4. Offer to escalate if unable to resolve

# What NOT to do:
- Don't blame the user
- Don't provide workarounds that violate security
- Don't promise features that don't exist

Best Practices for Copilot Studio:

✅ Be specific and clear – Unngå vage instruksjoner
✅ Use examples – Illustrer forventet oppførsel
✅ Keep it simple – Ikke overlast med detaljer
✅ Keep it brief – Lange instruksjoner → latency
✅ Give a way out – "If unable, respond with 'not found'"
✅ Test and refine – Iterer basert på faktisk bruk

Prompt Node for Dynamic Personas (nlu-prompt-node, Verified 2026-04):

Bruk prompt nodes i topics for å endre persona mid-flow. Legges til via "Add a tool" → "New prompt" i topic:

Node Type: Prompt (Add a tool > New prompt)
Best practices:
  - Be specific: Klare instruksjoner gir forutsigbare svar
  - Use examples: Illustrer forventet oppførsel
  - Keep it brief: Lange instruksjoner → latency og timeouts
  - Give a way out: "respond with not found if answer isn't present"
  - Temperature: Kontroller kreativitet/determinisme per prompt

Prompts kan også legges til på agent-nivå (Tools tab) eller som node i agent flows (AI capabilities → Run a prompt).

Microsoft 365 Copilot (Enterprise)

Grounding prompts:

M365 Copilot har innebygde personas, men kan tilpasses med grounding prompts i Copilot Studio når du utvider funksjonalitet:

You are an extension to Microsoft 365 Copilot specializing in [domain].

# Your role:
- Supplement Copilot's general knowledge with [domain-specific] expertise
- Provide insights based on [specific data sources]

# Integration guidelines:
- Maintain Copilot's professional tone
- Cite sources when providing information
- Defer to Copilot for general M365 tasks

Semantic Kernel

Prompts as Code:

I Semantic Kernel defineres personas i prompt templates:

var prompt = @"
<message role=""system"">
You are a {{$persona}} assistant.
Your expertise: {{$domain}}
Your communication style: {{$style}}
</message>

<message role=""user"">
{{$input}}
</message>
";

var config = new PromptTemplateConfig();
var template = new PromptTemplate(prompt, config, kernel);

var function = kernel.CreateFunctionFromPrompt(template);

var result = await kernel.InvokeAsync(function, new() {
    ["persona"] = "senior architect",
    ["domain"] = "Azure AI services",
    ["style"] = "concise and technical",
    ["input"] = "What's the best way to implement RAG?"
});

Offentlig sektor (Norge)

Krav og Hensyn

Krav	Hvorfor viktig	Persona-implikasjon
GDPR/Personvern	Offentlige tjenester håndterer sensitiv data	Persona må eksplisitt nekte forespørsler om persondata
Språkkrav	Mange offentlige tjenester må støtte både bokmål/nynorsk	Persona skal kunne bytte språk, eller ha separate instanser
Universell utforming	Tilgjengelighet for alle	Persona skal bruke klart språk, unngå jargong
Transparens	Brukere må vite når de snakker med AI	Persona må identifisere seg som AI
Nøytralitet	Offentlig sektor må være partipolitisk nøytral	Persona må unngå politiske uttalelser

Eksempel: Offentlig Servicechatbot

Du er en digital assistent for [Etatsnavnet].

## Din rolle:
- Hjelpe innbyggere med spørsmål om [tjenester]
- Veilede til riktig informasjon og skjemaer
- Forklare prosedyrer på et klart og enkelt språk

## Dine grenser:
- Du gir IKKE juridisk rådgivning
- Du gir IKKE personlige råd om enkeltvedtak
- Du håndterer IKKE persondata i samtalen
- Du uttrykker IKKE politiske meninger

## Når du er usikker:
Si: "For å svare på dette trenger jeg mer kontekst" og still oppklarende spørsmål.
Hvis du fortsatt ikke kan svare: "Jeg kan ikke hjelpe med dette. Kontakt oss på [kontaktinfo]."

## Språk og tone:
- Bruk bokmål som standard (eller nynorsk hvis bruker ber om det)
- Vær høflig, tålmodig og inkluderende
- Unngå faguttrykk – forklar heller på enkelt norsk

## Personvern:
**Aldri** be om eller lagre:
- Fødselsnummer
- Personnavn
- Adresse eller kontaktinformasjon

Compliance Checklist

Persona identifiserer seg som AI – Ingen "pretending to be human"
Eksplisitt nekte persondata-forespørsler
Språkstøtte (bokmål/nynorsk/samisk der relevant)
Referere til menneske når nødvendig – Escalation path
Ingen politiske/kontroversielle uttalelser
WCAG 2.1 AA-kompatibel output (klart språk, strukturert format)

Kostnad og lisensiering

Token-forbruk

System messages teller som input tokens i hver API-call. Lengre personas = høyere kostnad.

Eksempel (GPT-4o):

Persona lengde	Tokens	Kostnad per 1000 calls (ca.)
Minimal (1-2 setninger)	~20 tokens	$0.015 USD
Standard (10-15 linjer)	~100 tokens	$0.075 USD
Omfattende (30-50 linjer)	~300 tokens	$0.225 USD

Optimalisering:

✅ Kort og konsis – Fjern unødvendig tekst
✅ Cached system messages (future) – Når GPT-4 Turbo får caching
✅ Persistent personas – Ikke gjenta i hver turn (håndteres automatisk av API)

Lisensiering

Plattform	Krav	Persona-relevans
Azure OpenAI	Azure-abonnement + godkjent quota	Ingen begrensninger på persona-bruk
Copilot Studio	Copilot Studio-lisens (standalone eller M365 bundle)	Inkludert i quota
M365 Copilot	M365 E3/E5 + Copilot-lisens	Grounding prompts krever Copilot Studio-integrasjon

Kostnad-benefit:

🟢 Lav kostnad, høy verdi når persona reduserer unødvendige follow-up calls
🟡 Moderat kostnad for komplekse safety-first personas
🔴 Høy kostnad hvis system message er unødvendig lang og gjentas i high-volume scenarier

For arkitekten (Cosmo)

Når anbefale Role-Playing Personas

Indikatorer:

✅ JA, anbefal role-playing når:

Kunden trenger konsistent tone/stil på tvers av samtaler
Domene krever spesialisert språk eller ekspertise-preg
Sikkerhet/compliance krever strenge grenser
Multimodal interaksjon (text + function calling) trenger koordinering
Offentlig-tilgjengelig løsning med reputasjonsrisiko

⚠️ VURDER ALTERNATIVER når:

Enkeltstående completion-oppgaver (ikke samtalebasert)
Kunden allerede har modell-finetuning som håndterer stil
Ekstrem latency-sensitivitet (hver token teller)

❌ IKKE anbefal hvis:

Completion API (ikke chat) brukes
Kunden ønsker maksimal "raw" modell-output uten styring

Arkitektur-spørsmål å stille

Hva er assistentens eksakte rolle? (Få kunden til å definere dette presist)
Hva skal den ALDRI gjøre? (Boundaries er kritiske)
Hva skjer når modellen er usikker? (Fallback behavior)
Hva er akseptabel vs uakseptabel output? (Safety testing)
Hvor mange samtaler forventes? (Token cost estimation)
Hvem er sluttbrukerne? (Tone/språk/accessibility)

Decision Tree: Persona Complexity

START: Trenger kunden en persona?
│
├─ JA
│  ├─ Er dette offentlig tilgjengelig?
│  │  ├─ JA → Omfattende persona (15-50 linjer + safety guidelines)
│  │  └─ NEI → Vurder videre
│  │
│  ├─ Er det høy-risiko domene? (helse, finans, jus)
│  │  ├─ JA → Medium-omfattende persona (10-20 linjer + fallback)
│  │  └─ NEI → Basis persona (3-10 linjer)
│  │
│  └─ Er det intern/prototyping?
│     └─ Basis persona (3-5 linjer) → Iterer basert på feedback
│
└─ NEI → Bruk minimal system message eller ingen

Integration Patterns

Pattern 1: Static Persona (enkel)

SYSTEM_PERSONA = "You are a helpful Azure AI assistant."

# Bruk samme persona for alle calls
messages = [
    {"role": "system", "content": SYSTEM_PERSONA},
    {"role": "user", "content": user_input}
]

Pattern 2: Dynamic Persona (kontekst-avhengig)

def get_persona(user_intent):
    personas = {
        "technical": "You are a technical architect...",
        "business": "You are a business consultant...",
        "security": "You are a security specialist..."
    }
    return personas.get(user_intent, "You are a helpful assistant.")

persona = get_persona(detected_intent)
messages = [{"role": "system", "content": persona}, ...]

Pattern 3: Layered Persona (base + extensions)

BASE_PERSONA = "You are an assistant for [Company]."

SAFETY_LAYER = """
**Never** make assumptions about personal characteristics.
If asked about sensitive topics, decline politely.
"""

DOMAIN_LAYER = """
Your expertise: [Domain specifics]
Your tools: [Available functions]
"""

full_persona = f"{BASE_PERSONA}\n\n{SAFETY_LAYER}\n\n{DOMAIN_LAYER}"

Testing Playbook

Phase 1: Baseline testing

10 normale use cases
Verifiser tone, style, accuracy

Phase 2: Boundary testing

10 out-of-scope requests
Verifiser at modellen deklinerer korrekt

Phase 3: Adversarial testing

10 "jailbreak" forsøk
Verifiser at persona holder seg

Phase 4: Edge case testing

10 tvetydige/uklare prompts
Verifiser fallback behavior

Quick Reference: Common Persona Templates

# TEMPLATE 1: TECHNICAL SUPPORT
You are a technical support specialist for [Product].
Answer questions about [Product features].
If you don't know, say so and offer to escalate.
Tone: Professional and patient.

# TEMPLATE 2: DATA EXTRACTOR
You extract [entities] from user input.
Return only JSON: {"field1": "", "field2": ""}.
If a field is unknown, use null.

# TEMPLATE 3: SAFETY-FIRST PUBLIC BOT
You are an assistant for [Organization].
Provide information about [approved topics].
**Never** make assumptions about people or protected characteristics.
If out of scope, respond: "I can't help with that."

# TEMPLATE 4: DOMAIN EXPERT
You are a [Domain] expert with knowledge of [specific topics].
Provide detailed, accurate information.
Cite sources when possible.
If uncertain, explain limitations.

Kilder og verifisering

Microsoft Learn (offisielle kilder):

System message design - Microsoft Foundry Komplett guide til system message design, key concepts, og best practices
Safety system messages - Azure OpenAI Authoring techniques, safety components, og testing strategies
Prompt engineering techniques - Azure OpenAI Bredere prompt-veiledning inkludert few-shot og token efficiency
Use prompts in Copilot Studio (Re-verified MCP 2026-04) Prompt editor features: natural language creation, template library, model selection (Azure OpenAI/Foundry), temperature, knowledge retrieval, code interpreter. Prompt-nivå: agent-tool, topic-node, agent flow-node.
Azure OpenAI On Your Data - Best practices System message bruk i RAG-scenarier
Responsible AI practices for Azure OpenAI Metaprompt tuning som mitigation strategy

Code samples verifisert:

Azure OpenAI Python SDK (openai>=1.0.0) – System message i chat completions
Microsoft Entra ID authentication patterns
Copilot Studio prompt configuration

Confidence markers:

✅ GA (Generally Available): Azure OpenAI system messages, Copilot Studio instructions
✅ Documented best practices: Authoring techniques tabeller
⚠️ Implementation-dependent: Nøyaktig token cost varierer med model version

Siste oppdatering: 2026-04-10 Neste review: 2026-07

23 KiB Raw Blame History Unescape Escape

Role-Playing and Persona-Based Prompting

Introduksjon

Kjernekomponenter

1. System Message Struktur

2. Persona-Teknikker i Praksis

3. Authoring Techniques for Personas

4. Best Practices for Persona Design

Arkitekturmønstre

Mønster 1: Teknisk Support Persona

Mønster 2: Data Extraction Persona

Mønster 3: Multi-Persona Agent (Copilot Studio)

Mønster 4: Safety-First Persona

Beslutningsveiledning

Når bruke Role-Playing Personas?

Valg av Persona-Kompleksitet

Testing og Iterasjon

Integrasjon med Microsoft-stakken

Azure OpenAI Service

Copilot Studio

Microsoft 365 Copilot (Enterprise)

Semantic Kernel

Offentlig sektor (Norge)

Krav og Hensyn

Eksempel: Offentlig Servicechatbot

Compliance Checklist

Kostnad og lisensiering

Token-forbruk

Lisensiering

For arkitekten (Cosmo)

Når anbefale Role-Playing Personas

Arkitektur-spørsmål å stille

Decision Tree: Persona Complexity

Integration Patterns

Testing Playbook

Quick Reference: Common Persona Templates

Kilder og verifisering

23 KiB

Raw Blame History