What's in a Benchmark? The Case of SWE-Bench in Automated Program Repair

Resumen Técnico: ¿Qué hay en un Benchmark? El caso de SWE-Bench en la Reparación Automática de Programas

Declaración del Problema
El campo de la Reparación Automática de Programas (APR, por sus siglas en inglés) ha evolucionado rápidamente con la integración de Grandes Modelos de Lenguaje (LLMs) y sistemas basados en agentes. Si bien los benchmarks como Defects4J han servido históricamente como terrenos comunes para la evaluación, SWE-Bench ha emergido como un benchmark dominante diseñado para reflejar escenarios del mundo real mediante la minería de problemas de repositorios Python populares sin casos de prueba preexistentes para la validación. A pesar de su rápida adopción y la existencia de tablas de clasificación públicas (SWE-Bench Lite y SWE-Bench Verified), ha habido una falta de análisis sistemático sobre el ecosistema que rodea a estos benchmarks. Específicamente, la dinámica de quién está enviando soluciones, la naturaleza de los productos y los modelos empleados, y la apertura de estos enfoques, permanecen insuficientemente investigadas. Este artículo aborda la necesidad de comprender la composición del ecosistema de SWE-Bench para guiar la investigación futura hacia una mayor transparencia y diversidad.

Metodología
Los autores realizaron el primer estudio exhaustivo de las tablas de clasificación de SWE-Bench Lite y SWE-Bench Verified. El estudio analizó un total de 212 entradas: 79 de la tabla Lite y 133 de la tabla Verified.

• Recopilación de Datos: Los investigadores inspeccionaron manualmente cada entrada de la tabla de clasificación, recuperando metadatos de los pull requests de envío, sitios web asociados y archivos del repositorio (por ejemplo, README.md, metadata.yaml). Complementaron esto con búsquedas dirigidas en Google (usando el nombre de la entrada + "SWE-Bench") y el examen de perfiles de LinkedIn para identificar las afiliaciones de los remitentes y los detalles del producto.
• Criterios de Exclusión: Las tablas "Full" y "Multimodal" fueron excluidas porque las soluciones en "Full" ya están representadas en las otras tablas, y el estudio se centró estrictamente en agentes basados en lenguaje.
• Anotación: Utilizando una combinación de codificación deductiva e inductiva, los autores categorizaron los datos a través de cinco dimensiones correspondientes a sus Preguntas de Investigación (RQs):
  1. Evolución: Seguimiento de los recuentos de envíos y la precisión (% Resuelto) a lo largo del tiempo.
  2. Perfil del Remitente: Clasificación de los remitentes como Academia, Industria (segmentada además por tamaño y estatus público), colaboraciones entre Academia e Industria, Comunidad de Código Abierto, Desarrolladores Individuales o Desconocido.
  3. Productos y Disponibilidad: Categorización de los artefactos de software (por ejemplo, complementos de IDE, plataformas en la nube, herramientas de resolución de problemas) y sus modos de disponibilidad (Producto Disponible Públicamente, Bajo Solicitud, B2B, Solución No Comercial, No Disponible).
  4. Apertura: Distinción entre código de solución de código abierto y de código cerrado.
  5. LLMs Empleados: Identificación de los LLMs específicos utilizados, incluyendo combinaciones y si son propietarios o de código abierto.

Contribuciones Clave y Resultados

