Resumen Técnico: Los Modelos de Fundación como Oráculos para la Detección de la Corrección de la Refactorización

1. Planteamiento del Problema

Las herramientas de refactorización automatizada en los Entornos de Desarrollo Integrados (IDE) son esenciales para mantener la calidad del código, pero siguen siendo imperfectas. A pesar de décadas de investigación, estas herramientas pueden introducir cambios de comportamiento no deseados o errores de compilación, socavando la confianza del desarrollador. Los mecanismos de detección tradicionales dependen de precondiciones diseñadas a mano, análisis estático y pruebas dinámicas (por ejemplo, SafeRefactor). Sin embargo, estos enfoques enfrentan limitaciones significativas:

• Adaptabilidad: Definir precondiciones sólidas y completas para la explosión combinatoria de constructos de lenguaje y casos de borde es un desafío.
• Mantenimiento: Implementar nuevos análisis para tipos de refactorización emergentes o características del lenguaje requiere un esfuerzo de ingeniería sustancial.
• Cobertura: Las suites de pruebas existentes suelen ser insuficientes para revelar desviaciones de comportamiento sutiles, y los análisis estáticos pueden pasar por alto interacciones complejas.

El artículo postula que los modelos de fundación (modelos de propósito general entrenados en datos amplios) pueden servir como componentes complementarios, de tipo oráculo, para detectar estos errores. A diferencia de los sistemas basados en reglas, los modelos de fundación pueden razonar a través de diversos escenarios sin entrenamiento específico para la tarea, identificando potencialmente cambios semánticos sutiles que las herramientas tradicionales pasan por alto.

2. Metodología

Los autores realizaron un estudio empírico evaluando la capacidad de los modelos de fundación para detectar errores de refactorización en programas Java.

2.1 Construcción del Conjunto de Datos

El estudio utilizó un conjunto de datos de 226 errores de refactorización del mundo real recolectados durante más de una década de tres de los principales IDEs de Java: IntelliJ-IDEA, Eclipse y NetBeans.

• Composición: El conjunto de datos incluye 185 errores de compilación (CE) y 41 cambios de comportamiento (BC).
• Alcance: Abarca 47 tipos de refactorización distintos, siendo los más frecuentes Move Method, Inline Method y Pull Up Method.
• Verdad de Referencia (Ground Truth): Los autores reconstruyeron programas Java ejecutables para cada reporte de error. Para las instancias de BC, generaron casos de prueba JUnit específicos que pasan en el programa original pero fallan en la versión refactorizada, proporcionando evidencia ejecutable de la desviación de comportamiento.

2.2 Configuración Experimental

• Modelos Evaluados:
  • Pesos Abiertos (Open-Weight): GPT-OSS-20B (ejecución local), Llama-3.2-3B, Phi-4-14B, Gemma-4-31B y Qwen-3.6-35B.
  • Propietarios: GPT-5.4, Gemini-3.1-Pro-Preview y Claude-4.6-Sonnet.
• Estrategia de Prompting: El estudio empleó prompting zero-shot sin ajuste fino (fine-tuning) específico para la tarea. Se pidió a los modelos que analizaran el código original (code1) y el código refactorizado (code2) para determinar si la transformación introdujo un error de compilación o un cambio de comportamiento.
• Requisitos de Salida: Se requirió que los modelos devolvieran un JSON estructurado que contuviera un veredicto (YES, NO - COMPILATION ERROR, o NO - BEHAVIOR CHANGE), una breve explicación y, si aplica, un test JUnit generado para probar la diferencia de comportamiento.
• Métricas de Evaluación:
  • Precisión (Accuracy): Precisión media y pass@k (éxito dentro de $k$ intentos).
  • Estabilidad: Dispersión de la precisión, Tasa de Acuerdo Total (tar@k) y precisión de consenso (cons@k).
  • Robustez: Se aplicó pruebas metamórficas para evaluar la estabilidad bajo perturbaciones que preservan el comportamiento (por ejemplo, añadir comentarios, campos no utilizados o imports) para medir la sensibilidad a la contaminación de datos o memorización.

2.3 Viabilidad en Proyectos Grandes

Un estudio de viabilidad secundario evaluó los modelos en 44 diffs de refactorización del mundo real de proyectos de código abierto grandes utilizando un prompt basado solo en el diff. En este entorno, los modelos carecían del contexto completo del proyecto y se les permitió devolver un veredicto UNKNOWN si el diff carecía de información suficiente.

3. Resultados Clave

3.1 Precisión de Detección

• Modelos Propietarios: Gemini-3.1-Pro-Preview logró la mayor precisión general (99.6%), clasificando correctamente 225 de 226 instancias. GPT-5.4 y Claude-4.6-Sonnet le siguieron con 93.8% y 94.7% de precisión, respectivamente.
• Modelos de Pesos Abiertos: Gemma-4-31B superó a otros modelos abiertos con un 96.5% de precisión, sobrepasando el rendimiento de primera ejecución de GPT-5.4. GPT-OSS-20B alcanzó un 80.5% de precisión.
• Tipos de Error:
  • Errores de Compilación (CE): Los modelos propietarios sobresalieron generalmente aquí. Gemini-3.1-Pro-Preview alcanzó un 100% de precisión en CE. GPT-OSS-20B tuvo más dificultades con CE (77.8%), clasificando erróneamente código no compilable como preservación de comportamiento o cambio de comportamiento.
  • Cambios de Comportamiento (BC): Todos los mejores modelos funcionaron bien (92.7%–97.6%). Un modo de falla común fue la incapacidad de generar un test JUnit válido que compilara exitosamente y expusiera la diferencia.

