DeltaSelect : organiser des tests A/B abordables pour les agents de codage

Pourquoi les benchmarks complets sont difficiles à répéter

Une équipe qui développe un agent de codage change régulièrement ses instructions, ses skills, son niveau de raisonnement, son modèle ou son orchestration. Elle veut savoir si une configuration candidate est meilleure que la configuration de référence, moins chère, plus rapide ou plus fiable. Un benchmark complet peut répondre à cette question, mais son coût et sa durée rendent son exécution après chaque changement peu réaliste.

Le preprint « DeltaSelect: Affordable A/B Testing for Coding Agents » propose de traiter ce problème comme une décision de développement plutôt que comme un classement général de modèles. L’idée consiste à sélectionner un petit ensemble fixe de tâches dont les résultats suivent suffisamment bien ceux d’une suite plus large, puis à exécuter ces tâches dans un budget défini. La méthode conserve aussi une partie de l’information graduelle produite par les vérificateurs au lieu de réduire chaque exécution à un simple succès ou échec.

Cette distinction est essentielle pour un produit SaaS. Une équipe qui veut choisir le meilleur modèle du marché n’a pas le même besoin qu’une équipe qui veut comparer deux versions de son agent sur une semaine de développement. DeltaSelect vise le second cas : une mesure répétable, ciblée et assez économique pour accompagner les itérations.

Le constat de départ

Les auteurs commencent par analyser des essais publiés de DeepSWE. Dans cette analyse de rééchantillonnage, seuls 22 des 113 problèmes, soit 19,5 %, atteignent un cinquième percentile de corrélation de Pearson d’au moins 0,50 avec la performance du benchmark complet. Autrement dit, la plupart des tâches prises isolément sont trop variables pour servir de proxy fiable dans une comparaison réalisée une seule fois.

Ce résultat ne signifie pas que les autres tâches sont inutiles. Une tâche peut révéler une capacité rare ou un échec important tout en étant un mauvais indicateur de la performance globale. DeltaSelect cherche une propriété plus étroite : quelles tâches peuvent aider à distinguer une configuration de référence d’une configuration candidate dans un cycle de développement donné ?

Le choix des tâches doit donc être compris comme un instrument de mesure, pas comme une nouvelle définition de la capacité d’un agent. La suite courte sert à prendre une décision locale. Elle ne remplace pas une évaluation plus large lorsque l’enjeu est une publication, une comparaison de modèles ou une mise en production sensible.

Les trois briques de DeltaSelect

La méthode décrite par Nicholas J. Conn assemble trois opérations : classer les tâches, construire un score comparable et sélectionner une suite sous contrainte de coût.

La première opération utilise des résultats répétés pour estimer quelles tâches suivent le mieux la performance de la suite complète. Le classement est conçu de façon conservatrice : une tâche ne doit pas seulement avoir une corrélation moyenne favorable, elle doit rester suffisamment informative dans une estimation prudente. La méthode vise ainsi à éviter qu’une tâche qui a eu un comportement chanceux dans quelques essais domine la sélection.

La deuxième opération concerne le score. Les vérificateurs de tâches peuvent fournir plus qu’un booléen. Dans l’exemple étudié, les traces contiennent notamment la fraction de tests nouvellement échoués qui passent ensuite, appelée F2P. DeltaSelect utilise cette information graduelle et une régression linéaire pour mapper des résultats hétérogènes vers une échelle commune. La sélection des tâches et la construction du score sont séparées : la transformation du score ne doit pas changer le classement des tâches.

La troisième opération choisit un ensemble fixe dans un budget exprimé en dollars. La suite retenue doit rester identique entre la configuration de référence et la configuration candidate, afin que la différence observée ne provienne pas d’un changement de périmètre. L’ordre d’exécution et le budget doivent être définis avant de regarder les résultats de la comparaison.

Un protocole pratique

Pour adapter l’idée à un agent SaaS, commencez par définir la décision à prendre. S’agit-il de comparer deux prompts, deux versions d’un outil de récupération, deux politiques de délégation ou deux modèles ? Définissez ensuite le résultat prioritaire : réussite, coût, délai, couverture des tests ou compromis entre ces dimensions. Sans cette étape, une suite courte peut être optimisée pour un score qui ne correspond pas au besoin produit.

