La evaluación de modelos de lenguaje

La evaluación de un modelo de lenguaje es el procedimiento repetible con el que se decide si su salida sirve para algo. La palabra que importa en esa frase es repetible: mirar una respuesta y encontrarla buena no es evaluar, es opinar, y la opinión no se puede comparar con la de ayer ni permite decidir si el cambio que se hizo esta mañana mejoró o empeoró el sistema. Todo lo que se cuenta aquí existe para convertir esa opinión en un número que dos personas distintas obtendrían por separado y que la misma persona obtendrá igual la semana que viene.

La dificultad de fondo se enuncia en una línea. Un programa tradicional se prueba comparando lo que devuelve con lo que debía devolver, y esa comparación es una igualdad; un generador de texto tiene infinitas salidas correctas y ninguna canónica. Dos traducciones de la misma frase pueden ser ambas impecables y no compartir una sola palabra. Escribir una prueba automática para eso exige decidir antes qué se está midiendo, y ahí empieza el trabajo: no en el código del test, sino en la definición de lo que se considera bueno.

La respuesta más antigua a ese problema no viene del aprendizaje automático sino de la documentación. En los años sesenta, Cyril Cleverdon dirigió en el College of Aeronautics de Cranfield una serie de experimentos para comparar sistemas de indización, y montó lo que desde entonces es el esqueleto de cualquier evaluación: una colección fija de documentos, un conjunto fijo de consultas y un juicio humano de relevancia para cada par documento-consulta. Con esas tres piezas, dos sistemas de recuperación se pueden ordenar sin discutir. Los experimentos de Cranfield fueron polémicos, y la crítica que recibieron sigue siendo la crítica que recibe cualquier evaluación: los juicios de relevancia los hacen unas personas concretas con un criterio concreto, las consultas no son las que hará un usuario real y la colección no es el mundo. Cleverdon nunca sostuvo lo contrario. Su argumento era otro y sigue en pie: una medida imperfecta pero constante permite detectar diferencias entre sistemas, que es una pregunta mucho más modesta y mucho más útil que «¿es bueno este sistema?».

Esa distinción entre medir la calidad y medir la diferencia recorre todo lo que sigue. Casi ninguna evaluación de un sistema de lenguaje dice la verdad sobre su calidad absoluta; casi todas las buenas dicen la verdad sobre el signo de un cambio.

Cuando la traducción automática estadística empezó a necesitar iteración rápida, a principios de siglo, el problema de Cranfield reapareció con una vuelta de tuerca: aquí no hay que ordenar documentos, hay que puntuar una frase generada. La solución que se impuso, BLEU, la publicaron Papineni y sus colegas de IBM en 2002 y consiste en algo deliberadamente burdo: recoger varias traducciones humanas de la misma frase, contar cuántos grupos de una, dos, tres y cuatro palabras de la traducción automática aparecen en alguna de ellas, y penalizar las salidas demasiado cortas. No entiende nada; cuenta coincidencias. Dos años después Chin-Yew Lin publicó ROUGE con la misma idea aplicada a los resúmenes, invirtiendo el énfasis hacia la cobertura de las referencias en lugar de la precisión de la salida.

Conviene entender por qué estas medidas, que todo el mundo sabe que son groseras, dominaron la investigación durante quince años, porque la razón no ha caducado. No son buenas: correlacionan razonablemente con el juicio humano cuando se promedian sobre cientos de frases y casi nada cuando se aplican a una sola. Son, en cambio, gratis, instantáneas, deterministas y públicas, y eso permite que un equipo pruebe cuarenta variantes de un sistema en una tarde y que otro equipo, en otro continente, reproduzca la cifra exactamente. Una medida mediocre con esas cuatro propiedades mueve un campo entero; una medida excelente que cuesta dos semanas de trabajo humano por ejecución no mueve nada. La tensión entre esos dos polos es la decisión central del diseño de cualquier sistema de evaluación, y no se resuelve eligiendo un polo sino colocando medidas de los dos tipos en capas distintas.

