Slik leser du AI-kodingsbenchmarker og unngår å velge en papirseier

Kort sagt: Tallet «løser 76 prosent av oppgavene» sier nesten ingenting i seg selv. Det viktige er hvilket oppgavesett som ga resultatet, hvilken modell og agent-wrapper som ble målt sammen, om oppgavene er ferske eller gamle, og hvor mye det kostet. Uten disse betingelsene passer prosenttallet på et reklamebanner, men ikke når du skal velge et verktøy.

Nå skal jeg forklare på enkelt språk hva de to viktigste kodingsbenchmarkene måler, hvor fallgruven ligger i tabellene, og hvordan du kan sjekke en rangering på ett minutt før du stoler på den. Historiske benchmarkdefinisjoner omtales nedenfor. Her gjengis ingen aktuell, paret rangeringstabell. En gjeldende sammenligning av scorer eller kostnad trenger sin egen lenkede tabell, dato og konfigurasjon.

Les mer om arbeid med modeller i Ailoot-dokumentasjonen.

Hva viser en benchmarkprosent egentlig?#

En benchmark fungerer enkelt. Det finnes en ferdig liste med programmeringsoppgaver. Verktøyet får hver oppgave, sender tilbake kode, og systemet kjører automatiserte tester for å se om løsningen fungerer. Andelen oppgaver som består, er prosenttallet som vises i tabellen.

Styrken her er at evalueringen er objektiv. En test er enten grønn eller rød; ingen gir en poengsum basert på «øyemål». På dette punktet er benchmarker mer pålitelige enn anmeldelser eller anbefalinger.

Svakheten er akkurat den samme. Oppgavesettet er begrenset og kjent på forhånd for alle, også dem som trener modellene. Hver måling har sine egne betingelser. Og oppgavene i settet ligner nesten helt sikkert ikke på det du gjør. Det fører til alle fallgruvene jeg tar opp nedenfor. Prosenttallet beskriver et verktøys atferd på en lukket oppgaveliste som tilhører noen andre, og det kan ikke overføres direkte til prosjektet ditt.

Hva måler HumanEval, og hvorfor kan du ikke velge ut fra den lenger?#

HumanEval ble laget hos OpenAI og lansert i 2021 sammen med Codex-modellen. Det inneholder 164 små Python-oppgaver: Modellene får en tekstlig beskrivelse av en funksjon, skriver funksjonskroppen, og et sett med automatiserte tester kontrollerer om den fungerer riktig.

På den tiden var det en god måte å skille modellene på. I sin egen artikkel oppgir forfatterne dette tallet: Den første Codex løste 28.8 prosent av oppgavene i ett forsøk, mens vanlig GPT-3 ikke løste noen.

Siden den gang har modellene blitt bedre, og i dag fullfører de sterke modellene nesten hele HumanEval. Når alle skårer nær 100 prosent, slutter tabellen å skille mellom dem: Forskjellene mellom verktøyene forsvinner. Dette kalles metning av benchmarken, og HumanEval har vært i den tilstanden lenge.

Den andre svakheten er mer alvorlig. Oppgavene er svært små: Skriv én funksjon ut fra en beskrivelse. Det virkelige arbeidet ditt er annerledes – det handler om et stort prosjekt med en historikk, der du må forstå andres kode, finne en feil og unngå å ødelegge kode rundt den. Det er et stort gap mellom «skriv en funksjon fra bunnen av» og «rett en feil i et aktivt prosjekt». En høy HumanEval-poengsum er derfor ikke lenger noen grunn til å velge et verktøy; den er snarere et tegn på at «det grunnleggende er på plass».

Hva måler SWE-bench, og hvordan ligger den nærmere det virkelige arbeidet?#

SWE-bench er grunnleggende annerledes, og derfor mer interessant. Den er bygget på reelle issues og pull requests i populære GitHub-prosjekter. Ifølge forfatterne inneholder den 2,294 oppgaver fra 12 store Python-repositorier og ble lansert i oktober 2023.

Evalueringslogikken er objektiv. De tar et punkt i et prosjekt der det fantes en reell feil, sammen med et sett tester som feilet på det tidspunktet. Verktøyet får problembeskrivelsen og redigerer koden. Deretter kjører de de samme testene: Hvis de blir grønne, er oppgaven faktisk løst; her stoler ingen på muntlige løfter.

De første tallene viser hvor mye vanskeligere dette er enn leketøyoppgaver. Den første baseline-tilnærmingen fikk bare 1.96 prosent på SWE-bench, og den første agenten fikk 12.47 prosent. Med andre ord var det vanskelig selv å komme i nærheten av reelt kodearbeid. Prosentene økte senere, men de startet nær null.

