Add /ultraresearch-local for structured research combining local codebase analysis with external knowledge via parallel agent swarms. Produces research briefs with triangulation, confidence ratings, and source quality assessment. New command: /ultraresearch-local with modes --quick, --local, --external, --fg. New agents: research-orchestrator (opus), docs-researcher, community-researcher, security-researcher, contrarian-researcher, gemini-bridge (all sonnet). New template: research-brief-template.md. Integration: --research flag in /ultraplan-local accepts pre-built research briefs (up to 3), enriches the interview and exploration phases. Planning orchestrator cross-references brief findings during synthesis. Design principle: Context Engineering — right information to right agent at right time. Research briefs are structured artifacts in the pipeline: ultraresearch → brief → ultraplan --research → plan → ultraexecute. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
551 lines
22 KiB
Markdown
551 lines
22 KiB
Markdown
# Reasoning Models (O1/O3) Optimization and Usage
|
|
|
|
**Last updated:** 2026-02
|
|
**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
|
|
|
|
### Azure AI Foundry
|
|
|
|
Reasoning models er tilgjengelige i Azure AI 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 mars 2025 er O1-modeller tilgjengelige i **Prompt Builder**:
|
|
- 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):**
|
|
|
|
| Modell | Input Tokens | Reasoning Tokens | Output Tokens | Bruksområde |
|
|
|--------|--------------|------------------|---------------|-------------|
|
|
| `o1` | $15 | $60 | $60 | Balansert reasoning |
|
|
| `o3` | $10-20 | $60-80 | $60-80 | Standard reasoning |
|
|
| `o3-mini` | $1-3 | $15-25 | $15-25 | Kostnadseffektivt |
|
|
| `o4-mini` | $1-3 | $15-25 | $15-25 | Rask og billig |
|
|
| `gpt-5` | $20-30 | $80-100 | $80-100 | Premium reasoning |
|
|
| `gpt-5-mini` | $3-5 | $20-30 | $20-30 | Balansert premium |
|
|
| `codex-mini` | $1-3 | $15-25 | $15-25 | Kode-spesialist |
|
|
|
|
**Merk:** Faktiske priser varierer basert på region, commitment og enterprise agreements. Reasoning tokens kan utgjøre 20-60% av total token count avhengig av effort-nivå.
|
|
|
|
### 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)
|
|
- **Limited access request** for enkelte modeller (o3-pro, gpt-5-pro, gpt-5-codex)
|
|
- Request via: https://aka.ms/oai/o3access eller https://aka.ms/oai/gpt5access
|
|
|
|
**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) i februar 2026. Alle tekniske detaljer er verifisert mot siste API-versjon.
|
|
|
|
**Primary sources:**
|
|
|
|
1. **Azure OpenAI reasoning models**
|
|
https://learn.microsoft.com/en-us/azure/ai-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/ai-foundry/openai/concepts/models
|
|
*Confidence: Verified (MCP fetch 2026-02)*
|
|
|
|
3. **Reasoning models with Microsoft Foundry Models**
|
|
https://learn.microsoft.com/en-us/azure/ai-foundry/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/ai-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 search 2026-02)*
|
|
|
|
**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.
|