Exploring Generalizable Automated Program Repair with Large Language Models

Resumen Técnico: Reparación Automática de Programas (APR) con LLMs

1. El Problema

La Reparación Automática de Programas (APR) busca generar parches para corregir errores de software automáticamente. Aunque existen técnicas basadas en búsqueda, semántica y plantillas, el estado del arte actual enfrenta dos desafíos críticos:

• Falta de Generalización: Las técnicas existentes no logran generalizar bien más allá de los conjuntos de datos de referencia (benchmarks) específicos, fallando a menudo en entornos realistas.
• Dependencia de Suposiciones Irrealistas: La mayoría de las evaluaciones recientes basadas en Modelos de Lenguaje Grandes (LLM) asumen una localización de fallos (Fault Localization - FL) perfecta, lo cual no es viable en la práctica. Además, la mayoría de los estudios se centran en un solo lenguaje de programación o un solo modelo, limitando la comprensión de la capacidad de los LLMs para reparar código en múltiples lenguajes.

El objetivo de este trabajo es realizar una evaluación empírica exhaustiva para determinar la viabilidad de los LLMs actuales para realizar reparaciones generalizables a través de diferentes lenguajes, estrategias de prompt y niveles de complejidad, bajo condiciones realistas.

2. Metodología

Los autores diseñaron un estudio empírico sistemático que abarca múltiples dimensiones:

• Modelos Evaluados: Se compararon 13 LLMs de vanguardia, divididos en:
  • Cerrados (Propietarios): Claude 3.7 Sonnet, Claude 3.5 Haiku, Gemini 1.5 Pro, Gemini 2.0 Flash, OpenAI o3-mini, OpenAI GPT-4o.
  • Abiertos (Open Weights): Llama 3.3, CodeLlama (13B/70B), DeepSeek Coder 33B, DeepSeek R1 (distilado), Qwen 2.5 Coder 33B, CodeGemma 7B.
• Benchmarks y Lenguajes: Se utilizaron conjuntos de datos reales y reproducibles en cuatro lenguajes:
  • Java: Defects4J v3.0.
  • Python: BugsInPy.
  • JavaScript: BugsJS.
  • PHP: BugsPHP.
  • Criterio de selección: Solo se consideraron errores reproducibles y corregibles dentro de una sola función (single-function).
• Diseño de Prompts (Zero-shot): Se evaluaron cuatro configuraciones de entrada para evitar sesgos de optimización excesiva:
  1. Base: Solo el código defectuoso.
  2. Test: Código + información de casos de prueba fallidos y mensajes de error.
  3. Localización Perfecta (LL): Código + comentarios indicando la línea exacta del error.
  4. Localización Automatizada: Código + las 3 funciones más sospechosas identificadas por una herramienta de localización basada en espectro (FLACOCO).
• Métricas y Protocolo:
  • Se generaron 15 parches por error para mitigar la no determinística de los LLMs.
  • Métrica principal: Pass@k (probabilidad de que al menos $k$ parches pasen la suite de pruebas).
  • Criterio de corrección: Plausibilidad (paso de pruebas), ya que la verificación manual a escala es inviable.
  • Se utilizó la prueba de rangos con signo de Wilcoxon para validar la significancia estadística.

3. Contribuciones Clave

1. Evaluación Exhaustiva Multilingüe: La primera comparación sistemática de 13 modelos (abiertos y cerrados) en 4 lenguajes de programación distintos.
2. Análisis de la Localización de Fallos: Un estudio profundo sobre cómo la calidad de la localización (perfecta vs. automatizada) impacta la capacidad de reparación, demostrando que las suposiciones actuales son demasiado optimistas.
3. Estrategias de Combinación (Ensembles): Propuesta de combinar múltiples modelos para superar las limitaciones de un solo modelo en un lenguaje específico.
4. Recursos Abiertos: Publicación del código, configuraciones y resultados para fomentar la reproducibilidad y la investigación futura.

