GPT-5.5 low vs medium vs high vs xhigh : la courbe de raisonnement observée sur 26 tâches réelles dans un dépôt open source

 (reddit.com)
5 points par GN⁺ 8 시간 전 | 1 commentaires | Partager sur WhatsApp
  • En exécutant GPT-5.5 Codex sur 26 tâches réelles de GraphQL-go-tools avec les réglages low, medium, high, xhigh, l’écart d’effort de raisonnement apparaît bien plus nettement dans l’équivalence sémantique avec les patchs humains et le taux d’acceptation en code review que dans le simple passage des tests
  • Le passage des tests était de 21/26 pour low, 21/26 pour medium, 25/26 pour high et 24/26 pour xhigh, mais l’équivalence sémantique est montée de 4/26 → 11/26 → 18/26 → 23/26, et l’acceptation en code review de 3/26 → 5/26 → 10/26 → 18/26
  • high améliore par rapport à medium le passage des tests, l’équivalence et la validation en review, tandis que le coût moyen passe de $3.13 à $4.49, soit 1,43x, ce qui en fait le réglage par défaut le plus pratique sur ce dataset
  • xhigh augmente fortement l’équivalence et la qualité en review par rapport à high, mais le coût moyen grimpe à $9.77 et le temps d’exécution moyen à 753.3 secondes, avec aussi davantage de modifications sur les tests, les fixtures et les expected outputs, ce qui accroît le risque lié au footprint
  • L’effet de l’effort de raisonnement n’est pas monotone selon les tâches : il arrive que high fasse mieux que xhigh, ou que des réglages élevés produisent des implémentations plausibles mais incorrectes ; les équipes doivent donc mesurer sur leur propre harness et leurs propres tâches, plutôt que sur des benchmarks globaux

Objectif de l’expérience et méthode d’évaluation

  • GPT-5.5 Codex a été exécuté sur 26 tâches d’un même dépôt open source avec les niveaux d’effort de raisonnement low, medium, high, xhigh, afin de comparer non seulement le passage des tests, mais aussi l’équivalence sémantique avec les PR fusionnées par des humains et la probabilité de passer une review
  • Le dépôt ciblé est GraphQL-go-tools, basé sur Go, et chaque tâche est dérivée d’une PR ou d’un commit réellement fusionné
  • Chaque tâche se compose d’un snapshot figé du dépôt, d’un prompt de demande de modification, et d’une tentative unique de génération de patch dans un conteneur Docker
  • Stet applique le patch généré et exécute les tests propres à la tâche dans un conteneur isolé pour vérifier s’ils passent
  • Après les tests, une évaluation supplémentaire est effectuée selon les critères suivants
    • Équivalence : le patch candidat réalise-t-il le même changement de comportement que le patch humain d’origine ?
    • Passage en code review : un reviewer l’accepterait-il au regard de la justesse, du risque d’introduire des bugs, de la maintenabilité et des edge cases ?
    • Risque de footprint : combien de code supplémentaire l’agent a-t-il touché par rapport au patch humain ?
    • Rubrique craftsmanship / discipline : clarté, simplicité, cohérence, intentionnalité, robustesse, respect des consignes, discipline de périmètre et minimalité du diff
  • Tous les modèles ont été exécutés une fois par tâche, avec un seed unique
  • Le modèle LLM chargé du jugement était GPT-5.4, et l’évaluateur ne voyait que les patchs et la tâche, sans savoir quel modèle ni quel réglage de raisonnement avait produit le patch
  • Des exemples représentatifs ont aussi été vérifiés manuellement, mais il n’y a pas eu d’étalonnage humain séparé sur cet ensemble de tâches ; il faut donc faire davantage confiance à la direction des écarts qu’à un score absolu unique
  • Détails d’exécution
    • Modèle : GPT-5.5
    • Harness : Codex 0.128.0
    • Dataset : 26 tâches réelles de GraphQL-go-tools
    • Indicateurs principaux : passage des tests, équivalence sémantique, passage en code review, risque de footprint, évaluation personnalisée craftsmanship / discipline, coût et temps d’exécution
  • Des graphiques interactifs et une analyse détaillée tâche par tâche sont disponibles sur https://stet.sh/blog/gpt-55-codex-graphql-reasoning-curve
  • La même évaluation est aussi utilisée dans une boucle de recherche automatisée pour améliorer AGENTS.md
    • L’agent produit une proposition d’amélioration de AGENTS.md pour le dépôt, exécute les tâches passées avec Stet, puis itère en identifiant ce qui s’est amélioré ou dégradé

