Coût dans SWE-bench : comment calculer le prix par incident résolu sans masquer les échecs, les nouvelles tentatives ni l’évaluation

Le chiffre trompeur : le prix par incident résolu ne s’explique pas à lui seul

Présenter le résultat d’un agent comme un « coût par incident résolu » semble transformer une évaluation technique en décision économique simple. Pourtant, ce chiffre est un rapport entre des variables qui peuvent avoir été définies de façons très différentes. Le numérateur peut ne contenir que les tokens d’un appel final, ou bien l’ensemble des appels initiés au cours d’une trajectoire. Le dénominateur peut être le nombre de correctifs qui passent le vérificateur, le nombre d’incidents initialement sélectionnés ou un résultat choisi parmi plusieurs tentatives. Sans ces définitions, deux chiffres identiques ne décrivent pas nécessairement des opérations comparables.

La distinction est particulièrement importante dans SWE-bench. La tâche part d’incidents réels associés à des dépôts et exige de produire une modification qui puisse être vérifiée dans un environnement préparé à cet effet. Le coût observable ne se limite donc pas à rédiger un correctif. Un système peut inspecter des fichiers, demander du contexte supplémentaire, exécuter des outils, relancer une stratégie ou épuiser une limite sans produire de solution valide. Tous ces événements peuvent consommer des ressources, même si l’instance ne compte pas comme résolue.

La bonne question économique dépend de la décision à prendre. Pour budgéter une exécution complète, le coût moyen par incident tenté est pertinent. Pour évaluer le rendement d’un flux qui ne livre que des modifications vérifiées, il peut être utile de rapporter le coût total aux succès stricts. Pour décider si une configuration plus coûteuse en vaut la peine, la comparaison pertinente est souvent le coût supplémentaire par succès supplémentaire par rapport à une référence. Et si plusieurs trajectoires sont autorisées et qu’une seule est conservée, il faut mesurer le coût de toute la politique, non celui de la seule trajectoire sélectionnée.

Cela ne signifie pas qu’une métrique résumée est inutile. Cela signifie qu’elle doit être lue comme la couverture d’une fiche de coûts. Cette fiche doit indiquer la version du jeu de données, le sous-ensemble effectivement exécuté, les exclusions, le nombre de tentatives, la règle de sélection, le protocole d’arrêt, les catégories de consommation et la part de l’infrastructure d’évaluation incluse. Sans ces éléments, le chiffre peut être une observation interne valide, mais pas une base suffisante pour comparer des agents ou estimer une automatisation.

Ce qui est payé lors d’une exécution

La première composante est l’inférence. Dans une API, le relevé de consommation doit séparer les tokens d’entrée et de sortie lorsque le fournisseur les facture différemment. Si la plateforme renseigne des entrées mises en cache ou des tokens de raisonnement facturables, ces catégories doivent également apparaître séparément. La documentation d’OpenAI, applicable uniquement aux systèmes utilisant cette API, distingue ces catégories et indique que demander plusieurs complétions consomme des tokens additionnels. Cette terminologie, comme sa structure tarifaire, ne doit pas être extrapolée automatiquement à d’autres fournisseurs.

La deuxième composante concerne les appels auxiliaires et les outils. Un agent peut effectuer des recherches, résumer des fichiers, générer des tests, examiner des diffs ou demander de nouvelles complétions après avoir exécuté des commandes. Certains outils n’ont pas de prix d’API direct, mais augmentent le contexte des appels ultérieurs ou utilisent leur propre calcul. Si un outil externe facture à l’usage, il doit figurer comme poste séparé. Si aucun coût monétaire ne lui est attribué, son nombre d’invocations et les ressources qu’il consomme doivent au moins être enregistrés afin qu’une autre organisation puisse les valoriser selon son propre tarif.

La troisième composante est l’évaluation. Le harnais SWE-bench prépare des images Docker, applique des correctifs et exécute des tests avec des limites de temps par instance. Sa documentation prévoit aussi des exigences de CPU, de mémoire, de stockage et des mécanismes de cache. Construire ou récupérer des images, exécuter des conteneurs et conserver des artefacts peut représenter un coût significatif, particulièrement dans de vastes campagnes, même s’il ne s’agit pas d’un coût d’inférence. Les mélanger sans détail empêche de savoir si une amélioration provient de l’agent ou de l’infrastructure ; les omettre d’un budget opérationnel peut sous-estimer la dépense réelle.

Il est également utile de distinguer le coût amorti du coût marginal. Préparer une image partagée pour de nombreuses instances ne coûte pas la même chose par exécution que de la reconstruire à partir de zéro. De même, un cache de résultats peut éviter du travail ultérieur. Ces gains d’efficacité sont légitimes s’ils sont documentés, mais ils ne doivent pas être présentés comme si chaque incident avait exigé la même dépense marginale. Une fiche solide expose les deux niveaux : le coût de la campagne observée et les règles utilisées pour attribuer les coûts partagés.

