Per-kilde verifiserings-agenter (Opus xhigh, live microsoft_docs_fetch) bekreftet hver verdi mot kilden FOER endring; alle forekomster av samme gale fakta fikset fil-vidt (ikke bare sitert linje). - 37/38 confirm-fix anvendt; #8 (model-selection «Model Router GA») AVVIST: fila var allerede korrekt (Model Router GA siden 2025-11-18); den siterte model-choice-guide har utdatert «(preview)»-etikett. AA «fikse» ville innfoert en feil. - Tverteklynger reconciled til kilde-sann verdi: AI Search storage (S1 160/S2 512/S3 1024/L1 2048/L2 4096 GB; vektor 5/35/150/300), Quota Tiers (erstatter Default/Enterprise + «1 Unit Capacity»). - Hoey-innsats: realtime Schrems II omskrevet (global deployment != EU-residens, selv-verifisert mot kilde); Data Zone Norway East = gpt-5.4 OG gpt-5.5 (ikke kun 5.5); computer-use = gpt-5.4 + computer-tool (region flagget for verifisering). - Suite 552/552 groenn. Manifest oppdatert (fixed/verdict/verified per fiks). Spor 1-froe (cross-fil-gjentakelser i UBEROERTE filer): «DDoS Protection Standard» i ros-ai-threat-library.md + zero-trust-ai-services.md. Tilstoetende funn (ikke i de 38): se docs / STATE.
551 lines
23 KiB
Markdown
551 lines
23 KiB
Markdown
# Reasoning Models (O1/O3) Optimization and Usage
|
||
|
||
**Last updated:** 2026-06-19
|
||
**Status:** GA
|
||
**Category:** Prompt Engineering & LLM Optimization
|
||
|
||
---
|
||
|
||
## Introduksjon
|
||
|
||
Azure OpenAI sine reasoning models (O-serien og GPT-5-serien) representerer en ny generasjon språkmodeller som bruker chain-of-thought reasoning for å løse komplekse problemer. Disse modellene bruker mer tid på å "tenke" før de genererer et svar, noe som gjør dem eksepsjonelt sterke innen områder som koding, matematikk, vitenskapelig resonnering og kompleks dokumentanalyse.
|
||
|
||
O-serien inkluderer modeller som `o1`, `o3`, `o3-mini`, `o3-pro`, `o4-mini` og `codex-mini`, mens GPT-5-serien inkluderer `gpt-5`, `gpt-5-mini`, `gpt-5-pro`, `gpt-5-codex` og flere varianter. Disse modellene skiller seg fra tradisjonelle completion-modeller ved at de genererer skjulte reasoning tokens som brukes til intern resonnering, men som normalt ikke returneres til brukeren (med mindre reasoning summary er aktivert).
|
||
|
||
Den viktigste optimaliseringen for reasoning models er å forstå når de skal brukes, hvordan man prompter dem effektivt, og hvordan man balanserer reasoning effort mot kostnad og responstid.
|
||
|
||
## Kjernekomponenter / Nøkkelegenskaper
|
||
|
||
### Modellfamilier og kapabiliteter
|
||
|
||
| Modellserie | Eksempler | Context Window | Styrker |
|
||
|-------------|-----------|----------------|---------|
|
||
| **O3-serien** | `o3`, `o3-mini`, `o3-pro` | 200K input / 100K output | Chain-of-thought reasoning, structured outputs, function calling |
|
||
| **O4-serien** | `o4-mini`, `codex-mini` | 200K input / 100K output | Raskere reasoning, kostnadseffektivt, ideal for koding |
|
||
| **O1-serien** | `o1`, `o1-preview`, `o1-mini` | 200K input / 100K output | Eldre reasoning models, fortsatt støttet |
|
||
| **GPT-5-serien** | `gpt-5`, `gpt-5-mini`, `gpt-5-codex`, `gpt-5-pro` | 400K input / 128-272K output | Avansert reasoning, nye features (verbosity, preamble, lark_tool) |
|
||
|
||
### Reasoning Effort Levels
|
||
|
||
Reasoning effort kontrollerer hvor mye tid modellen bruker på resonnering. Høyere effort gir bedre kvalitet, men øker responstid og antall reasoning tokens.
|
||
|
||
| Level | Bruksområde | Reasoning Tokens | Responstid |
|
||
|-------|-------------|------------------|------------|
|
||
| `none` | Kun GPT-5.1 — ingen reasoning overhead | 0 | Raskest |
|
||
| `minimal` | Enkle oppgaver, raske svar | Lavt | Veldig rask |
|
||
| `low` | Standard oppgaver med litt kompleksitet | Moderat | Rask |
|
||
| `medium` | Balansert kvalitet og hastighet (default) | Middels | Moderat |
|
||
| `high` | Komplekse problemer, viktig presisjon | Høyt | Langsom |
|
||
| `xhigh` | Kun `gpt-5.1-codex-max` — maksimal reasoning | Svært høyt | Svært langsom |
|
||
|
||
### API-støtte
|
||
|
||
| Feature | O-serien | GPT-5-serien | Kommentar |
|
||
|---------|----------|--------------|-----------|
|
||
| **Chat Completions API** | ✅ (de fleste) | ✅ | Standard API-format |
|
||
| **Responses API** | ✅ | ✅ | Nyere API med bedre reasoning-støtte |
|
||
| **Developer messages** | ✅ | ✅ | Tilsvarer system messages |
|
||
| **Structured outputs** | ✅ | ✅ | JSON schema validation |
|
||
| **Function/tool calling** | ✅ | ✅ | Parallel tool calls varierer |
|
||
| **Image input** | ✅ (unntatt o3-mini) | ✅ | Multimodal reasoning |
|
||
| **Reasoning summary** | ✅ (o3, o4-mini, GPT-5) | ✅ | Innsikt i tankeprosessen |
|
||
| **Streaming** | ✅ (de fleste) | ✅ | Real-time respons |
|
||
|
||
### Reasoning Summary
|
||
|
||
Reasoning summary gir innsikt i modellens chain-of-thought prosess. Dette er spesielt nyttig for debugging og for å forstå hvordan modellen kom fram til et svar.
|
||
|
||
```python
|
||
response = client.responses.create(
|
||
model="o3",
|
||
input="Beregn arealet av en sirkel med radius lik antall 'r'-er i 'strawberry'",
|
||
reasoning={
|
||
"effort": "medium",
|
||
"summary": "auto" # auto, concise, eller detailed
|
||
}
|
||
)
|
||
```
|
||
|
||
**Tilgjengelige summary-nivåer:**
|
||
- `auto` — Modellen bestemmer detaljnivå
|
||
- `concise` — Kort oppsummering (ikke støttet av GPT-5)
|
||
- `detailed` — Utfyllende forklaring av reasoning
|
||
|
||
**Merk:** Reasoning summary genereres ikke for hvert request — dette er forventet oppførsel.
|
||
|
||
### Nye GPT-5 Features
|
||
|
||
GPT-5-serien introduserer flere nye parametere for mer finmasket kontroll:
|
||
|
||
| Parameter | Verdier | Beskrivelse |
|
||
|-----------|---------|-------------|
|
||
| `verbosity` | `low`, `medium`, `high` | Kontrollerer hvor konsist output er |
|
||
| `preamble` | Object | Innsikt i planning før function calls |
|
||
| `allowed_tools` | Array | Spesifiser flere tillatte tools under `tool_choice` |
|
||
| `lark_tool` | Grammar definition | Strukturert output med Python Lark grammar |
|
||
|
||
### Ikke-støttede parametere
|
||
|
||
Reasoning models støtter **ikke** følgende parametere som er vanlige i completion-modeller:
|
||
- `temperature`
|
||
- `top_p`
|
||
- `presence_penalty`
|
||
- `frequency_penalty`
|
||
- `logprobs`
|
||
- `top_logprobs`
|
||
- `logit_bias`
|
||
- `max_tokens` (bruk `max_completion_tokens` eller `max_output_tokens` i stedet)
|
||
|
||
## Arkitekturmønstre
|
||
|
||
### Mønster 1: Simple Zero-Shot Reasoning
|
||
|
||
**Bruk når:** Du har klare, velformulerte spørsmål uten behov for eksempler.
|
||
|
||
**Fordeler:**
|
||
- Enklest å implementere
|
||
- Ingen behov for few-shot eksempler
|
||
- Reasoning models er optimalisert for zero-shot
|
||
|
||
**Ulemper:**
|
||
- Mindre kontroll over output-format
|
||
- Kan gi lengre svar enn nødvendig
|
||
|
||
```python
|
||
response = client.chat.completions.create(
|
||
model="o3-mini",
|
||
messages=[
|
||
{"role": "user", "content": "Hva er de viktigste sikkerhetsprinsippene for OAuth2?"}
|
||
],
|
||
max_completion_tokens=2000,
|
||
reasoning_effort="low" # Tilstrekkelig for faktabaserte spørsmål
|
||
)
|
||
```
|
||
|
||
**Best practice:**
|
||
- Vær spesifikk i spørsmålsstillingen
|
||
- Unngå chain-of-thought prompting ("tenk steg-for-steg") — reasoning models gjør dette automatisk
|
||
- Bruk `reasoning_effort="low"` for enkle faktaspørsmål, `medium` for analyse
|
||
|
||
### Mønster 2: RAG med Reasoning Models
|
||
|
||
**Bruk når:** Du kombinerer retrieval med kompleks resonnering over dokumenter.
|
||
|
||
**Fordeler:**
|
||
- Bedre kvalitet på svar ved kompleks dokumentanalyse
|
||
- Reasoning models kan finne subtile sammenhenger
|
||
- Reduserer hallusinasjoner ved god retrieval
|
||
|
||
**Ulemper:**
|
||
- Lengre responstid
|
||
- Høyere kostnad pga. reasoning tokens
|
||
- Kan "over-tenke" enkle dokumentoppslag
|
||
|
||
```python
|
||
# Hent relevante dokumenter først
|
||
retrieved_docs = vector_search(query="Azure OpenAI pricing models")
|
||
|
||
# Bruk reasoning model til å analysere
|
||
response = client.chat.completions.create(
|
||
model="o1",
|
||
messages=[
|
||
{
|
||
"role": "developer",
|
||
"content": "Du skal analysere dokumenter og svare presist basert kun på innholdet."
|
||
},
|
||
{
|
||
"role": "user",
|
||
"content": f"Dokumenter:\n{retrieved_docs}\n\nSpørsmål: Hva er kostnadene for O3-modellen?"
|
||
}
|
||
],
|
||
max_completion_tokens=1500,
|
||
reasoning_effort="medium"
|
||
)
|
||
```
|
||
|
||
**Best practice:**
|
||
- Inkluder kun mest relevante dokumenter (ikke overload context)
|
||
- Bruk `developer` message for instruksjoner om hvordan dokumenter skal brukes
|
||
- Vurder `reasoning_effort="low"` hvis dokumentene er enkle å tolke
|
||
|
||
### Mønster 3: Complex Code Generation med Tool Calling
|
||
|
||
**Bruk når:** Du skal generere kompleks kode med behov for eksterne verktøy.
|
||
|
||
**Fordeler:**
|
||
- Modellen kan "planlegge" før den kaller functions
|
||
- GPT-5 modeller kan bruke `preamble` til å vise planning
|
||
- Structured outputs sikrer korrekt JSON-format
|
||
|
||
**Ulemper:**
|
||
- Krever GPT-5 eller nyere O-modeller for beste tool-støtte
|
||
- Reasoning overhead kan være unødvendig for simple function calls
|
||
|
||
```python
|
||
tools = [
|
||
{
|
||
"type": "function",
|
||
"function": {
|
||
"name": "execute_code",
|
||
"description": "Kjør Python-kode i sandbox",
|
||
"parameters": {
|
||
"type": "object",
|
||
"properties": {
|
||
"code": {"type": "string"}
|
||
},
|
||
"required": ["code"]
|
||
}
|
||
}
|
||
}
|
||
]
|
||
|
||
response = client.responses.create(
|
||
model="gpt-5-codex",
|
||
input="Skriv en funksjon som beregner Fibonacci-tall rekursivt og test den.",
|
||
tools=tools,
|
||
reasoning={
|
||
"effort": "medium"
|
||
}
|
||
)
|
||
|
||
# GPT-5 kan gi preamble med planning-innsikt
|
||
for item in response.output:
|
||
if item.type == "reasoning":
|
||
print(f"Planning: {item.summary}")
|
||
```
|
||
|
||
**Best practice:**
|
||
- Bruk `gpt-5-codex` eller `codex-mini` for kode-generering
|
||
- Aktiver reasoning summary for å se planleggingssteg
|
||
- Kombiner med structured outputs for strengere tool-validering
|
||
|
||
### Mønster 4: Background Processing for Lange Oppgaver
|
||
|
||
**Bruk når:** Du har tidkrevende reasoning-oppgaver som kan kjøres asynkront.
|
||
|
||
**Fordeler:**
|
||
- Unngår timeout for lange reasoning-prosesser
|
||
- Bedre ressursutnyttelse
|
||
- Spesielt nyttig for `o3-pro` og `gpt-5-pro`
|
||
|
||
**Ulemper:**
|
||
- Mer kompleks arkitektur (polling eller webhooks)
|
||
- Ikke real-time respons
|
||
|
||
```python
|
||
# Start background task
|
||
response = client.responses.create(
|
||
model="o3-pro",
|
||
input="Analyser alle sikkerhetsproblemer i denne 10 000 linjers kodebase.",
|
||
background=True,
|
||
tools=[{"type": "code_interpreter"}]
|
||
)
|
||
|
||
task_id = response.id
|
||
print(f"Status: {response.status}") # "queued"
|
||
|
||
# Poll status senere
|
||
status = client.responses.retrieve(task_id)
|
||
if status.status == "completed":
|
||
print(status.output_text)
|
||
```
|
||
|
||
**Best practice:**
|
||
- Kombiner med webhooks for notifikasjoner når task er ferdig
|
||
- Bruk for `o3-pro` som ikke støtter streaming
|
||
- Sett realistiske timeouts på polling-logikk
|
||
|
||
## Beslutningsveiledning
|
||
|
||
### Velg riktig modell
|
||
|
||
| Use Case | Anbefalt Modell | Reasoning Effort | Rationale |
|
||
|----------|----------------|------------------|-----------|
|
||
| Enkel kode-generering | `codex-mini`, `gpt-5-mini` | `low` | Rask og kostnadseffektiv |
|
||
| Komplekse algoritmer | `gpt-5-codex`, `o3` | `medium` til `high` | Presisjon viktigere enn hastighet |
|
||
| Matematikk og logikk | `o3`, `gpt-5` | `medium` til `high` | Chain-of-thought kritisk |
|
||
| Dokumentanalyse | `o1`, `o3-mini` | `low` til `medium` | Balanse mellom kvalitet og kostnad |
|
||
| Research-oppgaver | `o3-pro`, `gpt-5-pro` | `high` | Dypest mulig resonnering |
|
||
| Real-time chat | `gpt-5-mini`, `gpt-5.1-chat` | `minimal` til `low` | Hastighet prioriteres |
|
||
| Multi-modal (bilde+tekst) | `o3`, `o4-mini`, `gpt-5` | `medium` | Reasoning over bilder |
|
||
|
||
### Vanlige feil
|
||
|
||
| Problem | Symptom | Løsning |
|
||
|---------|---------|---------|
|
||
| **Over-engineering prompts** | Bruker chain-of-thought teknikker manuelt | Fjern "tenk steg-for-steg" — reasoning models gjør dette automatisk |
|
||
| **Feil reasoning effort** | Høy kostnad på enkle oppgaver | Bruk `low` eller `minimal` for faktabaserte spørsmål |
|
||
| **Timeout på store oppgaver** | Request feiler etter 2-5 minutter | Bruk `background=True` for o3-pro og store oppgaver |
|
||
| **Manglende markdown i kode** | Mister syntax highlighting | Legg til "Formatting re-enabled" i developer message (o3-mini, o1) |
|
||
| **Inkonsistent output-format** | Modellen returnerer feil JSON | Bruk structured outputs med JSON schema |
|
||
| **For mange reasoning tokens** | Høy kostnad, lang responstid | Senk reasoning effort eller bytt til non-reasoning modell |
|
||
|
||
### Røde flagg
|
||
|
||
⚠️ **Ikke bruk reasoning models hvis:**
|
||
- Du trenger svært raske svar (<500ms responstid)
|
||
- Oppgaven er triviell (enkel lookup, template-generering)
|
||
- Du har streng kostnadsbudsjett og oppgaven er volume-høy
|
||
- Du trenger `temperature` eller `top_p` kontroll (ikke støttet)
|
||
|
||
✅ **Bruk reasoning models når:**
|
||
- Oppgaven krever multi-step resonnering
|
||
- Nøyaktighet er kritisk (matematikk, kode, medisin, jus)
|
||
- Du analyserer komplekse dokumenter med subtile sammenhenger
|
||
- Du trenger planning før function calling
|
||
- Du ønsker innsikt i tankeprosessen (reasoning summary)
|
||
|
||
## Integrasjon med Microsoft-stakken
|
||
|
||
### Microsoft Foundry
|
||
|
||
Reasoning models er tilgjengelige i Microsoft Foundry (tidligere Azure AI Studio):
|
||
- Deploy via **Foundry Tools resource** for full kontroll
|
||
- Bruk **Playground** for testing med reasoning summary visualisering
|
||
- Kombiner med **Prompt Flow** for orchestration (merk: reasoning tokens telles i cost tracking)
|
||
|
||
### Power Platform AI Builder
|
||
|
||
Fra 21. mars 2025 er O1-modeller tilgjengelige i public preview i **Prompt Builder** (release-plan-siden er nå arkivert — se aktuell AI Builder-oversikt for status):
|
||
- Velg "o1 reasoning model" i model selector
|
||
- Ideell for store datasett-analyse, prognoser, og detaljert analyse
|
||
- Kombiner med Power Automate for automatisering av reasoning-oppgaver
|
||
|
||
### Copilot Studio
|
||
|
||
Reasoning models kan brukes som **custom LLM endpoints** i Copilot Studio:
|
||
- Konfigurer via **Generative AI** settings
|
||
- Bruk for komplekse decision trees i dialoger
|
||
- Kombiner med **Dataverse** for grounded reasoning over CRM-data
|
||
|
||
### Microsoft Agent Framework
|
||
|
||
Reasoning models integreres i Agent Framework:
|
||
- Bruk `AzureOpenAIResponsesClient` for O-modeller
|
||
- Støtte for agentic workflows med planning via `preamble`
|
||
- Kombiner med MCP (Model Context Protocol) servere for external tools
|
||
|
||
```python
|
||
from agent_framework.azure import AzureOpenAIResponsesClient
|
||
from azure.identity import AzureCliCredential
|
||
|
||
agent = AzureOpenAIResponsesClient(
|
||
deployment_name="o3",
|
||
credential=AzureCliCredential()
|
||
).as_agent(
|
||
instructions="Du er en ekspert på kompleks resonnering.",
|
||
name="ReasoningAgent"
|
||
)
|
||
|
||
result = await agent.run("Løs dette logikkproblemet: Hvis A > B, B > C...")
|
||
print(result.text)
|
||
```
|
||
|
||
### Azure AI Search (RAG)
|
||
|
||
Kombiner Azure AI Search med reasoning models for avansert RAG:
|
||
- Bruk **vector search** for retrieval
|
||
- Send resultater til reasoning model for dypere analyse
|
||
- Aktiver **semantic ranking** for bedre retrieval-kvalitet
|
||
- Vurder `reasoning_effort="low"` hvis retrieval allerede er høykvalitets
|
||
|
||
## Offentlig sektor (Norge)
|
||
|
||
### GDPR og datasuverenitet
|
||
|
||
Reasoning tokens klassifiseres som **personopplysninger** hvis input inneholder persondata:
|
||
- Reasoning tokens lagres midlertidig i Azure OpenAI-infrastruktur
|
||
- **Velg Norway East eller West Europe regions** for norsk datasuverenitet
|
||
- Aktiver **Customer Managed Keys (CMK)** for kryptering av reasoning data
|
||
- Logg reasoning summary kun hvis nødvendig for audit-trail
|
||
|
||
### Schrems II og internasjonale dataoverføringer
|
||
|
||
- **Global Standard deployments** kan rute til USA — unngå for offentlig sektor
|
||
- Bruk **Regional deployments** (Norway East prioritert)
|
||
- Vurder **Azure Private Link** for nettverk-isolasjon
|
||
- Dokumenter data processing agreement (DPA) med Microsoft
|
||
|
||
### AI Act (EU)
|
||
|
||
Reasoning models kan falle under **høyrisiko-AI** hvis brukt i kritiske beslutninger:
|
||
- **Dokumenter reasoning summary** for høyrisiko-vedtak (eiendomstakst, lånegodkjenning)
|
||
- Implementer **human-in-the-loop** for kritiske resonneringer
|
||
- Logg reasoning effort-nivå og modellversjon for audit
|
||
- Vurder **explainability krav** — reasoning summary kan oppfylle deler av dette
|
||
|
||
### Forvaltningsloven § 25 (begrunnelsesplikt)
|
||
|
||
Ved bruk i offentlige vedtak:
|
||
- Reasoning summary kan bidra til **begrunnelse** av AI-assisterte beslutninger
|
||
- Kombiner med human review før endelig vedtak
|
||
- Lagre full reasoning chain for klagesaker (vurder retention policies)
|
||
|
||
### Kostnadskontroll i offentlig sektor
|
||
|
||
Reasoning tokens kan øke kostnader betydelig:
|
||
- **Sett budsjetter** per use case i Azure Cost Management
|
||
- **Monitor reasoning tokens** separat fra completion tokens
|
||
- Vurder `reasoning_effort="low"` som default, med høyere effort kun ved behov
|
||
- Bruk `gpt-5-mini` eller `codex-mini` for volume-oppgaver
|
||
|
||
## Kostnad og lisensiering
|
||
|
||
### Prismodell (foreløpig basert på global pricing)
|
||
|
||
Reasoning models prises med **separate satser** for reasoning tokens og completion tokens.
|
||
|
||
**Eksempel (omtrentlige priser per 1M tokens):**
|
||
|
||
Reasoning-tokens faktureres til **output-raten** — de er ikke en egen prisklasse. Kolonnen «Reasoning Tokens» under viser derfor output-raten, og kostnaden skaleres med hvor mange reasoning-tokens modellen genererer.
|
||
|
||
| Modell | Input (per 1M) | Reasoning/Output (per 1M) | Bruksområde | Kilde |
|
||
|--------|----------------|---------------------------|-------------|-------|
|
||
| `gpt-5` | $1.25 | $10.00 | Premium reasoning | Verifisert juni 2026 |
|
||
| `gpt-5-mini` | $0.25 | $2.00 | Balansert | Verifisert juni 2026 |
|
||
| `gpt-5-nano` | $0.05 | $0.40 | Rask, billig reasoning | Verifisert juni 2026 |
|
||
| `o3-mini` | $1.10 | $4.40 | Kostnadseffektivt | Verifisert (register §1.1) |
|
||
| `o1` | $15.00 | $60.00 | Legacy, balansert | Legacy-rate |
|
||
| `o3` / `o4-mini` / `codex-mini` | verifiser | verifiser | Standard/rask reasoning | **Ikke re-verifisert — sjekk Azure prisside** |
|
||
|
||
**Merk:** Kanonisk prissannhet er `deterministic-cost-calculation-model.md` §1.1. Reasoning-tokens kan utgjøre 20–60 % av total token-count avhengig av effort-nivå — det er den reelle kostnadsdriveren for resonneringsmodeller, ikke base-raten.
|
||
|
||
### Optimaliseringstips
|
||
|
||
1. **Start med lavt effort-nivå** — øk kun ved behov
|
||
2. **Bruk mini-varianter** for volume-oppgaver
|
||
3. **Batch-prosesser** via background mode for store jobber
|
||
4. **Monitor token usage** — reasoning tokens kan overraske
|
||
5. **Cache retrieval-resultater** når du bruker RAG
|
||
6. **Vurder non-reasoning models** for enkle oppgaver (GPT-4o, GPT-4o-mini)
|
||
|
||
### Lisensiering
|
||
|
||
Reasoning models krever:
|
||
- **Azure OpenAI Service** subscription (ingen spesielle lisenser)
|
||
- Ingen «limited access request» lenger — tilgang til o3-pro, gpt-5-pro og gpt-5-codex er ikke lenger begrenset (verifisert mot Microsoft Learn 2026-06)
|
||
|
||
**Ingen spesielle lisenskrav:**
|
||
- `o1`, `o3-mini`, `o4-mini`, `codex-mini`
|
||
- `gpt-5-mini`, `gpt-5-nano`, `gpt-5.1-chat`, `gpt-5.1-codex-mini`
|
||
|
||
## For arkitekten (Cosmo)
|
||
|
||
### Spørsmål å stille kunden
|
||
|
||
1. **Hva er business-verdien av bedre reasoning?**
|
||
→ Hvis svaret kun handler om hastighet, vurder non-reasoning models.
|
||
|
||
2. **Hva er den kritiske nøyaktigheten som kreves?**
|
||
→ Høy nøyaktighet (>95%) kan rettferdiggjøre `high` eller `xhigh` effort.
|
||
|
||
3. **Hva er akseptabel responstid?**
|
||
→ Under 2 sekunder → bruk `minimal` eller non-reasoning.
|
||
→ Over 10 sekunder OK → kan bruke `medium` til `high`.
|
||
|
||
4. **Hvor ofte skal denne operasjonen kjøres?**
|
||
→ Høy frekvens (1000+ ganger/dag) → vurder kostnadseffektive modeller (`codex-mini`, `gpt-5-mini`).
|
||
|
||
5. **Trenger dere innsikt i tankeprosessen?**
|
||
→ Hvis ja (debugging, audit, læring) → aktiver reasoning summary.
|
||
→ Hvis nei → spar tokens ved å ikke bruke summary.
|
||
|
||
6. **Vil oppgaven kombineres med external tools?**
|
||
→ Hvis ja → vurder GPT-5 for `preamble` og bedre tool planning.
|
||
|
||
7. **Er dette en high-stakes beslutning (medisin, jus, sikkerhet)?**
|
||
→ Hvis ja → dokumenter reasoning, implementer human review, vurder ekstern audit.
|
||
|
||
8. **Har dere compliance-krav (GDPR, AI Act)?**
|
||
→ Hvis ja → regional deployment, reasoning summary logging, DPA med Microsoft.
|
||
|
||
### Fallgruver å unngå
|
||
|
||
⚠️ **Fallgruve 1: Bruke reasoning models for alt**
|
||
Mange kunder overvurderer behovet for reasoning. 80% av oppgaver kan løses med GPT-4o eller GPT-4o-mini til lavere kostnad og høyere hastighet.
|
||
|
||
⚠️ **Fallgruve 2: Sette reasoning effort for høyt**
|
||
`high` og `xhigh` effort kan gi 3-10x høyere reasoning tokens uten tilsvarende kvalitetsforbedring for enkle oppgaver.
|
||
|
||
⚠️ **Fallgruve 3: Glemme markdown-formateringsproblemer**
|
||
O3-mini og O1 returnerer ikke markdown som standard. Hvis kunden forventer kodeblokker med syntax highlighting, må "Formatting re-enabled" legges til.
|
||
|
||
⚠️ **Fallgruve 4: Ikke planlegge for timeouts**
|
||
O3-pro og store reasoning-oppgaver kan ta >5 minutter. Uten background mode vil HTTP-timeouts inntreffe.
|
||
|
||
⚠️ **Fallgruve 5: Manuell chain-of-thought prompting**
|
||
Kunder som migrerer fra GPT-4 prøver ofte å bruke "tenk steg-for-steg" teknikker. Dette er redundant og kan forvirre reasoning models.
|
||
|
||
### Anbefalinger per modenhetsnivå
|
||
|
||
#### Nivå 1: Proof-of-Concept (første gang med LLMs)
|
||
|
||
- **Start med:** `o3-mini` eller `gpt-5-mini`
|
||
- **Reasoning effort:** `low` som default
|
||
- **API:** Chat Completions API (enklere å komme i gang)
|
||
- **Prompt-strategi:** Enkle zero-shot prompts
|
||
- **Fokus:** Demonstrer verdi, ikke overoptimalisering
|
||
- **Metrikker:** Sammenlign kvalitet vs. GPT-4o for å dokumentere ROI
|
||
|
||
#### Nivå 2: Pilot / MVP (første produksjonssystem)
|
||
|
||
- **Utvid til:** `o1` eller `gpt-5` for kritiske use cases
|
||
- **Reasoning effort:** `low` for volume, `medium` for presisjon
|
||
- **API:** Introduser Responses API for bedre reasoning-støtte
|
||
- **Prompt-strategi:** Strukturerte prompts, begynn med RAG hvis nødvendig
|
||
- **Fokus:** Kostnadskontroll, error handling, monitoring av reasoning tokens
|
||
- **Metrikker:** Token usage per request type, responstid, feilrate
|
||
|
||
#### Nivå 3: Produksjon i skala (mature AI-løsning)
|
||
|
||
- **Model-strategi:** Kombiner flere modeller basert på use case
|
||
→ `codex-mini` for enkel koding
|
||
→ `o3` for kompleks analyse
|
||
→ `gpt-5-pro` for critical reasoning
|
||
- **Reasoning effort:** Dynamisk basert på kompleksitet (low/medium/high)
|
||
- **API:** Responses API med background mode for tunge oppgaver
|
||
- **Prompt-strategi:** Optimaliserte prompts, A/B-testing, few-shot når nødvendig
|
||
- **Fokus:** Kostnadsoptimalisering, latency-tuning, compliance, explainability
|
||
- **Metrikker:** Cost per outcome, reasoning token efficiency, human override rate
|
||
|
||
## Kilder og verifisering
|
||
|
||
Denne kunnskapsreferansen er basert på offisiell Microsoft Learn-dokumentasjon hentet via MCP (Model Context Protocol), sist re-verifisert 2026-06-19. Alle tekniske detaljer er verifisert mot siste API-versjon.
|
||
|
||
**Primary sources:**
|
||
|
||
1. **Azure OpenAI reasoning models**
|
||
https://learn.microsoft.com/en-us/azure/foundry/openai/how-to/reasoning
|
||
*Confidence: Verified (MCP fetch 2026-02)*
|
||
|
||
2. **Azure OpenAI model availability and pricing**
|
||
https://learn.microsoft.com/en-us/azure/foundry/foundry-models/concepts/models-sold-directly-by-azure
|
||
*Confidence: Verified (MCP fetch 2026-02)*
|
||
|
||
3. **Reasoning models with Foundry Models**
|
||
https://learn.microsoft.com/en-us/azure/foundry-classic/foundry-models/how-to/use-chat-reasoning
|
||
*Confidence: Verified (MCP search 2026-02)*
|
||
|
||
4. **Azure OpenAI function calling support**
|
||
https://learn.microsoft.com/en-us/azure/foundry/openai/how-to/function-calling
|
||
*Confidence: Verified (MCP search 2026-02)*
|
||
|
||
5. **GPT-5 prompting guide (OpenAI)**
|
||
https://cookbook.openai.com/examples/gpt-5/gpt-5_prompting_guide
|
||
*Confidence: Baseline (referenced in Microsoft docs, ikke direkte verifisert)*
|
||
|
||
6. **Power Platform O1 model support**
|
||
https://learn.microsoft.com/en-us/power-platform/release-plan/2024wave2/ai-builder/use-o1-reasoning-model-prompt-builder
|
||
*Confidence: Verified (MCP fetch 2026-06-19) — release-plan-siden er arkivert; public preview fra 21. mars 2025*
|
||
|
||
**Confidence levels per seksjon:**
|
||
|
||
- **Kjernekomponenter / Nøkkelegenskaper:** Verified (MCP)
|
||
- **Arkitekturmønstre:** Baseline (best practices fra modellkunnskap + MCP)
|
||
- **Beslutningsveiledning:** Baseline (arkitekturerfaring + Microsoft docs)
|
||
- **Integrasjon med Microsoft-stakken:** Verified (MCP + baseline)
|
||
- **Offentlig sektor (Norge):** Baseline (legal/compliance-kunnskap + Azure docs)
|
||
- **Kostnad og lisensiering:** Baseline (pricing estimert, lisensiering verifisert via MCP)
|
||
- **For arkitekten (Cosmo):** Baseline (erfaring + Cosmo-persona)
|
||
|
||
**Merk:** Priser er omtrentlige og basert på global Azure-prising. Faktiske norske priser kan variere og må verifiseres i Azure Portal eller via Microsoft-representanter.
|