🤖 machine learning

Gauge dependence and structured-output corruption in sign-branched repetition penalties: measurements across models, inference stacks, and alternative repetition controls

Cet article démontre que la pénalité de répétition par branchement de signe, largement utilisée dans les moteurs d'inférence de LLM, est fondamentalement erronée car elle dépend du point zéro arbitraire des logits, provoquant une instabilité massive de la sélection de jetons à travers les modèles et des échecs catastrophiques dans la production de sorties JSON structurées, un problème qui est résolu en appliquant la pénalité aux log-probabilités normalisées plutôt qu'aux logits bruts.

Auteurs originaux : Peter Hollows

Publié 2026-07-14

📖 7 min de lecture🧠 Analyse approfondie

CC BY 4.0

Auteurs originaux : Peter Hollows

Article original sous licence CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Ceci est une explication générée par l'IA de l'article ci-dessous. Elle n'a pas été rédigée ni approuvée par les auteurs. Pour une précision technique, consultez l'article original. Lire la clause de non-responsabilité complète

Imaginez que vous ayez un robot écrivain super intelligent qui adore raconter des histoires. Parfois, il se retrouve coincé dans une boucle, répétant le même mot encore et encore comme un disque rayé. Pour corriger cela, les ingénieurs ont doté le robot d'un bouton de « pénalité de répétition ». L'idée est simple : si le robot essaie de dire un mot qu'il vient d'utiliser, on tourne le bouton pour rendre ce mot moins probable, le forçant ainsi à passer à autre chose.

Pendant des années, presque tous les robots écrivains au monde (de Hugging Face à vLLM ou llama.cpp) ont utilisé exactement le même type de bouton. Mais cet article révèle un secret choquant : ce bouton spécifique est cassé parce qu'il regarde le mauvais chiffre.

La boussole cassée

Pour comprendre le bug, imaginez que le cerveau du robot est une carte géante où chaque mot possible possède un score. Les scores positifs signifient « Je veux vraiment dire ceci », et les scores négatifs signifient « Je ne veux vraiment pas dire cela ». La carte est flexible ; le robot peut faire glisser toute la carte vers la gauche ou la droite (en ajoutant un nombre constant à chaque score) sans changer le mot qu'il choisira ensuite. C'est comme déplacer une ville entière sur une carte ; les rues sont toujours dans le même ordre les unes par rapport aux autres, même si la ville se trouve maintenant dans un autre pays.

Le bouton cassé tente de décider de l'ampleur de la punition d'un mot répété en vérifiant si son score est positif ou négatif.

Si le score est positif, il divise le nombre par un facteur de pénalité (le rendant plus petit).
Si le score est négatif, il multiplie le nombre par le facteur de pénalité (le rendant encore plus négatif).

Voici le problème : la ligne entre « positif » et « négatif » est arbitraire. Parce que le robot peut faire glisser sa carte entière vers la gauche ou la droite sans changer son comportement, un mot qui est « positif » sur un robot peut être « négatif » sur un autre, ou même sur le même robot si l'on déplace légèrement la carte.

L'article prouve que ce « branchement par signe » (vérifier si le nombre est positif ou négatif) regarde une coordonnée que l'entraînement du robot n'a jamais réellement fixée. C'est comme essayer de conduire une voiture en se dirigeant en fonction du fait que le tableau de bord soit actuellement dans la zone « rouge » ou « bleue », alors que tout le tableau de bord peut glisser d'avant en arrière de lui-même.

Le chaos du « Même bouton, résultats différents »

À cause de cette carte glissante, le même réglage sur le bouton (comme 1,3) produit des choses totalement différentes selon les robots.

Sur un robot (comme gpt2), un réglage de 1,3 pourrait punir 84 % des mots répétés.
Sur un autre robot (comme Qwen2.5-Coder-7B), ce même réglage de 1,3 pourrait ne presque pas punir les mots, ou les punir de manière totalement différente.

Les auteurs ont testé cela en prenant un seul robot et en faisant glisser sa carte vers la gauche et la droite. Ils ont découvert qu'avec un réglage standard de 1,3, le robot changeait d'avis sur 58 % à 96 % de ses choix simplement parce que la carte avait glissé un tout petit peu !

Si vous utilisez une pénalité « soustractive » (on se contente de soustraire un nombre), le robot reste le même.
Si vous utilisez le « branchement par signe » multiplicatif standard, le robot devient fou, changeant d'avis sur presque chaque mot qu'il choisit.

Cela signifie que si vous réglez votre robot pour qu'il fonctionne bien avec un réglage de 1,3, vous le réglez en réalité pour qu'il fonctionne avec un « point zéro » accidentel et spécifique à ce robot particulier. Si vous déplacez ce robot sur un autre ordinateur ou si vous mettez à jour son logiciel, ce même réglage pourrait le briser complètement.

Le désastre du JSON

La partie la plus dangereuse de ce bug est qu'il détruit la « sortie structurée ». Il s'agit de lorsque vous demandez au robot d'écrire du code ou du JSON (un format de données spécifique) qui doit suivre des règles strictes, comme fermer chaque accolade { ou ajouter une virgule ,.

