LLM-evaluatie: van openbare benchmarks naar je golden set

Bijna elke discussie over evaluatie is twee mensen die verschillende dingen meten. Er zijn drie projecten en ze delen geen instrument.

De verwarring is in één richting duur. Een leaderboard vertelt je dat een model sterk is in redeneervragen op masterniveau; het kan je niet vertellen of het je supporttickets zal routeren. En een applicatie-evaluatie die één antwoord per input scoort, kan een agent helemaal niet zien, omdat een agent een verdeling van trajecten heeft en één antwoord daar één sample uit is. Hoofdstuk 22 benoemde die derde rij en liet hem leeg: de prestatiemaat, het ene onderdeel van de specificatie van een agent dat teams als laatste opschrijven of helemaal nooit.

De volgorde doet er ook toe, en de vendor die je het model verkoopt zegt dat zelf. OpenAI's agent-gids reduceert modelselectie tot drie stappen, in deze volgorde: "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".¹ Evaluatie komt eerst, omdat stap twee en drie zonder getal betekenisloos zijn.

Een golden set is een lijst met inputs, elk met het antwoord erbij geschreven, en een grader die beslist of een output overeenkomt. Het is saai, het is klein, en het is het enige artefact in dit hoofdstuk dat van jou is. De set die hier wordt gebouwd heeft twintig taken over een map met vijf bestanden — niet de drie uit Hoofdstuk 23, dus de antwoorden zijn niet dezelfde antwoorden — en de grader wordt geschreven voordat de agent draait:

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

Twee eigenschappen dragen de last. De lijst mustNot bestaat omdat een model dat drie bestanden noemt waaronder het juiste, niet heeft geantwoord. En answer is zowel in proza als in patronen geschreven, omdat een mens en een judge het later allebei nodig hebben — en hetzelfde feit twee keer in twee notaties opschrijven is hoe je ontdekt dat je het niet met jezelf eens was over wat de taak was.

Nu de tabel die beslist. Vier kandidaatsystemen, dezelfde twintig taken, accuracy met interval, en de twee kolommen die een tabel met alleen accuracies altijd verbergt:

Lees de intervallen vóór de winnaar. Arm B loopt van 11% tot 47%; arm A van 3% tot 30%. Ze overlappen over het grootste deel van hun lengte, precies de bevinding uit Hoofdstuk 4 op de plek waar die was beloofd: twintig cases kunnen vier systemen niet rangschikken. Hoofdstuk 15 maakte dit scherper door in plaats daarvan de gepaarde vraag te stellen — van de cases waarin twee armen verschillen, hoe scheef is de verdeling? — omdat de gedeelde moeilijkheid van de set wegvalt. Hier is elk paar:

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

Geen van de zes vergelijkingen is vastgesteld. De beste arm verslaat de arm zonder tools met vijftien punten, en dat rust op drie discordante cases. Twintig cases tonen een mechanisme en kunnen geen leverancier kiezen; in een vergadering iets anders zeggen is hoe een slecht model wordt gekocht.

Er is één ding dat deze tabel wel vaststelt, en het is de kolom die niemand opneemt. Arm D kost dertien keer zoveel als arm B per opgeloste taak, omdat drie trajecten samplen en het modale antwoord nemen de rekening verdrievoudigt, of het de accuracy nu verdrievoudigt of niet. Accuracy-tabellen die kosten weglaten maken die afweging onzichtbaar.

Nu de bevinding die verandert hoe je elke benchmark leest die je ooit zult zien. Neem dezelfde tweehonderd transcripts — twintig taken, tien runs, niet één token opnieuw gegenereerd — en scoor ze op drie manieren:

Nul, dertien, zesentwintig. Het systeem veranderde niet. De grader veranderde. Exact match geeft nul terug, niet omdat de agent nutteloos is, maar omdat geen enkel vrijetekstantwoord ooit byte-identiek is aan een referentie: het meet opmaak en rapporteert dat als capability.

Dat is geen curiositeit, het is een mechanisme, en het heeft een naam. Een hard-cutoff metric scoort een taak alles-of-niets over meerdere deelfeiten, en componeert dus. Taak t12 vraagt tegelijk naar drie statuscodes. Over de tien runs:

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

Elk feit is ongeveer driekwart van de tijd goed; alle drie tegelijk eisen halveert de score, en $0.77^3 = 0.457$ ligt dicht genoeg bij de gemeten 0.50 om te laten zien waar de daling vandaan kwam. Generaliseer:

Lees de rij 0.90 naast de rij 0.95 bij $k = 10$: een per-fact verbetering van vijf punten wordt vijfentwintig punten op de conjunctie. Er gebeurde niets discontinu met het model. Een gladde curve die door een alles-of-niets metric wordt gelezen, lijkt op een sprong — precies het argument dat Schaeffer, Miranda en Koyejo maakten over emergent abilities, en dat Hoofdstuk 10 naar hier doorschoof.² Hun audit vond dat hoogstens 5 van de 39 voorkeursmetrics van BIG-Bench überhaupt emergence tonen, waarbij twee discontinue metrics verantwoordelijk zijn voor meer dan 92% van de geclaimde gevallen.

Dus de discipline, in één zin: een sprong in een grafiek is bewijs over de metric totdat het tegendeel is aangetoond. Voordat je gelooft dat er een capability verscheen, plot je dezelfde runs met een metric die gedeeltelijke credit geeft en kijk je of de afgrond blijft bestaan.

Er is een tweede-ordeversie hiervan waarvan Kalai en collega's betogen dat die stroomopwaarts schade aanricht: benchmarks die als goed-of-fout worden gescoord belonen gokken boven zeggen "ik weet het niet", dus een model dat daarop wordt geoptimaliseerd leert gokken. Hun voorgestelde oplossing is niet nog een hallucination benchmark, maar "modifying the scoring of existing benchmarks that are misaligned but dominate leaderboards".³ Je golden set heeft dezelfde hendel, en die is één regel: bepaal of een abstention telt als failure of als eigen categorie. De meeste mensen beslissen dat nooit, dus telt het stilzwijgend als failure, en het systeem dat ze shippen gokt.

Tot nu toe scoorde alles één poging per taak. Een agent is niet één poging. Hoofdstuk 17 stelde vast dat je zelfs bij temperatuur nul geen determinisme hebt, dus dezelfde input produceert een verdeling van trajecten en een benchmark die elke taak één keer draait rapporteert één sample daaruit.

De bijdrage van τ-bench is de metric daarvoor. Het paper definieert die helder: "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."⁴ Draai elke taak $n$ keer, tel de $c$ successen, en de onbevooroordeelde schatters zijn:

De tweede is de vertrouwde pass@k uit codegeneratie: de kans dat minstens één van $k$ pogingen slaagt. Zet ze naast elkaar op dezelfde gemeten aantallen en ze bewegen in tegengestelde richting:

Dezelfde runs, dezelfde grader, dezelfde twintig taken. De ene kolom zegt dat het systeem verbetert met meer pogingen en de andere zegt dat het slechter wordt, en allebei kloppen, omdat ze verschillende vragen beantwoorden. pass@k is de juiste metric wanneer een mens de output filtert — codegeneratie, drafts, brainstormen — en de extra pogingen goedkoop zijn. pass^k is de juiste metric wanneer de agent zonder filter handelt, wat precies is wat "agent" betekent. De eerste publiceren waar de tweede geldt, is de meest voorkomende overdrijving in dit vakgebied, en τ-bench's eigen headline is de eerlijke versie: gpt-4o op ongeveer 61% pass^1 op retail daalt naar ongeveer 25% bij pass^8.⁴

Nu de angel in mijn eigen cijfers. pass^10 over mijn twintig taken is 5.0%: exact één taak van de twintig opgelost op alle tien runs. Die taak is t19, "Did deploy 42 succeed?", en hier zijn twee van de tien antwoorden die de rubric als correct scoorde:

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."

Het eerste antwoordt nooit. Het tweede voegt een claim toe die onwaar is — deploy 41 was rolled back. Beide matchten /succe|yes/. De enige taak die pass^10 boven nul houdt is een grader-artefact, dus het echte cijfer is nul, en geen aggregate had me dat laten zien. De transcripts achter je best scorende taak samplen is waar graders gaan sterven.

En nog één getal, het getal waar deze sectie naar is vernoemd. Tien identieke evaluaties — hetzelfde systeem, dezelfde twintig taken, dezelfde code, niets veranderd behalve de seeds:

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

Een bereik van dertig punten op een systeem dat niet veranderde. Als je je suite één keer vóór een release draait en één keer erna, valt een "verbetering" van acht punten binnen die spreiding en ship je die in de overtuiging dat jij hem hebt veroorzaakt. Daarom is het gepoolde interval hierboven — 26.0% [20.4, 32.5] — te smal om op zichzelf te citeren: het behandelt tweehonderd gecorreleerde trials als tweehonderd onafhankelijke. De eerlijke samenvatting van een agent-evaluatie is een gemiddelde en een spreiding over herhalingen, en bijna niemand publiceert dat tweede.

