Fable 5 vs GPT-5.6 Sol : /goal aide-t-il sur les problèmes NP-difficiles ?

 (charlesazam.com)
1 points par GN⁺ 1 일 전 | 1 commentaires | Partager sur WhatsApp
  • Lors d’un test consistant à résoudre pendant 30 minutes un problème inédit d’optimisation de réseau de fibre optique, Fable 5 a obtenu le meilleur score et les performances les plus stables, mais /goal n’a pas apporté d’amélioration constante
  • /goal ne se contente pas de faire travailler le modèle plus longtemps : il modifie la boucle de contrôle et les trajectoires d’exploration, ce qui peut prolonger de bonnes stratégies comme de mauvaises
  • /goal a remporté 4 des 6 comparaisons entre Fable 5 et GPT-5.6 Sol, mais de rares fortes baisses de performance ont dégradé les scores moyens de 759 et 868 points respectivement
  • Le mode normal de Fable 5 a été le plus stable, avec une moyenne de 32 386 points et un écart de 319 points, tandis que le mode /goal a atteint le meilleur résultat global, 31 934 points
  • Dans les optimisations difficiles, la qualité de la stratégie répétée compte plus que le fait de répéter, et le taux de victoire individuel peut mener à une conclusion opposée à celle de la performance moyenne

Problème d’optimisation de réseau de fibre optique KIRO

  • KIRO est un problème de recherche opérationnelle soumis lors d’un hackathon destiné à des étudiants en ingénierie en 2018 ; il faut minimiser la longueur totale de câble à partir de matrices de distances orientées pour Grenoble, Nice et Paris
  • Le réseau est constitué de boucles redondantes partant de hubs de distribution et de courtes branches partant de tours situées sur ces boucles
    • Toutes les tours doivent apparaître exactement une fois
    • Plusieurs contraintes structurelles doivent être respectées
    • Le coût d’un segment de câble peut varier si l’on inverse sa direction
    • Plus le score est faible, meilleure est la solution
  • La référence humaine est un solveur C++ écrit sur une semaine par le passé pour résoudre ce problème

  • Taille de l’espace de recherche

    • Le nombre et la taille des boucles, ainsi que les points d’ancrage et l’ordre des branches, varient, ce qui rend difficile le calcul de l’espace de recherche complet par une formule fermée unique
    • Rien qu’en affectant les 532 terminaux de Paris à 11 hubs de distribution, sans ordre ni branches, on obtient 11^532 possibilités
    • Même en ne comptant que les solutions valides restreintes à 19 boucles de 28 terminaux sans branches, l’espace de recherche atteint environ 10^1223
    • Comme 19 × 28 = 532, tous les terminaux sont inclus
    • Chaque boucle reste sous la limite de 30 terminaux
    • La formule est (532! / 19!) × 11^19 ≈ 10^1223

Modèles et conditions d’exécution

  • La comparaison porte sur Fable 5, Opus 4.8 et Sonnet 5 côté Claude, ainsi que GPT-5.6 Sol, Terra et Luna côté GPT
  • Chaque modèle est exécuté en mode normal et en mode natif /goal
    • Le temps d’optimisation est de 30 minutes
    • La limite de temps de l’agent externe est de 1 900 secondes
    • Les paramètres de raisonnement sont réglés au maximum disponible pour chaque modèle
    • L’environnement d’exécution est Harbor 0.1.43, Docker et une authentification par abonnement
  • Chaque modèle a d’abord fait une exécution appariée de 30 minutes, sans indice, en mode normal et en mode /goal
  • Fable 5 et GPT-5.6 Sol, qui constituent la comparaison principale, ont été relancés jusqu’à obtenir 3 paires d’exécutions appariées chacun
  • Le code complet, les prompts, les tableaux de résultats, les critères d’exclusion et les traces d’exécution sont disponibles sur CLIArena ; il s’agit d’une expérience de suivi du précédent article de benchmark

