Resumen Técnico: EVIACT – Un Marco de Evidencia-a-Acción para la Reparación de Programas Agéntica

Declaración del Problema

La Reparación Automática de Programas (APR) ha evolucionado desde la generación de parches de contexto fijo hacia la reparación interactiva a nivel de repositorio utilizando agentes de Modelos de Lenguaje Grande (LLM). Si bien los sistemas de APR agéntica existentes ofrecen flexibilidad, luchan por utilizar eficazmente la evidencia de ejecución para guiar el proceso de reparación. El artículo identifica una "brecha de evidencia-a-acción" crítica en los sistemas de APR agéntica basados en flujos de trabajo.

En los sistemas actuales basados en flujos de trabajo, la reparación se descompone en etapas (por ejemplo, localización, generación de parches, validación), pero los límites entre estas etapas están mal especificados. Esta falta de control estricto conduce a tres modos de fallo principales, ilustrados como una "cascada de mala localización" en la Figura 1:

1. Mala localización: Una evidencia de fallo débil conduce a conjuntos de sospechosos incorrectos, causando que el agente edite código no relacionado.
2. Intentos de parche inválidos: Los agentes generan parches malformados, inaplicables o no compilables que alcanzan la etapa de validación.
3. Alto costo de validación: El sistema prueba repetidamente parches semánticamente irrelevantes o no ejecutables, desperdiciando recursos computacionales.

El problema central es que la evidencia de ejecución se observa pero no se utiliza de manera fiable para controlar qué recuperar, qué editar y cuándo validar.

Metodología: El Marco EVIACT

Para abordar esta brecha, los autores proponen EVIACT (Evidencia-a-Acción), un marco de APR agéntica que coordina tres "guardarraíles" impulsados por la evidencia a través de una tubería estándar de cuatro etapas: Configuración, Localizar, Parchear y Verificar.

1. La Tubería

• Configuración: Inicializa un espacio de trabajo limpio, construye un índice de recuperación que preserva la estructura (utilizando spans AST y grafos de código) y reproduce el fallo objetivo para obtener evidencia ROJA (registros de pruebas fallidas, trazas de pila).
• Localizar: Convierte la evidencia ROJA en consultas fundamentadas en el fallo para clasificar las ubicaciones de código sospechosas.
• Parchear: Sintetiza ediciones candidatas basadas en el conjunto de sospechosos localizado.
• Verificar: Vuelve a ejecutar las pruebas objetivo y los conjuntos de pruebas de regresión completos para aceptar un parche.

2. Los Tres Guardarraíles

EVIACT introduce controles específicos en las transiciones de etapa para transformar la evidencia en restricciones accionables:

• Andamiaje de Recuperación (Configuración $\to$ Localizar):
  En lugar de una búsqueda de palabras clave sin restricciones, este andamiaje mapea la evidencia de fallo ROJA a un conjunto de sospechosos enfocado utilizando un grafo de código estructural. Realiza una recuperación determinista coincidiendo señales de fallo (marcos de pila, mensajes de error) con spans AST y descriptores estructurales (rutas de archivos, símbolos, grafos de llamadas). Clasifica los candidatos basándose en coincidencias exactas de traza-símbolo, proximidad de archivos y distancia de grafo, generando un conjunto compacto de los principales K sospechosos (valor predeterminado $K=3$).

• Puerta de Compilación (Etapa de Parche):
  Antes de cualquier validación de pruebas, esta puerta filtra los parches candidatos. Verifica si un parche es un diff bien formado, se aplica limpiamente y pasa las comprobaciones de sintaxis o compilación. Si un parche falla, se devuelven diagnósticos estructurados (tipo de fallo, archivos afectados, salida de compilación) al agente para su refinamiento, evitando que los candidatos inválidos alcancen costosos conjuntos de pruebas.

• Puerta Impulsada por Pruebas (PI) (Configuración $\to$ Verificar):
  Esta puerta impone un flujo ROJO-VERDE antes de la regresión completa.

  • ROJO: La prueba objetivo que falló originalmente debe fallar en la revisión con errores para anclar la localización.
  • VERDE: Después de aplicar el parche, la misma prueba objetivo debe pasar antes de que el sistema proceda a las pruebas de regresión completas.
    Esto asegura que el parche aborde específicamente el fallo observado antes de incurrir en el costo de la validación completa.

