Los benchmarks de IA ignoran el 90% del trabajo real

Una amiga mía dirige operaciones en una empresa de logística de tamaño mediano, y la primavera pasada su equipo dedicó tres semanas a evaluar si un LLM podía encargarse de su flujo de gestión de excepciones: el trabajo poco glamuroso de conciliar facturas que no cuadran con las órdenes de compra, en tres sistemas que se odian entre sí. El dossier del proveedor estaba lleno de cifras impresionantes: MMLU, GSM8K, HumanEval, un puñado de benchmarks agénticos. El modelo aprobó con sobresaliente todas las pruebas enlatadas que le pusieron delante. Luego lo enfrentaron a una semana real de excepciones y, con total seguridad, emparejó una factura de 14.000 $ con la orden de compra equivocada porque un proveedor había abreviado su nombre de forma diferente. Ningún leaderboard mide eso.

Esa brecha ya se puede medir. Un estudio reciente que cruzó los benchmarks públicos de IA con la taxonomía O*NET del Departamento de Trabajo de EE. UU. (923 ocupaciones y 18.797 tareas que componen el trabajo estadounidense) concluyó que el 90% de las horas laborales en EE. UU. se dedica a tareas con poca o nula cobertura de benchmarks. Solo 208 de las 923 ocupaciones tienen al menos una tarea respaldada por cinco o más prompts de benchmark. Seis de las 22 familias profesionales no tienen ninguna. La conclusión incómoda no es que la IA sea débil. Es que nuestros instrumentos para medir la capacidad de la IA apuntan casi por completo a la parte equivocada de la economía.

Qué cubren realmente los benchmarks de IA

La metodología de este estudio merece entenderse, porque es más cuidadosa de lo que sugiere el titular. Los investigadores tomaron 29 benchmarks agénticos de alta calidad y sin saturar (pruebas en las que los modelos tienen que ejecutar trabajo de verdad, en lugar de responder preguntas) y usaron un juez LLM, validado contra expertos humanos, para etiquetar cada prompt de benchmark con las tareas O*NET que ejercita. Una tarea cuenta como «cubierta» si al menos cinco prompts se le asignan. Si combinas eso con estimaciones de cuánto tiempo de trabajo consume cada tarea, obtienes una imagen de toda la economía de lo que nuestra batería de evaluación puede ver.

Lo que puede ver es estrecho y alto, no amplio. La ingeniería de software y el análisis financiero están saturados de benchmarks. Conducir camiones, operar plantas de gas, el servicio de restauración y la mayor parte del trabajo diario de la sanidad son prácticamente invisibles. Y el sesgo no solo tiene que ver con qué tareas son técnicamente automatizables. Las tareas etiquetadas como «expuestas a la IA» tienen unas seis veces más probabilidades de tener benchmark que las no expuestas, lo cual tiene sentido, pero incluso controlando por eso, las tareas de ocupaciones con grandes masas salariales totales aparecen de forma significativamente sobrerrepresentada. Las tareas de los abogados están muy cubiertas. Los secretarios jurídicos y los oficiales de juzgado, que se enfrentan a una exposición similar a la IA, apenas aparecen.

Léelo otra vez: estamos evaluando la IA contra la versión prestigiosa de un trabajo y pasando por alto la versión que la mayoría de la gente realmente desempeña. La larga cola del trabajo intelectual de salario medio (los coordinadores, administrativos, especialistas y planificadores cuyas horas suman una parte enorme de la economía) tiene casi cero infraestructura de medición. Cuando alguien afirma que la IA puede hacer un determinado porcentaje del «trabajo intelectual», pregunta qué trabajo intelectual, medido cómo y contra qué lista de tareas. La respuesta honesta suele ser: una rebanada fina y poco representativa, medida con pruebas diseñadas para artículos de investigación.

La saturación de benchmarks es un fallo de diseño de la evaluación

Pasé años construyendo pipelines de evaluación, y la lección más dura fue esta: un benchmark es un modelo del mundo, y la mayoría de los benchmarks son modelos pésimos. Comprimen una tarea humana desordenada, contextual y de varios pasos en un prompt limpio con una respuesta verificable, porque eso es lo barato de calificar. Después, la ley de Goodhart hace el resto. En cuanto un benchmark se convierte en el objetivo del desarrollo de modelos, deja de medir la capacidad que pretendía representar. Los datos de entrenamiento absorben la distribución del test, los equipos ajustan contra el leaderboard, y las puntuaciones suben mientras el rendimiento en el mundo real se queda estancado o empeora.

La saturación es el síntoma visible. Cuando todos los modelos de frontera superan el 90% en una prueba, la prueba ha dejado de discriminar, pero el problema más profundo es que respondemos construyendo otro benchmark del mismo estilo, que cubre los mismos tipos de tareas, porque son las que sabemos calificar automáticamente. El QA de opción múltiple engendra QA de opción múltiple más difícil. Los retos de programación engendran retos de programación más difíciles. Mientras tanto, nadie construye el benchmark para «detectar que la cláusula de indemnización de este contrato contradice discretamente la hoja de condiciones de marzo», porque calificar eso exige un abogado, tiempo y juicios que se resisten a la automatización.

