FR
Comment le contexte des agents de programmation modifie le travail du serveur
The Physical Cost of Context: Quality-Constrained Resource Accounting for Coding Agents · arXiv:2610.34763
En termes simples
Chaque fois qu’un agent de programmation demande au modèle d’agir, il lui envoie des informations sur le projet. Même si le message est plus court, le serveur peut avoir davantage de travail à effectuer si les modifications apportées aux messages précédents l’empêchent de réutiliser des informations déjà traitées.
L’article propose une méthode qui vérifie la qualité des tâches et comptabilise les appels au modèle ainsi que les entrées que le serveur doit traiter de nouveau. Dans des tests distincts de localisation, fournir tôt du code récupéré a franchi le contrôle de qualité et nécessité moins d’appels et moins d’énergie GPU mesurée qu’une recherche menée à partir du seul énoncé du problème.
La recherche
Quand les agents de programmation renvoient sans cesse le contexte du projet, réduire leurs prompts diminue-t-il à coup sûr le travail du serveur ?
La réponse peut dépendre de la possibilité de réutiliser les entrées précédentes et de l’effet d’une politique sur le nombre de requêtes envoyées par l’agent.
Les auteurs proposent une méthode de comptabilisation soumise à un seuil de qualité qui distingue la taille du prompt du travail du serveur, puis évaluent comment la récupération de code, les modifications de l’historique et la mise en cache changent ce travail.
Les auteurs comparent Grep, qui part d’un énoncé de problème pour localiser le code, à Eager, qui fournit dix extraits récupérés avant le premier tour ; les deux politiques conservent l’historique complet.
Sur 450 problèmes Python, le Recall@5 d’Eager était de 0.478, contre 0.470 pour Grep, et son écart de qualité apparié a franchi le seuil de non-infériorité de cinq points.
Dans une cohorte distincte de mesure des ressources, sans mise en cache, Eager a nécessité moins d’appels et affiché un indicateur d’énergie GPU inférieur par tâche tentée. Ensemble, ces résultats étayent l’idée que fournir tôt les éléments de code peut réduire le travail mesuré dans cette configuration.
La méthode de comptabilisation montre aussi que le seul nombre de jetons du prompt ne suffit pas à établir des économies.
Les mesures de qualité et les résultats détaillés sur les ressources pour la localisation proviennent de cohortes distinctes, et l’étude des correctifs utilisait un budget fixe de 32 appels.
Les tests ont porté sur quatre politiques définies à l’avance, sur un seul appareil traitant une requête à la fois ; ils ne permettent pas d’établir les résultats pour le traitement par lots, les GPU dans le cloud ou d’autres politiques.
Ce que montrent les preuves
- Évaluer le travail réellement économisé
L’article présente un protocole de comptabilisation des ressources soumis à un seuil de qualité pour comparer les politiques de contexte des agents de programmation. Il pose la question suivante : des prompts plus courts signifient-ils toujours moins de travail, quand les agents envoient des requêtes répétées et que les serveurs peuvent réutiliser les entrées précédentes ?
Le protocole vérifie la qualité des tâches avant de comparer les coûts en ressources, puis mesure les appels au modèle, le traitement des entrées non mises en cache, l’occupation de la mémoire cache, le temps et un indicateur indirect de l’énergie du GPU.
- Vérifier le seuil de qualité
Pour la localisation, Grep part du seul énoncé du problème, tandis qu’Eager fournit dix extraits de code récupérés avant le premier tour de l’agent ; les deux politiques conservent l’historique complet. La tâche est considérée comme réussie si la fonction ou la classe recherchée figure parmi les cinq blocs de code renvoyés. Sur 450 problèmes Python provenant de dépôts distincts, le score d’Eager était de 0.478, contre 0.470 pour Grep.
Son écart de qualité apparié a franchi le seuil de non-infériorité de cinq points défini par les auteurs.
- Mesurer les coûts de localisation
Les auteurs ont mesuré les ressources sur une cohorte distincte de 100 tâches de localisation, sans mise en cache des préfixes et en comptant les tâches échouées. Dans cette cohorte, Eager a nécessité moins d’appels serveur réussis et affiché un indicateur d’énergie GPU inférieur par tâche tentée à celui de Grep.
Cela étaye l’interprétation selon laquelle, dans cette comparaison, fournir les éléments plus tôt a réduit le travail en évitant certaines recherches. Les mesures de qualité et de coût ne proviennent toutefois pas des mêmes tâches.
- Évaluer la réutilisation et les modifications de l’historique
Deux autres comparaisons montrent pourquoi la longueur du prompt ne suffit pas à évaluer le travail. En gardant Eager fixe, l’activation de la mise en cache des préfixes a laissé le volume logique des prompts statistiquement similaire tout en réduisant fortement le nombre de jetons de préremplissage non mis en cache.
Dans une autre configuration de génération de correctifs, Mask-5 a raccourci les prompts, mais n’a pas franchi le seuil de qualité et a fortement augmenté ce nombre de jetons ainsi que l’énergie GPU mesurée. Ces résultats montrent que la réutilisation et le comportement de l’agent peuvent modifier le lien entre la taille du prompt et le travail réellement effectué.
Détails
- Auteurs de l’article original
- Zhongming Yu, Yitong Ma, Hengjia Yu, Boqin Yuan, Xiangye Lin
- Soumis à arXiv
- Licence
- arXiv non-exclusive