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 nueva ventana)¹—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 nueva ventana) 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 creó desde un problema resuelto de GitHub, en uno de los 12 repositorios de código abierto de Phyton en GitHub. Cada muestra tiene una solicitud de extracción (pull request, PR) asociada, 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 la PR, pero se aprueban después, y por ende se llaman pruebasFAIL_TO_PASS. Cada muestra también tiene asociadas pruebasPASS_TO_PASS, que se aprueban antes y después de que la PR se integre, y se usan para verificar que la funcionalidad existente no relacionada en la base de código no haya sido interrumpida por la PR. 

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

Una de las ediciones propuestas se evalúa al ejecutar tanto las pruebas de FAIL_TO_PASS como PASS_TO_PASS. Si se superan las pruebas de FAIL_TO_PASS , significa que la edición resuelve el problema. Si se superan las pruebas de PASS_TO_PASS , entonces la edición no ha roto de forma involuntaria secciones no relacionadas de la base de código. Ambos conjuntos de pruebas deben aprobarse para que la edición resuelva completamente el problema original de GitHub.

Dada la enorme importancia de SWE-bench para el Marco de preparación, nos propusimos encontrar formas de mejorar la solidez y fiabilidad de la prueba de referencia. Identificamos tres áreas principales de mejora²: 

1. Las pruebas unitarias utilizadas para evaluar la corrección de una solución suelen ser excesivamente específicas y, en algunos casos, incluso no guardan relación con el problema. Esto puede hacer que se rechacen soluciones correctas. 
2. Muchas muestras tienen una descripción del problema que no se especifica, lo que genera ambigüedad sobre cuál es el problema y cómo debe resolverse.
3. A veces es difícil configurar de forma fiable los entornos de desarrollo de SWE-bench para los agentes, los que provoca de forma involuntaria que las pruebas unitarias fallen independientemente de la solución. En tales casos, soluciones perfectamente válidas podrían calificarse como incorrectas.

A continuación se incluye un ejemplo que muestra la primera de las problemáticas.

La muestra SWE-bench scikit-learn__scikit-learn-14520 encarga a un agente que resuelva un problema en el repositorio scikit-learn⁠(se abre en una nueva ventana). Este enunciado de problema señala que el argumento de copy de una función podría ser especificado por un usuario, pero es ignorado por la biblioteca (el comportamiento está codificado dentro de la función):

Un agente que pueda abordar el problema anterior tendría que tratar primero la ambigüedad de si el comportamiento de la función es intencionado o un error, 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 de la PR que resolvió el problema al inicio⁠(se abre en una nueva ventana):

Esta evaluación comprueba explícitamente que la solución debe emitir un mensaje de DeprecationWarning cada vez que el parámetro de copy se utilice, aunque el enunciado del problema original en el texto del problema anterior no transmite este requisito. Además, incluso si el agente se dio cuenta de que debe emitirse un DeprecationWarning, la prueba también requiere que el agente coincida exactamente con el mensaje de desaprobación, al que solo se llegó tras alguna discusión en la PR a la que el agente no tiene acceso.

Ten en cuenta que al agente solo se le proporciona la descripción del problema del texto principal de la solicitud, y no tiene visibilidad sobre las pruebas que debe superar. Dada esta configuración, sería casi imposible para un agente resolver 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 nueva ventana) 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.

Trabajamos con 93 desarrolladores de software con experiencia en Python para examinar manualmente la calidad de las muestras de SWE-bench. Señalamos 1699 muestras aleatorias del conjunto de pruebas de SWE-bench para desarrollar SWE-bench Verified. El siguiente análisis se basa en las 1699 muestras.

Señalamos las muestras para capturarlas:

• Si consideramos que la descripción del problema no está suficientemente especificada y, por lo tanto, es injusto realizar pruebas sobre ella.
• Si las pruebas unitariasFAIL_TO_PASS filtran las soluciones válidas.

Cada criterio de valoración tiene una etiqueta que va de [0, 1, 2, 3] en gravedad creciente. Las etiquetas 0 y 1 son menores, las 2 y 3 son graves e indican que la muestra es inadecuada de alguna forma y debería descartarse. Optamos por señalar cuatro categorías ordinales en lugar de una única etiqueta binaria de grave/no grave para capturar más detalles.

