Germán FalcioniPunta del Este · Uruguay
Análisis · IA en el panorama · Edición #0019

Cómo se miden las IAs hoy

Los benchmarks son los exámenes de la IA. Hay cinco que todavía te dicen algo — y una sola prueba que no se puede comprar: usarla una semana en tu trabajo real.

Germán Falcioni✦ Lectura: 10 min

Una tabla con porcentajes no alcanza para decidir qué IA usar. La prueba real dura una semana, no una captura de pantalla.

MMLU fue creado en 2021 por un equipo académico liderado por Dan Hendrycks en Berkeley. 14 mil preguntas de opción múltiple en 57 disciplinas, desde álgebra abstracta hasta jurisprudencia. En el paper de publicación (Hendrycks et al., 2021), los autores reportaban que GPT-3 sacaba 43.9% — comparado con un humano experto, que promediaba 89.8%. La conclusión del paper era clara: los modelos de lenguaje tenían camino por recorrer en conocimiento general.

Tres años después, en 2024, los modelos de frontera — Claude 3 Opus, GPT-4 Turbo, Gemini 1.5 Pro — sacaban entre 86% y 88.7%. Para 2025, varios cruzaron el 90%. Hoy en 2026, casi ningún laboratorio reporta MMLU como métrica diferenciadora: es piso, no techo. La vida útil de un benchmark público en la frontera de escala actual es aproximadamente dos años. Lo que se mide se optimiza; lo que se optimiza, se satura.

Esa secuencia — invención académica, adopción como estándar, saturación, descarte — es el ciclo de vida normal de cualquier benchmark de IA. Entenderlo es la base para evaluar cualquier número que leas en los próximos meses.

Taxonomía de la evaluación actual

El espacio de evaluación de modelos se divide hoy en cinco familias con propiedades metodológicas distintas.

Conocimiento y razonamiento estructurado. MMLU (2021), MMLU-Pro (2024), GPQA Diamond (2023), BigBench-Hard. Formato opción múltiple o respuesta corta, corrección programática, métrica simple. Fortaleza: reproducibilidad y comparación cruzada. Debilidad: contaminables por leaks en training data, saturables cuando la comunidad converge al techo. MMLU original está saturado; MMLU-Pro fue la respuesta (más preguntas, más difíciles), pero ya empieza a saturarse también.

Programación ejecutable. HumanEval (2021), MBPP, SWE-Bench (2023), SWE-Bench Verified (2024), LiveCodeBench. Lo que se mide es si el código compila y pasa los tests. Poca ambigüedad. SWE-Bench es especialmente interesante porque mide resolución de issues reales de GitHub con repositorios enteros como contexto — se aproxima a tarea de ingeniería de software genuina. La versión Verified filtró manualmente 500 tareas de las 2.294 originales para eliminar ambigüedad en los tests case, respondiendo a la crítica de ruido estructural del benchmark base.

Razonamiento matemático. GSM8K (2021), MATH (2021), AIME. Los dos últimos cobraron relevancia desde la aparición de modelos con chain-of-thought extendida (o1, o3 de OpenAI, Opus 4.x de Anthropic), porque la diferencia entre pensar-más y responder-directo se vuelve medible.

Preferencia humana ciega. Chatbot Arena / LMSys. Sistema Elo basado en votos humanos en batallas ciegas de pares de modelos. La propiedad metodológica clave: el usuario no sabe qué modelo responde. Es lo más cercano a una métrica de utilidad en escala que tenemos. Sus limitaciones conocidas son tres: sesgo de muestra (votantes son auto-seleccionados y concentrados en países técnicamente alfabetizados), sesgo de longitud (respuestas más largas ganan sistemáticamente a igualdad de contenido), y concentración de prompts en consultas cortas (el benchmark mide bien puntualidad, peor sostenibilidad en tareas largas).

Evaluación agéntica. AgentBench, WebArena, GAIA, τ-bench (tau-bench). Emergentes. Miden ejecución de cadenas de acciones con herramientas — navegar, buscar, escribir código, persistir contexto, interactuar con APIs. Son los benchmarks que importan para los próximos dos años y donde todavía no hay saturación.

El problema metodológico central: contaminación

Cuando un test público aparece en los datos de entrenamiento, el modelo lo memoriza en lugar de resolverlo. El efecto es medible con técnicas de detección de memorización — por ejemplo, completar el prompt dejando huecos y medir la probabilidad exacta de la respuesta correcta — pero los proveedores pocas veces publican esos análisis.

