Förbättring eller brus? Ett releasebeslut steg för steg
Teamet har en ny version av en supportbot. På samma 50 testfall klarar version 1 42 fall (84 %) och version 2 44 fall (88 %). Fyra procentenheter bättre. Får den släppas? Så här resonerar du — det är samma fyra steg som kursens slutprov prövar i kod.
1. En siffra utan osäkerhet säger lite
88 % på 50 fall är ett stickprov, inte sanningen. Ett 95 %-konfidensintervall för andelen rätt (Wilsonintervallet, som håller även nära 0 och 1) blir ungefär 76–94 % för version 2 och 71–92 % för version 1. Intervallen överlappar nästan helt.
Med 500 fall i stället för 50 krymper intervallet för 88 % till ungefär 85–91 %. Det är därför stora eval-uppsättningar spelar roll: inte för att siffran blir högre, utan för att den blir säkrare.
2. Jämför parat — bara fallen där versionerna skiljer sig räknas
Båda versionerna har körts på samma fall. Då är det fel att jämföra två fristående andelar. Titta i stället på fallen där svaren skiljer sig: version 2 löser 6 fall som version 1 missade, men tappar 4 som version 1 klarade. De övriga 40 fallen säger ingenting om skillnaden.
Är 6 mot 4 mer än slumpen? McNemars test frågar just det: om versionerna vore lika bra skulle varje skiljande fall vara ett myntkast. Med 10 skiljande fall och fördelningen 6–4 blir p ≈ 0,75. Det är brus. För att en skillnad på 10 fall ska bli signifikant på 5 %-nivån krävs ungefär 1–9; med 12 skiljande fall räcker 2–10 (p ≈ 0,04).
Slutsatsen är inte att version 2 är sämre, utan att mätningen inte kan skilja dem åt. Behövs svaret måste testmängden växa, särskilt med fall där versionerna faktiskt beter sig olika.
3. Regressionstester: vissa fall får aldrig gå sönder
Ett av de fyra fall som version 2 tappade är att boten ska vägra lämna ut personnummer. Det är ett kritiskt fall. En releasegrind blockerar på kritiska fall oavsett totalen — en högre träffsäkerhet kan inte köpa tillbaka ett dataskyddsfel.
En vanlig fälla: fall som saknas i den nya körningen, till exempel för att de kraschade eller filtrerades bort. Räknas de inte alls stiger träffsäkerheten av sig själv. Ett fall som saknas ska räknas som fel.
- Lista regressioner: fall som gick från rätt till fel.
- Märk kritiska fall och blockera om något av dem fallerar.
- Sätt en lägsta träffsäkerhet och räkna saknade fall som fel.
- Spara resultatet per fall, så att nästa release jämförs mot samma baslinje.
4. LLM som domare: konsekvent är inte samma sak som rätt
När svaren är fritext används ofta en språkmodell som domare som jämför två svar parvis. Domare har kända snedvridningar: de föredrar ofta det första alternativet (positionsbias), det längsta svaret och sin egen stil.
Kör därför varje jämförelse i båda ordningarna. Byter domaren sida när ordningen byts är domslutet oavgjort. Men det räcker inte: en domare som alltid väljer det längsta svaret är helt konsekvent och ändå fel. Mät också hur ofta domaren håller med mänskliga bedömare på ett urval innan du låter den avgöra releaser.
Beslutet
Version 2 ska inte släppas. Förbättringen går inte att skilja från brus, och ett kritiskt fall har gått sönder. Rätt nästa steg är att laga fallet med personnumret, utöka testmängden och mäta igen — inte att leta efter ett mått som ser bättre ut. Testar man många mått eller delmängder tills något blir signifikant gäller problemet med multipla jämförelser.