Resumen Técnico: TrajSpec – Refinamiento de la Especificación de Reportes de Errores Guiado por Trayectorias

Declaración del Problema

Los agentes de Reparación Automática de Programas (APR) a nivel de repositorio dependen de los reportes de errores como su principal especificación de tarea. Sin embargo, los reportes de errores estándar suelen describir solo los síntomas de falla observados, omitiendo información crítica para la reparación, como el mecanismo de falla subyacente, los requisitos de comportamiento específicos y el alcance completo de la implementación. En consecuencia, los agentes de APR pueden inspeccionar código irrelevante, inferir requisitos incorrectos o generar parches que abordan el síntoma reportado sin restaurar el comportamiento previsto del repositorio. Aunque trabajos previos se han centrado en mejorar las estrategias de búsqueda, la localización o la ingeniería de prompts de los agentes, estos enfoques suelen asumir que el reporte de entrada proporciona una especificación suficiente. Existe una brecha en los métodos que refinan explícitamente el reporte mediante la recopilación de detalles de especificación faltantes del repositorio antes de que comience el proceso de reparación descendente.

Metodología: TrajSpec

Los autores proponen TrajSpec, un enfoque guiado por trayectorias para el refinamiento de especificaciones soportadas por el repositorio. El sistema opera sobre un reporte de error original ($b$) y una instantánea del repositorio pre-corrección ($R_c$) a través del siguiente flujo de trabajo:

1. Recopilación de Trayectorias No Verificadas:
   TrajSpec ejecuta un agente de recopilación de trayectorias utilizando únicamente $b$ y $R_c$. Este agente explora el repositorio, inspecciona el código y razona sobre el problema. Crucialmente, esta ejecución es no verificada: TrajSpec no valida ningún parche candidato producido durante esta fase. Cualquier parche candidato es descartado, y solo se retiene la trayectoria de ejecución ($\tau$) —una secuencia de tuplas de pensamiento-acción-observación—. Esta trayectoria sirve como una fuente de evidencia soportada por el repositorio, incluso si el parche final del agente fue incorrecto.

2. Abstracción Jerárquica de Evidencia:
   Las trayectorias puras suelen ser ruidosas y extensas. TrajSpec extrae hallazgos candidatos de $b$ y $\tau$ enfocándose en tres dimensiones:

   • Mecanismo de Falla: El comportamiento del código fuente que explica el síntoma.
   • Requisito de Comportamiento: El comportamiento que debería mantenerse.
   • Alcance de Implementación: Las ubicaciones de código involucradas.

   Estos hallazgos se organizan en una representación jerárquica ($M$) con tres niveles de detalle para cada dimensión:

   • Nivel alto: Una conclusión de la especificación candidata.
   • Nivel medio: Razonamiento diagnóstico y relaciones (por ejemplo, rutas de código, dependencias).
   • Nivel bajo: Observaciones concretas del repositorio (por ejemplo, archivos, funciones o variables específicas).

3. Generación de Borrador y Revisión Basada en el Repositorio:
   Utilizando $b$ y $M$, un LLM genera un borrador de reporte refinado ($\hat{b}$) siguiendo un esquema fijo (Título, Descripción, CausaRaíz, PasosParaReproducir, ComportamientoEsperado, ComportamientoObservado).

   Un paso de revisión basada en el repositorio valida entonces $\hat{b}$ contra $R_c$. Un agente revisor evalúa si las afirmaciones en el borrador están respaldadas por la evidencia en $M$ y el código fuente real. Elimina las afirmaciones no respaldadas, revisa las declaraciones inciertas, añade los detalles faltantes soportados por el repositorio y asegura que el alcance de la implementación esté apropiadamente delimitado. El resultado es el reporte refinado final ($\hat{b}_f$), que sirve como la especificación de tarea para el agente de reparación descendente.

Contribuciones Clave

