Resumen Técnico: Libra: Entrenando el Entorno para la Recuperación de Información Agéntica

Declaración del Problema

La localización de código dentro de repositorios de software masivos es una capacidad fundamental para los agentes de codificación autónomos, lo cual se correlaciona fuertemente con las tasas de resolución de tareas en etapas posteriores. Los enfoques existentes para mejorar el rendimiento de los agentes generalmente se dividen en dos categorías:

1. Centrados en el Modelo: Ajustar (fine-tuning) el modelo fundacional subyacente utilizando datos derivados del repositorio. Este enfoque vincula el sistema a un modelo específico, lo que podría sacrificar las capacidades de razonamiento superiores de los LLM comerciales de vanguardia.
2. Aumento de Entorno Estático: Construir índices estáticos (por ejemplo, resúmenes jerárquicos, índices inversos o grafos de conocimiento) para asistir en la recuperación. Aunque son agnósticos al modelo, estos índices son estáticos y carecen de mecanismos para adaptarse dinámicamente a los desafíos de recuperación específicos de un agente o para aprovechar los datos de interacción para una mejora continua.

El campo carece actualmente de un marco de trabajo agnóstico al modelo y basado en datos que pueda evolucionar activamente las capacidades de recuperación de información de un agente para un repositorio específico.

Metodología: El Marco de Trabajo Libra

Libra introduce un cambio de paradigma de la indexación estática a un índice de texto plano que evoluciona activamente y es nativo del repositorio. El sistema emplea un marco de autoevolución impulsado por un bucle de optimización de LLM adversarial que involucra a tres agentes congelados y un artefacto de entorno mutable: Libra Catalogs (Catálogos de Libra).

1. El Artefacto Mutable: Libra Catalogs

Libra construye una jerarquía de archivos Markdown (denominados "catálogos") ubicados en la raíz del repositorio y dentro de los directorios de los submódulos. Estos archivos sirven como índices navegables que codifican la información de enrutamiento del repositorio. A diferencia de los embeddings o grafos estáticos, estos catálogos son legibles por humanos, editables por humanos y variables de estado mutables actualizadas por el sistema.

2. Los Tres Agentes Congelados

El bucle de optimización utiliza tres agentes distintos con pesos y prompts fijos:

• Prompter (Sintetizador de Datos): Genera pares de pregunta-respuesta sintéticos. Toma un fragmento de código aleatorio $c$ del repositorio y fabrica una consulta en lenguaje natural $q$ que sea respondible por $c$, siendo la ruta del archivo de oro $p^*$ la respuesta. Se le instruye al Prompter que evite identificadores exactos para forzar la búsqueda semántica.
• Solver (Resolutor de Consultas): Representa al agente de codificación de nivel inferior. Dada una consulta $q$ y el estado actual del catálogo $K$, el Solver intenta localizar la ruta de archivo correcta $\hat{p}$ navegando por el repositorio utilizando únicamente los catálogos como guía. Crucialmente, el Solver no tiene acceso al fragmento de oro ni a la ruta durante este proceso.
• Healer (Optimizador de LLM): Funciona como el optimizador. Analiza el conjunto de fallos del Solver $F$ (donde $\hat{p} \neq p^*$) y reescribe los catálogos Markdown $K$ para reparar las señales de enrutamiento. El Healer diagnostica si los fallos se deben a brechas de información, ruido o problemas estructurales en el catálogo y aplica ediciones dirigidas.

3. El Bucle de Optimización

El sistema opera en rondas ($T$):

1. Fase de Prueba: El Prompter genera un lote de consultas. El Solver intenta resolverlas utilizando los catálogos actuales. Los fallos se agregan en un conjunto de fallos $F$.
2. Fase de Curación (Healing): El Healer procesa $F$ y actualiza los catálogos $K$ para minimizar futuros errores de enrutamiento.
   Este bucle continúa hasta la convergencia, produciendo un conjunto de catálogos optimizados que sirven como un índice persistente.

Contribuciones Clave

• Entrenamiento del Entorno: El artículo propone entrenar el entorno (el índice) en lugar del modelo, creando un artefacto agnóstico al modelo que mejora la recuperación sin realizar el ajuste de pesos del LLM.
• Auto-mejora Adversarial: El sistema utiliza un bucle adversarial donde el Prompter crea consultas desafiantes, el Solver expone las debilidades en el índice actual y el Healer refina iterativamente la estructura del índice basándose en estos fallos.
• Índices de Texto Plano: Al utilizar catálogos en Markdown en lugar de embeddings vectoriales o grafos complejos, Libra ofrece un índice interpretable, portátil y editable que se integra de forma nativa con el código base.

Resultados Experimentales

Los autores evaluaron Libra en 12 repositorios de Python del conjunto de datos SWE-BENCH LITE.

• Mejora Logarítmica: En el repositorio sympy, el entrenamiento con consultas sintéticas produjo mejoras continuas y logarítmicas en la precisión de la localización de código. El sistema comenzó con una precisión de archivo del 60.3% (Paso 0) y alcanzó el 83.3% (Paso 85), superando a los modelos de referencia del estado del arte.
• Generalización a Tareas del Mundo Real: Los catálogos entrenados enteramente con datos sintéticos se transfirieron con éxito a tareas de localización de errores reales de SWE-BENCH LITE. El Solver de Libra entrenado logró el mayor rendimiento (77.8% de File ACC en 5 turnos, 82.3% en 10 turnos) en comparación con LocAgent y RepoMem, a pesar de utilizar un conjunto de herramientas minimalista (solo Bash y Read).
• Agnosticismo al Modelo: Los catálogos optimizados actuaron como un recurso persistente que mejoró el rendimiento de diferentes modelos de Solver (GPT-5-mini, GPT-5 y Gemini-2.5-Flash) sin reentrenamiento. La mejora de rendimiento fue más significativa para los modelos más débiles (por ejemplo, Gemini-2.5-Flash ganó +31.0 puntos porcentuales).
• Efecto de Curación: El análisis de instancias de prueba individuales mostró que el 54.3% de las instancias mejoraron desde las etapas tempranas a las tardías del entrenamiento, con una relación de 3.3:1 entre el rendimiento mejorado y el degradado, demostrando la capacidad del sistema para corregir sistemáticamente los fallos de enrutamiento.

Significado y Reivindicaciones

El artículo afirma que Libra demuestra que la optimización de índices basados en texto mediante la retroalimentación de interacción ofrece una alternativa viable y adaptable a los métodos de recuperación tradicionales.

Los puntos clave enfatizados por los autores incluyen:

1. Cambio de Paradigma: Pasar de embeddings estáticos y externos a un índice de texto plano que evoluciona activamente y es nativo del repositorio.
2. Transferibilidad: Un sistema entrenado enteramente con sus propias consultas sintéticas puede transferir con éxito sus capacidades de enrutamiento aprendidas para resolver tareas de ingeniería de software del mundo real.
3. Costo y Portabilidad: El enfoque logra un rendimiento competitivo con los modelos de referencia del estado del arte, ofreciendo ventajas distintivas en interpretabilidad (catálogos legibles por humanos) y portabilidad (agnóstico al modelo).

Los autores reconocen las limitaciones, señalando la intensidad computacional del bucle de optimización y la suposición actual de repositorios estáticos, dejando las actualizaciones incrementales y la síntesis de consultas de múltiples saltos para trabajos futuros. Sin embargo, sostienen que el marco de trabajo logra cerrar la brecha entre el aumento de entorno estático y el ajuste fino específico del modelo.