Så läser du AI-benchmarks för kodning och undviker att utse en pappersvinnare

Kort sagt: siffran ”löser 76 procent av uppgifterna” säger nästan ingenting i sig. Det viktiga är vilken uppgiftsmängd som gav resultatet, vilken modell och agentens wrapper som räknades tillsammans, om uppgifterna är nya eller gamla och vad det kostade. Utan de villkoren duger procentsatsen som reklambanner, men inte för att välja ett verktyg.

Nu ska jag förklara på ett enkelt sätt vad de två viktigaste benchmarkerna för kodning mäter, var haken finns i tabellerna och hur du kan kontrollera en ranking på en minut innan du förlitar dig på den. Historiska benchmarkdefinitioner diskuteras nedan. Ingen aktuell parad topplistebild återges här; en aktuell poäng- eller kostnadsjämförelse behöver en egen länkad tabell, datum och konfiguration.

Läs mer om att arbeta med modeller i Ailoot-dokumentationen.

Vad visar egentligen en procentsats i en benchmark?#

En benchmark fungerar enkelt. Det finns en färdig lista med programmeringsuppgifter. Verktyget får varje uppgift och skickar tillbaka kod, och systemet kör automatiserade tester för att se om lösningen fungerar. Andelen uppgifter som klarar testerna är procentsatsen som visas i tabellen.

Styrkan är att utvärderingen är objektiv. Ett test är antingen grönt eller rött; ingen sätter ett poängtal efter en snabb blick. I det avseendet är benchmarker ärligare än recensioner och omdömen.

Svagheten är precis densamma. Uppgiftsmängden är begränsad och känd i förväg av alla, även dem som tränar modellerna. Varje mätning har sina egna villkor. Och uppgifterna i mängden liknar nästan säkert inte det du gör. Det leder till fallgroparna jag tar upp nedan. Procentsatsen beskriver ett verktygs beteende på någon annans slutna uppgiftslista, och den kan inte överföras direkt till ditt projekt.

Vad mäter HumanEval, och varför kan du inte längre välja utifrån den?#

HumanEval skapades hos OpenAI och släpptes 2021 tillsammans med modellen Codex. Den innehåller 164 små Python-uppgifter: modellerna får en funktionsbeskrivning i ord, skriver dess kod och en uppsättning automatiserade tester kontrollerar om den fungerar korrekt.

Då var den bra på att skilja modeller åt. I sin egen artikel anger författarna den här siffran: den första Codex löste 28,8 procent av uppgifterna i ett försök, medan vanliga GPT-3 inte löste någon.

Sedan dess har modellerna utvecklats, och i dag klarar de starka nästan allt i HumanEval. När alla får resultat nära 100 procent slutar tabellen att skilja modellerna åt: skillnaderna mellan verktygen försvinner. Det kallas att en benchmark har mättats, och HumanEval har varit i det läget länge.

Det andra felet är allvarligare. Uppgifterna är pyttesmå: skriv en funktion utifrån en beskrivning. Ditt verkliga arbete är annorlunda – det handlar om ett stort projekt med en historik, där du måste förstå någon annans kod, hitta ett fel och undvika att förstöra närliggande kod. Det är en avgrund mellan ”skriv en funktion från grunden” och ”rätta ett fel i ett projekt i drift”. Därför är ett högt HumanEval-resultat i dag inte längre ett skäl att välja ett verktyg; det är snarare en markering om att ”grunderna sitter”.

Vad mäter SWE-bench, och hur liknar den verkligt arbete mer?#

SWE-bench är i grunden annorlunda och därför mer intressant. Den byggdes utifrån verkliga ärenden och pull requests i populära GitHub-projekt. Enligt upphovspersonerna innehåller den 2 294 uppgifter från 12 stora Python-arkiv och släpptes i oktober 2023.

Utvärderingen är ärlig. De tar en punkt i ett projekt där det fanns ett verkligt fel och en uppsättning tester som då misslyckades. Verktyget får problembeskrivningen och redigerar koden. Sedan körs samma tester: om de blir gröna är uppgiften faktiskt löst; här litar ingen på muntliga löften.

De första siffrorna visar hur mycket svårare detta är än leksaksuppgifter. Den första baslinjemetoden fick bara 1,96 procent på SWE-bench, och den första agenten fick 12,47 procent. Med andra ord var det svårt att ens komma nära verkligt kodningsarbete, och procentsatserna steg senare, men de började nära noll.