Indicateurs globaux et interprétation

  • Les indicateurs globaux montrent que plus l’effort de raisonnement augmente, plus l’écart se voit dans l’équivalence sémantique et le taux de passage en review, davantage que dans le passage des tests
  • Résultats clés
    • Passage des tests : low 21/26, medium 21/26, high 25/26, xhigh 24/26
    • Équivalence avec le patch humain : low 4/26, medium 11/26, high 18/26, xhigh 23/26
    • Passage en code review : low 3/26, medium 5/26, high 10/26, xhigh 18/26
    • Moyenne craftsmanship / discipline : low 2.311, medium 2.604, high 2.736, xhigh 3.071
    • Coût moyen par tâche : low $2.65, medium $3.13, high $4.49, xhigh $9.77
    • Temps d’exécution moyen de l’agent : low 286.9 secondes, medium 411.0 secondes, high 579.0 secondes, xhigh 753.3 secondes
  • low et medium sont à égalité à 21/26 sur le passage des tests, mais l’équivalence monte de 4/26 à 11/26, et le passage en review de 3/26 à 5/26
  • Par rapport à medium, high augmente le passage des tests de +15.4%p, l’équivalence de +26.9%p et le passage en review de +19.2%p, ce qui en fait l’amélioration pratique la plus nette
  • Par rapport à high, xhigh recule de -3.8%p sur le passage des tests, mais gagne +19.2%p en équivalence et +30.8%p en passage en review
  • L’effort de raisonnement ne change pas seulement le taux de réussite aux tests ; il modifie aussi le type de patchs produits par Codex
  • Les benchmarks publics répondent souvent à une question binaire de réussite ou d’échec d’une tâche, alors qu’en ingénierie logicielle réelle, il est aussi crucial de savoir si le patch peut être fusionné puis maintenu
  • Terminal-Bench est surtout centré sur des problèmes de code difficiles, SWE-bench verified peut inclure des cas où le modèle connaissait déjà la réponse, et SWE-bench Pro est utile mais reste assez généraliste
  • Ici, la question d’intérêt est : « l’agent a-t-il produit, dans ma codebase, le même type de modification que ce qu’un humain a effectivement fusionné ? » et « aurais-je envie d’assumer la maintenance de ce patch ensuite ? »

De low à medium : du heuristique vers la modélisation du domaine

  • low et medium affichent tous deux 21/26 au passage des tests ; si l’on ne regarde que cela, on pourrait conclure à une égalité
  • Pourtant, medium fait progresser l’équivalence sémantique de 4/26 à 11/26, et la moyenne craftsmanship / discipline de 2.311 à 2.604
  • Dans cette plage, si l’on ne mesure que les tests, on passe à côté de l’essentiel de l’écart lié à l’effort de raisonnement
  • low restait parfois sur des heuristiques ou des implémentations partielles même dans les patchs qui passaient les tests, tandis que medium évoluait vers une meilleure modélisation du dépôt et de la sémantique du domaine
  • Exemple PR #1297
    • Il s’agit d’une tâche de validation des dépendances nullable external @requires dans GraphQL Federation
    • Si un champ required nullable revient à null avec une erreur, cette entité contaminée ne doit pas être transmise aux fetchs downstream qui en dépendent
    • Le cœur du problème n’est pas d’ajouter une simple branche de validation, mais de modéliser des règles subtiles de dépendances de données dans la federation
    • low a passé les tests, mais a traité le matching required-field/error de manière heuristique et a manqué les métadonnées structurées nullable @requires, ce qui le rendait ni équivalent ni acceptable en review
    • medium a suivi les objets contaminés et filtré les entrées des fetchs downstream, ce qui lui a permis de passer l’équivalence et la review, tandis que sa qualité craftsmanship / discipline montait de 1.350 à 3.225
    • high et xhigh sont restés dans une qualité comparable, ce qui montre que cette tâche illustre surtout le gain observé lors du passage de low à medium

