Avaliación de LLM: dos benchmarks públicos ao teu conxunto de ouro

Case toda discusión sobre avaliación son dúas persoas medindo cousas distintas. Hai tres proxectos e non comparten instrumento.

A confusión sae cara nunha dirección. Un leaderboard diche que un modelo é forte en razoamento de nivel de posgrao; non pode dicirche se encamiñará os teus tickets de soporte. E unha avaliación de aplicación que puntúa unha resposta por input non pode ver un agent en absoluto, porque un agent ten unha distribución de traxectorias e unha resposta é unha soa mostra desa distribución. O Capítulo 22 puxo nome a esa terceira fila e deixouna baleira: a medida de rendemento, a parte da especificación dun agent que os equipos escriben de última ou nunca.

A orde tamén importa, e o provedor que che vende o modelo tamén o di. A guía de agents de OpenAI reduce a selección de modelo a tres pasos, nesta orde: «Configura evals para establecer un baseline de rendemento», «Céntrate en cumprir o teu obxectivo de exactitude cos mellores modelos dispoñibles», «Optimiza custo e latencia substituíndo modelos maiores por outros máis pequenos onde sexa posible».¹ A avaliación vai primeiro, porque os pasos dous e tres non teñen sentido sen un número.

Un conxunto de ouro é unha lista de inputs, cada un coa resposta escrita, e un avaliador que decide se unha saída encaixa. É aburrido, é pequeno e é o único artefacto deste capítulo que é teu. O que se constrúe aquí ten vinte tarefas sobre un directorio de cinco ficheiros — non os tres do Capítulo 23, así que as respostas non son as mesmas — e o avaliador escríbese antes de que o agent se execute:

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

Dúas propiedades sosteñen a carga. A lista mustNot existe porque un modelo que nomea tres ficheiros incluíndo o correcto non respondeu. E answer está escrito en prosa ademais de en patróns, porque máis adiante o necesitarán tanto unha persoa como un judge; e escribir o mesmo feito dúas veces en dúas notacións é como descubres que non estabas de acordo contigo sobre cal era a tarefa.

Agora a táboa que decide. Catro sistemas candidatos, as mesmas vinte tarefas, exactitude co seu intervalo, e as dúas columnas que unha táboa só de exactitudes sempre agocha:

Le os intervalos antes de ler o gañador. As execucións do brazo B van do 11 % ao 47 %; as do brazo A, do 3 % ao 30 %. Solápanse ao longo de case toda a súa lonxitude, que é o achado do Capítulo 4 chegando exactamente onde estaba prometido: vinte casos non poden ordenar catro sistemas. O Capítulo 15 afinou isto facendo no seu lugar a pregunta pareada — nos casos nos que dous brazos discrepan, canto de desequilibrado é o reparto? — porque a dificultade compartida do conxunto cancélase. Aquí están todos os pares:

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

Ningunha das seis comparacións queda establecida. O mellor brazo supera o brazo sen ferramentas en quince puntos, e iso descansa en tres casos discordantes. Vinte casos mostran un mecanismo e non poden elixir un provedor; dicir o contrario nunha reunión é como se compra un mal modelo.

Hai unha cousa que esta táboa si establece, e é a columna que ninguén pon. O brazo D custa trece veces o brazo B por tarefa resolta, porque mostrar tres traxectorias e coller a resposta modal triplica a factura tanto se triplica a exactitude coma se non. As táboas de exactitude que omiten o custo fan invisible ese intercambio.

Agora o achado que cambia como les cada benchmark que vexas. Colle as mesmas duascentas transcricións — vinte tarefas, dez execucións, nin un token rexenerado — e puntúaas de tres maneiras:

Cero, trece, vinte e seis. O sistema non cambiou. O avaliador si. A coincidencia exacta devolve cero non porque o agent sexa inútil, senón porque ningunha resposta de texto libre é nunca idéntica byte a byte a unha referencia: mide formato e infórmao como capacidade.

Iso non é unha curiosidade, é un mecanismo, e ten nome. Unha métrica de corte duro puntúa unha tarefa todo-ou-nada sobre varios subfeitos, polo que compón. A tarefa t12 pide tres códigos de estado á vez. Ao longo das dez execucións:

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

Cada feito está ben arredor de tres cuartos das veces; esixir os tres á vez reduce a puntuación á metade, e $0.77^3 = 0.457$ está o suficientemente preto do 0.50 medido como para mostrar de onde veu a caída. Xeneraliza:

Le a fila 0.90 contra a fila 0.95 en $k = 10$: unha mellora por feito de cinco puntos convértese en vinte e cinco puntos na conxunción. Ao modelo non lle aconteceu nada discontinuo. Unha curva suave lida a través dunha métrica todo-ou-nada parece un salto: que é precisamente o argumento que Schaeffer, Miranda e Koyejo fixeron sobre as habilidades emerxentes, e que o Capítulo 10 adiou ata aquí.² A súa auditoría descubriu que como moito 5 das 39 métricas preferidas de BIG-Bench amosan emerxencia en absoluto, con dúas métricas discontinuas explicando máis do 92 % dos casos afirmados.

Así que a disciplina, nunha liña: un salto nun gráfico é evidencia sobre a métrica ata que se demostre o contrario. Antes de crer que apareceu unha capacidade, representa as mesmas execucións cunha métrica que dea crédito parcial e mira se o precipicio sobrevive.

Hai unha versión de segunda orde disto que Kalai e colegas argumentan que está facendo dano augas arriba: os benchmarks puntuados como certo-ou-errado recompensan adiviñar por riba de dicir «non o sei», así que un modelo optimizado contra eles aprende a adiviñar. A solución que propoñen non é outro benchmark de alucinacións senón «modificar a puntuación dos benchmarks existentes que están desaliciñados pero dominan os leaderboards».³ O teu conxunto de ouro ten a mesma panca, e é unha liña: decide se unha abstención conta como fallo ou como a súa propia categoría. A maioría da xente nunca o decide, así que conta silenciosamente como fallo, e o sistema que envían adiviña.

Todo ata aquí puntuou un intento por tarefa. Un agent non é un intento. O Capítulo 17 estableceu que non tes determinismo nin sequera a temperatura cero, así que o mesmo input produce unha distribución de traxectorias e un benchmark que executa cada tarefa unha vez informa unha mostra desa distribución.

A contribución de τ-bench é a métrica para iso. O artigo defínea con claridade: «propoñemos unha nova métrica — pass^k (pass hat k), definida como a probabilidade de que todos os k ensaios i.i.d. dunha tarefa teñan éxito, promediada entre tarefas».⁴ Executa cada tarefa $n$ veces, conta os $c$ éxitos, e os estimadores non sesgados son:

O segundo é o coñecido pass@k da xeración de código: a probabilidade de que polo menos un de $k$ intentos teña éxito. Poñéndoos un ao lado do outro sobre os mesmos recontos medidos, móvense en direccións opostas:

Mesmas execucións, mesmo avaliador, mesmas vinte tarefas. Unha columna di que o sistema mellora con máis intentos e a outra di que empeora, e as dúas son correctas, porque responden preguntas distintas. pass@k é a métrica correcta cando unha persoa filtra a saída — xeración de código, borradores, brainstorming — e os intentos extra son baratos. pass^k é a métrica correcta cando o agent actúa sen filtro, que é o que significa «agent». Publicar a primeira onde aplica a segunda é a esaxeración máis común neste campo, e o propio titular de τ-bench é a versión honesta: gpt-4o, con arredor dun 61 % de pass^1 en retail, cae a aproximadamente un 25 % en pass^8.⁴

Agora a punzada nos meus propios números. pass^10 nas miñas vinte tarefas é 5.0 %: exactamente unha tarefa de vinte resolta nas dez execucións. Esa tarefa é t19, «Tivo éxito o deploy 42?», e aquí van dúas das dez respostas que a rúbrica puntuou como correctas:

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

A primeira nunca responde. A segunda engade unha afirmación falsa: o deploy 41 foi revertido. Ambas coincidiron con /succe|yes/. A única tarefa que mantén pass^10 por riba de cero é un artefacto do avaliador, así que a cifra verdadeira é cero, e ningún agregado mo tería mostrado. Mostrear as transcricións detrás da túa tarefa con mellor puntuación é onde os avaliadores van morrer.

E un número máis, aquel polo que se chama esta sección. Dez avaliacións idénticas — mesmo sistema, mesmas vinte tarefas, mesmo código, nada cambiado agás as seeds:

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

Un rango de trinta puntos nun sistema que non cambiou. Se executas a túa suite unha vez antes dunha release e outra despois, unha «mellora» de oito puntos está dentro desa dispersión e enviarala crendo que a causaches. Por iso o intervalo agrupado de arriba — 26.0 % [20.4, 32.5] — é demasiado estreito para citalo só: trata duascentas probas correlacionadas como duascentas independentes. O resumo honesto dunha avaliación de agent é unha media e unha dispersión entre repeticións, e case ninguén publica a segunda.