La perplejidad, la otra cifra clásica, mide algo distinto que se confunde a menudo con lo anterior: cuánta sorpresa le produce al modelo el texto real que viene a continuación. Es una propiedad del modelo sobre un corpus, no de una respuesta sobre una tarea. Sirve para saber si un entrenamiento va bien y no sirve para saber si un asistente contesta lo que le preguntan. Un modelo puede bajar su perplejidad y empeorar en todo lo que le importa a quien lo usa.

Con los modelos instruidos llegó la era de los bancos de pruebas de opción múltiple, que resolvieron el problema de la puntuación por la vía de eliminarlo: si la respuesta correcta es una letra, comparar es trivial. GLUE y SuperGLUE reunieron tareas de comprensión; MMLU juntó cincuenta y siete materias de examen; BIG-bench acumuló cientos de tareas propuestas por la comunidad; HELM, el proyecto de Stanford dirigido por Percy Liang, fue el primero en insistir en evaluar cada modelo en varios escenarios con varias métricas a la vez —exactitud, calibración, robustez, sesgo, toxicidad, eficiencia— y en publicar la matriz entera en lugar de un número. Ese formato de examen tiene una virtud enorme, la comparabilidad, y tres defectos que la última hornada de investigación ha documentado con detalle.

El primero es de validez. Un examen de opción múltiple sobre biología mide la capacidad de elegir entre cuatro opciones en un examen de biología, y el salto de ahí a «comprensión del lenguaje» es una afirmación que hay que justificar, no un sinónimo. Raji y sus coautoras lo argumentaron en 2021 con el título más elocuente de la literatura, AI and the Everything in the Whole Wide World Benchmark, y Abigail Jacobs y Hanna Wallach habían formulado el mismo año la herramienta para analizarlo: la validez de constructo, un concepto prestado de la psicometría que obliga a distinguir entre el fenómeno que se quiere medir y el número que se mide. El trabajo más sistemático es reciente: Bean, Kearns, Romanou y una cuarentena de coautores revisaron en 2025 las cuatrocientas cuarenta y cinco pruebas presentadas en las principales conferencias del campo y encontraron que en la mayoría el fenómeno medido no está definido, o está definido de forma que la tarea elegida no lo representa, y que el contraste estadístico entre dos sistemas casi nunca se hace.

El segundo defecto es la contaminación. Un examen público acaba, antes o después, dentro de los datos de entrenamiento del siguiente modelo, y entonces deja de medir capacidad para medir memoria. El fenómeno tiene una versión sutil que no exige copiar el examen: el estudio The Leaderboard Illusion, dirigido por Shivalika Singh en 2025, documentó cómo funciona la arena pública de comparaciones por votación. Unos pocos proveedores prueban en privado decenas de variantes de un modelo antes de publicar y solo revelan la mejor, lo que convierte la puntuación en un máximo sobre muchos intentos en vez de en una medición; y el acceso a los datos de la propia arena está muy desigualmente repartido, de modo que entrenar con esos datos mejora hasta un ciento doce por ciento el resultado en la distribución de la arena sin mejorar en las pruebas académicas generales. Es decir: se puede subir en la tabla sin mejorar en nada más que en la tabla.

El tercer defecto es el más incómodo porque no admite arreglo por integridad: la fragilidad de la medición misma. Melanie Sclar y sus coautores mostraron en 2024 que cambiar detalles del formato del prompt que ninguna persona consideraría relevantes —dos puntos en lugar de una barra, un salto de línea, el orden de los separadores— mueve la exactitud de un modelo hasta setenta y seis puntos en la misma tarea con los mismos ejemplos. La conclusión de aquel trabajo, que debería ser norma y no lo es, es que una evaluación seria informa de un rango sobre formatos plausibles y no de una cifra.

Todo esto compone el primer diagnóstico útil para quien va a construir su propio sistema de evaluación: el banco de pruebas público y el sistema de evaluación de un producto son dos instrumentos distintos que responden a preguntas distintas. El público sirve para decidir qué modelo base contratar, con mucha cautela y sabiendo que la tabla está tensionada por los incentivos de quien publica. El propio sirve para decidir si el cambio que se hizo ayer en el prompt, en el modelo, en el contexto recuperado o en el esquema de salida mejora o empeora esta aplicación sobre esta distribución de entradas. La segunda pregunta es la única que se puede contestar bien, porque la distribución de entradas es conocida, los casos difíciles son propios y el criterio de calidad lo fija quien responde ante el usuario.

