Definición
Un benchmark es una prueba estandarizada que se le pasa a muchos modelos distintos para compararlos con la misma vara. Es el número que sale en las gráficas cada vez que alguien anuncia un modelo nuevo.
La diferencia con los evals es de propósito y conviene tenerla clara: un benchmark es público y general, y sirve para comparar modelos entre sí. Un eval es tuyo y específico, y sirve para saber si tu sistema hace bien tu trabajo.
Un modelo puede ganar todos los benchmarks del mundo y ser peor que otro para clasificar tus facturas. Lo primero se decide en un laboratorio; lo segundo, en tus datos.
Los que más vas a ver citados
- MMLU — Preguntas tipo test de 57 materias, de historia a medicina. Mide conocimiento general. Muy citado y ya bastante saturado: los modelos punteros van todos arriba y apenas se distinguen.
- HumanEval y MBPP — Programación: el modelo escribe una función y se ejecutan tests. Objetivo y verificable, pero son ejercicios pequeños y aislados.
- SWE-bench — Mucho más duro y más realista: incidencias reales de repositorios de GitHub que el modelo tiene que resolver dentro del proyecto entero. Se acerca bastante a trabajo de verdad.
- GPQA — Preguntas de nivel doctorado que ni buscando en Google se resuelven fácil. Diseñado para no saturarse enseguida.
- AIME y MATH — Matemáticas de competición. Es donde más se nota la diferencia de los modelos de razonamiento.
- Chatbot Arena — Distinto a todos: personas comparan dos respuestas a ciegas y votan. Mide preferencia humana, que es difícil de falsear pero también difícil de reproducir.
Los tres problemas que tienen
Contaminación. Los benchmarks son públicos y están en internet. Si sus preguntas acabaron en los datos de preentrenamiento —y con frecuencia acaban—, el modelo no razona: recuerda. Es la razón de que se creen benchmarks nuevos cada poco.
Saturación. Cuando todos los modelos buenos sacan más de un 88 %, el benchmark deja de distinguir. Las diferencias que quedan caen dentro del margen de ruido, y sin embargo se anuncian como avances.
La ley de Goodhart. Cuando una medida se convierte en objetivo, deja de ser buena medida. Los laboratorios saben en qué se les va a medir, y optimizan para ello. No hace falta mala fe: basta con elegir qué mezcla de datos entra al entrenamiento.
Ejemplo práctico
Cuando elegimos qué modelo usar en el CRM de IMDICA, la primera tentación fue mirar tablas. El que salía primero era también el más caro, con diferencia.
Montamos un eval propio: 120 movimientos bancarios reales, clasificación en 20 categorías. Probamos tres modelos.
El resultado fue instructivo. El modelo grande y caro sacó un 91 %. Uno mediano, un 89 %. Dos puntos de diferencia... y seis veces menos coste por petición.
Para clasificar miles de movimientos al mes, esos dos puntos no valían la diferencia de factura. Y el 2 % de fallos se resuelve donde ya se resolvía: con revisión humana de las categorías dudosas, que hay que hacer igualmente.
La conclusión general: los benchmarks te sirven para hacer la lista corta de modelos a probar. La decisión la toma tu eval con tus datos y tu factura.
Cómo leerlos sin comerte el marketing
- Mira si el benchmark está saturado. Si el segundo saca 88,1 y el primero 88,4, ahí no hay diferencia real.
- Comprueba en qué condiciones se midió. ¿Con cuántos intentos? ¿Con razonamiento extendido? ¿Con qué prompt? Cambiar eso mueve los números muchísimo.
- Desconfía de las comparativas hechas por el fabricante contra rivales que él mismo ha configurado.
- Busca el benchmark más parecido a tu problema. Si vas a generar código sobre un proyecto grande, SWE-bench te dice más que MMLU.
- Mira coste y latencia en la misma tabla. Un número de acierto sin su precio al lado está incompleto.
Cuándo te sirven
Sí para descartar: si un modelo va claramente por detrás en todo, no lo pruebes. Y para detectar saltos generacionales de verdad, que se notan en varios benchmarks a la vez.
No para elegir el definitivo. Esa decisión se toma con datos tuyos. La tabla te da tres candidatos; tu eval te dice cuál.
