Résumé Technique : Réduction de l'utilisation des jetons des agents à état en contexte par la minification

Énoncé du problème

Les modèles de langage de grande taille (LLM) sont de plus en plus utilisés comme moteurs de raisonnement pour les agents d'ingénierie logicielle (SE), particulièrement pour les tâches au niveau du dépôt comme celles de la référence SWE-bench. Dans ces flux de travail, les agents doivent extraire et raisonner sur de vastes bases de code, ce qui entraîne une croissance rapide de la taille du contexte et une consommation élevée de jetons (tokens). Étant donné que l'utilisation des jetons est directement corrélée aux coûts opérationnels et peut entraîner une dégradation des performances due aux limites de contexte, il est crucial de réduire efficacement la taille du contexte tout en conservant les informations pertinentes.

Des travaux récents de Jiang et al. ont introduit les agents « state-in-context » (état en contexte), qui simplifient l'architecture en injectant une version compressée de l'état complet de l'environnement dans un seul prompt, plutôt que de reconstruire progressivement l'état via des appels d'outils. Cependant, l'analyse de ces agents révèle que la vaste majorité de la consommation de jetons se produit lors de l'étape de réparation, où le code source domine le prompt. Plus précisément, plus de 90 % des jetons dans le prompt de réparation sont consommés par le code source, tandis que les instructions en langage naturel et le classement des fichiers ne représentent que moins de 10 %. Ce document traite du défi consistant à réduire cette consommation de jetons sans subir de pertes de performance prohibitives.

Méthodologie

Réplication et ligne de base

Les auteurs ont d'abord procédé à une réplication indépendante et une extension de l'agent state-in-context DirectSolve. Aucun artefact public n'étant disponible, ils ont implémenté une version « clean-room » basée sur les spécifications originales. Le flux de travail comprend trois étapes :

1. Classement (Ranking) : Un LLM classe les fichiers du dépôt en fonction de leur pertinence par rapport à une description de problème en utilisant uniquement les chemins de fichiers.
2. Agrégation : Les fichiers les mieux classés sont agrégés dans un contexte jusqu'à un budget de jetons prédéfini (plafonné à 100 000 jetons dans cette étude pour assurer une comparaison équitable entre les modèles).
3. Réparation (Repair) : Un LLM génère un patch au format SEARCH/REPLACE basé sur le contexte agrégé.

Les auteurs ont évalué cette ligne de base sur le benchmark SWE-bench Verified en utilisant GPT-5-mini, atteignant un taux de réussite pass@1 de 50,0 %, ce qui est cohérent avec le rapport original de 50,8 % utilisant Gemini-2.5-Pro.

Stratégie de minification

Pour réduire l'utilisation des jetons, les auteurs ont appliqué une série de techniques de minification de code aux fichiers sources avant qu'ils ne soient transmis au LLM pour la réparation. Ces transformations sont conçues pour supprimer ou raccourcir les éléments lexicaux non essentiels tout en préservant la sémantique du programme. Les techniques spécifiques incluent :

• Suppression des espaces blancs et des opérateurs : Élimination des lignes vides et suppression des espaces autour des opérateurs (par exemple, a + b devient a+b).
• Suppression des commentaires et docstrings : Retrait des commentaires et des docstrings, qui sont ignorés à l'exécution.
• Dédentation (Dedentation) : Réduction des niveaux d'indentation (par exemple, de 4 espaces à 2) tout en maintenant la cohérence au sein des blocs. Pour éviter que le LLM ne génère des patchs invalides en raison de désalignements d'indentation, le système instruit le modèle de produire des blocs SEARCH/REPLACE avec un style d'indentation fixe de 4 espaces, quel que soit le format d'entrée.
• Raccourcissement des identifiants : Remplacement des noms de variables, de fonctions et de classes par des alias plus courts. Cela a été testé sous deux modes :
  • Non-préservant la sémantique : Remplacement direct sans contexte.
  • Préservant la sémantique : Renommage des identifiants et ajout d'un tableau de correspondance au prompt afin que le LLM puisse reconstruire les noms originaux.
