Qwen 3.8 27B identifie trois jeux à partir des poids de réseaux de neurones sur un simple ordinateur portable

Pour un humain, les poids d'un réseau de neurones ressemblent d'ordinaire à un gigantesque tableau de nombres décimaux. Pour comprendre ce qu'un modèle a appris, l'ingénieur l'exécute sur des données de test, trace des graphiques d'activations ou analyse l'architecture avec des outils spécialisés. Une nouvelle expérience montre une autre voie : on peut simplement présenter à un modèle de langage les poids d'un petit réseau et lui demander d'expliquer ce qu'il fait.

Simon Willison a testé ce scénario avec Qwen 3.8 27B, exécuté localement sur un ordinateur portable. Le modèle a reçu les paramètres de quatre petits agents de jeu et une même question : pour quel jeu ce réseau a-t-il été entraîné ? Pas de Python, pas de calculatrice, pas d'exécution du modèle : seulement une longue requête remplie de nombres.

Le résultat s'est révélé étonnamment solide. Qwen a correctement identifié Pac-Man, Pong et Breakout. Pour Freeway, elle s'est trompée, y voyant une variante de Pac-Man. Ainsi, le modèle local a résolu trois tâches sur quatre, bien que chaque analyse ait pris de 46 minutes à plus d'une heure.

Ce que le modèle a concrètement fait

Imaginons un petit réseau qui pilote la raquette dans Breakout. Certaines entrées décrivent les cases du terrain de jeu, tandis que d'autres couches relient la position de la balle aux commandes « gauche » et « droite ». Après l'entraînement, ces dépendances restent inscrites dans les matrices de poids.

Qwen a tenté de les reconstituer à la main : elle a cherché les coefficients élevés, les a rapprochés des coordonnées des cases et a vérifié quels objets pouvaient influencer les actions de l'agent. Pour Breakout, elle est parvenue à une image correcte : la raquette se trouve en bas, se déplace horizontalement et renvoie la balle vers les briques. Son niveau de confiance était de 88 %.

Pour Pong, le modèle a décrit une raquette verticale à droite et une balle traversant le terrain, avec une confiance de 75 %. Pour Pac-Man, il a reconnu un labyrinthe, des objectifs et des menaces mobiles, avec une confiance de 72 %. Il ne s'agit pas d'une simple devinette du nom d'après le format de la requête : les quatre tâches ne différaient que par les jeux de poids.

Pourquoi c'est important pour les développeurs

L'intérêt pratique n'est pas de remplacer le débogueur par un chatbot. Il est bien plus utile de pouvoir obtenir rapidement une première hypothèse sur un modèle inconnu ou endommagé. Un ingénieur peut par exemple demander à un LLM de repérer des connexions anormalement fortes, d'expliquer le rôle d'une petite couche ou de comparer deux versions de poids après un réentraînement.

Une telle approche pourrait servir à l'audit de petits modèles, à l'analyse de régressions et à l'étude de composants neuronaux dont la documentation a été perdue. Un modèle de langage est capable de relier des nombres à des concepts d'ingénierie compréhensibles et d'indiquer où regarder ensuite. Mais sa conclusion devra de toute façon être vérifiée en exécutant le modèle et avec les outils de diagnostic habituels.

Il existe aussi un scénario plus audacieux : l'édition des poids sans véritable entraînement. Les auteurs du travail d'origine affirment que GPT-6 Astra a modifié 0,016 % des paramètres de Qwen3.5-0.8B et fait passer son score sur MATH-500 de 7,9 % à 48,1 %. Toutefois, des critiques soulignent qu'une partie de ces expériences implique du code et des opérations familières aux chercheurs en ML. Mieux vaut donc considérer la lecture des poids sans outils et la correction automatique d'un modèle comme deux problèmes distincts.

Où se situe la limite

On ne peut pas encore qualifier cette expérience de méthode fiable de rétro-ingénierie. Les tests ont porté sur des réseaux de jeu compacts, aux entrées claires et au nombre de réponses possibles réduit. Même dans ces conditions, Qwen s'est trompée sur un jeu sur quatre. L'analyse de chaque exemple a exigé des dizaines de milliers de tokens et près d'une heure de calcul, et le fil du raisonnement est par endroits difficile à vérifier.

Pour les grands modèles de langage, la tâche est bien plus ardue : on ne peut pas faire tenir des milliards de paramètres dans une requête, et un fragment isolé de poids a rarement un sens univoque. De plus, un texte assuré du modèle ne garantit pas une interprétation correcte.

La conclusion pratique est simple : considérer le LLM comme un outil d'analyse complémentaire, non comme un substitut à l'expérimentation. Il vaut mieux commencer par de petits réseaux, des exemples de contrôle connus d'avance et des questions précises. Si le modèle détecte de façon stable des régularités, ses conclusions peuvent guider le choix de la vérification suivante. Parler de la fin du code source est encore prématuré, mais une nouvelle classe d'outils d'audit des réseaux de neurones commence déjà à se dessiner.