LLM-evaluering: Fra offentlige benchmarks til dit golden set

Næsten enhver diskussion om evaluering er to personer, der måler forskellige ting. Der er tre projekter, og de deler ikke instrument.

Forvirringen er dyr i én retning. Et leaderboard fortæller dig, at en model er stærk til ræsonnement på kandidatniveau; det kan ikke fortælle dig, om den vil route dine supporttickets. Og en applikationsevaluering, der scorer ét svar per input, kan slet ikke se en agent, fordi en agent har en distribution af forløb, og ét svar er en enkelt sample fra den. Kapitel 22 navngav den tredje række og lod den stå tom: performance-målet, den ene del af en agents specifikation, som teams skriver ned sidst eller aldrig.

Rækkefølgen betyder også noget, og leverandøren, der sælger dig modellen, siger det samme. OpenAI's agent-guide reducerer modelvalg til tre trin, i denne rækkefølge: »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«.¹ Evaluering kommer først, fordi trin to og tre er meningsløse uden et tal.

Et golden set er en liste af inputs, hver med svaret skrevet ned, og en grader, der afgør, om et output matcher. Det er kedeligt, det er lille, og det er den eneste artefakt i dette kapitel, som er din. Det, der bygges her, har tyve opgaver over en mappe med fem filer — ikke kapitel 23's tre, så svarene er ikke de samme svar — og graderen skrives, før agenten kører:

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
];

To egenskaber bærer vægten. Listen mustNot findes, fordi en model, der nævner tre filer inklusive den rigtige, ikke har svaret. Og answer er skrevet i prosa såvel som i mønstre, fordi både et menneske og en judge får brug for den senere — og at skrive den samme kendsgerning to gange i to notationer er sådan, du opdager, at du ikke var enig med dig selv om, hvad opgaven var.

Nu tabellen, der afgør det. Fire kandidatsystemer, de samme tyve opgaver, accuracy med sit interval og de to kolonner, som en ren accuracy-tabel altid skjuler:

Læs intervallerne før vinderen. Arm B's kørsler går fra 11 % til 47 %; arm A's fra 3 % til 30 %. De overlapper over størstedelen af deres længde, hvilket er kapitel 4's fund, der ankommer præcis der, hvor det blev lovet: tyve cases kan ikke rangordne fire systemer. Kapitel 15 skærpede dette ved i stedet at stille det parrede spørgsmål — blandt de cases hvor to arme er uenige, hvor skæv er fordelingen? — fordi sættets fælles sværhedsgrad annulleres. Her er hvert 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

Ikke én af de seks sammenligninger er etableret. Den bedste arm slår armen helt uden værktøjer med femten point, og det hviler på tre diskordante cases. Tyve cases viser en mekanisme og kan ikke vælge en leverandør; at sige det modsatte i et møde er sådan, en dårlig model bliver købt.

Der er én ting, tabellen etablerer, og det er kolonnen, ingen tager med. Arm D koster tretten gange arm B per løst opgave, fordi sampling af tre forløb og valg af det modale svar tredobler regningen, uanset om det tredobler accuracy. Accuracy-tabeller, der udelader omkostning, gør den afvejning usynlig.

Nu fundet, der ændrer, hvordan du læser hvert benchmark, du nogensinde kommer til at se. Tag de samme to hundrede transskriptioner — tyve opgaver, ti kørsler, ikke én token regenereret — og scor dem på tre måder:

Nul, tretten, seksogtyve. Systemet ændrede sig ikke. Graderen gjorde. Exact match returnerer nul, ikke fordi agenten er ubrugelig, men fordi intet fritekstsvar nogensinde er byte-identisk med en reference: det måler formatering og rapporterer det som capability.

Det er ikke en kuriositet, det er en mekanisme, og den har et navn. En hard-cutoff metric scorer en opgave alt-eller-intet over flere del-fakta, så den sammensætter effekten. Opgave t12 beder om tre statuskoder på én gang. Over de ti kørsler:

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

Hvert faktum er rigtigt omkring tre fjerdedele af tiden; at kræve alle tre på én gang halverer scoren, og $0.77^3 = 0.457$ er tæt nok på den målte 0.50 til at vise, hvor faldet kom fra. Generalisér:

Læs 0.90-rækken mod 0.95-rækken ved $k = 10$: en forbedring per faktum på fem point bliver til femogtyve point på konjunktionen. Der skete intet diskontinuert med modellen. En glat kurve læst gennem en alt-eller-intet-metrik ligner et spring — hvilket præcis er det argument, Schaeffer, Miranda og Koyejo fremførte om emergent abilities, og som kapitel 10 udsatte til her.² Deres audit fandt, at højst 5 af BIG-Benchs 39 foretrukne metrics overhovedet viser emergence, hvor to diskontinuerte metrics står for over 92 % af de påståede tilfælde.

Så disciplinen, på én linje: et spring i en graf er bevis om metrikken, indtil andet er vist. Før du tror på, at en capability opstod, så plot de samme kørsler med en metrik, der giver delvis kredit, og se, om klippen overlever.

Der er en andenordens version af dette, som Kalai og kolleger argumenterer for skader opstrøms: benchmarks scoret som rigtigt-eller-forkert belønner gæt frem for at sige »jeg ved det ikke«, så en model optimeret mod dem lærer at gætte. Deres foreslåede løsning er ikke endnu et hallucination benchmark, men »modifying the scoring of existing benchmarks that are misaligned but dominate leaderboards«.³ Dit golden set har samme håndtag, og det er én linje: beslut, om abstention tæller som failure eller som sin egen kategori. De fleste beslutter det aldrig, så det tæller stiltiende som failure, og systemet, de shipper, gætter.

Alt indtil nu scorede ét forsøg per opgave. En agent er ikke ét forsøg. Kapitel 17 etablerede, at du ikke har determinisme selv ved temperature nul, så samme input producerer en distribution af forløb, og et benchmark, der kører hver opgave én gang, rapporterer én sample fra den.

τ-benchs bidrag er metrikken til det. Paperet definerer den klart: »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 hver opgave $n$ gange, tæl de $c$ succeser, og de unbiased estimatorer er:

Den anden er den velkendte pass@k fra kodegenerering: chancen for, at mindst ét af $k$ forsøg lykkes. Sæt dem side om side på de samme målte optællinger, og de bevæger sig i modsatte retninger:

Samme kørsler, samme grader, samme tyve opgaver. Den ene kolonne siger, at systemet forbedres med flere forsøg, og den anden siger, at det bliver værre, og begge har ret, fordi de svarer på forskellige spørgsmål. pass@k er den rigtige metrik, når et menneske filtrerer outputtet — kodegenerering, udkast, brainstorming — og de ekstra forsøg er billige. pass^k er den rigtige metrik, når agenten handler uden filter, hvilket er det, »agent« betyder. At offentliggøre den første, hvor den anden gælder, er den mest almindelige overdrivelse i feltet, og τ-benchs egen overskrift er den ærlige version: gpt-4o på cirka 61 % pass^1 i retail falder til cirka 25 % ved pass^8.⁴

Nu brodden i mine egne tal. pass^10 over mine tyve opgaver er 5.0 %: præcis én opgave ud af tyve løst på alle ti kørsler. Den opgave er t19, »Lykkedes deploy 42?«, og her er to af de ti svar, rubrikken scorede som korrekte:

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ørste svarer aldrig. Det andet tilføjer en påstand, der er falsk — deploy 41 blev rolled back. Begge matchede /succe|yes/. Den eneste opgave, der holder pass^10 over nul, er en grader-artefakt, så det sande tal er nul, og intet aggregat ville have vist mig det. Sampling af transskriptionerne bag din bedst scorende opgave er dér, graders går hen for at dø.

Og endnu et tal, det som dette afsnit er opkaldt efter. Ti identiske evalueringer — samme system, samme tyve opgaver, samme kode, intet ændret ud over seeds:

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

Et spænd på tredive point på et system, der ikke ændrede sig. Hvis du kører din suite én gang før en release og én gang efter, ligger en »forbedring« på otte point inde i det spænd, og du shipper den i den tro, at du forårsagede den. Det er derfor, det pooled interval ovenfor — 26.0 % [20.4, 32.5] — er for snævert til at citere alene: det behandler to hundrede korrelerede forsøg som to hundrede uafhængige. Den ærlige opsummering af en agent-evaluering er et gennemsnit og en spredning på tværs af gentagelser, og næsten ingen offentliggør det andet.

