Beyond Localization: Recoverable Headroom and Residual Frontier in Repository-Level RAG-APR

1. Problema de Investigación

El campo de la Reparación Automática de Programas a Nivel de Repositorio (RAG-APR) ha adoptado la localización mejorada (encontrar los archivos y líneas de código correctos) como la vía principal para mejorar las tasas de reparación. Sin embargo, existe una brecha en la comprensión de qué ocurre después de que la localización se fortalece.

La pregunta central del artículo es: Una vez que la localización se optimiza, ¿qué palancas posteriores a la localización aún ofrecen ganancias recuperables, cuáles están acotadas y qué "frontera residual" permanece sin resolver?

El problema actual es que las evaluaciones existentes suelen comparar tasas de éxito de extremo a extremo, lo que impide aislar si las mejoras provienen de una mejor localización, de una mejor construcción de contexto, de la generación de parches o de la validación. Sin esta descomposición, es difícil saber si el progreso futuro debe centrarse en mejorar la recuperación de evidencia o en cómo se empaqueta y consume dicha evidencia.

2. Metodología

Los autores diseñaron un protocolo de estudio controlado en el conjunto de datos SWE-bench Lite (300 instancias) utilizando tres paradigmas representativos de RAG-APR:

1. Agentless: Flujo de trabajo en etapas con localización jerárquica y selección basada en pruebas.
2. KGCompass: Utiliza un grafo de conocimiento consciente del repositorio para recuperar evidencia estructurada.
3. ExpeRepair: Utiliza memoria aumentada para recuperar demostraciones pasadas e inyectarlas en la generación iterativa.

El estudio se basa en cuatro intervenciones controladas para aislar factores específicos:

• Localización de Oráculo (Oracle Localization): Se inyectan las ubicaciones exactas de los fallos (archivos y rangos de líneas derivados del parche "gold") en el conjunto de candidatos de cada sistema antes de que construyan su prompt final. Esto permite medir el potencial máximo si el sistema supiera exactamente dónde buscar, manteniendo su lógica de construcción de contexto y generación de parches original.
• Muestreo Best-of-K (Búsqueda dentro del sistema): Se evalúa la diversidad de candidatos dentro de pools de 10 parches generados bajo localización de oráculo para determinar cuánto "espacio de maniobra" (headroom) existe mediante la selección ideal de candidatos.
• Sondas de Contexto Adicionado con Interfaz Fija: Se añaden bloques de contexto de otros paradigmas (ej. añadir evidencia de KGCompass al prompt de Agentless) bajo interfaces fijas. Se utilizan controles estrictos:
  • Relleno exacto (Same-token filler): Mantiene la longitud del prompt pero sin información útil.
  • Negativos duros (Hard negatives): Evidencia del mismo repositorio pero para un problema diferente.
• Verificación de Oráculo Común: Se evalúa si las ganancias dependen de la interfaz específica del sistema o si persisten bajo un "wrapper" (envoltorio) de reparación unificado.

3. Contribuciones Clave

El artículo no propone un nuevo sistema de reparación, sino una análisis diagnóstico controlado post-localización. Sus contribuciones principales son:

• Estudio Controlado Post-Localización: Cuantifica cuánto margen de mejora queda después de optimizar la localización.
• Caracterización del "Headroom" Acotado: Mide cuánto pueden recuperar los sistemas mediante la búsqueda interna (diversidad de candidatos) y la selección ideal.
• Atribución de Evidencia Consciente del Control: Demuestra que las ganancias provienen de la calidad de la evidencia añadida y no simplemente del aumento de la longitud del prompt, mediante el uso de controles de relleno y negativos duros.
• Caracterización de la Frontera Residual: Identifica que, incluso tras agotar las ganancias de localización y contexto, existe una frontera conjunta no resuelta amplia que no se soluciona solo fusionando prompts.

4. Resultados Principales

RQ1: Ganancia de la Localización de Oráculo

