Benchmarks de calidad de LLM: la trampa de la contaminación y las herramientas OSS para no mentirse

Notación: importes en euros (N €), decimales con coma. No se usa el símbolo de dólar (en este sitio es delimitador de fórmula).

Post B7 del track de benchmarking. La introducción B1 fijó la distinción entre los tres ejes (rendimiento, calidad, energía). El catálogo de herramientas B2 cubrió el eje de rendimiento (TTFT, ITL, goodput). Este artículo cubre el eje de calidad: qué mide cada benchmark, cómo se ejecuta, y por qué los números del leaderboard no siempre dicen lo que parecen. El pipeline de evals LLMOps y el LLM-as-judge cubren la capa de evaluación interna del sistema; este artículo cubre la evaluación del modelo base con benchmarks académicos estándar.

TL;DR

Un motor de inferencia con TTFT de 80 ms que sirve un modelo de baja calidad no sirve de nada: el Pareto de la plataforma tiene dos ejes independientes. En 2025–2026, los benchmarks estáticos más usados —MMLU, HumanEval— han cruzado el umbral de saturación (HumanEval > 93% en modelos frontier, MMLU-Pro > 75% en los top-5), lo que invalida su capacidad de diferenciar en la zona alta. La causa principal no es que los modelos sean mejores: es contaminación de datos, con solapamiento n-gram del 18% detectado en Llama-2-70B sobre datasets de evaluación. Las herramientas OSS activas en 2026 son lm-evaluation-harness (EleutherAI, MIT, 60+ tareas, motor de facto del ecosistema), HELM (Stanford, Apache 2.0, en mantenimiento desde junio 2026), LiveBench (MIT, 1.000 preguntas renovadas mensualmente para evitar contaminación), lighteval (Hugging Face, MIT, 1.000+ tareas, soporte vLLM), y LMArena/Chatbot Arena (Bradley-Terry sobre millones de comparaciones humanas). El OpenLLM Leaderboard v2 fue archivado en 2025 y sustituido por el ecosistema OpenEvals (200+ leaderboards especializados). Reproducir un número de eval requiere pinear: versión del harness, del modelo, de la plantilla de prompt y del número de shots.

Calidad ≠ rendimiento: el eje Pareto independiente

El eje de rendimiento (TTFT, ITL, throughput) mide cuánto tarda el motor en producir tokens. El eje de calidad mide qué tan correctos son esos tokens. Son ortogonales: un modelo pequeño servido con vLLM a 3.000 tok/s puede sacar 42% en MMLU-Pro; un modelo frontier puede necesitar 4× más GPU y sacar 72%. El producto throughput × calidad es el único número que importa para una plataforma en producción.

La consecuencia operativa: seleccionar modelo y motor primero por calidad (¿supera el umbral mínimo para la tarea?) y luego por rendimiento (¿cumple el SLO dentro del presupuesto de GPU?). Invertir el orden —elegir el motor más rápido y encajar el modelo— es el error más frecuente en el dimensionamiento inicial.

Benchmarks de referencia: qué mide cada uno

La tabla siguiente recoge los benchmarks académicos estándar en 2026, la capacidad que mide cada uno, su tamaño de test set y el nivel de saturación actual en modelos frontier.

Nota sobre saturación: un benchmark saturado no distingue modelos en la zona alta; sólo tiene valor como floor check (confirmar que el modelo no regresa al nivel de hace 3 años). Para la zona frontier, los benchmarks útiles en 2026 son MMLU-Pro, GPQA Diamond, IFEval y MuSR.

Herramientas OSS de evaluación: fichas

lm-evaluation-harness (EleutherAI)

El harness es el estándar de la industria para evaluación reproducible. Su fortaleza es la amplitud de tareas y la normalización del formato de prompt. Su limitación: las tareas son estáticas — los datasets no cambian entre versiones del harness, lo que lo expone al problema de contaminación si el modelo fue entrenado con los mismos datos.

Invocación completa con vLLM como backend:

lm_eval \
  --model vllm \
  --model_args pretrained=meta-llama/Llama-3.1-70B-Instruct,dtype=bfloat16 \
  --tasks mmlu_pro,gpqa_diamond,ifeval,humaneval \
  --num_fewshot 5 \
  --batch_size auto \
  --output_path ./eval_results/ \
  --log_samples