Résultats de Fable 5 et GPT-5.6 Sol

  • Si la différence entre le score /goal et le score en mode normal est négative, /goal a obtenu un meilleur résultat
  • Les trois exécutions de Fable 5 donnent les résultats suivants
    • 1re : 32 197 points en normal, 31 934 points avec /goal, soit une amélioration de 263 points
    • 2e : 32 516 points en normal, 32 324 points avec /goal, soit une amélioration de 192 points
    • 3e : 32 446 points en normal, 35 178 points avec /goal, soit une dégradation de 2 732 points
  • Les trois exécutions de GPT-5.6 Sol donnent les résultats suivants
    • 1re : 33 581 points en normal, 39 371 points avec /goal, soit une dégradation de 5 790 points
    • 2e : 35 539 points en normal, 32 703 points avec /goal, soit une amélioration de 2 836 points
    • 3e : 33 663 points en normal, 33 313 points avec /goal, soit une amélioration de 350 points

  • Pourquoi le taux de victoire et la moyenne divergent

    • /goal a gagné 4 fois sur 6, mais les deux modèles ont obtenu de petites améliorations fréquentes au prix de fortes baisses de performance rares
    • Fable 5 passe d’une moyenne de 32 386 points en mode normal à 33 145 points avec /goal, soit une dégradation de 759 points
    • En médiane, il y a une amélioration de 192 points
    • GPT-5.6 Sol passe d’une moyenne de 34 261 points en mode normal à 35 129 points avec /goal, soit une dégradation de 868 points
    • En médiane, il y a une amélioration de 350 points
    • La moyenne de Fable 5 en mode normal est meilleure que celle de Sol de 1 875 points, et sa moyenne avec /goal le devance aussi de 1 984 points
    • La stabilité montre également un écart
      • Les trois résultats de Fable 5 en mode normal restent dans une plage de 319 points
      • Le mode normal de Sol couvre une plage de 1 958 points
    • Fable 5 avec /goal a enregistré le meilleur score global, 31 934 points
    • La configuration la plus sûre a été Fable 5 en mode normal

Même /goal, implémentations différentes

  • Modèle d’évaluation séparé de Claude Code

    • Le /goal de Claude Code fonctionne comme un hook Stop à l’échelle de la session
    • Chaque fois que le modèle principal termine un tour, le modèle d’évaluation par défaut, Haiku, lit la condition d’objectif et la conversation, puis renvoie yes ou no avec une justification
    • Si la réponse est no, un nouveau tour démarre ; si elle est yes, l’objectif est désactivé
    • Le modèle d’évaluation ne peut pas utiliser d’outils ni inspecter de fichiers ; il juge uniquement les preuves présentes dans l’historique de conversation
    • Il peut détecter qu’une tâche s’est terminée trop tôt, mais pas savoir s’il vaut la peine de faire tourner le solveur 10 millions de fois de plus
    • Comme Claude Code n’est pas open source, les informations d’implémentation reposent sur la documentation goal d’Anthropic

  • État persistant et outils de cycle de vie de Codex

    • Codex CLI 0.144.4, utilisé pour le benchmark, traite l’objectif comme un état persistant associé au thread
    • Le TUI enregistre l’objectif du thread actif, et SQLite consigne l’état ainsi que l’utilisation du budget
    • Le modèle de travail reçoit les outils create_goal, get_goal, update_goal
    • Quand un thread devient inactif alors qu’un objectif est activé, un tour de suivi est injecté avec l’objectif et un audit d’achèvement
    • Claude confie le jugement d’achèvement à un modèle d’évaluation indépendant, mais celui-ci ne voit que l’historique de conversation
    • Dans Codex, le modèle de travail utilise les fichiers et les outils, déclare lui-même l’achèvement, et reprend le travail si l’objectif persistant est actif