Rubrics schalen niet naar open antwoorden, dus de standaardzet is om een model de output te laten beoordelen. Op frontier-schaal werkt dat goed genoeg om de default te zijn, en het heeft drie benoemde failure modes: position bias, verbosity bias en self-enhancement bias.⁵

Meet het voordat je het vertrouwt. Dezelfde zestig antwoorden — drie van de tien runs — kregen op drie manieren een label. Het menselijke label is van mij: ik las alle zestig met de vijf bestanden open en paste één geschreven regel toe, pass als en alleen als het antwoord het feit noemt waar de vraag om vroeg en niets bevat dat door de bestanden wordt tegengesproken.

De judge zei PASS zestig keer van de zestig. Hij zou deze agent rapporteren op 100% accuracy op een set waarop de mens hem op 18% scoort. Een judge zonder onderscheidend vermogen is geen lawaaiig instrument; het is een constante functie, en een constante functie geeft je beste systeem en je slechtste systeem dezelfde score.

Prompting redde het niet. Vier varianten, dezelfde zestig items:

De volgorde van de twee labels in de instructie omwisselen verplaatste vier oordelen. Dat is een meetbaar effect en het verkeerde soort effect: de judge reageert op de vorm van de prompt in plaats van op het antwoord dat voor hem ligt.

De schone demonstratie is pairwise. Twintig vragen, elk met één duidelijk correcte en één duidelijk foute kandidaat, gepresenteerd in beide volgorden:

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 %

Hij koos positie A veertig keer van de veertig. De 50% op correctheid is geen gedeeltelijke competentie — het is rekenkunde, omdat het correcte antwoord in precies de helft van de trials op positie A staat. Consistency is hier gedefinieerd zoals MT-Bench die definieert, "the percentage of cases where a judge gives consistent results when swapping the order of two assistants", waardoor de vergelijking appels met appels wordt: GPT-4 scoort 65.0% op die maat, en few-shot prompting tilde dat naar 77.5%.⁵ Die van mij scoort nul.

De standaardmitigatie komt ook uit dat 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."⁵ Pas dat hier toe en de judge produceert nul bruikbare oordelen uit twintig paren — wat de juiste uitkomst is, en oneindig veel beter dan twintig zelfverzekerde.

Een methodologische opmerking die meer waard is dan het resultaat. Ik draaide ook een verbosity-test: hetzelfde correcte antwoord, één kopie opgevuld met een zin van 36 woorden die niets toevoegt. De judge gaf in precies 50% van de trials de voorkeur aan de langere versie — wat lijkt op afwezigheid van verbosity bias en niets van dien aard is, omdat een judge die altijd positie A kiest op elke gebalanceerde pairing 50% scoort. Je kunt geen tweede bias meten voordat de eerste is gecontroleerd. Posities omwisselen is geen verfijning voor later; het is wat elke andere meting interpreteerbaar maakt.

De eerlijke caveat: deze judge is een model met een half miljard parameters, en niemand zou daarmee moeten beoordelen. Het punt is niet dat judges slecht zijn. Het punt is dat de cijfers hierboven acht minuten kostten om te produceren, en zonder die cijfers zou het oordeel van deze judge over een shipping-beslissing 100% zijn geweest.

Dit is het derde en laatste aangekondigde Python-paneel van de cursus, en de reden is waar de openbare cijfers vandaan komen. lm-evaluation-harness dekt "over 60 standard academic benchmarks for LLMs, with hundreds of subtasks and variants implemented" en is "the backend for Hugging Face's popular Open LLM Leaderboard"; HELM, SWE-bench en τ-bench zijn Python-pakketten met Python-entrypoints.⁶ Je model tegen een gepubliceerd cijfer draaien betekent hun code draaien, en op de dag dat je wilt vergelijken met een getal dat iemand citeerde, is dit het ecosysteem waarin je zit:

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

De tweede reden is dat één meting in dit hoofdstuk onmogelijk is via HTTP. Contamination — de testset die in de trainingsdata is gelekt — is de failure die een openbare benchmark stilletjes betekenisloos maakt, en de scherpste probe daarvoor heeft de eigen loss van het model nodig, die geen chat API teruggeeft. Het is de cross-entropy per token uit Hoofdstuk 8, gericht op een vraag over geheugen:

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)

