Cómo leer benchmarks de IA sin que te engañen

¿Qué es un benchmark?

En informática, un benchmark es una prueba que ejecuta programas u operaciones para medir el rendimiento de un sistema. Las especificaciones por sí solas no bastan para comparar: un procesador con menor velocidad de reloj puede rendir igual o mejor que otro más rápido en el papel. Por eso se usan cargas de trabajo estándar.

En IA, un benchmark puede ser un conjunto de preguntas de conocimiento, de problemas de programación o de tareas de ingeniería de software, con una forma automática de saber si la respuesta es correcta. El modelo responde y se calcula el porcentaje de aciertos. Otros benchmarks usan evaluación humana por pares: dos respuestas anónimas, una persona vota cuál prefiere.

¿Qué miden los benchmarks más conocidos?

Estos cuatro aparecen una y otra vez en las presentaciones de los proveedores. La tabla resume qué mide cada uno y qué reportaron sus autores al publicarlo.

Las cifras de la tabla son las del momento de cada publicación. Sirven para ver la escala de la prueba, no para comparar modelos de hoy: para eso hay que consultar la tabla vigente de cada benchmark, con su fecha y su configuración. Arena, por ejemplo, nació en abril de 2023 como Chatbot Arena, pasó a llamarse LMArena y desde el 28 de enero de 2026 se llama Arena.

¿Por qué los puntajes pueden engañar?

La ley de Goodhart resume el problema. En la formulación popularizada por la antropóloga Marilyn Strathern en 1997: cuando una medida se convierte en un objetivo, deja de ser una buena medida. Si los laboratorios optimizan para un benchmark, el puntaje sube sin que necesariamente suba la utilidad en otras tareas. Los benchmarks de hardware ya tenían el problema: los fabricantes tienden a ajustar sus productos para las pruebas estándar, y muchos benchmarks se centran solo en la velocidad y dejan fuera el costo total.

Hay casos concretos con IA:

• Pruebas que se agotan. Según el análisis de Latent Space sobre el anuncio de OpenAI de febrero de 2026, OpenAI dejó de reportar SWE-bench Verified. Encontró que modelos de frontera podían reproducir parches o enunciados de tareas concretas, probablemente porque esos repositorios abiertos están en los datos de entrenamiento. Una revisión de 138 problemas difíciles halló además pruebas que rechazaban soluciones correctas o exigían funciones que el enunciado no mencionaba. OpenAI recomienda ahora SWE-bench Pro. Es la contaminación: si las preguntas estaban en el entrenamiento, el puntaje mide memoria, no capacidad.
• Rankings con ventajas desiguales. El estudio The Leaderboard Illusion (abril de 2025) sostiene que las pruebas privadas permiten a algunos proveedores probar varias variantes y publicar solo la mejor. Cita 27 variantes privadas probadas por Meta antes del lanzamiento de Llama 4 y estima que Google y OpenAI recibieron el 19,2 % y el 20,4 % de los datos de Arena. Son afirmaciones de sus autores, pero muestran por qué un ranking público no es una vara neutral.
• Versiones distintas del mismo modelo. Meta presentó Llama 4 Maverick en LMArena con una versión distinta de la que publicó, y LMArena actualizó sus políticas en abril de 2025.
• Configuración. Temperatura, número de intentos o herramientas activadas cambian el resultado. Dos puntajes solo se comparan si se midieron igual.

¿Qué revisar antes de creerle a un puntaje?

Un diseñador que participa en la elección de un modelo no necesita calcular nada, pero sí hacer buenas preguntas. Un puntaje de programación no dice nada sobre la calidad de un texto de bienvenida, y tu usuario no responde preguntas de examen.

¿Cómo evaluar con tus propios casos?

Un proceso práctico para el equipo:

1. Reúne casos reales de tu producto: como punto de partida, entre 30 y 50, con entradas tal como llegan de los usuarios.
2. Define qué es una buena respuesta con criterios concretos: correcta, con el tono de marca, en el formato pedido, sin datos inventados.
3. Ejecuta los candidatos con el mismo prompt, la misma temperatura y el mismo contexto.
4. Califica a ciegas: quien evalúa no debe saber qué modelo generó cada respuesta.
5. Mide además latencia y costo por respuesta, porque la mejor respuesta no siempre es la más útil. Un modelo pequeño que cumple tus criterios puede ser la mejor decisión.
6. Repite la prueba cuando cambien el modelo o el prompt. Si además estás decidiendo entre usar una API o un modelo propio, mira build vs. buy.

Ejemplo

Ejemplo ilustrativo: un equipo quiere elegir entre dos modelos para un asistente de atención al cliente. El proveedor del modelo A publica un puntaje mayor en un benchmark de razonamiento. El equipo arma 40 consultas reales de clientes y califica a ciegas. El modelo B obtiene mejor calificación en tono y en apego a la política de devoluciones, y cuesta un tercio menos por respuesta. El benchmark no falló; simplemente medía otra cosa. La decisión se toma con la tabla de casos reales y el costo.

Errores comunes

• Elegir un modelo solo por su posición en un ranking general.
• Comparar puntajes publicados con configuraciones distintas o de fechas distintas.
• Citar una cifra de un paper de 2021 como si describiera los modelos actuales.
• Ignorar el tamaño de la muestra y las diferencias pequeñas.
• Evaluar sin ciego, de modo que la marca del modelo influya en la calificación.
• Olvidar repetir la evaluación cuando el proveedor actualiza el modelo.

Fuentes

• Measuring Massive Multitask Language Understanding (arXiv:2009.03300)
• Evaluating Large Language Models Trained on Code (arXiv:2107.03374)
• SWE-bench: Can Language Models Resolve Real-World GitHub Issues? (arXiv:2310.06770)
• Chatbot Arena: An Open Platform for Evaluating LLMs by Human Preference (arXiv:2403.04132)
• The Leaderboard Illusion (arXiv:2504.20879)
• Arena (AI platform), Wikipedia
• SWE-Bench is dead, Latent Space
• Goodhart’s law, Wikipedia
• Benchmark (computing), Wikipedia