原贴链接

第0部分 - 我们为何需要重复惩罚机制？ 出于各种假设的原因，在多轮对话中大型语言模型（LLMs）有重复自身内容并陷入循环的倾向（对于单轮问答/补全来说，通常不需要重复惩罚）。因此，降低已有单词的概率将减少重复。

第1部分 - 频率/存在/重复惩罚 频率和存在惩罚是减法运算。频率惩罚根据已有单词实例降低单词权重，而存在惩罚基于布尔型的单词存在性进行削减。注意这些惩罚是应用于每个标记（token）的对数几率（logits，未归一化的权重预测值），而非最终概率。

最终对数几率[“单词”] -> 原始对数几率[“单词”] - (单词计数[“单词”] * 频率惩罚) - (最小值(单词计数[“单词”], 1) * 存在惩罚)

重复惩罚与存在惩罚相同，但为乘法运算。在尝试不同模型时这通常比较好，因为不同模型的原始对数几率量级不同。

最终对数几率[“单词”] -> 原始对数几率[“单词”] / 重复惩罚 ^ 最小值(单词计数[“单词”], 1)

如今人们普遍使用重复惩罚而非频率/存在惩罚。我认为对频率惩罚的反感是由于它在大多数应用中的实施效果很差。

第2部分 - 问题 重复惩罚有一个显著问题：它要么影响过大，要么影响不足。“如果单词存在于提示中就停止使用它”对于首先停止重复来说是非常生硬的指导。频率惩罚通过当一个单词多次出现时逐渐增加惩罚来解决这个问题。

然而，由于某种原因，几乎所有的实现都将频率惩罚应用于所有现有的标记。这包括特殊/停止标记（例如<|eot_id|>）、来自用户消息的标记以及来自系统消息的标记。当惩罚的目的是减少大型语言模型对其自身消息的重复时，基于其他消息进行惩罚是没有意义的。此外，惩罚像<|eot_id|>这样的停止标记必然会导致失败，因为模型在某个时刻将无法结束自己的输出并开始无休止地胡言乱语。

第3部分 - 临时解决方法 我们可以利用对数几率偏差参数来单独减少标记惩罚。下面是一个假设基于聊天补全API的频率惩罚实现：

需要一个“标记器（tokenizer）”和“消息历史（message_history）”

频率惩罚（FREQUENCY_PENALTY） = 0.1

def _get_logit_bias(self): 偏差（biases） = {} for msg in message_history: # msg: {“角色（role）”: 系统/用户/助手, “内容（content）”: 文本消息} if msg[“角色”] == “助手”: 标记（tokens） = 标记器.encode(msg[“内容”]) for 标记 in 标记: 偏差[标记] = 偏差.get(标记, 0) - 频率惩罚

    return 偏差

这个函数基于模型自身的消息（而非其他）返回一个用于频率惩罚的对数几率偏差字典。

总结：频率惩罚并不差，只是实施得不好。如果使用得当，它可能比重复惩罚好得多。

讨论总结

原帖围绕语言模型中的重复惩罚实施不佳展开，认为频率惩罚若使用得当会比重复惩罚好。评论者从多个方面进行了讨论，有人指出频率惩罚存在对基本语法词元惩罚的问题，也有人分享自己实践中的技术栈相关内容，还有人提及特定模型遇到的输出问题是否与重复惩罚相关，以及不同模型是否需要重复惩罚的情况，还有评论者推荐新的方法而反对旧的重复惩罚方法，也有人反馈频率惩罚测试结果不佳，同时还有人感谢原帖并寻求解决机器人重复问题的更多资源。