Tien zinsparen: vijf in elke crawl van het web sinds het bestaat, vijf vanochtend voor dit hoofdstuk geschreven, elk gepaard met een herformulering met dezelfde inhoud.

Het model is vier keer zo verrast door een zin die vanochtend is geschreven als door een zin die het een miljoen keer heeft gezien, en herformuleren kost op de beroemde zinnen twee keer zoveel — de extra kost is het deel dat gememoriseerd was in plaats van begrepen. Absolute loss verwart memorisatie met gewone natuurlijkheid, dus de gap is de betere statistiek en de continuation-test is nog beter. Geef het de eerste zes woorden:

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."

Drie van de vijf beroemde strings werden vanaf zes woorden woordperfect voortgezet; geen van de vijf verse deed dat. Dat is een model met een half miljard parameters dat de MIT License opzegt. Als je benchmark op het openbare web staat, neem aan dat hij in de weights zit. Het is ook het argument voor het hele hoofdstuk: een golden set die je uit je eigen data hebt geschreven, buiten elke repository gehouden die een crawler leest, is de enige testset waarvan je zeker kunt zijn dat er nooit op is getraind.

Ze zijn nog steeds het lezen waard, zolang je leest wat elke benchmark meet in plaats van het ene getal dat eraan hangt.

Neem de tabel, niet één rij. De agentic benchmarks zetten mensen allemaal ver boven modellen, wat het tegenovergestelde is van de kennisbenchmarks en de beste samenvatting in één zin van waar het veld staat; hun cijfers verouderen binnen maanden, dus citeer ze met de datum waarop je ze las; en elk ervan meet een taak die niet de jouwe is.

Accuracy is de metric waar je over discussieert. Dit zijn de metrics die bepalen of het ding wordt geshipt. Alle vier vallen uit de tweehonderd runs die al gemeten zijn.

Kosten per opgeloste taak, niet per call. De agent kost $0.001345 per poging en $0.005172 per daadwerkelijk opgeloste taak — 3.85 keer zoveel, omdat driekwart van de pogingen niets oplevert. Latency gedraagt zich hetzelfde: 1,213 ms per poging, 4,667 ms per opgeloste taak. Elke retry, elke opnieuw gestelde vraag, elk verlaten traject zit in het tweede getal en is onzichtbaar in het eerste.

Een diagnostiek die accuracy verslaat. In 123 van de 200 pogingen antwoordde de agent zonder ook maar één tool aan te roepen — hij gokte in plaats van te kijken. Gesplitst daarop:

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

De intervallen komen niet in de buurt van elkaar. Dat is meer waard dan de aggregate 26%, omdat het benoemt wat je moet fixen — het model faalt niet in redeneren, het faalt in kijken — en de fix zit in de harness, niet in het model. Eén caveat die dit hoofdstuk aan zijn eigen standaarden verschuldigd is: de twee groepen zijn verschillende taken, niet dezelfde taken gepaard, dus een deel van die kloof kan zijn dat het de tools juist overslaat op de vragen die het moeilijk vindt. De split is een diagnose, geen causale claim.

Human intervention rate is de metric waar een koper als eerste om vraagt: welk deel van de runs stopte bij een approval, een guardrail of een handoff. De getypeerde onderbrekingen uit Hoofdstuk 23 maken het telbaar, en geteld per taaktype en per week is het wat een agent die zijn werk leert onderscheidt van een agent die stilletjes een wachtrij wordt.

Abandonment is de metric die geen enkele offline suite kan zien: de gebruiker die het antwoord las, het tabblad sloot en de taak zelf deed. Offline evaluatie is een poort; productie-evaluatie is een continue sample van echt verkeer, gescoord op dezelfde grader plus deze vier.

En een regel geërfd uit Hoofdstuk 17: assert nooit op exacte output. Assert op eigenschappen — geldige JSON, correct schema, de juiste tool aangeroepen, een getal binnen tolerantie, een vereiste substring aanwezig. De exact-match-kolom bovenaan dit hoofdstuk is wat er gebeurt wanneer die regel wordt gebroken.

Een leverancier evalueren gaat niet alleen over accuracy, en dit is de tweede helft van de ethiek van deze cursus, met een eigen kop in plaats van een appendix.

Meet de bias, neem hem niet aan. Wat je ook gelooft over het gedrag van een model op namen, dialecten, genders of nationaliteiten, het is een meetbare eigenschap van jouw pipeline, en het instrument is het instrument dat je al hebt: neem je golden set, varieer alleen het attribuut, vergelijk gepaard. HELM bestaat precies omdat alleen accuracy werd gerapporteerd waar bias, toxiciteit, calibration en robustness ook bepaalbaar waren.⁸ De model card van een vendor is een startpunt, geen bewijs over jouw inputs.