Rubrikker skalerer ikke til åbne svar, så standardgrebet er at få en model til at bedømme outputtet. Det virker godt nok på frontier-skala til at være default, og det har tre navngivne failure modes: position bias, verbosity bias og self-enhancement bias.⁵

Mål den, før du stoler på den. De samme tres svar — tre af de ti kørsler — blev labellet på tre måder. Den menneskelige label er min: jeg læste alle tres med de fem filer åbne og anvendte én skrevet regel, pass hvis og kun hvis svaret angiver det faktum, spørgsmålet bad om, og ikke indeholder noget, der modsiges af filerne.

Judgen sagde PASS tres gange ud af tres. Den ville have rapporteret denne agent til 100 % accuracy på et sæt, hvor mennesket scorer den til 18 %. En judge uden diskriminativ kraft er ikke et støjende instrument; det er en konstant funktion, og en konstant funktion giver dit bedste system og dit værste system samme score.

Prompting reddede den ikke. Fire varianter, samme tres items:

At bytte rækkefølgen af de to labels i instruktionen flyttede fire verdicts. Det er en målbar effekt, og det er den forkerte slags effekt: judgen reagerer på formen af prompt snarere end på svaret foran den.

Den rene demonstration er parvis. Tyve spørgsmål, hver med én klart korrekt og én klart forkert kandidat, præsenteret i begge rækkefølger:

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 valgte position A fyrre gange ud af fyrre. De 50 % på korrekthed er ikke delvis kompetence — det er aritmetik, fordi det korrekte svar står i position A på præcis halvdelen af forsøgene. Konsistens her er defineret, som MT-Bench definerer det, »the percentage of cases where a judge gives consistent results when swapping the order of two assistants«, hvilket gør sammenligningen apples to apples: GPT-4 scorer 65.0 % på det mål, og few-shot prompting løftede den til 77.5 %.⁵ Min scorer nul.

Standardafhjælpningen er også fra det paper: »call a judge twice by swapping the order of two answers and only declare a win when an answer is preferred in both orders.«⁵ Anvend den her, og judgen producerer nul brugbare verdicts fra tyve par — hvilket er det korrekte udfald og uendeligt bedre end tyve selvsikre.

En metodisk note, der er mere værd end resultatet. Jeg kørte også en verbosity-test: samme korrekte svar, én kopi polstret med en sætning på 36 ord, der ikke tilføjer noget. Judgen foretrak den længere version på præcis 50 % af forsøgene — hvilket ligner et fravær af verbosity bias og slet ikke er det, fordi en judge, der altid vælger position A, scorer 50 % på enhver balanceret parring overhovedet. Du kan ikke måle en anden bias, før den første er kontrolleret. At bytte positioner er ikke en forfinelse, man tilføjer senere; det er det, der gør enhver anden måling fortolkelig.

Det ærlige forbehold: denne judge er en model med en halv milliard parametre, og ingen bør grade med sådan en. Pointen er ikke, at judges er dårlige. Den er, at tallene ovenfor kostede otte minutter at producere, og uden dem ville denne judges verdict på en shipping-beslutning have været 100 %.

Dette er kursets tredje og sidste erklærede Python-panel, og årsagen er dér, de offentlige tal kommer fra. lm-evaluation-harness dækker »over 60 standard academic benchmarks for LLMs, with hundreds of subtasks and variants implemented« og er »the backend for Hugging Face's popular Open LLM Leaderboard«; HELM, SWE-bench og τ-bench er Python-pakker med Python-entry points.⁶ At køre din model mod et offentliggjort tal betyder at køre deres kode, og den dag du vil sammenligne med et tal, nogen citerede, er det økosystemet, du er i:

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

Den anden grund er, at én måling i dette kapitel er umulig over HTTP. Contamination — at testsættet er lækket ind i træningsdata — er den failure, der gør et offentligt benchmark stille og roligt meningsløst, og den skarpeste probe for det har brug for modellens eget loss, som ingen chat API returnerer. Det er kapitel 8's cross-entropy per token, rettet mod et spørgsmål om hukommelse:

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)