high : un point proche d’une valeur par défaut réellement pratique

  • high améliore à la fois le passage des tests, l’équivalence sémantique et la validation en revue par rapport à medium, tout en gardant la hausse de coût importante mais non excessive
  • Comparaison entre high et medium
    • Passage des tests : de 21/26 à 25/26
    • Équivalence : de 11/26 à 18/26
    • Validation en revue de code : de 5/26 à 10/26
    • Risque d’empreinte moyen : de 0.268 à 0.314
    • Moyenne production/discipline : de 2.604 à 2.736
    • Coût moyen par tâche : de $3.13 à $4.49, soit 1.43x
    • Temps d’exécution moyen : de 411.0 s à 579.0 s
  • high semble être le point où les tokens supplémentaires se traduisent en gains réels, avec un taux plus élevé de réussite sur les détails d’intégration
  • Exemple PR #1209
    • Il s’agit d’un travail où la datasource gRPC doit respecter les alias GraphQL dans le JSON de réponse, prévalider les types de message protobuf référencés et mettre à jour la couverture de mapping du chemin de mutation union/interface
    • low et medium ont tous deux passé les tests, mais n’étaient pas équivalents et ont échoué en revue
    • medium a largement traité la sérialisation des alias et la validation des messages manquants, mais a raté la mise à jour du mapping de la mutation createUser et a surchargé JSONPath de sémantique liée aux clés de réponse
    • high a introduit une gestion explicite des clés de réponse/alias et propagé les alias dans la planification et le marshaling JSON, obtenant ainsi le premier passage strict
    • La qualité personnalisée de high est montée à 3.625, ce qui montre qu’il ne s’est pas contenté d’ajouter du code, mais qu’il a visé juste sur les obligations d’intégration
    • xhigh a aussi réussi, mais sans améliorer l’interprétation au niveau de la tâche, et le temps d’exécution de l’agent selon le résumé régénéré était de 790.7s, plus long que les 314.0s de high
  • Exemple PR #1155
    • Il s’agit d’un travail de durcissement de la datasource gRPC incluant la prise en charge des repeated scalar fields, l’évitement de panic sur les messages nuls/invalides, la propagation des status codes gRPC, la désactivation de datasource et la prise en charge du client dynamique
    • low et medium ont passé les tests, mais n’étaient pas équivalents
    • medium a amélioré la robustesse, mais sérialise les repeated fields invalides en tableaux vides, manque le comportement de planification à racine aliasée et laisse subsister un risque sur le cycle de vie du dynamic client
    • high a validé l’équivalence et la revue grâce à une gestion plus sûre des cas nil/invalides, à la propagation des status codes, au comportement de datasource désactivée et à la couverture du fournisseur de dynamic client
    • Sur cette tâche, on observe un renversement où xhigh a passé les tests mais a mal traité la sémantique de datasource désactivée et le comportement des listes invalides, n’était donc pas équivalent et a aussi échoué en revue

