41 Evaluación: medir sin engañarte
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.
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 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.10 Resumen
- 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.11 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?