41 Evaluación: medir sin engañarte
¿Quieres pasar de la lectura a una prueba? Elige una tarea y abre TAF con una ruta guiada.
Dónde estamos. Hemos entrenado (Parte IV), usado (Parte V), abaratado (Parte VI) y auditado por dentro (Caps. 37-39) un transformer. Falta la pregunta que decide todo lo demás: ¿cómo sabemos que un modelo es bueno? Evaluar es tan difícil —y tan fácil de hacer mal— como entrenar. Y encaja aquí, en la Parte VII, porque comparte su espina: casi todo lo que mides es un proxy imperfecto, y el mayor peligro no es medir poco, sino medir mal y creértelo.
Controlar el formato antes de interpretar la puntuación. El resolutor de plantillas distingue plantilla ausente en los archivos consultados, varias opciones sin predeterminada inequívoca y plantilla presente. Ver los pasos de comprobación propone revisar la selección y la conversación formateada manteniendo fijos modelo, prompt y generación. Encontrar una plantilla no prueba que el servidor la aplique bien ni explica por sí solo una respuesta incorrecta. Los tres ejemplos opcionales muestran estos estados sin ejecutar Jinja ni inferencia.
Tras repetir, indica si encontraste controles distintos, si la diferencia persiste al alinearlos o si desapareció. Registra esa observación en el seguimiento del resolutor para adaptar la siguiente comprobación. Es una declaración tuya; no modifica el análisis inicial.
41.1 La idea en una frase
Evaluar un LLM es estimar su capacidad con métricas que son proxies —ninguna la mide directamente—, así que saber evaluar consiste, sobre todo, en conocer las trampas: la contaminación de datos, el juez que se deja engañar y la ley de Goodhart.
41.2 Conceptos clave y su papel en el transformer
Antes de entrar en detalle, definimos los términos de este capítulo y para qué sirve cada uno:
- Perplejidad. Definición: \(e^{\text{pérdida}}\); “entre cuántos tokens duda” el modelo (Cap. 11). En el transformer: la métrica interna más barata —pero solo comparable con el mismo tokenizador, y no mide si el modelo es útil—.
- Benchmark. Definición: un conjunto fijo de tareas con respuesta conocida. En el transformer: la forma estándar de poner una cifra a una capacidad (conocimiento, código, mates, contexto largo).
- LLM-as-judge. Definición: usar otro LLM para puntuar respuestas abiertas. En el transformer: escala la evaluación humana, pero hereda sesgos (posición, verbosidad, auto-preferencia).
- Contaminación de datos. Definición: que el test se coló en el entrenamiento. En el transformer: infla la nota sin que el modelo sea mejor —la amenaza número uno a la validez—.
- Ley de Goodhart. Definición: “cuando una medida se vuelve objetivo, deja de ser buena medida”. En el transformer: optimizar para un benchmark degrada lo que el benchmark pretendía medir.
- Validez de constructo. Definición: si la métrica mide de verdad la capacidad que dices, o solo un atajo correlacionado. En el transformer: la pregunta de fondo de todo el capítulo.
- Rigor estadístico. Definición: barras de error, varias semillas, significancia. En el transformer: sin ellas, un “+2 %” puede ser ruido.
41.3 Por qué un capítulo entero
Ya vimos métricas de texto en el Cap. 29 (BLEU, ROUGE, el juez-LLM). Aquí subimos un nivel: evaluar el modelo entero. Y lo ponemos en la Parte VII a propósito, porque la evaluación es donde la honestidad del libro se juega de verdad: una cifra alta no prueba capacidad. El resto del capítulo es un recorrido por las métricas y por las formas en que cada una te puede engañar.
41.4 Perplejidad: la métrica interna (y sus límites)
La métrica más barata es la que ya tienes del entrenamiento (Cap. 11): la perplejidad, \(\text{PPL}=e^{\text{pérdida}}\). Mide la sorpresa media del modelo ante un texto: una PPL de 8 significa que, de media, duda “como entre 8 tokens”. Baja = predice mejor.
La PPL depende de cómo troceas el texto: un modelo con vocabulario grande parte el texto en menos tokens y sale con una PPL que no es comparable a la de otro modelo. Por eso, para comparar de verdad, se usa bits-per-byte (bpb), que normaliza por bytes de texto, no por tokens. Y aun así: una PPL baja no dice que el modelo sea útil —solo que predice bien el siguiente token—.
41.5 Benchmarks de capacidad: poner una cifra a lo que sabe hacer
Para medir capacidades concretas se usan benchmarks: baterías de tareas con respuesta conocida. Los grandes ejes de 2024-2026:
| Capacidad | Benchmarks de referencia | Qué miden |
|---|---|---|
| Conocimiento / razonamiento | MMLU (Hendrycks et al. 2021), MMLU-Pro, GPQA, BBH | preguntas de examen en 57 materias; GPQA, de nivel doctorado |
| Código | HumanEval (Chen et al. 2021), MBPP, SWE-bench (Jimenez et al. 2024) | escribir funciones que pasan tests; SWE-bench, resolver issues reales de GitHub |
| Matemáticas | GSM8K (Cobbe et al. 2021), MATH, AIME | problemas de palabras (GSM8K) y competición (MATH/AIME) |
| Contexto largo | NIAH (needle-in-a-haystack), RULER (Hsieh et al. 2024) | encontrar/usar información escondida en un contexto enorme |
| Chat / preferencia | Chatbot Arena (Elo), MT-Bench | qué respuesta prefieren los humanos, cara a cara |
Los benchmarks tienen fecha de caducidad: MMLU, durísimo en 2020, hoy lo superan los modelos frontera por encima del 92 % —techo—. La respuesta de la comunidad son sucesores mucho más difíciles: ARC-AGI-2 (Chollet et al. 2025) (razonamiento abstracto fluido, con baseline humano), Humanity’s Last Exam (Phan et al. 2025) (preguntas de nivel experto, creado precisamente porque MMLU se quedó fácil) y FrontierMath (Glazer et al. 2024) (matemáticas de investigación, donde los mejores modelos resuelven <2 %). La lección: un benchmark saturado ya no distingue modelos —hay que subir el listón—.
🧩 Analogía — el examen y el alumno. Un benchmark es un examen; la nota es un proxy de lo que el alumno sabe. Un examen bien hecho correlaciona con el saber real… hasta que el alumno consigue el examen por adelantado (contaminación) o estudia solo para ese examen (Goodhart). Entonces la nota sube y el saber no.
41.6 El espejismo del benchmark: la contaminación
Aquí está la amenaza número uno, y la razón por la que este capítulo vive en la Parte VII. Contaminación es que las preguntas del test aparecieron en el entrenamiento (los datos web son enormes y los benchmarks están en la web). El modelo entonces recuerda la respuesta en vez de razonarla: la nota sube, la capacidad real no se mueve.
Muévelo tú mismo. Sube el dial de contaminación y mira cómo la nota se dispara mientras la capacidad real se queda plana —el hueco es puro espejismo—:
No es un temor abstracto: hay métodos que detectan contaminación (p. ej. viendo si el modelo completa un test palabra por palabra, o comparando rendimiento antes/después de la fecha de corte (Golchin y Surdeanu 2024)). Ejemplo concreto: la auditoría de OpenAI sobre SWE-bench (OpenAI 2026) encontró que ~59 % de las tareas revisadas tenían tests defectuosos o indicios de contaminación —tanto, que dejaron de reportar esa métrica—. La regla honesta: una nota alta en un benchmark público, sin control de contaminación, no prueba nada. Los benchmarks serios se renuevan (nuevas versiones, conjuntos privados) precisamente por esto.
Y su primo cercano, la ley de Goodhart: en cuanto un benchmark se vuelve el objetivo (lo que decide titulares y financiación), los equipos optimizan para él —y deja de medir lo que medía—. Por eso ningún número aislado basta.
41.7 El juez es un LLM (y se le puede engañar)
Para respuestas abiertas (un ensayo, una respuesta de chat) no hay solución correcta única, así que se usa otro LLM como juez —o el voto humano cara a cara del Chatbot Arena (ranking Elo)—. Es potente y escala, pero el juez tiene sesgos que conviene conocer:
- Sesgo de posición: tiende a preferir la primera (o la segunda) respuesta por su orden. Se corrige promediando ambos órdenes.
- Sesgo de verbosidad: premia la respuesta más larga, aunque no sea mejor.
- Auto-preferencia: un juez tiende a puntuar más alto el estilo de su propia familia de modelos.
- Adulación (sycophancy) (Sharma et al. 2023): los modelos tienden a darte la razón; un juez puede premiar la respuesta que suena segura y agradable sobre la correcta.
🧩 Analogía — el tribunal cansado. Un juez-LLM es como un tribunal que, sin querer, puntúa mejor al que habla primero, al que se extiende más y al que se le parece. Útil para mucho volumen, pero hay que controlar esos sesgos, no fiarse a ciegas.
41.8 Rigor estadístico: ¿ese “+2 %” es real?
Un último engaño, más silencioso: casi ningún número de modelo viene con barra de error. Pero cambiar la semilla, el orden de los ejemplos few-shot o la plantilla de prompt mueve la nota varios puntos. Un “+2 % en MMLU” sin intervalo de confianza puede ser puro ruido. Lo honesto: reportar varias semillas, barras de error y significancia antes de cantar victoria.
41.9 Un laboratorio común para contexto y compresión
Un número de acierto es como el tiempo de una carrera: sin saber la distancia y el terreno, compararlo con otro puede engañar. Para enlazar el contexto de ?sec-contexto-evidencia con la caché de Sección 21.6, publica la ficha de la carrera, no solo el marcador.
- Congela el modelo y la tarea. Revisión de pesos, tokenizador, plantilla de chat, motor, precisión, parámetros de generación y conjunto de preguntas. Reserva ejemplos que no uses para elegir el presupuesto de caché.
- Varía una dificultad cada vez. Longitud, posición, relleno, cantidad y dispersión de evidencia, o pasos de razonamiento. Declara qué se mantuvo fijo. Los diseños de LURCH y CRE motivan estos controles (Qin et al. 2026; Zhang et al. 2026).
- Obtén una referencia con caché completa. Después compara políticas de compresión a memoria efectiva igualada. Distingue prefill, decode, bytes de KV y memoria total.
- Puntúa por tarea y por ejemplo. Recuperación, integración y razonamiento necesitan recibos propios. Usa las mismas preguntas a ambos lados de la comparación; guarda resultados individuales y estima la incertidumbre remuestreando preguntas completas.
- Publica también lo que no salió. OOM, tareas sin ejecutar y configuraciones no soportadas son estados distintos de un acierto cero. Conserva los fallos reales para que el promedio no oculte qué comportamiento se perdió.
Si la caché completa acierta 80 de 100 preguntas y la comprimida 72 de las mismas 100, la diferencia es \(72\%-80\%=-8\) puntos porcentuales, y la retención relativa es \(72/80=90\%\). Son dos resúmenes distintos de un ejemplo inventado. Para saber si el cambio es estable necesitas los pares de acierto por pregunta: 80 y 72 por sí solos no bastan para calcular la incertidumbre de la diferencia pareada.
Conexión con TAF. Añade γ observado, intervalo, rango de ajuste y versión del protocolo como descriptores, siguiendo Capítulo 47. Una correlación con el acierto puede orientar una hipótesis; un predictor útil necesita evaluación en modelos y tareas no usados para ajustarlo. Ni R² ni una puntuación de cobertura de evidencia son una probabilidad calibrada de que una respuesta sea correcta.
41.9.1 Acompañar una diferencia entre evaluaciones
El resolutor de diferencias de TAF recibe dos puntuaciones en escala 0–100 y unos ajustes declarados. La casilla de comparabilidad es una declaración del usuario: no comprueba versiones de tarea, particiones, muestras ni métricas. Su banda numérica es heurística, no un intervalo de confianza ni un test de significación.
Ver los pasos de comprobación decide qué revisar primero: aplicación de plantilla desconocida, estados distintos de aplicación, cambios de motor/precisión/ lote y, después, repetición o estimación de incertidumbre. Esta prioridad se mantiene aunque las puntuaciones sean iguales. Dos estados «aplicada» no prueban que las plantillas ni las conversaciones formateadas sean idénticas.
Fija una referencia común, cambia un ajuste cada vez y conserva resultados por ejemplo cuando estén disponibles. Registra revisiones de modelo y tokenizador, versión de tarea, muestras, semillas, generación y entradas formateadas. Una diferencia menor tras el cambio es evidencia para investigar; no certifica una reparación ni atribuye por sí sola la causa a un kernel o a la plantilla.
Demo opcional: cinco situaciones ilustran estas prioridades en Explorar otro ejemplo. Las puntuaciones son sintéticas, no evaluaciones ejecutadas. El manual de lm-evaluation-harness describe cómo registrar configuración, semillas y muestras; comprueba las opciones de tu versión. Los resultados agregados de TAF no sustituyen esos registros ni un análisis de incertidumbre adecuado a la métrica.
41.10 Puente con nuestro tema (breve y honesto)
Aquí la evaluación toca directamente el libro. Nuestra afirmación de ingeniería estrella —la ventana D_f derivada de γ (Cap. 20)— está sin validar (el intento avenue-2 crasheó por falta de memoria, Cap. 19). El lugar donde dejaría de ser una hipótesis es exactamente este: un benchmark de contexto largo (NIAH / RULER (Hsieh et al. 2024)) comparando la retención de KV con D_f frente a las heurísticas del campo (Ada-KV, LAVa). Dicho con todas las letras: la evaluación es la casa donde nuestra propia tesis se pone a prueba —no es solo un tema más—.
tafagent trae dos diagnósticos de evaluación que atacan justo las trampas de este capítulo: el Contamination Prior (estima el riesgo de que un modelo haya visto un benchmark) y LongScore (mide contexto largo real con RULER, no la longitud anunciada). Antes de creerte una tabla de resultados, pásala por aquí.
41.11 Resumen
Laboratorio: condiciones declaradas, caché completa como referencia, resultados pareados e incertidumbre; una tarea no ejecutada no equivale a un fallo del modelo.
Evaluar = medir con proxies imperfectos. Ninguna métrica mide la capacidad directamente; saber evaluar es conocer las trampas.
Perplejidad (\(e^{\text{pérdida}}\)): barata e interna, pero no comparable entre tokenizadores (usa bits-per-byte) y no dice si el modelo es útil.
Benchmarks por capacidad: conocimiento (MMLU/GPQA), código (HumanEval/SWE-bench), mates (GSM8K/MATH), contexto largo (NIAH/RULER), chat (Arena/Elo).
Contaminación: el test se coló en el entrenamiento → la nota sube, la capacidad no (espejismo). Con la ley de Goodhart: optimizar para un benchmark lo estropea.
LLM-as-judge: escala, pero con sesgos de posición, verbosidad, auto-preferencia y adulación —contrólalos—.
Rigor: sin barras de error y varias semillas, un “+2 %” puede ser ruido.
Puente: la evaluación de contexto largo (RULER/NIAH) es donde nuestra ventana D_f debe validarse —aún pendiente—.
Siguiente (Capítulo 41): cerramos el libro con lo que ninguna métrica captura del todo —ética, seguridad y limitaciones—: sesgos, alucinación, uso responsable y, sobre todo, lo que aún no sabemos.
41.12 Ejercicios
- Perplejidad. ¿Por qué dos modelos con distinto tokenizador no se pueden comparar por perplejidad? ¿Qué métrica lo arregla y por qué?
- El espejismo. Explica, con el widget de este capítulo, por qué una nota alta en un benchmark público no prueba capacidad. ¿Qué es la contaminación?
- Goodhart. Da un ejemplo de cómo optimizar para un benchmark podría empeorar el modelo en la capacidad que el benchmark pretendía medir.
- El juez. Nombra tres sesgos del LLM-as-judge y cómo se mitiga cada uno.
- Rigor. Un paper reporta “+1,5 % en MMLU” sin barras de error. ¿Qué le preguntas antes de creerlo?
- Contexto largo. ¿Por qué RULER/NIAH es el sitio natural para validar (o refutar) nuestra ventana D_f del Cap. 20?