As rúbricas non escalan a respostas abertas, así que o movemento estándar é facer que un modelo avalíe a saída. Funciona o suficientemente ben a escala frontier como para ser o predeterminado, e ten tres modos de fallo con nome: sesgo de posición, sesgo de verbosidade e sesgo de auto-mellora.⁵

Mídeo antes de confiar nel. As mesmas sesenta respostas — tres das dez execucións — etiquetáronse de tres maneiras. A etiqueta humana é miña: lin as sesenta cos cinco ficheiros abertos e apliquei unha regra escrita, pasa se e só se a resposta afirma o feito que a pregunta pedía e non contén nada contradicido polos ficheiros.

O judge dixo PASS sesenta veces de sesenta. Tería informado este agent cun 100 % de exactitude nun conxunto no que a persoa o puntúa cun 18 %. Un judge sen poder discriminativo non é un instrumento ruidoso; é unha función constante, e unha función constante dálle a mesma puntuación ao teu mellor sistema e ao teu peor sistema.

O prompting non o rescatou. Catro variantes, os mesmos sesenta elementos:

Intercambiar a orde das dúas etiquetas na instrución moveu catro veredictos. Iso é un efecto medible e é o tipo de efecto equivocado: o judge está respondendo á forma do prompt e non á resposta que ten diante.

A demostración limpa é por pares. Vinte preguntas, cada unha cun candidato claramente correcto e outro claramente errado, presentados nas dúas ordes:

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 %

Escolleu a posición A corenta veces de corenta. O 50 % en corrección non é competencia parcial: é aritmética, porque a resposta correcta está na posición A exactamente na metade das probas. A consistencia aquí defínese como a define MT-Bench, «a porcentaxe de casos nos que un judge dá resultados consistentes ao intercambiar a orde de dous asistentes», o que permite comparar mazás con mazás: GPT-4 puntúa 65.0 % nesa medida, e o few-shot prompting elevouno a 77.5 %.⁵ O meu puntúa cero.

A mitigación estándar tamén vén dese artigo: «chamar a un judge dúas veces intercambiando a orde de dúas respostas e declarar unha vitoria só cando unha resposta é preferida nas dúas ordes».⁵ Aplícaa aquí e o judge produce cero veredictos utilizables de vinte pares: que é o resultado correcto, e infinitamente mellor ca vinte veredictos confiados.

Unha nota metodolóxica que vale máis ca o resultado. Tamén executei unha proba de verbosidade: a mesma resposta correcta, unha copia rechea cunha frase de 36 palabras que non engade nada. O judge preferiu a versión máis longa exactamente no 50 % das probas, o que parece ausencia de sesgo de verbosidade e non é nada diso, porque un judge que sempre escolle a posición A puntúa 50 % en calquera emparellamento equilibrado. Non podes medir un segundo sesgo ata que o primeiro estea controlado. Intercambiar posicións non é un refinamento para engadir máis tarde; é o que fai interpretable calquera outra medición.

A advertencia honesta: este judge é un modelo de medio billón de parámetros, e ninguén debería avaliar con un. O punto non é que os judges sexan malos. É que os números de arriba custaron oito minutos de producir, e sen eles o veredicto deste judge sobre unha decisión de envío tería sido 100 %.

Este é o terceiro e último panel Python declarado do curso, e a razón está en de onde veñen os números públicos. lm-evaluation-harness cobre «máis de 60 benchmarks académicos estándar para LLMs, con centos de subtarefas e variantes implementadas» e é «o backend do popular Open LLM Leaderboard de Hugging Face»; HELM, SWE-bench e τ-bench son paquetes Python con puntos de entrada Python.⁶ Executar o teu modelo contra unha cifra publicada significa executar o seu código, e o día que queiras comparar cun número que alguén citou, este é o ecosistema no que estás:

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

A segunda razón é que unha medición deste capítulo é imposible por HTTP. Contaminación — que o conxunto de proba se filtrase nos datos de adestramento — é o fallo que fai que un benchmark público perda significado silenciosamente, e a sonda máis afiada para detectalo necesita a loss do propio modelo, que ningunha API de chat devolve. É a entropía cruzada por token do Capítulo 8, apuntada a unha pregunta sobre memoria:

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)