Quatre dénominateurs pour quatre questions différentes

La première métrique est le coût moyen par incident tenté : le coût total de la campagne divisé par tous les incidents pour lesquels le protocole a été lancé. C’est la mesure la plus appropriée pour estimer la dépense liée au traitement d’une file de travail similaire, car elle inclut les succès, les échecs, les trajectoires invalides et les cas ayant épuisé leurs limites. Il faut préciser si un incident exclu avant le lancement de l’agent fait ou non partie de l’univers. Une exclusion après l’exécution ne devrait pas effacer son coût.

La deuxième métrique est le coût par succès strict : le coût total des trajectoires incluses dans la politique divisé par le nombre d’incidents dont le correctif passe le processus de vérification défini. Elle décrit la dépense nécessaire, en moyenne, pour obtenir un résultat validé selon ce protocole. Elle peut augmenter même si le coût par tentative diminue, lorsque le taux de résolution baisse ; elle ne doit donc pas être publiée sans les deux quantités de base.

La troisième est le coût incrémental pour augmenter la résolution. Si une configuration B résout davantage d’incidents qu’une configuration A, il se calcule comme la différence de coût total entre B et A divisée par la différence de succès. Ce rapport répond à une décision marginale : combien coûte chaque succès additionnel obtenu grâce à une configuration plus ambitieuse. Il n’est interprétable que si les deux systèmes sont exécutés sur le même ensemble, avec des critères de succès et des ressources d’évaluation équivalents.

La quatrième concerne les politiques qui prévoient plusieurs tentatives par incident. Si pass@k, des nouvelles tentatives ou une sélection ultérieure sont autorisés, le coût doit sommer les trajectoires générées pour chaque incident, y compris celles qui ne sont pas retenues. Rapporter le coût de la meilleure trajectoire trouvée revient à rapporter un résultat conditionnel qui ne reproduit pas la dépense nécessaire pour la trouver. La publication doit préciser si une seule trajectoire a été exécutée par instance, plusieurs trajectoires indépendantes ou un arbre de décision adaptatif.

Le protocole modifie la facture et la signification du résultat

Une limite de nombre d’étapes, de temps, d’appels ou de budget monétaire fait partie de l’intervention évaluée. L’augmenter peut permettre à certains incidents difficiles de bénéficier de plus d’exploration, mais peut aussi concentrer une part importante de la dépense dans une longue traîne de cas non résolus. C’est pourquoi, en plus de la moyenne, il est souhaitable de publier la médiane, les percentiles et la distribution par instance. Une moyenne faible peut coexister avec quelques cas exceptionnellement coûteux, inacceptables en production.

La politique d’arrêt doit être explicite. Une exécution peut s’arrêter après l’obtention d’un correctif, lorsqu’aucun fichier pertinent n’est trouvé, après dépassement d’un budget, à la suite de tests échoués ou après un certain nombre d’itérations. Chaque option modifie à la fois le coût et la probabilité de succès. Les nouvelles tentatives exigent la même précision : il faut indiquer ce qui les déclenche, si elles héritent du contexte, si elles réutilisent un cache et si les tentatives écartées sont comptabilisées. Appeler « une tentative » une séquence de redémarrages internes peut masquer une différence de consommation substantielle.

Pass@1 et pass@k répondent à des questions différentes. Pass@1 se rapproche de la performance d’une occasion unique dans une configuration fixée. Pass@k décrit la possibilité qu’au moins une de plusieurs occasions produise un succès, mais il ne correspond pas au coût d’une seule occasion. Lorsqu’il existe une sélection ultérieure, il faut documenter le signal employé pour sélectionner, si cette sélection a consommé du modèle ou du calcul supplémentaire et si elle a eu accès aux résultats de tests. Une sélection informée par le vérificateur peut être utile à la recherche, mais ne doit pas être confondue avec une politique disponible avant vérification.

La comparaison la plus informative fixe généralement des contraintes communes : même ensemble d’instances, même harnais, mêmes limites d’évaluation et, lorsque l’objectif est économique, un budget maximal comparable par incident. Des courbes coût-résolution peuvent ensuite être affichées. Cette présentation montre si le gain de résolution apparaît à un coût graduel ou dépend d’une minorité de trajectoires très coûteuses. Elle évite aussi d’attribuer à la qualité de l’agent ce qui peut provenir du fait qu’il a été autorisé à dépenser davantage.

Inférence et évaluation : les séparer ne signifie pas ignorer l’une ou l’autre