• Formulación: El artículo formula el mejoramiento de reportes de errores para APR a nivel de repositorio como un "refinamiento de especificación soportado por el repositorio", buscando hacer explícitos el mecanismo de falla, el requisito de comportamiento y el alcance de la implementación.
• Marco de Trabajo TrajSpec: Introducción de un método que extrae y organiza jerárquicamente la evidencia de la especificación a partir de una ejecución de recopilación de trayectorias no verificada, revisa esta evidencia contra el código fuente y genera un reporte refinado sin asumir que los parches candidatos de la trayectoria son correctos.
• Evaluación Exhaustiva: Evaluación en las 300 instancias de SWE-Bench Lite usando Mini-SWE-Agent V2, demostrando mejoras significativas en el rendimiento.
• Generalización: Demostración de que los beneficios de TrajSpec se generalizan a través de diferentes agentes de reparación descendentes (Agentless y AutoCodeRover).
• Análisis de Componentes: Estudios de ablación que confirman que tanto la representación jerárquica de la evidencia como la revisión basada en el repositorio son críticos para las ganancias de rendimiento.

Resultados de la Evaluación

Los autores evaluaron TrajSpec en 300 instancias de SWE-Bench Lite:

• Agente de Reparación Primario (Mini-SWE-Agent V2):

  • Con GPT-5-mini, el Pass@1 mejoró de 41.00% (reportes originales) a 59.67%.
  • Con MiniMax M2.5, el Pass@1 mejoró de 54.67% a 64.33%.
  • TrajSpec superó a una línea base "Agentic-Base" (que utiliza datos de trayectoria pero carece de abstracción jerárquica y revisión de repositorio) en ambos entornos.
  • Las mejoras se distribuyeron ampliamente en 12 repositorios diferentes, donde TrajSpec expandió la cobertura de reparación preservando casi todas las instancias previamente reparadas por los reportes originales.

• Generalización entre Agentes (Muestra Estratificada de 100 instancias):

  • Agentless: El Pass@1 mejoró del 41.00% al 71.00%.
  • AutoCodeRover: El Pass@1 mejoró del 47.00% al 72.00%.

• Estudios de Ablación:

  • Eliminar la revisión basada en el repositorio redujo el Pass@1 del 59.67% al 48.00%.
  • Eliminar la representación jerárquica de la evidencia redujo el Pass@1 al 47.67%.
  • Esto confirma que tanto estructurar la evidencia como verificar las afirmaciones contra el repositorio son esenciales.

• Análisis de Costos:

  • Aunque TrajSpec incurre en un costo adicional para la generación del reporte (aprox. $0.083 por instancia con GPT-5-mini), reduce el uso de tokens de entrada de la reparación descendente en un ~24% y disminuye el costo monetario de la ejecución de la reparación. El costo total de extremo a extremo sigue siendo modesto en relación con las ganancias significativas en el éxito de la reparación.

Significado y Reivindicaciones

El artículo sostiene que TrajSpec proporciona una dirección prometedora para mejorar la reparación a nivel de repositorio al abordar el "problema de la especificación" inherente a los reportes de errores subespecificados. Los autores enfatizan que:

1. Las trayectorias son reutilizables más allá de la generación de parches: Incluso las trayectorias no verificadas contienen evidencia valiosa sobre los mecanismos de falla y el alcance del código que puede abstraerse y estructurarse para mejorar la especificación de la tarea.
2. La verificación es crítica: El simple uso de datos de trayectoria es insuficiente; una estructura jerárquica y un paso de revisión basado en el repositorio son necesarios para filtrar el ruido y asegurar que las afirmaciones estén fundamentadas en el código pre-corrección.
3. La especificación de la tarea importa: Mejorar la especificación de entrada (el reporte de error) es tan importante como mejorar el propio agente de reparación. TrajSpec demuestra que proporcionar a los agentes un contexto accionable y soportado por el repositorio mejora consistentemente el rendimiento de la reparación en diferentes modelos y arquitecturas de agentes.

Los autores mantienen una postura modesta, señalando que su evaluación se limita a repositorios Python en SWE-Bench Lite y que la efectividad para otros lenguajes o benchmarks sigue siendo un trabajo futuro. También reconocen que, si bien los reportes refinados mejoran las métricas de reparación automatizada, el estudio se centra en la utilidad para APR en lugar de la calidad del reporte percibida por humanos.