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

Tue, 16 Jun 2026 03:00:00 +0200

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.

Benchmark	Capacidad medida	Formato	Test set	Saturación frontier 2026
MMLU	Conocimiento multidisciplinar (57 materias)	4-choice MCQ	14.079	Alta: top-5 > 88%; diferencia insuficiente
MMLU-Pro	MMLU con 10 opciones, razonamiento multistep	10-choice MCQ	12.032	Media: top-5 entre 72–77%; aún diferencia
GSM8K	Razonamiento matemático nivel primaria (problemas de enunciado)	generación de respuesta	1.319	Muy alta: top modelos > 97%
MATH	Matemáticas de competición (álgebra, geometría, cálculo, etc.)	generación LaTeX	5.000	Media-alta: top modelos 85–92%
GPQA Diamond	Razonamiento científico PhD (biología, física, química)	4-choice MCQ	198	Emergente: top > 90% en 2026; aún diferencia en 60–90%
BBH (BIG-Bench Hard)	23 tareas donde modelos anteriores caían por debajo del humano	generación	6.511	Media: útil para razonamiento complejo
IFEval	Seguimiento de instrucciones verifiable (format, longitud, idioma)	generación + reglas	541	Baja: diferencia notable entre modelos
HumanEval	Generación de código Python (164 problemas con signatura)	generación + ejecución	164	Muy alta: top > 93%; saturado
MBPP	Generación de código (500 problemas sin signatura de función)	generación + ejecución	500	Alta: top modelos 85–92%
MuSR	Razonamiento multistep sobre textos largos	generación	~1.000	Baja: útil para razonamiento extenso
TruthfulQA	Veracidad: resistencia a afirmar mitos populares	generación + MCQ	817	Media: diferencia visible entre familias

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)

Campo	Dato
Repositorio	github.com/EleutherAI/lm-evaluation-harness
Licencia	MIT
Mantenedor	EleutherAI
Versión activa (jun-2026)	0.4.x (rama `main`)
Tareas disponibles	60+ benchmarks, cientos de subtareas y variantes
Backends soportados	Hugging Face Transformers, vLLM, litellm, API OpenAI-compatible, GGUF
Formato de tareas	YAML + Python; cada tarea define dataset, plantilla, métrica y número de shots
Qué mide	Precisión en MCQ, exact match, pass@k en código, perplexity, BLEU/ROUGE
Cómo se invoca	`lm_eval --model hf --model_args pretrained=<modelo> --tasks mmlu,gsm8k --num_fewshot 5 --output_path resultados/`
Salida	JSON con métricas por tarea + metadatos de configuración
Uso en el ecosistema	Motor oficial del OpenLLM Leaderboard (v1 y v2); referencia de facto en investigación

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)

Campo	Dato
Repositorio	github.com/stanford-crfm/helm
Sitio oficial	crfm.stanford.edu/helm
Licencia	Apache 2.0
Mantenedor	Stanford CRFM
Estado (jun-2026)	Modo mantenimiento desde 1 de junio de 2026
Qué mide	Precisión, calibración, robustez, fairness, toxicidad, eficiencia (latencia/coste)
Formato de tareas	Python + YAML; escenarios con métricas múltiples simultáneas
Backends soportados	API (OpenAI, Anthropic, Cohere, etc.) + modelos locales vía Hugging Face
Variantes activas	HELM Classic, HELM Capabilities, HELM Lite, MedHELM, HELM Safety
Instalación	`pip install crfm-helm`
Cómo se invoca	`helm-run --conf-paths run_specs.conf --suite v1 --max-eval-instances 1000`
Salida	JSON + UI web con leaderboard reproducible y transparencia por prompt

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

Campo	Dato
Repositorio	github.com/LiveBench/LiveBench
Sitio oficial	livebench.ai
Licencia	MIT
Mantenedor	NYU, UT Austin, UC Santa Barbara
Paper	arXiv:2406.19314
Tamaño	1.000 preguntas activas (renovación mensual, mismo tamaño total)
Categorías	6: math, coding, reasoning, language, instruction following, data analysis
Tareas	18 subtareas
Qué mide	Capacidades generales sobre preguntas con respuesta verificable objetivamente
Anticontaminación	Preguntas generadas desde fuentes recientes: papers arXiv, noticias, IMDb, datasets nuevos
Scoring	Sin LLM-as-judge: respuesta verificable automáticamente (ground truth exacto)
Periodicidad	Nuevas preguntas mensualmente; las antiguas se retiran para evitar acumulación de memorización

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)

