# Domain-Specific Prompt Optimization

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

---

## Introduksjon

Domain-specific prompt optimization handler om å tilpasse prompts for spesialiserte fagområder som medisin, juss, finans, teknisk support eller offentlig sektor. Generelle promptingteknikker fungerer ofte dårlig når domenet krever presisjon, terminologi, compliance-krav eller kontekstforståelse som LLM-en ikke har i sin generelle treningsdata.

Ved å optimalisere prompts for et spesifikt domene kan man:
- **Øke presisjonen** — Få svar som respekterer fagterminologi og kontekst
- **Redusere hallusinasjoner** — Hindre modellen i å fabricere "fakta" fra generell kunnskap
- **Sikre compliance** — Følge regulatoriske krav (GDPR, helsepersonelloven, arkivloven)
- **Forbedre brukeropplevelse** — Gi svar som matcher brukerens forventninger til faglig nivå

**Viktighet for offentlig sektor:** Norske offentlige virksomheter opererer med strenge krav til presisjon, etterrettelighet og personvern. Domain-specific prompting er ikke valgfritt — det er en forutsetning for ansvarlig bruk av AI.

---

## Kjernekomponenter

### 1. Domain Context Declaration

Definer domenet eksplisitt i system message for å "prime" modellen:

| Domene | Eksempel system message |
|--------|-------------------------|
| **Medisin** | *"You are an AI assistant designed to help users extract information from retrieved medical documents. Please scrutinize the documents carefully before formulating a response. Always include medical disclaimers and never provide diagnostic advice."* |
| **Juss** | *"You are a legal document assistant. Answer using legal terminology accurately. Always cite sources. If legal interpretation is required, state 'consult a qualified attorney'."* |
| **Offentlig sektor (Norge)** | *"Du er en AI-assistent for offentlig sektor i Norge. Følg arkivloven, offentlighetsloven og GDPR. Svar på norsk med presise referanser til regelverk."* |
| **Teknisk support** | *"You are an expert incident support assistant that helps users solve technical issues. Base answers on similar incidents in the retrieved documents. Provide step-by-step troubleshooting."* |

*(Confidence: HIGH — basert på Microsoft Learn dokumentasjon om system messages)*

### 2. Output Structure Specification

Struktur i output reduserer feil og øker grunnlag for verifisering:

```json
{
  "CLAIM": "Påstand fra modellen",
  "CITATION": "Kildehenvisning",
  "CONFIDENCE": "HIGH/MEDIUM/LOW",
  "DISCLAIMER": "Relevant advarsel eller forbehold"
}
```

**Hvorfor dette virker:** Ved å kreve strukturert output må modellen:
1. Gjøre påstanden (første feil hvis feil)
2. Finne sitatet (andre feil hvis feil)
3. Gradere tillit (tredje feil hvis feil)

Dette gjør at hallusinasjoner krever *flere feil i sekvens*, noe som reduserer sannsynligheten for dem.

*(Confidence: HIGH — prompt engineering best practice fra Azure OpenAI dokumentasjon)*

### 3. Domain-Specific Few-Shot Examples

Few-shot learning er særlig effektivt for domener med:
- Spesialisert terminologi
- Standardiserte svarmønstre
- Compliance-krav

**Eksempel — Medisinsk assistent:**

```yaml
System: "You are a medical information assistant. Always include safety disclaimers."

User: "What is the recommended dosage for aspirin?"
Assistant: "According to medical guidelines, adult aspirin dosage for pain relief is typically 325-650mg every 4-6 hours, not exceeding 4g/24h. **Disclaimer:** This is general information only. Consult your doctor or pharmacist for personalized medical advice."

User: "Can I take aspirin with ibuprofen?"
Assistant: "Concurrent use of aspirin and ibuprofen may reduce aspirin's cardioprotective effects and increase gastrointestinal bleeding risk. **Disclaimer:** This is not medical advice. Consult your healthcare provider before combining medications."
```

*(Confidence: MEDIUM — basert på prompt engineering best practices, men krever domenespesifikk validering)*

### 4. Retrieval Augmented Generation (RAG) med domenfiltrering

