Presentamos SWE-bench Verified

Updated February 24, 2025

As part of our Preparedness Framework⁠, OpenAI develops a range of metrics to track, evaluate, and forecast models’ abilities to act autonomously. The ability to autonomously complete software engineering tasks is a key component of our Medium risk level in the Model Autonomy risk category. Evaluating these capabilities is challenging due to the complexity of software engineering tasks, the difficulty of accurately assessing generated code, and the challenge of simulating real-world development scenarios. Therefore, our approach to Preparedness must also involve careful examination of evaluations themselves, to reduce the potential for underestimating or overestimating performance in important risk categories.

One of the most popular evaluation suites for software engineering is SWE-bench⁠(se abre en una ventana nueva)¹—a benchmark for evaluating large language models’ (LLMs’) abilities to solve real-world software issues sourced from GitHub. The benchmark involves giving agents a code repository and issue description, and challenging them to generate a patch that resolves the problem described by the issue. Coding agents have made impressive progress on SWE-bench, with top scoring agents scoring 20% on SWE-bench and 43% on SWE-bench Lite according to the SWE-bench leaderboard⁠(se abre en una ventana nueva) as of August 5, 2024.

Our testing identified some SWE-bench tasks which may be hard or impossible to solve, leading to SWE-bench systematically underestimating models’ autonomous software engineering capabilities. We’ve collaborated with the authors of SWE-bench to address those issues in a new release of the benchmark that should provide more accurate evaluations.

Cada muestra del conjunto de pruebas de SWE-bench se crea a partir de un problema de GitHub resuelto en uno de los 12 repositorios de código abierto de Python. Cada muestra tiene un pull request (PR) asociado, que incluye tanto el código de la solución como pruebas unitarias para verificar la corrección del código. Estas pruebas unitarias fallan antes de que se añada el código de la solución en el PR, pero después son aptas, por lo que se denominan pruebas FAIL_TO_PASS. Cada muestra también tiene asociadas pruebas PASS_TO_PASS, que son aptas tanto antes como después de que se fusione el PR, y se utilizan para comprobar que el PR no ha roto la funcionalidad previa no relacionada en la base de código. 

Para cada muestra de SWE-bench, se proporciona a los agentes el texto original del problema de GitHub, conocido como enunciado del problema, y acceso a la base del código. A continuación, los agentes deben editar los archivos en la base del código para resolver la incidencia. Las pruebas no se muestran al agente.

La edición propuesta se evalúa ejecutando pruebas FAIL_TO_PASS y PASS_TO_PASS. Si las pruebas FAIL_TO_PASS son aptas, significa que la edición resuelve el problema. Si las pruebas PASS_TO_PASS son aptas, significa que la edición no ha roto accidentalmente secciones no relacionadas de la base de código. Es necesario que ambas pruebas sean aptas para que la edición resuelva totalmente el problema original de GitHub.

Debido a la relevancia que SWE-bench podría tener en el marco de preparación, nos propusimos encontrar formas de mejorar la solidez y fiabilidad de la prueba comparativa. Identificamos tres grandes áreas de mejora²: 

1. Las pruebas unitarias utilizadas para evaluar la corrección de una solución suelen ser demasiado específicas y, en algunos casos, no están relacionadas con el problema. Esto puede provocar que se rechacen soluciones correctas. 
2. La descripción del problema de muchas muestras es poco específica, lo que se traduce en ambigüedad sobre en qué consiste el problema y cómo debe resolverse.
3. En ocasiones es complicado configurar de forma fiable los entornos de desarrollo de SWE-bench para los agentes, por lo que las pruebas unitarias fallan independientemente de la solución. En tales casos, es posible que se califiquen como incorrectas soluciones que son válidas.

He aquí un ejemplo de la primera de estas dificultades.

