Evaluación de LLM: de los benchmarks públicos a tu golden set

Casi toda discusión sobre evaluación son dos personas midiendo cosas distintas. Hay tres proyectos y no comparten instrumento.

La confusión sale cara en una dirección. Un leaderboard te dice que un model es fuerte en razonamiento de posgrado; no puede decirte si enrutará tus tickets de soporte. Y una evaluación de aplicación que puntúa una respuesta por entrada no puede ver un agent en absoluto, porque un agent tiene una distribución de trayectorias y una respuesta es una sola muestra de ella. El Capítulo 22 nombró esa tercera fila y la dejó vacía: la medida de rendimiento, la única parte de la especificación de un agent que los equipos escriben al final o nunca.

El orden también importa, y el proveedor que te vende el model lo dice. La guía de agents de OpenAI reduce la selección de model a tres pasos, en este orden: "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".¹ La evaluación va primero, porque los pasos dos y tres no significan nada sin un número.

Un golden set es una lista de entradas, cada una con la respuesta escrita, y un evaluador que decide si una salida coincide. Es aburrido, es pequeño, y es el único artefacto de este capítulo que es tuyo. El que se construye aquí tiene veinte tareas sobre un directorio de cinco archivos —no los tres del Capítulo 23, así que las respuestas no son las mismas— y el evaluador se escribe antes de que el agent se ejecute:

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

Dos propiedades sostienen la carga. La lista mustNot existe porque un model que nombra tres archivos, incluido el correcto, no ha respondido. Y answer está escrito en prosa además de en patrones, porque una persona y un juez lo necesitarán más tarde; y escribir el mismo hecho dos veces en dos notaciones es la forma de descubrir que no estabas de acuerdo contigo mismo sobre cuál era la tarea.

Ahora la tabla que decide. Cuatro sistemas candidatos, las mismas veinte tareas, accuracy con su intervalo, y las dos columnas que una tabla solo de accuracies siempre oculta:

Lee los intervalos antes que el ganador. Las ejecuciones del brazo B van del 11 % al 47 %; las del brazo A, del 3 % al 30 %. Se solapan durante la mayor parte de su longitud, que es el hallazgo del Capítulo 4 llegando exactamente donde se prometió: veinte casos no pueden ordenar cuatro sistemas. El Capítulo 15 lo afinó haciendo la pregunta emparejada en su lugar —de los casos donde dos brazos discrepan, ¿cuánto se inclina el reparto?— porque la dificultad compartida del conjunto se cancela. Aquí están todos los 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

Ninguna de las seis comparaciones queda establecida. El mejor brazo supera al brazo sin herramientas por quince puntos, y eso descansa sobre tres casos discordantes. Veinte casos muestran un mecanismo y no pueden elegir un proveedor; decir lo contrario en una reunión es la forma en que se compra un mal model.

Hay una cosa que esta tabla sí establece, y es la columna que nadie incluye. El brazo D cuesta trece veces más que el brazo B por tarea resuelta, porque muestrear tres trayectorias y tomar la respuesta modal triplica la factura, triplique o no la accuracy. Las tablas de accuracy que omiten el coste vuelven invisible esa compensación.

Ahora el hallazgo que cambia cómo lees cualquier benchmark que vuelvas a ver. Toma las mismas doscientas transcripciones —veinte tareas, diez ejecuciones, ni un token regenerado— y puntúalas de tres formas:

Cero, trece, veintiséis. El sistema no cambió. Cambió el evaluador. La coincidencia exacta devuelve cero no porque el agent sea inútil, sino porque ninguna respuesta de texto libre es byte a byte idéntica a una referencia: mide formato y lo informa como capacidad.

Eso no es una curiosidad, es un mecanismo, y tiene nombre. Una métrica de corte duro puntúa una tarea todo-o-nada sobre varios subhechos, así que los compone. La tarea t12 pide tres códigos de estado a la vez. En las diez ejecuciones:

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

Cada hecho acierta alrededor de tres cuartas partes de las veces; exigir los tres a la vez reduce la puntuación a la mitad, y $0.77^3 = 0.457$ está lo bastante cerca del 0.50 medido como para mostrar de dónde vino la caída. Generaliza:

