Så prioriterar jag feltyper innan jag optimerar en AI-agent

När en agent fungerar "80 procent bra" är det frestande att optimera snittkvaliteten. Jag försöker i stället börja med en fel-taxonomi. Alla fel är inte lika dyra, och ett enda medelvärde döljer ofta det viktigaste problemet.

Jag börjar med konsekvens, inte frekvens

Anta att en CV-agent gör två typer av fel:

• den väljer ibland ett svagare verb,
• den hittar sällan på en erfarenhet som inte finns.

Det första kan vara tio gånger vanligare och ändå ha lägre prioritet. Sanningsbrottet är en helt annan felklass.

Samma logik gäller content. En lite svag ingress är inte samma sak som ett felaktigt myndighetskrav. Ett missat internlänksförslag är inte samma sak som en publicerad claim utan evidens.

Min felmatris har fyra axlar

Jag klassar varje återkommande fel efter:

Severity. Vad händer om felet når användaren?

Detectability. Hur lätt är det att fånga automatiskt eller manuellt?

Frequency. Hur ofta inträffar det i representativa fall?

Recoverability. Hur dyrt är det att rätta efteråt?

Det ger bättre prioritering än "accuracy 92 %". Två system med samma accuracy kan ha helt olika riskprofiler.

Precision och recall är inte symmetriska

För en klassificerare i pipelinen — till exempel en säkerhets- eller riskgate — räcker det inte att titta på severity och frequency isolerat. Jag frågar också vilken feltyp, falskt positivt eller falskt negativt, som faktiskt är dyrast att missa. Om systemet blockerar en legitim handling för ofta skadar det flödet; om det släpper igenom en farlig handling kan kostnaden vara mycket större, och det avgör vilken riktning jag optimerar åt.

I en screening-gate där målet är att fånga nästan alla riskfall accepterar jag ofta fler falsklarm och låter en senare reviewer sortera dem. Vid en klassificering som direkt triggar en irreversibel handling vill jag i stället ha färre falska positiva, gärna kompletterat med mänskligt godkännande. Jag utvärderar den balansen end-to-end, eftersom en reviewer, regelmotor eller fallback kan ändra den praktiska precision/recall-balansen längre fram i kedjan — inte bara genom att titta på ett isolerat modellscore.

Golden dataset ska innehålla fel, inte bara normala exempel

När ett viktigt fel hittas sparar jag det som regressionstest. Då blir kvalitetsarbetet kumulativt: en prompt- eller modelländring får inte lösa ett problem genom att återintroducera tre gamla.

Det här är också varför jag inte låter en reviewer bara ge ett betyg 1–10. Reviewern ska identifiera vilken felklass som inträffade och vilken gate som äger den.

Optimera den dyraste felklassen först

Min arbetsordning blir därför ofta:

Den exakta ordningen beror på produkten. Men principen är stabil: fixa inte kommatering medan agenten fortfarande kan utföra fel handling.

Google SRE använder error budgets för samma bredare idé i traditionella system: reliability måste påverka prioriteringen av fortsatt featurearbete. För AI-agenten använder jag inte exakt samma matematik, men jag gillar kontrollprincipen — när en allvarlig felklass överskrider toleransen ska optimering för nya features få stå tillbaka.

En förbättring ska kunna mätas på rätt feltyp

Efter en ändring vill jag inte bara köra "overall score" igen. Om problemet var fabricerade CV-meriter behöver evalen explicit mäta just unsupported additions. Om problemet var tool misuse behöver vi testfall där agenten lockas att använda ett bredare verktyg än uppgiften kräver.

Det gör optimeringen mindre glamorös men mycket mer riktad.

• Precision and recall (Wikipedia)

Relaterade artiklar

• Så bygger jag en model router istället för att välja modell manuellt
• Så sätter jag guardrails runt AI utan att döda användarupplevelsen
• Så bygger jag golden datasets för mina egna AI-evals
• Så designar jag AI-produkter för användare som inte bryr sig om AI
• Hur jag undviker att en AI-agent bygger något elegant men fel