Pruebas de rendimiento de LLM: entender las clasificaciones (MMLU, Arena, SWE-bench)

#Por qué los benchmarks importan (y te engañan)

Un benchmark LLM es un conjunto de preguntas cuyas respuestas se conocen, que se le plantean a un modelo para contar cuántas resuelve. El resultado es una puntuación —un porcentaje, un ranking Elo, una tasa de resolución—. Es el único lenguaje común que permite comparar dos modelos sin probarlos personalmente durante horas, y por eso todo el mundo lo usa.

El problema no es el principio, sino la diferencia entre lo que dice la puntuación y lo que tú interpretas en ella. Un modelo que obtiene un 90 % en MMLU no es «inteligente al 90 %»: responde correctamente al 90 % de las preguntas de un cuestionario de opción múltiple sobre conocimientos académicos. Eso no dice nada sobre su capacidad para seguir tus instrucciones, escribir francés correcto, no alucinar en tu ámbito o mantener una conversación de diez turnos. Un benchmark mide una competencia específica en condiciones de laboratorio.

Se pueden clasificar los benchmarks en tres grandes familias, que no miden lo mismo ni se manipulan de la misma manera: los benchmarks académicos (cuestionarios de opción múltiple sobre conocimientos y razonamiento), los benchmarks de tareas reales (resolver un bug real, usar herramientas) y las arenas de preferencia humana (personas que votan por la mejor respuesta). Vamos a repasarlos en ese orden.

#Los benchmarks académicos: MMLU, GPQA, MATH

Es la familia histórica, la de las tablas de puntuaciones que se ven en las páginas de lanzamiento de modelos. Son conjuntos de preguntas con respuestas verificables, a menudo de opción múltiple, que se puntúan automáticamente. Su punto fuerte es la reproducibilidad; su punto débil es que son fáciles de saturar y contaminar.

MMLU

Massive Multitask Language Understanding: ~14 000 preguntas de opción múltiple distribuidas en 57 materias (derecho, medicina, historia, matemáticas…). El benchmark de conocimientos más citado. Hoy está ampliamente saturado: los buenos modelos superan el 88-90 % y las diferencias entre ellos quedan dentro del ruido.

MMLU-Pro

Versión más exigente de MMLU: 10 opciones en lugar de 4, preguntas seleccionadas de nuevo para aumentar la dificultad, más razonamiento. Creada precisamente porque MMLU ya no permitía distinguir entre los modelos punteros.

GPQA (Diamond)

«Google-Proof Q&A»: preguntas de nivel de doctorado en biología, física y química, diseñadas para que una búsqueda en Google no sea suficiente. El subconjunto «Diamond» es el más difícil. Buen indicador del razonamiento científico de vanguardia.

MATH / AIME

Problemas de matemáticas (MATH: nivel de bachillerato/concursos; AIME: olimpiadas estadounidenses). Respuesta numérica única, por lo que es fácil de calificar. Se ha convertido en un indicador de modelos «de razonamiento» (reasoning) que reflexionan en varias etapas.

IFEval

Mide la capacidad de SEGUIR instrucciones verificables («responde con exactamente 3 viñetas», «no uses la letra e»). A menudo es más revelador para un uso real que un cuestionario de conocimientos de opción múltiple.