• RQ1 (Evolución): Los envíos han crecido de manera constante, con una actividad que se ha desplazado significativamente hacia la tabla Verified desde su lanzamiento oficial en agosto de 2024. Mientras que los envíos a Lite se han ralentizado en 2025, Verified continúa creciendo. La tabla Verified demuestra una mayor precisión, con una mediana del 46.6% y un máximo del 76.8%, comparado con la mediana del 32% y el máximo del 60.3% de Lite. Esta diferencia se atribuye a la construcción de Verified, que filtra instancias consideradas demasiado difíciles o irresolubles.
• RQ2 (Perfil del Remitente): La mayoría de los envíos se originan en la industria (58% del total, aumentando a 79% al incluir colaboraciones). Las empresas pequeñas y las grandes corporaciones que cotizan en bolsa (por ejemplo, Amazon, IBM, Google, EPAM) son los contribuyentes más activos. Aunque las contribuciones académicas siguen siendo competitivas, constituyen una parte menor del total, particularmente en Verified. Los desarrolladores individuales y las comunidades de código abierto están presentes pero son menos dominantes en la tabla Verified.
• RQ3 (Productos y Disponibilidad): Las entradas están asociadas con diversas formas de producto, incluyendo Asistentes de Codificación (a menudo complementos de IDE), Plataformas de Desarrollo (basadas en la nube) y herramientas de Resolución de Problemas. Los Productos Disponibles Públicamente (PAP) y las Soluciones No Comerciales (NCS) son los modos de disponibilidad más comunes. Notablemente, las entradas asociadas con PAPs y soluciones "Bajo Solicitud" tienden a lograr una mayor precisión, lo que correlaciona con una mayor participación de la industria.
• RQ4 (Apertura): Existe una división clara en la apertura. La academia impulsa el ecosistema de código abierto; cuando las instituciones académicas están involucradas (solas o en colaboración), las soluciones son predominantemente de código abierto. En contraste, los envíos de la industria son mayoritariamente de código cerrado. Aunque las soluciones de código cerrado generalmente logran una mediana de precisión más alta, varios enfoques de código abierto han alcanzado un rendimiento de vanguardia, particularmente en 2025.
• RQ5 (LLMs): Los LLMs propietarios dominan los mejores resultados. La familia Claude (específicamente Claude 4 Sonnet) es el modelo más prevalente para lograr resultados de vanguardia en ambas tablas. El mejor resultado en Verified (76.8%) fue logrado usando Claude 4 Sonnet. Aunque se utilizan modelos de código abierto (por ejemplo, Qwen2.5, Llama), a menudo en combinación con modelos cerrados o ajustados (fine-tuned), generalmente producen una precisión menor cuando se usan exclusivamente. Las combinaciones de múltiples LLMs son comunes entre los mejores competidores.

Significancia e Implicaciones
El artículo argumenta que el ecosistema de SWE-Bench está caracterizado actualmente por una fuerte presencia de la industria y una dependencia de LLMs propietarios de alto costo para lograr un rendimiento superior. Los autores destacan varias implicaciones críticas:

• Para Investigadores: Existe un desalineamiento entre las comunidades de Ingeniería de Software (SE) y de IA con respecto a la validación de parches. Los investigadores de SE típicamente distinguen entre parches correctos y de sobreajuste (overfitting), mientras que muchos envíos enfocados en IA reportan solo resultados de paso de pruebas. El artículo hace un llamado a una mayor difusión de los riesgos de sobreajuste y fomenta la producción de artefactos de código abierto.
• Para Profesionales: Las puntuaciones de las tablas de clasificación deben interpretarse con cautela debido a los riesgos de sobreajuste de parches y contaminación de datos (memorización de datos de entrenamiento). El rendimiento en SWE-Bench puede no generalizarse a diversos escenarios del mundo real.
• Para Creadores de Benchmarks: Existe un compromiso entre transparencia y participación. Si bien los metadatos detallados mejoran la comprensión, los requisitos estrictos pueden desalentar la participación de la industria. Los autores sugieren equilibrar los requisitos de metadatos ligeros con la necesidad de trazabilidad. También hacen un llamado a mecanismos para rastrear versiones de benchmarks, manejar subconjuntos emergentes (por ejemplo, SWE-bench-Lite-S) y mitigar la contaminación de datos mediante una infraestructura evolutiva como SWE-bench-Live.
• Costo y Accesibilidad: La dependencia de APIs costosas basadas en la nube para obtener un rendimiento de primer nivel crea una barrera de entrada para investigadores académicos y entidades más pequeñas. El artículo sugiere que las evaluaciones futuras deben considerar las relaciones costo-rendimiento y fomentar el reporte de resultados de modelos de código abierto para proporcionar bases de comparación diversas.

En conclusión, el estudio proporciona una comprensión fundamental del estado actual de la investigación en APR tal como se refleja en SWE-Bench, revelando un panorama impulsado por la industria y modelos propietarios, al tiempo que identifica áreas específicas en las que la comunidad debe evolucionar para asegurar la robustez, la transparencia e inclusividad en la futura investigación impulsada por benchmarks.