# Cómo leer los benchmarks de programación con IA y evitar elegir a un ganador sobre el papel > Qué miden HumanEval y SWE-bench, y cómo tener en cuenta el wrapper del agente, las condiciones, la antigüedad de las tareas, la varianza y el coste al consultar rankings de programación con IA. Source: https://ailoot.ai/blog/es/read-ai-coding-benchmarks/ Canonical: https://ailoot.ai/blog/es/read-ai-coding-benchmarks/ Language: es Publisher: Ailoot (https://ailoot.ai/) Translation: guide-125 Revision: sha256-b75e1825d1389a4d6619249aaf760056bc1ce6dc05d1550f1eac1c6c1e5e0338 En resumen: la cifra «resuelve el 76 por ciento de las tareas» no dice casi nada por sí sola. Lo que importa es qué conjunto de tareas produjo ese resultado, qué modelo y qué wrapper del agente se evaluaron juntos, si las tareas son recientes o antiguas y cuánto costó. Sin estas condiciones, el porcentaje sirve para un anuncio, pero no para elegir una herramienta. A continuación, explicaré en términos sencillos qué miden los dos principales benchmarks de programación, dónde está la trampa en las tablas y cómo comprobar cualquier ranking en un minuto antes de confiar en él. Se comentan a continuación definiciones históricas de benchmarks. No se reproduce una instantánea actual de clasificación con resultados emparejados; comparar puntuación o coste actuales exige tabla enlazada, fecha y configuración propias. Encontrará más información sobre cómo trabajar con modelos en la [documentación de Ailoot](https://ailoot.ai/docs/). ## ¿Qué muestra realmente el porcentaje de un benchmark?
Puntos clave El porcentaje de un benchmark es la proporción de tareas de un conjunto específico que una herramienta completó con un resultado funcional en unas condiciones concretas. Las tareas se comprueban mediante pruebas automatizadas: el código supera la prueba o no; la evaluación es objetiva y no hay términos medios. Sin embargo, el conjunto de tareas siempre es limitado y se conoce de antemano, y las condiciones de medición varían. Por tanto, la cifra responde a la pregunta «¿Cuántas de estas tareas resolvió esta herramienta de esta manera?». No responde a «¿Podrá encargarse de mi trabajo?».
Un benchmark funciona de forma sencilla. Hay una lista preparada de tareas de programación. Se le da cada tarea a la herramienta, esta devuelve código y el sistema ejecuta pruebas automatizadas para comprobar si la solución funciona. La proporción de tareas superadas es el porcentaje que aparece en la tabla. Su punto fuerte es la objetividad de la evaluación. Una prueba da verde o rojo; nadie pone una nota «a ojo». En este sentido, los benchmarks son más honestos que las reseñas o los testimonios. Su punto débil es exactamente el mismo. El conjunto de tareas es finito y todos lo conocen de antemano, incluidas las personas que entrenan los modelos. Cada medición tiene sus propias condiciones. Y es casi seguro que las tareas del conjunto no se parecen a lo que usted hace. De ahí vienen todas las trampas que comento más abajo. El porcentaje describe cómo se comporta una herramienta con una lista cerrada de tareas de otra persona; no se traslada directamente a su proyecto. ## ¿Qué mide HumanEval y por qué ya no se puede elegir una herramienta en función de él?
Puntos clave HumanEval es un conjunto antiguo de 164 pequeñas tareas de Python: se da a los modelos una descripción de una función, escriben el código y unas pruebas automatizadas verifican la tarea. Cuando se publicó en 2021, el primer Codex resolvía el 28,8 por ciento de las tareas en un intento. Hoy, los modelos más potentes completan casi todas, así que el benchmark ya no permite distinguirlos. Además, sus tareas son problemas de juguete: escribir una función a partir de una descripción está muy lejos de trabajar con un proyecto grande y activo. Una puntuación alta en HumanEval en 2026 no significa casi nada.
HumanEval se creó en OpenAI y se publicó en 2021 junto con el modelo Codex. Contiene 164 pequeñas tareas de Python: se da a los modelos una descripción en palabras de una función, escriben su cuerpo y un conjunto de pruebas automatizadas comprueba si funciona correctamente. En aquel momento, servía para distinguir bien los modelos. En su propio artículo, los autores dan esta cifra: el primer Codex resolvía el 28,8 por ciento de las tareas en un intento, mientras que GPT-3 normal no resolvía ninguna.