Por eso no comparto el planteamiento de que la saturación de benchmarks signifique que la IA ha «resuelto» un dominio. La saturación significa que el instrumento se ha quedado al límite, punto. Un termómetro que marca 40 °C no demuestra que la habitación esté a 40 grados; demuestra que necesitas otro termómetro. Si evalúas modelos para producción, y sobre todo si estás construyendo sistemas de decisión basados en LLM donde los errores tienen costes reales, las diferencias en el leaderboard de benchmarks saturados deberían pesar casi nada en tu decisión.

Sabemos con precisión lo buenos que son los modelos en el trabajo que hemos decidido medir. Sabemos casi nada sobre el otro noventa por ciento.

El efecto farola en la evaluación de la IA

Hay un viejo chiste sobre un borracho que busca sus llaves bajo una farola, no porque las haya perdido allí, sino porque es donde hay luz. La construcción de benchmarks sigue la misma lógica, y los datos confirman que no es aleatorio. El estudio de cruce encontró que la importancia de una tarea dentro de su ocupación predice su cobertura: las tareas de O*NET que se consideran más importantes para su ocupación tienen entre seis y diez veces más probabilidades de tener benchmark que las menos importantes. A primera vista suena a priorización sensata. En la práctica significa que medimos las tareas de escaparate y nos saltamos el tejido conectivo.

Todo trabajo está hecho sobre todo de tejido conectivo. La tarea de un ingeniero de software que tiene benchmark es «implementa una función que pase estos tests». Su jornada real incluye leer la migración a medio hacer de un compañero, averiguar qué stakeholder es realmente dueño de una decisión y darse cuenta de que el ticket describe el problema equivocado. Ya he escrito antes sobre cómo las herramientas de programación agéntica triunfan o fracasan justo en esto: el bucle, el contexto y los límites de permisos importan más que la calidad bruta de generación. Nada de eso aparece en una puntuación al estilo HumanEval.

Además, hay un problema de definición sutil en las propias cifras de cobertura. «Cubierta» significa que cinco o más prompts se asignan a una tarea, no que esos cinco prompts capturen la tarea. Trece prompts sobre cómo aconsejar a los padres en problemas de crianza no representan lo que hace un trabajador social a lo largo de su carga de casos, de un juzgado o de una visita a domicilio. Si aplicáramos la definición que tendría cualquier persona de «bien cubierta», la proporción medida de la economía no sería del 10%. Sería prácticamente cero. La farola no solo es estrecha; la luz que proyecta es tenue.

Los modelos generan, pero nadie evalúa el juicio

Aquí está la asimetría que me parece más demoledora. Casi todos los benchmarks existentes prueban la producción: escribe el código, redacta el memo, resuelve el problema. Pero la mitad económicamente crítica de la mayoría de tareas reales es la detección: cazar el error, señalar la incoherencia, saber cuándo la respuesta segura es incorrecta. El valor de un contable junior no está en producir una conciliación; está en notar que un número huele mal. Los benchmarks casi nunca prueban eso, porque construir una tarea calificable de detección de errores es mucho más difícil que construir una de generación. Necesitas artefactos realistas con fallos, errores plausibles pero sutiles y acuerdo humano sobre qué cuenta como detectado.

Esta es la falacia del portero aplicada al diseño de evaluaciones. Sustituyes a un portero por una puerta automática y descubres, demasiado tarde, que el portero también recibía a los inquilinos, aceptaba paquetes y vigilaba la calle. Automatizas la parte evaluada de un trabajo y descubres que las partes no evaluadas sostenían todo lo demás. El modelo de mi amiga de logística podía redactar notas de conciliación excelentes (la tarea visible) mientras estropeaba en silencio el emparejamiento, el juicio que hacía valer la pena escribir esas notas. La batería de evaluación puntuó el adorno y pasó por alto el plato principal.

Hasta que la detección de errores no reciba un tratamiento de primera categoría en los benchmarks, espera una brecha persistente entre el rendimiento en demos y el rendimiento en producción. Es la misma brecha que existe entre lo que dice una especificación y lo que hace la implementación, y como en el software, ahí es donde nacen los fallos. Un modelo que genera al percentil 90 y verifica al percentil 30 es, en producción, un empleado del percentil 30 con ventaja de velocidad al teclear.

Ponderar las evaluaciones según la distribución real de tareas

La idea más práctica del trabajo de cruce de benchmarks es también la más simple: si los benchmarks sobrerrepresentan algunas tareas, deja de promediar sobre prompts y empieza a promediar sobre tareas, ponderadas por el tiempo de trabajo que consume realmente cada una. Un promedio ingenuo de todos los prompts etiquetados como «analista financiero» está dominado por la tarea que casualmente tiene más prompts de benchmark, normalmente la que fue más fácil de construir como dataset. Un promedio ponderado con O*NET da a cada tarea real el mismo peso. La diferencia puede ser espectacular.