Dez pares de frases: cinco presentes en todos os rastrexos da web desde que existe, cinco escritas para este capítulo esta mañá, cada unha emparellada cunha versión reformulada co mesmo contido.

O modelo sorpréndese catro veces máis cunha frase escrita esta mañá ca cunha que viu un millón de veces, e reformular custa o dobre nas famosas: o custo extra é a parte que foi memorizada e non entendida. A loss absoluta confunde memorización con naturalidade ordinaria, así que a fenda é a mellor estatística e a proba de continuación é aínda mellor. Dálle as seis primeiras palabras:

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 das cinco cadeas famosas continuaron palabra por palabra desde seis palabras; ningunha das cinco novas o fixo. Iso é un modelo de medio billón de parámetros recitando a licenza MIT. Se o teu benchmark está na web pública, asume que está nos weights. É tamén o argumento de todo o capítulo: un conxunto de ouro que escribiches a partir dos teus propios datos, mantido fóra de calquera repositorio que lea un crawler, é o único conxunto de proba do que podes ter certeza de que nunca se adestrou nel.

Aínda paga a pena lelos, sempre que leas que mide cada un en vez do único número que leva pegado.

Colle a táboa máis ca calquera fila. Os benchmarks agentic poñen as persoas moi por riba dos modelos, que é o contrario dos benchmarks de coñecemento e o mellor resumo nunha liña de onde está o campo; as súas cifras envellecen en meses, así que cítaas coa data na que as liches; e todos miden unha tarefa que non é a túa.

A exactitude é a métrica sobre a que discutes. Estas son as que deciden se a cousa se envía. As catro saen das duascentas execucións xa medidas.

Custo por tarefa resolta, non por chamada. O agent custa $0.001345 por intento e $0.005172 por tarefa realmente resolta: 3.85 veces máis, porque tres cuartos dos intentos non producen nada. A latencia compórtase igual: 1,213 ms por intento, 4,667 ms por tarefa resolta. Cada reintento, cada nova pregunta, cada traxectoria abandonada está no segundo número e é invisible no primeiro.

Un diagnóstico que supera a exactitude. En 123 de 200 intentos o agent respondeu sen chamar nin unha soa ferramenta: adiviñou en vez de mirar. Dividindo por iso:

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

Os intervalos nin se achegan a tocarse. Iso vale máis ca o 26 % agregado, porque nomea o que hai que arranxar: o modelo non está fallando en razoar, está fallando en mirar; e a solución está no harness, non no modelo. Unha advertencia que este capítulo debe aos seus propios estándares: os dous grupos son tarefas distintas, non as mesmas tarefas emparelladas, así que parte desa fenda pode deberse a que salta as ferramentas precisamente nas preguntas que lle parecen difíciles. A división é un diagnóstico, non unha afirmación causal.

A taxa de intervención humana é a métrica que un comprador pregunta primeiro: que fracción de execucións pararon nunha aprobación, nun guardrail ou nun handoff. As interrupcións tipadas do Capítulo 23 fan que se poida contar, e contada por tipo de tarefa e por semana é o que separa un agent que aprende o seu traballo dun que silenciosamente se converte nunha cola.

Abandono é a que ningunha suite offline pode ver: a persoa que leu a resposta, pechou a pestana e fixo a tarefa pola súa conta. A avaliación offline é unha porta; a avaliación en produción é unha mostra continua de tráfico real, puntuada co mesmo avaliador máis estas catro.

E unha regra herdada do Capítulo 17: nunca fagas assert sobre a saída exacta. Fai assert sobre propiedades: JSON válido, esquema correcto, a ferramenta axeitada chamada, un número dentro dunha tolerancia, unha substring requirida presente. A columna de coincidencia exacta ao comezo deste capítulo é o que pasa cando esa regra se rompe.

Avaliar un provedor non vai só de exactitude, e esta é a segunda metade da ética deste curso, co seu propio encabezado en vez dun apéndice.

Mide o sesgo, non o asumas. Sexa o que sexa que cres sobre o comportamento dun modelo con nomes, dialectos, xéneros ou nacionalidades, é unha propiedade medible do teu pipeline, e o instrumento é o que xa tes: colle o teu conxunto de ouro, varía só o atributo, compara pareado. HELM existe precisamente porque se estaba informando só de exactitude onde tamén se podían decidir sesgo, toxicidade, calibración e robustez.⁸ A model card dun provedor é un punto de partida, non evidencia sobre os teus inputs.