For domener med store dokumentmengder (f.eks. lovverk, helsedokumentasjon, teknisk support):

| RAG-konfigurasjon | Anbefaling for domene |
|-------------------|----------------------|
| **Chunk size** | Juss: 1536 tokens (kontekst viktig), Medisin: 512 tokens (presisjon viktig) |
| **Strictness** | Høy (4-5) for compliance-domener, moderat (3) for general knowledge |
| **Search type** | Hybrid (vector + keyword) + semantic for flerspråklige domener |
| **Field mapping** | Map `content`, `title`, `citation`, `legal_tag` eller `classification` |

**Eksempel — Norwegian public sector:**

```json
{
  "data_sources": [{
    "type": "AzureCognitiveSearch",
    "parameters": {
      "indexName": "offentlig-regelverk-index",
      "fieldsMapping": {
        "contentFields": ["paragraph_text", "section_title"],
        "titleField": "law_name",
        "urlField": "lovdata_url",
        "filepathField": "document_id"
      },
      "inScope": true,
      "strictness": 4,
      "topNDocuments": 5
    }
  }]
}
```

*(Confidence: HIGH — Azure OpenAI On Your Data dokumentasjon)*

### 5. Multi-Lingual Domain Handling

For domener som opererer på flere språk (f.eks. norsk lovverk vs. EU-direktiver):

**Best practice:**
- Separat indeks per språk hvis mulig
- Eksplisitt språkinstruksjon i system message
- Semantic search for cross-lingual retrieval

```yaml
System: "You are an AI assistant designed to help users extract information from retrieved Norwegian legal documents. Please scrutinize the Norwegian documents carefully before formulating a response. The user's query will be in Norwegian, and you must respond in Norwegian with references to Norwegian law."
```

*(Confidence: HIGH — Microsoft Learn anbefaler dette for multi-lingual scenarios)*

---

## Arkitekturmønstre

### Pattern 1: Chain-of-Thought for Domain Reasoning

For komplekse domener (medisin, juss, ingeniørfag) hvor resonnering er kritisk:

```yaml
System: "You are a legal assistant. For each query, think step-by-step:
1. Identify the legal question
2. Find relevant statutes in retrieved documents
3. Apply legal reasoning
4. State conclusion with citations
Format: QUESTION → RELEVANT LAW → REASONING → CONCLUSION"

User: "Can an employer terminate without notice?"
Assistant:
"QUESTION: Employment termination without notice legality
RELEVANT LAW: Arbeidsmiljøloven § 15-14 states that termination without notice requires 'særlig grunner' (special grounds)
REASONING: Special grounds typically include serious breach of duty or criminal activity by employee
CONCLUSION: No, employer cannot terminate without notice unless special grounds exist per AML § 15-14. [Citation: Arbeidsmiljøloven § 15-14]"
```

*(Confidence: MEDIUM-HIGH — Chain-of-thought er dokumentert effektivt, men krever testing per domene)*

### Pattern 2: Role-Based Prompting with Domain Expertise

```yaml
System: "You are a senior incident response analyst with 10 years experience in Microsoft Azure infrastructure. You:
- Prioritize security over convenience
- Always check for related incidents in the knowledge base
- Escalate if unsure rather than guess
- Document all troubleshooting steps"
```

Dette mønsteret virker ved å:
1. Definere en "persona" med domeneekspertise
2. Liste opp atferdsprinsipper som er kritiske for domenet
3. Gi modellen en "mental model" for hvordan eksperter tenker

*(Confidence: MEDIUM — Ikke direkte dokumentert i Microsoft sources, men widely recognized pattern)*

### Pattern 3: Conditional Domain Routing

For systemer som håndterer flere domener:

```python
# Pseudo-code for domain routing
user_query = "What are the symptoms of diabetes?"

if classify_domain(user_query) == "medical":
    system_message = MEDICAL_SYSTEM_PROMPT
    add_disclaimer = True
    strictness = 5
elif classify_domain(user_query) == "technical":
    system_message = TECHNICAL_SYSTEM_PROMPT
    add_disclaimer = False
    strictness = 3

response = openai.chat.completions.create(
    model="gpt-4",
    messages=[
        {"role": "system", "content": system_message},
        {"role": "user", "content": user_query}
    ]
)
```