Ces règles exigent que le robot répète certains symboles. Mais comme la pénalité regarde les chiffres bruts, elle confond souvent une « règle nécessaire » avec une « mauvaise répétition ».

L'article a testé cela sur 200 schémas JSON réels.
Avec le réglage standard de 1,3, le taux de sorties JSON valides et fonctionnelles s'est effondré, passant de 97 % à seulement 23 %.
Le robot a commencé à briser la grammaire, oubliant de fermer les parenthèses ou manquant des virgules, parce que la pénalité était trop agressive sur les mauvais chiffres.

Ce n'était pas une supposition de simulation ; les auteurs l'ont mesuré directement sur cinq modèles différents, y compris des modèles spécialisés dans le code, et ont constaté le même effondrement dans chaque pile logicielle majeure (Hugging Face, vLLM et llama.cpp).

La solution : Normaliser d'abord

L'article propose une solution simple et prouvée. Au lieu de regarder les chiffres bruts et glissants, la pénalité devrait regarder les probabilités normalisées (le pourcentage de chance réel qu'un mot soit choisi).

Les probabilités sont toujours comprises entre 0 et 1, elles ne glissent donc pas.
Lorsque les auteurs ont appliqué la pénalité à ces nombres normalisés plutôt qu'aux scores bruts, le chaos a disparu.
Le « taux de bascule » (la fréquence à laquelle le robot changeait d'avis juste à cause d'un glissement) est tombé à 0,00.
Le taux de succès du JSON à 1,3 est remonté à 97 %.

Hugging Face possède déjà un outil appelé LogitNormalization qui fait cela, mais il est désactivé par défaut et s'exécute après la pénalité. L'article suggère que si vous l'activez et l'exécutez avant la pénalité, vous obtenez un résultat stable et fiable qui fonctionne de la même manière sur tous les modèles.

L'essentiel à retenir

La « pénalité de répétition multiplicative » qui est actuellement livrée avec presque tous les moteurs d'IA est fondamentalement défectueuse car elle repose sur une ligne numérique qui peut glisser. Ce n'est pas un bouton universel ; c'est un cadran cassé qui donne des résultats différents sur chaque machine.

Ce qu'elle fait : Elle provoque des changements massifs et imprévisibles dans ce que l'IA écrit (changeant 58 à 96 % des choix) et brise les formats structurés comme le JSON (faisant chuter la validité de 97 % à 23 %).
Ce qu'elle n'est pas : Ce n'est pas une fonctionnalité ; c'est un bug qui a été copié dans l'industrie pendant des années.
La solution : Normalisez les nombres d'abord. Cela élimine le problème de la carte glissante et fait en sorte que la pénalité se comporte de manière cohérente, quel que soit le robot que vous utilisez.

Les auteurs ont mesuré cela sur plusieurs modèles et piles logicielles, et les résultats sont clairs : le standard actuel est cassé, et la solution est prête à être déployée.

Résumé Technique : Dépendance à la Jauge et Corruption des Sorties Structurées dans les Pénalités de Répétition à Branchement de Signe

Énoncé du Problème
L'article identifie une faille fondamentale dans la pénalité de répétition multiplicative largement déployée dans l'écosystème d'inférence des LLM (incluant Hugging Face, vLLM et llama.cpp). L'opérateur standard, hérité du modèle CTRL, applique une pénalité aux jetons précédemment vus en effectuant un branchement sur le signe de leurs logits bruts : diviser les logits positifs par un facteur $\theta$ et multiplier les logits négatifs par $\theta$ .

Le problème central est que l'emplacement du point zéro des logits est arbitraire. La fonction softmax est invariante par translation ( $\text{softmax}(z+c) = \text{softmax}(z)$ ), ce qui signifie que l'objectif d'entraînement d'un modèle contraint la distribution de probabilité mais laisse les valeurs absolues des logits (la « jauge ») sans contrainte. Par conséquent, la branche de signe de la pénalité opère sur une coordonnée que le processus d'entraînement ne fixe pas. Cela conduit à deux conséquences négatives mesurables :