xhigh : plus proche d’un mode qualité que d’une valeur par défaut

  • xhigh améliore la qualité sémantique et la qualité en revue par rapport à high, mais ce n’est pas un cas où tout s’améliore simplement en augmentant le réglage
  • Comparaison entre xhigh et high
    • Passage des tests : baisse de 25/26 à 24/26
    • Équivalence : hausse de 18/26 à 23/26
    • Validation en revue de code : hausse de 10/26 à 18/26
    • Risque d’empreinte moyen : hausse de 0.314 à 0.365
    • Moyenne production/discipline : hausse de 2.736 à 3.071
    • Coût moyen par tâche : de $4.49 à $9.77, soit 2.18x
    • Temps d’exécution moyen : de 579.0 s à 753.3 s
  • xhigh tend à couvrir davantage de terrain, à mieux correspondre à l’intention humaine et à produire des modifications plus complètes, mais au prix d’une consommation de tokens bien plus élevée
  • Selon la grille de revue, xhigh obtient une moyenne de 3.365 et une médiane de 3.500, supérieures à la moyenne de 2.817 et à la médiane de 2.750 de high
  • Le fait que la médiane soit elle aussi supérieure à la moyenne suggère que l’amélioration de xhigh ne vient pas seulement d’un ou deux patchs exceptionnels qui tireraient la moyenne vers le haut
  • xhigh est plus complet sur le plan sémantique, mais il touche aussi davantage de code que les patchs écrits par des humains, ce qui augmente le risque d’empreinte
  • Sur 26 tâches, xhigh a ajouté au total 13,144 lignes, réparties entre 5,918 lignes de code d’implémentation et 7,226 lignes de tests, fixtures et sorties attendues
  • Par rapport à high, xhigh a ajouté 2,631 lignes de plus, dont 2,436 dans des fichiers de tests, fixtures et sorties attendues
  • L’augmentation de l’empreinte ne vient pas seulement de l’écriture d’un énorme volume de code de production ; elle tient aussi au fait que xhigh produit davantage de validation et de couverture via les fixtures
  • Mais les modifications de tests, de fixtures et de sorties attendues constituent elles aussi une vraie surface à relire et à maintenir
  • Exemple PR #1076
    • Il s’agit d’une restructuration du traitement des subscriptions pour éviter une race condition sur un mutex partagé
    • Les exigences incluaient des écritures sérialisées par subscription, un contrôle du heartbeat par subscription, une couverture par race detector et une correction de la sémantique de fermeture WebSocket
    • medium a passé les tests, mais n’était pas équivalent et a échoué en revue
    • high a atteint l’équivalence et le respect des consignes, mais a échoué en revue, car la nouvelle file de workers peut bloquer la boucle d’événements globale des subscriptions, l’arrêt peut se figer derrière un worker bloqué, une mise à jour suspendue peut durer indéfiniment, et la désinscription au niveau client saute encore la subscription interne
    • xhigh a été le premier passage strict et a porté la qualité personnalisée à 3.475
    • Cette tâche est le meilleur exemple de fonctionnement de xhigh comme mode qualité achetant un nettoyage des risques de revue sur une tâche fortement centrée sur la concurrence
  • Exemple PR #1308
    • Il s’agit d’implémenter l’objet d’entrée GraphQL @oneOf
    • Il faut ajouter la directive intégrée, l’exposer dans l’introspection, valider les littéraux d’opération et les variables à l’exécution, et améliorer les source locations des variables non définies
    • medium et high ont passé les tests, mais n’étaient pas équivalents et ont échoué en revue, car ils ont raté des sémantiques @oneOf importantes liées aux runtime variables, aux nullable variables, aux payloads null fournis et à la forme de l’introspection
    • xhigh a été le premier passage strict et a enregistré une robustesse de 3.7, un respect des consignes de 4.0 et une qualité personnalisée de 3.525
    • La différence ne tient pas à un simple polish de surface, mais à la couverture des edge cases à travers plusieurs parties du système
  • Exemple PR #1240
    • Il s’agit d’unifier la fusion de sélection de champs dans l’AST GraphQL et la fusion de sélection d’inline fragments dans un seul parcours de normalisation
    • low et high ont obtenu un passage strict
    • xhigh était équivalent selon le critère d’évaluation sémantique, mais a échoué en revue en conservant un sous-passage prioritaire, en modifiant l’ordre de AbstractFieldNormalizer et en laissant un ancien enregistrement de fusion de champs
    • Même un réglage de raisonnement plus élevé peut produire des refactorings plus sophistiqués et plausibles, tout en manquant le comportement d’exécution précis auquel les tests et les reviewers accordent de l’importance