• Mejora Limitada: La localización de oráculo mejora significativamente el rendimiento de los tres sistemas (aumentando las instancias resueltas de ~28-32% a ~39-43%), pero la tasa de éxito sigue estando por debajo del 50%.
• Cambio de Cuello de Botella: La mayor parte de la ganancia proviene de reducir los casos donde no se envía ningún parche (de ~45 casos a ~2-5), pero la mayoría de los fallos restantes ocurren en intentos de reparación que se envían pero fallan en las pruebas (unresolved).
• Dependencia de la Interfaz: La ganancia del oráculo depende de cómo se construye el prompt final. Agentless es muy sensible a la elección del "builder" (constructor del prompt), mientras que KGCompass y ExpeRepair mantienen gran parte de su ganancia incluso bajo un wrapper compartido.

RQ2: Espacio de Búsqueda y Saturación

• Ganancias Acotadas: La diversidad de candidatos y la selección ideal (Best-of-K) aportan mejoras adicionales (llegando a ~51-56% de éxito), pero estas ganancias saturan rápidamente.
• Saturación Temprana: Para $K=5$, ya se ha capturado el 86-87% del margen total disponible dentro del pool de 10 candidatos. Añadir más muestras ($K=10$) aporta muy poco.
• Bottleneck de Selección: El problema no es la falta de muestras, sino la dificultad para identificar y clasificar correctamente la "familia de parches" correcta y la variante adecuada dentro de los primeros intentos.

RQ3: Atribución de Contexto Adicionado

• Evidencia Informative vs. Relleno: Las condiciones de contexto añadido informativo (ej. añadir evidencia de KGCompass a Agentless) superan consistentemente a sus controles de relleno y negativos duros. Esto confirma que la mejora se debe a la estructura y relevancia de la evidencia, no solo a la longitud del prompt.
• Límites de Fusión: La fusión simple de múltiples fuentes de evidencia (UnionContext) no siempre es superior a la mejor fuente única. En algunos casos, la fusión diluye las ganancias estables de una fuente única.
• Impacto Temprano: Los contextos añadidos más fuertes ayudan a encontrar soluciones en los primeros intentos ($K=1$ o $K=2$), sugiriendo que mejoran la "ruta" hacia familias de parches correctas.

RQ4: Frontera Residual

• Frontera Amplia y Difícil: Incluso después de aplicar localización de oráculo, búsqueda óptima y fusión de contextos, 101 de 300 instancias (33.7%) permanecen sin resolver en la unión de los tres sistemas.
• Baja Recuperación de Frontera: Las sondas de contexto añadido recuperan muy pocos casos nuevos fuera de la unión nativa (solo 6 casos adicionales con la mejor sonda).
• Patrones de Fallo: La frontera residual se concentra en errores específicos como APIs incorrectas, excepciones de tiempo de ejecución, importaciones faltantes y fallos en aserciones. Estos errores persisten incluso con la mejor evidencia disponible, indicando que el modelo tiene dificultades para razonar sobre la semántica del código o la lógica de corrección más allá de la localización.

5. Significado e Implicaciones

Este trabajo cambia el enfoque de la investigación en APR de "mejorar la localización" a entender el proceso completo de reparación.

1. Más allá de la Localización: Mejorar la localización es necesario pero no suficiente. El cuello de botella se ha desplazado hacia la construcción de contextos efectivos, la selección de candidatos y la generación de parches semánticamente correctos.
2. Diseño de Interfaz: La forma en que se empaqueta la evidencia (el "wrapper" o interfaz) es tan crítica como la evidencia misma. Sistemas como Agentless son más sensibles a la arquitectura del prompt que otros.
3. Límites de la Fusión: Simplemente concatenar más contextos de diferentes fuentes no garantiza mejoras lineales; puede incluso degradar el rendimiento si no se gestiona bien la coherencia.
4. Frontera Real: Existe una "frontera residual" significativa que no se puede cerrar solo con mejores prompts o más datos de entrenamiento actuales. Se requieren avances en la capacidad de razonamiento de los modelos para entender la lógica de reparación profunda y manejar errores de ejecución complejos.

En conclusión, el artículo aboga por una agenda de investigación post-localización que priorice la calidad de la evidencia, el diseño de interfaces de reparación y estrategias de generación y validación de parches más robustas, en lugar de centrarse exclusivamente en la recuperación de archivos.