SWE-Refactor: A Repository-Level Benchmark for Real-World LLM-Based Code Refactoring

Resumen Técnico: SWE-Refactor

Declaración del Problema

Aunque los Modelos de Lenguaje de Gran Escala (LLMs) han demostrado una capacidad significativa en la generación de código, la refactorización de código presenta desafíos distintivos. La refactorización requiere ediciones precisas que preserven la semántica para mejorar la estructura del programa sin alterar su comportamiento. Esta tarea exige un razonamiento a nivel de repositorio, una comprensión de dependencias complejas y una verificación iterativa; capacidades que son difíciles de evaluar y que a menudo superan el alcance de los modelos actuales.

Los benchmarks existentes para la refactorización de código sufren de cuatro deficiencias críticas:

1. Cobertura de Escenarios Limitada: Se centran predominantemente en tipos de refactorización atómicos (transformaciones simples) en lugar de las refactorizaciones compuestas (múltiples transformaciones coordinadas) comunes en el desarrollo real.
2. Falta de Construcción Automatizada: Muchos benchmarks dependen de la curación manual o de verdades fundamentales (ground truth) generadas por LLMs, lo que introduce sesgos y problemas de escalabilidad.
3. Contexto Insuficiente a Nivel de Repositorio: Los conjuntos de datos existentes suelen carecer de la información estructural (por ejemplo, jerarquías de clases, relaciones de llamador/llamado) necesaria para una evaluación realista.
4. Datos Ruidosos: Muchos benchmarks incluyen commits "impuros" donde la refactorización se mezcla con correcciones de errores o adiciones de funciones, lo que dificulta aislar y evaluar las capacidades de refactorización del modelo.

Además, el campo sufre de una falta de diversidad en los lenguajes de programación, con la mayoría de los benchmarks recientes centrándose exclusivamente en Python, a pesar de que Java es un lenguaje dominante en los sistemas empresariales.

Metodología: SWE-Refactor

Para abordar estas brechas, los autores introducen SWE-Refactor, un benchmark a nivel de repositorio construido a partir de proyectos reales de Java. El benchmark se construye mediante un proceso automatizado de cuatro pasos:

1. Minería mediante Análisis Estático: Los autores aprovechan RefactoringMiner, una herramienta basada en AST, para extraer commits que contienen refactorizaciones de 18 proyectos de Java ampliamente utilizados.
2. Curación de Refactorizaciones Puras: Utilizando PurityChecker (una extensión de RefactoringMiner), el proceso filtra los cambios impuros (por ejemplo, correcciones de errores) para retener solo refactorizaciones "puras". Los autores verificaron manualmente una muestra aleatoria de 200 instancias para confirmar la fiabilidad de los detectores.
3. Enriquecimiento con Información Multinivel: Para soportar el razonamiento a nivel de repositorio, el proceso utiliza Eclipse JDT para extraer un contexto exhaustivo, incluyendo la estructura del proyecto, cuerpos de clases completos, llamadores/llamados de métodos y configuraciones de construcción.
4. Verificación: El proceso asegura la corrección funcional compilando el proyecto con la versión de JDK apropiada y ejecutando la suite de pruebas completa (usando JaCoCo) para verificar que la refactorización preserve el comportamiento.

Composición del Conjunto de Datos:

• Escala: 1,099 refactorizaciones escritas por desarrolladores que preservan el comportamiento.
• Fuentes: 18 proyectos de Java diversos.
• Tipos: Incluye 922 instancias atómicas y 177 instancias compuestas.
• Tipos de Refactorización: Cubre tres tipos atómicos (Extraer Método, Mover Método, Inline de Método) y tres tipos compuestos (Extraer y Mover, Mover e Inline, Mover y Renombrar).

Métricas de Evaluación:
El benchmark evalúa el rendimiento de los LLM en dos dimensiones:

1. Corrección Funcional: Medida por el éxito de la compilación, las tasas de paso de las pruebas y la Verificación de Refactorización Basada en AST (usando RefactoringMiner para asegurar que la transformación pretendida ocurrió sin efectos secundarios no deseados).
2. Similitud con el Humano: Medida mediante CodeBLEU para evaluar la similitud con la verdad fundamental escrita por el desarrollador.