La muestra de SWE-bench scikit-learn__scikit-learn-14520 asigna a un agente la tarea de resolver un problema en el repositorio scikit-learn⁠(se abre en una ventana nueva). El enunciado del problema indica que el argumento copy de una función podría ser especificado por un usuario, pero la biblioteca lo ignora (en su lugar, el comportamiento está codificado dentro de la función):

Un agente que intentara solucionar el problema anterior tendría que abordar primero la ambigüedad de si el comportamiento de la función es intencionado o un fallo, y luego hacer cambios en la base de código para resolver el problema. Según la configuración de SWE-bench, cualquier solución que proponga el agente deberá superar la siguiente prueba, extraída del PR que resolvió originalmente el problema⁠(se abre en una ventana nueva):

Esta prueba comprueba explícitamente que la solución emita un DeprecationWarning siempre que se utilice el parámetro copy, aunque el enunciado original del problema en el texto de la incidencia previamente descrita no incluya este requisito. Además, incluso si el agente se diera cuenta de que se debe emitir un DeprecationWarning, la prueba también requiere que el agente coincida exactamente con el mensaje de obsolescencia, al que se llegó tras una iteración en el PR a la que el agente no tiene acceso.

El agente solo recibe la descripción del problema del texto principal de la incidencia, y no tiene visibilidad sobre las pruebas que debe superar. Debido a esta configuración, sería casi imposible que un agente resolviera esta muestra en SWE-bench.

To address these issues, we launched a human annotation campaign with professional software developers to screen each sample of the SWE-bench test set for appropriately scoped unit tests and well-specified issue descriptions.

Together with the authors of SWE-bench, we are releasing SWE-bench Verified: a subset of the original test set from SWE-bench, consisting of 500 samples verified to be non-problematic by our human annotators. This version supersedes the original SWE-bench and SWE-bench Lite test sets. Additionally, we are releasing our human annotations for all SWE-bench test samples. These annotations enable slicing the dataset by difficulty. The 'easy' subset is composed of 196 <15-minute fix tasks, while the 'hard' subset is composed of 45 >1-hour tasks.

We also collaborated with the SWE-bench authors to develop a new evaluation harness for SWE-bench⁠(se abre en una ventana nueva) which uses containerized Docker environments to make evaluating on SWE-bench easier and more reliable.

On SWE-bench Verified, GPT‑4o resolves 33.2% of samples³, with the best performing open-source scaffold, Agentless, doubling its previous score of 16% on SWE-bench.

Colaboramos con 93 desarrolladores de software con experiencia en Python para examinar manualmente la calidad de las muestras de SWE-bench. Anotamos 1699 muestras aleatorias del conjunto de pruebas de SWE-bench para crear SWE-bench Verified. El siguiente análisis se basa en dichas muestras.

Anotamos muestras para determinar:

• Si consideramos que la descripción del problema no es lo suficientemente específica y, por lo tanto, es injusto hacer pruebas con ella.
• Si las pruebas unitarias FAIL_TO_PASS descartan soluciones válidas.

Cada criterio de anotación cuenta con una etiqueta [0, 1, 2, 3] de menor a mayor gravedad. Las etiquetas 0 y 1 son leves, mientras que las etiquetas 2 y 3 son graves e indican que la muestra es inadecuada y debe descartarse. Para la anotación, decidimos utilizar cuatro categorías ordinales en lugar de una única etiqueta binaria (grave o no grave) para capturar más detalles.

Además, calificamos la dificultad de cada muestra haciendo que los anotadores estimen cuánto tardaría un desarrollador en elegir y aplicar la solución, siempre que la muestra no sea problemática. Por último, proporcionamos una opción de entrada libre para indicar cualquier otro problema significativo de la muestra (por ejemplo, si es fácil engañar a las pruebas unitarias FAIL_TO_PASS, se podría marcar como correcta una solución no válida).