主要观点

  1. 👍 频率惩罚因会惩罚基本语法词元而无法起作用。
    • 支持理由：会对语言基本构建块进行惩罚，扭曲期望模型重现的语法。
    • 反对声音：无。
  2. 🔥 不同模型对重复惩罚的需求不同。
    • 正方观点：如Mistral Large 2 123B在特定上下文窗口下不需要重复惩罚，小模型更易出现重复问题。
    • 反方观点：无。
  3. 💡 直接惩罚序列重复可允许必要重复并阻止循环。
    • 解释：从解决模型重复问题的新角度出发，比基于词元惩罚更合理。
  4. 💡 不建议使用重复惩罚及相关旧方法。
    • 解释：推荐MinP和XTC或DRY等新方法。
  5. 💡 原帖将用户消息排除在惩罚范围外是合理的。
    • 解释：从模型自身重复的角度来看是合理的。

金句与有趣评论

  1. “😂 频率惩罚（Frequency penalties）无法发挥作用，因为它们总会对任何你正在使用的语言的构建块进行惩罚。”
    • 亮点：指出频率惩罚的一个关键弊端。
  2. “🤔 当人们谈论模型自我重复时，他们不是指特定的词元一次又一次地出现。他们指的是特定的序列的词元一次又一次地出现。”
    • 亮点：从新的角度定义模型重复问题。
  3. “👀 我已经这样做了一段时间了，并且可以证实这是朝着正确方向迈出的一步。”
    • 亮点：实践后的一种肯定。
  4. “😎 只要我将Mistral Large 2 123B的上下文窗口保持到40K（仅比其有效上下文长度32K多一点），通常就不需要任何类型的重复惩罚。”
    • 亮点：给出特定模型不需要重复惩罚的具体情况。
  5. “🤓 DRY通过惩罚重复序列工作，而非token，这效果要好得多。它不会破坏EOT。”
    • 亮点：介绍新方法DRY的优势。

情感分析

总体情感倾向是较为理性客观的。主要分歧点在于频率惩罚是否有用，原因是不同评论者从不同的模型使用场景、测试结果等方面出发，导致对频率惩罚的效果有不同看法。

趋势与预测

  • 新兴话题：新的如DRY、XTC等解决模型重复问题的方法可能会引发后续讨论。
  • 潜在影响：如果这些新方法被证实有效，可能会改变语言模型处理重复问题的方式，提高模型输出的质量。

详细内容：

《关于重复惩罚机制的热议：实施问题与解决方案》

近日，Reddit 上一篇题为“Repetition penalties are terribly implemented - A short explanation and solution”的帖子引起了广泛关注，收获了众多点赞和大量评论。该帖子主要探讨了语言模型中重复惩罚机制的相关问题，并提出了一些解决方案。

讨论的焦点主要集中在重复惩罚机制的效果和实施方式上。有人认为频率惩罚无法奏效，因为它会惩罚语言构建的基本元素，比如“a”“the”“and”“or”等，从而扭曲语法。还有人指出，从采样角度攻击重复问题有两种方式：一是直接惩罚序列重复，二是偶尔去除高概率令牌。

由用户分享道：“我一般不使用任何重复惩罚机制。每次尝试，效果要么几乎察觉不到，要么模型开始产出垃圾和错别字。”也有人表示：“我使用 DRY 在某些必要的情况下，但几乎总是关闭它，因为即使微调设置，它也可能严重降低质量。”

对于如何解决重复问题，有人提出可以利用逻辑偏差参数来单独降低令牌惩罚，还有人认为避免在惩罚上下文中包含用户消息的想法很有意义。但也有人觉得不要使用重复惩罚或其他类似的旧方法，只需要 MinP 以及 XTC（用于创意）或 DRY（用于角色扮演）即可。

同时，有用户测试频率惩罚后发现效果不佳，比如增加惩罚后模型开始永远吐出随机单词，而不是重复相同的单词。

这场讨论的核心争议点在于如何找到一种既有效又不影响模型正常运作的重复惩罚机制。虽然大家提出了各种观点和方法，但目前仍未达成完全一致的共识。究竟哪种方法才是解决语言模型中重复问题的最佳途径，还需要进一步的探讨和实践。