Resumen Técnico: Evaluación de LLMs en la Adaptación de Fragmentos de Código Java mediante un Marco de Inyección de Mutaciones

Planteamiento del Problema

Los desarrolladores reutilizan con frecuencia código copiando fragmentos de repositorios existentes o fuentes en línea y adaptándolos para que se ajusten a nuevos contextos. Este proceso de adaptación implica cambios diversos como el renombrado de variables, el intercambio de APIs, la adición de manejo de errores y la modificación del flujo de control. En escenarios del mundo real, los desarrolladores no proporcionan instrucciones de edición paso a paso explícitas; esperan que las herramientas infieran los cambios necesarios basándose en el fragmento copiado y su contexto circundante.

Los benchmarks actuales para evaluar los Modelos de Lenguaje de Gran Tamaño (LLMs) en la adaptación de código sufren tres limitaciones principales:

1. Dependencia de Instrucciones Explícitas: Muchas evaluaciones existentes proporcionan guía de edición explícita, lo que impide probar la capacidad del modelo para inferir cambios de forma autónoma.
2. Alcance Estrecho: Los benchmarks suelen cubrir solo tipos de cambios específicos (por ejemplo, el cableado de variables) o funcionan exclusivamente a nivel de función, ignorando la granularidad más fina de los fragmentos de código (por ejemplo, cuerpos de bucles, ramas condicionales) donde suelen ocurrir las operaciones de copiar y pegar.
3. Falta de Verdad de Referencia Controlada: Las tareas derivadas de commits reales suelen entrelazar múltiples tipos de cambios, lo que dificulta aislar qué tipos de adaptación específicos causan los fallos del modelo.

En consecuencia, se desconoce qué tan bien pueden los LLMs realizar la adaptación sin instrucciones de fragmentos de código cuando los cambios requeridos son variados, controlados y presentados en diferentes niveles de complejidad y contexto.

Metodía

Los autores proponen un Marco de Inyección de Mutaciones para construir un conjunto de datos controlado y escalable para evaluar la adaptación de código sin instrucciones. La metodología procede de la siguiente manera:

1. Construcción del Conjunto de Datos

• Fuente: Repositorios de Java de código abierto maduros (mínimo 500 estrellas, 70% de cobertura de líneas vía JaCoCo, compilables con Maven) que abarcan al menos cinco dominios de aplicación distintos.
• Extracción de Fragmentos: Utilizando el framework Spoon, los autores extraen fragmentos de código sintácticamente completos y contiguos (3 a 20 sentencias) que están cubiertos por casos de prueba y contienen al menos dos identificadores que no sean palabras clave.
• Selección de Semillas: Los fragmentos sirven como "semillas de verdad de referencia" que representan el estado objetivo.

2. Inyección de Mutaciones (Adaptación Inversa)

