LLM-utvärdering: från offentliga benchmarks till ditt golden set

Nästan varje argument om utvärdering är två personer som mäter olika saker. Det finns tre projekt och de delar inget instrument.

Förvirringen är dyr i en riktning. En leaderboard säger att en modell är stark på resonemang på forskarnivå; den kan inte säga om den kommer att routa dina supportärenden. Och en applikationsutvärdering som poängsätter ett svar per input kan inte se en agent alls, eftersom en agent har en fördelning av trajectories och ett svar är ett enda sample från den. Kapitel 22 namngav den tredje raden och lämnade den tom: prestandamåttet, den del av en agents specifikation som team skriver ner sist eller aldrig.

Ordningen spelar också roll, och leverantören som säljer modellen till dig säger det själv. OpenAI:s agent-guide reducerar modellval till tre steg, i den här ordningen: ”Set up evals to establish a performance baseline”, ”Focus on meeting your accuracy target with the best models available”, ”Optimize for cost and latency by replacing larger models with smaller ones where possible”.¹ Utvärdering kommer först, eftersom steg två och tre är meningslösa utan ett tal.

Ett golden set är en lista med inputs, var och en med svaret nedskrivet, och en grader som avgör om en output matchar. Det är tråkigt, det är litet, och det är den enda artefakten i det här kapitlet som är din. Det som byggs här har tjugo uppgifter över en katalog med fem filer — inte Kapitel 23:s tre, så svaren är inte samma svar — och gradern skrivs innan agenten kör:

export type Task = {
  id: string;
  prompt: string;
  answer: string;          // the fact, in words, for a human and for a judge
  must: RegExp[];          // ALL must match the final answer
  mustNot?: RegExp[];      // NONE may match
};

export const GOLDEN: Task[] = [
  { id: "t04", prompt: "Which file is the largest?", answer: "access.log",
    must: [/access\.log/i], mustNot: [/errors\.log/i, /notes\.txt/i] },       
  { id: "t12", prompt: "Which HTTP status codes appear in access.log? List all of them.",
    answer: "200, 429 and 500", must: [/200/, /429/, /500/] },                
  // ...eighteen more
];

Två egenskaper är bärande. Listan mustNot finns eftersom en modell som nämner tre filer inklusive den rätta inte har svarat. Och answer är skriven i prosa såväl som i mönster, eftersom både en människa och en judge kommer att behöva den senare — och att skriva samma faktum två gånger i två notationer är så du upptäcker att du inte var överens med dig själv om vad uppgiften var.

Nu tabellen som avgör. Fyra kandidatsystem, samma tjugo uppgifter, accuracy med sitt intervall, och de två kolumner som en tabell med enbart accuracy alltid döljer:

Läs intervallen före vinnaren. Arm B:s körningar går från 11 % till 47 %; arm A:s från 3 % till 30 %. De överlappar över större delen av sin längd, vilket är Kapitel 4:s fynd som anländer precis där det utlovades: tjugo fall kan inte rangordna fyra system. Kapitel 15 vässade detta genom att ställa den parade frågan i stället — av fallen där två armar är oense, hur sned är fördelningen? — eftersom setets gemensamma svårighet tar ut sig. Här är varje par:

A vs B  +0 / -3   p = 0.2500       B vs C  +4 / -1   p = 0.3750
A vs C  +2 / -2   p = 1.0000       B vs D  +4 / -0   p = 0.1250
A vs D  +2 / -1   p = 1.0000       C vs D  +1 / -0   p = 1.0000

Inte en enda av de sex jämförelserna är etablerad. Den bästa armen slår armen utan verktyg alls med femton punkter, och tre discordant cases är vad det vilar på. Tjugo fall visar en mekanism och kan inte välja en leverantör; att säga något annat i ett möte är så en dålig modell blir köpt.