Fabrication·discipline, coûts, limites et conclusion

  • L’évaluation personnalisée de fabrication·discipline, elle aussi, progresse globalement à mesure que l’effort de raisonnement augmente, de façon similaire à la grille de revue
  • Le score all-custom est plus élevé en xhigh, avec une moyenne de 3.071 et une médiane de 3.087, que pour high, avec une moyenne de 2.736 et une médiane de 2.688
  • Les médianes sont également plus élevées à la fois pour la fabrication et la discipline, ce qui suggère que xhigh n’a pas seulement produit quelques exemples exceptionnels, mais a amélioré la qualité globale des patchs
  • Indicateurs moyenne/médiane
    • Agrégat craft : low 2.327 / 2.338, medium 2.618 / 2.525, high 2.781 / 2.787, xhigh 3.126 / 3.100
    • Agrégat discipline : low 2.295 / 2.325, medium 2.590 / 2.588, high 2.691 / 2.688, xhigh 3.015 / 3.013
    • Tous les évaluateurs personnalisés : low 2.311 / 2.338, medium 2.604 / 2.550, high 2.736 / 2.688, xhigh 3.071 / 3.087
  • Interprétation détaillée
    • low est faible en robustesse et en respect des consignes
    • medium améliore significativement ces aspects sans augmenter le total de tests passés
    • high améliore la précision concrète et la robustesse
    • xhigh améliore presque toutes les dimensions, y compris le périmètre et la discipline sur le diff
  • Coût et durée
    • low : coût moyen $2.65, médiane $1.91, durée d’exécution moyenne 286.9s, médiane 294.6s
    • medium : coût moyen $3.13, médiane $2.87, durée d’exécution moyenne 411.0s, médiane 371.8s
    • high : coût moyen $4.49, médiane $3.99, durée d’exécution moyenne 579.0s, médiane 572.9s
    • xhigh : coût moyen $9.77, médiane $6.39, durée d’exécution moyenne 753.3s, médiane 732.7s
  • Les coûts sont asymétriques pour low et surtout pour xhigh, et le coût moyen de xhigh est influencé par quelques tâches particulièrement chères
  • Même en médiane, xhigh est plus coûteux et plus lent que high
  • high coûte environ 1,43 fois plus par tâche que medium, et xhigh coûte environ 2,18 fois plus que high
  • Limites
    • Une seule seed a été utilisée par tâche
    • L’étude ne couvre que 26 tâches réelles de GraphQL-go-tools
    • Le juge LLM était GPT-5.4 ; il voyait les patchs et les tâches, mais pas les labels
    • Il n’y a pas eu de calibration des graders pour cet ensemble de tâches
    • Il ne faut pas y voir un résultat universel statistiquement significatif ni un résultat directement transposable à d’autres dépôts
  • Comparaisons associées
    • Le leaderboard de tâches réelles de Voratiq, bien qu’avec une méthodologie différente, montre une tendance similaire
    • Chez Voratiq, GPT-5.5 xhigh atteint 1994 contre 1807 pour GPT-5.5 high, soit +187 points et +10.3%
    • Le coût est de $4.23 contre $2.52, soit +67.9%, et la durée de 11.9m contre 7.8m, soit +52.6%
    • Dans l’expérience Stet, le passage de high → xhigh est encore plus marqué, avec une équivalence de +19.2%p, un relatif de +27.8%, un passage de revue de code de +30.8%p, un relatif de +80.0%, tandis que l’agrégat fabrication/discipline est similaire à +12.2%
    • Voratiq est un leaderboard de type préférence/sélection sur des travaux en cours, tandis que cette expérience porte sur une seule tranche de dépôt de 26 tâches ; une comparaison directe n’est donc pas possible
  • Conclusion pratique
    • xhigh convient aux tâches ambiguës, couvrant plusieurs domaines, centrées sur la concurrence, ou présentant un risque élevé en revue
    • high semble être, dans ce jeu de données, le réglage le plus pratique comme daily driver par défaut
    • Les réglages medium ou inférieurs conviennent lorsque le coût compte davantage et que les tâches sont routinières ou bien définies
    • L’effet de l’effort de raisonnement n’est ni fluide ni monotone selon les tâches ; il arrive que high surpasse xhigh, ou qu’un réglage plus élevé produise une implémentation plausible mais erronée
    • Les équipes devraient mesurer sur leur propre harness et leurs propres tâches, plutôt que de recopier les valeurs par défaut d’un benchmark global
  • Divulgation
    • Ils développent Stet.sh et ont exécuté l’expérience avec cet outil d’évaluation local
    • Dans la version produit, l’agent de code crée des modifications candidates comme des améliorations de AGENTS.md, puis les évalue avec Stet sur des tâches historiques du dépôt
    • Ils cherchent des équipes avec lesquelles exécuter des essais par dépôt si elles utilisent beaucoup des agents de code et doivent prendre des décisions concrètes comme high vs xhigh, Codex vs Claude Code, les mises à jour de AGENTS.md, ou déterminer quelles tâches peuvent être déléguées en toute sécurité
    • Stet s’exécute entièrement en local en utilisant un abonnement LLM, et la liste d’attente se trouve sur https://www.stet.sh/private

À lire aussi

