🤖 machine learning

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

Dieses Paper zeigt auf, dass die weit verbreitete, zeichenbasierte Repetitionsstrafe (sign-branching repetition penalty) in LLM-Inferenz-Engines grundlegend fehlerhaft ist, da sie vom willkürlichen Logit-Nullpunkt abhängt, was zu massiver Instabilität bei der Token-Auswahl über verschiedene Modelle hinweg und katastrophalen Fehlern bei strukturierten JSON-Ausgaben führt – ein Problem, das durch die Anwendung der Strafe auf normalisierte Log-Wahrscheinlichkeiten anstelle von Roh-Logits gelöst wird.

Ursprüngliche Autoren: Peter Hollows

Veröffentlicht 2026-07-14

📖 6 Min. Lesezeit🧠 Tiefgang

CC BY 4.0

Ursprüngliche Autoren: Peter Hollows

Originalarbeit lizenziert unter CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Dies ist eine KI-generierte Erklärung des untenstehenden Papers. Sie wurde nicht von den Autoren verfasst oder gebilligt. Für technische Genauigkeit konsultieren Sie das Originalpaper. Vollständigen Haftungsausschluss lesen

Stellen Sie sich vor, Sie hätten einen superintelligenten Roboter-Schreiber, der es liebt, Geschichten zu erzählen. Manchmal gerät er in eine Endlosschleife und wiederholt dasselbe Wort immer und immer wieder wie eine kaputte Schallplatte. Um dies zu beheben, haben Ingenieure dem Roboter einen „Repetitions-Penalty-Regler“ gegeben. Die Idee ist simpel: Wenn der Roboter versucht, ein Wort zu sagen, das er gerade erst benutzt hat, wird der Regler hochgedreht, um dieses Wort weniger wahrscheinlich zu machen, damit der Roboter weitermachen kann.

Jahrelang hat fast jeder Roboter-Schreiber der Welt (von Huger Face über vLLM bis hin zu llama.cpp) exakt dieselbe Art von Regler verwendet. Doch dieses Paper enthüllt ein schockierendes Geheimnis: Dieser spezifische Regler ist kaputt, weil er auf die falsche Zahl schaut.

Der kaputte Kompass

Um den Fehler zu verstehen, stellen Sie sich vor, das Gehirn des Roboters ist eine riesige Landkarte, auf der jedes mögliche Wort einen Wert hat. Positive Werte bedeuten „Ich will das unbedingt sagen“, und negative Werte bedeuten „Ich will das gar nicht“. Die Landkarte ist flexibel; der Roboter kann die gesamte Karte nach links oder rechts verschieben (indem er eine Konstante zu jedem Wert addiert), ohne zu ändern, welches Wort er als Nächstes wählt. Es ist, als würde man eine ganze Stadt auf einer Karte verschieben; die Straßen liegen immer noch in der gleichen relativen Ordnung zueinander, selbst wenn die Stadt nun in einem anderen Land liegt.

Der kaputte Regler versucht zu entscheiden, wie stark ein wiederholtes Wort bestraft werden soll, indem er prüft, ob sein Wert positiv oder negativ ist.

Wenn der Wert positiv ist, teilt er die Zahl durch einen Straffaktor (was sie kleiner macht).
Wenn der Wert negativ ist, multipliziert er die Zahl mit dem Straffaktor (was sie noch negativer macht).

Hier liegt das Problem: Die Grenze zwischen „positiv“ und „negativ“ ist willkürlich. Da der Roboter seine gesamte Karte nach links oder rechts verschieben kann, ohne sein Verhalten zu ändern, kann ein Wort bei einem Roboter „positiv“ sein und bei einem anderen „negativ“ – oder sogar beim selben Roboter, wenn man die Karte leicht verschiebt.

Dieses „Vorzeichen-Verzweigungs“-Problem (das Prüfen, ob eine Zahl positiv oder negativ ist) blickt auf eine Koordinate, die der Roboter während seines Trainings nie wirklich fixiert hat. Es ist, als würde man versuchen, ein Auto zu steuern, indem man danach lenkt, ob das Armaturenbrett gerade in der „roten“ oder „blauen“ Zone ist, obwohl sich das ganze Armaturenbrett von selbst nach vorne oder hinten verschieben kann.

Das Chaos von „Gleicher Regler, andere Ergebnisse“

Wegen dieser verschiebbaren Landkarte bewirkt dieselbe Einstellung am Regler (wie zum Beispiel 1,3) bei verschiedenen Robotern völlig unterschiedliche Dinge.