Det finns en sak tabellen etablerar, och det är kolumnen ingen tar med. Arm D kostar tretton gånger arm B per löst uppgift, eftersom sampling av tre trajectories och att ta modal-svaret tredubblar räkningen oavsett om det tredubblar accuracy eller inte. Accuracy-tabeller som utelämnar kostnad gör den tradeoffen osynlig.

Nu fyndet som förändrar hur du läser varje benchmark du någonsin kommer att se. Ta de samma tvåhundra transkripten — tjugo uppgifter, tio körningar, inte en token regenererad — och poängsätt dem på tre sätt:

Noll, tretton, tjugosex. Systemet förändrades inte. Gradern gjorde det. Exakt matchning returnerar noll inte för att agenten är värdelös utan för att inget fritextsvar någonsin är byte-identiskt med en referens: den mäter formatering och rapporterar det som förmåga.

Det är ingen kuriositet, det är en mekanism, och den har ett namn. En hard-cutoff metric poängsätter en uppgift allt-eller-inget över flera delfakta, så den multiplicerar effekten. Uppgift t12 ber om tre statuskoder samtidigt. Över de tio körningarna:

per-code presence   200: 9/10    429: 6/10    500: 8/10    (mean 0.77 per fact)
all three at once   5/10

Varje faktum är rätt ungefär tre fjärdedelar av tiden; att kräva alla tre samtidigt halverar poängen, och $0.77^3 = 0.457$ är nära nog den uppmätta 0.50 för att visa var fallet kom ifrån. Generalisera:

Läs raden 0.90 mot raden 0.95 vid $k = 10$: en förbättring per faktum på fem punkter blir tjugofem punkter på konjunktionen. Inget diskontinuerligt hände med modellen. En jämn kurva läst genom en allt-eller-inget-metrik ser ut som ett hopp — vilket är precis argumentet Schaeffer, Miranda och Koyejo förde om emergent abilities, och som Kapitel 10 sköt upp hit.² Deras audit fann att högst 5 av BIG-Benchs 39 föredragna metriker visar emergence alls, med två diskontinuerliga metriker som står för över 92 % av de påstådda fallen.

Så disciplinen i en rad: ett hopp i ett diagram är bevis om metriken tills motsatsen visas. Innan du tror att en förmåga dök upp, plota samma körningar med en metrik som ger partial credit och se om stupet finns kvar.

Det finns en andra ordningens version av detta som Kalai och kollegor menar skadar uppströms: benchmarks som poängsätts som rätt-eller-fel belönar gissningar framför att säga ”jag vet inte”, så en modell optimerad mot dem lär sig gissa. Deras föreslagna fix är inte ännu ett hallucination benchmark utan ”modifying the scoring of existing benchmarks that are misaligned but dominate leaderboards”.³ Ditt golden set har samma spak, och den är en rad: bestäm om avstående räknas som ett misslyckande eller som en egen kategori. De flesta bestämmer aldrig, så det räknas tyst som misslyckande, och systemet de shippar gissar.

Allt hittills poängsatte ett försök per uppgift. En agent är inte ett försök. Kapitel 17 etablerade att du inte har determinism ens vid temperature noll, så samma input producerar en fördelning av trajectories och en benchmark som kör varje uppgift en gång rapporterar ett sample från den.

τ-benchs bidrag är metriken för det. Artikeln definierar den rakt: ”we propose a new metric – pass^k (pass hat k), defined as the chance that all k i.i.d. task trials are successful, averaged across tasks.”⁴ Kör varje uppgift $n$ gånger, räkna de $c$ lyckade, och de unbiased estimators är:

Den andra är det bekanta pass@k från kodgenerering: chansen att minst ett av $k$ försök lyckas. Lägg dem bredvid varandra på samma uppmätta counts och de rör sig åt motsatta håll:

Samma körningar, samma grader, samma tjugo uppgifter. En kolumn säger att systemet förbättras med fler försök och den andra säger att det blir sämre, och båda har rätt, eftersom de svarar på olika frågor. pass@k är rätt metrik när en människa filtrerar outputen — kodgenerering, utkast, brainstorming — och de extra försöken är billiga. pass^k är rätt metrik när agenten agerar utan filter, vilket är vad ”agent” betyder. Att publicera den första där den andra gäller är den vanligaste överdriften i fältet, och τ-benchs egen headline är den ärliga versionen: gpt-4o på ungefär 61 % pass^1 i retail faller till ungefär 25 % vid pass^8.⁴

Nu udden i mina egna tal. pass^10 över mina tjugo uppgifter är 5.0 %: exakt en uppgift av tjugo löst på alla tio körningar. Den uppgiften är t19, ”Lyckades deploy 42?”, och här är två av de tio svaren som rubriken poängsatte som korrekta:

run 2  "To check if 'deploy.log' succeeded in deploying 42, I will list the file
        names in the working directory using the list_files function..."
run 8  "Yes, deploy 42 has successfully deployed. Deploying was successful for 41
        as well."

Det första svarar aldrig. Det andra lägger till ett påstående som är falskt — deploy 41 rullades tillbaka. Båda matchade /succe|yes/. Den enda uppgift som håller pass^10 över noll är en grader-artefakt, så den sanna siffran är noll, och inget aggregat hade visat mig det. Att samplea transkripten bakom din bäst poängsatta uppgift är där graders går för att dö.

Och ett tal till, det som avsnittet är uppkallat efter. Tio identiska utvärderingar — samma system, samma tjugo uppgifter, samma kod, inget ändrat utom seeds:

per-run correct: 5 2 5 5 8 5 8 5 4 5   ->  10 % .. 40 %,  mean 26.0 %,  sd 8.8 points

Ett spann på trettio punkter i ett system som inte ändrades. Om du kör din suite en gång före en release och en gång efter, ligger en ”förbättring” på åtta punkter inom det spannet och du kommer att ship it i tron att du orsakade den. Därför är det poolade intervallet ovan — 26.0 % [20.4, 32.5] — för smalt för att citeras på egen hand: det behandlar tvåhundra korrelerade trials som tvåhundra oberoende. Den ärliga sammanfattningen av en agent-utvärdering är ett medelvärde och en spridning över repeats, och nästan ingen publicerar det andra.

Rubriker skalar inte till öppna svar, så standardgreppet är att låta en modell betygsätta outputen. Det fungerar tillräckligt bra i frontier-skala för att vara default, och det har tre namngivna failure modes: position bias, verbosity bias och self-enhancement bias.⁵

Mät den innan du litar på den. Samma sextio svar — tre av de tio körningarna — labelades på tre sätt. Den mänskliga etiketten är min: jag läste alla sextio med de fem filerna öppna och tillämpade en skriven regel, pass if and only if the answer states the fact the question asked for and contains nothing contradicted by the files.

Judgen sa PASS sextio gånger av sextio. Den skulle ha rapporterat denna agent till 100 % accuracy på ett set där människan ger den 18 %. En judge utan discriminative power är inte ett brusigt instrument; den är en konstant funktion, och en konstant funktion ger ditt bästa system och ditt sämsta system samma poäng.

Prompting räddade den inte. Fyra varianter, samma sextio items:

Att byta ordning på de två etiketterna i instruktionen flyttade fyra verdicts. Det är en mätbar effekt och fel sorts effekt: judgen svarar på promptens form snarare än på svaret framför sig.

Den rena demonstrationen är parvis. Tjugo frågor, var och en med en uppenbart korrekt och en uppenbart fel kandidat, presenterade i båda ordningarna:

picked the FIRST option              40/40 = 100.0 %
order-consistent (same winner both ways)   0/20 = 0.0 %   [Wilson 0.0, 16.1]
picked the CORRECT answer            20/40 = 50.0 %

