Édition des poids IA : mesurer le vrai progrès

Une petite modification, un grand écart de résultats

Les chercheurs ont demandé à GPT-6 Astra de modifier directement les poids de Qwen3.5-0.8B pour améliorer ses performances en mathématiques. La méthode ne ressemble pas à une mise à jour par gradients, ni à une boucle d'entraînement classique. Astra a identifié une direction liée à une boucle de raisonnement - ancrée dans les réseaux MLP des couches 15 et 19 - puis a retiré cette direction de 64 colonnes de sortie dans chacune de ces couches.

Au total, l'intervention touche 131 072 poids. Rapporté aux environ 800 millions de poids du modèle, on parle d'environ 0,016 %. Après une série d'essais, une modification donne des résultats marquants : sur MATH-500, le score passe de 7,9 % à 48,1 %. Sur GSM8K, de 13,8 % à 67,1 %. Et sur IFEval (qui mesure le respect des consignes), de 21,0 % à 62,3 %.

Ces chiffres sont ceux de l'expérience - mais ils ne prouvent pas, à eux seuls, que le modèle "a appris les mathématiques". L'élément clé, c'est le comportement initial. Avant modification, Qwen avait tendance à tourner en boucle. Sur les 96 premières réponses d'entraînement, 85 atteignaient la limite de 32 768 jetons. Sur MATH-500, la part des réponses interrompues à cette limite passe de 93 % à 33 % après la modification retenue.

Le score a surtout progressé quand le modèle a pu finir

Les essais intermédiaires donnent une piste directe. Avant la modification, avec 10 passes, MATH-500 est à 12,3 % et 87,2 % des réponses finissent encore à la limite de jetons. Avec 25 passes, le score atteint 14,1 %, mais 86,4 % des réponses sont toujours interrompues. Les gains décollent surtout quand la boucle est vraiment réduite.

Donc non : le modèle ne s'améliore pas "en apprenant progressivement" au fil des modifications. Il échoue d'abord de la même façon, puis il arrive davantage à terminer. Et un test qui ne compte que la fin de la réponse ne peut pas "récompenser" un raisonnement qui se répète jusqu'à épuisement du temps ou du budget de calcul.

Le gain en suivi des consignes colle aussi à cette lecture : la boucle n'était pas seulement un problème de mathématiques. Elle empêchait aussi le modèle de produire une sortie finale exploitable sur d'autres tâches. Autrement dit, lire le score sans regarder les mesures de terminaison revient à prendre une partie du problème pour la solution.

Formuler le défaut avant d'interpréter le résultat

La règle simple est la suivante : un correctif de blocage rend accessible une capacité déjà présente ; un apprentissage ajoute ou améliore une capacité qui manquait. En pratique, les deux peuvent se superposer. Le point, c'est de savoir ce qui explique l'essentiel du gain.

Commencez donc par décrire le défaut en une phrase, en utilisant les termes du système. Par exemple : « Le modèle répète une étape jusqu'à la limite de génération » ou « Le service relance la requête jusqu'à l'expiration du délai de la passerelle ». Cette phrase devient une hypothèse testable. Vous devez pouvoir définir un indicateur qui dit clairement si le défaut apparaît ou non.

Sans ça, le score agrégé mélange plusieurs causes possibles : incapacité à résoudre le problème, interruption, non-respect du format, ou défaillance d'une dépendance. Si vous ne séparez pas ces causes, une variation globale ne vous apprend pas ce qui a changé.

Utiliser un groupe de contrôle où le blocage est rare

L'expérience sur Gemma 3 270M apporte une comparaison utile. Les chercheurs indiquent que seulement 8,5 % des réponses atteignent la limite de jetons, contre 93 % pour Qwen avant modification. Ils appliquent aussi la même approche d'édition directe des poids, mais sur MATH-500 le score ne passe que de 6,8 % à 7,7 % au mieux : pas de hausse comparable.

Les auteurs rapportent que les erreurs de Gemma viennent plutôt de calculs faux ou d'algèbre invalide, sans composant unique à neutraliser. Cette comparaison ne raconte pas toute l'histoire interne des deux modèles, mais elle renforce une interprétation : la modification aide surtout quand le défaut ciblé est fréquent. Si un système boucle presque jamais, corriger ce type de boucle ne peut pas produire un énorme gain.

Même logique côté logiciel. Comparez les résultats avant et après correctif, puis regardez un scénario similaire où le comportement supprimé était déjà rare. Si le "parcours témoin" ne bouge pas, mais que le parcours ciblé progresse nettement - notamment en termes de sorties complètes - vous avez des raisons solides de penser que vous avez levé un obstacle plutôt que ajouté une compétence générale.

Suivre le score et le défaut sur les mêmes cas

Le minimum utile, c'est un tableau qui relie le résultat final au mécanisme supposé l'avoir empêché. Pour un modèle, ça peut inclure : le taux de réponses correctes, le taux d'interruption à la limite de jetons, et la proportion de réponses qui respectent le format attendu. Pour une API : taux de succès, délais d'expiration, répétitions, et erreurs renvoyées par les dépendances.

