15 KiB
System Message Design Patterns and Best Practices
Last updated: 2026-06-24 Status: GA Category: Prompt Engineering & LLM Optimization
Introduksjon
System messages (også kalt system prompts eller metaprompts) er grunnleggende for å styre oppførselen til chat-baserte LLM-modeller i Azure OpenAI-økosystemet. De fungerer som det øverste instruksjonslaget som definerer assistentens rolle, tone, outputformat og sikkerhetsgrenser. En veltilpasset system message kan dramatisk forbedre konsistensen og kvaliteten på AI-assisterte tjenester, mens en dårlig designet kan føre til uforutsigbar oppførsel og brudd på forventet scope.
System messages sender du som del av chat completions API, hvor meldinger er organisert i roller: system, user og assistant. System-rollen plasseres typisk først og setter premissene for hele samtalen. Til forskjell fra prompt engineering for eldre completion-APIer, hvor alt er fritekst, gir chat-modellene en strukturert tilnærming som gjør det lettere å skille instruksjoner fra brukerinput.
I Microsoft Foundry (tidligere Azure OpenAI Studio) og via REST API kan utviklere definere system messages både programmatisk og via UI. Forståelse av hvordan disse virker – og hvilke begrensninger de har – er essensielt for å bygge produksjonsklare AI-løsninger.
Kjernekomponenter
En effektiv system message består av flere komponenter som samarbeider for å forme modellens oppførsel:
1. Role Definition (rollespesifikasjon)
Definer tydelig hva assistenten er. Eksempler:
- "You are a technical support assistant for an internal product."
- "Assistant is a large language model trained by OpenAI."
- "You are an AI assistant designed to help Norwegian public sector employees with AI Act compliance."
Rollespesifikasjonen setter konteksten for modellens persona og ekspertise.
2. Scope and Boundaries (omfang og grenser)
List eksplisitt hva assistenten skal og ikke skal gjøre. Dette reduserer risikoen for at modellen besvarer spørsmål utenfor sin kompetanse eller genererer upassende innhold.
Eksempel:
Only answer questions using the context below. Do not perform actions unrelated to incident support.
3. Output Format Specification (formatspesifikasjon)
Hvis applikasjonen krever strukturert output (JSON, CSV, markdown), spesifiser dette klart i system message. Azure OpenAI støtter også JSON mode, men system-instruksjonen må eksplisitt be om JSON-format.
Eksempel:
You extract entities from user text. Return only JSON using this schema:
{
"name": "",
"company": "",
"phone_number": ""
}
4. Tone and Communication Style (tone og stil)
Styr hvordan assistenten kommuniserer: formelt, uformelt, i rim, konsis, pedagogisk osv. Dette påvirker brukeropplevelsen kraftig.
Eksempel:
You respond in rhyme. If the user asks a question you don't know the answer to, say so.
5. Fallback Behavior (fallback-oppførsel)
Definer hva modellen skal gjøre når den:
- Ikke har nok informasjon
- Får tvetydige spørsmål
- Blir bedt om noe utenfor scope
Eksempel:
If you don't have enough information to answer, ask a clarifying question. If you still can't answer, say you don't know.
6. Safety and Compliance Constraints (sikkerhetsregler)
Legg til instruksjoner som reduserer risiko for skadelig output. For høy-risiko applikasjoner i offentlig sektor bør disse være eksplisitte:
Do not generate content that violates Norwegian data protection laws. Refuse requests for personal data without proper authorization.
Azure tilbyr også dedikerte Safety System Message Templates som kan kombineres med egendefinerte system messages for å styrke RAI (Responsible AI) compliance.
Arkitekturmønstre
Pattern 1: Minimal System Message
Egnet for generiske assistenter uten strenge krav til scope eller format.
messages = [
{"role": "system", "content": "You are a helpful AI assistant."},
{"role": "user", "content": "Who were the founders of Microsoft?"}
]
Fordeler: Enkel, lav token-bruk Ulemper: Lite kontroll, kan generere uønsket innhold
Pattern 2: Structured Task-Specific Assistant
For domene-spesifikke use cases (customer support, entity extraction, compliance chatbots).
system_message = """
You are a technical support assistant for Azure AI services.
Your job is to help users troubleshoot issues with Azure OpenAI deployments.
Only answer questions related to Azure OpenAI, Azure AI Search, and Microsoft Foundry.
If the user asks about unrelated topics, politely redirect them.
When unsure, ask clarifying questions. If you lack information, say "I don't know."
"""
Fordeler: Klar scope, forutsigbar oppførsel Ulemper: Krever grundig testing for edge cases
Pattern 3: Grounded RAG Assistant (Retrieval-Augmented Generation)
Brukes med Azure OpenAI On Your Data eller egne RAG-pipelines. System message må instruere modellen om å prioritere hentet kontekst over intern kunnskap.
system_message = """
You are an AI assistant that helps users answer questions using retrieved documents only.
Do not use your own knowledge. Generate citations to retrieved documents for every claim.
If the user question cannot be answered using retrieved documents, explain why documents are relevant but insufficient.
"""
Fordeler: Reduserer hallusinasjoner, øker transparens Ulemper: Krever robust retrieval-system
Pattern 4: Multi-Language and Localization
For norsk offentlig sektor eller internasjonale brukere.
system_message = """
You are an AI assistant for Norwegian public sector employees.
User questions can be in Norwegian or English. Retrieve documents in Norwegian and read them carefully.
All answers must be in Norwegian, translating knowledge from English sources when necessary.
"""
Fordeler: Språktilpassing, kulturell sensitivitet Ulemper: Kan øke latency ved oversettelse
Pattern 5: Chain-of-Thought Encouraged
For komplekse resonnerende oppgaver (ikke relevant for o-series reasoning models som har egen reasoning-fase).
system_message = """
You are an expert in regulatory compliance analysis.
When answering questions, think step by step:
1. Identify the relevant regulation
2. Extract applicable clauses
3. Analyze the user's scenario
4. Provide a reasoned conclusion
"""
Fordeler: Bedre resonnering, transparens i beslutningsprosess Ulemper: Økt token-bruk, lengre svar
Beslutningsveiledning
Når bruke korte vs lange system messages?
| Scenario | Anbefaling |
|---|---|
| Generisk chatbot | Kort (1-3 setninger) |
| Domene-spesifikk assistent | Medium (50-200 tokens) |
| Compliance-kritisk applikasjon | Lang (200-500 tokens) |
| RAG-basert system | Medium-lang (100-300 tokens) |
Viktig: Lange system messages spiser av context window og reduserer plass til brukerinnhold. Test alltid token-forbruk.
Skal du bruke JSON mode eller system message for output-format?
Azure OpenAI tilbyr både JSON mode (via API-parameter) og system message-basert format enforcement. Kombinasjon anbefales:
- Aktiver JSON mode via API (
response_format: {"type": "json_object"}) - Spesifiser schema i system message for ekstra styring
Hvordan prioritere konflikterende instruksjoner?
Unngå konflikter som "be brief" og "be comprehensive" uten tydelig prioritering. Hvis begge trengs:
Provide comprehensive answers, but prioritize brevity. Limit responses to 3-5 sentences unless the user explicitly requests more detail.
Testing og iterasjon
- Bruk både benigne og adversarielle prompts i testing
- Mål defect rate, ikke bare accuracy
- Iterer basert på edge case failures
- Kombiner system messages med Azure Content Safety filters for layered defense
Integrasjon med Microsoft-stakken
Azure OpenAI Service
System messages er first-class citizens i Azure OpenAI Chat Completions API (versjon 2024-02-01 og nyere). Send via messages array:
from openai import AzureOpenAI
import os
client = AzureOpenAI(
azure_endpoint=os.getenv("AZURE_OPENAI_ENDPOINT"),
api_key=os.getenv("AZURE_OPENAI_API_KEY"),
api_version="2024-02-01"
)
response = client.chat.completions.create(
model="gpt-4o",
messages=[
{"role": "system", "content": "You are a helpful assistant."},
{"role": "user", "content": "Explain RAG architecture"}
]
)
Verified: Kodeeksempel fra Microsoft Learn (2024-02-01 API)
Microsoft Foundry (Portal)
I AI Foundry Studio kan du sette system message via:
- Chat playground → System message field
- Deployment configuration → Default system message
- Azure OpenAI On Your Data → System message override
Copilot Studio
For Microsoft Copilot Studio (tidligere Power Virtual Agents), konfiguerer du system-like instructions via:
- Generative AI node → System prompt field
- Prompt builder → Custom instructions
Copilot Studio bruker implisitt system-message-konseptet, men med begrenset kontroll sammenlignet med Azure OpenAI direkte.
Microsoft 365 Copilot Extensions
Ved utvikling av Copilot extensions (via Teams Toolkit eller Copilot Studio), kan system messages defineres i declarative agents manifest eller via Custom Engine Agent API.
Azure AI Search + RAG
Når du bruker Azure AI Search som retrieval layer, kombiner system message med On Your Data system message templates:
system_message = """
You answer queries using information from retrieved documents about Azure AI services.
Retrieved documents are in JSON format with fields: title, content, source.
Cite sources using [doc: source_name] format.
"""
Offentlig sektor (Norge)
AI Act Compliance
EU AI Act krever transparency og human oversight for høy-risiko AI-systemer. System messages kan bidra til compliance ved:
- Eksplisitt rolledefinisjon: "You are an AI assistant (not a human expert)"
- Scope-begrensninger: "Only provide informational guidance, not legal advice"
- Fallback til menneskelig ekspert: "For complex cases, recommend consulting a human specialist"
GDPR og personvern
System messages bør instruere modellen om personvernhåndtering:
Do not generate, store, or request personal data unless explicitly authorized.
If a user provides personal information, remind them of data protection principles.
Språk og kulturell kontekst
Norsk offentlig sektor krever ofte norskspråklige tjenester. System message bør:
- Eksplisitt be om norsk output
- Tilpasse tone til norsk forvaltningskultur (høflig, nøytral)
- Referere til norske lover og standarder når relevant
Eksempel:
Du er en AI-assistent for norsk offentlig sektor.
Svar alltid på norsk (bokmål). Bruk formell tone.
Referer til norsk regelverk (forvaltningsloven, GDPR/DPIA-krav).
Ved tvil, be brukeren om å kontakte saksbehandler.
Kostnad og lisensiering
Token-bruk
System messages teller mot totale input-tokens for hver request. For repetitive applikasjoner (chatbots med mange samtaler) kan dette summere seg.
Kostnadsoptimalisering:
- Hold system messages konsise (100-200 tokens)
- Bruk prompt caching (hvis tilgjengelig i API-versjon) for å redusere kostnad ved gjentatt system message
- Vurder om deler av instruksjonene kan flyttes til pre-processing eller client-side logic
Lisensiering
- Azure OpenAI: Pay-as-you-go (per 1K tokens) eller Provisioned Throughput Units (PTU) for dedikert kapasitet
- Microsoft 365 Copilot: Inkludert i M365 Copilot-lisens, men begrensninger på custom system messages avhenger av Copilot-type
- Copilot Studio: Krever Copilot Studio-lisens, system messages via generative AI nodes teller mot message-quota
Anbefaling: For høyvolum enterprise-løsninger, vurder PTU for forutsigbare kostnader.
For arkitekten (Cosmo)
Design-anbefalinger
- Start med rollespesifikasjon: Definer alltid "You are..." først. Dette gir modellen en persona å forholde seg til.
- Legg til boundaries tidlig: Eksplisitt scope reduserer risiko for jailbreaks og prompt injections.
- Test adversarielt: Bruk red teaming for å identifisere edge cases hvor system message ikke overholdes.
- Kombiner med content filters: System messages garanterer ikke compliance – layer med Azure Content Safety API.
- Versjonskontroll: Behandle system messages som code – bruk Git, dokumenter endringer, A/B-test nye versjoner.
Trade-offs
| Aspekt | Kort system message | Lang system message |
|---|---|---|
| Kontroll | Lav | Høy |
| Token-kostnad | Lav | Høy |
| Context window | Mer plass til brukerinnhold | Mindre plass |
| Konsistens | Varierende | Mer forutsigbar |
| Vedlikehold | Enklere | Krever grundig testing |
Når unngå system messages?
For reasoning models (O1, O3) anbefales det å holde system messages minimale, da disse modellene har egen extended thinking-fase. Bruk heller developer-rollen (ekvivalent til system for reasoning models):
response = client.chat.completions.create(
model="gpt-5-mini", # o1-deployment
messages=[
{"role": "developer", "content": "You are a helpful assistant."},
{"role": "user", "content": "Explain quantum computing"}
],
reasoning_effort="medium"
)
Verified: O-series models syntax fra Microsoft Learn (2024-10 API)
Arkitekturmønstre for enterprise
For store organisasjoner med mange AI-assistenter:
- Template library: Opprett standard system message templates per use case (support, compliance, content generation)
- Centralized management: Bruk Microsoft Foundry prompt management for versjonskontroll
- A/B testing framework: Deploy parallelle varianter av system messages, mål success metrics
- Monitoring: Logg system message effectiveness via Application Insights
Kilder og verifisering
Verified (fra Microsoft Learn MCP):
- System message design concepts: https://learn.microsoft.com/en-us/azure/foundry/openai/concepts/advanced-prompt-engineering
- Prompt engineering techniques: https://learn.microsoft.com/en-us/azure/foundry/openai/concepts/prompt-engineering
- Safety system messages: https://learn.microsoft.com/en-us/azure/foundry/openai/concepts/system-message
- Code samples (Python SDK): https://learn.microsoft.com/en-us/azure/foundry/openai/how-to/chatgpt
- Azure OpenAI On Your Data best practices: https://learn.microsoft.com/en-us/azure/foundry-classic/openai/concepts/use-your-data
Baseline (modellkunnskap):
- EU AI Act compliance patterns (February 2026)
- Norwegian public sector AI guidelines (Digdir anbefalinger)
- Token optimization strategies for production systems
Sist verifisert: 2026-02-04