Avaluació d’LLM: dels benchmarks públics al teu golden set

Gairebé totes les discussions sobre avaluació són dues persones mesurant coses diferents. Hi ha tres projectes i no comparteixen instrument.

La confusió és cara en una direcció. Un leaderboard et diu que un model és fort en raonament de nivell de postgrau; no et pot dir si enrutarà els teus tiquets de suport. I una avaluació d’aplicació que puntua una resposta per entrada no pot veure un agent en absolut, perquè un agent té una distribució de trajectòries i una resposta és una sola mostra d’aquesta distribució. El Capítol 22 va donar nom a aquesta tercera fila i la va deixar buida: la mesura de rendiment, l’única part de l’especificació d’un agent que els equips escriuen l’última o no escriuen mai.

L’ordre també importa, i el venedor que et ven el model ho diu. La guia d’agents d’OpenAI redueix la selecció de model a tres passos, en aquest ordre: «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».¹ L’avaluació va primer, perquè els passos dos i tres no volen dir res sense un número.

Un golden set és una llista d’entrades, cadascuna amb la resposta escrita, i un grader que decideix si una sortida hi coincideix. És avorrit, és petit, i és l’únic artefacte d’aquest capítol que és teu. El que es construeix aquí té vint tasques sobre un directori de cinc fitxers — no els tres del Capítol 23, així que les respostes no són les mateixes — i el grader s’escriu abans que l’agent s’executi:

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

Dues propietats són estructurals. La llista mustNot existeix perquè un model que anomena tres fitxers incloent-hi el correcte no ha respost. I answer està escrit en prosa i també en patrons, perquè un humà i un jutge ho necessitaran més endavant — i escriure el mateix fet dues vegades en dues notacions és com descobreixes que no estaves d’acord amb tu mateix sobre quina era la tasca.

Ara, la taula que decideix. Quatre sistemes candidats, les mateixes vint tasques, accuracy amb el seu interval, i les dues columnes que una taula només d’accuracies sempre amaga:

Llegeix els intervals abans que el guanyador. Les execucions del braç B van de l’11 % al 47 %; les del braç A, del 3 % al 30 %. Se solapen en gairebé tota la seva longitud, que és el resultat del Capítol 4 arribant exactament on s’havia promès: vint casos no poden ordenar quatre sistemes. El Capítol 15 ho va afinar fent la pregunta aparellada — dels casos en què dos braços discrepen, com de desequilibrada és la divisió? — perquè la dificultat compartida del conjunt es cancel·la. Aquí hi ha cada parell:

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

Cap de les sis comparacions queda establerta. El millor braç supera el braç sense cap eina per quinze punts, i això descansa en tres casos discordants. Vint casos mostren un mecanisme i no poden triar un proveïdor; dir el contrari en una reunió és com es compra un mal model.

Hi ha una cosa que aquesta taula sí que estableix, i és la columna que ningú hi posa. El braç D costa tretze vegades el braç B per tasca resolta, perquè mostrejar tres trajectòries i quedar-se amb la resposta modal triplica la factura tant si triplica l’accuracy com si no. Les taules d’accuracy que ometen el cost fan invisible aquest intercanvi.

Ara, el resultat que canvia com llegiràs cada benchmark que vegis mai. Agafa les mateixes dues-centes transcripcions — vint tasques, deu execucions, ni un token regenerat — i puntua-les de tres maneres:

Zero, tretze, vint-i-sis. El sistema no ha canviat. El grader sí. La coincidència exacta retorna zero no perquè l’agent sigui inútil, sinó perquè cap resposta de text lliure no és mai idèntica byte per byte a una referència: mesura format i ho informa com a capacitat.

Això no és una curiositat, és un mecanisme, i té nom. Una mètrica de tall dur puntua una tasca com tot o res sobre diversos subfets, així que els compon. La tasca t12 demana tres codis d’estat alhora. En les deu execucions:

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

Cada fet és correcte aproximadament tres quartes parts de les vegades; exigir tots tres alhora redueix la puntuació a la meitat, i $0.77^3 = 0.457$ és prou a prop del 0.50 mesurat per mostrar d’on ve la caiguda. Generalitza:

Llegeix la fila 0.90 contra la fila 0.95 a $k = 10$: una millora de cinc punts per fet es converteix en vint-i-cinc punts en la conjunció. No li ha passat res discontinu al model. Una corba suau llegida a través d’una mètrica de tot o res sembla un salt — que és precisament l’argument que Schaeffer, Miranda i Koyejo van fer sobre les capacitats emergents, i que el Capítol 10 va diferir fins aquí.² La seva auditoria va trobar que com a molt 5 de les 39 mètriques preferides de BIG-Bench mostren emergència, amb dues mètriques discontínues responsables de més del 92 % dels casos afirmats.

Així que la disciplina, en una línia: un salt en un gràfic és evidència sobre la mètrica fins que es demostri el contrari. Abans de creure que ha aparegut una capacitat, grafica les mateixes execucions amb una mètrica que doni crèdit parcial i mira si el penya-segat sobreviu.

Hi ha una versió de segon ordre d’això que Kalai i col·laboradors argumenten que està fent mal aigües amunt: els benchmarks puntuats com a correcte-o-incorrecte premien endevinar per sobre de dir «no ho sé», així que un model optimitzat contra ells aprèn a endevinar. La seva solució proposada no és un altre benchmark d’al·lucinacions, sinó «modifying the scoring of existing benchmarks that are misaligned but dominate leaderboards».³ El teu golden set té la mateixa palanca, i és una línia: decideix si una abstenció compta com a fallada o com la seva pròpia categoria. La majoria de gent no ho decideix mai, així que compta silenciosament com a fallada, i el sistema que envien a producció endevina.

Tot fins ara puntuava un intent per tasca. Un agent no és un intent. El Capítol 17 va establir que no tens determinisme ni tan sols a temperatura zero, així que la mateixa entrada produeix una distribució de trajectòries i un benchmark que executa cada tasca una vegada n’informa una sola mostra.

La contribució de τ-bench és la mètrica per a això. L’article la defineix clarament: «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».⁴ Executa cada tasca $n$ vegades, compta els $c$ èxits, i els estimadors no esbiaixats són:

El segon és el familiar pass@k de la generació de codi: la probabilitat que almenys un de $k$ intents tingui èxit. Posa’ls costat a costat sobre els mateixos recomptes mesurats i es mouen en direccions oposades:

Mateixes execucions, mateix grader, mateixes vint tasques. Una columna diu que el sistema millora amb més intents i l’altra diu que empitjora, i totes dues són correctes, perquè responen preguntes diferents. pass@k és la mètrica correcta quan un humà filtra la sortida — generació de codi, esborranys, brainstorming — i els intents extra són barats. pass^k és la mètrica correcta quan l’agent actua sense filtre, que és el que vol dir «agent». Publicar la primera quan aplica la segona és l’exageració més comuna en aquest camp, i el titular propi de τ-bench n’és la versió honesta: gpt-4o a aproximadament un 61 % pass^1 en retail cau a prop del 25 % a pass^8.⁴

Ara, la punxada en els meus propis números. pass^10 sobre les meves vint tasques és 5.0 %: exactament una tasca de vint resolta en totes les deu execucions. Aquesta tasca és t19, «Did deploy 42 succeed?», i aquí tens dues de les deu respostes que la rúbrica va puntuar com a correctes:

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

La primera no respon mai. La segona afegeix una afirmació falsa — deploy 41 es va revertir. Totes dues van coincidir amb /succe|yes/. L’única tasca que manté pass^10 per sobre de zero és un artefacte del grader, així que la xifra real és zero, i cap agregat m’ho hauria ensenyat. Mostrejar les transcripcions darrere de la teva tasca amb millor puntuació és on els graders van a morir.

I un número més, aquell pel qual es diu així aquesta secció. Deu avaluacions idèntiques — mateix sistema, mateixes vint tasques, mateix codi, res canviat excepte les llavors:

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

Un rang de trenta punts en un sistema que no ha canviat. Si executes la teva suite una vegada abans d’una release i una vegada després, una «millora» de vuit punts és dins d’aquesta dispersió i l’enviaràs a producció creient que l’has causat tu. Per això l’interval agrupat anterior — 26.0 % [20.4, 32.5] — és massa estret per citar-lo sol: tracta dues-centes proves correlacionades com si fossin dues-centes d’independents. El resum honest d’una avaluació d’agent és una mitjana i una dispersió entre repeticions, i gairebé ningú publica la segona.