Den valde position A fyrtio gånger av fyrtio. De 50 % på korrekthet är inte partiell kompetens — det är aritmetik, eftersom det korrekta svaret sitter i position A på exakt hälften av trials. Konsistens definieras här som MT-Bench definierar den, ”the percentage of cases where a judge gives consistent results when swapping the order of two assistants”, vilket låter jämförelsen bli äpplen mot äpplen: GPT-4 får 65.0 % på det måttet, och few-shot prompting höjde det till 77.5 %.⁵ Min får noll.

Standardmitigeringen kommer också från den artikeln: ”call a judge twice by swapping the order of two answers and only declare a win when an answer is preferred in both orders.”⁵ Tillämpa det här och judgen producerar noll användbara verdicts från tjugo par — vilket är rätt utfall, och oändligt mycket bättre än tjugo självsäkra.

En metodologisk not värd mer än resultatet. Jag körde också ett verbosity-test: samma korrekta svar, en kopia utfylld med en mening på 36 ord som inte tillför något. Judgen föredrog den längre versionen i exakt 50 % av trials — vilket ser ut som avsaknad av verbosity bias och inte alls är det, eftersom en judge som alltid väljer position A får 50 % på vilken balanserad parning som helst. Du kan inte mäta en andra bias förrän den första är kontrollerad. Att byta positioner är inte en förfining att lägga till senare; det är det som gör varje annan mätning tolkbar.

Den ärliga reservationen: denna judge är en modell med en halv miljard parametrar, och ingen borde gradera med en sådan. Poängen är inte att judges är dåliga. Poängen är att talen ovan tog åtta minuter att producera, och utan dem hade den här judgens verdict i ett shipping-beslut varit 100 %.

Detta är den tredje och sista deklarerade Python-panelen i kursen, och skälet är var de offentliga talen kommer ifrån. lm-evaluation-harness täcker ”over 60 standard academic benchmarks for LLMs, with hundreds of subtasks and variants implemented” och är ”the backend for Hugging Face's popular Open LLM Leaderboard”; HELM, SWE-bench och τ-bench är Python-paket med Python-entry points.⁶ Att köra din modell mot en publicerad siffra betyder att köra deras kod, och den dag du vill jämföra med ett tal någon citerade är detta ekosystemet du är i:

lm_eval --model hf \
    --model_args pretrained=EleutherAI/gpt-j-6B \
    --tasks hellaswag \
    --device cuda:0 \
    --batch_size 8

Det andra skälet är att en mätning i det här kapitlet är omöjlig över HTTP. Contamination — att test-setet har läckt in i träningsdata — är felet som gör en offentlig benchmark tyst meningslös, och den skarpaste proben för det behöver modellens egen loss, som inget chat API returnerar. Det är Kapitel 8:s cross-entropy per token, riktad mot en fråga om minne:

def nll(text: str) -> float:
    """Mean negative log-likelihood per token, in nats."""
    ids = tok(text, return_tensors="pt").input_ids.to(model.device)
    with torch.no_grad():
        out = model(ids, labels=ids)
    return float(out.loss)

Tio meningspar: fem i varje crawl av webben sedan den fanns, fem skrivna för det här kapitlet i morse, var och en parad med en omformulerad version med samma innehåll.

Modellen blir fyra gånger mer överraskad av en mening skriven i morse än av en den har sett en miljon gånger, och omformulering kostar dubbelt så mycket på de kända — extrakostnaden är den del som memorerades snarare än förstods. Absolut loss blandar ihop memorisering med vanlig naturlighet, så gapet är den bättre statistiken och continuation-testet är ännu bättre. Ge den de första sex orden:

famous  "Permission is hereby granted, free of"
     -> "charge, to any person obtaining a copy of this software and associated
         documentation files (the "
famous  "All human beings are born free"
     -> "and equal in dignity and rights. The right to life, liberty, and security"
fresh   "All evaluation harnesses are born tiny"
     -> ", and the most common way to measure their size is by using a ruler."

Tre av de fem kända strängarna fortsatte ord-perfekt från sex ord; ingen av de fem färska gjorde det. Det är en modell med en halv miljard parametrar som reciterar MIT License. Om din benchmark finns på den offentliga webben, anta att den finns i weights. Det är också argumentet för hela kapitlet: ett golden set du skrev från dina egna data, hållit utanför varje repository som en crawler läser, är det enda test-set du kan vara säker på aldrig tränades på.

De är fortfarande värda att läsa, så länge du läser vad var och en mäter snarare än den enda siffra som sitter på den.

Ta tabellen snarare än någon rad. De agentiska benchmarks placerar alla människor långt över modeller, vilket är motsatsen till kunskaps-benchmarks och den bästa enradsammanfattningen av var fältet är; deras siffror åldras inom månader, så citera dem med datumet då du läste dem; och var och en mäter en uppgift som inte är din.

Accuracy är metriken du argumenterar om. Det här är de som avgör om saken shippas. Alla fyra faller ut ur de tvåhundra körningarna som redan mätts.

Kostnad per löst uppgift, inte per call. agenten kostar $0.001345 per försök och $0.005172 per faktiskt löst uppgift — 3.85 gånger mer, eftersom tre fjärdedelar av försöken inte producerar något. Latency beter sig likadant: 1,213 ms per försök, 4,667 ms per löst uppgift. Varje retry, varje omfråga, varje övergiven trajectory finns i det andra talet och är osynlig i det första.

En diagnostik som slår accuracy. I 123 av 200 försök svarade agenten utan att anropa ett enda verktyg — den gissade i stället för att titta. Uppdelat på det:

answered without reading anything   8/123  =  6.5 %  [3.3, 12.3]
answered after reading something   44/77   = 57.1 %  [46.0, 67.6]

Intervallen kommer inte i närheten av att röra vid varandra. Det är värt mer än aggregatet 26 %, eftersom det namnger det som ska fixas — modellen misslyckas inte med att resonera, den misslyckas med att titta — och fixen finns i harness, inte i modellen. En reservation som det här kapitlet är skyldigt sina egna standarder: de två grupperna är olika uppgifter, inte samma uppgifter parade, så en del av gapet kan vara att den hoppar över verktygen just på de frågor den tycker är svåra. Splitten är en diagnostik, inte ett kausalt påstående.

Human intervention rate är metriken en köpare frågar efter först: vilken andel av körningarna stannade vid ett godkännande, en guardrail eller en handoff. Kapitel 23:s typade avbrott gör den räkningsbar, och räknad per uppgiftstyp och per vecka är den det som skiljer en agent som lär sig sitt jobb från en som tyst blir en kö.

Abandonment är den som ingen offline suite kan se: användaren som läste svaret, stängde fliken och gjorde uppgiften själv. Offline-utvärdering är en gate; produktionsutvärdering är ett kontinuerligt sample av verklig trafik, poängsatt med samma grader plus dessa fyra.

Och en regel ärvd från Kapitel 17: gör aldrig assert på exakt output. Gör assert på egenskaper — giltig JSON, korrekt schema, rätt verktyg anropat, ett tal inom tolerans, en required substring närvarande. Kolumnen exact-match högst upp i kapitlet är vad som händer när den regeln bryts.

Att utvärdera en leverantör handlar inte bara om accuracy, och detta är andra halvan av kursens etik, med egen rubrik snarare än en bilaga.

Mät biasen, anta den inte. Vad du än tror om en modells beteende på namn, dialekter, kön eller nationaliteter är det en mätbar egenskap hos din pipeline, och instrumentet är det du redan har: ta ditt golden set, variera bara attributet, jämför parat. HELM finns just för att accuracy ensam rapporterades där bias, toxicitet, calibration och robusthet också gick att avgöra.⁸ En leverantörs model card är en startpunkt, inte bevis om dina inputs.

Contamination är också en leverantörsfråga. Proben ovan är skälet att fråga vad en publicerad siffra mättes på, och när modellens data cuttades.

Retention, träning och residency, läst den 7 september 2026. Dessa ändras, så anteckna datumet bredvid svaret. Anthropics policysida säger: ”By default, we will not use your inputs or outputs from our commercial products (e.g. Claude for Work, Anthropic API, Claude Gov, etc.) to train our models”, med undantag för innehåll du uttryckligen skickar som feedback, vilket lagras ”for up to 5 years”.¹⁶ OpenAI:s dokumentation för datakontroller säger att ”data sent to the OpenAI API is not used to train or improve OpenAI models (unless you explicitly opt in to share data with us)”, beskriver trettio dagars standardretention för abuse-monitoring logs och erbjuder Zero Data Retention, som ”excludes customer content from abuse monitoring logs”, plus konfigurerbar data residency över en lista med regioner.¹⁷

Fyra frågor att få skriftligt före första produktions-callet, eftersom var och en har en annan ägare: används mina data för träning; hur länge behålls de och av vem; var behandlas och lagras de; och vad händer med allt detta om jag använder en reseller, gateway eller aggregator i stället för leverantören direkt. Den sista är där de flesta överraskningarna bor, och ingen benchmark kommer att berätta det för dig.

Du har nu instrumentet: ett golden set du äger, ett intervall på varje tal, ett parat test för varje jämförelse, pass^k för körningarna du inte visade någon, en uppmätt judge och en probe för om ett offentligt score betyder något. Kapitel 23:s slutpåstående kan nu kontrolleras i stället för att hävdas — en harness gör en agent styrbar, inte korrekt — och att kontrollera det tog tvåhundra körningar och åtta minuter.

Det finns en egenskap hos en agent som inget av detta mäter, och det är den som gör att folk får sparken.

Varje uppgift i det här kapitlets golden set skrevs av mig, och varje fil agenten läste skrevs av mig. Ingenting i den katalogen försökte göra något. Ändra en rad i en fil som agenten instrueras att läsa — en rad som slutar med en instruktion adresserad till vad som än läser den härnäst — och agenten som fick 26 % kommer att följa den med samma verktyg, samma permissions och samma rena trace, och varje tal i det här kapitlet kommer att ligga kvar exakt där det är. En utvärderings-suite mäter hur ofta ett system når ditt mål. Den mäter inte hur lätt någon annan kan ersätta det med sitt.

Kapitel 30 är det: prompt injection, den dödliga trifektan av privata data, opålitligt innehåll och extern kommunikation, och vad det kostar att ge en agent verkliga permissions. Det öppnar med observationen detta kapitel har undvikit — att samma godkända poäng är kompatibel med en agent som gör exakt vad en angripare skrev i en fil den blev tillsagd att läsa.

Varje tal ovan producerades på en maskin och inget av det rörde en betald endpoint. agenten är Kapitel 23:s loop med två av sina fyra verktyg över en katalog med fem filer; modellen bakom porten är Qwen/Qwen2.5-0.5B-Instruct, exponerad via en liten server med samma form som en chat completions-endpoint precis som i Kapitel 23, men i half precision på en consumer GPU i stället för det kapitlets CPU. Kostnader använder Kapitel 16:s priser — $2.00 per miljon input tokens och $12.00 per miljon output — applicerade på uppmätta token counts. De upprepade körningarna använder temperature 0.7 med fasta seeds så hela setet reproduceras; fyrarmstabellen är greedy. Intervall är Wilson på 95 %, parade jämförelser är tvåsidiga exakta teckentest över discordant pairs; Wilson-intervallet är Kapitel 4:s och det exakta parade teckentestet Kapitel 15:s, båda återanvända oförändrade. De mänskliga labels är mina, applicerade på sextio svar under den skrivna regeln citerad i texten. Läs varje storlek här som en egenskap hos en modell med en halv miljard parametrar och varje metod som överförbar: en större modell flyttar alla tal uppåt och flyttar inget av instrumenten.