HELM (Stanford CRFM)

HELM es la herramienta que introdujo la evaluación holística (múltiples métricas sobre el mismo escenario en lugar de un único número). En 2026, con HELM en modo mantenimiento, el ecosistema ha fragmentado en leaderboards especializados; pero HELM sigue siendo la referencia metodológica para evaluaciones que necesitan fairness y toxicidad además de precisión.

HELM Capabilities (publicado marzo 2025): leaderboard activo con transparencia total de prompt, reproducible con el framework HELM. Disponible en crfm.stanford.edu/helm/capabilities.

LiveBench

LiveBench es la respuesta arquitectural al problema de contaminación: si el benchmark cambia cada mes con preguntas basadas en fuentes publicadas después del cutoff del modelo evaluado, la memorización del training set no puede inflar el resultado. La limitación es el tamaño (1.000 preguntas) y que no cubre todos los dominios con la misma profundidad que MMLU.

Ejecución:

git clone https://github.com/LiveBench/LiveBench
cd LiveBench
pip install -e .
python livebench/gen_model_answer.py \
  --model-path meta-llama/Llama-3.1-70B-Instruct \
  --model-id llama3-70b
python livebench/gen_ground_truth_judgment.py \
  --model-id llama3-70b
python livebench/show_livebench_result.py

lighteval (Hugging Face)

lighteval es el sucesor interno de lm-evaluation-harness en el ecosistema HF: más moderno, mejor soporte de vLLM y de backends distribuidos, y diseñado para poder correr sin salir del stack HF. Para equipos que ya usan el Hub para gestionar modelos, es la opción con menos fricción.

OpenLLM Leaderboard v2 (archivado 2025) → OpenEvals

El OpenLLM Leaderboard v2 evaluó más de 13.000 modelos entre junio de 2024 y su cierre en 2025, usando seis benchmarks fijos: IFEval, MuSR, GPQA, MATH, BBH y MMLU-Pro, todos ejecutados con lm-evaluation-harness. Su cierre fue consecuencia directa del problema de saturación y gaming: a medida que los benchmarks se conocían, los modelos se optimizaban para ellos.

Sucesor: OpenEvals (huggingface.co/spaces/OpenEvals/find-a-leaderboard)

La colección archivada está disponible como referencia en huggingface.co/collections/OpenEvals/archived-open-llm-leaderboard-2024-2025.

LMArena / Chatbot Arena

LMArena es el único benchmark basado en preferencia humana a escala. Su ventaja: captura calidad percibida real, no solo exactitud en MCQ. Su limitación: es difícil reproducirlo on-premise (requiere interfaz de usuario y panel de votantes humanos). Útil como señal de validación externa, no como gate de CI.

Tabla de decisión: qué herramienta para cada objetivo

La trampa de la contaminación de datos

Qué es

Un modelo que ha visto durante preentrenamiento los datos de test de un benchmark memoriza respuestas en lugar de generalizar. El benchmark mide memorización, no capacidad. Esto se denomina data contamination o benchmark leakage.

Escala del problema (datos 2024–2025)

Mecanismos de detección

1. N-gram overlap (método clásico)

Calcula la fracción de n-gramas del test set que aparecen en el corpus de preentrenamiento del modelo. Un umbral práctico: si más del 13% de los 8-gramas del test coinciden con el corpus, el resultado está comprometido.

[ \text{ratio contaminación} = \frac{|{g \in \text{n-gramas test}} \cap {g \in \text{n-gramas train}}|}{|\text{n-gramas test}|} ]

Límite: sólo funciona si tienes acceso al corpus de preentrenamiento. Para modelos cerrados, no es aplicable.

2. Canary strings (inserción de señuelos)

Se insertan cadenas únicas y aleatorias en el dataset de evaluación durante su creación. Si el modelo reproduce esas cadenas sin haberlas visto en contexto, se confirma que las memorizó del preentrenamiento. Técnica propuesta en “Extracting Training Data from Large Language Models” (Carlini et al., 2021) y adoptada en benchmarks recientes.

3. Perturbación y reformulación

Se generan variantes semánticas equivalentes del test (paraphrasing, cambio de nombres propios, traducción y retradución). Un modelo que generaliza mantiene el accuracy; un modelo que memoriza cae. La caída promedio detectada en modelos contaminados es de 9–15 pp sobre prompts reformulados equivalentes.

