Concevoir des boucles avec Fable 5

• Deux techniques clés sont mises en avant pour bien exploiter Claude Fable 5, un modèle de classe Mythos qui a changé la manière de travailler en interne chez Anthropic : la boucle d’auto-correction et la mémoire
• Des goal et rubric bien conçus injectent du feedback dans l’environnement, permettant à Claude de répéter exécution → collecte de feedback → auto-correction jusqu’à atteindre l’objectif
• Dans le défi d’ingénierie ML Parameter Golf, Fable 5 a amélioré le pipeline d’entraînement d’environ 6 fois plus que Opus 4.7
• Grâce à la mémoire, une boucle externe qui s’étend d’une session à l’autre, Claude peut réutiliser dans les sessions suivantes ce qu’il a consigné pendant une session
• Le point essentiel est qu’au lieu de recourir au prompting direct ou au pilotage fin, il est plus efficace de concevoir des boucles où le modèle se corrige lui-même et gère son propre contexte

---

Boucle d’auto-correction

• Une recette générale pour améliorer les performances sur une tâche consiste à laisser le modèle faire du hillclimbing sur la base de critères d’évaluation
  • bcherny a indiqué que « son travail consiste à écrire des boucles »
  • Le /goal de Claude Code et les Outcomes de Claude Managed Agent sont des primitives qui appliquent cette recette à des tâches spécifiques
• Un goal ou une rubric bien conçu ajoute du feedback à l’environnement dans lequel Claude s’exécute, puis il continue jusqu’à satisfaire le goal/la rubric après avoir exécuté, collecté le feedback et effectué une auto-correction

Test Parameter Golf

• Parameter Golf est un défi open source d’ingénierie ML consistant à entraîner en moins de 10 minutes sur 8xH100 le modèle le plus performant pouvant tenir dans un artefact de 16 Mo
  • Il évalue la capacité à modifier un unique fichier train_gpt.py, lancer l’entraînement, interroger les logs, vérifier le score et décider de l’expérience suivante
  • Il est similaire au projet autoresearch de karpathy
• Comparaison entre Fable 5 et Opus 4.7 à l’aide de Claude Managed Agents (CMA)
  • CMA fournit un agent harness et un sandbox hébergé, adaptés au travail de longue durée de Fable 5
  • Pour Parameter Golf, un sandbox auto-hébergé avec 8xH100 GPU a été fourni

L’importance de l’instance d’évaluation

• Il a été confirmé que le modèle montre des problèmes lorsqu’il fait une auto-critique de sa propre sortie (comme l’a décrit Prithvi Rajasekaran dans un billet d’ingénierie)
• Un sous-agent de vérification est supérieur à l’auto-critique, car l’évaluation se fait dans une fenêtre de contexte indépendante
  • Les Outcomes de CMA créent automatiquement un sous-agent évaluateur pour s’en charger
• Une rubric contenant 9 critères vérifiables (exécution de la baseline, réalisation de 20 expériences, etc.) a été fournie, avec jusqu’à 8 heures d’exécution
  • L’évaluateur Outcomes n’autorise Claude à terminer son travail qu’après avoir confirmé que tous les critères expérimentaux sont remplis

Comparaison des résultats

• Fable 5 a amélioré le pipeline d’entraînement d’environ 6 fois plus que Opus 4.7
  • En distinguant les expériences structurelles (changements d’architecture) des ajustements scalaires (réglage de constantes), Fable 5 parie sur des changements structurels plus importants et fait preuve de résilience (en surmontant une régression de quantification pour atteindre la meilleure performance)
• Opus 4.7, après un petit succès lors de la première expérience, a ensuite surtout répété le même modèle : ajustement scalaire → mesure → conservation si le résultat est positif

Mémoire

• En tant que boucle externe traversant les sessions, la mémoire permet de rechercher et réutiliser dans les sessions suivantes les notes rédigées pendant une session
• L’équipe de pgasawa a publié Continual Learning Bench 1.0
  • Il s’agit du premier benchmark réaliste mesurant à quel point un système d’IA s’améliore dans un environnement en ligne
  • Les benchmarks existants supposent généralement des modèles stateless et un traitement indépendant de chaque exemple

Configuration du test

• L’une des tâches du benchmark compare Fable 5, Opus 4.7 et Sonnet 4.6
  • La tâche consiste à répondre à des questions séquentielles avec accès à une base de données SQL ; chaque question correspond à une session d’agent distincte, avec mémoire fournie
• Utilisation de la memory de CMA, qui fournit à chaque agent un système de fichiers monté pouvant être partagé entre sessions

Étapes d’un usage efficace de la mémoire

• L’usage efficace de la mémoire se renforce via la progression fail (consigner l’erreur) → investigate (identifier la cause) → verify (transformer en fait vérifié) → distill (généraliser en règle) → consult (consulter la règle)
• Sonnet 4.6 s’arrête près de la première étape
  • Son dépôt devient une liste de notes d’échec et de suppositions non résolues (« maybe prc instead of prc_usd? »), sans presque jamais référencer les notes précédentes
  • Des consignes de mémoire spécifiques à la tâche sont nécessaires pour améliorer les performances
• Opus 4.7 s’arrête près de la troisième étape
  • Il crée une référence de schéma indiquant l’incertitude (« possibly prc in cents? Verify. »), mais la couverture de vérification reste faible, de 7 à 33 % (médiane d’environ 17 %)
• Fable 5 a tendance à mener le processus à son terme
  • Dans son exécution la plus performante, la couverture de vérification a atteint 73 % (22 sur 30), et il distille ce qu’il apprend en règles générales utiles pour les tâches suivantes

En résumé

• Plutôt que de faire du prompting direct ou de piloter finement Fable 5, il est plus efficace de concevoir des boucles où il réagit au feedback de l’environnement (/goal, Outcomes), s’auto-corrige et gère lui-même son contexte grâce à la mémoire
• Il est recommandé de tester directement Fable 5 sur des tâches difficiles en exploitant des boucles d’auto-correction et de mémoire