Por qué SWE-bench Verified ya no mide las capacidades de programación de vanguardia

Desde que publicamos por primera vez SWE-bench Verified en agosto de 2024, la industria lo ha utilizado ampliamente para medir el progreso de los modelos en tareas de ingeniería de software autónoma. Tras su lanzamiento, SWE-bench Verified proporcionó una señal sólida del progreso de las capacidades y se convirtió en una métrica estándar informada en los lanzamientos de modelos de vanguardia. El seguimiento y la previsión del progreso de estas capacidades también es una parte importante del Marco de preparación de OpenAI. Cuando creamos inicialmente la prueba de referencia de Verified, intentamos resolver problemas en la evaluación original que hacían que ciertas tareas fueran imposibles de realizar en el conjunto de datos de SWE-bench⁠(se abre en una nueva ventana).

Tras los avances iniciales, el progreso de vanguardia en SWE-bench Verified se ha ralentizado, con una mejora⁠(se abre en una nueva ventana) del 74,9 % al 80,9 % en los últimos 6 meses. Esto plantea la siguiente pregunta: ¿Los fallos restantes reflejan limitaciones del modelo o propiedades del propio conjunto de datos?

En un nuevo análisis, descubrimos dos problemas importantes con el conjunto Verified que indican que la prueba de referencia ya no es adecuada para medir el progreso en capacidades de ingeniería de software autónoma para lanzamientos de vanguardia en los niveles de rendimiento actuales:

1. Las pruebas rechazan soluciones correctas: Auditamos un subconjunto del 27,6 % del conjunto de datos que los modelos a menudo no lograban resolver y descubrimos que al menos el 59,4 % de los problemas auditados tienen casos de prueba defectuosos que rechazan envíos funcionalmente correctos, a pesar de nuestro máximo esfuerzo por mejorarlo en la creación inicial de SWE-bench Verified.
2. Entrenamiento sobre soluciones: Debido a que los modelos de vanguardia grandes pueden aprender información a partir de su entrenamiento, es importante que nunca se entrenen con los problemas y las soluciones con los que se evalúan. Esto es similar a compartir problemas y soluciones de un examen próximo con los estudiantes antes del examen: quizá no memoricen la respuesta, pero los estudiantes que ya han visto las respuestas sin duda lo harán mejor que quienes no. Los problemas de SWE-bench provienen de repositorios de código abierto que muchos proveedores de modelos utilizan con fines de entrenamiento. En nuestro análisis, descubrimos que todos los modelos de vanguardia que probamos pudieron reproducir la corrección de error original escrita por humanos utilizada como valor de referencia real, conocido como el parche de referencia, o los detalles textuales del planteamiento del problema para ciertas tareas, lo que indica que todos han visto al menos algunos de los problemas y soluciones durante el entrenamiento.

También encontramos evidencia de que los modelos que detectaron los problemas durante el entrenamiento tienen más probabilidades de tener éxito, porque cuentan con información adicional necesaria para superar las pruebas poco específicas.

Esto significa que las mejoras en SWE-bench Verified ya no reflejan mejoras significativas en las capacidades reales de desarrollo de software de los modelos. En cambio, cada vez reflejan más cuánto estuvo expuesto el modelo a la prueba de referencia durante el entrenamiento. Por eso hemos dejado de informar las puntuaciones de SWE-bench Verified y recomendamos que otros desarrolladores de modelos hagan lo mismo.

Estamos desarrollando evaluaciones nuevas sin contaminación para realizar un mejor seguimiento de las capacidades de programación y creemos que es un área importante en la que enfocarse para la comunidad de investigación en general. Hasta que lo logremos, OpenAI recomienda informar los resultados de SWE-bench Pro.

La evaluación original de SWE-bench⁠(se abre en una nueva ventana) se publicó en 2023. Cada problema proviene de uno resuelto de GitHub en uno de los 12 repositorios de Python de código abierto y se empareja con la pull request (PR) correspondiente. Para determinar si un cambio de código generado por un modelo es correcto, cada problema incluye dos conjuntos de pruebas:

• Pruebas que fallan en el código base sin modificar, pero se superan si el problema se corrige correctamente
• Pruebas de regresión que se superan tanto antes como después de la corrección para asegurar que la funcionalidad no relacionada se mantenga intacta.

El modelo no ve las pruebas. Tiene que producir un cambio de código dado solo el texto original del problema y el estado del repositorio antes de la corrección. Solo se aprueba un problema si se superan todas las pruebas después de aplicar el cambio de código.