import pandas as pd
# The tasks an occupation actually performs, with time shares
# (from O*NET, your own ticket logs, or time-tracking data)
tasks = pd.DataFrame({
"task": ["draft contract", "advise client", "review filing", "coordinate closing"],
"time_share": [0.30, 0.25, 0.35, 0.10],
})
# Model results: one row per eval prompt, mapped to the task it exercises
results = pd.DataFrame({
"prompt_id": ["p1", "p2", "p3", "p4", "p5"],
"task": ["draft contract", "draft contract", "draft contract",
"review filing", "coordinate closing"],
"score": [0.92, 0.88, 0.95, 0.61, 0.40],
})
# Naive: flat average over prompts. Drafting has 3 of 5 prompts,
# so the score is dominated by the model's best task.
naive = results["score"].mean()  # 0.752
# Task-weighted: average within each task first, then weight by
# the share of working hours that task consumes.
per_task = results.groupby("task")["score"].mean()
weights = tasks.set_index("task")["time_share"]
weighted = (per_task * weights).sum() / weights[per_task.index].sum()
# 0.30*0.917 + 0.35*0.61 + 0.10*0.40, over covered time (0.75) = 0.705
# vs naive 0.752 — and 'advise client' (25% of the job) has no data at all

Hay dos cosas que notar en ese fragmento. Primero, la puntuación ponderada baja porque las tareas más débiles del modelo estaban infrarrepresentadas en el conjunto de prompts, exactamente la distorsión que oculta un promedio plano. Segundo, y más importante: «asesorar al cliente» desaparece por completo del cálculo porque ningún prompt se le asigna. Cualquier esquema de ponderación descarta en silencio las tareas sin cobertura, y la falta de cobertura es lo normal en la mayor parte de la economía. Ponderar corrige el problema de la ponderación. No puede corregir el problema de los datos que faltan. Eso exige construir evaluaciones nuevas, no volver a promediar las viejas.

Cómo evaluar la IA frente al trabajo que realmente haces

Si estás eligiendo o desplegando modelos, la brecha de cobertura de toda la economía tiene una implicación concreta: los benchmarks públicos son un prior débil para tu caso de uso, a menos que resulte que estás en la pequeña esquina brillante que miden. Así que construye tu propia esquina. Suena menos heroico de lo que parece, y supera con mucho confiar en el dossier de un proveedor.

• Muestrea tareas de tus registros, no de la imaginación. Saca una semana de tickets, correos o excepciones reales y muestrea según la frecuencia. Tu conjunto de evaluación debería parecerse al histograma de tu carga de trabajo, incluida la cola aburrida: la cola aburrida es la mayor parte del trabajo.
• Pondera por tiempo o coste y reporta ambos números. Un promedio plano y uno ponderado acotan la verdad. Si un modelo gana en el promedio plano pero pierde en el ponderado, es bueno en las tareas fáciles de probar, justo el modo de fallo que estás buscando detectar.
• Incluye tareas de verificación. Toma resultados reales, incluidos algunos que sabes que están mal, y puntúa al modelo por cazar errores plantados y naturales. En mi experiencia, la habilidad de detección y la de generación apenas están correlacionadas, y la detección es lo que realmente compras.
• Mantén un conjunto privado y renuévalo. Cualquier evaluación que reutilices durante meses se convierte en un objetivo de entrenamiento, aunque sea sin querer, en cuanto alguien empieza a ajustar prompts contra ella. Rota los casos cada trimestre.
• Puntúa los resultados de extremo a extremo siempre que sea posible. Si la tarea es «concilia esta factura», califica la conciliación, no la prosa intermedia. Las métricas intermedias halagan a los modelos del mismo modo que los tests unitarios halagan a un código sin cobertura de integración.

Hay un efecto final, más silencioso, que vale la pena nombrar, y que reconocerá cualquiera que use herramientas de programación con IA a diario: la enfermedad de costes de Baumol a microescala. Cuando la generación se vuelve veinte veces más rápida, no pasas el día generando. Pasas el día en las partes que no se aceleraron: revisar, coordinar, verificar, decidir. El remanente sin benchmark no se encoge a medida que la IA mejora; crece para llenar el tiempo liberado, y se convierte en una parte cada vez mayor de lo que determina si valió la pena desplegar la IA. Medir la porción automatizable con una precisión cada vez mayor mientras se ignora el remanente no solo es incompleto. Invierte lo que importa.

Nada de esto es un argumento de que el progreso de la IA sea falso. Las ganancias en capacidad son reales, y yo he apostado proyectos por ellas. Es un argumento de que nuestra cultura de medición apunta a la distribución equivocada. Los benchmarks se construyeron donde los prompts eran baratos de escribir y calificar: código, matemáticas, conocimiento de tipo examen. La economía en su mayoría no es eso. Hasta que la evaluación se ponga al día, trata cada afirmación de capacidad que aparezca en titulares como una afirmación sobre la décima parte brillante del mapa, y construye las evaluaciones que cubran tu propio noventa por ciento oscuro. Las organizaciones que hagan este trabajo de medición aburrido y poco glamuroso tomarán mejores decisiones de despliegue que todos los que refrescan leaderboards, y no será ni de lejos una competencia reñida.