Ti sætningspar: fem i enhver crawl af nettet, siden det fandtes, fem skrevet til dette kapitel i morges, hver parret med en omformuleret version med samme indhold.

Modellen bliver fire gange mere overrasket over en sætning skrevet i morges end over en, den har set en million gange, og omformulering koster dobbelt så meget på de berømte — den ekstra omkostning er den del, der blev memoriseret snarere end forstået. Absolut loss sammenblander memorisering med almindelig naturlighed, så gap er den bedre statistik, og continuation-testen er endnu bedre. Giv den de første seks ord:

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 af de fem berømte strenge fortsatte ordperfekt fra seks ord; ingen af de fem friske gjorde. Det er en model med en halv milliard parametre, der reciterer MIT License. Hvis dit benchmark ligger på det offentlige web, så antag, at det er i vægtene. Det er også argumentet for hele kapitlet: et golden set, du skrev fra dine egne data og holdt ude af ethvert repository, en crawler læser, er det eneste testsæt, du kan være sikker på aldrig blev trænet på.

De er stadig værd at læse, så længe du læser, hvad hver enkelt måler, frem for det ene tal, der er sat på den.

Tag tabellen frem for en enkelt række. De agentic benchmarks placerer alle mennesker langt over modeller, hvilket er det modsatte af vidensbenchmarks og den bedste én-linjes opsummering af, hvor feltet er; deres tal ældes inden for måneder, så citér dem med datoen, du læste dem; og hver eneste måler en opgave, der ikke er din.

Accuracy er metrikken, du diskuterer. Disse er dem, der afgør, om tingen shipper. Alle fire falder ud af de to hundrede kørsler, der allerede er målt.

Omkostning per løst opgave, ikke per call. Agenten koster $0.001345 per forsøg og $0.005172 per faktisk løst opgave — 3.85 gange mere, fordi tre fjerdedele af forsøgene ikke producerer noget. Latency opfører sig på samme måde: 1,213 ms per forsøg, 4,667 ms per løst opgave. Hvert retry, hvert re-ask, hvert forladt forløb ligger i det andet tal og er usynligt i det første.

En diagnostik, der slår accuracy. I 123 af 200 forsøg svarede agenten uden at kalde et eneste værktøj — den gættede i stedet for at kigge. Split 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]

Intervallerne er ikke i nærheden af at røre hinanden. Det er mere værd end de aggregerede 26 %, fordi det navngiver det, der skal fixes — modellen fejler ikke i at ræsonnere, den fejler i at kigge — og fixet er i harness, ikke modellen. Ét forbehold, som dette kapitel skylder sine egne standarder: de to grupper er forskellige opgaver, ikke de samme opgaver parret, så en del af gap'et kan være, at den springer værktøjerne over netop på de spørgsmål, den finder svære. Splittet er en diagnostik, ikke en kausal påstand.

Human intervention rate er den metrik, en køber spørger efter først: hvilken andel af kørsler stoppede ved en approval, en guardrail eller et handoff. Kapitel 23's typede interruptions gør det tælleligt, og talt per opgavetype og per uge er det dét, der adskiller en agent, der lærer sit job, fra en, der stille bliver til en kø.

Abandonment er den, ingen offline suite kan se: brugeren, der læste svaret, lukkede fanen og udførte opgaven selv. Offline-evaluering er en gate; produktionsevaluering er en kontinuerlig sample af rigtig trafik, scoret på samme grader plus disse fire.

Og en regel arvet fra kapitel 17: assert aldrig på exact output. Assert på egenskaber — valid JSON, korrekt schema, det rigtige værktøj kaldt, et tal inden for tolerance, en påkrævet substring til stede. Exact-match-kolonnen øverst i dette kapitel er det, der sker, når den regel brydes.

At evaluere en leverandør handler ikke kun om accuracy, og dette er anden halvdel af kursets etik, med sin egen overskrift frem for et appendiks.

