🤖 machine learning

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

本文表明，大语言模型推理引擎中广泛使用的符号分支重复惩罚（sign-branching repetition penalty）存在根本性缺陷，因为它依赖于任意的逻辑值（logit）零点，从而导致不同模型之间出现大规模的标记选择不稳定性以及结构化 JSON 输出的灾难性失败，而这一问题可以通过将惩罚应用于归一化后的对数概率而非原始逻辑值来解决。

原作者： Peter Hollows

发布于 2026-07-14

📖 1 分钟阅读☕ 轻松阅读

CC BY 4.0

原作者： Peter Hollows

原始论文采用 CC BY 4.0 许可（http://creativecommons.org/licenses/by/4.0/）。 ✨ 这是对下方论文的AI生成解释。它不是由作者撰写或认可的。如需技术准确性，请参阅原始论文。阅读完整免责声明

想象一下，你有一个超级聪明的机器人作家，它非常喜欢讲故事。有时，它会陷入循环，像坏掉的唱片一样重复同一个词。为了修复这个问题，工程师们给了这个机器人一个“重复惩罚”（repetition penalty）旋钮。这个想法很简单：如果机器人试图说出一个刚刚用过的词，就调高旋钮，让这个词出现的概率降低，从而迫使机器人继续往下说。

多年来，世界上几乎所有的机器人作家（从 Hugging Face 到 vLLM 再到 llama.cpp）都在使用完全相同类型的旋钮。但这篇文章揭示了一个令人震惊的秘密：这个特定的旋钮是坏掉的，因为它看错了数字。

失灵的指南针

要理解这个故障，请想象机器人的大脑是一个巨大的地图，地图上的每个可能的词都有一个分数。正分意味着“我真的很想说这个”，负分意味着“我真的不想说这个”。这张地图是灵活的；机器人可以左右移动整张地图（给每个分数加上一个常数），而不会改变它下一个会选择哪个词。这就像在地图上移动一整座城市；即使城市现在处于另一个国家，街道之间的相对顺序仍然保持不变。

这个坏掉的旋钮试图通过检查一个分数的正负号来决定对重复词进行多少惩罚。

如果分数是正数，它会将这个数字除以一个惩罚因子（使其变小）。
如果分数是负数，它会将这个数字乘以一个惩罚因子（使其变得更负）。

问题在于：“正”与“负”之间的界限是人为规定的。 因为机器人可以左右滑动整张地图而不改变其行为，所以一个在某个机器人身上是“正”的词，在另一个机器人身上可能是“负”的，甚至在同一个机器人身上，只要稍微移动一下地图，情况也会改变。

论文证明了这种“符号分支”（检查数字是正还是负）所观察的坐标，是机器人训练过程中从未真正固定的。这就像试图通过观察仪表盘目前是在“红色区”还是“蓝色区”来驾驶汽车，而整个仪表盘其实是可以自行前后滑动的。

“同样的旋钮，不同的结果”引发的混乱

由于这种可滑动的地图，同一个旋钮设置（例如 1.3）会对不同的机器人产生完全不同的影响。

在一个机器人（如 gpt2）上，1.3 的设置可能会惩罚 84% 的重复词。
在另一个机器人（如 Qwen2.5-Coder-7B）上，同样的 1.3 设置可能几乎不会惩罚任何重复词，或者以完全不同的方式进行惩罚。

作者通过移动单个机器人的地图来进行测试。他们发现，使用标准的 1.3 设置，仅仅因为地图发生了微小的滑动，机器人就会改变其 58% 到 96% 的选择！

如果你使用“减法式”惩罚（仅仅是减去一个数），机器人的行为保持不变。
如果你使用标准的“乘法式”符号分支，机器人就会变得疯狂，几乎在每一个词的选择上都会改变主意。

这意味着，如果你调整你的机器人以使其在 1.3 的设置下表现良好，你实际上是在针对该特定机器人的一个偶然的“零点”进行调优。如果你将这个机器人移动到不同的计算机或更新其软件，同样的设置可能会彻底破坏它的表现。

JSON 灾难