1 commentaires

 
GN⁺ 8 시간 전
Avis Reddit
  • Cette comparaison est bien, et j’aimerais aussi voir une comparaison avec 5.4
    Jusqu’ici, à l’usage, 5.5 ne vaut pas son surcoût. 5.4-high s’en sort mieux que la plupart des niveaux de raisonnement de 5.5, pour un coût moitié moindre, et avec un temps réel bien plus court. 5.5-medium n’a pas réussi à terminer les tâches jusqu’au bout, et 5.5-high a fait de la sur-ingénierie en créant des bugs et des régressions
  • Pour la plupart des tâches sérieuses, high semble être le bon niveau
    Au-delà, les gains relèvent presque des rendements décroissants au vu du coût
  • Sur un compte Pro, j’utilise 5.5 xHigh Codex Terminal CLI comme lead principal, avec Codex Desktop App 5.5 xhigh en lead secondaire
    Les deux ont un accès complet risqué et travaillent sur le même projet. J’attache en moyenne 6 sous-agents 5.5 à chacun, et c’est le CLI ou l’app qui décide quel niveau utiliser pour ces sous-agents. C’est un mélange, mais le CLI assigne généralement du 5.5 Medium
    Le CLI a les droits admin et gère seul GitHub, Supabase, Vercel, Clerk, Linear, Symphony, ainsi que les push, merge, PR et deploy. Je ne fais strictement rien moi-même, et j’ai zéro incident P0/P1/P2. GitHub, Vercel et Supabase sont tous au vert, aucun problème, le code et le produit sont propres, et le frontend sort de façon impressionnante à partir d’une seule image de référence
    L’inconvénient, c’est que ça peut brûler 30 % du quota hebdomadaire en une journée
    • J’ai testé xhigh sur quelques tâches après avoir vu cette expérience ; c’est assez efficace, mais ça consomme les tokens à un rythme délirant
      Je suis ensuite revenu à high
  • Mon principal reproche à 5.5 xhigh, c’est qu’il avance tout seul sans même demander
    Cela dit, j’ai l’impression que ça m’a économisé quelques années de vie et pas mal de tokens
    • J’utilise surtout high, et il se comporte pareil
      Je cherche encore quelle formulation mettre dans agents.md pour l’empêcher de faire des suppositions de son propre chef. Quand je pose une question parce qu’il a besoin d’en savoir plus avant de recevoir des instructions de code, il lui arrive de coder directement au lieu de répondre. Il finit bien par inclure la réponse à la question dans sa réponse finale, donc il fait attention à ce que je dis, mais il ne semble pas comprendre que s’il y a une question, cela signifie qu’il ne doit pas encore coder
  • Je me demande si tu as relancé plusieurs fois sur la même PR
    J’aimerais savoir à quel point le modèle varie d’une exécution à l’autre. Même si high a mieux codé dans l’exemple ci-dessus, si la variabilité entre exécutions est forte, il pourrait quand même être préférable d’utiliser xhigh
    Une autre expérience intéressante serait de donner un retour sur le résultat après exécution, puis de lui faire mettre à jour AGENTS.md, les skills, les rules, etc. en comparant avec les modifications faites par un humain, avant de relancer en session fraîche avec high/xhigh. Après quelques itérations d’amélioration, on pourrait relancer l’expérience à tous les niveaux d’effort ; en affinant correctement AGENTS.md et les skills/rules, on pourrait probablement améliorer la qualité globale des sorties
    • Je n’ai pas exécuté chaque variante plusieurs fois. La raison principale, c’est le coût et les limites de tokens. Mon portefeuille n’est pas infini, mais c’est une très bonne idée pour une étude de suivi
      L’optimisation de AGENTS.md me plaît beaucoup, et j’ai justement fait faire ça à Stet, que j’ai créé pour lancer ces expériences. Il fait tourner Codex sur quelques tâches, observe les scores et les modes d’échec, modifie ensuite AGENTS.md, puis relance le tout, de manière entièrement autonome. Ça fonctionne comme une recherche automatisée pour AGENTS.md, et c’est assez fascinant de voir des propositions d’amélioration fondées sur les données revenir dans AGENTS.md
  • Il nous faut maintenant aussi un indice CPI pour l’inflation des prix. J’ai l’impression que le CPI mensuel est presque de 100 %