4. Resultados Principales

• Especialización por Lenguaje (RQ1): No existe un "mejor modelo" universal.

  • Diferentes LLMs obtienen los mejores resultados en diferentes lenguajes (ej. Claude 3.7 Sonnet en Java, DeepSeek R1 en PHP, Gemini 2.0 Flash en Python).
  • Hallazgo crítico: Los modelos tienen dificultades para generalizar entre lenguajes; un modelo que funciona bien en Java puede fallar estrepitosamente en Python.
  • Problema de Python: Se observó una tasa de errores de indentación muy alta en los parches generados para Python, lo que afectó negativamente la puntuación de muchos modelos, excepto a los de la familia Gemini.

• Impacto de la Información de Pruebas (RQ1):

  • Incluir información de los casos de prueba fallidos (mensajes de error y código de prueba) en el prompt aumentó drásticamente el rendimiento (hasta un +47% en Pass@1 en algunos casos).
  • La información de pruebas es una señal clave para todos los modelos, independientemente del lenguaje.

• Localización de Fallos (RQ2):

  • Localización Perfecta vs. Automatizada: Cuando se asume una localización perfecta (línea exacta), el rendimiento es alto. Sin embargo, al usar una herramienta de localización automatizada (que solo sugiere funciones sospechosas), la precisión cae drásticamente (-7% a -16%).
  • En muchos casos, la herramienta automática no identificó la función correcta, lo que llevó a que los LLMs intentaran reparar código irrelevante, fallando en la generación de parches plausibles.

• Complejidad del Parche (RQ3):

  • Los LLMs manejan sorprendentemente bien la complejidad creciente. Aunque el rendimiento disminuye ligeramente de errores de una sola línea a errores multi-hunk (múltiples cambios), la caída no es tan severa como se esperaba.
  • En algunos casos, los modelos incluso mejoraron su rendimiento en errores más complejos, sugiriendo que la capacidad de razonamiento de los LLMs ayuda a entender el contexto global.

• Modelos Abiertos vs. Cerrados (RQ4):

  • Los modelos cerrados (especialmente los de razonamiento como o3-mini y Claude 3.7) suelen tener un rendimiento superior en promedio.
  • Sin embargo, los modelos abiertos (como DeepSeek R1 y Qwen) están cerrando rápidamente la brecha y, en ciertos escenarios y lenguajes, igualan o superan a sus contrapartes cerradas.

• Combinación de Modelos:

  • Crear un "comité" de expertos (combinando parches de dos modelos diferentes) mejora significativamente el resultado final. Por ejemplo, combinar o3-mini con DeepSeek R1 aumentó la tasa de éxito en JavaScript y PHP.

5. Significado e Implicaciones

• Para la Práctica (Practitioners):

  • No se debe confiar en un solo modelo para una solución de reparación multi-lenguaje. Se recomienda implementar comités de modelos o seleccionar modelos específicos según el lenguaje de programación.
  • La información de las pruebas de fallo es esencial; los sistemas de APR deben integrar la ejecución de pruebas en el flujo de prompt.
  • Los modelos abiertos son ahora una alternativa viable y sostenible, reduciendo la dependencia de proveedores propietarios.

• Para la Investigación (Researchers):

  • La localización de fallos es un cuello de botella: Las evaluaciones futuras deben abandonar la suposición de localización perfecta y utilizar herramientas automatizadas realistas para medir el verdadero potencial de los LLMs.
  • Es necesario evaluar la generalización entre lenguajes y no solo dentro de un único benchmark.
  • La investigación debe enfocarse en mejorar la robustez de los LLMs ante la localización imprecisa y en la integración de flujos de trabajo agenticos que combinen localización y reparación.

En conclusión, el trabajo demuestra que, aunque los LLMs han avanzado significativamente en la reparación de software, la generalización sigue siendo un desafío. El éxito depende de la combinación inteligente de modelos, el uso de información de pruebas y la consideración realista de la calidad de la localización de errores.