När du i dag ser höga siffror i en ranking av AI-kodningsagenter kommer de därför oftast från SWE-bench eller dess delmängd med 500 mänskligt verifierade uppgifter, kallad SWE-bench Verified. Det är en rimlig benchmark. Men även den har villkor utan vilka procentsatsen blir missvisande, och det ska jag ta upp härnäst.

Inte ens den ärligaste benchmarken i en tabell är ännu ett resultat i ditt projekt. Utfallet beror på hur du arbetar med verktyget, och den översta raden i rankingen säger väldigt lite. För tillförlitligt arbete spelar kombinationen roll: AI-klon, Second Brain och kontextteknik. Ren kontext förbättrar din personliga träffsäkerhet mycket mer märkbart än att välja en modell från en tabell.

Varför visar samma modell olika procentsatser?#

Det är här det vanligaste misstaget vid läsning av benchmarker döljer sig. Folk läser en tabell som en modellranking: den här modellen är två procent smartare än den där. Men tre saker påverkar procentsatsen, och modellen är bara en av dem.

För det första själva modellen. För det andra agentens wrapper runt den: ett program som låter modellen navigera bland filer, köra kommandon, läsa felmeddelanden och skriva om kod. Samma modell i en smart wrapper och en enkel wrapper ger olika resultat eftersom wrappern avgör hur modellen arbetar med projektet. För det tredje resonemangsnivån – det vill säga hur grundligt modellen tänker igenom varje steg. Ju längre den tänker, desto högre blir procentsatsen vanligtvis, och desto högre blir kostnaden.

En reproducerbar jämförelse ska bevara hela konfigurationen. Använd följande som rapportmall, inte som uppmätt topplista:

Det visar vad som ändrades och om jämförelsen faktiskt isolerar resonemangsinställningen. Det tidigare numeriska exemplet utan länk behandlas inte som ett uppmätt resultat.

Regeln är följande: en bra ranking anger alltid vilken modell, vilken wrapper och vilken resonemangsnivå som användes. Om tabellen bara innehåller ett modellnamn och en procentsats, utan att ange wrappern, är den svår att lita på: du vet inte vad som faktiskt mättes. Mer om vad kombinationen ”modell plus wrapper” består av förklaras i artikeln om rankingen över AI-kodningsagenter.

Det här förklarar också varför ett verktyg med toppresultat ibland har svårt för dina uppgifter. Benchmarken mäter en modell i någon annans förfinade wrapper och på någon annans uppgifter. Din wrapper, ditt projekt och kontexten du ger modellen är annorlunda. I ditt projekt beror resultatet på kontexten; tabellraden kommer i andra hand.

Varför ”blir uppgifter inaktuella”, och vad är läckage av träningsdata?#

Här är haken som inte syns i själva siffran men undergräver den mer än något annat. Modeller tränas på enorma mängder text och kod som samlats in från internet. Och nästan alla benchmarker för kodning är offentligt tillgängliga: uppgifterna, testerna och referenslösningarna.

Mekanismen är enkel. Om en uppgift och dess korrekta lösning kommit med i träningsdata kan modellen ha memorerat dem. Under utvärderingen löser den då inte uppgiften så mycket som den hämtar ett välbekant svar ur minnet. Det ser ut som en lösning, men är bara minne. Det kallas läckage av träningsdata eller datakontaminering.

Ju äldre och mer populär uppgiftsmängden är, desto större är risken. HumanEval har funnits på nätet sedan 2021; den har skrivits om, analyserats och inkluderats i otaliga dataset många gånger om. Det vore märkligt att förvänta sig att en modern modell inte skulle ha ”sett den”. Därför är uppgifternas aktualitet en separat kvalitetsindikator för en benchmark. En bra uppgiftsmängd uppdateras antingen regelbundet eller håller vissa uppgifter slutna så att de inte kan läras in i förväg.

Vad ska du göra när du läser en ranking? Kontrollera när uppgifterna skapades och om uppgiftsmängden uppdateras. Om en benchmark bygger på nya fel från de senaste månaderna förtjänar den större tillit. Om den bygger på en uppgiftsmängd från fem år sedan säger en hög procentsats mer om modellens goda minne än dess förmåga att lösa din nya uppgift. Det här visas konkret i artikeln om den nya benchmarken FrontierCode, vars uppgifter medvetet var nya.

Varför betyder en skillnad på ett par procentenheter ofta ingenting?#

En annan sak som gör förstaplatsen i en tabell missvisande är att en modell inte svarar likadant varje gång. På samma prompt kan den följa ett något annorlunda resonemang. Om du därför kör ett verktyg flera gånger på en uppgiftsmängd varierar procentsatsen en aning från körning till körning, och den variationen kallas varians.