Contribuciones Clave

1. Benchmark SWE-Refactor: Un nuevo conjunto de datos de alta calidad de 1,099 refactorizaciones puras de 18 proyectos de Java, que cubre tanto transformaciones atómicas como compuestas. Es el primero en proporcionar un contexto exhaustivo a nivel de repositorio y verificación automatizada para Java.
2. Proceso de Construcción Automatizado: Un proceso reproducible de cuatro pasos que extrae refactorizaciones del mundo real, filtra la pureza, enriquece los datos estructurales y verifica la corrección sin necesidad de anotación manual o verdad fundamental generada por LLM.
3. Evaluación Exhaustiva: Una evaluación extensa de 9 LLMs ampliamente utilizados (incluyendo GPT-4o-mini, DeepSeek-V3 y varias variantes de CodeLLaMa/Qwen) a través de diferentes tipos de refactorización y estrategias de prompting (Prompting Simple, RAG y flujos de trabajo Multi-Agente).

Resultados Experimentales

Los autores evaluaron 9 LLMs sobre las 1,099 instancias. Los hallazgos clave incluyen:

• Rendimiento General: Los modelos de propósito general superaron a los modelos de código de código abierto. DeepSeek-V3 logró la tasa de éxito más alta (41.58%), seguido de GPT-4o-mini (39.85%). Los modelos de código abierto como CodeLLaMa-7B lograron solo un 1.10% de éxito.
• Atómico vs. Compuesto: Los modelos funcionaron significativamente mejor en refactorizaciones atómicas (ediciones locales) que en refactorizaciones compuestas (transformaciones entre archivos y de múltiples pasos).
  • DeepSeek-V3 destacó en Extraer Método (301 éxitos).
  • GPT-4o-mini mostró una generalización más amplia en tareas entre archivos como Mover Método (92 éxitos).
  • Los modelos de código abierto tuvieron dificultades casi totales con los tipos compuestos.
• Impacto de Técnicas Avanzadas:
  • Flujos de Trabajo Multi-Agente: Un flujo de trabajo que utiliza un Agente Desarrollador y un Agente Revisor (usando GPT-4o-mini) logró el mayor éxito general (579 instancias), superando significativamente al prompting simple y a la Generación Aumentada por Recuperación (RAG), particularmente en refactorizaciones compuestas complejas.
  • Andamiaje Agéntico (OpenAI Codex): Incluso un agente potente (GPT-5.1-Codex) logró solo un 39.4% de éxito en instancias compuestas, comparado con el 82.6% en instancias atómicas, lo que resalta la dificultad persistente de las transformaciones de múltiples pasos y estrictamente limitadas.

Significancia y Reivindicaciones

El artículo posiciona a SWE-Refactor como una evolución necesaria en los benchmarks de ingeniería de software. Su significancia radica en:

• Realismo: Al utilizar commits escritos por desarrolladores de proyectos reales, evita los sesgos y las alucinaciones asociados con los benchmarks sintéticos o generados por LLM.
• Complejidad: Apunta explícitamente a la brecha entre las refactorizaciones atómicas y las compuestas, proporcionando una prueba rigurosa para las capacidades de razonamiento a nivel de repositorio.
• Diversidad de Lenguaje: Aborda el sesgo centrado en Python de la literatura actual al proporcionar un benchmark de Java robusto, reflejando los lenguajes utilizados en sistemas empresariales a gran escala.
• Fiabilidad: El proceso automatizado asegura que la verdad fundamental preserve el comportamiento y sea estructuralmente correcta, ofreciendo un estándar confiable para futuras investigaciones.

Los autores concluyen que, si bien los LLM muestran potencial en la generación de código, siguen enfrentando desafíos significativos en las tareas de refactorización compuestas y complejas, lo que sugiere que los marcos agénticos actuales aún no son confiables para el mantenimiento de software de múltiples pasos sin supervisión humana.