Comportement Indéfini : Un réglage de pénalité de répétition fixe (par exemple, $\theta=1,3$ ) effectue une opération mathématique différente sur différents modèles (ou même sur le même modèle avec un biais décalé), car la fraction de jetons tombant sur la branche « division » versus la branche « multiplication » varie considérablement selon le point zéro des logits du modèle.
Corruption des Sorties Structurées : La pénalité supprime de manière indiscriminée des jetons requis par la grammaire (par exemple, les accolades de fermeture en JSON, l'indentation dans le code) simplement parce qu'ils sont déjà apparus. Cela provoque une chute catastrophique de la validité des sorties structurées.

Méthodologie
Les auteurs mènent une série d'expériences contrôlées sur cinq modèles (allant de gpt2 à Qwen2.5-7B, incluant des variantes base et RLHF) et deux piles d'inférence (vLLM et llama.cpp) pour isoler les effets de la branche de signe.

Expérience de Basculement de Jauge (Conséquence 1) : Les auteurs décodent le même modèle deux fois avec des graines aléatoires et des entrées identiques, mais en ajoutant une constante $c$ à tous les logits (simulant un décalage dans le biais du modèle). Pour une intervention bien définie, la sélection de jeton greedy devrait rester identique. Ils mesurent le « taux de basculement » (fraction de positions où le jeton diffère) à $\theta=1,3$ par rapport aux contrôles (pénalités soustractives et pénalités normalisées).
Évaluation des Sorties Structurées (Conséquence 2) : Les auteurs évaluent l'impact de la pénalité sur deux tâches :
- HumanEval : Génération de code où des délimiteurs spécifiques sont requis.
- JSONSchemaBench : Génération d'objets JSON contre 200 schémas réels.
  Ils mesurent le taux de sortie valide, conforme au schéma, et la fréquence des « basculements de délimiteurs » (où un jeton structurel requis est incorrectement supprimé).
Vérification Trans-Stack : Les expériences sont répliquées dans vLLM et llama.cpp en utilisant leurs échantillonneurs natifs pour confirmer que le problème est inhérent à l'implémentation de l'opérateur.
Correction Proposée : Les auteurs testent une variante où la pénalité est appliquée aux log-probabilités normalisées ( $\log p_i$ ) plutôt qu'aux logits bruts ( $z_i$ ), éliminant ainsi la branche de signe puisque toutes les log-probabilités sont non positives.

Résultats Clés

Dépendance à la Jauge : La pénalité standard à branche de signe est hautement sensible au point zéro des logits.
- À travers cinq checkpoints réels, la fraction de jetons vus avec des logits positifs (et donc divisés) varie de 0,17 (gpt2) à 0,95 (Qwen2.5-Coder-7B).
- Dans l'expérience de basculement contrôlée, décaler le point zéro des logits par une constante de $\pm 5$ provoque la bascule de 58 % à 96 % des jetons greedy à $\theta=1,3$ . En revanche, les pénalités soustractives et les pénalités normalisées présentent un taux de basculement de 0 %.
- Le « coût » de l'intervention (mesuré en log-vraisemblance) varie d'un facteur 4,1 selon la jauge, tandis que les contrôles restent constants.
Échec des Sorties Structurées : La pénalité dégrade sévèrement la génération structurée.
- Sur JSONSchemaBench, l'application de $\theta=1,3$ fait chuter le taux de sortie JSON valide de 97 % à 23 %.
- Sur HumanEval, la pénalité provoque des basculements sur les jetons structurels avec une précision équilibrée de 0,999 contre une prédiction théorique, confirmant que le mécanisme est piloté par la suppression des délimiteurs nécessaires.
Prévalence dans l'Écosystème : L'implémentation de la branche de signe se retrouve dans Hugging Face, vLLM, llama.cpp et douze autres moteurs (ex: TGI, SGLang, Ollama). Le problème n'est pas isolé à une seule bibliothèque mais est un artefact systémique de la conception de l'opérateur.
Efficacité de la Normalisation : Appliquer la pénalité aux log-probabilités normalisées ( $\log \text{softmax}(z)$ $lo g softmax (z)$ ) élimine les deux effets.
- Le taux de basculement de jauge tombe à 0,00.
- La validité JSON à $\theta=1,3$ remonte à 97 %.
- La corruption des délimiteurs diminue d'environ 80x.

Signification et Revendications
L'article soutient que la pénalité de répétition multiplicative par défaut n'est pas un « bouton scalaire propre » mais une intervention au moment de l'inférence dont le comportement est partiellement déterminé par un artefact d'entraînement non contraint (le point zéro des logits).

Manque de Portabilité : Une valeur $\theta$ fixe ne représente pas la même opération d'un modèle à l'autre, rendant le réglage par modèle et par tâche nécessaire, même pour un paramètre « standard ».
Conséquences Imprévues : La pénalité corrompt la génération structurée en traitant les nécessités grammaticales (qui doivent se répéter) comme des répétitions indésirables, un mode de défaillance particulièrement aigu pour la génération de code et de JSON.
Solution : Les auteurs démontrent que normaliser les logits avant d'appliquer la pénalité (ou utiliser des pénalités soustractives) élimine la dépendance à la jauge et la corruption des sorties structurées. Ils notent que Hugging Face fournit déjà un opérateur LogitNormalization, mais qu'il est actuellement désactivé par défaut et appliqué après la pénalité, ce qui échoue à résoudre le problème.

L'article conclut que, bien que les pénalités de répétition soient des solutions de contournement nécessaires au comportement des modèles, l'implémentation standard actuelle introduit des « arêtes vives » qui compromettent la fiabilité. Les auteurs appellent les mainteneurs de piles à adopter soit la famille des pénalités soustractives, soit à réordonner la pénalité multiplicative pour qu'elle opère sur les log-probabilités normalisées.

La boussole cassée

Le chaos du « Même bouton, résultats différents »

Le désastre du JSON

La solution : Normaliser d'abord

L'essentiel à retenir

Articles similaires