Resumen Técnico: MigrationBench

Declaración del Problema

Aunque los Modelos de Lenguaje Grande (LLM) han demostrado un éxito significativo en la generación de código y la resolución de problemas aislados, sus capacidades en la migración de código a nivel de repositorio siguen sin evaluarse adecuadamente. A diferencia de las tareas centradas en funciones o archivos individuales, la migración de código requiere un enfoque holístico para navegar problemas interconectados en toda una base de código, particularmente al actualizar sistemas heredados. Específicamente, existe una falta de conjuntos de datos de referencia (benchmarks) a gran escala y de alta calidad diseñados para evaluar la migración de repositorios de Java 8 a versiones modernas de Soporte a Largo Plazo (LTS) (Java 17 y 21). Los benchmarks existentes a menudo se centran en la generación de código, la traducción entre lenguajes o tareas de mantenimiento a pequeña escala, sin capturar la complejidad y la escala de los escenarios de migración del mundo real que involucran miles de líneas de código y árboles de dependencias complejos.

Metodología

1. Curación del Conjunto de Datos (MigrationBench)

Los autores introducen MigrationBench, el primer benchmark a gran escala para la migración de repositorios de Java. El proceso de curación implicó una tubería de filtrado rigurosa y multi-etapa aplicada a repositorios de GitHub:

• Filtrado Inicial: Los repositorios se filtraron por licencia (MIT/Apache 2.0), calidad (mínimo 3 estrellas) y herramienta de compilación (Maven).
• Verificación de Compatibilidad: El equipo identificó un "commit base" ($H_b$) para cada repositorio donde el código se compilaba exitosamente y pasaba las pruebas bajo Java 8. Esto implicó verificar las configuraciones de pom.xml, asegurando que no hubiera versiones de Java 8 codificadas de forma rígida incompatibles con el objetivo, y validando que las versiones mayores de las clases compiladas fueran 52 (Java 8).
• Deduplicación: Los repositorios se deduplicaron basándose en coincidencias exactas de hashes de archivos y contenido.
• Requisito de Pruebas: Los repositorios se dividieron en un conjunto de datos Completo (5,102 repositorios con pruebas unitarias) y un subconjunto UTG (4,814 repositorios sin pruebas). El conjunto de datos Completo sirve como el benchmark principal para la evaluación de la migración.
• Subconjunto Seleccionado: Se curó un subconjunto representativo de 300 repositorios (seleccionados) a partir del conjunto de datos Completo. Este subconjunto enfatiza repositorios más grandes y de múltiples módulos para reflejar mejor la diversidad y la intrincación de los desafíos de migración del mundo real.

2. Marco de Evaluación

Debido a la ausencia de repositorios objetivo de verdad fundamental (ground-truth), los autores proponen un marco de evaluación automatizado basado en la Equivalencia Funcional Aproximada (FE):

• Migración Mínima: Definida por cuatro criterios:
  1. Éxito de Compilación: mvn clean verify pasa bajo Java 17.
  2. Validación de Versión: Las clases compiladas tienen una versión mayor de 61 (Java 17).
  3. Invarianza del Método de Prueba: Los métodos de prueba (anotados con @Test) no se renombren, deshabiliten o eliminen (verificado mediante análisis de AST).
  4. Invarianza del Conteo de Pruebas: El número de casos de prueba no disminuye.
• Migración Máxima: Se basa en la migración mínima añadiendo un quinto criterio:
  5. Modernización de Dependencias: Todas las dependencias se actualizan a sus versiones mayores estables más recientes disponibles en Maven Central (a noviembre de 2024).

3. Marcos Agénticos

El artículo evalúa varios enfoques basados en agentes utilizando el marco de agente Strands y Claude-4.5-Sonnet:

• Línea Base (Agente Strands): Equipado con herramientas de shell y edición para migrar código y asegurar que mvn clean verify pase.
• Agente de Ingeniería de Prompts (PE): Augmentado con prompts del sistema que instruyen explícitamente al agente a actualizar todas las dependencias a sus versiones mayores más recientes.
• Agente RAG: Incorpora un enfoque de Generación Aumentada por Recuperación donde el agente consulta una base de conocimientos externa de dependencias para identificar las versiones más recientes correctas.
• Enfoque Híbrido: Combina el análisis estático de código (actualizando dependencias de manera determinista) con el agente LLM. La herramienta estática maneja las actualizaciones de versión, y el agente corrige los fallos de compilación resultantes y los problemas de compatibilidad.