En primer lugar, nuestro equipo de ingenieros etiquetó manualmente 50 muestras con un alto grado de confianza para utilizarlas en las pruebas de incorporación de anotadores. Para participar en la campaña de anotación, todos los candidatos tenían que aprobar una serie de pruebas. Proporcionamos a cada uno de ellos observaciones detalladas durante el proceso con el fin de entrenarlos mejor para la tarea.  Los anotadores no tenían por qué ser expertos en bases de código relevantes para SWE-bench, por lo que se les dio tiempo para que se familiarizaran con cada base de código con la que iban a trabajar.

Con el fin de asegurar la calidad del conjunto de datos, tres anotadores diferentes etiquetan cada muestra. Puesto que es fácil pasar por alto posibles problemas, que además pueden ser ambiguos, agrupamos las anotaciones de forma conservadora utilizando la etiqueta de mayor gravedad de los tres anotadores.

El texto completo de nuestra rúbrica de anotación está disponible aquí⁠(se abre en una ventana nueva).

Para construir SWE-bench Verified, eliminamos cualquier muestra del conjunto de pruebas original en la que el enunciado del problema o las pruebas unitarias FAIL_TO_PASS tuvieran una etiqueta agrupada de gravedad 2 o superior. También eliminamos todas las muestras en las que se identificaron problemas importantes. Dado nuestro método de agrupación, esto significa eliminar las muestras en las que uno de los tres anotadores señaló un problema. Este enfoque implica una mayor tasa de falsos positivos a la hora de eliminar las muestras, pero ayuda a aumentar nuestra confianza en la calidad de las que se utilizan en el conjunto final de datos. 

Incluimos todas las muestras posibles con dificultad 1-4 horas y >4 horas, y a continuación, muestreamos aleatoriamente el resto para llegar a las 500 muestras de SWE-bench Verified.

A continuación, presentamos los resultados de nuestras anotaciones:

Según las anotaciones, el 38,3 % de las muestras tenían enunciados de problemas poco específicos, mientras que en el 61,1 %, las pruebas unitarias podían marcar injustamente soluciones válidas como incorrectas. En resumen, en nuestro proceso de anotación se eliminó un 68,3 % de las muestras de SWE-bench por estar insuficientemente especificadas, porque las pruebas unitarias eran injustas o por otros problemas. Como hemos mencionado previamente, este proceso de filtrado puede parecer demasiado riguroso, pero nos permite tener una gran confianza en la viabilidad de las muestras no eliminadas.

A continuación, presentamos algunos ejemplos de muestras y sus anotaciones, seleccionados minuciosamente para ilustrar la diversidad de la calidad de las muestras:

Con nuestro nuevo conjunto de datos de SWE-bench Verified, probamos el rendimiento de GPT‑4o utilizando varios scaffolds de código abierto con un buen rendimiento en las tablas de clasificación originales de SWE-bench⁴.

Descubrimos que en SWE-bench Verified, GPT‑4o alcanzaba un rendimiento del 33,2 % en el scaffold de mejor rendimiento, lo que duplica su puntuación en SWE-bench original (16 %). En general, esto confirma nuestra sospecha inicial de que el conjunto de datos original de SWE-bench subestima las capacidades de los agentes. Cabe destacar que el salto de SWE-bench Lite a SWE-bench Verified no es muy significativo, puesto que SWE-bench Lite ya había sido sometido a un filtro para que resultara más sencillo⁠(se abre en una ventana nueva) que el conjunto de datos completo, aunque ese proceso no captaría completamente los mismos problemas que nuestro procedimiento de filtrado.

La mejora del rendimiento al evaluar SWE-bench Verified se podría explicar parcialmente cambiando la distribución a muestras más sencillas (como se indica en los análisis previos). Sin embargo, nuestra meta no es inflar las puntuaciones de las pruebas comparativas, sino asegurar que representan fielmente la capacidad del modelo en cualquier nivel de dificultad.