Bei einem Roboter (wie gpt2) bestraft eine Einstellung von 1,3 vielleicht 84 % der wiederholten Wörter.
Bei einem anderen Roboter (wie Qwen2.5-Coder-7B) bestraft dieselbe 1,3-Einstellung fast gar keine der Wörter oder bestraft sie auf eine völlig andere Weise.

Die Autoren testeten dies, indem sie einen einzelnen Roboter nahmen und seine Landkarte nach links und rechts verschoben. Sie fanden heraus, dass der Roboter mit einer Standardeinstellung von 1,3 seine Meinung bei 58 % bis 96 % seiner Entscheidungen änderte, nur weil die Landkarte ein winziges Stück verrutschte!

Wenn man einen „subtraktiven“ Penalty verwendet (also einfach eine Zahl abzieht), bleibt der Roboter gleich.
Wenn man den standardmäßigen „multiplikativen“ Vorzeichen-Check verwendet, dreht der Roboter völlig durch und ändert seine Entscheidung bei fast jedem Wort, das er wählt.

Das bedeutet: Wenn Sie Ihren Roboter so feinabstimmen, dass er mit einer Einstellung von 1,3 gut funktioniert, stimmen Sie ihn eigentlich auf den spezifischen, zufälligen „Nullpunkt“ dieses speziellen Roboters ab. Wenn Sie diesen Roboter auf einen anderen Computer bewegen oder seine Software aktualisieren, könnte dieselbe Einstellung ihn komplett unbrauchbar machen.

Die JSON-Katastrophe