*(Confidence: MEDIUM — Pattern basert på generell arkitekturpraksis)*

### Pattern 4: Grounding with Domain-Specific Metadata

For Azure AI Search indexer med domeneinformasjon:

| Metadata-felt | Eksempel verdi | Formål |
|---------------|----------------|--------|
| `classification` | "Helsepersonelloven", "GDPR-relevant" | Compliance-filtrering |
| `confidence_level` | "peer_reviewed", "draft", "official" | Kildevurdering |
| `effective_date` | "2024-01-01" | Tidsrelevans (viktig for juss, regelverk) |
| `domain_tags` | ["diabetes", "type2", "symptoms"] | Presisjonssøk |

```json
{
  "fieldsMapping": {
    "contentFields": ["content"],
    "titleField": "title",
    "urlField": "url",
    "vectorFields": ["content_vector"],
    "metadataFields": ["classification", "effective_date", "confidence_level"]
  }
}
```

*(Confidence: HIGH — Azure AI Search field mapping er GA-funksjonalitet)*

---

## Beslutningsveiledning

### Når velge domain-specific prompting?

| Kriterium | Vurdering |
|-----------|-----------|
| **Høy presisjonskrav** | JA → Domain prompting kritisk |
| **Regulatoriske krav** | JA → Må ha (compliance, personvern) |
| **Spesialisert terminologi** | JA → Few-shot examples nødvendig |
| **Lav toleranse for feil** | JA → Strictness = 5, grounding required |
| **Generisk FAQ** | NEI → Standard prompting holder |

### Decision Tree: Hvilken prompting-strategi?

```
START
├─ Har du eksisterende dokumentasjon (RAG)?
│  ├─ JA → Bruk Azure OpenAI On Your Data
│  │      ├─ Compliance-kritisk? → Strictness 4-5, inScope=true
│  │      └─ General knowledge? → Strictness 3, hybrid search
│  └─ NEI → Fine-tuning eller GPT-4 med few-shot
│         ├─ <50 eksempler? → Few-shot learning
│         └─ >500 eksempler? → Vurder fine-tuning
│
└─ Krever domenet multi-turn reasoning?
   ├─ JA → Chain-of-thought + conversation history
   └─ NEI → Single-turn med strukturert output
```

*(Confidence: MEDIUM — Basert på Azure OpenAI best practices og prompt engineering guidance)*

---

## Integrasjon med Microsoft-stakken

### Azure OpenAI On Your Data

**Best practice for domain-specific prompting:**

```python
# Python SDK example
from openai import AzureOpenAI

client = AzureOpenAI(
    api_key=os.getenv("AZURE_OPENAI_API_KEY"),
    api_version="2024-02-01",
    azure_endpoint=os.getenv("AZURE_OPENAI_ENDPOINT")
)

# Domain-specific configuration
response = client.chat.completions.create(
    model="gpt-4",
    messages=[
        {
            "role": "system",
            "content": """You are a medical information assistant for healthcare professionals in Norway.
            Rules:
            - Answer in Norwegian
            - Always cite sources from Helsedirektoratet or approved medical literature
            - Include medical disclaimers
            - Never provide diagnostic advice"""
        },
        {
            "role": "user",
            "content": "Hva er anbefalte screeningintervaller for diabetes type 2?"
        }
    ],
    extra_body={
        "data_sources": [{
            "type": "azure_search",
            "parameters": {
                "endpoint": os.getenv("AZURE_SEARCH_ENDPOINT"),
                "index_name": "helsedirektoratet-index",
                "authentication": {
                    "type": "api_key",
                    "key": os.getenv("AZURE_SEARCH_KEY")
                },
                "in_scope": True,  # Limit to grounding data only
                "strictness": 4,   # High strictness for medical domain
                "top_n_documents": 5
            }
        }]
    }
)

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

*(Confidence: HIGH — basert på Azure OpenAI SDK dokumentasjon)*

### Copilot Studio med domain grounding

For public sector:

1. **Custom topics** — Definer topic triggers basert på domene-keywords
2. **Generative answers** — Koble til Azure OpenAI On Your Data med domain-specific index
3. **Conversation boosting** — Bruk SharePoint/Dataverse som knowledge source
4. **Compliance guardrails** — Bruk content filters + custom system message

| Konfigurasjon | Anbefaling for offentlig sektor |
|---------------|--------------------------------|
| **Data source** | SharePoint med klassifiserte dokumenter |
| **System message** | Inkluder referanser til offentlighetsloven § 3 |
| **Content moderation** | Høy (block PII, sensitive topics) |
| **Citation style** | Inline citations med dokumentklassifisering |

*(Confidence: MEDIUM-HIGH — Copilot Studio best practices)*

### Azure AI Foundry

**Domain-specific deployment pattern:**

```yaml
# AI Foundry project configuration
project:
  name: "medisinsk-assistent-pilot"
  region: "norwayeast"