Analizamos esta cuestión trazando el rendimiento estratificado por dificultad. Si nuestro nuevo conjunto de datos se limitara a cambiar la distribución de la dificultad para incluir más muestras fáciles, el rendimiento estratificado dentro de cada categoría no cambiaría, como parece ocurrir al pasar de SWE-bench original a SWE-bench Lite. En cambio, al pasar a SWE-bench Verified, observamos que el rendimiento aumenta dentro de todas las categorías de dificultad, lo que corrobora el efecto previsto de eliminar las muestras imposibles de todas las categorías en lugar de eliminar las muestras difíciles. El efecto es más evidente en los dos grupos más fáciles, donde contamos con más muestras.

Utilizamos SWE-bench como una de varias evaluaciones de seguimiento del nivel de riesgo medio de la categoría de riesgo de autonomía de los modelos en nuestro marco de preparación. El seguimiento de los niveles de riesgo catastrófico mediante evaluaciones depende de que podamos confiar en sus resultados y de que conozcamos lo que implican las puntuaciones.

Nuestra experiencia indica que deberíamos:

Invertir en comprender mejor nuestras pruebas comparativas. Aunque SWE-bench fue diseñado cuidadosamente, subestima las capacidades del modelo debido a los problemas mencionados en esta publicación. A medida que nuestros sistemas se acercan a la inteligencia artificial general, debemos evaluarlos en tareas cada vez más exigentes. Esto también aumenta el nivel de experiencia y atención necesario para seleccionar y verificar las pruebas comparativas con el fin de asegurar que sean lo suficientemente complejas y robustas (por ejemplo, puede ser útil el trabajo de CriticGPT⁠, que explora formas en las que la IA puede ayudar con los pipelines de anotación).

Tener en cuenta los avances del ecosistema. Los avances comunitarios en el scaffolding de agentes ponen de manifiesto la necesidad de tener en cuenta las posibles mejoras externas de un modelo al evaluar el riesgo. Si observamos la diferencia entre los scaffolds con peor y mejor rendimiento de un modelo determinado en las tablas de clasificación de SWE-bench⁠(se abre en una ventana nueva), podemos ver que, por ejemplo, el rendimiento de GPT‑4 en SWE-bench Lite varía entre el 2,7 % si utilizamos un scaffold basado en la generación aumentada por recuperación (RAG) y el 28,3 % si utilizamos CodeR. Por lo tanto, el marco de preparación exige que las evaluaciones se realicen de forma continua y con la frecuencia necesaria para identificar cualquier cambio de capacidad no trivial, antes, durante e incluso después del entrenamiento, cuando los modelos pueden mejorarse mediante la integración con sistemas externos. Además, la selección de evaluaciones es un esfuerzo que abarca todo el ecosistema, por lo que esperamos seguir colaborando con investigadores para crear evaluaciones fiables y de alta calidad.

Conocer las limitaciones. Las evaluaciones basadas en conjuntos de datos estáticos son por sí mismas limitadas y SWE-bench no es la excepción. Puesto que la prueba comparativa se compone de extractos de repositorios públicos de GitHub, es probable que las tareas de los modelos fundacionales de grandes bases preentrenados con texto de Internet estén contaminadas. Además, SWE-bench solo cubre una pequeña distribución del nivel de riesgo medio para la autonomía de los modelos, por lo que debe complementarse con otras evaluaciones. 

Confiamos en un enfoque empírico y científico del seguimiento y la protección frente a los riesgos catastróficos. Construir y mejorar las evaluaciones de forma continua es un elemento clave de esta labor. Queda mucho por hacer y esperamos que la comunidad siga contribuyendo con valiosas pruebas comparativas como SWE-bench. 

Descárgate SWE-bench Verified en este enlace⁠(se abre en una ventana nueva) y encuentra el conjunto completo de nuestras anotaciones aquí⁠(se abre en una ventana nueva), además de nuestra rúbrica de anotaciones en este otro enlace⁠(se abre en una ventana nueva).