SevenTnewS

Análisis de Benchmark

HumanEval Medía si la IA Podía Programar. Nunca Preguntó si el Código Era Trabajo Real

Los 164 problemas de finalización de funciones de HumanEval se convirtieron en la prueba estándar para la capacidad de codificación de la IA, pero la memorización y su alcance limitado dejaron una amplia brecha entre aprobar el benchmark y manejar una base de código real, una brecha que SWE-bench fue construido para exponer.

Emmanuel Fabrice Omgbwa Yasse

2026-07-30 · 2 min de lectura

HumanEval Medía si la IA Podía Programar. Nunca Preguntó si el Código Era Trabajo Real
Fuentes : Évaluation et B…·HumanEval — off…·Evaluating Larg…

HumanEval le pide a un modelo que complete una función de Python a partir de un docstring, luego verifica la salida contra pruebas unitarias. Es una configuración limpia: 164 problemas, aprobado/reprobado sin ambigüedad, sin necesidad de un evaluador humano. Esa limpieza es por lo que se convirtió en el punto de referencia para afirmaciones de "este modelo puede programar" durante la primera ola de LLMs generadores de código.

También es por lo que dejó de ser útil. Los problemas son cortos, autónomos y lo suficientemente antiguos como para haber sido copiados, discutidos y resueltos en repositorios públicos miles de veces. La investigación sobre la memorización de modelos de código ha encontrado una relación directa entre el tamaño del modelo y la capacidad de reproducir soluciones conocidas al pie de la letra, el mismo patrón de contaminación que socavó MMLU y GSM8K, pero aplicado al código en lugar de trivialidades. Un modelo puede aprobar HumanEval al haber memorizado variantes cercanas de exactamente estos 164 problemas, sin que esa habilidad se transfiera a una sola línea de código que no haya visto antes.

La verdadera brecha: funciones de juguete versus repositorios reales

El problema más profundo no es la contaminación, sin embargo. Es el alcance. Los problemas de HumanEval son del tipo que verías en una entrevista de programación inicial: escribir una función que invierte una cadena, escribir una función que verifica si un número es primo. Escribir software profesionalmente no se parece en nada a eso. Significa entender un código base existente, rastrear un error a través de múltiples archivos, respetar una API que alguien más diseñó y no romper pruebas que no escribiste.

SWE-bench fue construido para cerrar exactamente esa brecha, evaluando modelos en issues reales de GitHub en lugar de funciones sintéticas. Los resultados no fueron amables con la narrativa de la era HumanEval. Los modelos que parecían fuertes en la finalización de funciones aisladas vieron colapsar sus tasas de éxito una vez que se les pidió resolver un ticket real en un repositorio real, especialmente en bases de código privadas y creadas recientemente donde la memorización no puede ayudar. Mientras que los mejores modelos superan el 70% al 95% en problemas públicos y verificados de SWE-bench, ese mismo nivel de modelo cae aproximadamente al 23% en los repositorios privados de SWE-bench Pro, y aún más en su conjunto de exclusión confidencial. Ese colapso es la verdadera historia que HumanEval nunca fue diseñado para contar.

Para qué sigue siendo útil HumanEval

Como una prueba de humo de cinco minutos, todavía funciona: si un modelo no puede completar una función de invertir cadena, algo anda muy mal. Pero como evidencia de que se puede confiar en un modelo para una base de código de producción, nunca midió lo que todos asumían que medía. El cambio de la industria hacia SWE-bench, y hacia benchmarks agentivos que prueban el uso de herramientas y la edición de múltiples archivos en lugar de la finalización de una sola función, es una admisión tácita de que HumanEval respondió una pregunta mucho más limitada de la que la gente estaba haciendo.

Lo esencial de la tecnología en 3 minutos cada mañana

Un correo, cada día laborable, con lo que realmente importa en IA y tecnología.