Lee la fila 0.90 frente a la fila 0.95 en $k = 10$: una mejora por hecho de cinco puntos se convierte en veinticinco puntos en la conjunción. No le ocurrió nada discontinuo al model. Una curva suave leída a través de una métrica todo-o-nada parece un salto, que es precisamente el argumento que Schaeffer, Miranda y Koyejo formularon sobre las capacidades emergentes, y que el Capítulo 10 aplazó hasta aquí.² Su auditoría descubrió que como mucho 5 de las 39 métricas preferidas de BIG-Bench muestran emergencia, y que dos métricas discontinuas explican más del 92 % de los casos afirmados.

Así que la disciplina, en una línea: un salto en una gráfica es evidencia sobre la métrica hasta que se demuestre lo contrario. Antes de creer que ha aparecido una capacidad, grafica las mismas ejecuciones con una métrica que otorgue crédito parcial y comprueba si el precipicio sobrevive.

Hay una versión de segundo orden de esto que Kalai y sus colegas sostienen que está haciendo daño aguas arriba: los benchmarks puntuados como correcto-o-incorrecto recompensan adivinar frente a decir "no lo sé", así que un model optimizado contra ellos aprende a adivinar. Su solución propuesta no es otro benchmark de alucinaciones, sino "modifying the scoring of existing benchmarks that are misaligned but dominate leaderboards".³ Tu golden set tiene la misma palanca, y es una línea: decidir si una abstención cuenta como fallo o como su propia categoría. La mayoría de la gente nunca lo decide, así que cuenta silenciosamente como fallo, y el sistema que envían adivina.

Hasta ahora todo ha puntuado un intento por tarea. Un agent no es un intento. El Capítulo 17 estableció que no tienes determinismo ni siquiera a temperatura cero, así que la misma entrada produce una distribución de trayectorias y un benchmark que ejecuta cada tarea una vez informa de una muestra de ella.

La contribución de τ-bench es la métrica para eso. El paper la define con claridad: "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."⁴ Ejecuta cada tarea $n$ veces, cuenta los $c$ éxitos, y los estimadores insesgados son:

El segundo es el familiar pass@k de generación de código: la probabilidad de que al menos uno de $k$ intentos tenga éxito. Ponlos uno junto al otro sobre los mismos recuentos medidos y se mueven en direcciones opuestas:

Mismas ejecuciones, mismo evaluador, mismas veinte tareas. Una columna dice que el sistema mejora con más intentos y la otra dice que empeora, y ambas son correctas, porque responden preguntas distintas. pass@k es la métrica adecuada cuando una persona filtra la salida —generación de código, borradores, brainstorming— y los intentos adicionales son baratos. pass^k es la métrica adecuada cuando el agent actúa sin filtro, que es lo que significa "agent". Publicar la primera donde aplica la segunda es la exageración más común en este campo, y el propio titular de τ-bench es la versión honesta: gpt-4o, con alrededor de un 61 % en pass^1 en retail, cae a alrededor del 25 % en pass^8.⁴

Ahora el aguijón en mis propios números. pass^10 sobre mis veinte tareas es 5.0 %: exactamente una tarea de veinte resuelta en las diez ejecuciones. Esa tarea es t19, "Did deploy 42 succeed?", y aquí hay dos de las diez respuestas que la rúbrica puntuó 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."

La primera nunca responde. La segunda añade una afirmación falsa: deploy 41 se revirtió. Ambas coincidieron con /succe|yes/. La única tarea que mantiene pass^10 por encima de cero es un artefacto del evaluador, así que la cifra real es cero, y ningún agregado me lo habría mostrado. Muestrear las transcripciones detrás de tu tarea con mejor puntuación es donde los evaluadores van a morir.

Y un número más, el que da nombre a esta sección. Diez evaluaciones idénticas —mismo sistema, mismas veinte tareas, mismo código, nada cambiado salvo las semillas:

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 treinta puntos en un sistema que no cambió. Si ejecutas tu suite una vez antes de una release y otra después, una "mejora" de ocho puntos está dentro de esa dispersión y la enviarás creyendo que la causaste tú. Por eso el intervalo agrupado anterior —26.0 % [20.4, 32.5]— es demasiado estrecho para citarlo solo: trata doscientos ensayos correlacionados como si fueran doscientos independientes. El resumen honesto de una evaluación de agent es una media y una dispersión entre repeticiones, y casi nadie publica lo segundo.