Construisez ensuite une population historique de tâches avec des traces et des résultats répétés. Les tâches doivent être suffisamment représentatives du produit : correction de bugs, ajout de fonctionnalités, modification de tests, mise à jour de dépendances ou changement de configuration. Évitez de mélanger sans distinction des tâches dont les vérificateurs, les dépôts ou les environnements n’ont pas la même signification.

À partir de cette population, estimez la stabilité de chaque tâche. Utilisez le classement conservateur décrit dans le preprint ou une variante documentée qui garde le même objectif. Retenez un ensemble fixe compatible avec le budget. Conservez les identifiants, les versions des dépôts, les vérificateurs et les sommes de contrôle nécessaires pour pouvoir réexécuter exactement le protocole.

Enfin, exécutez la configuration de référence et la candidate dans le même environnement. Enregistrez le score gradué, le résultat binaire si disponible, le coût, le nombre d’appels et les artefacts produits. Une comparaison utile ne devrait pas seulement dire « B a gagné » : elle doit permettre de voir si B a gagné sur le score, le coût, la stabilité ou un sous-ensemble de tâches.

Le cas d’étude rapporté

Le preprint décrit un cas d’utilisation pendant la révision de skills et d’instructions d’un agent. Treize évaluations ont été conduites avec une suite fixe de huit tâches. La configuration initiale obtient un score calibré de 36,46 % pour un coût enregistré de 4,18 dollars. La configuration adoptée atteint 42,36 % pour 1,75 dollar. La baisse de coût rapportée est de 58,1 %, soit 2,43 dollars sur l’évaluation complète, et le nombre brut de contrôles F2P passe de 251 sur 411 à 265 sur 411.

Ces nombres ne doivent pas être résumés comme une preuve que les instructions ont amélioré de manière statistiquement établie la capacité générale de l’agent. Le test de score présenté par les auteurs donne une valeur p de 0,326 avec une variance transférée depuis une configuration publiée. Le mouvement du score est favorable dans ce cas, mais l’étude ne l’établit pas comme un gain de population, une équivalence ou une non-infériorité. Le résultat le plus net du cas d’étude est la réduction du coût enregistré, tandis que l’interprétation de la qualité reste prudente.

Le même cas montre pourquoi un benchmark publié ne se transfère pas automatiquement à un autre harnais. Sur huit tâches identiques, les résultats observés avec le harnais Codex diffèrent des estimations publiées avec mini-swe-agent. Les coûts mesurés dans l’environnement Codex sont entre 1,5 et 3,5 fois les estimations publiées selon le niveau de raisonnement rapporté. La première mesure utile pour une équipe est donc une base dans le harnais cible, et non un prix théorique copié depuis un autre protocole.

Lire les variations sans surinterpréter

Une suite courte réduit le coût, mais elle augmente la sensibilité aux tâches sélectionnées. Une configuration candidate peut gagner parce qu’elle traite mieux les dépôts représentés dans la suite et perdre sur une capacité absente. De même, un écart favorable sur une seule exécution peut venir de la variance d’un agent non déterministe.

Le guide d’utilisation doit donc prévoir une règle pour les résultats surprenants. Une répétition peut servir de diagnostic lorsqu’une exécution contredit fortement l’historique, mais répéter systématiquement toutes les tâches jusqu’à obtenir une conclusion stable annule une partie de l’économie recherchée. Il faut aussi distinguer l’amélioration du score et la réduction du coût : une configuration moins chère avec un score plus faible peut être acceptable pour un usage exploratoire, mais pas pour un workflow de livraison.

Les journaux doivent être conservés avec les artefacts. Si une modification de prompt augmente le score, l’équipe doit pouvoir vérifier quelles tâches ont changé, quels appels ont été économisés et si l’agent a simplement cessé de faire une étape de contrôle. Les résultats agrégés sont utiles pour une décision, mais les traces sont nécessaires pour comprendre le mécanisme.

Les garde-fous de benchmark

DeltaSelect ne peut pas réparer une suite de tâches défectueuse. Les auteurs soulignent qu’un petit ensemble amplifie l’effet d’une tâche mal construite. Il faut donc vérifier la disponibilité des dépôts, les dépendances, les tests, les versions de l’environnement et les règles du vérificateur avant de calculer un score. Un échec d’installation ne doit pas être confondu avec une incapacité de l’agent.