Además, calificamos la dificultad de cada muestra al solicitar a los anotadores que estimen el tiempo que tardaría un desarrollador en decidir y aplicar la solución, suponiendo que el ejemplo no sea problemático. Por último, proporcionamos una opción de entrada libre para señalar cualquier otro problema importante con la muestra (por ejemplo, si las pruebas unitarias FAIL_TO_PASS son fáciles de engañar, lo que podría llevar a marcar como correcta una solución no válida).

En primer lugar, nuestro equipo de ingenieros etiquetó a mano 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 posibles anotadores tuvieron que superar nuestras pruebas de incorporación. Durante la incorporación, proporcionamos comentarios detallados a cada anotador para capacitarlos mejor para la tarea.  No eran necesariamente expertos previos en las bases de código relevantes para SWE-bench, pero se les dio tiempo para familiarizarse con cada base de código con la que trabajaban.

Con el fin de garantizar un conjunto de datos de alta calidad, distintos anotadores etiquetan 3 veces cada muestra. Es fácil pasar por alto eventualmente problemas potenciales y los propios problemas pueden ser ambiguos, por lo que agrupamos las anotaciones de forma cuidadosa tomando la etiqueta de mayor gravedad entre los 3 anotadores.

Aquí⁠(se abre en una nueva ventana) puedes encontrar el texto completo de nuestra rúbrica de anotación.

Para desarrollar SWE-bench Verified, filtramos cualquier muestra del conjunto de pruebas originales donde ya sea el enunciado del problema o las pruebas unitarias FAIL_TO_PASS tuvieran una etiqueta de conjunto de gravedad igual o superior a 2. También filtramos todas las muestras que presentan otros problemas importantes. Dado el método de agrupación, esto equivale a filtrar las muestras en las que uno de los tres anotadores ha señalado un problema con la muestra. Este enfoque conlleva una mayor tasa de falsos positivos en la eliminación de muestras, pero ayuda a aumentar nuestra confianza en la calidad de las muestras para el conjunto de datos final. 

Incluimos tantas muestras con dificultad de 1 a 4 horas y >4 horas como sea posible y, a continuación, muestreamos aleatoriamente el resto para llegar a las 500 muestras que constituyen SWE-bench Verified.

A continuación se muestran los resultados de los anotadores:

Vemos que el 38,3 % de las muestras se marcaron por enunciados de problemas poco específicos y el 61,1 % por pruebas unitarias que pueden marcar injustamente soluciones válidas como incorrectas. En general, el proceso de anotación resultó en 68,3 % de muestras SWE-bench que se filtraron por falta de especificación, pruebas unitarias injustas u otros problemas. Como ya se ha comentado, es probable que este proceso de filtrado sea demasiado entusiasta, pero nos permite tener una gran confianza en la viabilidad de las muestras sin filtrar.

A continuación presentamos unas cuantas muestras y sus anotaciones , seleccionadas para ilustrar la diversidad de la calidad de las muestras:

Con nuestro nuevo conjunto de datos SWE-bench Verified, probamos el rendimiento de GPT‑4o con varias matrices de código abierto que obtuvieron buenos resultados en las tablas de clasificación originales de SWE-bench⁴.

Descubrimos que el rendimiento de GPT‑4o en la matriz de mejor rendimiento alcanza el 33,2 % en SWE-bench Verified, más del doble de su puntuación del 16 % en el SWE-bench original. En general, esto valida nuestra sospecha inicial de que el conjunto de datos original de SWE-bench subestima las capacidades de los agentes. Ten en cuenta que el salto de SWE-bench Lite a SWE-bench Verified no es tan significativo, porque SWE-bench Lite ya filtraba de forma que fuese más fácil⁠(se abre en una nueva ventana) que el conjunto de datos completo, aunque ese proceso no captaría totalmente los mismos problemas que nuestro procedimiento de filtrado.