Den praktiska slutsatsen är enkel. När två rader i en ranking skiljer sig med en eller två procent kan skillnaden lätt bero på brus. Det är dumt att jaga ett verktyg som är ”två procent bättre”: vid nästa körning kan ordningen lätt ändras. En skillnad är värd att betrakta som betydelsefull när den märks och håller i sig över en stor uppgiftsmängd; ett par procentenheter når inte upp till den nivån.

Och det sista, som nästan alltid är viktigare än själva procentsatsen, är priset. Liknande resultat kan kosta väldigt olika mycket. En kostnadsjämförelse behöver båda modell- och agentkonfigurationerna samt hela kostnaden för utvärderad uppgiftsuppsättning, inklusive misslyckade försök. Dividera med försökta uppgifter för kostnad per försök eller med lösta uppgifter för kostnad per löst uppgift och ange vilket mått du använder. Artikeln ger ingen källbelagd parad kostnadsmätning. Läs därför alltid en rad i rankingen tillsammans med priset, eftersom procentsatsen säger lite på egen hand. Artikeln om kostnaden för en löst uppgift förklarar hur du jämför verktyg rättvist utifrån kostnad.

Hur läser du vilken benchmarktabell som helst på en minut?#

Låt mig sammanfatta allt i en kort checklista. Öppna valfri rankingtabell och gå igenom de här sju punkterna i ordning.

1. Vilken uppgiftsmängd? HumanEval är svag i dag; SWE-bench ligger närmare verkligt arbete. Om uppgiftsmängden inte anges behöver du inte läsa vidare.
2. Är uppgifterna nya eller gamla? En ny eller delvis sluten uppgiftsmängd är mer tillförlitlig än en gammal offentlig mängd som modellen kan ha lärt sig.
3. Vilken modell utvärderades? Det exakta namnet och versionen, inte ett vagt ”AI” eller namnet på en modellfamilj.
4. Vilken agentwrapper? Procentsatsen gäller kombinationen ”modell plus wrapper”. Om wrappern inte anges vet du inte vad som mättes.
5. Vilken resonemangsnivå? En modell på olika nivåer ger olika procentsatser och olika kostnader.
6. Vad kostar en uppgift? Liknande resultat kan skilja sig mångdubbelt i pris. Läs procentsatsen tillsammans med kostnaden.
7. Hur stor är variansen? En skillnad på en eller två procentenheter mellan rader är ofta bara brus.

Det finns en åttonde fråga, och den handlar om dig: Liknar uppgifterna i mängden ditt arbete? En benchmark med Python-uppgifter säger inte mycket till någon som bygger en webbplats eller en bot med en annan uppsättning verktyg. Även en ärlig siffra från någon annans uppgifter garanterar inte ett resultat i ditt projekt. Det finns bara ett tillförlitligt sätt att kontrollera: kör ett par typiska uppgifter genom verktyget och granska resultatet själv. Artikeln om hur du kontrollerar AI-genererad kod förklarar hur du kan avgöra om koden fungerar även om du inte programmerar själv.

Vad ska du då titta på till slut?#

Huvudpoängen i hela artikeln är kort: en plats i rankingen är ett skäl att titta närmare på ett verktyg, men du måste själv undersöka det vidare. En hög siffra visar bara att ett verktyg gjorde ett hyfsat jobb på en särskild, sluten uppgiftslista under särskilda villkor. Procentsatsen visar inte om de villkoren passar dig.

Läs därför det som står under rankingraden: vilka uppgifter det gäller, hur nya de är, vilken kombination av modell och wrapper som använts, vilken resonemangsnivå den har, hur mycket det kostar och om skillnaden försvinner i bruset. En tabell som inte besvarar frågorna hör hemma på en reklambanner. Recensionen vilket verktyg du ska koda med 2026 förklarar vilket verktyg du bör välja för dina uppgifter från början.

Och här är det som betyder mer än någon benchmark. Även det bästa verktyget i rankingen har svårt med rörig kontext och fungerar bra med ren kontext. Din personliga träffsäkerhet beror på vad du ger modellen och hur du formulerar uppgiften; tabellraden kommer i andra hand. Rankingen hjälper dig att välja bort de tydligt svaga alternativen, men det är du som skapar resultatet.

En plats i rankingen hjälper dig att välja bort svaga alternativ, men resultaten i ditt projekt beror på metoden: AI-klon plus Second Brain plus kontextteknik.

För fortsatt arbete – Ailoot.