Contamination is ook een leveranciersvraag. De probe hierboven is de reden om te vragen waarop een gepubliceerd getal is gemeten, en wanneer de data van het model is afgekapt.

Retention, training en residency, gelezen op 7 september 2026. Deze veranderen, dus noteer de datum naast het antwoord. Anthropic's beleidspagina stelt: "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", met als uitzondering content die je expliciet als feedback indient, die "for up to 5 years" wordt bewaard.¹⁶ OpenAI's documentatie over datacontroles stelt dat "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)", beschrijft een standaardretentie van dertig dagen voor abuse-monitoring logs, en biedt Zero Data Retention, dat "excludes customer content from abuse monitoring logs", plus configureerbare data residency over een lijst met regio's.¹⁷

Vier vragen om schriftelijk te krijgen vóór de eerste productie-call, omdat elke vraag een andere eigenaar heeft: wordt mijn data gebruikt voor training; hoe lang wordt die bewaard en door wie; waar wordt die verwerkt en opgeslagen; en wat gebeurt er met al die dingen als ik een reseller, een gateway of een aggregator gebruik in plaats van de provider direct. In die laatste vraag zitten de meeste verrassingen, en geen benchmark vertelt je dat.

Je hebt nu het instrument: een golden set die van jou is, een interval op elk getal, een paired test voor elke vergelijking, pass^k voor de runs die je niemand liet zien, een gemeten judge, en een probe voor de vraag of een openbare score iets betekent. De slotclaim van Hoofdstuk 23 kan nu worden gecontroleerd in plaats van beweerd — een harness maakt een agent bestuurbaar, niet correct — en die controle kostte tweehonderd runs en acht minuten.

Er is één eigenschap van een agent die dit allemaal niet meet, en het is de eigenschap waardoor mensen ontslagen worden.

Elke taak in de golden set van dit hoofdstuk is door mij geschreven, en elk bestand dat de agent las is door mij geschreven. Niets in die map probeerde iets te doen. Verander één regel in één bestand dat de agent moet lezen — een regel die eindigt met een instructie gericht aan wat het daarna ook leest — en de agent die 26% scoorde zal die volgen met dezelfde tools, dezelfde permissies en dezelfde schone trace, en elk getal in dit hoofdstuk blijft precies waar het is. Een evaluatiesuite meet hoe vaak een systeem jouw doel bereikt. Ze meet niet hoe makkelijk iemand anders zijn doel ervoor in de plaats kan zetten.

Hoofdstuk 30 gaat daarover: prompt injection, de dodelijke trifecta van private data, untrusted content en external communication, en wat het kost om een agent echte permissies te geven. Het opent met de observatie die dit hoofdstuk heeft vermeden — dat dezelfde passing score compatibel is met een agent die precies doet wat een aanvaller schreef in een bestand dat hij moest lezen.

Elk getal hierboven is geproduceerd op één machine en niets ervan raakte een betaald endpoint. De agent is de loop uit Hoofdstuk 23 met twee van zijn vier tools over een map met vijf bestanden; het model achter de poort is Qwen/Qwen2.5-0.5B-Instruct, beschikbaar gemaakt via een kleine server met dezelfde vorm als een chat-completions-endpoint precies zoals in Hoofdstuk 23, maar in half precision op één consumer-GPU in plaats van de CPU uit dat hoofdstuk. Kosten gebruiken de tarieven uit Hoofdstuk 16 — $2.00 per miljoen input tokens en $12.00 per miljoen output — toegepast op gemeten token-aantallen. De herhaalde runs gebruiken temperature 0.7 met vaste seeds zodat de hele set reproduceert; de tabel met vier armen is greedy. Intervallen zijn Wilson op 95%, paired comparisons zijn tweezijdige exacte sign tests over de discordante paren; het Wilson-interval is dat uit Hoofdstuk 4 en de exacte paired sign test die uit Hoofdstuk 15, allebei ongewijzigd hergebruikt. De menselijke labels zijn van mij, toegepast op zestig antwoorden onder de geschreven regel die in de tekst is geciteerd. Lees elke orde van grootte hier als een eigenschap van een model met een half miljard parameters en elke methode als overdraagbaar: een groter model schuift alle cijfers omhoog en verandert geen van de instrumenten.