Ces indicateurs doivent être mesurés sur les mêmes cas de test, avant et après la modification. Sinon, vous comparez des échantillons différents et vous risquez d'attribuer au correctif une variation qui vient juste de la composition des tests. Ajoutez aussi une contrainte : conservez le budget de calcul, les limites de temps et les critères de notation. Si vous changez tout en même temps, vous rendez l'explication beaucoup plus difficile.

Un relevé de départ peut tenir sur quelques lignes :

• Résultat métier ou score : réponse correcte, requête traitée ou consigne respectée.
• Taux du blocage suspecté : boucle détectée, délai dépassé ou retour prématuré.
• Taux de terminaison : part des cas qui produisent une sortie complète.
• Coût par cas : jetons générés, temps de calcul ou appels effectués.
• Résultat du groupe témoin : comportement comparable où le blocage était peu fréquent.

Le coût mérite vraiment sa place. Une réponse peut devenir "réussie" parce qu'elle a été générée beaucoup plus longtemps, ce qui améliore le score... tout en rendant le système trop lent ou trop cher pour un usage réel. L'indicateur pertinent dépend donc de votre contexte : démo ponctuelle versus déploiement à grande échelle.

Lire les évolutions conjointement

Ensuite, interprétez les variations ensemble. Ne commentez pas seulement le score.

• Le score augmente et le défaut diminue fortement : le système est probablement moins entravé. C'est bon signe, mais ça ne prouve pas encore une compétence nouvelle.
• Le score augmente alors que le défaut reste stable : il y a peut-être eu un progrès ailleurs, ou un autre mécanisme a bougé. Reconsidérez les erreurs restantes et rejouez l'évaluation dans des conditions comparables.
• Le défaut diminue, mais le score bouge peu : le blocage était bien réel, mais ce n'était probablement pas la principale cause des erreurs, ou le test capte mal l'effet du correctif.
• Le score et le défaut ne changent pas : l'hypothèse initiale était peut-être fausse, ou la modification n'a pas touché le mécanisme visé.

Cette lecture évite de transformer une corrélation en explication "définitive". Elle sert aussi à décider la suite. Si les réponses finissent désormais, mais restent fausses, le problème n'est plus surtout la terminaison : il faut chercher du côté des lacunes de raisonnement, des données, du code ou de la conception.

Livrer un déblocage sans le présenter comme un apprentissage

Un défaut qui empêche le système de terminer devrait souvent être corrigé, même si ça ne crée aucune "capacité" nouvelle. Une boucle inutile gaspille du calcul et retarde les réponses. Dans un service, des répétitions sans limite épuisent le délai, augmentent la charge sur les dépendances et dégradent l'expérience utilisateur. Supprimer ce comportement a donc souvent une vraie valeur opérationnelle.

Prenez une API qui, après un délai dépassé, relance indéfiniment le même appel jusqu'à ce que la passerelle coupe la connexion. Si une correction stoppe les relances au bon moment, les utilisateurs peuvent enfin recevoir les réponses déjà produites par le service. Le taux de réussite monte, mais les cas réellement erronés ne deviennent pas meilleurs pour autant. La documentation doit faire la différence entre "fiabilité" et "apprentissage".

Même logique avec une fonction qui retourne trop tôt sur une entrée inhabituelle : une fois corrigée, certains tests débloquent et passent. Là, vous avez surtout amélioré la fiabilité. En revanche, si la branche nécessaire pour traiter correctement cette entrée manque toujours, le système n'a pas "appris" : vous verrez juste le défaut autrement, au lieu de le masquer par un délai.

Transformer les erreurs restantes en plan de travail

Une fois le blocage réduit, revenez aux cas qui échouent encore et classez-les par cause. Pour un modèle, séparez les réponses incomplètes des raisonnements terminés mais faux. Pour un produit logiciel : erreurs de validation, cas non implémentés, échecs de dépendances. Cette étape évite de traiter tous les échecs avec le même marteau.

Ensuite, la suite peut venir de la qualité des données, d'un entraînement supplémentaire, d'une modification d'algorithme, ou d'une règle métier manquante. Le choix dépend de ce que vous observez, du coût, et du risque de régression. Ajouter de l'entraînement à un problème de boucle peut être inefficace : si une branche de code n'existe pas (ou ne s'exécute pas), modifier les poids ne résoudra pas forcément le problème.

Avant de publier, rendez visibles : le score, le taux du défaut ciblé, et le résultat du groupe de contrôle. Si les deux premiers évoluent ensemble, vous pouvez dire que vous avez supprimé un obstacle. Si le score progresse sans variation claire du défaut, présentez cette évolution comme une piste à vérifier - pas comme une preuve d'apprentissage. Ce réflexe rend les annonces moins "spectaculaires", mais les décisions de produit plus sûres.