Contribuciones Clave

1. Conjunto de Datos MigrationBench: La introducción del primer benchmark a gran escala para la migración de código a nivel de repositorio, que comprende 5,102 repositorios (Completo) y un subconjunto curado de 300 repositorios (Seleccionado).
2. Marco de Evaluación: Un marco automatizado y exhaustivo para evaluar el éxito de la migración a través de criterios mínimos y máximos, abordando la falta de verdad fundamental en las tareas de migración.
3. Soluciones Agénticas: La propuesta y evaluación de un flujo de trabajo agéntico para la migración de código, incluyendo un Enfoque Híbrido novedoso que combina el análisis estático con el razonamiento de LLM para mejorar la eficiencia.
4. Recursos Abiertos: La liberación del conjunto de datos, el código fuente de evaluación y las trayectorias detalladas de los agentes (incluyendo decisiones intermedias y modos de fallo) para apoyar la reproducibilidad y la investigación futura.

Resultados Experimentales

Los experimentos se realizaron en el subconjunto seleccionado (300 repositorios) utilizando el marco de agente Strands con Claude-4.5-Sonnet.

• Migración Mínima: El agente Strands de línea base logró una tasa de éxito del 71.67% (pass@1) para la migración mínima.
• Migración Máxima:
  • El agente de línea base logró solo un 15.33% de éxito.
  • Añadir Ingeniería de Prompts (PE) aumentó la eficacia al 45.67%.
  • Incorporar RAG mejoró aún más la eficacia al 53.33%.
  • El Enfoque Híbrido igualó la eficacia del agente RAG del 53.33% mientras reducía el número promedio de llamadas a LLM por repositorio (52.55 vs. 59.22), demostrando una compensación favorable entre costo y eficiencia.
• Comparación de Modelos: Al aplicar el Enfoque Híbrido a otros modelos (DeepSeek-V3.1, Qwen3-Coder-480B, GLM-5), Claude-4.5-Sonnet permaneció como el más efectivo, aunque otros modelos mostraron diversos grados de éxito (por ejemplo, GLM-5 logró un 45.33%).
• Compilación vs. Verificación: Deshabilitar las pruebas unitarias (confiando solo en mvn clean compile) aumentó la eficacia de la migración mínima del 71.67% al 97.67%, destacando el papel crítico de los conjuntos de pruebas en la validación de la equivalencia funcional.

Significado y Afirmaciones

El artículo posiciona a MigrationBench como un recurso crítico para avanzar en la investigación en ingeniería de software y capacidades de LLM. Los autores afirman que:

• Brecha de Complejidad: Las tareas de migración presentan un nivel de dificultad significativamente mayor que la generación de código o la resolución de problemas aislados, requiriendo una comprensión holística del repositorio.
• Viabilidad: Los LLM, particularmente cuando se guían por flujos de trabajo agénticos y conocimiento externo (RAG) o análisis estático híbrido, pueden abordar eficazmente la migración a nivel de repositorio de Java 8 a Java 17.
• Estandarización: El marco de evaluación propuesto proporciona un método riguroso y estandarizado para evaluar el éxito de la migración, yendo más allá de las comprobaciones simples de compilación para incluir la modernización de dependencias y la preservación de pruebas.
• Dirección Futura: La liberación de las trayectorias de los agentes y el subconjunto UTG abre nuevas vías para estudiar las limitaciones de los agentes, los modos de fallo y la generación de pruebas unitarias para código heredado.

Los autores reconocen limitaciones, incluida la dependencia de la cobertura de pruebas existente (que puede no garantizar la equivalencia funcional completa para el código no probado) y posibles problemas de reproducibilidad debido a la limitación de velocidad (throttling) de Maven Central durante la recopilación de datos a gran escala. Sin embargo, sostienen que MigrationBench ofrece una base robusta para la evaluación sistemática y reproducible de los métodos de migración de código.