Resumen Técnico: Estructura de Exploración en Agentes LLM para la Localización de Cambios en Múltiples Archivos

Planteamiento del Problema

Los problemas de ingeniería de software rara vez involucran cambios en un solo archivo; resolver un error suele requerir modificaciones en múltiples subsistemas (por ejemplo, CLI, librerías subyacentes, complementos y documentación). Los agentes de Modelos de Lenguaje Extensos (LLM) actuales emplean típicamente una estrategia de exploración lineal y secuencial, visitando un directorio o archivo por paso. Los autores postulan que este enfoque lineal es un desajuste estructural para los cambios de múltiples archivos que abarcan varios subsistemas. Si un agente agota su presupuesto de pasos o de tokens mientras explora el primer subsistema, es posible que los subsistemas posteriores que contienen los archivos "gold" necesarios nunca lleguen a ser examinados.

El artículo aborda tres preguntas de investigación fundamentales:

1. ¿Es la exploración lineal estructuralmente limitante para los cambios de múltiples archivos, o pueden los modelos potentes compensarlo mediante una mejor selección de pasos?
2. ¿Otorgar acceso directo al sistema de archivos mejora la localización de forma fiable, o introduce errores de navegación y sobrepredicción?
3. ¿Forzar una consulta multi-agente agresiva mejora la recuperación (recall), o inyecta ruido de subsistemas irrelevantes?

Metodología

Construcción del Benchmark

El estudio utiliza un benchmark de sesión persistente derivado de SWE-BENCH PRO, centrándose en el repositorio ansible/ansible.

• Alcance: Se construyeron tres ventanas temporales: mayo–noviembre de 2020 (el conjunto curado original), abril–septiembre de 2025 y enero–mayo de 2026.
• Estabilidad: Todos los casos en una ventana están anclados a un único commit base para garantizar un estado constante del repositorio y costos de exploración constantes.
• Conjuntos Gold: Los autores comparan contra el conjunto gold curado de SWE-BENCH PRO (archivos fuente seleccionados manualmente) y un conjunto gold expandido basado en PR (cada archivo tocado por el Pull Request que resolvió el problema, incluyendo pruebas y registros de cambios).
• Métricas: Las métricas primarias incluyen Micro-F1, la tasa de All-Gold (fracción de instancias donde se predice todos los archivos de la verdad fundamental) y el F1 macro por instancia.

Sistemas Experimentales

Los autores comparan cuatro familias de sistemas LLM, aislando la estructura de exploración de la capacidad del modelo base mediante el uso del mismo modelo pequeño de la clase Haiku para la mayoría de las variantes:

1. LLM Simple (Sin acceso al repositorio): Una única llamada a la API que depende únicamente del conocimiento preentrenado de la estructura del repositorio.
2. Modelo de Lenguaje Recursivo (RLM) de Agente Único: Un agente con un REPL de Python persistente que permite el acceso secuencial al sistema de archivos (por ejemplo, os.listdir, grep). Esto pone a prueba la eficacia de la exploración secuencial sin especialización de dominio.
3. Sistema de Agente de Dominio (Propuesto): Una arquitectura multi-agente que presenta:
   • Inicialización: Un coordinador raíz explora el repositorio para identificar áreas de mantenimiento coherentes (subsistemas como cli/, module_utils/, docs/) y genera agentes de dominio persistentes para cada uno.
   • Tiempo de Consulta: El coordinador despacha agentes de dominio relevantes en paralelo para explorar sus regiones asignadas.
   • I/O Limitada: Los archivos grandes y los listados de directorios se gestionan en un entorno programático; solo vistas previas compactas o rangos de líneas específicos entran en el contexto del LLM para evitar el agotamiento de tokens.
   • Ablaciones: Las variantes incluyen "no-spawn" (el registro está presente pero no hay despacho paralelo) y "nudged" (consulta agresiva forzada).
4. Línea Base de CLI Externa: Utiliza Codex 5.5 High, un modelo de frontera mucho más grande, para establecer una referencia de límite superior.
5. Línea Base BM25: Un sistema clásico de recuperación léxica que recorre $K$ de 1 a 30 para generar un envolvente de precisión-recuperación.

Contribuciones Clave y Hallazgos

1. La estructura de exploración es un factor crítico

El enfoque de Agente de Dominio, que paraleliza la exploración a lo largo de los subsistemas del repositorio, logra el Micro-F1 más alto entre todos los modelos de la clase Haiku por un margen amplio.

