GPT-6 Astra corrige les boucles de Qwen : la précision passe de 7,9 % à 48,1 %

Un modèle local reçoit un problème de mathématiques, commence à raisonner et reste bloqué dans des répétitions. Les jetons sont consommés, l'utilisateur attend, et aucune réponse finale n'arrive. L'équipe du MIT CSAIL a présenté une méthode expérimentale pour corriger ce type de défaillance : charger un autre modèle de langage de trouver la source de la boucle et d'ajuster les paramètres numériques du réseau problématique. Pour un développeur, c'est une piste utile : une faible précision tient parfois au fait que le modèle ne termine pas sa résolution.

Dans l'expérience publiée, GPT-6 Astra a modifié Qwen3.5-0.8B. Après l'intervention, le résultat au test de mathématiques MATH-500 est passé de 7,9 % à 48,1 %. Les auteurs ont baptisé cette approche weight-space programming, c'est-à-dire la programmation par les poids du modèle. Les résultats et les conditions de l'expérience sont détaillés dans la publication des chercheurs.

Ce qui a été réparé exactement

Les poids sont des nombres qui déterminent la façon dont un réseau de neurones traite les données d'entrée. On les modifie en général pendant l'entraînement. Ici, l'agent a eu accès aux paramètres et la possibilité de tester des hypothèses, mais le réentraînement habituel par calcul de gradients lui était interdit.

Sur un exemple simple, le problème se présente ainsi : le modèle a déjà établi la bonne formule, puis il réexplique l'étape précédente et y revient encore une fois. La réponse est coupée lorsque le nombre de jetons autorisé est épuisé. À l'évaluation, un tel essai peut être considéré comme un échec, même si la partie utile de la solution est déjà apparue.

Selon les chercheurs, l'agent a trouvé dans deux couches de Qwen un composant qui entretenait les répétitions et en a réduit la contribution. La modification n'a touché que 0,016 % des paramètres. Cela ressemble à la recherche d'une panne précise : on détermine d'abord où naît le comportement indésirable, puis on vérifie si une petite intervention aide.

Ce qui est intéressant en pratique, c'est la séquence de travail elle-même. L'agent analyse l'architecture du réseau, propose une explication de la défaillance, modifie les paramètres et obtient un retour. Pour une équipe qui exploite son propre modèle, il pourrait s'agir d'un outil de diagnostic supplémentaire. L'expérience ne fournit pas pour l'instant de recette universelle pour corriger toutes les répétitions.

Pourquoi la hausse de précision appelle des réserves

Les auteurs relient explicitement l'amélioration à la disparition des boucles. On ne peut donc pas y voir automatiquement l'apparition de nouvelles connaissances mathématiques. Si le modèle n'arrivait pas auparavant à la réponse finale, supprimer l'obstacle suffit en soi à relever fortement le score.

Pour un produit, la différence est importante. L'utilisateur veut un résultat abouti, et la correction des répétitions peut être très utile. Mais un chef de produit qui promettrait, après une telle intervention, un raisonnement mathématique globalement plus solide devra vérifier cette promesse séparément sur les tâches de son propre service.

L'étude comporte un test révélateur sur un autre petit modèle, Gemma 3 270M. Les chercheurs n'y ont pas obtenu d'amélioration comparable. Ce résultat négatif limite la conclusion : la correction réussie d'une défaillance très marquée ne prouve pas que l'agent ait appris à améliorer de façon fiable n'importe quel réseau.

Par ailleurs, l'absence de réentraînement ne rend pas la procédure gratuite. L'analyse, les exécutions de contrôle et l'évaluation des résultats exigent du calcul. En comparant cette approche à d'autres méthodes de correction, l'équipe devra tenir compte de tous ces coûts. Le prix de l'erreur compte aussi : une petite modification des paramètres doit être évaluée sur le comportement global du modèle, y compris sur les tâches pour lesquelles il a été choisi à l'origine.

Que vérifier sur son propre modèle

Il faut commencer par les journaux des réponses ratées. À quelle fréquence le modèle se répète-t-il ? Combien de requêtes se terminent par l'atteinte de la limite ? Ces cas diffèrent-ils des erreurs ordinaires de calcul ou de faits ? Cet étiquetage aide à comprendre quel problème il s'agit réellement de résoudre.

Il faut ensuite un jeu de tests que l'agent n'utilise pas pour choisir ses modifications. On y comparera la qualité des réponses, la longueur de génération et le temps d'attente avant et après l'intervention. Il est également utile de vérifier séparément les scénarios de travail habituels : l'amélioration d'un test peut s'accompagner de la dégradation d'un autre.

Pour une équipe qui passe par une API fermée, l'édition directe des poids n'est généralement pas possible. Mais la leçon diagnostique s'applique aussi : distinguez les erreurs de connaissance, les erreurs de raisonnement et les réponses inachevées. De cela dépend la suite : changer de modèle, modifier les paramètres de génération ou revoir l'architecture de l'application elle-même. L'expérience du MIT invite à examiner plus attentivement les causes des échecs avant de budgétiser un nouvel entraînement.