La répétition d’une même suite peut aussi spécialiser l’agent. Un système pourrait apprendre les dépôts ou les vérificateurs sélectionnés sans progresser sur les tâches voisines. Pour limiter ce risque, gardez une évaluation de contrôle séparée, non utilisée pour choisir les tâches ni pour ajuster les instructions. Faites varier périodiquement la suite de développement, tout en conservant un historique permettant de relier les décisions.

Il faut également documenter les changements testés. Si une évaluation modifie à la fois les outils, le modèle, les instructions et le niveau de raisonnement, l’écart obtenu ne peut pas être attribué à une seule décision. Une suite abordable ne dispense pas d’un contrôle des variables ; elle rend seulement possible un plus grand nombre de comparaisons.

Ce que la méthode ne promet pas

Le preprint ne montre pas que son sélecteur est toujours meilleur qu’un tirage aléatoire, qu’une sélection par coût minimal ou qu’un autre classement à budget égal. Il ne montre pas non plus qu’une petite suite mesure toutes les capacités d’un agent. La calibration linéaire peut être moins adaptée près des bornes du score, et les tâches apparentées peuvent violer des hypothèses d’indépendance utilisées pour l’incertitude.

Les résultats publiés utilisés pour établir le classement proviennent d’un même instantané de données. Ils peuvent donc donner une estimation optimiste de la relation entre tâches et benchmark complet. Les coûts et les scores varient aussi selon le modèle, le harnais, les outils, les niveaux de raisonnement et l’environnement. Une suite sélectionnée pour un produit ne doit pas être réutilisée comme classement universel sans nouvelle validation.

Enfin, le document est un preprint ArXiv. Il s’agit d’un résultat de recherche mis à disposition, pas d’une norme de mesure ni d’une certification de performance. Les valeurs et conclusions doivent être attribuées au protocole présenté par l’auteur et reproduites dans l’environnement qui intéresse l’équipe.

Une place raisonnable dans un cycle SaaS

DeltaSelect peut prendre place entre deux niveaux d’évaluation. Au quotidien, une suite fixe et économique aide à détecter les régressions de coût, les gains de score et les changements de comportement. À intervalles plus espacés, une suite plus large vérifie que l’optimisation locale ne masque pas une perte sur d’autres capacités. Avant une décision importante, des tests ciblés peuvent compléter la mesure : sécurité des outils, respect du périmètre, qualité des modifications et robustesse des reprises.

Le bénéfice attendu n’est pas de transformer chaque commit en publication scientifique. Il est de rendre les décisions d’ingénierie plus observables. Une équipe peut dire : cette version coûte moins cher sur les tâches sélectionnées, son score gradué ne montre pas de régression dans le protocole, et une évaluation de contrôle reste à effectuer. Cette formulation est plus utile qu’un classement définitif obtenu sur huit tâches.

La méthode invite aussi à regarder l’agent comme un système. Le coût peut venir du modèle, mais aussi des revues répétées, des appels de récupération, des boucles de reprise ou d’un harnais qui ne sait pas terminer. Une comparaison A/B abordable devient alors un outil de diagnostic : elle mesure le résultat final tout en fournissant des traces permettant de chercher où se trouve le travail inutile.

Checklist de mise en œuvre

Avant chaque campagne, vérifiez le périmètre de la décision, la version de l’agent, le modèle, le niveau de raisonnement, les outils, l’environnement et le budget. Fixez la suite et ses vérificateurs avant de lancer la comparaison. Enregistrez les scores gradués, les résultats binaires, le coût, les appels, les échecs d’installation et les artefacts.

Après la campagne, examinez les résultats tâche par tâche. Cherchez les coûts déplacés, les tâches qui dominent la moyenne et les changements qui augmentent le score en supprimant une étape de validation. Comparez la candidate à une suite de contrôle lorsque l’enjeu le justifie. Conservez enfin la décision, son incertitude et la condition qui déclenchera une évaluation plus large.

Cette discipline respecte l’intention de DeltaSelect : mesurer souvent, à coût raisonnable, une décision de développement précise. Elle évite en même temps de confondre un instrument de comparaison locale avec une preuve de capacité générale.

Sources

Nicholas J. Conn, « DeltaSelect: Affordable A/B Testing for Coding Agents », ArXiv 2609.19607v1, consulté le 21 septembre 2026 : résumé et preprint, PDF.