A contaminación tamén é unha pregunta para o provedor. A sonda de arriba é a razón para preguntar sobre que se mediu un número publicado, e cando se cortaron os datos do modelo.

Retención, adestramento e residencia, lido o 7 de setembro de 2026. Isto cambia, así que rexistra a data xunto á resposta. A páxina de política de Anthropic di: «Por defecto, non usaremos os teus inputs ou outputs dos nosos produtos comerciais (por exemplo Claude for Work, Anthropic API, Claude Gov, etc.) para adestrar os nosos modelos», coa excepción do contido que envíes explicitamente como feedback, que se almacena «ata 5 anos».¹⁶ A documentación de controis de datos de OpenAI di que «os datos enviados á OpenAI API non se usan para adestrar nin mellorar os modelos de OpenAI (a non ser que aceptes explicitamente compartir datos connosco)», describe unha retención predeterminada de trinta días para logs de monitorización de abuso, e ofrece Zero Data Retention, que «exclúe o contido do cliente dos logs de monitorización de abuso», máis residencia de datos configurable nunha lista de rexións.¹⁷

Catro preguntas para obter por escrito antes da primeira chamada de produción, porque cada unha ten un propietario distinto: úsanse os meus datos para adestramento; canto tempo se reteñen e por quen; onde se procesan e almacenan; e que lle pasa a todo iso se uso un revendedor, unha pasarela ou un agregador en vez do provedor directamente. Esa última é onde viven a maioría das sorpresas, e ningún benchmark cho dirá.

Agora tes o instrumento: un conxunto de ouro que posúes, un intervalo en cada número, unha proba pareada para cada comparación, pass^k para as execucións que non lle ensinaches a ninguén, un judge medido e unha sonda para saber se unha puntuación pública significa algo. A afirmación final do Capítulo 23 agora pode comprobarse en vez de afirmarse — un harness fai que un agent sexa gobernable, non correcto — e comprobalo levou duascentas execucións e oito minutos.

Hai unha propiedade dun agent que nada diso mide, e é a que fai que a xente perda o traballo.

Cada tarefa do conxunto de ouro deste capítulo foi escrita por min, e cada ficheiro que leu o agent foi escrito por min. Nada nese directorio intentaba facer nada. Cambia unha liña nun ficheiro que se lle di ao agent que lea — unha liña que remata cunha instrución dirixida a quen a lea a continuación — e o agent que puntuou 26 % seguiraa coas mesmas ferramentas, os mesmos permisos e o mesmo rastro limpo, e todos os números deste capítulo quedarán exactamente onde están. Unha suite de avaliación mide con que frecuencia un sistema chega ao teu obxectivo. Non mide con que facilidade alguén pode substituílo polo seu.

O Capítulo 30 é iso: prompt injection, a trifecta letal de datos privados, contido non fiable e comunicación externa, e que custa darlle permisos reais a un agent. Abre coa observación que este capítulo estivo evitando: que a mesma puntuación aprobada é compatible cun agent que fai exactamente o que un atacante escribiu nun ficheiro que se lle mandou ler.

Todos os números de arriba producíronse nunha máquina e ningún tocou un endpoint de pago. O agent é o bucle do Capítulo 23 con dúas das súas catro ferramentas sobre un directorio de cinco ficheiros; o modelo detrás do porto é Qwen/Qwen2.5-0.5B-Instruct, exposto a través dun pequeno servidor coa mesma forma ca un endpoint de chat completions exactamente como no Capítulo 23, pero en media precisión nunha GPU de consumo en vez da CPU daquel capítulo. Os custos usan as tarifas do Capítulo 16: $2.00 por millón de input tokens e $12.00 por millón de output, aplicadas aos recontos de token medidos. As execucións repetidas usan temperatura 0.7 con seeds fixas para que todo o conxunto se reproduza; a táboa de catro brazos é greedy. Os intervalos son Wilson ao 95 %, as comparacións pareadas son probas exactas de signos bilaterais sobre os pares discordantes; o intervalo de Wilson é o do Capítulo 4 e a proba exacta de signos pareada é a do Capítulo 15, ambos reutilizados sen cambios. As etiquetas humanas son miñas, aplicadas a sesenta respostas baixo a regra escrita citada no texto. Le cada magnitude aquí como unha propiedade dun modelo de medio billón de parámetros e cada método como transferible: un modelo maior sobe todos os números e non move ningún dos instrumentos.