Astra : le gain sur Qwen passe par du code Python

Ce qui se passe

Notre fiche du 3 novembre présentait le billet « Weight-Space Programming », un texte de blog non relu selon lequel GPT-6 Astra sait lire les poids d'un réseau et corrige Qwen3.5-0.8B en en éditant 0,016 % (MATH-500 de 7,9 % à 48,1 %). Le résumé du billet ouvre sur ce que le modèle peut faire « rien qu'en regardant les poids bruts », puis enchaîne sur l'expérience Qwen, ce qui laisse croire que la même chose y est à l'œuvre. Matthew Honnibal (auteur de spaCy) juge cette présentation trompeuse, comparable aux numéros de magie où chaque tour utilise une technique différente et où le public croit n'en voir qu'une.

Ce que montre son tableau

Honnibal range les huit expériences du billet selon ce que le modèle a eu à sa disposition :

• Poids bruts seuls, sans outil, sans exécution : uniquement les expériences n° 1, 2 et 4, sur des réseaux de 17 000 à 172 000 poids.
• Du code Python : toutes les expériences qui touchent un vrai modèle de langage (de 7,2 millions de paramètres à 800 millions).
• Le modèle exécuté : le résultat sur Qwen3.5-0.8B, qui peut le faire tourner sur jusqu'à 50 lots de problèmes d'entraînement.

Le résultat sur Qwen relève donc de la deuxième et de la troisième catégorie : Astra écrit des programmes qui analysent et modifient les poids, et regarde le modèle répondre à des problèmes d'essai. Sur le petit Gemma 3 de 270 millions de paramètres, la même démarche n'a rien amélioré. Pour Honnibal, cela revient à ce qu'un ingénieur en apprentissage automatique sait déjà faire avec du code, ce qui reste utile, mais ne relève pas d'une lecture directe des poids.

Il reproche aussi de mélanger, dans un même texte, deux questions distinctes : ce qu'un modèle comprend de poids bruts sans outil, et ce qu'il fait avec du code pour en améliorer un autre. Un procédé unique qui réussirait les deux impliquerait une capacité profonde ; ce n'est pas ce qui est testé.

Une reproduction locale

Simon Willison a repris la première question, sans outil, sur son portable : Qwen 3.8 27B en GGUF Q4_K_M (17 Go), servi par LM Studio, avec l'outil llm et le greffon llm-lmstudio. Les invites des quatre jeux sont publiques dans le dépôt RikiyaT/lm_understand-logs. Mesures relevées :

• Pac-Man trouvé en 46 min 12 s (43 506 jetons de raisonnement), confiance annoncée 72 % ;
• Breakout en 52 min 25 s (88 %), Pong en 1 h 4 min 54 s (75 %) ;
• Freeway, jeu plus obscur, raté : le modèle y a vu un jeu de type Pac-Man ;
• le contexte par défaut de 8192 jetons échoue : il faut le rallonger ; le délai d'attente du greffon llm-lmstudio doit aussi être relevé (LMSTUDIO_TIMEOUT=900) ;
• un autre modèle, Kimi K3.1 Pro via OpenRouter, a trouvé Breakout en 9 min 41 s et 19 493 jetons de raisonnement.

Il juge ces traces presque incompréhensibles, et estime qu'un humain suffisamment expérimenté, muni d'un bloc-notes et d'un crayon, y arriverait. Il ne se dit pas prêt à déclarer que l'ère du code source est finie ; Sean Goedecke, de son côté, a décortiqué l'exemple Qwen en y retrouvant les gestes d'un chercheur humain.

Comment s'y prendre

• Si vous citez le résultat, distinguez lecture directe de poids (petits réseaux, sans outil) et édition outillée par du code (modèle réel, exécution à l'appui).
• Pour rejouer la partie sans outil en local : prévoir un modèle d'environ 17 Go, un contexte long, et des essais qui se comptent en dizaines de minutes.
• Le billet d'origine reste une prépublication non relue : ses chiffres (7,9 % → 48,1 %) sont ceux de ses auteurs.

Sources : Matthew Honnibal et Simon Willison, tous deux en anglais.