FR
Des tests révèlent les lacunes des modèles qui construisent le logiciel des agents
Doc2Harness: Benchmarking LLMs on Long-Horizon Harness Engineering of Coding Agents · arXiv:2610.20344
En termes simples
Doc2Harness vérifie si un modèle de langage peut construire le logiciel qui entoure un agent de programmation. Ce logiciel, appelé environnement ou « harness », gère les outils, les autorisations, l’état enregistré d’une session et la reprise après une erreur.
Le modèle construit un candidat, puis un modèle fictif piloté par un script le met à l’épreuve dans des sessions de test. Dans l’étude portant sur 19 modèles, même celui qui obtient le meilleur score a vu ses environnements échouer à de nombreux tests comportementaux en moyenne sur trois constructions.
La mesure porte sur le comportement du logiciel construit, pas sur la réussite de vraies tâches de programmation.
La recherche
Quand les tests d’agents de programmation gardent fixe le logiciel qui les entoure, une question concrète reste sans réponse : un modèle peut-il bien construire ce logiciel ? L’environnement gère les outils, le contexte, les autorisations, l’état des sessions et la reprise après erreur, autant d’éléments qui façonnent ce que l’agent peut faire. Doc2Harness rend cette capacité de construction mesurable.
Doc2Harness évalue en deux étapes la construction d’environnements pour agents de programmation par des modèles, puis mesure la proportion de tests comportementaux réussis par chaque construction figée lors de sessions scriptées.
Chaque modèle a construit trois candidats à partir d’un document de développement et d’un squelette contenant uniquement les interfaces. Un modèle scripté a piloté chaque candidat figé dans des sessions de test, et des assertions en ont vérifié le comportement. Le taux de réussite désigne la proportion de cas réussis, hors contrôles positifs.
Sur les 328 cas et les trois constructions de chacun des 19 modèles, les candidats de GPT-6 Astra atteignent un taux moyen de 53,05 %, contre 27,44 % pour ceux de Hy3.
Cette dispersion, avec des échecs même pour le modèle en tête, étaye la conclusion des auteurs : la suite différenciait les modèles évalués sans atteindre un plafond de scores.
Les candidats ont été figés après une vérification de forme seulement. Les scores ne montrent donc pas si les modèles auraient pu améliorer un environnement en s’appuyant sur des retours sur son comportement.
Les tests étaient pilotés par un modèle fictif scripté : ils ne mesurent pas la réussite sur de véritables tâches de programmation.
Ce que montrent les preuves
- Une capacité de construction peu évaluée
Doc2Harness est un benchmark en deux étapes qui évalue si de grands modèles de langage peuvent construire le logiciel entourant les agents de programmation. Le score correspond à la proportion de tests comportementaux réussis par chaque environnement construit ; c’est une mesure indirecte de la capacité de construction du modèle.
Les tests existants sur les agents gardent généralement ce logiciel fixe et mesurent l’accomplissement des tâches, sans évaluer cette capacité de construction.
- Construire à partir d’un document de comportement
Pendant la construction, un modèle travaille dans un dispositif fixe et reçoit un document de développement décrivant le comportement attendu, ainsi qu’un squelette de départ qui contient les interfaces mais aucune mise en œuvre.
Il écrit un candidat complet dans un conteneur isolé. Une vérification de forme confirme que le candidat compile et s’installe, possède les commandes et interfaces requises et ne contient pas de blocs de remplacement ; elle ne lance pas de tests comportementaux. Tout candidat qui la réussit est figé.
- Tester des sessions scriptées complètes
À la deuxième étape, un modèle fictif scripté fait passer chaque environnement figé par une session complète pour chaque cas de test. Des assertions inspectent les requêtes envoyées au modèle, les fichiers présents sur le disque, le code de sortie du processus et la sortie des commandes.
Certains cas comportent des contrôles positifs qui vérifient si le comportement et ses effets sont observables. L’échec d’un contrôle entraîne celui du cas, et les contrôles ne comptent pas dans le dénominateur du taux de réussite.
- Les scores révèlent de grands écarts
Les auteurs ont évalué 19 modèles de pointe issus de 11 fournisseurs, en construisant trois candidats indépendants par modèle et en les notant sur 328 cas de test. Le taux de réussite correspond à la proportion de cas réussis, les contrôles positifs étant exclus du dénominateur ; pour chaque modèle, le taux est la moyenne des trois constructions.
GPT-6 Astra arrive en tête avec 53,05 %, contre 27,44 % pour Hy3 : même les candidats du mieux classé échouent à près de la moitié des cas. Cette dispersion indique que la suite pouvait différencier les modèles évalués sans atteindre un plafond de scores.
- Le classement général masque des variations
Le classement général ne se retrouve pas dans toutes les parties de la suite. Dans les six grandes catégories, qui comptent chacune au moins 20 cas, les rangs des modèles varient jusqu’à 16 places.
GPT-6 Astra mène quatre catégories ; Grok 4.7 et Qwen3.8 Max mènent chacune l’une des deux autres. Comme les catégories reposent sur des cas différents et sont de tailles différentes, ces variations nuancent le classement général sans isoler les capacités propres à chaque catégorie.
- Davantage de modules vont de pair avec des scores plus faibles
Une analyse distincte du code source porte sur les 57 environnements candidats notés. Après prise en compte statistique du nombre de lignes de code, les auteurs relèvent une corrélation partielle de −0,423 entre le nombre de modules et le taux de réussite.
En répétant l’analyse en retirant chaque modèle à tour de rôle, l’association reste négative, entre −0,484 et −0,309. Dans cet ensemble, un plus grand nombre de modules tend à accompagner des scores plus faibles, mais l’analyse ne montre pas que le nombre de modules est à l’origine de cette différence.
Détails
- Auteurs de l’article original
- Yuyao Ge, Shenghua Liu, Peizhong Gao, Chendi Ge, Chenxu Liu
- Soumis à arXiv
- Licence
- CC BY 4.0