Mål bias, antag den ikke. Hvad end du tror om en models adfærd på navne, dialekter, køn eller nationaliteter, er det en målbar egenskab ved din pipeline, og instrumentet er det, du allerede har: tag dit golden set, varier kun attributten, sammenlign parret. HELM findes præcis fordi accuracy alene blev rapporteret, hvor bias, toxicity, calibration og robustness også kunne afgøres.⁸ En leverandørs model card er et udgangspunkt, ikke bevis om dine inputs.

Contamination er også et leverandørspørgsmål. Proben ovenfor er grunden til at spørge, hvad et offentliggjort tal blev målt på, og hvornår modellens data blev cuttet.

Retention, træning og residency, læst 7. september 2026. Disse ændrer sig, så noter datoen ved siden af svaret. Anthropics policy-side siger: »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 undtagelse af indhold, du eksplicit indsender som feedback, som gemmes »for up to 5 years«.¹⁶ OpenAI's data controls-dokumentation siger, at »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 en default retention på tredive dage for abuse-monitoring logs og tilbyder Zero Data Retention, som »excludes customer content from abuse monitoring logs«, plus konfigurerbar data residency på tværs af en liste af regioner.¹⁷

Fire spørgsmål at få på skrift før det første produktionscall, fordi hvert har en forskellig ejer: bruges mine data til træning; hvor længe gemmes de og af hvem; hvor behandles og lagres de; og hvad sker der med alt det, hvis jeg bruger en reseller, en gateway eller en aggregator i stedet for provideren direkte. Det sidste er dér, de fleste overraskelser bor, og intet benchmark vil fortælle dig det.

Du har nu instrumentet: et golden set, du ejer, et interval på hvert tal, en parret test for hver sammenligning, pass^k for de kørsler du ikke viste nogen, en målt judge og en probe for, om en offentlig score betyder noget. Kapitel 23's afsluttende påstand kan nu tjekkes i stedet for at blive hævdet — et harness gør en agent styrbar, ikke korrekt — og at tjekke det tog to hundrede kørsler og otte minutter.

Der er én egenskab ved en agent, som intet af det måler, og det er den, folk bliver fyret for.

Hver opgave i dette kapitels golden set blev skrevet af mig, og hver fil agenten læste, blev skrevet af mig. Intet i den mappe prøvede at gøre noget. Ændr én linje i én fil, agenten får besked på at læse — en linje, der ender med en instruktion adresseret til hvad end der læser den næste gang — og agenten, der scorede 26 %, vil følge den med de samme værktøjer, de samme tilladelser og den samme rene trace, og hvert tal i dette kapitel vil blive stående præcis, hvor det er. En evaluation suite måler, hvor ofte et system når dit mål. Den måler ikke, hvor let en anden kan erstatte det med deres.

Kapitel 30 er det: prompt injection, den dødelige trifecta af private data, untrusted content og external communication, og hvad det koster at give en agent rigtige permissions. Det åbner med den observation, dette kapitel har undgået — at den samme passing score er kompatibel med en agent, der gør præcis det, en angriber skrev i en fil, den fik besked på at læse.

Hvert tal ovenfor blev produceret på én maskine, og intet af det ramte et betalt endpoint. Agenten er kapitel 23's loop med to af dens fire værktøjer over en fem-filers mappe; modellen bag porten er Qwen/Qwen2.5-0.5B-Instruct, eksponeret gennem en lille server med samme form som et chat completions-endpoint præcis som i kapitel 23, men i half precision på én consumer GPU snarere end kapitlets CPU. Omkostninger bruger kapitel 16's satser — $2.00 per million input tokens og $12.00 per million output — anvendt på målte token-optællinger. De gentagne kørsler bruger temperature 0.7 med faste seeds, så hele sættet kan reproduceres; fire-arms-tabellen er greedy. Intervaller er Wilson ved 95 %, parrede sammenligninger er tosidede eksakte fortegnstests over de diskordante par; Wilson-intervallet er kapitel 4's og den eksakte parrede fortegnstest er kapitel 15's, begge genbrugt uændret. De menneskelige labels er mine, anvendt på tres svar under den skrevne regel citeret i teksten. Læs hver størrelsesorden her som en egenskab ved en model med en halv milliard parametre og hver metode som overførbar: en større model flytter alle tallene op og flytter ingen af instrumenterne.