4. LiveBench (renovación mensual)

La solución arquitectural: si las preguntas se generan de fuentes publicadas después del cutoff del modelo (papers arXiv recientes, noticias, datos nuevos), la memorización del preentrenamiento no puede ayudar. El modelo debe razonar sobre información que nunca pudo ver.

5. Análisis de divergencia de kernel (Savelka et al., 2025)

Método estadístico más sofisticado: compara la distribución de embeddings del conjunto de test con la distribución del corpus de entrenamiento. Una divergencia anormalmente baja indica que el benchmark y el corpus de entrenamiento provienen de la misma fuente.

Por qué los leaderboards estáticos se saturan

El ciclo es predecible:

1. Se publica un benchmark nuevo (MMLU en 2021, GPQA en 2023).
2. Los labs lo usan como evaluation target durante el preentrenamiento y fine-tuning.
3. El rendimiento en ese benchmark sube rápido —más rápido que la capacidad real.
4. El benchmark deja de discriminar en la zona alta.
5. La comunidad necesita un benchmark nuevo.

El tiempo medio entre publicación de un benchmark y saturación en modelos frontier ha pasado de ~36 meses (MMLU: 2021–2024) a ~18 meses (HumanEval: 2021–2023, GPQA: 2023–2025). La velocidad de saturación se acelera.

Metodología honesta: reproducibilidad y fuentes de varianza

Los cuatro parámetros que deben pinarse

Un resultado de eval sólo es reproducible si declara:

Few-shot vs zero-shot: la diferencia numérica

La sensibilidad al número de shots varía drásticamente por benchmark:

Publicar un resultado de MMLU-Pro en 0-shot sin indicarlo, cuando el estándar del leaderboard es 5-shot, infla la comparación en ~10 pp. Dos resultados del mismo modelo publicados con diferente número de shots no son comparables.

Sensibilidad al prompt

Perturbaciones menores en la plantilla de prompt generan variaciones de hasta ±8 pp en MCQ y ±15 pp en tareas de generación. Fuentes de varianza identificadas en la literatura:

• Orden de las opciones en MCQ (position bias): hasta ±4 pp.
• Formulación del enunciado (paraphrasing): ±3–8 pp.
• Presencia o ausencia de “Let’s think step by step”: ±5–12 pp en razonamiento.
• Idioma de las instrucciones del sistema: ±3–10 pp en modelos no multilingues.

Por qué dos evals dan resultados distintos

Escenario habitual: el paper reporta MMLU-Pro 74,3% y la reproducción da 71,8%. Causas frecuentes:

La suma de estas fuentes explica gaps de 2–6 pp que no son ruido sino diferencias sistemáticas de protocolo.

La fórmula del intervalo de confianza para comparar dos modelos

Para saber si la diferencia entre el modelo A (accuracy (p_A)) y el modelo B ((p_B)) sobre un test set de tamaño (n) es estadísticamente significativa:

[ \Delta p \pm 1{,}96 \cdot \sqrt{\frac{p_A(1-p_A) + p_B(1-p_B)}{n}} ]

Aplicado a GPQA Diamond ((n = 198)), si (p_A = 0{,}90) y (p_B = 0{,}88):

[ \Delta p = 0{,}02 \quad;\quad \text{margen} = 1{,}96 \cdot \sqrt{\frac{0{,}09 + 0{,}1056}{198}} \approx 1{,}96 \cdot 0{,}0314 \approx 0{,}062 ]

El intervalo de confianza al 95% es ([{-0{,}042},\ {+0{,}082}]): cruza el cero. Una diferencia de 2 pp sobre 198 preguntas no es estadísticamente distinguible del ruido. Para distinguir 90% vs 88% con confianza 95%, hacen falta:

[ n \approx \frac{(1{,}96)^2 \cdot (p_A(1-p_A) + p_B(1-p_B))}{(\Delta p)^2} \approx \frac{3{,}84 \cdot 0{,}1956}{0{,}0004} \approx 1,878 \text{ preguntas} ]

GPQA Diamond no tiene ese tamaño. Diferencias de 1–2 pp en GPQA Diamond son estadísticamente invisibles.

El eje calidad en el cuadro de mando