Der gefährlichste Teil dieses Fehlers ist, dass er „strukturierte Ausgaben“ zerstört. Dies ist der Fall, wenn man den Roboter bittet, Code oder JSON (ein spezifisches Datenformat) zu schreiben, das strengen Regeln folgen muss, wie etwa das Schließen jeder geschweiften Klammer { oder das Hinzufügen eines Kommas ,.

Diese Regeln erfordern, dass der Roboter bestimmte Symbole wiederholt. Aber da der Penalty auf die Rohwerte schaut, hält er oft eine „notwendige Regel“ für eine „schlechte Wiederholung“.

Das Paper testete dies an 200 realen JSON-Schemas.
Mit der Standardeinstellung von 1,3 stürzte die Rate der gültigen, funktionierenden JSON-Ausgaben von 97 % auf nur noch 23 % ab.
Der Roboter begann, die Grammatik zu brechen, vergaß Klammern zu schließen oder ließ Kommas weg, weil der Penalty bei den falschen Zahlen zu aggressiv war.

Dies war keine Simulation, sondern die Autoren haben dies direkt an fünf verschiedenen Modellen, einschließlich spezialisierter Code-Modelle, gemessen und sahen denselben Absturz in jedem großen Software-Stack (Hugging Face, vLLM und llama.cpp).

Die Lösung: Zuerst normalisieren

Das Paper bietet eine einfache, bewährte Lösung an. Anstatt auf die rohen, verschiebbaren Zahlen zu schauen, sollte der Penalty auf die normalisierten Wahrscheinlichkeiten (die tatsächliche prozentuale Chance, dass ein Wort gewählt wird) schauen.

Wahrscheinlichkeiten liegen immer zwischen 0 und 1, daher verschieben sie sich nicht.
Als die Autoren den Penalty auf diese normalisierten Zahlen anwandten statt auf die Rohwerte, verschwand das Chaos.
Die „Flip-Rate“ (wie oft der Roboter seine Meinung änderte, nur weil die Karte verrutschte) sank auf 0,00.
Die JSON-Erfolgsrate bei 1,3 sprang wieder auf 97 % zurück.

Hugging Face besitzt bereits ein Werkzeug namens LogitNormalization, das dies tut, aber es ist standardmäßig ausgeschaltet und läuft nach dem Penalty. Das Paper schlägt vor, dass man, wenn man es einschaltet und es vor dem Penalty ausführt, ein stabiles, zuverlässiges Ergebnis erhält, das auf jedem Modell auf die gleiche Weise funktioniert.

Das Fazit

Der „multiplikative Repetitions-Penalty“, der derzeit in fast jeder KI-Engine ausgeliefert wird, ist grundlegend fehlerhaft, da er auf einer Zahlenlinie basiert, die sich verschieben kann. Er ist kein universeller Regler; er ist ein kaputter Drehknopf, der auf jeder Maschine andere Ergebnisse liefert.

Was er tut: Er verursacht massive, unvorhersehbare Änderungen in dem, was die KI schreibt (Änderung von 58–96 % der Entscheidungen) und zerstört strukturierte Formate wie JSON (Abfall der Gültigkeit von 97 % auf 23 %).
Was er nicht ist: Er ist kein Feature; er ist ein Bug, der seit Jahren in der gesamten Branche kopiert wird.
Die Lösung: Normalisieren Sie zuerst die Zahlen. Dies entfernt das Problem der verschiebbaren Landkarte und sorgt dafür, dass der Penalty konsistent funktioniert, egal welchen Roboter Sie verwenden.

Die Autoren haben dies über mehrere Modelle und Software-Stacks hinweg gemessen, und die Ergebnisse sind eindeutig: Der aktuelle Standard ist kaputt, und die Lösung ist bereit zum Einsatz.

Technische Zusammenfassung: Gauge-Abhängigkeit und Korruption strukturierter Ausgaben durch signalseitige Repetitionsstrafen

Problemstellung
Das Paper identiert einen grundlegenden Fehler in der multiplikativen Repetitionsstrafe (Repetition Penalty), die weit verbreitet in der LLM-Inferenz-Ökosystem (einschließlich Hugging Face, vLLM und llama.cpp) eingesetzt wird. Der Standardoperator, der vom CTRL-Modell geerbt wurde, wendet eine Strafe auf bereits gesehene Token an, indem er auf dem Vorzeichen der rohen Logits verzweigt: Er teilt positive Logits durch einen Faktor $\theta$ und multipliziert negative Logits mit $\theta$ .

Das Kernproblem besteht darin, dass der Lagepunkt des Logit-Nullpunkts arbiträr ist. Die Softmax-Funktion ist verschiebungsinvariant ( $\text{softmax}(z+c) = \text{softmax}(z)$ ), was bedeutet, dass das Trainingsziel eines Modells die Wahrscheinlichkeitsverteilung einschränkt, aber die absoluten Werte der Logits (die „Gauge“ bzw. den Maßstab) unbeschränkt lässt. Folglich operiert der Zweig des Vorzeichens der Strafe auf einer Koordinate, die der Trainingsprozess nicht fixiert. Dies führt zu zwei messbaren negativen Konsequenzen:

Undefiniertes Verhalten: Eine feste Einstellung der Repetitionsstrafe (z. B. $\theta=1,3$ ) führt eine unterschiedliche mathematische Operation auf verschiedenen Modellen aus (oder sogar auf demselben Modell mit einem verschobenen Bias), da der Anteil der Token, die auf den „Dividieren“- vs. den „Multiplizieren“-Zweig fallen, je nach Logit-Nullpunkt des Modells stark variiert.
Korruption strukturierter Ausgaben: Die Strafe unterdrückt wahllos Token, die durch Grammatik erforderlich sind (z. B. schließende geschweifte Klammern in JSON, Einrückungen in Code), einfach weil diese bereits zuvor aufgetreten sind. Dies verursacht einen katastrophalen Abfall der Validität strukturierter Ausgaben.

Methodik
Die Autoren führen eine Reihe kontrollierter Experimente über fünf Modelle (von gpt2 bis Qwen2.5-7B, einschließlich Base- und RLHF-Varianten) und zwei Inferenz-Stacks (vLLM und llama.cpp) durch, um die Effekte des Signal-Zweigs zu isolieren.

Gauge-Flip-Experiment (Konsequenz 1): Die Autoren dekodieren dasselbe Modell zweimal mit identischen Zufalls-Seeds und Inputs, addieren jedoch eine Konstante $c$ zu allen Logits (um eine Verschiebung im Bias des Modells zu simulieren). Für eine wohldefinierte Intervention sollte die Greedy-Token-Selektion identisch bleiben. Sie messen die „Flip-Rate“ (Anteil der Positionen, an denen sich das Token unterscheidet) bei $\theta=1,3$ im Vergleich zu Kontrollgruppen (subtraktive Strafen und normalisierte Strafen).
Evaluierung strukturierter Ausgaben (Konsequenz 2): Die Autoren evaluieren die Auswirkungen der Strafe auf zwei Aufgaben:
- HumanEval: Generierung von Code, bei dem spezifische Delimiter erforderlich sind.
- JSONSchemaBench: Generierung von JSON-Objekten gegen 200 reale Schemata.
  Sie messen die Rate valider, schema-konformer Ausgaben sowie die Häufigkeit von „Delimiter-Flips“ (wo ein strukturell erforderliches Token fälschlicherweise unterdrückt wird).
Cross-Stack-Verifizierung: Die Experimente werden in vLLM und llama.cpp unter Verwendung ihrer nativen Sampler repliziert, um zu bestätigen, dass das Problem inhärent in der Implementierung des Operators ist.
Vorgeschlagene Lösung: Die Autoren testen eine Variante, bei der die Strafe auf normalisierte Log-Wahrscheinlichkeiten ( $\log p_i$ ) angewendet wird, anstatt auf rohe Logits ( $z_i$ ), wodurch der Signal-Zweig effektiv entfernt wird, da alle Log-Wahrscheinlichkeiten nicht-positiv sind.

Wichtigste Ergebnisse

Gauge-Abhängigkeit: Die standardmäßige Signal-Zweig-Strafe ist hochsensibel gegenüber dem Logit-Nullpunkt.
- Über fünf reale Checkpoints hinweg reicht der Anteil der gesehenen Tokens mit positiven Logits (und damit dividierten Logits) von 0,17 (gpt2) bis 0,95 (Qwen2.5-Coder-7B).
- Im kontrollierten Flip-Experiment verursacht das Verschieben des Logit-Nullpunkts um eine Konstante von $\pm 5$ bei der Standardstrafe einen Flip von 58 % bis 96 % der Greedy-Tokens bei $\theta=1,3$ . Im Gegensatz dazu zeigen subtraktive Strafen und normalisierte Strafen eine Flip-Rate von 0 %.
- Die „Kosten“ der Intervention (gemessen in der Log-Likelihood) variieren um einen Faktor von 4,1 in Abhängigkeit von der Gauge, während die Kontrollgruppen konstant bleiben.
Versagen strukturierter Ausgaben: Die Strafe degradiert die strukturierte Generierung massiv.
- Auf JSONSchemaBench senkt die Anwendung von $\theta=1,3$ die Rate valider JSON-Ausgaben von 97 % auf 23 %.
- Auf HumanEval verursacht die Strafe Flips bei strukturellen Tokens mit einer balancierten Genauigkeit von 0,999 gegenüber einer theoretischen Vorhersage, was bestätigt, dass der Mechanismus durch die Unterdrückung notwendiger Delimiter getrieben wird.
Prävalenz im Ökosystem: Die Signal-Zweig-Implementierung wurde in Hugging Face, vLLM, llama.cpp und zwölf weiteren Engines (z. B. TGI, SGLang, Ollama) gefunden. Das Problem ist nicht auf eine einzelne Bibliothek isoliert, sondern ein systemisches Artefakt des Designs des Operators.
Effektivität der Normalisierung: Die Anwendung der Strafe auf normalisierte Log-Wahrscheinlichkeiten ( $\log \text{softmax}(z)$ $lo g softmax (z)$ ) eliminiert beide Effekte.
- Die Gauge-Flip-Rate sinkt auf 0,00.
- Die JSON-Validität bei $\theta=1,3$ stellt sich wieder auf 97 % her.
- Die Korruption von Delimitern verringert sich um etwa das 80-Fache.

Bedeutung und Behauptungen
Das Paper argumenttiert, dass die standardmäßige multiplikative Repetitionsstrafe keine „saubere skalare Stellschraube“ ist, sondern eine Inferenz-Zeit-Intervention, deren Verhalten teilweise durch ein unbeschränktes Trainings-Artefakt (den Logit-Nullpunkt) bestimmt wird.

Mangelnde Portabilität: Ein fester $\theta$ -Wert repräsentiert nicht dieselbe Operation über verschiedene Modelle hinweg, was ein Tuning pro Modell und Aufgabe notwendig macht, selbst für einen „Standard“-Parameter.
Unbeabsichtigte Folgen: Die Strafe korrumpiert die strukturierte Generierung, indem sie grammatikalische Notwendigkeiten (die sich wiederholen müssen) als unerwünschte Wiederholungen behandelt – ein Fehlermodus, der besonders akut bei der Generierung von Code und JSON ist.
Lösung: Die Autoren demonstrieren, dass die Normalisierung der Logits vor der Anwendung der Strafe (oder die Verwendung von subtraktiven Strafen) sowohl die Gauge-Abhängigkeit als auch die Korruption strukturierter Ausgaben beseitigt. Sie merken an, dass Hugging Face bereits einen LogitNormalization-Operator bereitstellt, dieser jedoch derzeit deaktiviert und nach der Strafe angewendet wird, was die Problemlösung verhindert.

Das Paper schließt mit dem Schluss, dass die aktuelle Standardimplementierung der Repetitionsstrafe zwar notwendige Workarounds für das Modellverhalten darstellt, aber „scharfe Kanten“ einführt, welche die Zuverlässigkeit beeinträchtigen. Die Autoren fordern die Wartung der Stacks auf, entweder die Familie der subtraktiven Strafen zu adoptieren oder die Reihenfolge der multiplikativen Strafe so zu ändern, dass sie auf normalisierten Log-Wahrscheinlichkeiten operiert.