3.2 Estabilidad y Robustez

• Muestreo Repetido: Para GPT-OSS-20B, el muestreo repetido (hasta 5 intentos) aumentó la cobertura acumulada de 80.5% a 92.9%. GPT-5.4 mostró alta estabilidad, con ganancias marginales tras intentos repetidos (93.8% a 97.3%).
• Pruebas Metamórficas: Tanto GPT-OSS-20B como GPT-5.4 mostraron alta estabilidad bajo perturbaciones de código fuente que preservan el comportamiento (ej. añadir comentarios o variables no utilizadas), con cambios de precisión de menos del 1%. Sin embargo, los autores señalan que esto indica robustez ante perturbaciones específicas, no necesariamente inmunidad a la contaminación de datos.
• Sensibilidad de la Temperatura: GPT-OSS-20B mostró variaciones de sensibilidad según los ajustes de temperatura; temperaturas más bajas (0.1–0.5) favorecieron la detección de cambios de comportamiento, mientras que temperaturas más altas (0.8) favorecieron la detección de errores de compilación. La detección de cambios de comportamiento de GPT-5.4 cayó significamente bajo decodificación determinista ($T=0$).

3.3 Viabilidad en Proyectos Grandes

En la evaluación basada solo en el diff, el 40.9% de los casos fueron clasificados como UNKNOWN por GPT-5.4. Los autores atribuyen esto a la insuficiencia de contexto en el diff (por ejemplo, referencias faltantes a métodos movidos o campos en otras partes del código base), resaltando una limitación al usar modelos de fundación como oráculos independientes para proyectos a gran escala sin el contexto completo.

3.4 Comparación con Baselines Tradicionales

• SafeRefactor: Logró un 97.8% de precisión en el conjunto de datos, pero falló en 5 casos debido a incompatibilidades de versiones (la herramienta depende de Java 8, mientras que el conjunto de datos incluye características de Java más recientes).
• Modelos de Fundación: El modelo de fundación más fuerte (Gemini-3.1-Pro-Preview) igualó o superó ligeramente la precisión de SafeRefactor (99.6%) mientras manejaba de forma nativa las nuevas características de Java.
• Compromiso (Trade-off): Las herramientas tradicionales proporcionan evidencia determinista y ejecutable; los modelos de fundación proporcionan evaluaciones probabilísticas con explicaciones en lenguaje natural, pero carecen de garantías formales.

4. Contribuciones Clave

1. Evaluación Empírica: El primer estudio exhaustivo que evalúa los modelos de fundación como oráculos zero-shot para detectar errores de refactorización en escenarios reales de IDE.
2. Curación de Conjunto de Datos: La extensión y reconstrucción de un conjunto de datos de 226 errores de refactorización en artefactos ejecutables, incluyendo tests JUnit específicos para cambios de comportamiento.
3. Análisis de Robustez Metamórfica: Una evaluación de la estabilidad de los modelos bajo perturbaciones de código fuente que preservan el comportamiento para evaluar la robustez contra la posible fuga de datos.
4. Análisis de Costo y Latencia: Un análisis comparativo del costo monetario y el tiempo de ejecución de los modelos locales de pesos abiertos frente a los modelos propietarios basados en API, resaltando los compromisos para el despliegue.
5. Estudio de Viabilidad de Solo-Diff: Una investigación sobre las limitaciones de usar modelos de fundación para la validación de refactorizaciones en proyectos grandes donde el contexto completo no está disponible.

5. Significado y Reivindicaciones

El artículo sostiene que los modelos de fundación son herramientas complementarias prometedoras para la detección de la corrección de la refactorización, en lugar de reemplazos para las técnicas de verificación tradicionales.

• Rol Complementario: Los autores argumentan que los modelos de fundación pueden señalar transformaciones sospechosas y proporcionar razonamientos explicativos, ayudando a la inspección del desarrollador. Son particularmente útiles en escenarios donde las herramientas tradicionales son incompletas, costosas o difíciles de configurar para nuevas características del lenguaje.
• Adaptabilidad: A diferencia de los sistemas basados en reglas que requieren actualizaciones manuales para nuevos constructos del lenguaje, los modelos de fundación demostraron la capacidad de analizar refactorizaciones que involucran características más recientes de Java (ej. var, expresiones switch) sin entrenamiento específico.
• Limitaciones: El artículo concluye modestamente que los modelos de fundación no proporcionan garantías formales. Su efectividad depende del diseño del prompt, la disponibilidad del contexto y las configuraciones de decodificación. El estudio enfatiza que la supervisión humana sigue siendo crucial, especialmente cuando las explicaciones del modelo son plausibles pero insuficientemente fundamentadas.
• Dirección Futura: Los autores sugieren flujos de trabajo híbridos donde las herramientas deterministas manejen las comprobaciones de compilación y los modelos de fundación asistan en la evaluación de la equivalencia semántica y el triaje, particularmente en IDEs aumentados por IA.

El estudio no afirma que los modelos de fundación hayan resuelto el problema de la corrección de la refactorización; más bien, proporciona evidencia de que pueden servir como oráculos efectivos y de alta precisión que complementan las prácticas de ingeniería existentes.