Un ejemplo concreto: durante 2023, análisis independientes sobre varios modelos abiertos encontraron que fragmentos sustanciales del test set de MMLU aparecían en datasets públicos usados para pre-training (The Pile, RefinedWeb, C4). Cuando se re-midieron esos modelos contra versiones "paraphrase-resistant" generadas post-entrenamiento, los puntajes cayeron entre 10 y 25 puntos porcentuales. Pocos laboratorios publican este análisis proactivamente.

La respuesta parcial de la comunidad es mantener sets de evaluación privados (holdouts) que cada laboratorio usa internamente. El costo metodológico es claro: no-reproducibilidad. Anthropic ha tendido a combinar reportes en benchmarks públicos con resultados en holdouts internos declarados explícitamente; OpenAI tradicionalmente publica menos detalle sobre settings específicos; DeepMind ha sido más explícito con eval cards. Esa no es una equivalencia — es una diferencia observable en política de transparencia.

La otra respuesta es re-generar el benchmark. GPQA Diamond, MMLU-Pro, y SWE-Bench Verified son ejemplos de esa carrera: cada vez que un benchmark se satura o se contamina, aparece una versión más difícil o más limpia. El ciclo se repite cada dos a tres años.

Goodhart's law aplicada al entrenamiento

"Cuando una medida se vuelve objetivo, deja de ser una buena medida." En entrenamiento de LLMs, Goodhart's law se manifiesta como el problema del gaming: un laboratorio optimiza explícitamente contra un benchmark conocido, obtiene puntajes superiores en ese test, y degrada performance fuera de distribución.

El caso más documentado fue el de varios modelos chinos durante 2024 que reportaron resultados excepcionales en GSM8K; análisis posteriores encontraron que el set de evaluación había circulado en foros técnicos previos al entrenamiento. La corrección fue de 25-30 puntos porcentuales cuando se midió con un set limpio generado post-entrenamiento.

El antídoto técnico es evaluación fuera de distribución: generar problemas con la misma estructura pero distintos del set público, y correrlos recién después del entrenamiento. Pocos proveedores lo hacen sistemáticamente por el costo de generar sets nuevos de calidad metodológica equivalente.

El problema del juez LLM

Cuando la evaluación requiere juicio de calidad ("cuál de estas dos respuestas es mejor"), una práctica común es usar otro LLM como juez — típicamente GPT-4 evaluando respuestas de otros modelos. El problema es circularidad: si evaluás modelo A contra modelo B con modelo C como juez, el resultado depende de las preferencias de C.

Estudios recientes (Zheng et al. 2023; otros follow-ups 2024-2025) muestran que los LLM-judges tienen tres sesgos sistemáticos: sesgo de verbosidad (prefieren respuestas más largas), sesgo de auto-identificación (prefieren respuestas que se parecen estilísticamente a sí mismos), y sesgo de posición (prefieren la primera respuesta mostrada en una comparación). Chatbot Arena mitiga esto usando humanos como jueces, pero introduce sesgos humanos diferentes — verbosidad sigue presente, y los votantes no son una muestra representativa.

El consenso metodológico emergente es que ninguna fuente única de juicio es suficiente: una evaluación robusta requiere combinar tests programáticos (corrección de código, matemática verificable), preferencia humana (Arena), y evaluaciones privadas fuera de distribución. Ningún proveedor publica hoy un stack completo.

Transparencia diferencial entre proveedores

Vale contrastar con precisión cómo los laboratorios principales reportan sus números, porque la diferencia es operativa, no retórica.

Anthropic publica system cards detalladas en cada release mayor, incluye secciones explícitas sobre settings de evaluación (shot count, temperatura, prompting strategy), reporta resultados en benchmarks donde Claude pierde (no solo donde gana), y mantiene política de holdouts internos declarados. Las tablas comparativas que publica tienden a usar la misma versión y settings entre competidores. Esto no es neutralidad — Anthropic sigue siendo parte interesada — pero es un régimen probatorio que permite auditar.

OpenAI ha publicado históricamente menos detalle sobre settings específicos. Varios picos reportados en lanzamientos de GPT-4 y GPT-4o se midieron con configuraciones que el usuario típico no usa en producción: mayor cómputo de inferencia, prompting asistido por ingeniería interna, re-tries con majority voting. Estos settings se documentaron a veces en technical reports posteriores, pero no en el material de lanzamiento inicial que captura el ciclo de noticias.

Google DeepMind está en un punto intermedio: Gemini releases incluyen eval cards estructuradas, pero la metodología se comunica a veces con menos granularidad que la de Anthropic.

El punto editorial: esto no es una acusación de fraude. Es la observación de que el régimen probatorio varía entre proveedores, y el lector crítico necesita saber contra qué estándar está leyendo cada tabla.