• En el benchmark curado de 2020, el Agente de Dominio (Haika) logra un Micro-F1 de 0.447, superando significativamente al LLM Simple (Haiku) con 0.199 y al RLM de Agente Único (Haiku) con 0.151.
• El sistema de Agente de Dominio es competitivo con el mucho más grande Codex 5.5 High (Micro-F1 0.422 en el curado, 0.523 en el basado en PR), a pesar de utilizar un modelo más pequeño.
• Hallazgo: La exploración lineal (RLM) es estructuralmente limitante; la exploración paralela y con alcance de dominio es necesaria para una localización de múltiples archivos efectiva.

2. El acceso ingenuo al sistema de archivos puede degradar el rendimiento

Contrario a la intuición de que más acceso equivale a un mejor rendimiento, otorgar a un solo agente acceso bruto al sistema de archivos (RLM) degradó la localización en comparación con un LLM Simple al usar el mismo modelo Haiku.

• RLM (Haiku): Micro-F1 0.151.
• LLM Simple (Haiku): Micro-F1 0.199.
• Causa: El RLM tendía a sobrepredecir archivos de prueba y a navegar hacia jerarquías irrelevantes, agotando los presupuestos de contexto e introduciendo falsos positivos. El LLM Simple, al confiar en el conocimiento estructural preentrenado, era más conservador y preciso.

3. La consulta forzada no ayuda

Forzar al coordinador a consultar más agentes (variante "nudged") no mejoró la recuperación de forma mensurable, pero aumentó significativamente los costos de tokens (de ~16M a ~25M de tokens).

• El despliegue indiscriminado introdujo ruido de subsistemas irrelevantes sin recuperar archivos gold adicionales.
• Conclusión: El despacho adaptativo (consultar solo los dominios relevantes) es superior a la consulta forzada y agresiva.

4. La brecha de co-evolución de la documentación

Se observó un fallo sistemático en todas las arquitecturas (incluyendo el modelo grande Codex) con respecto a los archivos de documentación (docs/docsite/).

• Tasa de Omisión: Los archivos de documentación tuvieron una tasa de omisión agregada del 73%, mucho más alta que la de los archivos de código.
• Razón: Las descripciones de los problemas suelen describir cambios en el comportamiento del código fuente sin mencionar explícitamente la necesidad de actualizar la documentación. Esta es una dependencia latente (acoplamiento lógico) que las políticas de exploración actuales no pueden resolver porque la "señal" falta en el texto de entrada.

5. Generalización en el tiempo

Los resultados se generalizan a través de las ventanas temporales (2020, 2025, 2026).

• El enfoque de Agente de Dominio superó consistentemente a otras líneas base de modelos pequeños.
• En las ventanas de 2025 y 2026, el enfoque de Agente de Dominio incluso superó a Codex 5.5 High en el conjunto gold "estrecho" (solo fuente), aunque Codex mantuvo una ventaja en el conjunto "amplio" (basado en PR) debido a su tendencia a predecir conjuntos de archivos más amplios (incluyendo pruebas).

Significado y Reivindicaciones

El artículo afirma que la estructura de exploración es un factor de segundo orden que puede compensar la capacidad limitada del modelo. Al reestructurar el agente para paralelizar la exploración a lo largo de los subsistemas del repositorio y utilizar I/O limitada, un modelo pequeño puede igualar o superar el rendimiento de modelos de frontera mucho más grandes en tareas de localización de cambios de múltiples archivos.

Sin embargo, los autores son modestos sobre las limitaciones:

• La exploración no es suficiente: Ninguna arquitectura actual puede recuperar de forma fiable los archivos de documentación porque el texto del problema carece de las señales necesarias. Esto requiere un cambio en la política de enrutamiento (por ejemplo, despachar agentes de documentación basados en cambios de fuente) en lugar de una mejor exploración.
• El acceso no es una panacea: El acceso bruto al sistema de archivos sin estrategias de exploración dirigidas puede dañar activamente el rendimiento al amplificar las ambigüedades de los prompts y causar sobrepredicción.
• Alcance: El estudio aísla la localización de archivos de la generación de parches y la ejecución de pruebas, lo que significa que estos hallazgos se aplican específicamente a la fase de "dónde realizar el cambio" de la ingeniería de software.

El trabajo establece que para la localización de cambios de múltiples archivos, el despliegue paralelo con alcance de dominio es un patrón arquitectónico superior a la exploración secuencial lineal, siempre que el sistema evite el acceso ingenuo al sistema de archivos y gestione los presupuestos de tokens mediante I/O limitada.