SWE-bench (benchmark) (ES)

From Systems analysis wiki
Jump to navigation Jump to search

SWE-bench es un benchmark a gran escala (un conjunto de tareas de prueba) para evaluar las capacidades de los grandes modelos de lenguaje (LLM) en el campo del desarrollo y la depuración automatizados de software[1]. Fue desarrollado por un grupo de investigadores de la Universidad de Princeton y otras organizaciones, y presentado en la conferencia ICLR 2024[2]. SWE-bench se diferencia de los benchmarks de código tradicionales por el uso de tareas reales de la práctica del desarrollo: el conjunto de pruebas incluye 2294 tareas basadas en incidencias cerradas (issues) y sus correspondientes correcciones (pull requests) de 12 populares repositorios de Python de código abierto en GitHub[1][3]. Cada tarea contiene la descripción del problema (issue) y proporciona al modelo acceso al código fuente del proyecto correspondiente; el objetivo del modelo es generar los cambios mínimos en la base de código (un parche) que solucionen el problema indicado[1][3].

Metodología y particularidades de la evaluación

SWE-bench simula el proceso real de desarrollo de software. Para cada tarea, se presenta al modelo el texto de la incidencia original de GitHub (descripción del problema) y una instantánea del código del repositorio en la versión anterior a la aplicación de la corrección[4]. El modelo (o un agente basado en el modelo) debe analizar el código fuente, comprender la naturaleza del error o del cambio requerido y realizar las modificaciones en los archivos de código correspondientes para solucionar el problema[4][5]. La validación de la solución está automatizada: cada tarea está asociada a pruebas unitarias reales del pull request que cerró el problema. Entre ellas se encuentran tanto pruebas de «fallo a éxito» (fail-to-pass), que no pasan en el código original pero deben pasar después de aplicar la corrección correcta, como pruebas de regresión (pass-to-pass), que pasan desde el principio y deben seguir pasando después de realizar los cambios[3]. El parche propuesto por el modelo se aplica al código, y luego se ejecutan las pruebas correspondientes: si todas las pruebas de «fallo a éxito» comienzan a pasar y las pruebas de «éxito a éxito» no se rompen, la tarea se considera resuelta correctamente[3]. Este enfoque de evaluación permite verificar no solo la capacidad del modelo para generar código sintácticamente correcto, sino también su habilidad para resolver realmente la tarea planteada sin romper la funcionalidad existente. Además, el modelo debe operar con un contexto amplio (un repositorio de código completo), comprender las interrelaciones entre los componentes y coordinar cambios en varios archivos simultáneamente[1], todo lo cual es significativamente más complejo que las tareas típicas de escribir una función a partir de una descripción.

En las evaluaciones de SWE-bench, generalmente no participan solo los LLM por sí mismos, sino sistemas de agentes que envuelven al modelo con herramientas auxiliares (por ejemplo, para navegar por archivos, ejecutar código, usar un depurador, etc.)[4][6]. Dicho sistema imita el ciclo de desarrollo real: el modelo puede examinar archivos secuencialmente, ejecutar pruebas o scripts y mejorar la solución por etapas hasta alcanzar un resultado exitoso[4]. Es revelador que la eficacia en la resolución de tareas de SWE-bench depende en gran medida de la calidad de este «scaffolding» (infraestructura del agente): los mismos modelos base pueden mostrar resultados diferentes dependiendo de cómo se organice la interacción con el repositorio y las herramientas[4][7]. De este modo, SWE-bench sirve como una medida de las capacidades conjuntas del modelo y su estrategia de resolución de problemas, acercando la evaluación a las condiciones reales de trabajo de un desarrollador de IA autónomo[4][7].

Variantes del conjunto de tareas