El aumento del rendimiento cuando se evalúa en SWE-bench Verified puede explicarse en parte por el desplazamiento de la distribución hacia muestras más fáciles (como se muestra en análisis anteriores). Sin embargo, el objetivo no es inflar las puntuaciones de las pruebas de rendimiento, sino asegurarse de que estas representan fielmente la capacidad del modelo en cualquier nivel de dificultad.

Lo investigamos trazando el rendimiento estratificado por dificultad. Si nuestro nuevo conjunto de datos se limitara a cambiar la distribución de la dificultad para que contuviera más muestras fáciles, el rendimiento estratificado dentro de cada categoría no cambiaría, como parece ser el caso al pasar del SWE-bench original al SWE-bench Lite. En cambio, observamos que el rendimiento aumenta dentro de las categorías de dificultad individuales al pasar a SWE-bench Verified, lo que concuerda con 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 claro en los dos grupos de dificultad más fáciles, donde tenemos más muestras.

Utilizamos SWE-bench como una de las diversas evaluaciones de seguimiento del nivel de riesgo medio de la categoría de riesgo Autonomía del modelo en nuestro Marco de preparación. El análisis de los niveles de riesgo catastrófico mediante evaluaciones depende de que podamos confiar en los resultados de las evaluaciones y de que estemos ajustados sobre lo que implican las puntuaciones.

Nuestra experiencia sugiere que se debería:

Invertir en conocer a fondo nuestras pruebas de rendimiento. Aunque SWE-bench se diseñó cuidadosamente, subestima las capacidades del modelo debido a los problemas mencionados en esta entrada de blog. A medida que nuestros sistemas se acercan a la IAG, necesitamos evaluarlos en tareas cada vez más exigentes. Esto también eleva el nivel de pericia y cuidado necesarios para elaborar y verificar las pruebas de rendimiento, con el fin de garantizar que sean lo suficientemente exigentes y sólidas (un caso en el que trabajos como CriticGPT⁠, que explora formas en las cuales la IA puede ayudar en los procesos de anotación).

Contabilizar los avances en el ecosistema. Los avances comunitarios en la matriz de agentes ponen de relieve la necesidad de tener en cuenta las posibles mejoras externas de un modelo a la hora de evaluar el riesgo. Si se observa la diferencia entre las matrices con peor y mejor rendimiento para un modelo determinado en la tabla de clasificación de SWE-bench ⁠(se abre en una nueva ventana), se puede ver que, por ejemplo, el rendimiento de GPT‑4 en SWE-bench Lite varía entre el 2,7 % utilizando una primera matriz basada en RAG y un 28,3 % utilizando CodeR. Así pues, 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; lo que incluye antes, durante e incluso después del entrenamiento, cuando los modelos pueden mejorarse mediante la integración con sistemas externos. Además, la conservación de las evaluaciones es un esfuerzo de todo el ecosistema, y esperamos seguir colaborando con los investigadores en la creación de evaluaciones fiables y de alta calidad.

Ten en cuenta los límites. Las evaluaciones basadas en conjuntos de datos estáticos son inherentemente limitadas, y SWE-bench no es una excepción. Dado que la prueba de rendimiento se compone de extracciones de repositorios públicos de GitHub, es probable que los modelos de grandes bases entrenadas previamente en texto de Internet resulten contaminados en las tareas. Además, SWE-bench solo cubre una estrecha distribución del nivel de riesgo medio para la autonomía del modelo, por lo que debe complementarse con otras evaluaciones. 

Creemos en un enfoque empírico y científico del monitoreo y la protección frente a los riesgos catastróficos. Desarrollar y mejorar continuamente las evaluaciones es un elemento clave de este trabajo. Queda mucho por hacer, y estamos impacientes por ver más trabajo por parte de la comunidad a la hora de contribuir con valiosos puntos de referencia como SWE-bench. 

SWE-bench Verified puede descargarse aquí⁠(se abre en una nueva ventana). El conjunto completo de nuestras anotaciones está aquí⁠(se abre en una nueva ventana), y nuestra rúbrica de anotaciones está aquí⁠(se abre en una nueva ventana).