En HumanEval, nuestro modelo resuelve el 28,8 por ciento de los problemas, mientras que GPT-3 resuelve el 0 por ciento y GPT-J el 11,4 por ciento.

— OpenAI, artículo «Evaluating Large Language Models Trained on Code»
Desde entonces, los modelos han mejorado y, hoy, los más potentes completan casi todo HumanEval. Cuando todos rondan el 100 por ciento, la tabla deja de distinguirlos: las diferencias entre herramientas desaparecen. Esto se llama saturación del benchmark, y HumanEval lleva mucho tiempo en ese estado. El segundo defecto es más grave. Las tareas son diminutas: escribir una función a partir de una descripción. Su trabajo real es distinto: implica un proyecto grande con un historial, donde hay que entender el código de otra persona, encontrar un defecto y evitar romper el código cercano. Hay un abismo entre «escribir una función desde cero» y «corregir un error en un proyecto activo». Por eso, hoy una puntuación alta en HumanEval ya no es motivo para elegir una herramienta; más bien indica que «lo básico está cubierto». ## ¿Qué mide SWE-bench y por qué se acerca más al trabajo real?
Puntos clave SWE-bench se basa en defectos reales de proyectos populares de GitHub: 2.294 tareas de 12 repositorios de Python. La herramienta recibe una descripción del problema y modifica el código; después, el sistema ejecuta pruebas que fallaban antes del cambio y deberían pasar tras la corrección. Esto se acerca mucho más al trabajo real que HumanEval, por lo que se utiliza para comparar herramientas serias. Su historial muestra claramente su dificultad: el primer método sencillo resolvió menos del dos por ciento de las tareas.
SWE-bench es fundamentalmente distinto y, por tanto, más interesante. Se creó a partir de incidencias y pull requests reales de proyectos populares de GitHub. Según sus autores, contiene 2.294 tareas de 12 grandes repositorios de Python y se publicó en octubre de 2023. La lógica de evaluación es clara. Se toma un punto de un proyecto en el que había un defecto real y un conjunto de pruebas que fallaban en aquel momento. La herramienta recibe la descripción del problema y modifica el código. Después se ejecutan esas mismas pruebas: si pasan, la tarea está realmente resuelta; aquí nadie confía en promesas verbales.

Recopilamos 2.294 tareas revisando pull requests e incidencias de 12 repositorios populares de Python. Cada tarea se basa en una pull request vinculada a una incidencia y que modifica al menos un archivo relacionado con las pruebas.