Los autores de SWE-bench y la comunidad han presentado posteriormente varios conjuntos derivados para diferentes propósitos de evaluación:

  • SWE-bench Lite — una versión simplificada del benchmark que incluye ~300 tareas[8], seleccionadas para reducir la complejidad y los costos computacionales de las pruebas de modelos. Este subconjunto fue creado para la experimentación rápida con modelos y excluye las validaciones más laboriosas, manteniendo al mismo tiempo la representatividad de los problemas principales[7]. En esencia, Lite contiene tareas de corrección de errores más simples y cortas, y los resultados de los modelos en Lite suelen ser más altos que en el conjunto completo, debido a la exclusión de los casos más difíciles[7].
  • SWE-bench Verified — un subconjunto filtrado mediante verificación manual, presentado en agosto de 2024 en colaboración con OpenAI[7]. Los investigadores contaron con 93 desarrolladores profesionales para analizar cada tarea del benchmark original y excluyeron los casos en los que la descripción inicial del problema era demasiado ambigua o el comportamiento requerido por las pruebas no se derivaba claramente del enunciado de la tarea[7]. También se eliminaron las tareas que en la práctica eran imposibles de resolver debido a problemas con el entorno o pruebas incorrectas[7]. Como resultado, se formó un conjunto de 500 tareas que están garantizadas como resolubles y correctamente formuladas[7]. SWE-bench Verified tiene como objetivo proporcionar una evaluación más fiable de las capacidades de los modelos, eliminando los casos en los que incluso una solución correcta es rechazada debido a la inadecuación de las pruebas o de la tarea[7]. Este conjunto ha reemplazado a las muestras de prueba originales de SWE-bench (completa y Lite) como el principal punto de referencia para la comparación de modelos[7]. Además, junto con Verified, se publicaron evaluaciones de la dificultad de las tareas (por ejemplo, se destacaron tareas «fáciles», que un humano resuelve en <15 minutos, y «difíciles», que requieren >1 hora)[7], y también se lanzó un nuevo marco de herramientas basado en Docker para una ejecución de pruebas más estable y reproducible[7].
  • SWE-bench Multimodal — una extensión del benchmark, presentada en enero de 2025, que incluye tareas donde la descripción del problema contiene no solo texto, sino también elementos visuales (por ejemplo, imágenes de la interfaz, capturas de pantalla de errores, etc.)[8]. Este conjunto (517 tareas[8]) evalúa la capacidad de los modelos y agentes para comprender y utilizar información visual al resolver problemas de programación. La evaluación en el conjunto multimodal se organiza de manera similar, pero requiere que el modelo tenga capacidades multimodales (por ejemplo, reconocimiento de texto en imágenes). La parte de prueba de SWE-bench Multimodal se mantiene cerrada (oculta) para evitar el sobreajuste de las soluciones a respuestas conocidas; los desarrolladores pueden enviar soluciones a un leaderboard remoto para la evaluación de sus modelos en estas tareas[2].

Además de estas variaciones principales, en torno a SWE-bench se ha formado un ecosistema de herramientas: SWE-agent — un «agente» de software de código abierto que demuestra resultados de vanguardia en las tareas del benchmark[2]; SWE-smith — un framework para entrenar modelos de desarrolladores propios; SWE-REX — una herramienta para la extracción y procesamiento avanzados de información de repositorios, entre otros. Estos proyectos tienen como objetivo simplificar la reproducción de resultados e impulsar la investigación en el campo de los sistemas de programación autónomos.

Resultados y progreso de los modelos

Cuando apareció por primera vez, SWE-bench reveló una brecha significativa entre los LLM modernos y las habilidades de los programadores experimentados. Los autores informaron que incluso los modelos más potentes de principios de 2023 solo lograban resolver un porcentaje de un solo dígito de las tareas: por ejemplo, el modelo Claude 2 de la empresa Anthropic resolvía con éxito menos del 2% de las tareas del conjunto completo[1]. Un modelo entrenado específicamente por los autores del benchmark (basado en LLaMA, llamado SWE-Llama) y modelos propietarios como GPT-4 solo podían resolver principalmente los errores más simples[1]. Estas bajas métricas iniciales subrayaron la dificultad de SWE-bench y sirvieron de estímulo para el desarrollo de nuevos enfoques.

A lo largo de 2024, a medida que aparecieron modelos y esquemas de agentes más avanzados, los resultados mejoraron significativamente. Investigadores de Princeton presentaron el sistema SWE-agent, que combina GPT-4 con búsqueda de código, planificación y otras herramientas; alcanzó aproximadamente el 12,5% de tareas resueltas en el conjunto completo, estableciendo un nuevo punto de referencia para los modelos académicos[5]. A mediados de 2024, en el leaderboard oficial de SWE-bench, las mejores soluciones (incluidas las propietarias) alcanzaron alrededor del 20% de éxito en el benchmark completo y hasta el 43% en el conjunto simplificado Lite[7]. Este crecimiento está relacionado con la mejora de los modelos (por ejemplo, la aparición de GPT-4, Claude 2 y 3) y especialmente con el desarrollo del “scaffolding”, es decir, estrategias externas que permiten al modelo dividir eficazmente la tarea en pasos, leer documentación, ejecutar sesiones de depuración, etc.[7].