Når du ser høye tall i en rangering av AI-kodingsagenter i dag, kommer de som oftest fra SWE-bench eller den menneskeverifiserte delmengden på 500 oppgaver, kalt SWE-bench Verified. Det er en rimelig benchmark. Men også den har betingelser som kan gjøre prosenttallet misvisende, og det er det jeg tar opp videre.

Selv den mest pålitelige benchmarken i en tabell er ennå ikke et resultat på prosjektet ditt. Resultatet avhenger av hvordan du arbeider med verktøyet, og topplasseringen i rangeringen avgjør lite. For pålitelig arbeid er kombinasjonen viktig: AI-klon, Second Brain og kontekstutvikling. Ryddig kontekst forbedrer din personlige suksessrate langt tydeligere enn å velge en modell fra en tabell.

Hvorfor viser den samme modellen ulike prosenttall?#

Det er her den vanligste feilen ved lesing av benchmarker ligger. Folk leser en tabell som en rangering av modeller: Denne modellen er to prosent smartere enn den andre. Men tre ting påvirker prosenttallet, og modellen er bare én av dem.

For det første selve modellen. For det andre agent-wrapperen rundt den: et program som lar modellen navigere i filer, kjøre kommandoer, lese feilmeldinger og skrive om kode. Den samme modellen gir forskjellige resultater i en smart wrapper og en enkel wrapper fordi wrapperen bestemmer hvordan modellen arbeider med prosjektet. For det tredje resonneringsnivået – altså hvor grundig modellen tenker gjennom hvert trinn. Jo lenger den tenker, desto høyere blir prosenttallet vanligvis, og desto høyere blir kostnaden.

En reproduserbar sammenligning må bevare hele oppsettet. Bruk dette som rapportmal, ikke en målt rangering:

Da kan du se hva som endret seg og om sammenligningen faktisk isolerer resonneringsinnstillingen. Det tidligere tallmessige eksemplet uten lenke behandles ikke som et målt resultat.

Regelen er enkel: En god rangering oppgir alltid hvilken modell, wrapper og hvilket resonneringsnivå som ble brukt. Hvis tabellen bare viser et modellnavn og en prosent, uten å oppgi wrapperen, er den vanskelig å stole på: Du vet ikke hva som faktisk ble målt. Artikkelen om rangeringen av AI-kodingsagenter forklarer mer om hva kombinasjonen «modell pluss wrapper» består av.

Dette forklarer også hvorfor et verktøy med toppscore noen ganger sliter for deg. Benchmarken måler en modell i en finslipt wrapper som tilhører noen andre, på oppgaver som tilhører noen andre. Wrapperen, prosjektet og konteksten du gir modellen, er annerledes. På prosjektet ditt avhenger resultatet av konteksten; tabellraden er sekundær.

Hvorfor «utløper» oppgaver, og hva er lekkasje av treningsdata?#

Her er fallgruven som ikke synes i selve tallet, men som undergraver det mer enn noe annet. Modeller trenes på enorme mengder tekst og kode samlet inn fra internett. Og nesten alle kodingsbenchmarker er offentlig tilgjengelige: oppgavene, testene og referanseløsningene.

Mekanismen er enkel. Hvis en oppgave og den riktige løsningen kom med i treningsdataene, kan modellen ha pugget dem. Under evalueringen løser den da ikke egentlig oppgaven, men henter fram et kjent svar fra hukommelsen. Det ser ut som en løsning, men er bare et minne. Dette kalles treningslekkasje eller datakontaminering.

Jo eldre og mer populært oppgavesettet er, desto større er risikoen. HumanEval har vært på nettet siden 2021; settet er skrevet om, analysert og tatt med i utallige datasett mange ganger. Det ville være rart å forvente at en moderne modell ikke har «sett det». Derfor er hvor ferske oppgavene er, en egen kvalitetsindikator for en benchmark. Et godt sett oppdateres regelmessig eller holder noen oppgaver lukket, slik at de ikke kan læres på forhånd.

Hva bør du gjøre når du leser en rangering? Sjekk datoen for oppgavene og om settet oppdateres. Hvis en benchmark er bygget på ferske feil fra de siste månedene, fortjener den større tillit. Hvis det er et sett fra fem år tilbake, sier en høy prosent mer om modellens gode hukommelse enn evnen til å løse den nye oppgaven din. Denne effekten vises med et konkret eksempel i artikkelen om den ferske FrontierCode-benchmarken, der oppgavene bevisst var nye.

Hvorfor betyr en forskjell på et par prosentpoeng ofte ingenting?#

Et annet forhold gjør topplasseringen i en tabell misvisende: En modell svarer ikke likt hver gang. På samme prompt kan den følge en litt annen tankerekke. Kjører du derfor ett verktøy flere ganger på ett oppgavesett, svinger prosenttallet litt fra kjøring til kjøring. Denne variasjonen kalles varians.