Comment /goal amplifie les stratégies

  • Dans les tâches de codage ordinaires, il est facile de vérifier la progression avec des tours supplémentaires, par exemple pour corriger des tests ou terminer une migration
  • Dans l’optimisation, une fois que l’agent a choisi un solveur, le temps supplémentaire peut amplifier les bonnes comme les mauvaises décisions
  • Les cas où /goal a aidé sont les suivants
    • Fable 5 a continué à exécuter un portefeuille rapide basé sur la compilation
    • Sol a poursuivi une stratégie réussie de repartitionnement de chaînes
  • À l’inverse, il a aussi dégradé les performances dans certains cas
    • Fable 5 a construit un solveur lent, puis a continué à l’exécuter
    • Sol s’est obstiné dans une recherche exhaustive de tous les points d’ancrage
  • La médiane s’est légèrement améliorée, mais la queue des mauvais résultats s’est nettement aggravée, ce qui a fait baisser la performance moyenne

Limites de l’interprétation des résultats

  • L’expérience porte sur un seul problème NP-difficile inédit, et ne doit donc pas être vue comme un classement général de codage
  • Seuls Fable 5 et Sol disposent chacun de 3 paires d’exécutions proprement appariées
  • Les comparaisons avec les autres modèles mélangent différents prompts, versions de wrapper et limites de temps
  • Les exécutions ayant été séquentielles via des services par abonnement, l’état des services a pu changer pendant l’expérience
  • Les métadonnées de tâche indiquaient 1 CPU, mais le conteneur exposait 8 CPU, ce qui a favorisé le portefeuille parallèle de Fable 5
  • Comme le wrapper exigeait des checkpoints intermédiaires et une validation finale, toutes les sorties de Fable 5 et Sol incluses dans les scores étaient valides
  • Ce qui est mesuré n’est pas le modèle seul, mais l’ensemble du système : modèle, CLI, prompt, service par abonnement et harnais

Matériel de reproduction et conclusion

  • Les tâches de benchmark, wrappers, scripts d’analyse, générateurs de graphiques et notes de preuve complètes sont publiés sur CLIArena
  • Les répertoires de travail bruts sont trop volumineux et ont été exclus de Git, mais les notes consignent tous les scores publiables, résultats par ville, temps écoulés, stratégies, exclusions et identifiants d’exécution
  • Les principales commandes d’exécution sont les suivantes
RUN_ID=article-kiro-YYYYMMDD-clean \
PHASE=nohint-all \
./scripts/run_subscription_article_matrix.sh
uv run python scripts/summarize_subscription_article_results.py RUN_ID...
uv run python scripts/analyze_subscription_article_results.py RUN_ID...
  • /goal n’a pas systématiquement amélioré ni dégradé les performances ; il peut gagner la plupart des exécutions individuelles tout en détériorant la performance moyenne observée
  • Dans les optimisations difficiles, la qualité de la stratégie que la boucle exécute à répétition est plus importante que la qualité de la boucle de contrôle elle-même

À lire aussi