El cuadro de mando de la plataforma tiene tres columnas: rendimiento (goodput bajo SLO), calidad (score en benchmark de referencia), energía (J/token). La columna de calidad se construye así:

Una eval completa en 4 benchmarks (MMLU-Pro 12.032 + GPQA 198 + IFEval 541 + MBPP 500) con un modelo 70B en un nodo genérico 2×H100 tarda del orden de 4–8 horas según el batch size y el número de shots. El coste de GPU es real: a ~5 €/h por tarjeta amortizada, una eval completa cuesta del orden de 40–80 €. No se ejecuta en cada commit; se ejecuta en cada release de modelo o adapter major.

Ver también

• Evals LLM: la capa después del tracing — la capa de evaluación interna del sistema (golden dataset, CI gate, judge calibrado). Complemento necesario a los benchmarks académicos de este artículo.
• LLM-as-judge: fundamentos — el judge LLM que evalúa outputs en producción; distinto del benchmark académico, pero comparte la necesidad de calibración y reproducibilidad.
• Evaluar un RAG: RAGAS y el golden dataset — especialización de la evaluación para sistemas RAG; faithfulness y context precision no aparecen en los benchmarks académicos de este artículo.
• Catálogo de herramientas de benchmark: ficha a ficha — el eje de rendimiento (TTFT, ITL, goodput); el par complementario de este artículo en el cuadro de mando.
• Benchmarking LLM: estado del arte — introducción B1 con los tres ejes y la metodología general del track.

Fuentes

• EleutherAI · lm-evaluation-harness — https://github.com/EleutherAI/lm-evaluation-harness
• Stanford CRFM · HELM — https://github.com/stanford-crfm/helm
• Stanford CRFM · HELM Capabilities (mar-2025) — https://crfm.stanford.edu/2025/03/20/helm-capabilities.html
• Stanford CRFM · HELM (sitio oficial) — https://crfm.stanford.edu/helm/
• LiveBench · paper arXiv:2406.19314 — https://arxiv.org/abs/2406.19314
• LiveBench · sitio oficial — https://livebench.ai
• LiveBench · GitHub — https://github.com/LiveBench/LiveBench
• NYU Center for Data Science · LiveBench blog — https://nyudatascience.medium.com/livebench-challenging-language-models-with-contamination-free-questions-999b52967ec8
• Hugging Face · lighteval — https://github.com/huggingface/lighteval
• Hugging Face · OpenLLM Leaderboard (archivado) — https://huggingface.co/spaces/open-llm-leaderboard/open_llm_leaderboard
• Hugging Face · OpenEvals (sucesor) — https://huggingface.co/spaces/OpenEvals/find-a-leaderboard
• Hugging Face · Archived Open LLM Leaderboard 2024-2025 — https://huggingface.co/collections/OpenEvals/archived-open-llm-leaderboard-2024-2025
• LMArena · Chatbot Arena — https://lmarena.ai
• LMSys · blog Chatbot Arena Elo — https://www.lmsys.org/blog/2023-05-03-arena/
• “A Statistical Framework for Ranking LLM-Based Chatbots” · arXiv:2412.18407 — https://arxiv.org/pdf/2412.18407
• “Data Contamination or Genuine Generalization?” (2025) — https://www.suaspress.org/ojs/index.php/AJNS/article/view/v2n2a03
• “When Benchmarks Leak: Inference-Time Decontamination” (2025) · arXiv:2601.19334 — https://arxiv.org/pdf/2601.19334
• “How Contaminated Is Your Benchmark?” (2025) · arXiv:2502.00678 — https://arxiv.org/pdf/2502.00678
• “When AI Benchmarks Plateau” (2026) · arXiv:2602.16763 — https://arxiv.org/pdf/2602.16763
• GPQA · arXiv:2311.12022 — https://arxiv.org/abs/2311.12022
• GPQA Diamond leaderboard · Artificial Analysis — https://artificialanalysis.ai/evaluations/gpqa-diamond
• “The Emperor’s New Clothes in Benchmarking?” (2025) · arXiv:2503.16402 — https://arxiv.org/pdf/2503.16402
• lm-evaluation-harness · CLI reference — https://lm-evaluation-harness.readthedocs.io/running_evals/cli_reference/
• crfm-helm · PyPI — https://pypi.org/project/crfm-helm/