GPT-6 Astra corrige les poids de Qwen et porte son score sur MATH-500 à 48,1 %

Le modèle déroule un long raisonnement, répète sans cesse la même étape et ne s'arrête que parce qu'il a atteint la limite de tokens. Pour les développeurs, la panne est familière : la requête a été payée, l'utilisateur attend, mais aucun résultat utile n'arrive. Des chercheurs du MIT CSAIL ont présenté une façon d'intervenir sur ce dysfonctionnement : confier à un autre modèle de langage la modification des poids du réseau défaillant.

Dans leur expérience, GPT-6 Astra a corrigé Qwen3.5-0.8B en modifiant 0,016 % de ses paramètres. Son score sur MATH-500 est passé de 7,9 % à 48,1 %. L'intérêt pratique réside dans la possibilité de rechercher une cause précise de dysfonctionnement à l'intérieur du modèle. Il est toutefois trop tôt pour en conclure que « n'importe quel réseau neuronal se répare en une seule requête ».

Ce qu'Astra a précisément corrigé

Selon le compte rendu des chercheurs, Astra avait accès aux poids via Python et pouvait tester le comportement de Qwen sur des problèmes d'entraînement. L'entraînement par gradient était interdit. Le meilleur résultat a été obtenu avec un budget de 50 exécutions d'évaluation.

Astra a associé les répétitions à une direction particulière dans les sorties de deux couches internes, puis ajusté les poids correspondants. La proportion de réponses sur MATH-500 qui atteignaient la limite de longueur est passée de 93 % à 33,1 %. Les paramètres de génération sont restés identiques pour la comparaison.

Imaginez une calculatrice capable d'effectuer les calculs, mais qui relance l'étape précédente après chaque opération. Supprimer ce dysfonctionnement ferait augmenter la proportion de réponses correctes menées à terme, sans ajouter de nouvelles règles d'arithmétique. Cette analogie aide à comprendre le résultat, même si l'architecture d'un modèle de langage est bien plus complexe que celle d'une calculatrice.

Les auteurs ont également testé séparément Gemma 3 270M, qui s'enfermait rarement dans des boucles. La méthode n'a pas permis d'améliorer de façon convaincante ses résultats en mathématiques. Le principal enseignement de l'étude concerne donc la suppression des obstacles à une capacité de résolution de problèmes déjà présente.

Pourquoi un taux de réussite ne suffit pas

Pour une équipe qui utilise un modèle local, cette approche présente avant tout un intérêt diagnostique. Avant de choisir entre un changement de modèle, un nouveau prompt et un entraînement supplémentaire, il est utile de comprendre quelles erreurs dominent. Répéter du texte, effectuer un calcul erroné ou ignorer une exigence de l'utilisateur se traduit de la même manière dans la métrique finale : la tâche est un échec. Pourtant, ces problèmes peuvent nécessiter des corrections différentes.

Supposons que vous développiez un assistant chargé de traiter des demandes. Rassemblez des exemples de réponses ratées et examinez précisément leurs défaillances. Dans certains cas, le modèle peut tourner en rond ; dans d'autres, inventer des informations avec assurance ; dans d'autres encore, perdre le format demandé. Si vous regroupez tout dans un seul indicateur de qualité, même une modification réussie sera difficile à expliquer.

Pour les répétitions, il est pertinent de mesurer séparément la proportion de réponses menées à terme, la longueur des générations et le temps d'attente. Les erreurs de fond nécessitent une vérification de l'exactitude. Les problèmes de format exigent un contrôle de la structure des réponses. Cette analyse aide à définir la correction à apporter et à fixer à l'avance les critères de réussite.

Elle change aussi la discussion avec l'équipe produit. Une hausse du score à un test ne montre pas, à elle seule, que l'assistant est devenu plus utile au client. Mieux vaut choisir à l'avance un indicateur opérationnel : par exemple, combien de demandes le système a traitées correctement et combien d'entre elles ont nécessité une nouvelle exécution.

Comment tester ce type de correction sur son propre modèle

Si une équipe décide de reproduire l'approche, il est raisonnable de commencer avec une copie distincte du modèle et un petit ensemble de défaillances bien analysées. Il faut conserver les poids d'origine, les paramètres de génération et les résultats : sinon, la comparaison se transforme vite en débat d'impressions.

Les problèmes de contrôle doivent être séparés des exemples utilisés pour mettre au point la correction. Il faut ensuite tester le scénario problématique, mais aussi les requêtes habituelles en conditions de travail. Par exemple, supprimer les répétitions chez un assistant de support doit s'accompagner de vérifications de l'exactitude factuelle, du respect des instructions et du bien-fondé des refus. Il s'agit d'une procédure de vérification proposée ici, et non d'un résultat de l'expérience du MIT.

Pour les développeurs qui ont accès aux poids, cette nouvelle ouvre une piste d'expérimentation. Pour les équipes qui passent par une API fermée, le bénéfice immédiat consiste à mieux analyser leurs propres défaillances et à évaluer les corrections du fournisseur. Quant aux fondateurs, mieux vaut éviter de revoir prématurément leur budget d'entraînement : il faut d'abord démontrer qu'une correction précise améliore durablement leur propre produit.