Tras la introducción a finales de 2024 del conjunto Verified (depurado de tareas incorrectas), el rendimiento medido aumentó aún más. El modelo GPT-4 (variante GPT-4o) mostró inmediatamente alrededor del 33% de soluciones exitosas en Verified, en comparación con el ~16% anterior en el conjunto original[7]. Los mejores frameworks de agentes de código abierto (por ejemplo, Agentless) duplicaron su resultado de ~16% a 32% en Verified[7]. Esto confirmó la suposición de que el benchmark original subestimaba los indicadores debido a la presencia de casos irresolubles[7]. Al mismo tiempo, la mejora de los resultados en Verified en comparación con Lite no es tan drástica (los mejores modelos ya alcanzaban ~43% en Lite), lo cual es lógico: Lite seleccionaba inicialmente ejemplos más fáciles, mientras que Verified eliminó los irrealizables pero mantuvo las tareas complejas[7]. Es importante destacar que el aumento de los indicadores al pasar a Verified se produjo en todas las categorías de dificultad de las tareas, y no solo por la eliminación de las más difíciles, es decir, el filtrado también eliminó casos ocultamente irrealizables entre tareas relativamente simples[7].

A principios de 2025, los sistemas de IA líderes ya demuestran una eficacia cercana a la humana en el conjunto de tareas verificado, aunque el techo del 100% todavía está lejos. En enero de 2025, la empresa Anthropic informó que su nuevo modelo Claude 3.5 Sonnet, junto con un agente mejorado, resolvió el 49% de las tareas de SWE-bench Verified[4], situándose temporalmente en el primer lugar. Grandes empresas tecnológicas y equipos independientes también participan activamente en competiciones no oficiales en este benchmark. Por ejemplo, el equipo de CodeStory desarrolló un enfoque multimodelo con búsqueda de variantes («Midwit Agent»), que alcanzó un récord del 62,2% de tareas resueltas en Verified (datos de principios de 2025)[5][9]. Se señaló que para lograr esto fue necesario aumentar significativamente los costos de recursos computacionales en la etapa de inferencia del modelo (el llamado escalado en tiempo de inferencia), ejecutando múltiples intentos de solución y seleccionando el mejor resultado[5]. A su vez, en materiales de OpenAI se mencionó un sistema experimental GPT-03 que, con suficiente escalado computacional, supuestamente logró superar el umbral del 70% en Verified (datos no oficiales)[5]. Sin embargo, no existe una verificación independiente de estos resultados, y un indicador tan alto sigue siendo más un objetivo para futuras investigaciones que un hito alcanzado.

Según un estudio de Microsoft Research (2025), incluso los modelos más recientes, equipados con herramientas de depuración, todavía no superan el umbral del 50% de correcciones de errores exitosas en SWE-bench Lite[6]. En esta prueba, el mejor rendimiento fue el de Claude 3.7 Sonnet con ~48,4% de tareas resueltas, mientras que un sistema basado en GPT-4 (OpenAI 01) resolvió alrededor del 30%, y un modelo más ligero, el 03-mini, solo el 22%[6]. Estos resultados subrayan que, a pesar del rápido progreso, la IA actual todavía está por debajo de los programadores experimentados: para un humano, resolver tales tareas (con comprensión del código) no presenta dificultades, mientras que un modelo a menudo no sabe cómo aplicar eficazmente las herramientas de depuración o sufre de una falta de datos de entrenamiento que reflejen el proceso multifacético de corrección de errores[6].

Limitaciones y perspectivas

SWE-bench se ha convertido en una plataforma estandarizada para evaluar agentes de código inteligentes; sin embargo, las investigaciones también han revelado varias de sus limitaciones. El principal problema es la cobertura de pruebas incompleta: el conjunto de pruebas de verificación para cada tarea se toma del pull request específico y, por lo general, incluye solo las pruebas unitarias que se modificaron durante la corrección del error[3]. Como demostró un análisis de un grupo de científicos de la Universidad de Zhejiang y la Universidad de Stuttgart (Wang et al. 2025), ignorar el resto de las pruebas del proyecto puede ocultar la incorrección de algunas soluciones[3]. La reevaluación de las soluciones con el conjunto completo de pruebas del repositorio reveló que, en promedio, el 7,8% de los parches marcados como exitosos en SWE-bench en realidad no pasan otras pruebas del proyecto[3]. Esto conduce a una sobreestimación de la métrica de «tareas resueltas» en aproximadamente 4-6 puntos porcentuales[3]. Un caso aún más sutil es cuando un parche generado pasa todas las pruebas originales pero no es equivalente a la solución del desarrollador y cambia el comportamiento del programa de una manera no esperada. Mediante la generación de casos de prueba adicionales (método PatchDiff), los investigadores encontraron que casi el 30% de las correcciones propuestas por la IA se comportan de manera diferente a los parches de referencia, y alrededor del 11% son inequívocamente erróneas, aunque no son detectadas por las pruebas existentes[3]. Por lo tanto, las capacidades reales de los modelos pueden estar sobrestimadas si solo se confía en la superación de un conjunto limitado de pruebas. Los creadores de SWE-bench reconocen esta vulnerabilidad y subrayan que el benchmark debe evolucionar con el tiempo: mejorar la cobertura de las pruebas, añadir verificaciones de la ausencia de efectos secundarios no deseados y ampliar la variedad de tipos de tareas[7]. El desarrollo de tales herramientas de evaluación es una parte importante de la preparación para la aparición de desarrolladores de IA cada vez más autónomos y potentes, y la experiencia con SWE-bench demuestra la necesidad de prestar una atención cuidadosa a la calidad de los benchmarks[7].