— SWE-bench, sitio web oficial del benchmark
Las cifras iniciales muestran cuánto más difícil es esto que los problemas de juguete. El primer método de referencia obtuvo apenas un 1,96 por ciento en SWE-bench, y el primer agente alcanzó el 12,47 por ciento. En otras palabras, incluso acercarse al trabajo real de programación era difícil. Más adelante los porcentajes aumentaron, pero partieron de casi cero. Así que, cuando hoy ve grandes cifras en un ranking de agentes de programación con IA, lo más habitual es que provengan de SWE-bench o de su subconjunto verificado por personas, de 500 tareas, llamado SWE-bench Verified. Es un benchmark razonable. Pero también tiene condiciones sin las cuales el porcentaje resulta engañoso; de eso hablaré a continuación. Ni siquiera el benchmark más honesto de una tabla es todavía un resultado en su proyecto. El resultado depende de cómo trabaje con la herramienta, y la primera posición del ranking determina muy poco. Para trabajar de forma fiable importa la combinación: clon de IA, Second Brain e ingeniería del contexto. Un contexto limpio mejora su tasa de éxito personal mucho más que elegir un modelo de una tabla. ## ¿Por qué el mismo modelo muestra un porcentaje distinto?
Puntos clave Porque el resultado depende de algo más que el modelo. En cualquier medición intervienen al menos tres elementos: el propio modelo, el wrapper del agente que lo rodea y el nivel de razonamiento habilitado. Cambiar el ajuste de razonamiento puede producir filas distintas para el mismo modelo y wrapper. Sin nombre y revisión del entorno, ajustes y fuente fechada, esas filas no respaldan una comparación numérica. Por eso hay que comparar las combinaciones completas; la marca del modelo, por sí sola, no determina mucho.
Aquí se esconde el error más habitual al leer benchmarks. La gente interpreta una tabla como un ranking de modelos: este modelo es dos puntos porcentuales más inteligente que aquel. Pero hay tres elementos que influyen en el porcentaje, y el modelo solo es uno de ellos. Primero, el propio modelo. Segundo, el wrapper del agente que lo rodea: un programa que permite al modelo recorrer archivos, ejecutar comandos, leer errores y reescribir código. El mismo modelo obtiene resultados distintos con un wrapper inteligente y con uno sencillo, porque el wrapper determina cómo trabaja el modelo con el proyecto. Tercero, el nivel de razonamiento, es decir, hasta qué punto el modelo analiza cada paso. Cuanto más tiempo piensa, mayor suele ser el porcentaje y más alto el coste. Una comparación reproducible debe conservar toda la configuración. Usa esta plantilla de informe, no como clasificación medida: | Campo | Ejecución A | Ejecución B | |----|----|----| | Modelo y versión exacta | Registrar la versión probada | La misma para una comparación controlada | | Entorno del agente y revisión | Registrar repositorio y commit | Mismo entorno y commit | | Tareas y puntuación | Registrar subconjunto y revisión de evaluación | Mismas tareas y puntuación | | Razonamiento | Registrar ajuste A | Registrar ajuste B | | Resultado y pruebas | Resueltas, denominador, registros, fecha | Resueltas, denominador, registros, fecha | Así se ve qué cambió y si realmente se aísla el ajuste de razonamiento. El ejemplo numérico anterior sin enlace no se trata como un resultado medido. La regla es esta: un buen ranking siempre especifica qué modelo, qué wrapper y qué nivel de razonamiento se usaron. Si la tabla solo incluye un nombre de modelo y un porcentaje, sin especificar el wrapper, cuesta confiar en ella: no se sabe qué se midió realmente. El artículo sobre el [ranking de agentes de programación con IA](https://ailoot.ai/blog/es/ai-coding-agent-rankings/) explica mejor qué compone la combinación de «modelo más wrapper». Esto también explica por qué una herramienta con la mejor puntuación a veces le da problemas. El benchmark mide un modelo dentro del wrapper perfeccionado de otra persona y con las tareas de otra persona. Su wrapper, su proyecto y el contexto que usted proporciona al modelo son distintos. En su proyecto, el resultado depende del contexto; la fila de la tabla queda en segundo plano. ## ¿Por qué «caducan» las tareas y qué es una filtración de datos de entrenamiento?
Puntos clave Los modelos se entrenan con cantidades enormes de texto y código de Internet, y los benchmarks populares son públicos. Si las tareas y sus soluciones acabaron en los datos de entrenamiento, el modelo podría haberlas memorizado y limitarse a reproducir lo memorizado durante la evaluación en lugar de resolverlas. Esto se llama filtración de tareas en los datos de entrenamiento. Cuanto más antiguo y conocido sea el conjunto, mayor será el riesgo: un benchmark antiguo tiene más probabilidades de reflejar la memoria del modelo que su capacidad de razonamiento. Los conjuntos de tareas recientes y cerrados son más fiables que los antiguos y públicos.
Aquí está la trampa que no se ve en la cifra, pero que la invalida más que cualquier otra cosa. Los modelos se entrenan con enormes cantidades de texto y código recopilados de Internet. Y casi todos los benchmarks de programación son públicos: sus tareas, pruebas y soluciones de referencia. El mecanismo es sencillo. Si una tarea y su solución correcta llegaron a los datos de entrenamiento, el modelo podría haberlas memorizado. Durante la evaluación, quizá no resuelva realmente la tarea, sino que recupere de la memoria una respuesta conocida. Parece una solución, pero es solo un recuerdo. Esto se llama filtración de entrenamiento o contaminación de datos. Cuanto más antiguo y popular sea el conjunto de tareas, mayor será el riesgo. HumanEval está en línea desde 2021; se ha reescrito, analizado e incluido en innumerables conjuntos de datos muchas veces. Sería extraño esperar que un modelo moderno no lo hubiera «visto». Por eso, la actualidad de las tareas es un indicador de calidad independiente para un benchmark. Un buen conjunto se actualiza con regularidad o mantiene cerradas algunas tareas para que no puedan aprenderse de antemano. ¿Qué debe hacer al leer un ranking? Compruebe la fecha de las tareas y si el conjunto se actualiza. Si un benchmark se compone de defectos recientes de los últimos meses, merece más confianza. Si es un conjunto de hace cinco años, un porcentaje alto dice más sobre la buena memoria del modelo que sobre su capacidad para resolver su nueva tarea. El artículo sobre el [reciente benchmark FrontierCode](https://ailoot.ai/blog/es/frontiercode-benchmark-mergeable-ai-code/), cuyas tareas eran deliberadamente nuevas, muestra este efecto exacto con un ejemplo concreto. ## ¿Por qué a menudo no significa nada una diferencia de un par de puntos porcentuales?
Puntos clave Los benchmarks tienen varianza: la misma herramienta obtiene resultados algo distintos en las mismas tareas en diferentes ejecuciones porque el modelo no siempre responde de la misma forma. Por eso, una diferencia de uno o dos puntos entre filas contiguas de un ranking a menudo se pierde en el ruido y no indica una superioridad real. Compruebe también el precio por separado: porcentajes parecidos pueden costar muchas veces más. Compara costes solo cuando se indiquen configuraciones completas, tasas de éxito, supuestos de facturación y denominador de coste.
Otra razón por la que el primer puesto de una tabla puede ser engañoso: un modelo no responde siempre igual. Ante el mismo prompt, puede seguir una línea de razonamiento ligeramente distinta. Así que, si ejecuta una herramienta varias veces con el mismo conjunto de tareas, el porcentaje fluctúa un poco de una ejecución a otra; esa fluctuación se llama varianza. La conclusión práctica es sencilla. Cuando dos filas de un ranking difieren en uno o dos puntos porcentuales, esa diferencia bien podría ser ruido. Es absurdo perseguir una herramienta que es «dos puntos mejor»: en la siguiente ejecución las posiciones podrían intercambiarse fácilmente. Una diferencia merece considerarse significativa cuando es notable y se mantiene en un conjunto grande de tareas; unos pocos puntos no cumplen ese criterio. Y lo último, que casi siempre importa más que el propio porcentaje, es el precio. Resultados parecidos pueden costar cantidades muy distintas. Una comparación de costes necesita ambas configuraciones de modelo y entorno y todo el gasto del conjunto evaluado, incluidos intentos fallidos. Divide entre tareas intentadas para coste por intento o entre resueltas para coste por tarea resuelta e indica cuál utilizas. Este artículo no aporta una medición emparejada de coste con fuente. Por eso, lea siempre la fila del ranking junto con su precio: el porcentaje por sí solo dice poco. El artículo sobre el [coste de una tarea resuelta](https://ailoot.ai/blog/es/ai-agent-cost-per-solved-task/) explica cómo comparar justamente las herramientas por coste. ## ¿Qué preguntas hacer al comparar benchmarks de programación con IA?
Puntos clave Antes de confiar en un ranking, hágale siete preguntas: ¿Qué conjunto de tareas? ¿Son recientes o antiguas? ¿Qué modelo? ¿Qué wrapper del agente? ¿Qué nivel de razonamiento? ¿Cuál es el coste por tarea? ¿Qué magnitud tiene la varianza? Si la tabla no responde al menos a la mitad, no puede confiar en ella: probablemente sea publicidad. Compruebe por separado si las tareas del conjunto se parecen a su trabajo real, porque ni siquiera un porcentaje honesto obtenido con las tareas de otra persona se traslada a su proyecto.
Resumamos todo en una lista breve. Abra cualquier tabla de rankings y repase estos siete puntos en orden. 1. **¿Qué conjunto de tareas?** HumanEval es poco útil hoy; SWE-bench se acerca más al trabajo real. Si no se nombra el conjunto, no hace falta seguir leyendo. 2. **¿Las tareas son recientes o antiguas?** Un conjunto reciente o parcialmente cerrado es más fiable que uno antiguo y público que el modelo quizá haya aprendido. 3. **¿Qué modelo se evaluó?** El nombre y la versión exactos, no un «IA» impreciso ni el nombre de una familia de modelos. 4. **¿Qué wrapper del agente?** El porcentaje corresponde a la combinación de «modelo más wrapper». Si no se especifica el wrapper, no se sabe qué se midió. 5. **¿Qué nivel de razonamiento?** Un modelo obtiene porcentajes distintos con distintos niveles y también genera costes distintos. 6. **¿Cuánto cuesta una tarea?** Resultados parecidos pueden diferir varias veces en precio. Lea el porcentaje junto con el coste. 7. **¿Qué magnitud tiene la varianza?** Una diferencia de uno o dos puntos entre filas a menudo es solo ruido. Hay una octava pregunta, y tiene que ver con usted: **¿Se parecen a su trabajo las tareas del conjunto?** Un benchmark de tareas de Python dice poco a quien desarrolla un sitio web o un bot con otro conjunto de herramientas. Ni siquiera una cifra honesta obtenida con las tareas de otra persona garantiza un resultado en su proyecto. Solo hay una forma fiable de comprobarlo: pase unas cuantas tareas habituales por la herramienta y examine usted mismo el resultado. El artículo sobre [cómo comprobar el código generado por IA](https://ailoot.ai/blog/es/check-ai-generated-code/) explica cómo saber si el código funciona si usted no programa. ## Entonces, ¿en qué debe fijarse al final?
Puntos clave Fíjese en las condiciones que hay detrás del primer puesto, no solo en ese puesto: el conjunto de tareas y su actualidad, la combinación de «modelo más wrapper», el nivel de razonamiento, el coste por tarea y el grado de varianza. Una cifra aislada, sin estas condiciones, no demuestra nada. Y recuerde que ni siquiera un porcentaje honesto obtenido con las tareas de otra persona se traslada a su proyecto: la última palabra siempre la tienen las pruebas con sus propias tareas reales, y su resultado depende más de cómo trabaja con la herramienta que del puesto que ocupa en el ranking.
La idea principal del artículo es breve: ocupar un puesto en el ranking es motivo para examinar una herramienta más de cerca, pero tendrá que investigar por su cuenta. Una cifra alta solo dice que una herramienta rindió razonablemente bien en una lista cerrada y concreta de tareas, bajo unas condiciones específicas. El porcentaje no muestra si esas condiciones coinciden con las suyas. Así que lea lo que hay debajo de la fila del ranking: qué tareas se usaron, cuánto tiempo hace que existen, qué combinación de modelo y wrapper se utilizó, qué nivel de razonamiento se activó, cuánto cuesta y si la diferencia se pierde en el ruido. Una tabla que no responde a estas preguntas merece estar en un anuncio. La reseña [qué herramienta usar para programar en 2026](https://ailoot.ai/blog/es/ai-coding-tools/) explica qué herramienta elegir para sus tareas en primer lugar. Y esto importa más que cualquier benchmark. Incluso la mejor herramienta del ranking tiene dificultades con un contexto desordenado y funciona bien con uno limpio. Su tasa de éxito personal depende de lo que le proporcione al modelo y de cómo plantee la tarea; la fila de la tabla queda en segundo plano. El ranking ayuda a descartar las opciones claramente débiles, pero el resultado lo produce usted.
### Fuentes - [HumanEval - conjunto de datos openai/openai_humaneval (huggingface.co)](https://huggingface.co/datasets/openai/openai_humaneval) - conjunto de 164 tareas de Python, comprobadas con pruebas automatizadas
Un puesto en el ranking permite descartar las opciones débiles, pero los resultados en su proyecto dependen del método: clon de IA más Second Brain más ingeniería del contexto. Para seguir trabajando: [Ailoot](https://ailoot.ai/). ## Preguntas sobre la elección de agentes y modelos de IA ### ¿Qué registro antes de comparar dos filas de un benchmark? Modelo exacto, entorno del agente y revisión, ajustes de razonamiento, subconjunto de tareas, puntuación, fecha y fuente directa del resultado. Sin esos datos, no puede atribuirse una diferencia a un único ajuste cambiado. ### ¿El coste por tarea intentada es igual al coste por tarea resuelta? No. Divide el gasto total de evaluación entre todos los intentos para la primera medida o entre las tareas resueltas para la segunda. Incluye el gasto fallido e indica el denominador antes de comparar precios. ## Ailoot · La empresa y su cartera de proyectos Ailoot se apoya en la experiencia operativa acumulada, una amplia base de clientes, un servicio estable y el seguimiento continuo de KPI. La empresa y su cartera de proyectos: millones de clientes; ventas por miles de millones al mes. Ailoot aplica esa experiencia operativa al acceso por API a funciones de IA en productos de clientes, agentes, aplicaciones y automatizaciones.