- La evaluación de las capacidades de programación de los modelos de IA se vincula directamente con decisiones de despliegue y seguridad, pero una auditoría de OpenAI estima que alrededor del 30% de las tareas de SWE-Bench Pro están rotas
- SWE-Bench Pro apuntaba a un alcance de tareas más largo y problemas más realistas, pero se volvió difícil confiar tal cual en el resultado de que la tasa de aprobación en 731 tareas públicas subiera de 23.3% a 80.3% en solo 8 meses
- Los defectos se dividen en pruebas excesivamente estrictas, prompts subespecificados, pruebas de baja cobertura y prompts engañosos; envíos correctos pueden fallar o correcciones incompletas pueden pasar
- La auditoría marcó 286 tareas potencialmente problemáticas con base en intentos de modelos, metadatos de tareas y seguimiento de fallas, y luego pasaron por revisión independiente de un agente de investigación y 5 ingenieros experimentados
- OpenAI retiró su recomendación de adoptar SWE-Bench Pro; los benchmarks de evaluación deben aportar señales significativas que no distorsionen el juicio sobre las capacidades y la seguridad de los modelos
Problemas revelados por la auditoría de SWE-Bench Pro
- OpenAI auditó SWE-Bench Pro y estima que alrededor del 30% de todas las tareas están rotas
- Medir con precisión las capacidades de los modelos también afecta las decisiones de despliegue y seguridad según el Preparedness Framework
- Las evaluaciones defectuosas pueden llevar a entender mal las capacidades reales de un modelo y alterar los juicios de seguridad y las prioridades de investigación
Objetivo de SWE-Bench Pro y cambios en la tasa de aprobación
- OpenAI ya había identificado problemas de diseño y contaminación en el ampliamente usado SWE-bench Verified, y concluyó que esa evaluación ya no ofrecía una señal significativa sobre las capacidades de desarrollo de software
- En ese momento, OpenAI recomendó a la comunidad migrar a SWE-Bench Pro
- SWE-Bench Pro fue diseñado para mejorar SWE-bench Verified y hacer seguimiento de capacidades de programación agéntica con un alcance de tareas más largo y desafíos de programación más realistas
- Las tareas se extraen programáticamente de historiales de cambios de funcionalidades en repositorios públicos y privados
- El modelo debe implementar una solución que pase las pruebas de la nueva funcionalidad sin romper la funcionalidad existente
- En la partición pública de 731 tareas, la tasa de aprobación de modelos frontier subió de 23.3% a 80.3% durante 8 meses
Pipeline de aseguramiento de calidad
- OpenAI creó un pipeline de aseguramiento de calidad para verificar que cada punto de datos refleje capacidades reales del modelo
- Los filtros automáticos iniciales revisan las instrucciones dadas al modelo, sus intentos de solución y las pruebas de calificación para marcar ejemplos rotos o sospechosos
- En este proceso se marcaron 286 tareas potencialmente problemáticas
- El subconjunto marcado fue revisado con mayor profundidad por dos vías
- Revisión con agentes supervisada por humanos: un agente de investigación realizó verificaciones detalladas y luego hubo un juicio humano final
- Campaña de anotación humana: desarrolladores de software experimentados revisaron directamente las tareas
Cómo fueron las revisiones con agentes y humanas
- Los problemas marcados fueron auditados por un agente de investigación basado en Codex
- El agente tenía acceso al repositorio de la tarea y al entorno de ejecución
- Podía ejecutar pruebas, inspeccionar archivos del repositorio e investigar intentos de modelos y modos de falla comunes
- Se usó para distinguir ambigüedades razonables resolubles a partir del código circundante y las convenciones del repositorio, de casos reales de subespecificación
- Tras varias rondas de auditorías profundas independientes, investigadores revisaron los resúmenes y asignaron el juicio final y las etiquetas de problema
- En la campaña paralela de anotación humana, ingenieros de software experimentados recibieron capacitación sobre los objetivos del benchmark, la clasificación de problemas y los casos límite antes de revisar las tareas
- Cada tarea fue revisada por 5 ingenieros
- Primero, los revisores emitieron un juicio independiente con base en la descripción visible del problema, los casos de prueba y el gold patch, la solución de referencia correcta
- Luego usaron análisis o registros del pipeline como contexto de apoyo
- Asignaron etiquetas y severidad con base en evidencia concreta, y escalaron para revisión adicional los desacuerdos o casos de baja confianza
Cuatro tipos de fallas
- Los problemas identificados en la auditoría se agrupan principalmente en cuatro categorías
- Pruebas excesivamente estrictas: invalidan envíos funcionalmente correctos al imponer detalles de implementación específicos que no están en el prompt
- Prompts subespecificados: omiten requisitos exigidos por pruebas ocultas pero difíciles de inferir razonablemente
- Pruebas de baja cobertura: no verifican suficientemente la funcionalidad solicitada, por lo que correcciones incompletas también pueden pasar
- Prompts engañosos: inducen al modelo a un comportamiento incorrecto o contradicen los requisitos de las pruebas
- En algunas tareas, el prompt pedía una implementación específica, pero los casos de prueba ocultos esperaban otro comportamiento
Diferencias entre la revisión humana y la revisión con agentes
- Los revisores humanos tenían más probabilidad que el agente de investigación de marcar una tarea como rota
- Hubo diferencias en los juicios de categoría entre las dos vías de revisión, pero entre las tareas marcadas no hubo casos en que “no rota” fuera la etiqueta más frecuente en las etiquetas humanas
- La categoría marcada por el pipeline con agentes y el juicio de los revisores humanos coincidieron en el 74% de los casos
- Los revisores humanos también seleccionaron múltiples etiquetas para una misma tarea con mayor frecuencia
- Esto indica que las tareas estaban rotas de varias formas o no encajaban limpiamente en una sola categoría
- Un pipeline que combina agentes y revisores capturó los modos de falla amplios encontrados por humanos, pero contó de forma conservadora menos problemas adicionales o duplicados
- La mayor diferencia apareció en las pruebas de baja cobertura
- Los humanos las eligieron como el problema más común en el 9.4% del benchmark
- El pipeline con agentes las marcó en 4.1%
Por qué es difícil construir benchmarks
- Los casos de SWE-Bench Pro y SWE-bench Verified muestran que los benchmarks deben validarse rigurosamente
- Los issues y pull requests de repositorios open source se crean originalmente para la colaboración humana, no para evaluar modelos
- En entornos con mucho ida y vuelta entre mantenedores y contribuyentes, la descripción del problema, el código fusionado y las pruebas unitarias no siempre forman una tarea limpia e independiente para evaluación de modelos
- Las pruebas incluidas en un pull request suelen escribirse para validar un cambio específico, por lo que pueden imponer una implementación específica en vez de criterios de solución independientes del modo de implementación
Dirección futura de las evaluaciones
- A medida que mejoran las capacidades de los modelos, también se vuelve más fácil encontrar defectos en las evaluaciones
- Los modelos mejorados pueden inspeccionar prompts, pruebas, parches, trazas de ejecución y casos límite con mayor profundidad y consistencia, revelando problemas de benchmarks que antes eran difíciles o costosos de encontrar a gran escala
- OpenAI espera que la comunidad de evaluación más amplia desarrolle nuevos benchmarks creados directamente por desarrolladores de software experimentados con el propósito de probar capacidades de modelos
- Este enfoque permite una mejor supervisión humana durante todo el proceso, manteniendo a la vez la alta dificultad y el realismo que se busca medir
- OpenAI retira su recomendación previa de adoptar SWE-Bench Pro debido a los problemas revelados en este análisis
- Las evaluaciones deben ser difíciles de manipular, fáciles de confiar y aportar señales significativas que reflejen realmente las capacidades o el estado de alineación de los modelos
1 comentarios
Opiniones de Hacker News
Hay que medir eficiencia e inteligencia a la vez. Los modelos pequeños podrían usar estrategias como probar los resultados mediante uso de la computadora o dedicar más tiempo al problema y verificar la salida, mientras que los modelos grandes podrían tener poco presupuesto para sus propias pruebas, así que surgirían diferencias tácticas interesantes.
https://artificialanalysis.ai/?cost=intelligence-vs-cost-per...
Toby Ord hizo lo que pudo con datos públicos, pero los resultados no se ven muy bien.
https://www.tobyord.com/writing/hourly-costs-for-ai-agents
A eso se suman trampas a nivel del harness de ejecución, reward hacking del modelo, etc. Lo que me sigue molestando después de varios meses es la entrega oficial de gpt-5.5, en particular esta tarea: https://www.tbench.ai/leaderboard/terminal-bench/2.0/codex/0...
Según https://github.com/harbor-framework/terminal-bench-2/blob/ma..., los límites de tiempo de la tarea son 1200 segundos para el verifier, 1200 segundos para el agent y 600 segundos para el environment build, así que ningún agente debería superar los 3000 segundos. Pero en el enlace anterior, 2 de los 5 intentos superaron ampliamente los 3000 segundos y tardaron 75 y 80 minutos, respectivamente. Aunque hayan fallado, es sospechoso que se hayan ejecutado tanto tiempo. Es un caso de la ley de Goodhart en acción.
Hacer benchmarks de personas tampoco funciona bien. La capacidad de programar solo puede medirse de manera más o menos adecuada interactuando directamente. Si un modelo es, en la práctica, un simulador de personas, cuanto más precisa sea la simulación, más raro es esperar que los benchmarks sigan siendo útiles. Al final, esto no es más que una versión más larga de la “ley de Goodhart” mencionada arriba, y realmente funciona como una ley.
Entonces, ¿el argumento es que un modelo de punta no es ni siquiera un ingeniero junior, sino un pasante del primer mes sin capacidad de superar ese nivel?
Lo interesante es cómo los LLM superan el 70% en estos benchmarks o aciertan algunas preguntas pésimamente planteadas. ¿Aprendieron implícitamente el estilo de quienes escribieron las pruebas? ¿Se filtraron las soluciones en los datos de entrenamiento?
Aun así, es tranquilizador que incluso Fable se quede alrededor del 72% en un conjunto oculto sobre el que OpenAI no ejecutó este análisis. Parece que no entrenaron directamente sobre el benchmark en sí, salvo quizá de formas muy indirectas.
Los modelos abiertos pequeños nunca podrán aprender estas manías tan específicas, así que es realmente importante tener una buena forma de juzgar los modelos con justicia. Además, OpenAI está enturbiando un poco el panorama: solo alrededor del 20% de los problemas están rotos de una forma injusta para el agente, y entre el 4% y el 10% están rotos a su favor, así que el techo del benchmark probablemente esté más cerca del 80–85%.
Por eso, los prompts de tareas muy estrechos son fáciles de verificar, pero probablemente demasiado simples como desafío. En cambio, los prompts de tareas más realistas son mucho más difíciles de verificar, y también se vuelve difícil construir verificadores robustos y ejecutarlos barato.
Claro que el benchmark termina probando algo distinto de lo que afirma, pero a veces también prueba accidentalmente algo más cercano a la realidad que un benchmark prolijo, así que eso tiene su valor.
Pero esto solo vale cuando el agente puede ver las pruebas fallidas e iterar. Si no, es simplemente un problema. Y cuando las pruebas incrustan detalles de implementación de una solución específica y exigen una estructura interna arbitraria, eso es aún peor. En la realidad, uno no se encuentra con esa situación.
Por un lado, en realidad es digno de elogio que hayan hecho ese trabajo. Por otro, es literalmente eso de “si entra basura, sale basura”. Es un poco vergonzoso que los autores originales no lo hayan verificado de verdad, y también que nadie downstream lo haya verificado. Además, al leer el artículo, el LLM sí encontró problemas, pero tendía a subestimar los problemas encontrados por un ingeniero de software profesional.
Los benchmarks, cuando uno mira por dentro, en general son bastante malos
Para dar contexto: estoy iterando en un agente supervisor para reemplazar varios procedimientos engorrosos que hacen falta al usar Codex/Claude Code, y recientemente lo probé con Terminal Bench 2.1.
Al principio me alegré, porque el supervisor basado en especificaciones superaba a Codex básico en varias tareas. Pero al mirar más de cerca, las tareas en sí tenían muchísimos problemas.
El punto central es que las instrucciones suelen ser ambiguas, mientras que los casos de prueba son demasiado específicos. Por ejemplo, en
configure-git-webserver, expresiones como “so that I can run” vuelven difuso el límite entre qué debe proporcionar el agente y qué debe eliminar. Un agente que piensa de más configura el servidor y luego, al considerar que si el usuario ejecuta el mismo comando habrá un conflicto, borra exactamente los archivos que verifica el validador.En
make-mips-interpreter, por la frase “I will check that you booted doom correctly”, el supervisor interpretó que el usuario no iba a verificar que Doom arrancara de forma independiente, sino el resultado del arranque hecho por el agente, y dejó el/tmp/frame.bmpgenerado. El validador termina si ya existe/tmp/frame.bmp, así que no puede iniciar Doom, y tampoco verifica si se genera uno nuevo durante el proceso de arranque[0].En
mcmc-sampling-stan, el agente supervisor muchas veces llegaba al valor correcto, pero en vez de emitir un decimal simple, imprimía los números específicos del dominio en notación científica. El validador parseaba mal el resultado y fallaba[1].Estas discrepancias son solo una parte, y por eso considero que Terminal Bench 2.1 ya está saturado, y que los resultados de GPT-5.6 y Mythos, 88.8% y 88% respectivamente, están casi en el límite superior esperable. El mayor problema es que la mayoría de los benchmarks son de ejecución única, y casi no prueban el conjunto modelo+arnés en trabajos iterativos largos, que es la principal forma en que los usuarios reales usan estas herramientas.
[0] https://github.com/harbor-framework/terminal-bench-2-1/issue...
[1] https://github.com/harbor-framework/terminal-bench-2-1/issue...
¿No sabía todo el mundo desde el principio que SWE-Bench completo tenía fallas? Incluso sus autores reconocieron sus limitaciones y pasaron a la siguiente etapa hace mucho.
Entiendo por qué puede ser un mal benchmark, pero si se trata de que pruebas demasiado estrictas impongan detalles de implementación específicos no explicitados en el prompt e invaliden envíos funcionalmente correctos; de que prompts insuficientes omitan requisitos que las pruebas ocultas imponen, pero que no se pueden inferir razonablemente; de que pruebas con baja cobertura verifiquen menos de lo pedido y permitan que pasen correcciones incompletas; y de que prompts engañosos lleven al modelo a un comportamiento incorrecto o entren en conflicto con los requisitos de las pruebas, entonces, si el objetivo es comparar modelos con ingenieros de software reales, es una situación bastante realista.
Es parecido a armar un examen de enfermería y luego marcar algunos problemas porque había que preguntarle al médico a cargo información adicional que no estaba en la historia clínica, o porque la familia del paciente no explicó lo suficiente los antecedentes de una abuela mayor. Puede que uno quiera un benchmark más riguroso, pero si OpenAI prometió modelos como sustitutos de trabajadores reales, esto no deja una buena imagen. Más bien debería querer probar justamente estas cosas.
Se lee como “hicimos todo el trabajo necesario para arreglar el benchmark y, al final, decidimos descartarlo”. ¿Hay alguna razón por la que los datos base sean tan valiosos que no se puedan parchear? Al final se propone un enfoque un poco más selectivo para generar benchmarks, pero siento que también es un camino bastante sólido parchear de manera justa pruebas sucias e incompletas tomadas de datos reales.
También habría estado bien que dijeran “la lista de instancias rotas está aquí” o “este es el subconjunto de SWE Bench Pro que usaremos en adelante”. Están dejando que lo perfecto sea enemigo de lo bueno.
Aunque, cuando OpenAI lanzó SWE-Bench Verified, hizo exactamente algo así, así que quizás estoy diciendo tonterías.
¿Qué deberíamos considerar ahora como el estado del arte en benchmarks de SWE?
Desde hace bastante, tanto en mi opinión como en mis evaluaciones personales, pienso que aunque el techo potencial de un modelo sea más alto, su valor es limitado si no me siento realmente seguro de dar mi aprobación a ese código.
[0] https://deepswe.datacurve.ai/
[1] https://cognition.com/blog/frontier-code-1.1
[0]: https://deepswe.datacurve.ai/
Existe https://cognition.ai/blog/frontier-code. Para dejarlo claro, estuve en ese equipo, pero ahí también abordamos problemas de swebench pro/deepswe
Alcanzar la AGI debería ser más que pasar todos los benchmarks, y también debería considerar problemas desconocidos
Las únicas soluciones son a) hacer que los LLM sean más pequeños con un rendimiento similar para que no puedan memorizar ni atacar los benchmarks, o b) crear un benchmark que abarque todos los datos del mundo real, pero esto último es inviable