Contribuciones Clave

1. Identificación de la Brecha de Evidencia-a-Acción: El artículo enmarca la ineficiencia en la APR agéntica basada en flujos de trabajo como un problema de diseño de límites de etapa donde la evidencia de ejecución falla al restringir las decisiones de reparación posteriores.
2. El Marco EVIACT: Una arquitectura novedosa que coordina tres guardarraíles (Andamiaje de Recuperación, Puerta de Compilación, Puerta PI) para asegurar que las trayectorias de reparación permanezcan vinculadas a los fallos observados, los comentarios del compilador y los resultados de validación.
3. Evaluación Exhaustiva: Evaluación en cuatro puntos de referencia (Defects4J 2.0, SWE-bench Verified, SWE-bench Lite, SWE-bench Live) utilizando múltiples bases de modelos LLM (GPT-4o, GPT-5.2, DeepSeek-V3.2, Gemini-2.5-Pro).
4. Evidencia Empírica: Resultados que demuestran que el control coordinado de la evidencia mejora tanto la efectividad (tasa de resolución) como la eficiencia (costo de API, tiempo de ejecución).

Resultados Experimentales

Evaluado bajo la base de modelos GPT-4o, EVIACT supera a las líneas base comparables más fuertes reportadas en los cuatro conjuntos de datos:

• Tasas de Resolución: EVIACT logra mejoras de 1.6 a 6.0 puntos porcentuales sobre las líneas base (por ejemplo, 25.0% en Defects4J 2.0 frente a 19.6% para RepairAgent; 40.4% en SWE-bench Verified frente a 38.8% para Agentless).
• Eficiencia: Cuando están disponibles los costos de las líneas base, EVIACT muestra 70.1–88.6% menos costos de API por error.
• Escalado de Modelos: El uso de bases de modelos más potentes como GPT-5.2 aumenta aún más las tasas de resolución (hasta 70.2% en SWE-bench Verified), mientras que modelos rentables como DeepSeek-V3.2 mantienen un alto rendimiento con costos significativamente más bajos ($0.03–$0.05 por error).

Estudios de Ablación:
La eliminación de los guardarraíles degrada significativamente el rendimiento. El sistema completo EVIACT mejora la tasa de resolución en +13.0 puntos porcentuales sobre una línea base sin guardarraíles en una muestra estratificada, mientras reduce el uso de tokens en 84.1K y el tiempo de ejecución en 195.3 segundos. El estudio confirma que el andamiaje de recuperación reduce la deriva de localización, la puerta de compilación filtra candidatos inválidos y la puerta PI previene la regresión completa prematura.

Análisis de Fallos:
En las ejecuciones fallidas, el 46.5% se debe a mala localización y el 38.5% a ediciones incorrectas (contexto correcto pero cambio semántico erróneo). Cabe destacar que los parches malformados o no compilables se filtran eficazmente por la puerta de compilación, desplazando la frontera de fallo de la "invalidad ejecutable" a la "fundamentación semántica". El análisis manual de los parches resueltos muestra que el 78.0% son semánticamente correctos, aunque el 11.5% son sobreajustes (pasan las pruebas pero no implementan una reparación general).

Significado y Afirmaciones

El artículo afirma que EVIACT proporciona un mecanismo práctico de control de evidencia-a-acción para la APR agéntica. Al anclar las acciones de reparación en evidencia trazable (registros de fallos, diagnósticos del compilador y resultados de pruebas), el marco hace que las decisiones de reparación sean más efectivas y fiables.

Los autores notan modestamente que, aunque EVIACT reduce significativamente el costo de validación y mejora la localización, los cuellos de botella restantes son la fundamentación semántica (asegurar que la edición sea el correcto arreglo, no solo un arreglo funcional) y la recuperación robusta en estructuras de repositorio complejas. El artículo no afirma resolver completamente el sobreajuste semántico, pero demuestra que desplazar la frontera de fallo de errores sintácticos/ejecutables a errores semánticos es un paso necesario hacia una reparación agéntica más robusta. Se sugiere trabajo futuro para extender este diseño hacia sistemas adaptativos que refinen la localización y la validación basándose en la retroalimentación de ejecución acumulada.