SWE-bench, aunque es solo un conjunto estático de tareas, no cubre absolutamente todos los aspectos de la programación, pero ya se ha convertido en un estándar de facto para el análisis comparativo de modelos de código[3]. Se utiliza en trabajos científicos para demostrar nuevos métodos y algoritmos, así como por grupos de investigación industriales para evaluar el potencial de los sistemas destinados a automatizar la programación[3]. El constante crecimiento de los resultados en SWE-bench durante 2023-2025 demuestra claramente la rápida mejora de las capacidades de los LLM para resolver problemas prácticos de desarrollo. Al mismo tiempo, sirve como barómetro de la dificultad: incluso acercándose al 50-60% de tareas resueltas, los modelos todavía están lejos de ser un reemplazo completo para un ser humano, especialmente en condiciones de información limitada y la necesidad de una comprensión sutil de los requisitos[4][7]. Sin embargo, el progreso no se detiene; gracias a iniciativas como SWE-bench, la comunidad ve claramente sus objetivos y limitaciones, y continúa avanzando hacia la creación de un desarrollador de IA completo, capaz de comprender y corregir de forma autónoma el código de software al nivel de un experto humano[4][7].

Enlaces externos

Bibliografía

  • Liang, P. et al. (2022). Holistic Evaluation of Language Models (HELM). arXiv:2211.09110.
  • Chang, Y. et al. (2023). A Survey on Evaluation of Large Language Models. arXiv:2307.03109.
  • Ni, S. et al. (2025). A Survey on Large Language Model Benchmarks. arXiv:2508.15361.
  • Biderman, S. et al. (2024). The Language Model Evaluation Harness (lm-eval): Guidance and Lessons Learned. arXiv:2405.14782.
  • Kiela, D. et al. (2021). Dynabench: Rethinking Benchmarking in NLP. arXiv:2104.14337.
  • Ma, Z. et al. (2021). Dynaboard: An Evaluation‑As‑A‑Service Platform for Holistic Next‑Generation Benchmarking. arXiv:2106.06052.
  • Goel, K. et al. (2021). Robustness Gym: Unifying the NLP Evaluation Landscape. arXiv:2101.04840.
  • Xu, C. et al. (2024). Benchmark Data Contamination of Large Language Models: A Survey. arXiv:2406.04244.
  • Liu, S. et al. (2025). A Comprehensive Survey on Safety Evaluation of LLMs. arXiv:2506.11094.
  • Chiang, W.-L. et al. (2024). Chatbot Arena: An Open Platform for Evaluating LLMs by Human Preference. arXiv:2403.04132.
  • Boubdir, M. et al. (2023). Elo Uncovered: Robustness and Best Practices in Language Model Evaluation. arXiv:2311.17295.
  • Huang, L. et al. (2023). A Survey on Hallucination in Large Language Models. arXiv:2311.05232.

Referencias

  1. 1.0 1.1 1.2 1.3 1.4 1.5 Jimenez, Carlos E. et al. «SWE-bench: Can Language Models Resolve Real-World GitHub Issues?». arXiv. [1]
  2. 2.0 2.1 2.2 «SWE-bench/SWE-bench». GitHub. [2]
  3. 3.00 3.01 3.02 3.03 3.04 3.05 3.06 3.07 3.08 3.09 3.10 Wang, Shuyang et al. «Are "Solved Issues" in SWE-bench Really Solved Correctly? An Empirical Study». arXiv. [3]
  4. 4.0 4.1 4.2 4.3 4.4 4.5 4.6 4.7 4.8 «Claude SWE-Bench Performance». Anthropic. [4]
  5. 5.0 5.1 5.2 5.3 5.4 Jain, Sulbha. «SWE Benchmark: LLM evaluation in Software Engineering Setting». Medium. [5]
  6. 6.0 6.1 6.2 6.3 Hatmaker, Taylor. «AI models still struggle to debug software, Microsoft study shows». TechCrunch. [6]
  7. 7.00 7.01 7.02 7.03 7.04 7.05 7.06 7.07 7.08 7.09 7.10 7.11 7.12 7.13 7.14 7.15 7.16 7.17 7.18 7.19 7.20 7.21 7.22 «Introducing SWE-bench Verified». OpenAI. [7]
  8. 8.0 8.1 8.2 «SWE-bench Leaderboard». [8]
  9. «SOTA on swebench-verified: relearning the bitter lesson». Hacker News (Y Combinator). [9]