deployments:
  - name: "gpt-4-medical"
    model: "gpt-4"
    sku: "Standard"
    capacity: 10
    system_message: |
      You are a medical information assistant...
      [domain-specific system message]

  - name: "embedding-medical"
    model: "text-embedding-ada-002"
    sku: "Standard"

data_connections:
  - type: "azure_ai_search"
    name: "medical-knowledge-base"
    index_name: "helsedirektoratet-retningslinjer"

safety:
  content_filters:
    - category: "medical_advice"
      severity: "high"
      action: "block"
```

*(Confidence: MEDIUM — Azure AI Foundry er relativt nytt, pattern basert på generell guidance)*

---

## Offentlig sektor (Norge)

### Juridiske og etiske rammeverk

| Regelverk | Implikasjon for prompting |
|-----------|---------------------------|
| **Offentlighetsloven § 3** | System message må inkludere: *"If document classification is 'UNNTATT', do not include in response"* |
| **Arkivloven § 6** | Alle AI-genererte svar må logges med metadata (timestamp, user, query, sources) |
| **GDPR Art. 22** | Hvis AI gjør "automated decision", må bruker informeres — legg til disclaimer |
| **Personopplysningsloven § 11** | PII må filtreres ut av prompts — bruk Azure OpenAI content filters |

*(Confidence: HIGH — Norsk lovverk er kjent, men krever juridisk validering for spesifikke use cases)*

### Use case: NAV selvbetjeningsbot

**Scenario:** NAV ønsker en chatbot som hjelper brukere med spørsmål om dagpenger.

**Domain-specific prompt design:**

```yaml
System: |
  Du er NAV Assistent, en AI-assistent som hjelper brukere med spørsmål om NAVs tjenester.

  REGLER:
  - Svar alltid på norsk (bokmål)
  - Referer til offisielle NAV-sider (nav.no)
  - Hvis spørsmålet gjelder personlig situasjon, svar: "For å vurdere din konkrete situasjon, ta kontakt med NAV på telefon 55 55 33 33 eller book time via nav.no"
  - Aldri gi juridisk rådgivning — referer til Folketrygdloven med paragraf
  - Hvis usikker, svar: "Jeg er usikker på dette. Ta kontakt med NAV for sikker informasjon."

  STRUKTUR:
  - Start med direkte svar
  - Gi lenke til relevant NAV-side
  - Avslutt med "Trenger du mer hjelp? Ring 55 55 33 33"

User: "Hvor mye kan jeg tjene ved siden av dagpenger?"
Assistant: |
  Du kan tjene inntil 60% av dagpengegrunnlaget ditt uten at dagpengene reduseres. Overstiger du dette, reduseres dagpengene krone for krone.

  Les mer: https://www.nav.no/dagpenger#hvor-mye
  (Ref: Folketrygdloven § 4-18)

  Trenger du mer hjelp? Ring 55 55 33 33 eller book time via nav.no.