Les rúbriques no escalen a respostes obertes, així que el moviment estàndard és fer que un model puntuï la sortida. Funciona prou bé a escala frontier per ser el valor per defecte, i té tres modes de fallada amb nom: biaix de posició, biaix de verbositat i biaix d’auto-millora.⁵

Mesura’l abans de confiar-hi. Les mateixes seixanta respostes — tres de les deu execucions — es van etiquetar de tres maneres. L’etiqueta humana és meva: vaig llegir les seixanta amb els cinc fitxers oberts i vaig aplicar una regla escrita, passa si i només si la resposta afirma el fet que la pregunta demanava i no conté res contradit pels fitxers.

El jutge va dir PASS seixanta vegades de seixanta. Hauria informat aquest agent amb un 100 % d’accuracy en un conjunt on l’humà el puntua amb un 18 %. Un jutge sense poder discriminatiu no és un instrument sorollós; és una funció constant, i una funció constant dona la mateixa puntuació al teu millor sistema i al teu pitjor sistema.

El prompting no el va rescatar. Quatre variants, els mateixos seixanta ítems:

Intercanviar l’ordre de les dues etiquetes a la instrucció va moure quatre veredictes. És un efecte mesurable i és el tipus d’efecte equivocat: el jutge respon a la forma del prompt més que a la resposta que té davant.

La demostració neta és per parelles. Vint preguntes, cadascuna amb una candidata clarament correcta i una clarament errònia, presentades en tots dos ordres:

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 %

Va triar la posició A quaranta vegades de quaranta. El 50 % en correcció no és competència parcial — és aritmètica, perquè la resposta correcta és a la posició A exactament en la meitat de les proves. La consistència aquí es defineix com la defineix MT-Bench, «the percentage of cases where a judge gives consistent results when swapping the order of two assistants», cosa que permet comparar pomes amb pomes: GPT-4 puntua un 65.0 % en aquesta mesura, i el few-shot prompting la va elevar al 77.5 %.⁵ El meu puntua zero.

La mitigació estàndard també ve d’aquest article: «call a judge twice by swapping the order of two answers and only declare a win when an answer is preferred in both orders».⁵ Aplica-ho aquí i el jutge produeix zero veredictes utilitzables de vint parelles — que és el resultat correcte, i infinitament millor que vint de confiats.

Una nota metodològica que val més que el resultat. També vaig executar una prova de verbositat: la mateixa resposta correcta, una còpia farcida amb una frase de 36 paraules que no afegeix res. El jutge va preferir la versió més llarga exactament en el 50 % de les proves — cosa que sembla una absència de biaix de verbositat i no ho és gens, perquè un jutge que sempre tria la posició A puntua un 50 % en qualsevol aparellament equilibrat. No pots mesurar un segon biaix fins que el primer està controlat. Intercanviar posicions no és un refinament per afegir més tard; és el que fa que qualsevol altra mesura sigui interpretable.

L’advertiment honest: aquest jutge és un model de mig miler de milions de paràmetres, i ningú no hauria de puntuar amb un. La qüestió no és que els jutges siguin dolents. És que els números anteriors van costar vuit minuts de produir, i sense ells el veredicte d’aquest jutge sobre una decisió de producció hauria estat 100 %.

Aquest és el tercer i últim panell de Python declarat del curs, i el motiu és d’on venen els números públics. lm-evaluation-harness cobreix «over 60 standard academic benchmarks for LLMs, with hundreds of subtasks and variants implemented» i és «the backend for Hugging Face's popular Open LLM Leaderboard»; HELM, SWE-bench i τ-bench són paquets de Python amb punts d’entrada de Python.⁶ Executar el teu model contra una xifra publicada vol dir executar el seu codi, i el dia que vulguis comparar amb un número que algú ha citat, aquest és l’ecosistema on ets:

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

El segon motiu és que una mesura d’aquest capítol és impossible per HTTP. Contaminació — que el test set s’hagi filtrat a les dades d’entrenament — és la fallada que fa que un benchmark públic no signifiqui res en silenci, i la sonda més afilada per detectar-la necessita la loss pròpia del model, que cap API de chat retorna. És l’entropia creuada per token del Capítol 8, apuntada a una pregunta sobre memòria:

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)

