NERVE : atténuer les « neurones SQL » de Qwen 27B pour corriger les requêtes 1C sans réentraînement

Une douleur bien connue : vous avez affiné un modèle ouvert sur un domaine étroit, et il se trompe pourtant régulièrement au même endroit. Les nouveaux jeux de données n'aident presque pas, et chaque cycle de collecte de données coûte des semaines. L'auteur d'un article sur Habr a rencontré exactement ce problème avec Qwen 3.8 27B, affinée pour 1C:Entreprise. Le modèle écrit correctement du code dans le langage intégré, mais confond le langage de requêtes de 1C avec SQL : il mélange les tables virtuelles, place les paramètres au mauvais endroit et introduit des constructions qui n'existent pas dans 1C. Les jeux de données supplémentaires ont apporté moins de 1 % de gain d'accuracy.

L'hypothèse : SQL gêne

Les lexèmes des deux langages se ressemblent : SELECT, JOIN, WITH. L'auteur a supposé que la connaissance du vrai SQL poussait le modèle vers une mauvaise réponse. Plutôt que de réentraîner, on peut alors trouver les neurones précis responsables et les affaiblir. C'est ainsi qu'est né le pipeline NERVE.

Ici, un neurone désigne une composante du vecteur intermédiaire du bloc MLP (17 408 par couche dans Qwen 3.8 27B), avec la colonne de la matrice W_down dans laquelle elle écrit. Multiplier la colonne par m revient à multiplier l'activation du neurone par m à chaque token. La valeur 0 désactive le neurone, 0,5 l'affaiblit de moitié. L'architecture ne change pas, et la modification survit à la quantification et à l'export en GGUF. Il y a environ 1,1 million de candidats au total (64 couches), donc une recherche à l'aveugle n'a aucun sens.

Fonctionnement du pipeline

1. On prend des paires « requête correcte / requête erronée », comme pour DPO, environ deux mille. Les réponses coïncidant à 90–95 %, on ne compare que les tokens qui diffèrent, repérés par difflib. Une moyenne sur toute la réponse diluerait le signal.
2. Des hooks placés à l'entrée de chaque down_proj collectent l'activation moyenne des neurones sur ces tokens. Sur l'ensemble des paires, on calcule la moyenne, la statistique t et la cohérence du signe. Le classement se fait selon |t|, afin que deux ou trois paires aberrantes ne créent pas de faux leaders.
3. L'attribution par gradient (« gradient × entrée ») prédit comment le margin évolue, c'est-à-dire à quel point le modèle préfère la bonne réponse à la mauvaise, si le neurone est atténué. Un neurone à contribution négative est considéré comme « fautif ». L'attribution est coûteuse, elle est donc calculée sur 512 paires.
4. La sélection gloutonne essaie les candidats un par un, par-dessus ceux déjà acceptés. Une modification est conservée si le margin augmente d'au moins 0,002 par token et si le nll sur les bonnes réponses ne baisse pas de plus de 2 %. Comme on annule les essais ratés, les prévisions linéaires cumulées deviennent inutiles.

La principale protection contre le surapprentissage : le val est divisé en deux moitiés selon le hash de la requête. Les décisions se prennent sur l'une, le résultat est vérifié sur l'autre. Un ensemble n'est considéré comme confirmé que si le margin augmente sur le contrôle et que le nll ne se dégrade pas au-delà de la tolérance. Les modifications confirmées s'accumulent dans un fichier JSON à côté de la carte et sont exclues des futurs candidats.

Ce qui a été découvert en chemin

Première erreur : la carte était construite sur les tokens différents, alors que la qualité était mesurée sur toute la réponse. L'effet était dilué environ 25 fois. Correction : un même masque de diff pour la carte et pour la vérification. Deuxième constat : amplifier les « bons » neurones dégradait plus souvent le nll, tandis que supprimer les neurones fautifs donnait une hausse stable du margin ; le mode suppress est donc devenu le mode principal. Autre fait observé : une excitation sur les réponses erronées existe presque dans chaque couche, c'est-à-dire que le comportement de type SQL est diffusé sur toute la profondeur du réseau.

Limites et conclusion

Le texte disponible ne contient pas de chiffres finaux : nous ignorons de combien l'accuracy a augmenté sur le contrôle. Il s'agit d'un seul modèle et d'un seul jeu de données ; la méthode repose sur une approximation linéaire qui se brise lorsque les modifications interagissent, d'où la nécessité de la sélection gloutonne. Pour les praticiens, l'idée reste utile : si un modèle affiné présente une erreur persistante de « mélange » avec un domaine voisin, il existe une alternative peu coûteuse à un nouveau cycle de SFT.

Il faut des paires de préférences, un forward-backward sur un échantillon et une vraie moitié de contrôle. Leçon clé : calculez la métrique sur les mêmes tokens que ceux qui ont servi à construire la carte, et vérifiez toujours sur des données n'ayant pas participé à la sélection.