HLE (Humanity's Last Exam)

Benchmark reciente y deliberadamente extremo: preguntas de nivel experto en múltiples áreas, diseñadas para seguir siendo difíciles durante mucho tiempo. Incluso los mejores modelos siguen sin superar puntuaciones bajas en esta prueba, lo que la convierte en una buena herramienta para distinguir su rendimiento en 2026.

#Los benchmarks de tareas reales: SWE-bench y los agentes

Esta familia es más reciente y mucho más difícil de engañar, porque no plantea preguntas: pide completar una tarea cuyo resultado se puede verificar objetivamente. Resolver un ticket real de GitHub, conseguir que pase una batería de pruebas, navegar por un repositorio de código. Lo explicamos en detalle en nuestra guía dedicada a los benchmarks de código; aquí tienes lo esencial.

SWE-bench Verified

Un subconjunto de 500 problemas reales de GitHub (issues + parche esperado) validados manualmente por OpenAI como resolubles y bien especificados. El modelo debe producir un parche que pase los tests del repositorio. Se ha convertido en el estándar para código en condiciones reales, mucho más relevante que HumanEval (hoy saturado al 96-98 %).

SWE-bench (full / Lite)

La versión completa (~2.300 tareas) y una versión ligera para iterar rápido. Las puntuaciones publicadas dependen enormemente del «harness» (el agente que orquesta el modelo): un mismo modelo puede ganar 15 puntos según las herramientas que lo rodean.

Tau-bench / benchmarks de agentes

Benchmarks de agentes que utilizan herramientas (llamadas a funciones, API, cumplimiento de reglas de negocio) a lo largo de varios turnos. Miden la fiabilidad cuando se usan como «asistentes que actúan», no solo que responden.

LiveCodeBench

Problemas de programación competitiva recopilados continuamente, con una fecha de publicación. Se pueden evaluar únicamente los problemas posteriores a la fecha de entrenamiento de un modelo: un antídoto directo contra la contaminación.

#LMArena: el ranking por preferencia humana

LMArena (el anterior «Chatbot Arena» de LMSYS) funciona de otra manera: dos modelos anónimos responden a la misma pregunta planteada por un usuario real, quien vota por la mejor respuesta. A partir de millones de duelos, se calcula un puntaje Elo (el mismo sistema que el ajedrez). Es el benchmark más cercano a «¿qué modelo prefieren realmente las personas?».

Lo que mide bien

La calidad percibida en una conversación abierta: tono, estructura, utilidad global, capacidad para dar una respuesta agradable. Está muy correlacionada con la satisfacción en el uso real.

Lo que mide mal

La precisión factual. Los votantes suelen premiar las respuestas largas, bien formateadas y expresadas con seguridad, incluso cuando son falsas. Un modelo «adulador» puede subir en la clasificación sin ser más preciso.

Elo no es un porcentaje

Una diferencia de 10-20 puntos Elo es ruido estadístico. Siempre revisa el intervalo de confianza mostrado: dos modelos pueden estar 'empatados' incluso si no están en la misma línea de la tabla.

Las subclasificaciones

LMArena ofrece categorías (código, matemáticas, respuestas largas, estilo controlado). La clasificación específica de «hard prompts» o «style control» suele ser más informativa que la clasificación global, que mezcla todo.

#La trampa n.º 1: la contaminación de los datos

La contaminación se produce cuando las preguntas de un benchmark (o sus respuestas) acaban, voluntariamente o no, en los datos de entrenamiento del modelo. Entonces, el modelo ya no razona: recita. Los benchmarks públicos circulan por internet, GitHub y Hugging Face; terminan mecánicamente en los corpus de preentrenamiento. Resultado: un puntaje inflado que no predice nada sobre preguntas nuevas.

Es el punto débil de todos los benchmarks estáticos y públicos. Cuanto más antiguo y famoso sea un benchmark, mayor será el riesgo. Algunas señales que deben alertar:

Diferencia entre versiones

Un modelo que destaca en MMLU pero se desploma en MMLU-Pro (mismas materias, preguntas nuevas) sugiere más memorización que comprensión.

Puntuación anormalmente alta para el tamaño

Un pequeño modelo de 7B que supera a los 70B en un benchmark específico y único: precaución, suele implicar un entrenamiento enfocado («benchmaxxing») en este conjunto de prueba.

Benchmarks con fecha

Las evaluaciones «en vivo» (LiveCodeBench, preguntas con marca de tiempo) evitan el problema: solo se puntúa lo que es posterior a la fecha de corte del modelo.

Lagunas de memoria sospechosas

Algunas pruebas introducen variantes canario («canary strings») o reformulaciones para detectar la reproducción de respuestas memorizadas. Una gran diferencia entre la pregunta original y la reformulada revela la contaminación.

#La trampa n.º 2: la saturación

Un benchmark está saturado cuando los mejores modelos alcanzan puntuaciones tan altas que ya no permite distinguirlos. Cuando todos están en el 96-99 %, los 3 puntos restantes son ruido de medición (preguntas ambiguas, errores de etiquetado) en lugar de una verdadera diferencia de capacidad. HumanEval (código) y MMLU (conocimiento) son los ejemplos canónicos: fueron muy útiles, pero ya no lo son para distinguir entre los modelos mejor clasificados.

Es por eso que nuevos benchmarks más difíciles aparecen constantemente: MMLU-Pro reemplaza a MMLU, GPQA Diamond y HLE toman el relevo para el razonamiento, SWE-bench Verified reemplaza a HumanEval para el código. Un benchmark tiene una vida útil; una vez superado un cierto nivel medio, debe eliminarse de tus criterios de decisión.

#Leer un leaderboard sin ser engañado

Este es el método que debes aplicar al examinar cualquier tabla de puntuaciones, tanto si procede de un comunicado sobre un modelo como de una clasificación pública.

1. 01
   Identifica quién publica

   Un gráfico en la presentación de un modelo es publicidad: elige los benchmarks favorables y el protocolo ventajoso (cherry-picking). Un leaderboard externo y neutral (Open LLM Leaderboard, LMArena, la página oficial de SWE-bench) es mucho más fiable que una diapositiva de lanzamiento.
2. 02
   Verifica el protocolo

   ¿0-shot o few-shot? ¿Con cadena de pensamiento? ¿Con qué entorno de ejecución para los agentes? Dos puntuaciones solo se pueden comparar si el método es idéntico. Un asterisco «self-reported» (declarado por el propio evaluado) vale menos que una puntuación reproducida por un tercero.
3. 03
   Revisa los intervalos de confianza

   En LMArena, una diferencia de Elo inferior a ~15 puntos es ruido. En las pruebas con una muestra pequeña (GPQA Diamond, 198 preguntas), unas pocas respuestas correctas hacen variar la puntuación en varios puntos. Una clasificación sin margen de error debe tomarse con cautela.
4. 04
   Compara varios benchmarks

   Nunca tomes una decisión basándote en una sola cifra. Un modelo sólido obtiene buenos resultados en un conjunto de pruebas variadas, no solo en un pico. Un pico aislado y anómalo sugiere más bien una optimización específica.
5. 05
   Pondera según TU uso

   ¿Programas? Mira SWE-bench y LiveCodeBench, no MMLU. ¿Trabajas en francés? Ninguno de estos benchmarks está en francés: busca evaluaciones en francés o haz tus propias pruebas. ¿Lo usas para conversar? LMArena tiene prioridad. El mejor modelo «en promedio» no es necesariamente el mejor para ti.

#Evaluar un modelo local en tareas propias

La conclusión lógica de todo lo anterior: el benchmark más fiable para ti es el tuyo. No puede contaminarse (tus preguntas no están en la web), nunca está saturado (lo calibras con tus casos difíciles) y mide exactamente lo que necesitas. No necesitas una infraestructura pesada: unos veinte ejemplos representativos bastan para decidir entre dos modelos.

1. 01
   Crea un pequeño conjunto de pruebas

   Reúne entre 15 y 30 prompts extraídos de tus casos de uso reales (correos que redactar, extracciones, preguntas sobre tus documentos, fragmentos de código). Para cada uno, anota qué debe contener una buena respuesta. Mantén este conjunto privado y estable para comparar los modelos a lo largo del tiempo.
2. 02
   Instala los modelos para comparar

   Con Ollama, descarga los modelos candidatos. Ollama expone una API compatible con OpenAI en http://localhost:11434, lo que permite automatizar las llamadas.
3. 03
   Automatiza llamadas

   Un pequeño script recorre tus prompts en un bucle y guarda las respuestas de cada modelo una al lado de otra en un archivo, para compararlas con calma sin dejarte influir por el nombre del modelo.
4. 04
   Evalúa a ciegas

   Relee las respuestas sin saber qué modelo produjo cada una (mezcla el orden). Puntúalas según tus propios criterios: exactitud, respeto de las instrucciones, calidad del francés, ausencia de invenciones. Es tu «Arena» personal.
5. 05
   También mide el costo real

   La calidad no lo es todo: anota la velocidad (tokens/segundo) y la VRAM consumida. Un modelo de 14B en Q4_K_M (~9 GB) que cabe en tu RTX 4070 y responde rápido puede superar a un 70B (~40 GB) teóricamente «mejor» pero inviable en tu equipo.

# Récupérer deux candidats via Ollama
ollama pull qwen3:14b
ollama pull gemma3:12b

# Vérifier qu'ils répondent (API locale sur le port 11434)
curl http://localhost:11434/api/generate -d '{
  "model": "qwen3:14b",
  "prompt": "Résume ce texte en 3 puces : ...",
  "stream": false
}'