这个漏洞最危险的部分在于它破坏了“结构化输出”（structured output）。这是指当你要求机器人编写代码或 JSON（一种特定的数据格式）时，它必须遵循严格的规则，比如闭合每一个大括号 { 或添加逗号 ,。

这些规则要求机器人重复某些符号。但由于惩罚机制是基于原始数值的，它经常会将一个“必要的规则”误认为是“错误的重复”。

论文在 200 个真实的 JSON Schema 上测试了这一点。
使用标准的 1.3 设置，有效、可运行的 JSON 输出率从 97% 骤降至仅 23%。
机器人开始破坏语法，忘记闭合括号或遗漏逗号，因为惩罚机制对错误的数字过于激进。

这并非模拟实验的猜测；作者在包括代码专用模型在内的五种不同模型上直接测量了这一点，并看到在所有主流软件栈（Hugging Face、vLLM 和 llama.cpp）中都发生了同样的崩溃。

修复方案：先进行归一化

论文提供了一个简单且经过验证的修复方法。与其观察那些会滑动的原始数字，不如观察归一化概率（即一个词被选中的实际百分比机会）。

概率始终在 0 到 1 之间，因此它们不会发生滑动。
当作者将惩罚应用于这些归一化后的数字而非原始分数时，混乱消失了。
“翻转率”（即仅仅因为滑动就导致机器人改变主意的频率）降至 0.00。
在 1.3 设置下的 JSON 成功率回升到了 97%。

Hugging Face 已经有一个名为 LogitNormalization 的工具可以实现这一点，但它默认是关闭的，并且是在惩罚之后运行的。论文建议，如果你在惩罚之前开启并运行它，你就能得到一个稳定、可靠的结果，且在任何模型上表现一致。

核心结论

目前几乎所有 AI 引擎中内置的“乘法重复惩罚”存在根本性缺陷，因为它依赖于一条可以滑动的数轴。它不是一个通用的旋钮；它是一个坏掉的拨盘，会在不同的机器上给出不同的结果。

它做了什么： 它会导致 AI 编写的内容发生大规模、不可预测的变化（改变 58–96% 的选择），并破坏 JSON 等结构化格式（使有效性从 97% 降至 23%）。
它不是什么： 这不是一个功能；这是一个在行业内被复制了多年的 Bug。
解决方案： 先对数字进行归一化。这消除了滑动地图的问题，使惩罚无论在你使用哪种机器人时都能表现得一致。

作者在多个模型和软件栈中测量了这一点，结果非常明确：现行的标准是错误的，而修复方案已经就绪。

技术摘要：符号分支重复惩罚中的标度依赖与结构化输出损坏

问题陈述
本文指出，广泛应用于 LLM 推理生态系统（包括 Hugging Face、vLLM 和 llama.cpp）的多乘性重复惩罚（multiplicative repetition penalty）存在一个根本性缺陷。这种继承自 CTRL 模型的标准算子通过对先前出现的 token 的原始 logits 进行符号分支处理来施加惩罚：将正 logits 除以因子 $\theta$ ，并将负 logits 乘以 $\theta$ 。

核心问题在于 logit 零点的位置是任意的。Softmax 函数具有平移不变性（ $\text{softmax}(z+c) = \text{softmax}(z)$ ），这意味着模型的训练目标约束了概率分布，但并未约束绝对值（即“标度/gauge”）。因此，惩罚的符号分支操作作用于一个训练过程并未固定的坐标系上。这导致了两个可衡量的负面后果：

未定义行为： 一个固定的重复惩罚设置（例如 $\theta=1.3$ ）在不同模型上（甚至是在具有不同偏移量的同一模型上）执行的是不同的数学运算，因为落在“除法”分支与“乘法”分支上的 token 比例会随 logit 零点的变化而剧烈波动。
结构化输出损坏： 惩罚会无差别地抑制语法所要求的 token（例如 JSON 中的闭合括号、代码中的缩进），仅仅因为这些 token 之前出现过。这导致结构化输出的有效性出现灾难性下降。

方法论
作者通过在五个模型（范围从 gpt2 到 Qwen2.5-7B，包括基座模型和 RLHF 版本）和两个推理栈（vLLM 和 llama.cpp）上进行一系列受控实验，以隔离符号分支的影响。

标度翻转实验（后果 1）： 作者使用相同的随机种子和输入对同一个模型进行两次解码，但在所有 logits 上加上一个常数 $c$ （模拟模型偏置的偏移）。对于一个定义良好的干预，贪婪选择的 token 应当保持一致。他们测量了在 $\theta=1.3$ 时，相对于对照组（减法惩罚和归一化惩罚）的“翻转率”（即位置发生变化的 token 比例）。
结构化输出评估（后果 2）： 作者针对两个任务评估了惩罚的影响：
- HumanEval： 生成需要特定分隔符的代码。
- JSONSchemaBench： 针对 200 个真实世界模式（schema）生成 JSON 对象。
  他们测量了有效且符合 schema 的输出率，以及“分隔符翻转”（即必需的结构化 token 被错误抑制）的频率。
跨栈验证： 实验在 vLLM 和 llama.cpp 的原生采样器中进行了复制，以确认该问题是该算子实现本身固有的问题。
提议的修复方案： 作者测试了一种变体，即将惩罚应用于归一化后的对数概率（ $\log p_i$ ）而非原始 logits（ $z_i$ ），从而有效地消除了符号分支，因为所有对数概率均为非正值。

关键结果

标度依赖性： 标准的符号分支惩罚对 logit 零点高度敏感。
- 在五个真实检查点中，出现正 logits（从而被除以）的已见 token 比例从 0.17 (gpt2) 到 0.95 (Qwen2.5-Coder-7B) 不等。
- 在受控的翻转实验中，将 logit 零点移动 $\pm 5$ 会导致标准惩罚在 $\theta=1.3$ 时引起 58% 到 96% 的贪婪 token 翻转。相比之下，减法惩罚和归一化惩罚的翻转率为 0%。
- 该干预的“代价”（通过对数似然衡量）随标度的不同而产生高达 4.1 倍的差异，而对照组保持不变。
结构化输出失败： 惩罚严重降解了结构化生成。
- 在 JSONSchemaBench 上，应用 $\theta=1.3$ 会使有效 JSON 输出率从 97% 降至 23%。
- 在 HumanEval 上，惩罚导致结构化 token 发生翻转，其平衡准确率对理论预测为 0.999，证实了该机制是由惩罚抑制必要分隔符驱动的。
生态系统普遍性： 发现符号分支实现在 Hugging Face、vLLM、llama.cpp 以及其他十二个引擎（如 TGI、SGLang、Ollama）中。该问题并非孤立于某个库，而是该算子设计的系统性人工痕迹。
归一化的有效性： 将惩罚应用于归一化后的对数概率（ $\log \text{softmax}(z)$ $lo g softmax (z)$ ）消除了上述两种效应。
- 标度翻转率降至 0.00。
- $\theta=1.3$ 时的 JSON 有效性恢复至 97%。
- 分隔符损坏减少了约 80 倍。

意义与主张
论文认为，默认的多乘性重复惩罚并非一个“干净的标量旋钮”，而是一种其行为部分由未受约束的训练人工产物（即 logit 零点）决定的推理时干预手段。

缺乏可移植性： 一个固定的 $\theta$ 值并不代表在不同模型上执行相同的操作，这使得针对每个模型和每个任务进行调优变得必要，即使对于一个“标准”参数也是如此。
意外后果： 惩罚通过将语法必需品（必须重复的部分）视为不需要的重复，从而破坏了结构化输出，这种失效模式在代码和 JSON 生成中尤为严重。
解决方案： 作者证明，在应用惩罚前对 logits 进行归一化（或使用减法类惩罚）可以消除标度依赖性和结构化输出的损坏。他们注意到 Hugging Face 已经提供了一个 LogitNormalization 算子，但目前该算子是默认禁用的，且是在惩罚之后应用的，因此无法解决问题。

论文总结道，虽然重复惩罚是应对模型行为的必要手段，但当前的实现方式引入了“锐利边缘”，损害了可靠性。作者呼吁技术栈维护者要么采用减法类惩罚，要么重新排序多乘性惩罚，使其作用于归一化后的对数概率。