DeepSeek爆出“极你太美”bug 官方回应了

像这样：

这个问题最初是在火山引擎、chutes等平台上被发现，但随着事件的发酵，更多平台也被卷入了进来，包括腾讯的CodeBuddy，甚至是DeepSeek官方……

事件之火，在国外Reddit上也是讨论声一片，重灾区是“extreme”、“极” 和“極”：

“extreme”（id:15075）

“极”（id:2577，简体中文的extreme）

“極”（id:16411，繁体中文中的extreme）

腾讯CodeBuddy还出现了更加奇葩的情况，直接插了句带“极”字儿的广告……

△

图源：小红书用户@ 奈绪白 Nine-piece shell

若是开发者们没有细看，直接用了生成的代码，那定然是会导致编译不通过等情况，可以说是对需要高精度、结构化输出的场景是致命一击。

截至目前，大家已经统一将问题的矛头指向了DeepSeek V3.1模型本身，以及CodeBuddy帮忙问了：

已经和DeepSeek团队取得联系，将在最近的一个版本中进行修复。

△

图源：微信公众号“刘小排r”评论区

现在该如何防范“极”字bug？

就目前来看，虽然完全解决问题要等到DeepSeek官方下场，但已经有网友开始支招解决这个问题了。

例如小红书网友@大模型产品经理，便分享了一招——提示词缓解：

关键的一句提示词是这样的：

禁止如下符号序列模式：

[空格] [几个token] [占位符/省略符号]

并且这个方法主要是针对调用API的第三方平台，若是在DeepSeek V3.1官方，则不需要。

为什么会这样？

最后，至于为什么DeepSeek V3.1会出现这样的bug，知乎网友、阶跃星辰黄哲威给出了他的看法，并获得了高赞。

他首先指出，这种现象并非孤例。在他使用小模型和开源数据蒸馏，以及在测试早期的R1模型时，就曾遇到过类似的bug。

黄哲威认为，这与大模型编程编题时可能出现的一种“恶性模式”（malicious pattern）有关。他举例说，在枚举素数的任务中，一个正常的模型本应无限地列举下去，如“素数表 2， 3， 5， 7 …”。

然而，他观察到之前一个代号为 R1-0528 的模型会出现一种奇特行为：在列举一段后会自行停止，变成一个有限的列表，例如“素数表 2， 3， 5， 7 … 997， 极长”。

这个“极长”的用法，与现在讨论的“极”字问题非常相似，常常出现在大量恶性重复之后，作为正常推理过程的回正。有时，模型甚至会输出“90000000…0000极大的数字”这样的内容。

他进一步描述了这种bug的触发场景。当模型陷入“thinking”的末尾循环无法跳出时，有千分之一的概率会突然蹦出一个“极”字，然后终止思考（），这似乎是一种特殊的终止符或标记。

通过观察R1模型大量的输出，黄哲威发现了不少问题，包括超长响应（response）、大面积的空白字符、不断的短句重复等，甚至连thinking末尾的英文字符都变得破碎。

基于以上观察，他提出了一个核心推测：这个问题的根源可能在于数据清洗不彻底。他认为，在进行SFT（监督微调）数据合成，乃至构建预训练数据时，可能没有将一组名为“‘极长’的数组”的“脏数据”清洗干净。

他推断，R1模型在处理一些难题的解答时，似乎大量使用了RAG（检索增强生成）技术，而后续的RL+（强化学习）阶段，模型直接将这个“极”字当作了某种终止符或者语言切换标记来学习和使用了。

最后，黄哲威总结道，如果R1迭代时的数据没有清洗干净，模型自行蒸馏并“污染”到正常的输出过程中，是完全可能发生的。这为理解DeepSeek V3.1模型出现的“极”字问题提供了一个可能的解释路径。

至于这个被网友戏称为“极你太美”、“‘极’速版”的问题到底何时会彻底解决，就要等DeepSeek官方的新版本了。