Résumé Technique : Libra : Entraîner l'Environnement pour la Récupération d'Informations Agentique

Problématique

La localisation de code au sein de dépôts logiciels massifs est une capacité fondamentale pour les agents de codage autonomes, et elle est fortement corrélée aux taux de résolution des tâches en aval. Les approches existantes pour améliorer les performances des agents se classent généralement en deux catégories :

1. Centrées sur le Modèle : Le réglage fin (fine-tuning) du modèle de fondation sous-jacent à partir de données dérivées du dépôt. Cette approche verrouille le système à un modèle spécifique, risquant de sacrifier les capacités de raisonnement supérieures des modèles de langage commerciaux de pointe.
2. Augmentation Statique de l'Environnement : La construction d'indices statiques (par exemple, des résumés hiérarchiques, des indices inversés ou des graphes de connaissances) pour assister la récupération. Bien que ces indices soient indépendants du modèle, ils sont statiques et ne possèdent aucun mécanisme pour s'adapter dynamiquement aux défis de récupération spécifiques d'un agent ou pour exploiter les données d'interaction en vue d'une amélioration continue.

Le domaine manque actuellement d'un cadre agnostique au modèle et piloté par les données, capable de faire évoluer activement les capacités de récupération d'informations d'un agent pour un dépôt spécifique.

Méthodologie : Le Cadre Libra

Libra introduit un changement de paradigme, passant d'un indexation statique à un index de texte brut évoluant activement et natif au dépôt. Le système utilise un cadre d'auto-évolution piloté par une boucle d'optimisation de LLM adversaire impliquant trois agents gelés et un artefact d'environnement mutable : les Catalogues Libra.

1. L'Artéfact Mutable : Les Catalogues Libra

Libra construit une hiérarchie de fichiers Markdown (appelés « catalogues ») placés à la racine du dépôt et dans les répertoires des sous-modules. Ces fichiers servent d'indices navigables, encodant les informations de routage du dépôt. Contrairement aux plongements (embeddings) statiques ou aux graphes, ces catalogues sont lisibles par l'humain, éditables par l'humain et constituent des variables d'état mutables mises à jour par le système.

2. Les Trois Agents Gelés

La boucle d'optimisation utilise trois agents distincts avec des poids et des prompts fixes :

• Prompter (Synthétiseur de Données) : Génère des paires question-réponse synthétiques. Il échantillonne un fragment de code $c$ aléatoire dans le dépôt et fabrique une requête en langage naturel $q$ qui peut être résolue par $c$, avec le chemin de fichier cible $p^*$ comme réponse. Le Prompter est instruit d'éviter les identifiants exacts pour forcer la recherche sémantique.
• Solver (Résolveur de Requêtes) : Représente l'agent de codage en aval. Étant donné une requête $q$ et l'état actuel du catalogue $K$, le Solver tente de localiser le chemin de fichier correct $\hat{p}$ en naviguant dans le dépôt en utilisant uniquement les catalogues pour se guider. Crucialement, le Solver n'a pas accès au fragment ou au chemin cible pendant ce processus.
• Healer (Optimiseur de LLM) : Fonctionne comme l'optimiseur. Il analyse l'ensemble des échecs du Solver $F$ (où $\hat{p} \neq p^*$) et réécrit les catalogues Markdown $K$ pour réparer les signaux de routage. Le Healer diagnostique si les échecs proviennent de lacunes d'information, de bruit ou de problèmes structurels dans le catalogue, et applique des modifications ciblées.

3. La Boucle d'Optimisation

Le système opère en cycles ($T$) :

1. Phase de Test : Le Prompter génère un lot de requêtes. Le Solver tente de les résoudre en utilisant les catalogues actuels. Les échecs sont agrégés dans un ensemble d'échecs $F$.
2. Phase de Guérison (Healing) : Le Healer traite $F$ et met à jour les catalogues $K$ pour minimiser les futures erreurs de routage.
   Cette boucle se poursuit jusqu'à la convergence, produisant un ensemble de catalogues optimisés qui servent d'index persistant.

Contributions Clés

• Entraînement de l'Environnement : L'article propose d'entraîner l'environnement (l'index) plutôt que le modèle, créant un artéfact agnostique au modèle qui améliore la récupération sans nécessiter le réglage fin des poids du LLM.
• Auto-amélioration Adversaire : Le système utilise une boucle adversaire où le Prompter crée des requêtes difficiles, le Solver expose les faiblesses de l'index actuel, et le Healer affine de manière itérative la structure de l'index sur la base de ces échecs.
• Indices en Texte Brut : En utilisant des catalogues Markdown plutôt que des plongements vectoriels ou des graphes complexes, Libra offre un index interprétable, portable et éditable qui s'intègre nativement au code source.

Résultats Expérimentaux

Les auteurs ont évalué Libra sur 12 dépôts Python issus du jeu de données SWE-BENCH LITE.

• Amélioration Logarithmique : Sur le dépôt sympy, l'entraînement sur des requêtes synthétiques a produit des améliorations continues et logarithmiques de la précision de la localisation de code. Le système est parti d'une précision de fichier de 60,3 % (Étape 0) pour atteindre 83,3 % (Étape 85), surpassant les bases de référence de l'état de l'art.
• Généralisation aux Tâches Réelles : Des catalogues entraînés entièrement sur des données synthétiques ont réussi à transférer leurs capacités de routage à des tâches de localisation de bugs réelles de SWE-BENCH LITE. Le Solver Libra entraîné a obtenu les meilleures performances (77,8 % de File ACC à 5 tours, 82,3 % à 10 tours) par rapport à LocAgent et RepoMem, malgré un ensemble d'outils minimaliste (uniquement Bash et Read).
• Agnosticisme au Modèle : Les catalogues optimisés ont agi comme une ressource persistante qui a amélioré les performances de différents modèles de Solver (GPT-5-mini, GPT-5, et Gemini-2.5-Flash) sans réentraînement. L'augmentation de performance a été la plus significative pour les modèles les plus faibles (par exemple, Gemini-2.5-Flash a gagné +31,0 points de pourcentage).
• Effet de Guérison : L'analyse d'instances de test individuelles a montré que 54,3 % des instances se sont améliorées entre les premières et les dernières étapes de l'entraînement, avec un ratio de 3,3:1 entre les performances améliorées et dégradées, démontrant la capacité du système à corriger systématiquement les échecs de routage.

Signification et Revendications

L'article affirme que Libra démontre que l'optimisation d'indices textuels via un retour d'interaction offre une alternative viable et adaptable aux méthodes de récupération traditionnelles.

Les points clés soulignés par les auteurs incluent :

1. Changement de Paradigme : Passer d'un indexation statique et externe par plongements à un index de texte brut évoluant activement et natif au dépôt.
2. Transférabilité : Un système entraîné entièrement sur ses propres requêtes synthétiques peut réussir à transférer ses capacités de routage apprises pour résoudre des tâches de génie logiciel réelles.
3. Coût et Portabilité : L'approche atteint des performances compétitives par rapport aux bases de référence de l'état de l'art tout en offrant des avantages distincts en termes d'interprétabilité (catalogues lisibles par l'humain) et de portabilité (indépendance vis-à-vis du modèle).

Les auteurs reconnaissent des limites, notant l'intensité computationnelle de la boucle d'optimisation et l'hypothèse actuelle de dépôts statiques, laissant les mises à jour incrémentielles et la synthèse de requêtes multi-étapes aux travaux futurs. Cependant, ils affirment que le cadre comble avec succès le fossé entre l'augmentation statique de l'environnement et le réglage fin spécifique au modèle.