Encontramos muchos problemas con esa evaluación que podrían llevar a subestimar la capacidad de los modelos.

• Algunas pruebas unitarias eran demasiado específicas o estaban desalineadas con la tarea, por lo que se podían rechazar correcciones correctas.
• Muchos planteos de tareas estaban poco especificados, lo que podría dar lugar a múltiples interpretaciones válidas, mientras que las pruebas solo cubrían una específica.
• Según la configuración del entorno (por ejemplo, Linux vs. Windows o la versión de Python), algunas pruebas podrían fallar de forma engañosa.

Creamos SWE-bench Verified en 2024 para abordar estos problemas. Trabajamos con ingenieros de software expertos para revisar 1699 problemas de SWE-bench y filtrar los problemas que tenían estos inconvenientes. Cada problema fue revisado de forma independiente por tres expertos. Este proceso de revisión dio como resultado SWE-bench Verified, un conjunto curado de 500 problemas.

Si bien SWE-bench Verified es una gran mejora con respecto a la versión inicial, persisten problemas residuales. Realizamos una auditoría de 138 problemas de SWE-bench Verified que OpenAI o3 no resolvió de manera consistente en 64 ejecuciones independientes. Cada caso fue revisado de forma independiente por al menos seis ingenieros de software experimentados. Si un experto señalaba un problema, un equipo adicional lo volvía a verificar.

Descubrimos que el 59,4 % de los 138 problemas contenían problemas materiales en el diseño de la prueba o la descripción del problema, lo que los hacía extremadamente difíciles o imposibles de resolver incluso para el modelo o humano más capaz.

• El 35,5 % de las tareas auditadas tienen casos de prueba estrictos que imponen detalles específicos de implementación, lo que invalida muchos envíos funcionalmente correctos, a los que llamamos casos de prueba estrechos.
• El 18,8 % de las tareas auditadas tienen pruebas que verifican una funcionalidad adicional que no se especificó en la descripción del problema, a lo que llamamos casos de prueba amplios.
• El 5,1 % restante de las tareas presentaba problemas diversos que no se combinaron bien con esta taxonomía.

Un ejemplo ilustrativo del primer modo de falla es pylint-dev__pylint-4551⁠(se abre en una nueva ventana), donde la PR introduce una nueva función `get_annotation` como parte de la solución general. Este nombre de función no se menciona en la descripción del problema, pero las pruebas lo importan directamente. Si bien algunos modelos podrían intuir crear una función de este tipo, no es estrictamente necesario implementar una función con este nombre específico para abordar correctamente el problema. Muchas soluciones válidas no superan las pruebas debido a errores de importación.

Un ejemplo de casos de prueba demasiado amplios es sympy__sympy-18199⁠(se abre en una nueva ventana). Esta tarea se originó a partir de una PR que abordó tres problemas distintos con la función `nthroot_mod`, específicamente #17373⁠(se abre en una nueva ventana), #17377⁠(se abre en una nueva ventana) y #18212⁠(se abre en una nueva ventana). Sin embargo, la descripción de la tarea SWE-bench Verified solo cubre el problema final #18212⁠(se abre en una nueva ventana). Esto crea una discrepancia: las pruebas de la PR cubren los tres problemas, mientras que la descripción detalla solo uno. En nuestras ejecuciones, los modelos a menudo implementan correctamente la corrección descrita y, luego, fallan las pruebas que cubren la implementación de los otros dos problemas.

SWE-bench Verified y los repositorios (bases de código y notas de la versión) son de código abierto, y se usan y se discuten ampliamente, lo que dificulta evitar la contaminación de los desarrolladores de modelos.

Primero encontramos señales de contaminación en nuestros propios modelos. Por ejemplo, cuando GPT‑5.2 resolvió 31 tareas que identificamos como casi imposibles de resolver. En django__django-14725⁠(se abre en una nueva ventana) las pruebas requieren un nuevo parámetro específico `edit_only` que no es explícitamente requerido por el planteo del problema. Mientras resolvía el problema, GPT‑5.2 muestra en su cadena de pensamiento que tiene información sobre las notas de la versión que detallan cambios en la base de código e identifica correctamente que el parámetro `edit_only` se introdujo en Django 4.1.

Para evaluar qué tan significativa es la contaminación de manera más amplia, creamos una configuración automatizada de red teaming. Para cada pregunta de SWE-bench Verified, le pedimos a GPT‑5 que analizara un GPT‑5.2‑Chat, Claude Opus 4.5 y Gemini 3 Flash Preview para detectar contaminación. Estos modelos se eligieron para excluir los modelos de razonamiento, pero reconocemos que probablemente exista una brecha de capacidad no trivial entre ellos.