La contrapartida honesta: Chatbot Arena, que no está controlada por ninguno de los tres, es más honesta que cualquier cifra que cualquiera de ellos reporte. Cuando Claude aparece en el top de Arena y simultáneamente pierde algunos benchmarks académicos, la señal útil es Arena — porque es votación ciega, no tabla armada.

Métricas recomendadas para 2026

Para filtrar (descartar lo malo): MMLU como piso. Si un modelo no pasa de 75, no es serio para trabajo profesional.

Para razonamiento duro: GPQA Diamond y AIME. Los dos requieren pensamiento genuino y son de generación reciente, menos contaminados.

Para código: SWE-Bench Verified. Es la métrica menos gameable en el espacio de programación.

Para preferencia humana en uso cotidiano: Chatbot Arena. Difícil de inflar, sesgos conocidos y compensables.

Para agentes y uso con herramientas: AgentBench, τ-bench. Emergentes, poco saturados, relevantes para lo que viene.

Para tu caso específico: ninguno de los anteriores. Tu evaluación es tu eval privada.

Cómo armar una eval privada que funcione

Esta sección es la más importante del artículo y la que rara vez aparece en cobertura mainstream.

Una eval privada bien construida tiene cuatro elementos.

Tareas representativas. Entre 10 y 15 tareas reales que hacés en una semana normal de trabajo. No tareas hipotéticas, no tareas de benchmark — las que pagás por resolver. Ejemplos para consultoría: redactar un mail de rechazo a un cliente, resumir un contrato de 30 páginas, hacer un draft de propuesta comercial, debuggear código ajeno, traducir una carta formal. Ejemplos para developers: implementar una función con tests, refactorizar un módulo sucio, revisar un pull request. Cada perfil tiene su set.

Prompts canónicos. Escribí el prompt exacto como lo usarías en tu flujo normal. No lo optimicés para el modelo — parte de la evaluación es ver qué modelo entiende mejor tu forma natural de pedir.

Protocolo de medición. Corré cada tarea con cada modelo candidato en condiciones idénticas — misma versión, mismo día, sin contexto previo. Idealmente doble ciego: alguien más etiqueta los outputs antes de que vos los veas.

Rúbrica de scoring. Dos dimensiones mínimas: calidad del output (1 a 5) y costo de edición para dejarlo presentable (1 a 5, invertido — menos edición es mejor). Opcional: tercera dimensión de confianza, "¿me animaría a entregarlo sin revisión detallada?". Sumá puntajes por tarea, promediá por modelo.

El resultado es una tabla interna que te dice, con evidencia propia, qué modelo rinde mejor en tu trabajo específico. Esa tabla vale más que cualquier paper de benchmark.

Las empresas serias — consultoras, firmas legales, fintechs, equipos de producto — hacen esto antes de adoptar un proveedor. Es lo que Anthropic, OpenAI y Google llaman informalmente "bakeoff": el cliente prueba los tres modelos con su eval privada y decide. En mi experiencia de consultoría, el ganador del bakeoff varía por caso — pero la frecuencia con la que gana Claude en tareas de producción con responsabilidad es la razón por la que es mi default.

Tesis editorial

Cierro con una tesis que excede el reporting metodológico y entra en evaluación.

El benchmark más valioso para un profesional serio no está publicado en ningún paper ni aparece en ninguna tabla de lanzamiento. Es el que construís vos, con 10 a 15 tareas reales de tu trabajo, repetidas con cada modelo candidato, scoreadas con criterios que vos definís, y actualizadas cada tres o seis meses. Esa eval privada es lo que las empresas serias hacen antes de adoptar un proveedor, lo que los consultores bien calibrados hacen antes de recomendar una herramienta, y lo que la prensa de IA rara vez explica a sus lectores.

La razón por la que no se explica es estructural: los benchmarks públicos generan titulares; las evals privadas generan decisiones. Y los incentivos del ciclo de noticias priorizan titulares. Por eso la mayor parte de la cobertura de "qué IA es mejor" en 2026 sigue siendo una lectura ingenua de tablas que deberían leerse como evidencia de parte interesada.

La línea editorial de este diario es explícita en ese punto: los benchmarks oficiales se reportan con su régimen probatorio declarado, Chatbot Arena se cita como contraste cuando corresponde, y la recomendación operativa siempre apunta a la eval privada. No porque sea más glamorosa — al contrario, es más trabajo. Porque es la única que responde la pregunta que importa.

¿Tenés una eval privada armada para tu trabajo, o estás eligiendo IA por tabla todavía? Si la respuesta es la segunda, la tarde que te tome armar las 10 tareas y correrlas probablemente sea la mejor inversión de tiempo en infraestructura de herramientas que vas a hacer este año.

Siguiente artículoQué es un prompt — la instrucción más importante que vas a escribir