Las rúbricas no escalan a respuestas abiertas, así que el movimiento estándar es hacer que un model califique la salida. Funciona lo bastante bien a escala frontier como para ser el valor por defecto, y tiene tres modos de fallo con nombre: sesgo de posición, sesgo de verbosidad y sesgo de autoensalzamiento.⁵

Mídelo antes de confiar en él. Las mismas sesenta respuestas —tres de las diez ejecuciones— se etiquetaron de tres formas. La etiqueta humana es mía: leí las sesenta con los cinco archivos abiertos y apliqué una regla escrita, pasa si y solo si la respuesta afirma el hecho que la pregunta pedía y no contiene nada contradicho por los archivos.

El juez dijo PASS sesenta veces de sesenta. Habría informado de este agent con un 100 % de accuracy en un conjunto donde la persona lo puntúa en un 18 %. Un juez sin poder discriminativo no es un instrumento ruidoso; es una función constante, y una función constante da la misma puntuación a tu mejor sistema que a tu peor sistema.

El prompting no lo rescató. Cuatro variantes, los mismos sesenta ítems:

Intercambiar el orden de las dos etiquetas en la instrucción movió cuatro veredictos. Es un efecto medible y es el tipo de efecto equivocado: el juez responde a la forma del prompt en lugar de a la respuesta que tiene delante.

La demostración limpia es por pares. Veinte preguntas, cada una con un candidato claramente correcto y otro claramente incorrecto, presentados en ambos órdenes:

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 %

Eligió la posición A cuarenta veces de cuarenta. El 50 % en corrección no es competencia parcial: es aritmética, porque la respuesta correcta está en la posición A exactamente en la mitad de los ensayos. La consistencia aquí se define como la define MT-Bench, "the percentage of cases where a judge gives consistent results when swapping the order of two assistants", lo que permite que la comparación sea justa: GPT-4 obtiene 65.0 % en esa medida, y el few-shot prompting la elevó a 77.5 %.⁵ El mío obtiene cero.

La mitigación estándar también viene de ese 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."⁵ Aplícala aquí y el juez produce cero veredictos utilizables de veinte pares, que es el resultado correcto, e infinitamente mejor que veinte veredictos seguros.

Una nota metodológica que vale más que el resultado. También ejecuté una prueba de verbosidad: la misma respuesta correcta, con una copia rellenada con una frase de 36 palabras que no añade nada. El juez prefirió la versión larga exactamente en el 50 % de los ensayos, lo que parece una ausencia de sesgo de verbosidad y no lo es en absoluto, porque un juez que siempre elige la posición A obtiene un 50 % en cualquier emparejamiento equilibrado. No puedes medir un segundo sesgo hasta controlar el primero. Intercambiar posiciones no es un refinamiento para añadir más tarde; es lo que vuelve interpretable cualquier otra medición.

La salvedad honesta: este juez es un model de quinientos millones de parámetros, y nadie debería calificar con uno. La cuestión no es que los jueces sean malos. Es que los números anteriores costaron ocho minutos de producir, y sin ellos el veredicto de este juez sobre una decisión de envío habría sido 100 %.

Este es el tercer y último panel declarado de Python del curso, y la razón está en dónde vienen los números públicos. lm-evaluation-harness cubre "over 60 standard academic benchmarks for LLMs, with hundreds of subtasks and variants implemented" y es "the backend for Hugging Face's popular Open LLM Leaderboard"; HELM, SWE-bench y τ-bench son paquetes de Python con puntos de entrada en Python.⁶ Ejecutar tu model contra una cifra publicada significa ejecutar su código, y el día que quieras comparar con un número que alguien citó, este es el ecosistema en el que estás:

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

La segunda razón es que una medición de este capítulo es imposible por HTTP. Contaminación —que el conjunto de test se haya filtrado a los datos de entrenamiento— es el fallo que vuelve silenciosamente insignificante un benchmark público, y la sonda más afilada para detectarlo necesita la pérdida propia del model, que ninguna API de chat devuelve. Es la cross-entropy por token del Capítulo 8, dirigida a una 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)

