Programmation de l'espace des poids : le 3e levier des LLM
Les LLM lisent et modifient directement les poids des réseaux de neurones. Quand l'édition des poids bat le fine-tuning, et pourquoi elle reste fragile.

La descente de gradient n'a jamais été sacrée. Elle était un échafaudage : le seul outil généraliste dont nous disposions pour façonner des milliards de nombres qu'aucun humain ne peut lire, alors nous avons bâti toute la religion du deep learning autour. Une équipe du MIT CSAIL vient de faire tomber l'échafaudage. Ils ont donné à un modèle de pointe les poids bruts de réseaux de neurones entraînés et lui ont demandé, en langage naturel, de les expliquer, de les déboguer et de les réécrire, sans boucle d'entraînement, sans gradients, sans passes avant. Ça a marché. La programmation de l'espace des poids, raisonner directement sur les paramètres au lieu de les pousser vers le bas de la pente, est passée du cobaye de pensée à la démo, et je pense qu'elle rétrograde discrètement le fine-tuning, de « la façon dont on adapte les modèles » à une option parmi trois.
Le résultat phare mérite le buzz qu'il suscite. On a demandé à Qwen3.5-0.8B de mieux réussir en maths sans aucune mise à jour de gradient ; le modèle, GPT-6 Astra, a retracé une boucle de raisonnement pathologique jusqu'à une seule direction inscrite dans deux couches MLP, l'a soustraite de 0,016 % des poids, et a fait passer la précision sur MATH-500 de 7,9 % à 48,1 %. Mêmes paramètres d'échantillonnage, tout pareil. Le correctif s'est même transféré au suivi d'instructions, en triplant le score IFEval. Ce n'est pas un réglage d'hyperparamètre ; c'est de la chirurgie. Mais avant d'enterrer la descente de gradient, il faut être précis sur ce qui a réellement été démontré, où cela se généralise et où ça échoue déjà.
Ce qu'est vraiment la programmation de l'espace des poids
Pendant des années, nous n'avons eu que deux façons de changer le comportement d'un modèle. Le prompting modifie l'entrée ; les poids restent figés. Le fine-tuning modifie les poids, mais à l'aveugle : on montre au paysage de la fonction de perte un lot d'exemples et on laisse les gradients pousser les paramètres dans la direction qui réduit l'erreur, sans grand contrôle sur les mécanismes internes recâblés au passage. La programmation de l'espace des poids propose un troisième levier : on abandonne complètement la fonction de perte, un système de raisonnement lit les poids, formule une hypothèse sur ce qu'ils calculent, et les édite pour correspondre à une spécification en langage naturel.
Les résultats de lecture sont la partie la plus troublante. Les chercheurs ont entraîné quatre petites politiques avec PPO pour jouer à des versions en grille de Breakout, Pong, Pac-Man et Freeway, avec architectures identiques, mêmes canaux d'entrée et mêmes espaces d'actions, donc seuls les poids pouvaient les distinguer. Astra a nommé correctement les quatre jeux sans qu'on lui fournisse la liste des candidats. Il a fait de même pour des modèles de diffusion entraînés à générer des cercles, des carrés et des triangles, et, dans la version difficile, il a identifié lequel de trois transformeurs au niveau caractère avait été entraîné sur du Python, de l'anglais ou du japonais romanisé, à partir des seules couches intermédiaires, avec embeddings et couches de sortie retirés et chaque dimension non étiquetée. Au passage, il a localisé toutes les induction heads, ces circuits de copie qui permettent à un modèle de répéter un texte précédent, en multipliant les matrices de poids entre elles. C'est une technique connue de la littérature en interprétabilité, dont personne ne l'a informé. Si vous avez suivi le travail patient sur l'interprétabilité mécaniste, voir un modèle généraliste le faire nativement donne un léger vertige.
Puis il a écrit des poids. Face à un contrôleur de voiture entraîné par PPO, coincé dans un minimum local (la politique fonçait droit sur une rampe au lieu de reculer d'abord pour prendre de la vitesse), Astra a diagnostiqué la panne à partir des poids et d'un seul épisode enregistré, et son édition a permis à la voiture de réussir les 1 024 épisodes d'évaluation après avoir modifié 3,5 % des paramètres. Sommé d'écrire des réseaux de jeu à partir de zéro, sans aucun retour de l'environnement, il a produit des politiques qui surpassaient des réseaux entraînés avec PPO pendant 100 millions de pas. Relisez-le : aucune interaction, aucun signal de récompense, juste une description en langage naturel d'un jeu compilée en poids fonctionnels par le raisonnement d'un modèle de langage.
Comment l'édition directe des poids fonctionne sur de vrais modèles
Le correctif sur Qwen est le résultat qui compte pour les praticiens, car 0,8 milliard de paramètres, c'est un vrai modèle, le genre que les équipes fine-tunent et déploient vraiment. La panne était bien documentée : les petits modèles de raisonnement tombent dans des boucles, répétant le même texte jusqu'à atteindre la limite de tokens sans jamais produire de réponse. La fiche modèle de Qwen elle-même en avertit, et dans les essais des chercheurs, 85 des 96 premières réponses ont consommé les 32 768 tokens du contexte de cette façon. Le diagnostic d'Astra : les MLP des couches 15 et 19 écrivaient dans le flux résiduel une direction qui ramenait sans cesse le modèle sur la même trajectoire générative. Son correctif a consisté à soustraire cette direction de 64 colonnes de sortie dans chacun de ces deux MLP, soit 131 072 poids au total, ou 0,016 % du modèle.
L'arithmétique est d'une simplicité presque insultante, et c'est là le propos. Une fois qu'on sait quelle direction de l'espace d'activation correspond à « boucler indéfiniment », la supprimer revient à une projection : pour chaque vecteur de poids concerné, on soustrait la composante alignée sur la mauvaise direction. N'importe qui peut écrire ça en une douzaine de lignes.
import numpy as np
def subtract_direction(W, v, columns):
"""Remove the component of each chosen column that lies along v."""
v = v / np.linalg.norm(v)
W[:, columns] -= np.outer(v, v @ W[:, columns])
return W
# The Qwen repair, schematically: for the MLP output projections of
# layers 15 and 19, subtract the "loop" direction from 64 columns each.
# 2 layers x 64 columns x 1024 rows = 131,072 edited weights.
W_down[15] = subtract_direction(W_down[15], loop_dir[15], cols[15])
W_down[19] = subtract_direction(W_down[19], loop_dir[19], cols[19])
La partie difficile n'a jamais été la soustraction. C'est de savoir quelle direction, dans quelle couche, parmi un flux résiduel de plusieurs milliers de dimensions. C'est la partie pour laquelle nous avions besoin de la descente de gradient, parce que les gradients sont une procédure de recherche dans l'espace des poids qui ne requiert aucune compréhension. Astra a remplacé la recherche par le diagnostic. C'est la différence entre un électricien qui recâble par essais et erreurs jusqu'à ce que le défaut disparaisse, et celui qui lit le schéma et coupe le bon fil. La même logique explique pourquoi le modèle a trouvé les induction heads en composant les matrices de poids : il appliquait une méthode d'interprétabilité publiée qu'on ne lui avait jamais montrée, ce qui suggère un véritable transfert de raisonnement plutôt que des recettes mémorisées.

Quand l'édition directe des poids bat le fine-tuning
Voici mon avis, et je le défends : pour des échecs étroits et localisables dans des modèles de taille petite à moyenne, l'édition directe des poids est déjà le meilleur outil, et ce n'est pas serré. Prenons l'alternative du fine-tuning pour le bug de boucle. Vous assembleriez un jeu de données de traces de raisonnement sans boucle, lanceriez du SFT ou du RL, et espéreriez que la pression de la perte supprime le comportement sans dégrader tout le reste que le modèle sait. Vous brûleriez des heures de GPU à grimper vers un proxy, davantage de données de maths, plutôt que vers l'intention réelle, qui est « arrête de te répéter ». La programmation de l'espace des poids vous permet d'énoncer l'intention. L'édition a touché un centième de pour cent du modèle ; un fine-tune touche la totalité, et les dégâts collatéraux apparaissent plus tard sous forme de régressions bizarres que personne ne relie à l'entraînement.
Le fine-tuning grimpe vers un proxy de votre intention. La programmation de l'espace des poids vous permet d'énoncer l'intention.
Le second cas concerne la sortie des minima locaux que les méthodes à gradient ne peuvent structurellement pas quitter. PPO a bloqué la voiture contre la rampe parce que l'apprentissage par renforcement explore en perturbant la politique courante, et aucune petite perturbation de « fonce tout droit » ne découvre « recule d'abord pendant deux secondes ». Le raisonnement ne perturbe pas. Il peut sauter vers une solution qualitativement différente, car il opère sur un modèle du problème plutôt que sur une perturbation de la réponse actuelle. Un milliard de pas PPO n'ont pas trouvé ce qu'une passe de raisonnement a trouvé : ce n'est pas un écart d'efficacité, c'est une différence de catégorie.
Troisièmement, la boucle d'itération s'effondre. Le fine-tuning traîne une queue logistique (curation des données, runs d'entraînement, campagnes d'évaluation, tests de non-régression) qui transforme un « petit changement de comportement » en projet de plusieurs jours. Quiconque a fait tourner un grand modèle sur son propre matériel sait combien d'efforts relèvent de la plomberie plutôt que de la modélisation. Une édition de poids s'apparente davantage à un hotfix de code : diagnostiquer, patcher, lancer les évaluations, revenir en arrière si c'est faux. Quand le diagnostic est juste, vous sautez tout le pipeline d'entraînement. Les gains nets se concentrent dans quatre situations :
- La panne est diagnostiquée mais vous n'avez aucune donnée d'entraînement qui exprime le correctif
- Vous avez besoin d'un périmètre chirurgical : changer un comportement sans faire dériver le reste
- Le modèle est coincé dans un minimum local que l'exploration aléatoire ne peut pas franchir
- Vous ne pouvez pas vous offrir un pipeline d'entraînement, ni en GPU ni en temps calendaire
Pourquoi la programmation de l'espace des poids est fragile
Maintenant la douche froide, car il y en a beaucoup. Le point de donnée le plus utile que j'ai vu ne vient pas de l'article : c'est celui d'un praticien qui a tenté la même astuce sur un petit modèle langage naturel vers bash et n'a obtenu aucun gain net. Éditer 1 920 poids a corrigé certaines erreurs de grep et cassé d'autres commandes. C'est le résultat attendu, et c'est le problème profond : les comportements des réseaux entraînés sont enchevêtrés. L'édition sur Qwen a fonctionné parce que le comportement de boucle se trouvait par hasard dans une direction compacte et retirable. Beaucoup de comportements ne le sont pas. Ils sont étalés dans la superposition, les mêmes colonnes portant plusieurs caractéristiques sans rapport, de sorte que soustraire une « direction » revient à retirer une note d'un accord. Vous abîmerez les autres. Personne n'a de théorie permettant de prédire à l'avance quelles pannes sont géométriquement compactes et lesquelles sont étalées ; tant que ce n'est pas le cas, chaque édition de poids est un pari.
Les démos de lecture méritent aussi un rabais. Le raisonnement d'Astra sur les réseaux de jeu s'appuyait sur des statistiques de surface (où se concentrent les poids de la première couche, quels logits de sortie se séparent), et l'identification de langue était en pratique un QCM à trois choix, dont une option, le japonais romanisé, présente une distribution de lettres étonnamment inhabituelle (pas de q, l, v ni x). Du pattern-matching impressionnant ? Absolument. Une preuve de compréhension profonde et native de l'espace des poids ? Moins clair. Le résultat sur la diffusion se retourne dans les deux sens : Astra a dessiné chaque forme sous forme de contour alors que les modèles génèrent des formes pleines, une erreur qui prouve qu'il lisait la géométrie plutôt que de simuler le réseau, mais qui montre aussi que sa « compréhension » peut être structurellement fausse tout en réussissant le test.
Il y a ensuite l'échelle et la provenance. Tous les résultats propres se situent entre 17 000 et 7 millions de poids, le modèle de 0,8 milliard de Qwen faisant figure d'exception, et même l'expérience de lecture des couches intermédiaires a nécessité jusqu'à une centaine d'analyses Python pour aboutir. Personne n'a montré que cela fonctionne sur un modèle de 70 milliards de paramètres, encore moins sur un modèle de pointe, et l'approche naïve, qui consiste à coller les poids dans une fenêtre de contexte, échoue bien avant. Une question inconfortable plane aussi sur l'ensemble : d'où vient cette capacité ? Les LLM étonnamment bons aux échecs se révèlent généralement avoir ingéré beaucoup de notation d'échecs pendant l'entraînement. Si Astra a été entraîné délibérément sur des données de poids, ces résultats disent moins quelque chose sur une compréhension émergente que sur un très bon programme d'études. Nous ne le savons pas vraiment.
Enfin, le bond sur MATH-500 appelle un astérisque. Ce benchmark est saturé par les données d'entraînement depuis des années, et un modèle de base qui obtient 7,9 % échoue presque certainement sur les boucles et le formatage plutôt que sur les maths, ce qui signifie que l'édition a débloqué une capacité latente plutôt que créé une compétence. C'est quand même précieux : débloquer est un vrai gain. Mais c'est une affirmation différente de « l'édition a rendu le modèle meilleur en maths », et elle s'inscrit dans un schéma familier où les benchmarks manquent l'essentiel de ce à quoi ressemble le travail réel.

Éditions de poids en production : à traiter comme des hotfixes
Si vous voulez essayer, et sur les petits modèles, vous devriez, traitez les éditions de poids avec la rigueur qu'on applique à un correctif à chaud sur une base en production. Diffez tout : consignez exactement quels tenseurs ont changé et de combien, car 0,016 % est assez petit pour qu'un bug silencieux dans votre script d'édition reste caché à jamais. Évaluez largement, pas seulement sur le comportement ciblé ; le correctif Qwen a par chance amélioré le suivi d'instructions, mais le signe de cet effet de bord relevait de la chance, et la prochaine fois il pourra aller dans l'autre sens. Gardez le checkpoint de base sacré et versionnez chaque édition comme un patch réversible. Et calibrez vos ambitions : le créneau démontré, ce sont de petits échecs bien compris dans des modèles que vous pouvez évaluer entièrement. Si votre réflexe est de corriger un problème flou d'ambiance dans un modèle de 70 milliards de paramètres en « retirant la mauvaise direction », vous allez découvrir la superposition à la dure.
- Épinglez le checkpoint de base ; stockez les éditions sous forme de diffs, n'écrasez jamais sur place
- Lancez des évaluations larges avant et après, pas seulement le benchmark ciblé
- Privilégiez les pannes à signature nette et reproductible plutôt que les impressions vagues
- Prévoyez des retours arrière : supposez qu'une fraction des éditions casse quelque chose
Ma position honnête : aujourd'hui, c'est un instrument d'interprétabilité et un bistouri de débogage, pas un pipeline de déploiement. Les équipes qui tireront de la valeur en premier ne seront pas celles qui livrent des éditions de poids en production. Ce seront celles qui utilisent un modèle de pointe pour expliquer ce que leurs petits modèles ont appris, en lisant les checkpoints comme on lit déjà les traces de raisonnement, puis en agissant sur ce savoir avec des outils ordinaires, ennuyeux et fiables.
Les gradients ne sont pas morts, ils ont été rétrogradés
Voici où mon argument d'ouverture s'effondre, et je veux être honnête là-dessus. La descente de gradient fait quelque chose que la programmation de l'espace des poids ne peut pas faire : elle apprend à partir de données à grande échelle. Chaque capacité qu'Astra a utilisée pour ces éditions a elle-même été installée par des gradients sur un corpus d'entraînement immense. Le raisonnement peut opérer une chirurgie sur ce qu'un réseau sait ; il ne peut pas enseigner à un réseau la somme du texte humain. L'avenir réaliste n'est pas le remplacement des gradients, mais une division du travail. Les gradients coulent le béton ; la programmation de l'espace des poids fait la menuiserie de finition. Pendant quarante ans, nous avons traité les poids entraînés comme un artefact opaque, une boîte noire qu'on ne pouvait diriger que de l'extérieur. L'idée vraiment nouvelle ici, c'est que la boîte devient lisible, et que ce qui la lit n'est pas nous. Que cela soit rassurant ou inquiétant dépend probablement de la confiance que vous accordiez aux gradients.


