Ordre 20260912T193441Z-7358817909. Steg 1 var ikke transformen, men å rette
roadmapens R13-gate og få den ratifisert. Gaten `grep -rl "Cosmo"
skills/*/references -> 0` var usann på to uavhengige måter:
1. Ordren fanget den første: 451 av forekomstene er Azure Cosmos DB, ekte
produktinnhold. Diskriminatoren er ikke bokstaven «s» — `Cosmos <norsk
substantiv>` er genitiv av personaen (`### Cosmos tonalitet`), mens
`Cosmos DB`/`CosmosClient`/`cosmos_ru` er produkt.
2. Denne økten fant den andre: 132 persona-forekomster ligger i prosa,
tabeller, dialog-replikker og proveniens-linjer. Heading-nøytralisering
kan ikke nå dem, så «0 persona» er uoppnåelig også under den ratifiserte
formen. Operatøren ratifiserte alternativ A: gaten speiler formen, og de
132 bokføres til R13b/R14.
Tre korreksjoner av premisser som sto i ordren og STATE:
«ca 320 produkt» -> 451 (case-sensitivt nett manglet 327 lowercase
TOC-ankre + 99 identifikatorer; sann nevner 1 638)
«169 headinger» -> 401. 169 var `^## For Cosmo`-prefikset (168) og var
internt inkonsistent med sin egen topp-variant (204)
«417 matcher ingen
populasjon» -> 417 er cosmo-headinger utenfor kodefences; briefens
nevner var reell hele tiden
Fence-bevissthet er målt skadelig, ikke nødvendig: begge toggle-regler er
gale på dette korpuset (naiv toggle skjuler en ekte heading i
chain-of-thought-prompting.md, CommonMark-regelen ubalanserer
service-level-documentation-dr.md). Fence-agnostisk deteksjon finner 401
heading-linjer i nøyaktig de samme 40 variantene som fence-bevisst finner
400 i — ingen kodeblokk-linje er byte-identisk til en persona-heading. Derfor
nøkles transformen på 40 enumererte heading-tekster og ignorerer fences. En
ukjent variant kaster; en slug-kollisjon kaster. Ingenting auto-fikses.
TOC-en regenereres ikke, den rettes kirurgisk: alle 327 persona-lenker hadde
lenketekst lik én av de 40 heading-tekstene og anker lik slugify av den
(327/327, 0 avvik), så heading og TOC-entry skrives i samme operasjon og
ingen mellomtilstand etterlater en død lenke.
Ratifisert målform: `For Cosmo`, `For Cosmo Skyberg` og `For arkitekten
(Cosmo)` konvergerer på `For arkitekten`. To filer kolliderte og er adjudisert
ved å lese dem, ikke ved regel.
Verifisering (alle 7 kriterier fra ordren):
G1 persona på heading-linjer 401 -> 0
G2 døde fragmentlenker 1 -> 1 (pre-eksisterende, unntatt)
G3 produkt-forekomster 451 -> 451; `Cosmos DB|Azure Cosmos` 308 = 308
de 3 kun-produkt-filene byte-identiske
nettet validert begge veier injisert persona feller G1; genitiv feller G1;
produkt-heading og de 3 filene passerer
hele diffen 802 heading-linjer + 654 TOC-linjer, ANNET = 0
linjeantall 728 lagt til = 728 slettet
suite 1120/1120 (1097 + 23 nye)
validate-plugin 250 PASS / 0 FAIL
stikkprøve 10 filer, alle 5 skills, inkl. de 3 mest
produkt-tunge (26/20/19) — kun heading+TOC
Utenfor scope, urørt: de 4 SKILL.md, de 23 commands, CLAUDE.md, README.md,
NOTICE.md, docs/ (alt R14).
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
14 KiB
GPT-4o Vision Architecture and Capabilities
Last updated: 2026-02 Status: GA Category: Multi-Modal AI Type: reference
Innhold
- Introduksjon
- GPT-4o Vision Capabilities
- Token-berekningsmodell for bilete
- Native vs. External Vision Integration
- Performance og Latency-optimalisering
- Brukstilfelle for norsk offentleg sektor
- Avgrensingar og kjende utfordringar
- For arkitekten
Introduksjon
GPT-4o (Omni) representerer en fundamental endring i korleis multimodale AI-modellar fungerer. I motsetnad til tidlegare tilnærmingar der tekst- og bildeforståing var separate modellar kopla saman, integrerer GPT-4o tekst og bilete i ein enkelt modell. Dette gir lågare latency, betre kontekstuell forståing og meir nøyaktige svar som kombinerer visuell og tekstuell informasjon.
For norsk offentleg sektor opnar GPT-4o vision nye moglegheiter innanfor dokumentanalyse, tilgjengelegheitsvurdering, kartanalyse, byggesaksbehandling og kvalitetssikring av offentlege tenester. Modellen er tilgjengeleg via Azure OpenAI Service, noko som sikrar at data blir behandla innanfor Microsofts enterprise-grade tryggleiksrammeverk med full GDPR-etterleving.
Microsoft Foundry gir ein samla plattform for å deploye, administrere og overvake GPT-4o vision-deployments med innebygd innhaldsfiltrering, kostnadshandtering og tilgangskontroll via Microsoft Entra ID.
GPT-4o Vision Capabilities
Modelloversikt
| Eigenskap | GPT-4o | GPT-4o mini | GPT-4 Turbo with Vision |
|---|---|---|---|
| Max kontekstvindu | 128 000 tokens | 128 000 tokens | 128 000 tokens |
| Max output tokens | 16 384 | 16 384 | 4 096 |
| Bildeinndata | Ja | Ja | Ja |
| JSON Mode | Ja | Ja | Ja |
| Parallel function calling | Ja | Ja | Ja |
| Structured outputs | Ja (2024-08-06+) | Ja | Nei |
| Fleirspråkleg ytelse | Overlegen | God | Standard |
| Vision fine-tuning | Ja (2024-08-06) | Nei | Nei |
Støtta bildeformat
GPT-4o aksepterer bilete i følgjande format:
- JPEG — Mest kompakt, eigna for foto
- PNG — Støttar transparens, eigna for diagram og skjermbilete
- WEBP — Moderne format med god komprimering
- GIF — Statiske bilete (ikkje animerte)
Bilete kan leverast på to måtar:
- URL-referanse — Offentleg tilgjengeleg URL til bildet
- Base64-koda data — Inline bildedata i API-kallet
{
"messages": [
{
"role": "user",
"content": [
{
"type": "text",
"text": "Beskriv innhaldet i dette dokumentet."
},
{
"type": "image_url",
"image_url": {
"url": "data:image/jpeg;base64,<base64_encoded_data>",
"detail": "high"
}
}
]
}
]
}
Ansiktsblurring og personvern
Azure OpenAI utfører automatisk ansiktsblurring på alle bildeinndata til GPT-4o. Dette beskyttar personvernet til individ i bileta og er spesielt relevant for norsk offentleg sektor som må etterleve personopplysningslova. Blurringa skal ikkje påverke kvaliteten på analysen i dei fleste tilfelle, men modellen kan i nokre tilfelle referere til blurringa.
Viktig: Modellen utfører ikkje ansiktsgjenkjenning eller individuell identifisering. Kontekstuelle signal (som klede, logo, stadier) kan framleis gjere at modellen identifiserer kjende personar.
Token-berekningsmodell for bilete
Lav oppløysingsmodus (detail: low)
Lav oppløysningsmodus prosesserer biletet som ein 512x512 versjon uavhengig av originalstorleik.
| Modell | Token per bilete | Kommentar |
|---|---|---|
| GPT-4o | 85 tokens | Flat rate, uavhengig av storleik |
| GPT-4o mini | 2 833 tokens | Flat rate, uavhengig av storleik |
Brukstilfelle: Rask klassifisering, generell bildeforståing der detaljar ikkje er kritiske.
Høg oppløysingsmodus (detail: high)
Høg oppløysningsmodus gir detaljert analyse gjennom ein fleirstegs prosess:
Steg 1: Resizing
- Biletet blir skalert til å passe innanfor eit 2048 x 2048 pikslar kvadrat
- Om kortaste side er større enn 768 pikslar, skalerast bildet slik at kortaste side er 768 pikslar
- Aspektforholdet bevares
Steg 2: Tile-beregning
- Det skalerte bildet delast i 512 x 512 piksel-fliser
- Delvis utfylte fliser rundast opp til heile fliser
Steg 3: Token-beregning
| Modell | Token per tile | Base tokens | Formel |
|---|---|---|---|
| GPT-4o | 170 | 85 | (tiles x 170) + 85 |
| GPT-4o mini | 5 667 | 2 833 | (tiles x 5667) + 2833 |
Eksempel: Token-beregning for ulike biletestorleikar
| Originalstorleik | Resized til | Tiles | GPT-4o tokens | GPT-4o mini tokens |
|---|---|---|---|---|
| 512 x 512 | 512 x 512 | 1 | 255 | 8 500 |
| 1024 x 1024 | 768 x 768 | 4 | 765 | 25 501 |
| 2048 x 4096 | 768 x 1536 | 6 | 1 105 | 36 835 |
| 4096 x 8192 (low) | 512 x 512 | - | 85 | 2 833 |
Detail-parameter
{
"type": "image_url",
"image_url": {
"url": "<image_url>",
"detail": "high" // "low", "high", eller "auto"
}
}
| Verdi | Oppførsel |
|---|---|
auto |
Standard. Modellen vel mellom low og high basert på biletestorleik |
low |
Brukar alltid 512x512, raskare respons, færre tokens |
high |
Full analyse med tile-basert prosessering |
Native vs. External Vision Integration
Native integrasjon (Chat Completions API)
Native bildeanalyse brukar GPT-4o direkte via Chat Completions API. Bileta sendast som ein del av meldingsstrukturen.
Fordelar:
- Lågast latency — eitt API-kall
- Full kontekstuell forståing mellom tekst og bilete
- Structured outputs for standardisert respons
- Enkel implementering
Avgrensingar:
- Maks 64 bilete per request (ved vision fine-tuning)
- Kvar bilete maks 10 MB
- Ingen spesialisert dokumentforståing (layout, tabellar)
from openai import AzureOpenAI
client = AzureOpenAI(
api_version="2024-08-06",
azure_endpoint=os.environ["AZURE_OPENAI_ENDPOINT"],
azure_ad_token_provider=token_provider
)
response = client.chat.completions.create(
model="gpt-4o",
messages=[
{
"role": "system",
"content": "Du er ein dokumentanalytiker for norsk offentleg sektor."
},
{
"role": "user",
"content": [
{"type": "text", "text": "Analyser dette skjemaet og ekstraher nøkkelfelter."},
{
"type": "image_url",
"image_url": {
"url": f"data:image/png;base64,{encoded_image}",
"detail": "high"
}
}
]
}
],
max_tokens=4096
)
External vision med Azure AI Services
For avanserte dokumentscenario, kombiner GPT-4o med spesialiserte Azure AI-tenester:
| Teneste | Brukstilfelle | Integrasjon med GPT-4o |
|---|---|---|
| Azure Document Intelligence | Strukturert dokumentekstraksjon, tabellar, skjema | Ekstraher strukturdata, send til GPT-4o for resonnering |
| Azure AI Vision | Objektdeteksjon, OCR, bildeanalyse | Detaljert bildeanalyse som input til GPT-4o |
| Azure Video Indexer | Videoanalyse, ansiktsdeteksjon | Ekstraher keyframes, analyser med GPT-4o |
| Azure Content Understanding | Semantisk chunking, cross-page tabellar | Avansert dokumentforståing |
Arkitekturmønster: Enrichment pipeline
Dokument → Document Intelligence → Strukturerte felt
→ Tabellar (JSON)
→ Bilete (ekstraherte)
↓
GPT-4o Vision Analysis
↓
Kombinert innsikt (tekst + visuell)
Vision Fine-Tuning
GPT-4o (versjon 2024-08-06) støttar fine-tuning med bildedata:
Krav:
- Maks 50 000 eksempel med bilete per treningsfil
- Maks 64 bilete per eksempel
- Kvar bilete maks 10 MB
- Format: JPEG, PNG, WEBP (RGB eller RGBA)
- Minimum 10 eksempel
Avgrensingar:
- Bilete med personar/ansikt blir ekskludert frå treningsdata
- CAPTCHAs blir ekskludert
- Bilete kan ikkje vere output frå assistant-meldingar
Performance og Latency-optimalisering
Strategiar for lågare latency
| Strategi | Effekt | Trade-off |
|---|---|---|
Bruk detail: low |
50-70% raskare | Lågare bildekvalitet |
| Reduser bildeoppløysing før sending | 20-40% raskare | Manuell preprosessering |
| Batch-prosessering | Betre throughput | Høgare per-request latency |
| Streaming responses | Opplevd raskare | Inga endring i total tid |
| Bruk GPT-4o mini | Raskare, billegare | Noko lågare kvalitet |
Bildeoptimalisering for Azure OpenAI
from PIL import Image
import io
import base64
def optimize_image_for_vision(image_path, max_size=2048, quality=85):
"""Optimaliser bilete for GPT-4o vision API."""
img = Image.open(image_path)
# Resize om nødvendig
if max(img.size) > max_size:
ratio = max_size / max(img.size)
new_size = (int(img.size[0] * ratio), int(img.size[1] * ratio))
img = img.resize(new_size, Image.LANCZOS)
# Konverter til RGB om nødvendig
if img.mode in ('RGBA', 'P'):
img = img.convert('RGB')
# Komprimer til JPEG
buffer = io.BytesIO()
img.save(buffer, format='JPEG', quality=quality)
buffer.seek(0)
return base64.b64encode(buffer.read()).decode('utf-8')
Rate Limits og kvotering
| Deployment type | TPM (Tokens Per Minute) | RPM (Requests Per Minute) |
|---|---|---|
| Standard | Varierer per region | Avheng av TPM |
| Global Standard | Høgare kvoter | Avheng av TPM |
| Provisioned (PTU) | Garantert throughput | Avheng av PTU-tal |
Viktig: Bilete telles mot TPM-kvoten. Eit stort bilete i
highdetail-modus kan bruke over 1000 tokens, noko som reduserer effektiv RPM.
Caching-strategi for biletanalyse
For gjentakande analysar av same bilete, implementer caching:
import hashlib
import json
from functools import lru_cache
def get_image_hash(image_data: bytes) -> str:
"""Generer hash for biletecaching."""
return hashlib.sha256(image_data).hexdigest()
# Redis-basert caching for produksjon
async def analyze_image_cached(image_data: bytes, prompt: str, cache_client):
cache_key = f"vision:{get_image_hash(image_data)}:{hashlib.md5(prompt.encode()).hexdigest()}"
cached = await cache_client.get(cache_key)
if cached:
return json.loads(cached)
result = await call_gpt4o_vision(image_data, prompt)
await cache_client.set(cache_key, json.dumps(result), ex=3600)
return result
Brukstilfelle for norsk offentleg sektor
Dokumentanalyse og saksbehandling
| Scenario | Detail-modus | Tilnærming |
|---|---|---|
| Byggesøknad med teikningar | high |
Ekstraher mål, material, plassering |
| Passfoto-validering | low |
Grunnleggjande kvalitetssjekk (ansiktsblurring aktiv) |
| Vegskilt-inventering | high |
Klassifisering og tilstandsvurdering |
| Kartanalyse | high |
Identifiser markerte område, målestokk |
| Fakturabehandling | high |
Kombiner med Document Intelligence |
Tilgjengelegheitsvurdering
GPT-4o kan analysere bilete av offentlege bygg og infrastruktur for tilgjengelegheitsutfordringar:
accessibility_prompt = """
Analyser dette biletet av ein offentleg bygning.
Vurder følgjande tilgjengelegheitskriterier:
1. Rullestolrampe tilgjengeleg?
2. Taktile leielinjer synlege?
3. Kontrastmerking på trapper?
4. Automatiske dører?
Gje ein strukturert vurdering i JSON-format.
"""
Avgrensingar og kjende utfordringar
| Avgrensing | Detaljar | Workaround |
|---|---|---|
| Ingen bildegenereringsevne | GPT-4o analyserer bilete, genererer ikkje | Bruk DALL-E 3 / GPT-image-1 |
| Metadata ikkje tilgjengeleg | EXIF, geo-data, kamerainfo blir ikkje lest | Ekstraher metadata separat |
| Spatial resonnering | Avgrensa evne til nøyaktig avstandsvurdering | Bruk spesialiserte vision-modellar |
| Handskrift | Variabel kvalitet, spesielt for norsk | Kombiner med Document Intelligence |
| Tidsavgrensing | Komplekse bilete kan ta opptil 60 sekund | Optimaliser biletestorleik |
For arkitekten
- GPT-4o vision brukar ein to-nivå token-modell:
low(flat 85 tokens) vs.high(tile-basert, 170 tokens per 512x512 tile + 85 base). Alltid berekn token-kostnad før du designar ein pipeline med mange bilete. - Ansiktsblurring er automatisk i Azure OpenAI og kan ikkje deaktiverast for GPT-4o. Dette er ein fordel for norsk personvern, men avgrensar brukstilfelle som ansiktsbasert identifisering.
- Kombiner native vision med Azure Document Intelligence for strukturert dokumentanalyse. GPT-4o gir generell forståing; Document Intelligence gir presis feltekstraksjon.
- Vision fine-tuning er tilgjengeleg for GPT-4o (2024-08-06) og kan forbetrast for spesifikke domene som norske byggesøknadar eller vegskilt. Merk at bilete med personar blir filtrert ut.
- For kostnadsoptimalisering, bruk
detail: autosom standard oglowfor screeing/klassifisering. Reservarhighfor tilfelle der detaljar er kritiske.