Den praktiske konklusjonen er enkel. Når to rader i en rangering skiller seg med ett eller to prosent, kan forskjellen lett skyldes støy. Det er bortkastet å jakte på et verktøy som er «to prosent høyere»: De kan lett bytte plass i neste kjøring. En forskjell er verdt å vurdere som betydelig når den er tydelig og holder seg på tvers av et stort oppgavesett; et par poeng oppfyller ikke det kravet.

Det siste punktet, som nesten alltid er viktigere enn selve prosenttallet, er prisen. Lignende resultater kan koste svært forskjellige beløp. En kostnadssammenligning trenger begge modell- og wrapperkonfigurasjoner og hele forbruket på det evaluerte oppgavesettet, inkludert mislykkede forsøk. Del på forsøkte oppgaver for kostnad per forsøk, eller på løste oppgaver for kostnad per løst oppgave, og merk hvilket mål som brukes. Artikkelen gir ingen kildebelagt paret kostnadsmåling. Les derfor alltid en rangeringsrad sammen med prisen, for prosenttallet betyr lite alene. Artikkelen om kostnaden for én løst oppgave forklarer hvordan du kan sammenligne verktøy rettferdig ut fra kostnad.

Hvordan kan du lese en benchmarktabel på ett minutt?#

La meg samle alt i en kort sjekkliste. Åpne en rangeringstabell og gå gjennom disse sju punktene i rekkefølge.

1. Hvilket oppgavesett? HumanEval er svak i dag; SWE-bench ligger nærmere virkelig arbeid. Hvis settet ikke er navngitt, trenger du ikke lese videre.
2. Er oppgavene ferske eller gamle? Et ferskt eller delvis lukket sett er mer pålitelig enn et gammelt, offentlig sett som modellen kan ha lært.
3. Hvilken modell ble målt? Det nøyaktige navnet og versjonen, ikke et vagt «AI» eller navnet på en modellfamilie.
4. Hvilken agent-wrapper? Prosenttallet gjelder kombinasjonen «modell pluss wrapper». Hvis wrapperen ikke er oppgitt, vet du ikke hva som ble målt.
5. Hvilket resonneringsnivå? Én modell gir forskjellige prosentresultater og kostnader på ulike nivåer.
6. Hva koster en oppgave? Lignende resultater kan ha flere ganger så stor prisforskjell. Se prosenttallet sammen med kostnaden.
7. Hvor stor er variansen? En forskjell på ett eller to poeng mellom rader er ofte bare støy.

Det finnes et åttende spørsmål, og det handler om deg: Ligner oppgavene i settet på arbeidet ditt? En benchmark med Python-oppgaver sier lite til noen som bygger et nettsted eller en bot med et annet sett verktøy. Selv et ærlig tall på andres oppgaver garanterer ikke et resultat på prosjektet ditt. Det finnes bare én pålitelig måte å sjekke det på: Kjør et par vanlige oppgaver gjennom verktøyet og se selv på resultatet. Artikkelen om hvordan du sjekker AI-generert kode forklarer hvordan du kan finne ut om koden fungerer hvis du ikke programmerer selv.

Hva bør du til slutt se på?#

Hovedpoenget i hele artikkelen er kort: En plassering i rangeringen er en grunn til å se nærmere på et verktøy, men du må grave videre selv. Et høyt tall sier bare at et verktøy gjorde en grei jobb på en bestemt, lukket liste med oppgaver under bestemte betingelser. Prosenttallet viser ikke om disse betingelsene passer for deg.

Les derfor det som står under rangeringsraden: hvilke oppgaver, hvor ferske de er, hvilken kombinasjon av modell og wrapper, hvilket resonneringsnivå, hva det koster, og om forskjellen forsvinner i støyen. En tabell som ikke besvarer disse spørsmålene, hører hjemme på et reklamebanner. Vurderingen av hvilket verktøy du bør kode med i 2026 forklarer hvilket verktøy du bør velge for oppgavene dine i utgangspunktet.

Og dette er viktigere enn enhver benchmark. Selv det beste verktøyet i rangeringen sliter med rotete kontekst og fungerer godt med ryddig kontekst. Din personlige suksessrate kommer av hva du gir modellen og hvordan du formulerer oppgaven; tabellraden er sekundær. Rangeringen hjelper deg med å utelukke de klart svake alternativene, men du skaper resultatet.

En plassering i rangeringen utelukker svake alternativer, men resultatene på prosjektet ditt avhenger av metoden: AI-klon pluss Second Brain pluss kontekstutvikling.

For videre arbeid – Ailoot.