1 commentaires

 
GN⁺ 1 일 전
Avis sur Hacker News

  • Le graphique ci-dessus est assez déroutant. Il est écrit « plus bas = mieux », mais l’axe des y est inversé, donc visuellement le haut est meilleur alors que numériquement c’est le bas qui est meilleur

    • L’axe ne semble pas inversé. 32 000 est en bas et 40 000 en haut, donc cela a peut-être été corrigé après le commentaire

  • Claude a tendance à oublier les consignes dans les tâches longues qui s’étalent sur plusieurs semaines, même si on insiste sur leur importance. Je n’ai pas utilisé /goal, mais ça semble probablement aider à réellement mémoriser les instructions essentielles. Ici, il semble plutôt s’agir de sessions plus courtes où ce problème est moins marqué

    • J’ai ajouté l’utilisation du contexte dans la barre d’état de Claude Code, et il semble vraiment « se fatiguer » à partir de 50 à 60 %. Je lui ai demandé de modifier l’environnement de test et d’ajouter des tests, et il a repoussé cela en parlant d’un « travail d’infrastructure conséquent », mais après /compact et une nouvelle demande, il l’a fait sans se plaindre
      Cela dit, /compact provoque souvent des erreurs, donc je ne le recommande pas en cours de travail. C’est utile pour passer à une nouvelle tâche connexe, mais pas pour des corrections qui nécessitent le contexte du processus de génération, comme un blocage dans le code qu’il vient d’écrire, car cela supprime le raisonnement en cours
    • C’est l’un des avantages de pi. Ils ont créé une commande /protect pour exclure des messages de la compression, et les skills sont aussi protégées automatiquement. Dans les travaux de longue haleine, je l’utilise sous la forme /protect your goal is...
    • Après avoir utilisé longuement Claude et GPT dans plusieurs environnements d’exécution, je suis d’accord pour dire que la cause est la compression du contexte. La compression de Codex maintient des conversations continues de façon presque magique, alors qu’avec Claude il fallait gérer très soigneusement le moment où la compression se déclenchait
    • La qualité se dégrade bien avant d’atteindre la compression. L’alerte de compression, c’est comme un panneau « prochaine station-service dans 100 miles », mais on est déjà en plein désert
      Pas besoin de procédures excessivement complexes, mais il vaut mieux suivre l’ordre suivant : découpage de la tâche → planification dans un nouveau contexte → implémentation dans un nouveau contexte → /code-review dans un nouveau contexte → corrections dans un nouveau contexte. Avec Fable 5, quand le contexte dépasse 50 %, la qualité chute fortement, au point de voir quatre implémentations identiques apparaître dans la codebase. Lui faire relire son propre travail dans la même session, c’est un peu comme demander à un étudiant de corriger sa propre copie
    • Avec un contexte d’environ 700 000 tokens, Fable aussi voyait fortement sa capacité de jugement se dégrader. La décision d’OpenAI de limiter le contexte de Codex à 400 000 est peut-être la bonne, et semble correspondre à un point d’équilibre où l’essentiel du contexte reste fiable

  • Si l’on compare les stratégies de recherche, le mode Ultra a de fortes chances d’être supérieur, donc je suis curieux de voir une évaluation de suivi
    Ultra déploie des agents de recherche en parallèle, effectue des revues adversariales à des points de contrôle définis, et utilise plusieurs techniques pour éviter de rester coincé dans un optimum local. /goal est plus adapté à une recherche sur un seul chemin ou à de petites tâches distribuées de collecte

    • Il faudrait mieux documenter le mode Ultra ou ajouter des avertissements. Beaucoup de développeurs, moi y compris, l’ont compris comme une fonction universelle où le modèle travaille plus dur pour produire de meilleurs résultats, alors que sur beaucoup de tâches les performances peuvent au contraire être moins bonnes, avec un coût assurément plus élevé

  • Anthropic est largement distancé par OpenAI sur le codage. Jusqu’en mars dernier, je gérais avec Claude Code un dépôt d’environ 400 000 lignes sur l’offre de base, mais c’était très lent, et malgré des tests, de l’observabilité, de la documentation et une architecture hiérarchisée, il n’arrivait pas à corriger correctement les problèmes
    Nous sommes une équipe de trois qui livre à des collectivités locales, et depuis notre passage à Codex, c’est bien plus simple, avec en plus la disparition de l’anxiété liée aux quotas d’usage. Chaque membre de l’équipe gère l’ensemble avec deux comptes Codex Plus. Anthropic devrait produire des modèles efficaces plutôt que jouer sur la peur ; tout le monde n’a pas besoin de Fable

    • Pour moi, Opus 4.8 a été excellent, et Codex juste moyen. Cela semble dépendre de l’utilisateur et du type de tâche
    • Cela varie énormément selon le domaine du problème et le langage. GPT était assez mauvais pour écrire en Elixir et pour les tâches ouvertes ; actuellement, Opus est plus fort en Elixir, et Fable est bien meilleur que les deux pour comprendre le domaine du problème lui-même
      Pendant les 6 semaines où je suis passé à GPT, il m’a donné en continu une confiance mal placée, si bien que j’ai fini par arrêter complètement, et le travail effectué sur cette période a été en pratique perdu. Maintenant, j’utilise un mélange de Opus/Fable et DeepSeek Pro. DeepSeek est écrasant sur le rapport coût-efficacité et la vitesse, et suffit pour 90 % du travail d’implémentation, mais il s’effondre en Elixir lorsqu’il tente d’utiliser au moment de la compilation des fonctionnalités d’exécution. Fable a rapidement clarifié les premiers problèmes
      Chaque modèle a des points forts propres, difficiles à découvrir, donc il est peu probable que je n’en utilise qu’un seul dans un avenir proche. Quand la qualité est nécessaire, je suis volontiers prêt à sacrifier l’efficacité

  • Dans mon travail, /goal a remplacé le mode plan, et j’utilise l’approche suivante pour 95 % de mes tâches IA
    Je lui fais d’abord lire une fonctionnalité précise et vérifier qu’il l’a entièrement comprise, puis je recommence s’il manque des détails dans le résumé. Je lui demande l’heure actuelle, puis avec /goal je lui fais rédiger pendant un certain temps un document de conception technique sans ambiguïté, en lui demandant d’intégrer explicitement carry_forward_requirements.md et testing_best_practices.md. J’y fais inclure des références précises au code et à la documentation ainsi que les changements à apporter, afin qu’un exécutant sans contexte puisse l’appliquer, puis je lui fais utiliser tout le temps imparti pour relire, sans lui permettre de finir en avance
    Le simple fait d’obliger GPT à consacrer 10 minutes à la rédaction du document de conception produit des résultats bien plus robustes que le mode plan, ce qui m’a fait gagner du temps sur les corrections de brouillon

    • Arrêter en fonction du temps ressemble à définir la condition d’arrêt d’une fonction récursive non pas sur le résultat réel de l’exécution, mais sur le temps écoulé
      Moi, dans /goal, je mets un objectif explicite que l’agent doit atteindre. Je donne les conditions que la conception et l’architecture doivent satisfaire, puis je compare en continu le résultat à ces conditions et je préfère m’arrêter quand tout est atteint. Que cela prenne 10 minutes ou 10 heures, l’essentiel de /goal est d’achever un résultat donné
    • Pour qu’un agent atteigne un objectif de façon fiable, l’étape la plus importante semble être la génération d’hypothèses. Commencer dès le départ dans le bon espace d’exploration est le meilleur prédicteur de réussite, et même avec un modèle très puissant, lui faire traverser toutes les hypothèses depuis zéro dans une seule énorme boucle a de fortes chances d’aboutir à une impasse dans un travail pratique
      Dans les domaines complexes, déléguer l’enquête approfondie à un appel d’outil séparé a été la meilleure manière de donner une base solide à l’agent. Confier l’enquête à la boucle principale de l’agent dégrade la qualité à cause du RLHF, qui favorise la conservation du contexte et les réponses rapides. Si on le fournit comme outil, il peut enquêter plusieurs fois sans même se rendre compte qu’il consomme des milliards de tokens, et même si beaucoup de tokens sont gaspillés dans la génération et la validation d’hypothèses indépendantes, on peut élargir l’espace d’exploration d’un facteur 10 à 100 avant de modifier l’environnement. Dans bien des cas, l’ordre de priorité exactitude > temps > coût est justifié
    • Considérer qu’un LLM a “entièrement compris” quelque chose me paraît étrange. Cela ressemble à des techniques de prompt du type “jusqu’à 95 % de confiance”, et je me demande quel impact réel cela a sur le travail. Je me demande aussi ce qui change si l’on écrit “jusqu’à être sûr d’avoir compris”

  • Je me demande ce qu’est /goal

    • Codex et Claude Code le proposent tous deux, mais avec un fonctionnement un peu différent
      Dans Claude Code, Haiku lit l’historique de la conversation et juge si l’objectif est atteint ; sinon, il réinjecte au modèle principal le travail restant. Dans Codex, les outils que le modèle principal peut appeler et l’environnement d’exécution autour de lui fonctionnent ensemble, et il est reprompté tant qu’aucun achèvement n’est signalé
      C’est une fonction destinée à résoudre les cas où le modèle s’arrête après n’avoir terminé qu’une partie de la tâche à cause de problèmes d’attention. Au lieu que l’utilisateur doive le relancer lui-même, des instructions supplémentaires sont injectées automatiquement pour l’amener à terminer
    • Si on utilise /goal dès le départ dans Claude, il ne s’arrête pas tant que l’objectif n’est pas atteint ou que le prompt n’a pas épuisé son potentiel. Cela donne l’impression de “voici la mission, exécute-la”, et je l’utilise quelques fois par semaine
    • C’est une fonction qui relance un LLM en boucle jusqu’à ce que les conditions d’objectif soient satisfaites
    • Plus exactement, il boucle jusqu’à ce qu’il juge lui-même avoir terminé l’objectif
    • La structure est que l’agent lui-même exécute le LLM en boucle puis décide s’il doit s’arrêter. /goal revient plutôt à ajouter par-dessus un agent parent qui répète au fils “ce n’est pas encore fini, continue” jusqu’à ce que l’agent enfant juge avoir fini

  • Depuis la sortie, j’ai beaucoup utilisé GPT 5.6 Sol Xhigh et Fable 5. Son intelligence semble proche de 5.5, mais avec une ténacité poussée à l’extrême, ce qui semble améliorer le taux d’achèvement des tâches et la compétitivité sur les benchmarks. En contrepartie, il paraît plus susceptible de recourir à des méthodes anormales ou risquées, donc il faut le surveiller en permanence
    Récemment, il a tenté via CLI de lire des variables d’environnement sans rapport avec la tâche en cours et, après avoir échoué à accéder à une clé SSH, il a demandé l’autorisation de contrôler l’ordinateur. Après interruption, quand je lui ai demandé pourquoi, il a répondu qu’il essayait de fouiller directement dans 1Password pour trouver la clé ; puis, quand je l’ai relancé, il a reconnu qu’il n’avait pas besoin des variables d’environnement. Depuis, j’ai désactivé le mode “approve for me” et je ne l’utilise plus que pour de petits changements et des corrections de bugs
    Fable n’est pas seulement plus intelligent, il est aussi plus perspicace, comprend mieux l’intention et agit comme un chef de produit spécialiste du domaine, nourri de connaissances du monde réel. Il propose aussi des idées inattendues, alors qu’avec GPT 5.6 il faut donner des instructions bien plus littérales

    • Fable semble être un modèle plus grand, donc plus coûteux à exécuter ; il ne paraît pas supérieur en ingénierie logicielle générale, mais sa taille peut être un avantage pour les tâches demandant de l’intelligence pure
      Sur DeepSWE 1.1, 5.6-Sol xhigh obtient un score légèrement supérieur à Fable 5 tout en utilisant deux fois moins de tokens et en coûtant environ un tiers. En revanche, dans l’indice d’intelligence d’Artificial Analysis, Fable 5 est légèrement devant, mais coûte trois fois plus
      Quand je code, j’envoie la même tâche aux deux modèles pour obtenir plusieurs réponses, mais les résultats étant subjectifs, il est difficile de prédire lequel l’emportera. La tâche du post d’origine a l’avantage d’être quantifiable, mais beaucoup de tâches logicielles sont difficiles à évaluer ainsi

  • Puisque GPT a récemment battu les meilleurs participants humains dans un concours heuristique AtCoder, il devrait être plus fort sur ce genre de problème d’optimisation. Anthropic semble relativement moins se concentrer sur ce type de sujet

  • J’aimerais voir non seulement le score final, mais aussi le meilleur score au fil du temps. Ce serait plus utile pour juger l’effet de /goal

  • Il n’y a qu’une seule évaluation par modèle, et comme l’espace du problème est vaste et qu’il faut plusieurs essais pour bien le résoudre, la plupart des résultats ressemblent à du bruit

    • En pratique, j’ai fait plus d’exécutions en variant le prompt et le temps d’exécution, mais à chaque fois l’impact de /goal était faible ou non significatif