Diez pares de frases: cinco en cada rastreo de la web desde que existe, cinco escritas para este capítulo esta mañana, cada una emparejada con una versión reformulada que conserva el mismo contenido.

El model se sorprende cuatro veces más ante una frase escrita esta mañana que ante una que ha visto un millón de veces, y reformular cuesta el doble en las famosas: ese coste extra es la parte memorizada en lugar de entendida. La pérdida absoluta confunde memorización con naturalidad ordinaria, así que la brecha es la mejor estadística, y la prueba de continuación es aún mejor. Dale las seis primeras 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 de las cinco cadenas famosas continuaron palabra por palabra desde seis palabras; ninguna de las cinco nuevas lo hizo. Eso es un model de quinientos millones de parámetros recitando la licencia MIT. Si tu benchmark está en la web pública, asume que está en los pesos. También es el argumento de todo el capítulo: un golden set que escribiste con tus propios datos, mantenido fuera de cualquier repositorio que lea un crawler, es el único conjunto de test del que puedes estar seguro de que nunca se entrenó.

Siguen mereciendo la pena leerse, siempre que leas qué mide cada uno en lugar del número único que lleva asociado.

Quédate con la tabla, no con una fila. Todos los benchmarks agentic sitúan a los humanos muy por encima de los models, que es lo contrario que los benchmarks de conocimiento y el mejor resumen en una línea de dónde está el campo; sus cifras envejecen en meses, así que cítalas con la fecha en que las leíste; y todos miden una tarea que no es la tuya.

Accuracy es la métrica sobre la que discutes. Estas son las que deciden si la cosa se envía. Las cuatro salen de las doscientas ejecuciones ya medidas.

Coste por tarea resuelta, no por llamada. El agent cuesta $0.001345 por intento y $0.005172 por tarea realmente resuelta: 3.85 veces más, porque tres cuartas partes de los intentos no producen nada. La latencia se comporta igual: 1,213 ms por intento, 4,667 ms por tarea resuelta. Cada retry, cada repregunta, cada trayectoria abandonada está en el segundo número y es invisible en el primero.

Un diagnóstico que supera a la accuracy. En 123 de 200 intentos, el agent respondió sin llamar a una sola herramienta: adivinó en lugar de mirar. Al dividir por eso:

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

Los intervalos ni siquiera se acercan a tocarse. Eso vale más que el 26 % agregado, porque nombra lo que hay que arreglar: el model no está fallando al razonar, está fallando al mirar, y la solución está en el harness, no en el model. Una salvedad que este capítulo debe a sus propios estándares: los dos grupos son tareas distintas, no las mismas tareas emparejadas, así que parte de esa brecha puede deberse a que se salta las herramientas precisamente en las preguntas que le parecen difíciles. La división es un diagnóstico, no una afirmación causal.

La tasa de intervención humana es la métrica que un comprador pregunta primero: qué fracción de ejecuciones se detuvo en una aprobación, un guardrail o un handoff. Las interrupciones tipadas del Capítulo 23 hacen que sea contable, y contada por tipo de tarea y por semana es lo que separa a un agent que aprende su trabajo de uno que se convierte silenciosamente en una cola.

El abandono es lo que ninguna suite offline puede ver: el usuario que leyó la respuesta, cerró la pestaña e hizo la tarea por su cuenta. La evaluación offline es una puerta; la evaluación en producción es una muestra continua de tráfico real, puntuada con el mismo evaluador más estas cuatro.

Y una regla heredada del Capítulo 17: nunca hagas aserciones sobre la salida exacta. Haz aserciones sobre propiedades: JSON válido, esquema correcto, la herramienta adecuada llamada, un número dentro de la tolerancia, un substring requerido presente. La columna de coincidencia exacta al principio de este capítulo es lo que ocurre cuando se rompe esa regla.

Evaluar a un proveedor no va solo de accuracy, y esta es la segunda mitad de la ética de este curso, con su propio encabezado en lugar de un apéndice.

Mide el sesgo, no lo presupongas. Creas lo que creas sobre el comportamiento de un model con nombres, dialectos, géneros o nacionalidades, es una propiedad medible de tu pipeline, y el instrumento es el que ya tienes: toma tu golden set, varía solo el atributo, compara emparejado. HELM existe precisamente porque se informaba solo de accuracy cuando sesgo, toxicidad, calibración y robustez también eran decidibles.⁸ La model card de un proveedor es un punto de partida, no evidencia sobre tus entradas.