Deu parelles de frases: cinc en tots els crawls del web des que existeix, cinc escrites aquest matí per a aquest capítol, cadascuna aparellada amb una versió reformulada que porta el mateix contingut.

El model queda quatre vegades més sorprès per una frase escrita aquest matí que per una que ha vist un milió de vegades, i reformular costa el doble en les famoses — el cost extra és la part memoritzada més que entesa. La loss absoluta confon memorització amb naturalitat ordinària, així que la diferència és una estadística millor i la prova de continuació encara ho és més. Dona-li les primeres sis paraules:

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

Tres de les cinc cadenes famoses van continuar paraula per paraula des de sis paraules; cap de les cinc fresques no ho va fer. Això és un model de mig miler de milions de paràmetres recitant la llicència MIT. Si el teu benchmark és al web públic, assumeix que és als pesos. També és l’argument de tot el capítol: un golden set que has escrit a partir de les teves pròpies dades, mantingut fora de qualsevol repositori que llegeixi un crawler, és l’únic test set del qual pots estar segur que mai no s’ha entrenat.

Encara val la pena llegir-los, sempre que llegeixis què mesura cadascun en lloc del número únic que hi va enganxat.

Agafa la taula més que cap fila. Els benchmarks agentics posen tots els humans molt per sobre dels models, que és el contrari dels benchmarks de coneixement i el millor resum en una línia d’on és el camp; les seves xifres envelleixen en mesos, així que cita-les amb la data en què les has llegit; i cadascun mesura una tasca que no és la teva.

L’accuracy és la mètrica sobre la qual discuteixes. Aquestes són les que decideixen si la cosa s’envia. Totes quatre surten de les dues-centes execucions ja mesurades.

Cost per tasca resolta, no per crida. L’agent costa $0.001345 per intent i $0.005172 per tasca realment resolta — 3.85 vegades més, perquè tres quartes parts dels intents no produeixen res. La latència es comporta igual: 1,213 ms per intent, 4,667 ms per tasca resolta. Cada retry, cada repregunta, cada trajectòria abandonada és al segon número i invisible al primer.

Un diagnòstic que supera l’accuracy. En 123 de 200 intents l’agent va respondre sense cridar ni una sola eina — va endevinar en lloc de mirar. Separant per això:

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

Els intervals no s’acosten ni a tocar-se. Això val més que l’agregat del 26 %, perquè posa nom a allò que cal arreglar — el model no està fallant a raonar, està fallant a mirar — i la solució és al harness, no al model. Un advertiment que aquest capítol deu als seus propis estàndards: els dos grups són tasques diferents, no les mateixes tasques aparellades, així que una part d’aquesta diferència pot ser que se salti les eines precisament en les preguntes que troba difícils. La divisió és un diagnòstic, no una afirmació causal.

La taxa d’intervenció humana és la mètrica que un comprador pregunta primer: quina fracció d’execucions es va aturar en una aprovació, un guardrail o un handoff. Les interrupcions tipades del Capítol 23 ho fan comptable, i comptat per tipus de tasca i per setmana és el que separa un agent que està aprenent la seva feina d’un que s’està convertint silenciosament en una cua.

L’abandonament és la que cap suite offline pot veure: l’usuari que ha llegit la resposta, ha tancat la pestanya i ha fet la tasca ell mateix. L’avaluació offline és una porta; l’avaluació en producció és una mostra contínua de trànsit real, puntuada amb el mateix grader més aquestes quatre.

I una regla heretada del Capítol 17: no facis mai asserts sobre la sortida exacta. Fes asserts sobre propietats — JSON vàlid, esquema correcte, l’eina adequada cridada, un número dins de tolerància, una subcadena requerida present. La columna de coincidència exacta al principi d’aquest capítol és el que passa quan aquesta regla es trenca.

Avaluar un proveïdor no va només d’accuracy, i aquesta és la segona meitat de l’ètica d’aquest curs, amb el seu propi encapçalament en lloc d’un apèndix.

Mesura el biaix, no l’assumeixis. Sigui el que sigui que creguis sobre el comportament d’un model amb noms, dialectes, gèneres o nacionalitats, és una propietat mesurable de la teva pipeline, i l’instrument és el que ja tens: agafa el teu golden set, varia només l’atribut, compara aparellat. HELM existeix precisament perquè s’informava només d’accuracy quan biaix, toxicitat, calibratge i robustesa també eren decidibles.⁸ La model card d’un venedor és un punt de partida, no evidència sobre les teves entrades.