Séparer l’inférence et l’évaluation permet de répondre à deux questions qu’un chiffre unique mélange. La première est le coût pour l’agent de proposer une modification. La seconde est le coût pour déterminer si cette modification passe le protocole du benchmark. Dans SWE-bench, l’évaluation exige d’appliquer la prédiction et d’exécuter des tests dans un environnement de dépôt. Le harnais documente la préparation d’images, l’exécution avec des conteneurs, les limites temporelles et des options de cache ; traiter la vérification comme une opération gratuite serait donc méthodologiquement incomplet.

Cette séparation n’oblige pas à adopter une convention unique. Pour la recherche sur les modèles, il peut être raisonnable de présenter d’abord le coût d’inférence puis, à côté, le coût d’évaluation de la campagne. Pour planifier un service de réparation automatisée, le coût total de possession est plus pertinent : inférence, orchestration, outils, calcul des tests, stockage et revue humaine lorsqu’elle fait partie du flux. L’essentiel est de ne pas additionner certains postes pour un agent tout en les omettant pour un autre.

Une incertitude pratique demeure : les coûts d’infrastructure dépendent de la région, du fournisseur, de la capacité réservée, de la concurrence et de la politique de rétention. Les sources disponibles décrivent les composants du harnais, mais n’établissent pas un tarif universel pour les exécuter. Une publication rigoureuse doit donc fournir des unités physiques, telles que le temps de conteneur et les ressources allouées, en plus de toute conversion monétaire locale. Une autre organisation pourra ainsi recalculer le montant à partir de ses propres contrats.

Les artefacts d’expérimentation sont essentiels à cette séparation. Le dépôt d’expériences de SWE-bench prévoit des prédictions, des journaux d’exécution, des traces et des résultats par instance. Partager ou résumer ces artefacts dans une structure cohérente permet de vérifier quels correctifs ont été évalués, de détecter les instances sans résultat et de rapprocher les totaux de coût des trajectoires. L’auditabilité n’exige pas de révéler des identifiants, des prompts confidentiels ou des données protégées ; elle exige que les exclusions et les agrégations n’empêchent pas l’examen de la comptabilité.

La fiche minimale de publication et la décision opérationnelle

La fiche devrait commencer par l’identité de l’expérience : variante et révision du jeu de données, nombre d’instances éligibles, tentées et exclues, avec les motifs d’exclusion. C’est important car SWE-bench propose plusieurs variantes et la documentation du projet identifie SWE-bench Verified comme un ensemble de 500 instances. Nommer seulement « SWE-bench » ne suffit pas à savoir quelle population a été évaluée. Il faut également conserver l’identifiant du harnais, les images ou la configuration pertinente, ainsi que les règles de vérification.

La fiche doit ensuite indiquer le modèle, le fournisseur ou l’endpoint, la région si elle modifie le prix, la date de consultation des prix et la devise. La comptabilité doit montrer les tokens d’entrée, de sortie, de cache et de raisonnement lorsque ces catégories existent pour le fournisseur utilisé, ainsi que les appels auxiliaires. Elle doit inclure la limite par incident, la politique d’arrêt, les nouvelles tentatives et la méthode de sélection. Les moyennes doivent être accompagnées d’une distribution par instance et de décomptes de trajectoires échouées, épuisées, invalides ou non vérifiables.

La fiche se termine par deux totaux : inférence et évaluation. Pour chacun, elle doit préciser les postes inclus, les exclusions et la façon dont les coûts partagés sont attribués. Si un chiffre par succès est publié, le total du numérateur doit pouvoir être rapproché des postes précédents et le dénominateur des succès stricts observés. S’il existe plusieurs échantillons par instance, le coût communiqué doit être celui de leur génération et de la sélection parmi eux, non celui du seul échantillon gagnant.

Pour explorer des modèles à un stade précoce, le coût par incident tenté et une courbe de résolution sous budgets fixes sont souvent les métriques les plus utiles. Pour optimiser un agent, il convient d’ajouter le coût incrémental par succès additionnel et la distribution des cas coûteux. Pour budgéter une automatisation, la référence est le coût total de possession par incident entrant, y compris la vérification et l’intervention humaine réellement requise par le processus. Aucune de ces mesures ne remplace les autres : chacune répond à un risque différent.

La conclusion prudente est qu’un agent ne réduit pas nécessairement le coût de résolution des incidents parce qu’il atteint un taux de résolution supérieur ou affiche un montant faible associé à ses succès. Il peut déplacer la dépense vers plus de trajectoires, plus de contexte, plus de calcul de tests ou une sélection ultérieure. Une comparaison défendable déclare ce déplacement. Avec une fiche complète, une équipe peut décider si elle paie pour davantage de succès, si elle limite son exposition aux cas coûteux ou si elle adopte une configuration offrant une économie plus prévisible.

Poursuivre l’exploration

Corrections et transparence

Si vous repérez une information incorrecte ou obsolète, envoyez-nous la page et la source à vérifier.