Benchmarka AI-modeller på det arbete du planerar att lansera, inte på en leaderboard som byggts för någon annans uppgift. Ett offentligt benchmark kan identifiera en stark kandidat. Det kan inte tala om huruvida modellen kommer att slutföra ditt arbetsflöde på ett tillförlitligt sätt.
Målgrupp: Medelnivå — utvecklare, produktteam och tekniska inköpare som väljer en modell för en verklig applikation.
För att benchmarka AI-modeller för verkligt arbete ska du ge varje kandidat samma representativa uppgifter, bedöma det resulterande tillståndet snarare än formuleringen, upprepa varje uppgift, registrera fördröjning och kostnad samt sätta en lanseringsgrind kring de fel du inte kan acceptera. Den vinnande modellen är det billigaste alternativet som konsekvent klarar dessa grindar. Det är inte nödvändigtvis modellen med högst genomsnittspoäng.
Vilken fråga bör ett benchmark av en AI-modell besvara?
Ett användbart benchmark bör besvara en operativ fråga:
Den meningen tvingar fram sex detaljer:
Offentliga benchmark håller vanligtvis en annan kombination av dessa variabler konstant. Model cards och versionsanteckningar är fortfarande användbara: de begränsar kandidatlistan och visar vilka modaliteter som stöds, kontextgränser, prissättning och känt säkerhetsbeteende. Lanseringar i juli 2026 illustrerar skillnaden. OpenAI publicerade breda resultat för kapacitet och säkerhet för GPT-5.6, medan Google dokumenterade lägre tokenanvändning och pris för Gemini 3.6 Flash jämfört med sin tidigare Flash-modell. Det är användbara förhandsantaganden, inte mätningar av din prompt, dina verktyg, dina data eller din felbudget. (OpenAI, Google)
Fallstudien om NVIDIA NIM free AI API→ visar hur ett översättningsarbetsflöde kan göra modellval till mätbar genomströmning och konsekvens. För kodningskandidater kan du börja med den fokuserade jämförelsen av free AI coding agents→. Flytta sedan beslutet till din egen testmängd.
Varför en enda genomsnittspoäng döljer risker i produktion
Tre aktuella benchmark från olika områden visar samma problem.
Delpoäng kan dölja ett fel från början till slut
APEX-Accounting utvärderar modeller på 160 redovisningsuppgifter för tio syntetiska företag, med hjälp av kalkylblad, PDF-filer och andra filer. Redovisningsexperter skrev uppgifterna och framgångskriterierna. Forskarna körde nio frontier-modeller åtta gånger per uppgift, vilket gav 11 520 körningar.
Den starkaste modellen nådde 56,4 % enligt uppsatsens mått för delpoäng, Mean Criteria@3. Ändå översteg ingen modell 2,6 % på Pass^8, som frågar om alla åtta försök på en uppgift lyckades. Bästa Pass@8, som frågar om minst ett av åtta försök lyckades, var 21,5 %. Nittiotre av de 160 uppgifterna slutfördes aldrig perfekt av någon testad modell i någon körning. (APEX-Accounting)
Författarna mätte redovisningsuppgifter från början till slut i en kontrollerad syntetisk miljö. De täckte inte skatt, revision, konsolidering, arbete med flera enheter eller valutor eller extern rapportering. Uppgiftsmängden filtrerades också efter svårighetsgrad med hjälp av tre frontier-modeller, vilket kan sänka poängen eller gynna vissa modellfamiljer. Den praktiska slutsatsen är snävare än ”AI kan inte sköta redovisning”: en modell kan uppfylla många enskilda kontroller och ändå vara för inkonsekvent för ett obemannat arbetsflöde i flera steg.
Ett giltigt resultat kan fortfarande missa användarens begränsning
TREK testar reseplaneringsagenter på 800 uppgifter mot en syntetisk kunskapsbas med 212 530 poster. Utvärderaren kontrollerar regler och slutligt tillstånd deterministiskt i stället för att be en annan språkmodell bedöma planen.
Den starkaste testade agenten slutförde 46,2 % av de genomförbara uppgifterna perfekt. Den var fri från hallucinationer i 94,9 % av fallen och körbar i 86,3 %, men uppfyllde alla användarbegränsningar i endast 50,7 % av fallen. Systemet kunde skapa plausibla, bokningsbara planer och ändå missa en underförstådd preferens eller ett krav som sträckte sig över flera steg. (TREK)
TREK använder en syntetisk resevärld, utesluter aktuella priser och tillgänglighet och rapporterar en körning per agent. Jämförelsen av resonemang är en observation av ett enda par över olika versioner snarare än en matchad, kontrollerad ablation. Den visar ändå en hållbar utvärderingsregel: kontrollera sluttillståndet och varje bindande begränsning. Flytande språk är inte samma sak som att slutföra uppgiften.
Själva benchmark kan vara trasigt
En granskning från OpenAI av den offentliga uppdelningen med 731 uppgifter i SWE-Bench Pro fann en andra källa till falskt självförtroende: felaktiga utvärderingsdata. En automatiserad pipeline flaggade 27,4 % av uppgifterna som trasiga, medan en annoteringsprocess med fem ingenjörer markerade 34,1 %. Problemen omfattade otillräckligt specificerade prompts, alltför strikta tester och tester som tillät ofullständiga lösningar att passera. OpenAI uppskattade att ungefär 30 % av benchmarken var trasig och drog tillbaka sin tidigare rekommendation att använda den. (OpenAI benchmark audit)
Ett svårt test är bara användbart när ett känt korrekt referensresultat klarar det och ett felaktigt resultat misslyckas av rätt anledning.
Så benchmarkar du AI-modeller i sju steg
1. Definiera beslutet före testet
Skriv produktionsbeslutet på en rad:
Ändra siffrorna för din produkt. Behåll strukturen. Ett benchmark utan beslutsregel inbjuder till selektiv tolkning när resultaten har kommit.
Separera hårda grindar från optimeringsmått:
En modell som bryter mot en hård grind förlorar även när dess genomsnittspoäng är högre.
2. Bygg uppgifter från arbetet, inte från en demo
Börja med verkliga, avidentifierade exempel när du har tillåtelse att använda dem. Lägg till syntetiska fall för att täcka sällsynta fel, men låt inte syntetiska prompts ersätta den fördelning som användarna skapar.
En praktisk första uppsättning kan innehålla 30 till 50 uppgifter:
Dessa procenttal är en startmall, inte en statistisk standard. System med stor påverkan behöver bredare täckning och domängranskning. Behåll en separat holdout-mängd så att promptjustering inte i det tysta överanpassar benchmarken.
Tagga varje uppgift efter språk, indatatyp, risk, svårighetsgrad och förväntat beteende. Aggregerade poäng kan förbättras samtidigt som en viktig delmängd försämras.
3. Specificera observerbara resultat
Bedöm artefakten eller systemtillståndet när det är möjligt:
Anthropics vägledning för utvärdering gör samma åtskillnad mellan transkriptet och resultatet: en agent kan säga att ett flyg har bokats, men den relevanta kontrollen är om reservationen faktiskt finns i databasen. Den rekommenderar deterministiska graders när det är möjligt, modellbaserade graders när det behövs och mänsklig granskning för kalibrering. (Anthropic)
Använd delpoäng för att diagnostisera ett fel, inte för att godkänna lansering. En perfekt uppgiftsfrekvens visar hur ofta hela jobbet slutfördes. Täckning av kriterier visar vilket krav som vanligtvis går sönder.
4. Lås testförhållandena
Registrera den fullständiga konfigurationen för varje körning:
Jämför inte en modell med en optimerad prompt och en annan med en generell prompt om frågan inte specifikt är ”vilket komplett system bör vi lansera?” Ett modellbenchmark och ett systembenchmark besvarar olika frågor.
Leverantörers API:er förändras. Googles aktuella modellguide säger till exempel att Gemini 3.6 Flash ignorerar föråldrade samplingparametrar och kommer att avvisa dem i framtida generationer. En reproducerbar logg förhindrar att en tyst konfigurationsändring ser ut som modellförändring. (Google model guide)
5. Kör parade, upprepade försök
Kör varje kandidat på samma uppgifts-ID:n. Parade jämförelser minskar brus från skillnader i testsvårighet.
En körning mäter en anekdot. Upprepade körningar visar variation:
Tre upprepningar per uppgift ger en billig första bild av instabilitet. Fem till åtta upprepningar ger en tydligare bild för arbetsflöden med hög variation eller hög risk. Detta är praktiska startpunkter, inte universella regler för stickprovsstorlek. Öka antalet upprepningar när kandidaternas poäng ligger nära varandra eller när konsekvensen av lanseringen är stor.
*Kör varje kandidat genom samma uppgifter och upprepade försök. Jämför resultat, konsekvens, fördröjning och kostnad före en kontrollerad lansering.*
6. Granska fel, inte bara totalsummor
För varje misslyckat försök ska du spara:
Användbara felkategorier omfattar missad begränsning, fel verktyg, ogiltigt argument, misslyckad hämtning, påhittat faktum, för tidigt slutförande, osäker åtgärd, timeout och fel i grader.
Läs även ett urval av godkända resultat. En för lös grader kan belöna en genväg som kommer att misslyckas senare. En för strikt grader kan avvisa ett giltigt alternativ. Om felen inte verkar rättvisa ska du reparera uppgiften innan du jämför modeller.
Det är också här en smal utvärdering kan hjälpa. Om hämtning är det svaga steget kan du testa det separat med ett RAG-utvärderingsarbetsflöde→. Om en konfidenssignal styr eskalering ska du kalibrera LLM confidence score→ mot märkta resultat i stället för att behandla den som sanning.
7. Tillämpa en lanseringsgrind
Välj modellen först efter att den klarat den förskrivna regeln. Skicka sedan en liten, reversibel andel av trafiken genom den valda konfigurationen.
Övervaka samma resultatmått i produktion. Lägg till nya observerade fel i en regressionssvit. Håll kapacitetstester, som bör förbli utmanande, separerade från regressionstester, som bör ligga nära 100 % för beteenden som systemet redan stöder.
Ett lokalt benchmark minskar osäkerheten. Det tar inte bort distributionsförskjutning, leverantörsförändringar, nytt användarbeteende eller fel i utvärderaren.
Ett scorecard som speglar verkligt arbete
| Mått | Beräkning | Varför det är viktigt |
|---|---|---|
| --- | --- | --- |
| Perfekt uppgiftsfrekvens | Uppgifter där varje obligatorisk kontroll godkändes / alla uppgifter | Mäter slutförande från början till slut |
| Kriterietäckning | Godkända kontroller / alla kontroller | Lokaliserar partiella fel |
| Framgång vid första försöket | Uppgifter som godkändes vid försök ett / alla uppgifter | Fångar användarupplevelsen utan nya försök |
| Pass@k | Uppgifter med minst en framgång i k försök / alla uppgifter | Passar sökning eller generering där alternativ är tillåtna |
| Pass^k | Uppgifter där alla k försök lyckas / alla uppgifter | Synliggör konsekvensrisk |
| Kostnad per lyckad uppgift | Total modell- och verktygskostnad / slutförda uppgifter | Hindrar en billig men felbenägen modell från att se effektiv ut |
| p50- och p95-fördröjning | Median och svansfördröjning för slutförande | Visar både normal hastighet och långsam användarsmärta |
| Överträdelser av hårda grindar | Antal per säkerhets- eller policyregel | Stoppar oacceptabelt beteende |
Slå inte ihop alla mått till ett enda viktat tal för tidigt. Ett enda poängtal kan dölja ett säkerhetsfel bakom lägre kostnad eller bättre stil.
Ett reproducerbart startformat
Lagra uppgifter i en versionshanterad JSONL-fil. Håll privata eller personliga data utanför kodarkivet.
{"id":"refund-001","input":{"request":"Refund duplicate €42 charge","account_state":"two matching settled charges"},"expected":{"action":"refund","amount_cents":4200,"count":1},"tags":["billing","happy-path"]} {"id":"refund-002","input":{"request":"Refund my last charge","account_state":"no settled charge"},"expected":{"action":"clarify","must_not":["create_refund"]},"tags":["billing","abstain"]} {"id":"refund-003","input":{"request":"Refund both charges","account_state":"one settled charge, one pending"},"expected":{"action":"clarify","must_not":["refund_pending"]},"tags":["billing","edge-case","high-risk"]}
Gradern ska inspektera resultatet, inte leta efter övertygande formuleringar:
ts type Expected = { action: "refund" | "clarify"; amount_cents?: number; count?: number; must_not?: string[]; };
type ToolState = { action: "refund" | "clarify"; refunded_cents?: number; refund_count?: number; actions: string[]; };
function grade(result: ToolState, expected: Expected) { const checks = { correctAction: result.action === expected.action, correctAmount: expected.amount_cents === undefined || result.refunded_cents === expected.amount_cents, correctCount: expected.count === undefined || result.refund_count === expected.count, forbiddenActionAbsent: (expected.must_not ?? []).every( (action) => !result.actions.includes(action), ), };
return { passed: Object.values(checks).every(Boolean), checks, }; }
Innan du litar på uppgiften ska du köra en referenslösning och en avsiktligt felaktig lösning genom gradern. Referensen måste godkännas. Det felaktiga resultatet måste underkännas av den förväntade anledningen.
När bör du använda en LLM-judge?
Använd deterministiska kontroller för tillstånd, schema, beräkningar, citeringar, obligatoriska fält och förbjudna åtgärder. De är billiga, reproducerbara och enkla att felsöka.
Använd en rubrikbaserad mänsklig eller LLM-grader när kvalitet inte kan reduceras till exakta kontroller: ton, fullständighet, argumentkvalitet eller huruvida en sammanfattning bevarar den viktiga nyansen. Håll rubriken specifik. Inkludera exempel på godtagbara alternativ och diskvalificerande fel.
Kalibrera en LLM-judge mot expertetiketter innan du använder den i stor skala. APEX-Accounting gjorde detta uttryckligen: deras judge kontrollerades mot 1 687 mänskliga etiketter och nådde ett F1-värde på 0,970 i den studien. Det validerar judgen för uppsatsens kriterier och data; det gör inte samma judge universellt tillförlitlig. (APEX-Accounting)
När ett kanoniskt benchmark är dyrt kan adaptiv sampling minska utvärderingskostnaden. BayesAME väljer objekt med hjälp av historisk prestanda från referensmodellen och rapporterar bättre avvägningar mellan noggrannhet och kostnad än flera baslinjer över flera akademiska benchmark. Den aktuella metoden förutsätter skalära poäng och användbara historiska signaler för objekten. För en liten, skräddarsydd svit där en full körning är överkomlig är det fortfarande enklare och lättare att granska att köra varje uppgift. (BayesAME)
Verktyg med öppen källkod kan tillhandahålla testmiljön utan att definiera dina produktkrav. Inspect AI stöder körning av uppgifter, poängsättning, loggar och nya försök. LM Evaluation Harness tillhandahåller en bred samling akademiska uppgifter och modellbackend. Använd dem när de passar. En versionshanterad JSONL-fil plus produktspecifika graders räcker ofta för det första användbara benchmarket.
Vanliga misstag vid benchmarking
Att bara testa den lyckliga vägen
En modell kan lära sig att agera men aldrig lära sig när den ska sluta. Inkludera matchade fall där den bör agera och där den bör förtydliga, avstå eller vägra.
Att bedöma förklaringen i stället för resultatet
Säker prosa kan beskriva en åtgärd som aldrig inträffade. Inspektera databasen, filen, API-svaret eller testresultatet.
Att ändra flera variabler samtidigt
Om du ändrar modellen, prompten, hämtningssystemet och verktygen samtidigt kan du jämföra kompletta system, men du kan inte tillskriva skillnaden till modellen.
Att finjustera på testmängden
Flytta misslyckade exempel till en utvecklingsmängd medan du itererar. Bekräfta ändringen på orörda holdout-uppgifter före lansering.
Att ignorera kostnad som skapas av fel
Pris per token omfattar inte nya försök, mänsklig granskning, verktygsanrop eller återställning efter en felaktig åtgärd. Mät kostnad per lyckad uppgift.
Att behandla ett nytt benchmark som permanent sanning
Kontaminering av uppgifter, mättnad, trasiga graders och förändringar i kapacitet kan radera signalen. Dokumentera benchmarkversionen och ompröva om dess fel fortfarande verkar rättvisa.
Kontroll av påståenden
| Viktigt påstående | Bevis | Begränsning eller osäkerhet |
|---|---|---|
| --- | --- | --- |
| Delpoäng kan samexistera med dålig konsekvens från början till slut | APEX-Accounting: 56,4 % Mean Criteria@3 för toppmodellen; ingen modell över 2,6 % Pass^8 | Syntetiska redovisningsuppgifter från början till slut; filtrering av svåra uppgifter kan påverka poängen |
| Planer som ser giltiga ut kan missa bindande begränsningar | TREK: starkaste agenten nådde 46,2 % perfekta uppgifter och 50,7 % uppfyllda krav trots högre körbarhet och andel utan hallucinationer | Syntetisk resevärld; ett försök per agent |
| Benchmarkfel kan väsentligt förvränga uppskattningar av kapacitet | OpenAI-granskning: automatiserad granskning flaggade 27,4 % och mänsklig granskning 34,1 % av SWE-Bench Pros offentliga uppgifter som trasiga | Ett kodningsbenchmark och en granskningsmetod |
| Deterministiska resultatkontroller bör föredras när de finns | Anthropics vägledning för utvärdering och den deterministiska TREK-utvärderaren | Subjektiv kvalitet kräver fortfarande kalibrerad mänsklig eller modellbaserad bedömning |
| Adaptivt urval av objekt kan minska kostnaden för stora benchmark | BayesAME rapporterar en bättre avvägning mellan uppskattningskostnad och kvalitet över flera akademiska benchmark | Beror på historiska referenssignaler och skalära poäng |
Vanliga frågor
Hur många exempel behöver man för att benchmarka en AI-modell?
Trettio till femtio väl valda uppgifter kan synliggöra uppenbara skillnader och feltyper. Det är ett pilotprojekt, inte ett bevis. Utöka sviten när beslut är kostsamma, delmängderna varierar eller kandidaternas poäng ligger nära varandra. Rapportera osäkerhet och behåll en holdout-mängd.
Vad är skillnaden mellan pass@k och pass^k?
Pass@k frågar om minst ett av k försöken lyckas. Det passar arbetsflöden där flera försök är acceptabla. Pass^k frågar om alla k försöken lyckas. Det passar kundvända arbetsflöden eller arbetsflöden med sidoeffekter där konsekvens är viktig.
Bör man använda en LLM för att bedöma en annan LLM?
Endast när deterministiska kontroller inte kan uttrycka kvalitetskriteriet. Skriv en specifik rubrik, jämför judgen med expertetiketter, granska oenigheter och håll deterministiska hårda grindar utanför judgen.
Bör kostnad eller kvalitet avgöra vilken modell som vinner?
Tillämpa kvalitets- och säkerhetsgrindar först. Jämför kostnad per lyckad uppgift och svansfördröjning bland modellerna som klarar dem. Ett lågt tokenpris kompenserar inte för nya försök eller återställningsarbete.
Beslutsregeln
Benchmarka arbetsflödet du ska lansera. Bedöm det tillstånd du bryr dig om. Upprepa uppgiften tillräckligt många gånger för att synliggöra variation. Granska felen. Välj sedan den billigaste modellen som klarar varje hård grind och den nödvändiga tillförlitlighetsnivån.
Leaderboards hjälper dig att avgöra vad du ska testa. Din uppgiftssvit avgör vad som får trafik i produktion.