En lugar de pedir a los modelos que adapten el código a un objetivo, el marco parte del objetivo (la semilla) y aplica operadores de adaptación en reversa para crear un fragmento mutado ($F'$).

• Taxonomía: Un conjunto curado de nueve operadores de mutación derivados de estudios empíricos del comportamiento de los desarrolladores (ej., Zhang et al., Roy et al.). Estos incluyen:
  • Nivel de Identificador: Renombrado de variables, actualizaciones de constantes, resolución de identificadores.
  • Nivel de Sentencia: Inserción de guardas, cambios de tipo, ediciones de try/catch.
  • Estructural/Semántico: Modificación del flujo de control, sustitución de API, personalización de la lógica.
• Validación: Las mutaciones se validan para asegurar que el código resultante compile y, crucialmente, falle al menos un caso de prueba existente en el repositorio. Esto asegura que la mutación introduzca un defecto semántico que el LLM deba corregir.
• Niveles de Complejidad: Las tareas se categorizan por complejidad ($L1$ a $L4$) basada en el número y la combinación de mutaciones inyectadas.

3. Formulación de la Tarea

Se presenta al LLM el fragmento mutado ($F'$) y un prompt que le instruye a "adaptar el fragmento para que se ajuste al contexto circundante". No se proporcionan listas de edición explícitas ni guía paso a paso.

• Granularidad del Contexto: El estudio evalúa tres niveles de contexto:
  • C1: Sin contexto (solo el fragmento).
  • C2: Contexto de método (cuerpo del método envolvente).
  • C3: Contexto de archivo (archivo fuente completo).

4. Métricas de Evaluación

• Corrección Funcional: La salida del LLM se reinserciona en la ubicación original del código base y se ejecuta la suite de pruebas del repositorio. El éxito se mide mediante pass@1 y pass@5 (donde cualquiera de las 5 salidas generadas pasa).
• Corrección a Nivel de Adaptación: Una inspección detallada verifica si las mutaciones inyectadas fueron revertidas correctamente, utilizando metadatos JSON registrados durante la inyección.
• Análisis Estadístico: Se utiliza regresión logística de efectos mixtos para analizar las interacciones entre el modelo, el tipo de adaptación, el contexto y la complejidad.

Contribuciones Clave

1. Paradigma de Evaluación sin Instrucciones: El estudio desplaza el enfoque de la guía de edición explícita hacia la inferencia autónoma, reflejando mejor los escenarios de reutilización de código del mundo real.
2. Granularidad a Nivel de Fragmento: A diferencia de los benchmarks a nivel de función, este marco apunta a unidades sub-método (bucles, condicionales), alineándose con la forma en que los desarrolladores realmente copian y pegan código en los IDEs.
3. Verdad de Referencia Controlada mediante Inyección de Mutaciones: Al aplicar los operadores en reversa, los autores saben exactamente qué cambios son necesarios. Esto permite la atribución precisa de los fallos del modelo a tipos de adaptación específicos, una capacidad que carecen los benchmarks construidos a partir de commits reales entrelazados.
4. Marco Escalable y Reutilizable: La taxonomía se operacionaliza como operadores de mutación programables, permitiendo a futuros investigadores evaluar nuevas herramientas a escala sin anotación manual.

Preguntas de Investigación

El estudio se estructura en torno a tres preguntas exploratorias:

• RQ1 (Dificultad del Tipo de Adaptación): ¿Qué categorías de adaptación son las más difíciles de realizar para los LLMs sin instrucciones explícitas?
• RQ2 (Complejidad de la Adaptación): ¿Cómo escala el rendimiento con el número y la combinación de cambios inyectados? ¿La combinación de cambios fáciles crea una dificultad emergente?
• RQ3 (Granularidad del Contexto): ¿Cuánto contexto circundante se requiere para una adaptación exitosa, y varía este requisito según el tipo de adaptación?

Significado y Reivindicaciones

El artículo se posiciona como un Reporte Registrado, enfatizando el rigor de su diseño experimental y la naturaleza pre-registrada de su plan de análisis.

• Abordar la Brecha: Los autores afirman que los benchmarks existentes no logran ofrecer simultáneamente tareas sin instrucciones, granularidad a nivel de fragmento, tipos de cambio controlados y escalabilidad. Su marco está diseñado para llenar este vacío combinado.
• Impacto Práctico: Los resultados pretenden guiar el desarrollo de futuras herramientas de reutilización de código y plugins de IDE al identificar tipos específicos de adaptación donde los LLMs actuales tienen dificultades y determinar las ventanas de contexto óptimas para diferentes tipos de cambio.
• Reproducibilidad: Los autores se comprometen a hacer públicos el conjunto de datos completo, el marco de mutación y los scripts de evaluación para apoyar la replicación y extensión.

El documento no pretende haber resuelto el problema de la adaptación de código, sino que propone un método sistemático para medir el estado actual de los LLMs en este dominio, proporcionando una línea base para mejoras futuras. Reconoce limitaciones, como la restricción a Java/Maven y la posible divergencia entre las mutaciones sintéticas y las adaptaciones naturales de los desarrolladores, señalando que el marco está diseñado para ser extensible a otros lenguajes y sistemas de construcción en trabajos futuros.