import json, requests

OLLAMA = "http://localhost:11434/api/generate"
MODELES = ["qwen3:14b", "gemma3:12b"]

# Vos prompts réels — la clé d'une éval qui vous ressemble
prompts = [
    "Rédige un mail de relance poli à un client en retard de paiement.",
    "Extrais les dates et montants de ce texte : ...",
    "Explique la différence entre Q4_K_M et Q8_0 en 2 phrases.",
]

def interroger(modele, prompt):
    r = requests.post(OLLAMA, json={
        "model": modele, "prompt": prompt, "stream": False
    }, timeout=120)
    return r.json()["response"].strip()

resultats = []
for p in prompts:
    ligne = {"prompt": p}
    for m in MODELES:
        ligne[m] = interroger(m, p)
    resultats.append(ligne)

# À relire en aveugle, sans regarder la colonne du modèle
with open("comparaison.json", "w", encoding="utf-8") as f:
    json.dump(resultats, f, ensure_ascii=False, indent=2)
print("OK — comparaison.json généré, notez les réponses à froid.")

#Para ir más allá

Estas guías amplían las nociones vistas aquí en lo relativo a los benchmarks especializados y a la elección concreta de un modelo local:

Benchmarks de código en detalle

«HumanEval está muerto: entender los benchmarks de código de los LLM en 2026» profundiza en SWE-bench, LiveCodeBench y cómo interpretar las puntuaciones de código: la continuación directa de esta guía en lo relativo al desarrollo.

Elegir la cuantización

« Cuantización GGUF en 2026: Q4_K_M vs Q5_K_M vs Q6_K » muestra cómo medir el impacto real de una cuantización en la calidad — una evaluación propia aplicada a un caso concreto.

Prueba completa del modelo

« Qwen 3 en local: prueba completa y benchmarks reales » ilustra el método de evaluación local (tokens/segundo, calidad FR, VRAM) en un modelo específico.