La contaminació també és una pregunta de proveïdor. La sonda anterior és el motiu per preguntar sobre què es va mesurar una xifra publicada, i quan es van tallar les dades del model.

Retenció, entrenament i residència, llegit el 7 de setembre de 2026. Això canvia, així que registra la data al costat de la resposta. La pàgina de polítiques d’Anthropic diu: «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», amb l’excepció del contingut que envies explícitament com a feedback, que s’emmagatzema «for up to 5 years».¹⁶ La documentació de controls de dades d’OpenAI diu que «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)», descriu una retenció predeterminada de trenta dies per als logs de monitoratge d’abús, i ofereix Zero Data Retention, que «excludes customer content from abuse monitoring logs», més residència de dades configurable entre una llista de regions.¹⁷

Quatre preguntes per obtenir per escrit abans de la primera crida de producció, perquè cadascuna té un propietari diferent: les meves dades s’usen per entrenar; quant de temps es conserven i per qui; on es processen i s’emmagatzemen; i què passa amb tot això si faig servir un revendedor, una passarel·la o un agregador en lloc del proveïdor directament. L’última és on viuen la majoria de sorpreses, i cap benchmark t’ho dirà.

Ara tens l’instrument: un golden set que és teu, un interval per a cada número, una prova aparellada per a cada comparació, pass^k per a les execucions que no vas ensenyar a ningú, un jutge mesurat, i una sonda per saber si una puntuació pública significa res. L’afirmació final del Capítol 23 ara es pot comprovar en lloc d’afirmar-se — un harness fa que un agent sigui governable, no correcte — i comprovar-ho va requerir dues-centes execucions i vuit minuts.

Hi ha una propietat d’un agent que res d’això mesura, i és la que fa que acomiadin gent.

Cada tasca del golden set d’aquest capítol la vaig escriure jo, i cada fitxer que l’agent va llegir el vaig escriure jo. Res en aquell directori intentava fer res. Canvia una línia en un fitxer que es diu a l’agent que llegeixi — una línia que acaba amb una instrucció adreçada a qualsevol cosa que la llegeixi després — i l’agent que va puntuar 26 % la seguirà amb les mateixes eines, els mateixos permisos i el mateix trace net, i cada número d’aquest capítol es quedarà exactament on és. Una suite d’avaluació mesura amb quina freqüència un sistema arriba al teu objectiu. No mesura amb quina facilitat algú altre pot substituir-lo pel seu.

El Capítol 30 és això: prompt injection, la trifecta letal de dades privades, contingut no fiable i comunicació externa, i què costa donar permisos reals a un agent. Obre amb l’observació que aquest capítol ha estat evitant — que la mateixa puntuació d’aprovat és compatible amb un agent que fa exactament el que un atacant va escriure en un fitxer que se li va dir que llegís.

Cada número anterior es va produir en una màquina i res no va tocar cap endpoint de pagament. L’agent és el bucle del Capítol 23 amb dues de les seves quatre eines sobre un directori de cinc fitxers; el model darrere del port és Qwen/Qwen2.5-0.5B-Instruct, exposat a través d’un petit servidor amb la mateixa forma que un endpoint de chat completions exactament com al Capítol 23, però en mitja precisió en una GPU de consum en lloc de la CPU d’aquell capítol. Els costos usen les tarifes del Capítol 16 — $2.00 per milió d’input tokens i $12.00 per milió de sortida — aplicades a recomptes de token mesurats. Les execucions repetides usen temperatura 0.7 amb llavors fixes perquè tot el conjunt es reprodueixi; la taula de quatre braços és greedy. Els intervals són Wilson al 95 %, les comparacions aparellades són proves exactes de signes bilaterals sobre les parelles discordants; l’interval de Wilson és el del Capítol 4 i la prova exacta de signes aparellada és la del Capítol 15, tots dos reutilitzats sense canvis. Les etiquetes humanes són meves, aplicades a seixanta respostes sota la regla escrita citada al text. Llegeix cada magnitud aquí com una propietat d’un model de mig miler de milions de paràmetres i cada mètode com a transferible: un model més gran mou tots els números amunt i no mou cap dels instruments.