```

**RAG-konfigurasjon:**

| Parameter | Verdi | Begrunnelse |
|-----------|-------|-------------|
| `inScope` | `true` | Kun bruk NAV.no som kilde |
| `strictness` | `4` | Høy — feil kan ha store konsekvenser |
| `topNDocuments` | `3` | Fokusert svar, ikke overload |
| `roleInformation` | System message over | Domain-specific instruksjoner |

*(Confidence: HIGH — Basert på Azure OpenAI On Your Data og offentlig sektor best practices)*

### Personvernhensyn

**PII-filtrering:**

```json
{
  "content_filter_config": {
    "pii_detection": {
      "enabled": true,
      "categories": ["phone_number", "email", "ssn", "address"],
      "action": "redact"
    }
  }
}
```

**Logging for etterrettelighet:**

```python
# Pseudo-code
import logging

logger = logging.getLogger("nav-assistent")

def log_conversation(user_id, query, response, sources):
    logger.info({
        "timestamp": datetime.utcnow().isoformat(),
        "user_id_hash": hash(user_id),  # Anonymized
        "query_length": len(query),
        "response_length": len(response),
        "sources_used": [s["title"] for s in sources],
        "model": "gpt-4",
        "deployment": "nav-assistent-prod"
    })
```

*(Confidence: MEDIUM-HIGH — Best practice, men krever organisasjonsspesifikk vurdering)*

---

## Kostnad og lisensiering

### Token-estimat per domene

Basert på testing (Azure OpenAI dokumentasjon):

| Konfigurasjon | Generation prompt tokens | Intent prompt tokens | Response tokens | Total avg |
|---------------|--------------------------|---------------------|-----------------|-----------|
| **Default (chunk 1024, top 5)** | 4297 | 1366 | 111 | ~5774 |
| **Medical (chunk 512, top 5, strictness 5)** | ~3800 | ~1200 | ~120 | ~5120 |
| **Legal (chunk 1536, top 10, strictness 4)** | ~7200 | ~1500 | ~150 | ~8850 |

**Kostnad (gpt-4, ca. priser):**
- Medical domain: ~5120 tokens × $0.00003/token (input) = $0.15 per query
- Legal domain: ~8850 tokens × $0.00003/token = $0.27 per query

**Optimaliseringstips:**
1. Bruk **GPT-3.5-turbo** for enklere queries (10x billigere)
2. Cache **intent prompt** hvis samme bruker stiller flere spørsmål
3. Bruk **semantic search** for å redusere antall irrelevante chunks
4. **Chunk size 512** for presisjon vs. 1024 for kontekst

*(Confidence: HIGH — basert på Azure OpenAI pricing og token usage documentation)*

### Lisenskrav

| Microsoft-produkt | Relevant for | Lisens |
|-------------------|--------------|--------|
| **Azure OpenAI** | Alle domener | Azure subscription + Azure OpenAI access (application required) |
| **Azure AI Search** | RAG-baserte løsninger | Standard tier ($250/month+) for semantic search |
| **Copilot Studio** | Public-facing bots | Per-user ($200/month) eller per-session ($100/1000 sessions) |
| **M365 Copilot** | Internal assistants | Microsoft 365 E3/E5 + Copilot ($30/user/month) |

*(Confidence: MEDIUM — Priser endres, sjekk offisiell Microsoft pricing)*

---

## For arkitekten (Cosmo)

### Når anbefale domain-specific prompting?

**JA hvis:**
1. ✅ Klient opererer i regulert domene (helse, finans, juss, offentlig)
2. ✅ Feil kan ha store konsekvenser (økonomi, helse, personvern)
3. ✅ Klient har eksisterende dokumentasjon (RAG mulig)
4. ✅ Terminologi er spesialisert og konsistent

**NEI hvis:**
1. ❌ Generisk FAQ uten compliance-krav
2. ❌ Klient har ikke dokumentasjon (fine-tuning eller GPT-4 generell kunnskap)
3. ❌ Budsjettet er svært begrenset (domain prompting øker token-bruk)

### Typiske feil å unngå

| Feil | Konsekvens | Fix |
|------|------------|-----|
| **For generisk system message** | Modellen gir generiske svar uten domenetilpasning | Legg til eksplisitt rolleinformasjon og compliance-krav |
| **Manglende disclaimers** | Juridisk/etisk risiko | Inkluder disclaimers i system message + output structure |
| **For stor chunk size** | Modellen drukner i informasjon | Reduser chunk size til 512 for presisjonsdomener |
| **inScope=false** | Modellen hallusinerer ved siden av grounding data | Sett `inScope=true` for compliance-domener |
| **Manglende citation** | Ikke mulig å verifisere svar | Bruk `"type": "CONTENT"` citation pattern i API |

*(Confidence: HIGH — Basert på Azure OpenAI best practices og Cosmo's erfaring)*

### Anbefalte verktøy

| Fase | Verktøy | Formål |
|------|---------|--------|
| **Prompt-testing** | Azure AI Foundry Playground | Iterativ testing av system messages |
| **Evaluation** | Prompt Flow + Custom evaluators | Måle domain accuracy (presisjon, recall, F1) |
| **Deployment** | Azure OpenAI API + RAG | Produksjon med logging og monitoring |
| **Monitoring** | Azure Monitor + Application Insights | Token usage, latency, error rate |

### Spørsmål å stille klienten

1. **Hva er konsekvensen av feil?** (Lav/Medium/Høy) → Bestemmer strictness, inScope
2. **Har dere eksisterende dokumentasjon?** → RAG vs. fine-tuning
3. **Hva er compliance-kravene?** → System message disclaimers, content filters
4. **Hva er forventet volum?** → Cost estimation (GPT-4 vs. GPT-3.5)
5. **Kreves det multi-språk støtte?** → Separat indeks per språk
6. **Må svar være auditable?** → Logging, citation, metadata tracking

---

## Kilder og verifisering

### Microsoft Learn dokumentasjon (fetched via MCP 2026-02-04)

1. **Prompt engineering techniques** (Azure OpenAI)
   https://learn.microsoft.com/en-us/azure/ai-foundry/openai/concepts/prompt-engineering
   *Source for: Best practices, few-shot learning, chain-of-thought, output structure*

2. **Azure OpenAI On Your Data**
   https://learn.microsoft.com/en-us/azure/ai-foundry/openai/concepts/use-your-data
   *Source for: RAG configuration, field mapping, strictness, multi-lingual support, token estimation*

3. **Transparency note for Azure OpenAI**
   https://learn.microsoft.com/en-us/azure/ai-foundry/responsible-ai/openai/transparency-note
   *Source for: Model capabilities, limitations, responsible AI considerations*

4. **Azure OpenAI FAQ**
   https://learn.microsoft.com/en-us/azure/ai-foundry/openai/faq
   *Source for: Language handling, model behavior, grounding strategies*

5. **Apply prompt engineering with Azure OpenAI Service - Training**
   https://learn.microsoft.com/en-us/training/modules/apply-prompt-engineering-azure-openai/
   *Source for: Prompt engineering learning objectives, prerequisites*

### Confidence markers brukt i dokumentet

- **HIGH** — Direkte dokumentert i Microsoft Learn eller Azure OpenAI docs
- **MEDIUM-HIGH** — Logisk utledning basert på dokumentasjon + generell best practice
- **MEDIUM** — Best practice fra industrien, ikke eksplisitt dokumentert av Microsoft
- **MEDIUM-LOW** — Antatt basert på generell kunnskap, bør verifiseres

### Verifiseringsmetode

- **MCP-søk** — 3 søk mot microsoft-learn (2026-02-04)
- **Fetch** — 2 fullstendige dokumenter hentet via microsoft_docs_fetch
- **Code samples** — Søk mot microsoft_code_sample_search (ingen direkte treff for "domain prompting", men generelle patterns funnet)

---

**Cosmo's anbefaling:**
*Start med Azure OpenAI On Your Data + RAG for domener med dokumentasjon. Bruk GPT-4 med high strictness (4-5) og inScope=true for compliance-kritiske domener. Test grundig med representative queries før produksjon. For offentlig sektor: alltid inkluder disclaimers, logging og PII-filtering.*

---

**Dato generert:** 2026-02-04
**Generert av:** Cosmo Skyberg (AI Architect) via MCP-research
**Neste review:** 2026-08 (6 måneder) eller ved major Azure OpenAI API update