Campo	Dato
Repositorio	github.com/huggingface/lighteval
Licencia	MIT
Mantenedor	Hugging Face (Leaderboard & Evals Team)
Tareas disponibles	1.000+ tareas en múltiples dominios e idiomas
Backends soportados	Hugging Face Accelerate (CPU/GPU/multi-GPU), Nanotron, vLLM, TGI, endpoints OpenAI-compatible
Qué mide	Accuracy, BERT score, BLEU, exact match; ídem al harness + tareas propias de HF
Diferenciador	Diseñado para ser el motor de los leaderboards de HF; fácil extensión con tareas custom
Instalación	`pip install lighteval`
Cómo se invoca	`lighteval accelerate –model_args “pretrained=” –tasks “lighteval
Salida	JSON + integración directa con Hugging Face Hub para publicar resultados

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)

Aspecto	OpenLLM Leaderboard v2	OpenEvals
Arquitectura	Único leaderboard centralizado	+200 leaderboards especializados de la comunidad
Benchmarks	Fijos (6 tareas)	Variables por leaderboard (math, code, médico, seguridad, etc.)
Modelos evaluados	13.000+	Distribuido por leaderboard
Motor de eval	lm-evaluation-harness	lighteval (mayoría) o harness
Estado	Archivado con UI actualizada (mar-2025)	Activo; se puede crear leaderboard propio
Ventaja	Consistencia histórica	Especialización, velocidad de adaptación

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

LMArena / Chatbot Arena

Campo	Dato
Sitio	lmarena.ai (rebrand de LMSys Chatbot Arena, enero 2026)
Metodología	Comparaciones pareadas anónimas: el usuario vota qué respuesta prefiere sin saber el modelo
Modelo estadístico	Bradley-Terry (máxima verosimilitud sobre historial completo de enfrentamientos; sustituyó al Elo clásico por mayor estabilidad)
Votos acumulados	> 6 millones (jun-2026)
Variantes	Overall, Coding, Math, Hard Prompts, Multimodal — las especializadas son más fiables
Licencia/acceso	Gratuito (web); datos de votos disponibles bajo licencia CC
Limitaciones	Overall sesgado por disclosure selectiva de labs y gaming de formato; Bradley-Terry se recalibró en mid-2025 (Style Control), desplazando ±20–40 Elo en algunos modelos

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

Objetivo	Herramienta	Por qué
Reproducir una eval académica estándar	lm-evaluation-harness	Motor de facto; máxima compatibilidad con papers
Evaluación holística (accuracy + fairness + toxicidad)	HELM (+ HELM Capabilities)	El único framework que mide todos los ejes a la vez
Evitar contaminación con preguntas recientes	LiveBench	Renovación mensual; respuesta verificable sin judge
Integración nativa con HF Hub y vLLM	lighteval	Backend vLLM, 1.000+ tareas, publicación directa en Hub
Comparar con el estado del arte público (OSS)	OpenEvals + lighteval	Ecosistema sucesor del OpenLLM Leaderboard
Preferencia humana a escala	LMArena	Bradley-Terry sobre millones de comparaciones reales
Eval de dominio personalizado (médico, legal, etc.)	lighteval con tarea custom	Extensión más sencilla que el harness
CI gate rápido (<10 min)	lm-eval harness (subset)	Tareas individuales con `--tasks ifeval,gpqa` + batching vLLM

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)

Hallazgo	Fuente	Dato
N-gram overlap en Llama-2-70B	“Data Contamination or Genuine Generalization?” (2025)	18,1% de solapamiento con datasets de eval
Caída out-of-distribution en modelos grandes contaminados	Ibíd.	−9,4 pp en prompts reformulados vs test original
HumanEval saturado	Artificial Analysis / múltiples reportes 2026	Top modelos > 93%; diferencia ≤ 2 pp entre los 5 mejores
GPQA Diamond: aparición de contaminación indirecta	mindstudio.ai analysis 2026	“Data laundering”: preguntas filtradas vía foros online

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:

Se publica un benchmark nuevo (MMLU en 2021, GPQA en 2023).
Los labs lo usan como evaluation target durante el preentrenamiento y fine-tuning.
El rendimiento en ese benchmark sube rápido —más rápido que la capacidad real.
El benchmark deja de discriminar en la zona alta.
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:

Parámetro	Ejemplo	Por qué importa
Versión del harness	`lm-evaluation-harness==0.4.3`	Cambios en la plantilla de prompt entre versiones invalidan la comparación
Versión exacta del modelo	`meta-llama/Llama-3.1-70B-Instruct@sha256:abc…`	Actualizaciones silenciosas del modelo en el Hub cambian los resultados
Plantilla de prompt (template)	`mmlu_pro_cot_0shot` vs `mmlu_pro_5shot`	La diferencia entre 0-shot y 5-shot puede ser 5–12 pp
Número de shots	`--num_fewshot 5`	El estándar publicado varía por benchmark; 0-shot y 5-shot no son comparables

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

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

Benchmark	0-shot típico	5-shot típico	Diferencia
MMLU-Pro	62%	72%	+10 pp
GPQA Diamond	55%	65%	+10 pp
GSM8K	70%	82%	+12 pp
IFEval	68%	71%	+3 pp
HumanEval	75%	80%	+5 pp

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:

Causa	Magnitud típica
Versión del harness diferente (plantilla cambiada)	1–4 pp
Modelo con actualización silenciosa	0,5–3 pp
Truncamiento distinto del contexto	0,5–2 pp
Seed de sampling (para generación)	0,3–1,5 pp
Tokenización con plantilla de chat vs sin plantilla	2–8 pp

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í:

Campo	Contenido
Benchmark primario	MMLU-Pro (5-shot) — diferencia en zona 60–77%
Benchmark de razonamiento	GPQA Diamond (0-shot) — diferencia en zona 55–90%
Benchmark de instrucciones	IFEval (0-shot prompt-level accuracy)
Benchmark de código	MBPP (0-shot, pass@1) — menos saturado que HumanEval
Anticontaminación	LiveBench global score (mensual)
Herramienta	lm-evaluation-harness (primary) + lighteval (secondary, HF Hub)
Versión pineada	`harness==0.4.3`, `lighteval==0.6.x`
Shots	Declarado explícitamente por benchmark
Reproducibilidad	JSON de salida guardado con SHA del modelo
Frecuencia	Por release de modelo; no en CI de cada PR (coste de GPU-horas)

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/

Calidad-Llm on lo0 — Blog Técnico