La contaminación también es una pregunta para el proveedor. La sonda anterior es la razón para preguntar sobre qué se midió una cifra publicada y cuándo se cortaron los datos del model.

Retención, entrenamiento y residencia, leído el 7 de septiembre de 2026. Estas cosas cambian, así que registra la fecha junto a la respuesta. La página de políticas de Anthropic afirma: "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", con la excepción del contenido que envías explícitamente como feedback, que se almacena "for up to 5 years".¹⁶ La documentación de controles de datos de OpenAI afirma 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)", describe una retención por defecto de treinta días para logs de monitorización de abusos y ofrece Zero Data Retention, que "excludes customer content from abuse monitoring logs", además de residencia de datos configurable en una lista de regiones.¹⁷

Cuatro preguntas para obtener por escrito antes de la primera llamada en producción, porque cada una tiene un propietario distinto: ¿se usan mis datos para entrenamiento? ¿cuánto tiempo se retienen y quién los retiene? ¿dónde se procesan y almacenan? ¿y qué ocurre con todo eso si uso un revendedor, una pasarela o un agregador en lugar del proveedor directamente? Esa última es donde viven la mayoría de las sorpresas, y ningún benchmark te la dirá.

Ahora tienes el instrumento: un golden set que posees, un intervalo en cada número, un test emparejado para cada comparación, pass^k para las ejecuciones que no enseñaste a nadie, un juez medido y una sonda para saber si una puntuación pública significa algo. La afirmación final del Capítulo 23 ya puede comprobarse en lugar de enunciarse —un harness hace que un agent sea gobernable, no correcto— y comprobarlo requirió doscientas ejecuciones y ocho minutos.

Hay una propiedad de un agent que nada de eso mide, y es la que hace que despidan a la gente.

Cada tarea del golden set de este capítulo la escribí yo, y cada archivo que leyó el agent lo escribí yo. Nada en ese directorio intentaba hacer nada. Cambia una línea en un archivo que se le dice al agent que lea —una línea que termina con una instrucción dirigida a lo que sea que la lea después— y el agent que obtuvo un 26 % la seguirá con las mismas herramientas, los mismos permisos y la misma traza limpia, y cada número de este capítulo permanecerá exactamente donde está. Una suite de evaluación mide con qué frecuencia un sistema alcanza tu objetivo. No mide con qué facilidad otra persona puede sustituirlo por el suyo.

El Capítulo 30 es eso: prompt injection, la trifecta letal de datos privados, contenido no confiable y comunicación externa, y lo que cuesta darle a un agent permisos reales. Abre con la observación que este capítulo ha estado evitando: que la misma puntuación de aprobado es compatible con un agent que hace exactamente lo que un atacante escribió en un archivo que se le dijo que leyera.

Todos los números anteriores se produjeron en una máquina y ninguno tocó un endpoint de pago. El agent es el bucle del Capítulo 23 con dos de sus cuatro herramientas sobre un directorio de cinco archivos; el model detrás del puerto es Qwen/Qwen2.5-0.5B-Instruct, expuesto mediante un pequeño servidor con la misma forma que un endpoint de chat completions exactamente como en el Capítulo 23, pero en media precisión en una GPU de consumo en lugar de la CPU de aquel capítulo. Los costes usan las tarifas del Capítulo 16 —$2.00 por millón de input tokens y $12.00 por millón de output— aplicadas a recuentos de token medidos. Las ejecuciones repetidas usan temperatura 0.7 con semillas fijas para que todo el conjunto se reproduzca; la tabla de cuatro brazos es greedy. Los intervalos son Wilson al 95 %, las comparaciones emparejadas son tests exactos de signos bilaterales sobre los pares discordantes; el intervalo de Wilson es el del Capítulo 4 y el test exacto de signos emparejado es el del Capítulo 15, ambos reutilizados sin cambios. Las etiquetas humanas son mías, aplicadas a sesenta respuestas bajo la regla escrita citada en el texto. Lee cada magnitud aquí como propiedad de un model de quinientos millones de parámetros y cada método como transferible: un model mayor sube todos los números y no mueve ninguno de los instrumentos.