Para analizar la contaminación, GPT‑5 recibió el ID de la tarea de SWE-bench Verified, la descripción, el parche de referencia y las pruebas de PR. A lo largo de 15 turnos, permitimos que GPT‑5 variara el prompt del sistema/desarrollador, el prompt del usuario, el prellenado del asistente y diferentes estrategias de obtención. Después de cada turno, un modelo juez etiquetó cuánta información novedosa específica de la tarea apareció y cada respuesta se etiquetó según la gravedad de la contaminación, de “ninguna” a “mucha”. Se permitió que GPT‑5 adaptara su estrategia en función de los turnos anteriores para recuperar de forma iterativa detalles específicos de la tarea. Para cada ejemplo de mucha contaminación, verificamos con otro juez que GPT‑5 no filtrara demasiada información al modelo objetivo. Por último, revisamos manualmente los ejemplos “de mucha contaminación” que conforman las transcripciones en esta publicación.

A continuación, se muestran ejemplos de gran contaminación en diferentes proveedores de modelos.

Dado un fragmento breve de la descripción de la tarea, GPT‑5.2 genera el parche exacto de referencia. En particular, conoce el nombre exacto de la clase y del método, así como la nueva condición de retorno anticipado `if username is None or password is None` que se introduce.

ID de la tarea: django__django-11451⁠(se abre en una nueva ventana)

Opus no solo puede recordar el cambio funcional exacto de 4 líneas que introdujo la PR, junto con el nombre de archivo y el método específicos que tocó, sino que también cita textualmente el comentario en línea que formaba parte de la diferencia. 

ID de la tarea: astropy__astropy-13236⁠(se abre en una nueva ventana)

Gemini 3 Flash, cuando no se le proporciona más información sobre la tarea además del ID, es capaz de reproducir textualmente detalles de la descripción de la tarea y del parche de referencia. Esto incluye la nueva fórmula de regex para la validación del nombre de usuario y los números de línea exactos del cambio.

ID de la tarea: django__django-11099⁠(se abre en una nueva ventana)

A partir de esta auditoría de SWE-bench Verified, observamos dos lecciones más amplias para el diseño de evaluaciones. Primero, las pruebas de referencia obtenidas de material disponible al público conllevan un riesgo de contaminación, donde la exposición a los datos de entrenamiento puede inflar silenciosamente las puntuaciones. Si se utilizan datos rastreados públicamente en la creación de una prueba de referencia, los desarrolladores de modelos deben realizar pruebas adicionales para detectar contaminación. Las pruebas de referencias, e incluso sus soluciones, publicadas públicamente pueden derivar en datos de entrenamiento. Se debe tener especial cuidado tanto en cómo se publican los conjuntos de datos (es decir, protegidos con contraseña) y en cómo se filtran los datos de entrenamiento (es decir, estricto cumplimiento de cadenas canario). 

En segundo lugar, la calificación automatizada correcta resulta complicada; los casos de prueba perfectos deberían verificar plenamente la funcionalidad correcta, siendo tanto agnósticos a detalles específicos e irrelevantes de la implementación como también robustos frente a soluciones de atajo. Estos problemas son inherentemente complejos y difíciles de resolver. Detectar estos problemas requirió múltiples campañas extensas de etiquetado humano. 

Hemos incorporado estos hallazgos en nuestras iniciativas recientes de evaluación. En los últimos meses hemos optado por informar resultados de la división pública de SWE-Bench Pro. Recomendamos que otros desarrolladores de modelos hagan lo mismo. SWE-bench Pro no es perfecto, pero empíricamente parece presentar menos problemas de contaminación. Nuestro proceso de detección de contaminación encontró algunos casos de contaminación, pero dichos casos fueron mucho menos frecuentes y menos graves que en SWE-bench Verified, y ningún modelo pudo producir un parche de referencia completo y literal.

Seguiremos invirtiendo en pruebas de referencia originales, de autoría privada, y pediremos ayuda a la industria y al mundo académico para que hagan lo mismo. En GDPVal⁠, las tareas son creadas de forma privada por expertos en la materia, lo que reduce el riesgo de exposición, y las soluciones se evalúan de manera integral por revisores capacitados. Este enfoque requiere muchos recursos, pero es cada vez más necesario para medir mejoras genuinas en las capacidades.