• Manipulation des imports : Fusion de tous les imports dans un seul fichier synthétique ou suppression pure et simple.

Ces transformations ont été intégrées dans le pipeline de réparation. Après la génération du patch, les correspondances d'identifiants ont été inversées, et une procédure de correspondance tolérante aux différences d'espaces blancs et de commentaires a été utilisée pour appliquer les patchs au dépôt original.

Principales contributions

1. Réplication indépendante : Une réimplémentation « clean-room » de l'agent state-in-context DirectSolve, démontrant qu'un agent à appel unique et sans outil peut atteindre des performances compétitives (50 % pass@1) sur SWE-bench Verified lorsqu'il est couplé à un modèle performant (GPT-5-mini).
2. Analyse de l'allocation des jetons : Une analyse empirique révélant que le code source dans le prompt de réparation est le facteur dominant de la consommation de jetons, éclipsant les instructions en langage naturel et les prompts de classement.
3. Cadre de minification : La proposition et l'intégration d'un ensemble de transformations de minification de code légères et préservant la sémantique, adaptées au code source Python dans le flux de travail de réparation state-in-context.
4. Évaluation empirique : Une évaluation systématique sur SWE-bench Verified montrant que la minification réduit l'utilisation moyenne des jetons d'entrée d'environ 42 % avec une baisse de 12 points de pourcentage du taux de résolution (de 50,0 % à 38,0 %).
5. Étude d'ablation et d'échec : Des études détaillées isolant les transformations individuelles et leurs combinaisons cumulées, quantifiant leurs compromis spécifiques. Les auteurs ont identifié que si la plupart des transformations entraînent des pertes de performance modestes, la transformation « dedent » provoque une chute significative du taux de résolution en raison de la génération de patchs syntaxiquement invalides (erreurs d'indentation).

Résultats

• Efficacité vs Efficacité : La principale conclusion est un arbitrage clair. La minification réduit les jetons d'entrée moyens de ~90 535 à ~52 776 (une réduction de 42 %). Cela se traduit par une diminution absolue de 12 % du taux de résolution.
• Implications de coût : Puisque les jetons d'entrée représentent environ 93 % du coût de l'étape de réparation, la réduction des jetons se traduit directement par des économies de coûts significatives.
• Spécificités des transformations :
  • La suppression des docstrings et des commentaires a fourni les plus grandes réductions de jetons avec des pénalités de performance relativement faibles (les taux de résolution restant au-dessus de 40 %).
  • La transformation « dedent » a été l'anomalie principale, faisant chuter le taux de résolution à 27-36 % selon le modèle et la configuration de cumul. L'analyse d'échec a indiqué que cela était dû à l'incapacité du LLM à restaurer l'indentation requise de 4 espaces dans la sortie, entraînant des erreurs IndentationError dans le code généré.
  • Le cumul de plusieurs transformations (en excluant le dedent) a systématiquement réduit les coûts tout en maintenant des performances proches de la ligne de base.
• Généralisabilité : Les tendances observées sont stables à travers différents dépôts et niveaux de difficulté des problèmes, suggérant que l'approche se généralise bien à différentes conditions.

Signification

L'article soutient que les transformations légères de code source offrent une voie prometteuse vers des agents d'ingénierie logicielle plus rentables. En démontant qu'une fraction substantielle de la performance de base peut être conservée tout en réalisant une réduction de près de 50 % des jetons, ce travail suggère qu'une compression agressive du contexte est viable pour les tâches au niveau du dépôt. Les auteurs soulignent que leurs conclusions mettent en évidence un arbitrage explicite entre efficacité et efficacité, fournissant une base de données pour sélectionner des stratégies de transformation basées sur des exigences spécifiques de coût et de performance. L'implémentation complète est rendue publique pour soutenir la recherche ultérieure dans ce domaine.