Un sistema de evaluación de producto, visto como pieza de ingeniería, tiene seis partes, y conviene nombrarlas desde el principio porque el resto de este libro las recorre una a una. Un corpus de casos con sus entradas y, cuando existe, su respuesta esperada. Un conjunto de puntuadores que convierten cada salida en cifras. Una regla de agregación que reduce las cifras de todos los casos a unas pocas comparables. Un umbral que decide si una ejecución pasa o no pasa. Un informe que permite ver los casos concretos que fallaron, y no solo la media. Y una versión de todo lo anterior, porque comparar dos ejecuciones con corpus distintos o rúbricas distintas no compara nada. La sexta es la que más se olvida y la que más caro se paga: un corpus que crece sin versionarse hace que la serie histórica de la calidad sea ilegible.

Los puntuadores se organizan en tres capas, ordenadas por coste y por el tipo de pregunta que contestan. La primera es determinista: código que comprueba lo comprobable. Que la salida es un JSON válido contra su esquema, que contiene las secciones obligatorias, que no repite literalmente el texto de entrada, que no incluye un correo electrónico ni un teléfono, que respeta el idioma pedido, que el rango salarial que declara tiene el mínimo por debajo del máximo. Es gratis, instantánea y no tiene varianza, y por eso va primero y se ejecuta siempre. La segunda capa es el juez automático: otro modelo que puntúa lo que el código no puede formular, como el tono o la fidelidad al contexto, guiado por una rúbrica. Cuesta dinero, tiene sesgos propios y hay que calibrarla contra juicios humanos antes de creerle. La tercera es la evaluación humana, que es la verdad de referencia, la que resuelve los desacuerdos y la que fija el criterio con el que se calibran las otras dos; es cara, lenta y por eso se reserva para muestras pequeñas y decisiones importantes.

El orden importa: lo determinista filtra lo evidente antes de gastar una llamada de juez, y el juez filtra lo grueso antes de gastar atención humana. Pero el orden no es una jerarquía de autoridad. Si la capa humana y la capa de juez discrepan, el juez está mal.

Existe una forma intermedia, entre el código y el juez, que sigue siendo la mejor idea práctica del campo y que se publicó antes de que existieran los modelos actuales: las pruebas de comportamiento. Ribeiro y sus coautores propusieron en 2020, con CheckList, tratar un modelo de lenguaje como una pieza de software y escribirle pruebas unitarias por capacidad —invariancia frente a cambios que no deben alterar la respuesta, esperas direccionales frente a cambios que sí deben alterarla, pruebas de funcionalidad mínima sobre casos elementales— en lugar de resumirlo en una cifra de exactitud. Cuando lo aplicaron a sistemas comerciales de análisis de sentimiento con exactitud publicada muy alta, encontraron fallos gruesos y sistemáticos que ninguna cifra agregada mostraba. Diez años después, la forma de un buen corpus de evaluación de producto sigue siendo esa: no una muestra aleatoria del tráfico, sino un conjunto de casos que interrogan capacidades concretas, cada uno construido para que su fallo signifique algo.

Queda la advertencia que hay que escribir en la primera página de cualquier plan de evaluación, porque cuando se descubre por experiencia ya ha costado un trimestre. Marilyn Strathern la formuló en 1997 en la versión que hoy se cita como ley de Goodhart: cuando una medida se convierte en objetivo, deja de ser una buena medida. En un equipo que itera sobre prompts con un juez automático como criterio, la presión selectiva es constante y no hace falta mala fe para que actúe: se conservan los cambios que suben el número y se descartan los que lo bajan, y al cabo de treinta iteraciones el sistema está ajustado a las manías del juez, incluidas las que no tienen nada que ver con la calidad. La defensa no es dejar de medir; es separar los papeles. Las cifras del juez son diagnóstico y guía de iteración, y la decisión de subir una versión a producción se toma con señales que el ajuste no puede tocar: una muestra humana fresca, el comportamiento de los usuarios reales, los casos que alguien acaba de encontrar rotos. Y la disciplina que ninguna infraestructura sustituye, la que repiten todos los que han montado uno de estos sistemas y funciona, es mirar las salidas. En crudo, unas cuantas cada semana, con la cifra tapada.