4.3 KiB
Erfaring: Modell-benchmark (mars 2026)
Testoppsett
Oppgave: Kodegjennomgang av synops-transcribe (441 linjer Rust).
Prompt: "Hva gjør verktøyet? Er det bugs? Hva kan forbedres? Maks 300 ord."
Modeller: Haiku 4.5, Sonnet 4.6, Opus 4.6 Effort: Medium (default) for alle tre Kontekst: Alle modeller fikk CLAUDE.md (~200 linjer prosjektinstruksjoner)
Resultater
| Modell | Tid | Ord | Bugs funnet | Kvalitet |
|---|---|---|---|---|
| Haiku 4.5 | 16s | ~230 | 3 | God. Fant batch-insert, hardkodet timeout, resource logging. Én feil-positiv (metadata NULL). |
| Sonnet 4.6 | 28s | ~250 | 3 | Bedre. Fant transaksjonsgap (DELETE utenfor tx), i32 overflow, manglende retry. |
| Opus 4.6 | 24s | ~240 | 3 | Best. Fant transaksjonsgap + hele-filen-i-minne + content-overskriving. Mest presise vurdering. |
Analyse
Haiku
- Styrke: Rask. Finner overfladiske problemer pålitelig.
- Svakhet: Finner ikke transaksjonsgapet (den viktigste buggen). Foreslår forbedringer som er riktige men åpenbare.
- Egnet for: Triage, enkel kodesjekk, "er dette åpenbart feil?"
Sonnet
- Styrke: Finner transaksjonsgapet. God balanse mellom dybde og fart.
- Svakhet: Noe lengre enn nødvendig. Nevner ting som er "uproblematisk i CLI-bruk" (reqwest::Client) — korrekt men ikke actionable.
- Egnet for: Daglig bruk. Kodegjennomgang, chat-svar, oppsummering.
Opus
- Styrke: Finner alt Sonnet finner + hele-filen-i-minne-problemet (streaming vs buffer). Mest presist prioritert — viktigste bug først. Nevner content-overskriving som et designspørsmål, ikke bare en bug.
- Svakhet: Tar omtrent like lang tid som Sonnet for dette omfanget. Marginalgevinsten er reell men liten for enkel kode.
- Egnet for: Validering, arkitekturgjennomgang, kompleks analyse.
Effort-observasjoner
Full 3×3-matrise (model × effort) ble forsøkt men feilet pga ressurskonkurranse (6+ samtidige Claude-instanser på 16GB server).
Fra den initielle testen uten effort-prefix (medium):
- Haiku med "vær ekstremt grundig"-prefix fant ikke flere bugs enn uten — modellens kapasitet er begrensningen, ikke effort.
- Opus med "svar kort"-prefix ville sannsynligvis fortsatt funnet transaksjonsgapet — modellens innsikt er ikke avhengig av ordmengde.
Hypotese: Effort-nivå påvirker ordmengde og grundighet mer enn funnkvalitet. Modellvalg er den avgjørende faktoren for dybde. Effort styrer overflaten.
Anbefaling for Synops
| Oppgave | Modell | Effort | Begrunnelse |
|---|---|---|---|
| @bot chat-svar | Sonnet | medium | God nok for daglig bruk |
| Orkestrering (standardsteg) | Haiku | low | Mekanisk dispatch, trenger ikke dybde |
| Orkestrering (feilhåndtering) | Sonnet | medium | Resonnering om uventet situasjon |
| Kodegjennomgang (PR) | Sonnet | high | Grundig men ikke overkill |
| Validering (fase 23) | Opus | high | Må finne subtile bugs |
| Arkitekturanalyse | Opus | high | Designspørsmål krever dybde |
| Triage / klassifisering | Haiku | low | Rask, billig, god nok |
| Work item fra chat | Haiku | low | Bare fang opp og kategoriser |
Kostnadsimplikasjon
Haiku er ~20× billigere enn Opus per token. For et system med 100 daglige @bot-interaksjoner:
| Strategi | Estimert dagskostnad |
|---|---|
| Alt med Opus | ~$15-25/dag |
| Alt med Sonnet | ~$3-5/dag |
| Smart routing (anbefalt) | ~$1-2/dag |
Smart routing: Haiku for 70% (triage, enkel chat), Sonnet for 25% (normal chat, orkestrering), Opus for 5% (validering, arkitektur). Auto-eskalering med ↑-knappen for resten.
Merk
- Alle modeller fikk full CLAUDE.md som kontekst (~200 linjer). For Haiku er dette en relativt stor andel av vinduet.
- Testen ble kjørt med task runner (23.1) aktiv — noe ressurs- konkurranse kan ha påvirket timingen.
- Én test per modell er ikke statistisk signifikant. Resultatene er indikasjoner, ikke fasit.
- Parallelle tester (3 modeller + task runner + interaktiv sesjon) feilet — alle ga 0 output etter ~810s timeout. Claude-instanser konkurrerer om RAM (350MB × 6 = 2.1GB) og API-ratelimits. Lærdom: benchmark må kjøres sekvensielt på rolig server.
- Full 3×3×2-matrise er planlagt som nattkjøring via
scripts/benchmark-models.sh.