AI-system i produktion: vilka metrics jag faktiskt följer
När ett AI-system går från demo till produktion räcker det inte att fråga om modellen "är bra". Jag vill veta om hela jobbet lyckas, var det misslyckas och vad det kostar att få ett godkänt resultat.
När ett AI-system går från demo till produktion räcker det inte att fråga om modellen "är bra". Jag vill veta om hela jobbet lyckas, var det misslyckas och vad det kostar att få ett godkänt resultat.
Det här är särskilt viktigt för agentiska eller flerstegsbaserade system. En run kan ha ett perfekt slutligt språk men ändå vara dålig eftersom den använde fel källa, gjorde onödiga tool calls eller krävde tre manuella räddningar. En annan run kan vara kort och tekniskt ful men lösa uppgiften korrekt direkt. Jag försöker därför mäta systemet i lager.
1. Task success är huvudmåttet
Det första måttet är inte tokenkostnad eller modellscore. Det är om användarens jobb blev klart enligt ett tydligt kontrakt.
För en contentpipeline kan task success betyda att artikeln har tillräcklig evidens, klarar faktakontroll, klarar editorial QA, har rätt internlänkar och passerar Publisher Gate utan manuella undantag. För en CV-produkt kan det vara att förbättringen är relevant, sanningsenlig och accepterad av användaren.
Task success behöver alltså definieras per produkt. Ett universellt "LLM quality score" räcker inte.
2. Jag mäter failure taxonomy, inte bara fail-rate
Två system med tio procent fel kan ha helt olika risk. Jag delar gärna upp fel i kategorier:
Då kan jag se om problemet verkligen kräver en bättre modell. Ofta gör det inte det. Retrievalfel kan kräva bättre data. Formatfel kan lösas med schema validation. Toolfel kan vara en integration. Unsupported claims kan kräva bättre evidence gates.
3. Cost per successful task är mer användbart än cost per token
Tokenkostnad är ett inputmått. Jag vill främst förstå outputekonomin. En enkel beräkning är:
Det gör routingbeslut mycket mer rationella. En billig modell är inte billig om den dubblar reviewbehovet. En dyrare modell är inte dyr om den minskar retries och manuellt arbete så mycket att kostnaden per godkänt resultat sjunker.
4. Human intervention rate visar var autonomin är falsk
Om ett "autonomt" workflow behöver räddas manuellt i 40 procent av fallen är det viktigt att se. Jag följer därför hur ofta en människa behöver korrigera output, lägga till saknad kontext, godkänna en exception, starta om en run, byta source eller skriva om modellen manuellt.
Intervention är inte alltid dåligt. Vid högriskbeslut kan det vara avsiktligt. Men då ska det vara designad human-in-the-loop, inte dold supportkostnad.
5. Jag vill se abstention rate separat
Ett system som aldrig säger "jag vet inte" kan se effektivt ut tills man granskar felen. I flera av mina workflows är BLOCKED, UNRESOLVED eller "kan inte bedöma" legitima outputs. Jag följer därför hur ofta systemet avstår och om abstentionen var korrekt.
För låg abstention kan betyda överkonfidens. För hög kan betyda att systemet får för lite data eller har för strikta gates.
6. Evals måste ligga nära verkliga trajectories
Ett agentiskt system är inte ett enda svar. Det söker, väljer verktyg, modifierar state och fattar mellanbeslut. Därför vill jag inte bara score:a finaltexten.
Anthropic beskriver i sin aktuella eval-guidance just detta problem: agenters flexibilitet gör dem svårare att evaluera, och bra evals behöver matcha systemets faktiska komplexitet och användning. De lyfter bland annat graderade trajectories, datasets och kombinationer av automatiska och mänskliga bedömningar. Anthropic: Demystifying evals for AI agents
OpenAI:s builder-guide "Building with GPT-5" (från 2026) betonar på samma sätt agent evals, trace grading, datasets och promptoptimering när system går från prototyp till drift — kontrollera att länken och titeln fortfarande stämmer vid publicering. OpenAI: Building with GPT-5
7. Jag följer latency som en fördelning
Genomsnittslatency kan dölja det som användaren upplever. Jag vill hellre se p50, p95 och timeout rate. Ett workflow som oftast tar fem sekunder men ibland två minuter skapar en annan produktupplevelse än ett som stabilt tar tio sekunder.
För multi-agentflöden tittar jag även på vilket steg som står för väntan. Då kan jag parallellisera rätt del i stället för att bara byta modell.
8. Tool-call-effektivitet avslöjar dålig orkestrering
Fler tool calls är inte automatiskt bättre agentarbete. Jag följer gärna tool calls per lyckad task, andel misslyckade calls, redundanta reads/searches, retries per tool och felaktigt valda tools.
En agent som hämtar samma dokument fem gånger är inte "noggrann". Den har sannolikt ett state- eller planeringsproblem.
9. Retrieval quality behöver egen mätning
När systemet bygger på externa källor vill jag kunna skilja retrieval från reasoning. Relevant evidence recall, source freshness och source authority är exempel på separata dimensioner. Om rätt källa aldrig kom in i kontexten är det missvisande att skylla allt på modellen.
I fact-heavy content är det dessutom viktigt att mäta claim coverage: hur stor andel av materiella claims har faktiskt stöd, inte bara om några källor finns i slutet.
10. Regression rate efter ändringar är ett av mina viktigaste driftmått
Modellbyte, promptändring, ny tool description eller ny retrievalstrategi kan förbättra ett case och försämra tre andra. Jag vill därför köra samma golden/eval-set före och efter materiella förändringar. Det viktiga är inte bara om medelscoren steg utan vilka tidigare fungerande cases som bröts.
Det här är varför evals blir mer värdefulla över tid. De är inte en lanseringschecklista. De är produktens minne över kända felmoder.
En minimal dashboard jag faktiskt skulle använda
Om jag måste börja enkelt vill jag ha:
| Metric | Varför |
|---|---|
| Task success rate | Löser systemet jobbet? |
| Cost per successful task | Är ekonomin hållbar? |
| p50 / p95 latency | Hur känns upplevelsen? |
| Human intervention rate | Hur autonomt är systemet i praktiken? |
| Abstention rate | Är osäkerheten kalibrerad? |
| Failures by category | Vad ska vi faktiskt förbättra? |
| Tool errors / run | Fungerar integrationerna? |
| Eval regression count | Har senaste ändringen brutit något? |
Sedan lägger jag till domänspecifika metrics. För content kan det vara unsupported claim rate. För routing kan det vara eskaleringsgrad. För en utbildningsprodukt kan det vara progression och felmönster över tid.
Metrics ska styra ett beslut
Jag försöker undvika dashboards där allt går upp och till höger men ingen vet vad man ska göra. Varje metric bör ha en koppling till ett beslut. Hög human intervention rate kanske leder till bättre verktyg eller smalare autonomi. Hög cost per successful task kanske leder till routing eller kortare kontext. Hög unsupported claim rate leder till bättre evidence layer, inte "mer kreativ modell".
Det är då observability blir produktutveckling i stället för bara driftövervakning.
Min viktigaste förändring har varit att sluta mäta modellen som en separat magisk komponent. Jag mäter systemets förmåga att slutföra ett jobb, med modellen som en av flera delar. Det är den nivån som faktiskt går att förbättra över tid.