陆续有开发者发现，在调用API进行代码开发时生成结果中频繁出现”极”字异常现象。
这一问题最初由火山引擎、chutes等平台开发者发现并引发关注后迅速扩散至腾讯CodeBuddy等更多平台甚至DeepSeek官方渠道。
在Reddit论坛上也能看到大量讨论聚焦于”extreme”、”极”及”極”字符异常出现的情况。
腾讯CodeBuddy平台甚至出现更极端案例——生成代码中夹杂带有”极”字的广告内容（图源：小红书用户@奈绪白 Nine-piece shell）。
若开发者未仔细核对直接使用这些代码，则会导致编译失败等问题，在对精度要求严苛的代码场景中形成致命缺陷。
目前各方已将问题根源指向DeepSeek V3.1模型本身及CodeBuddy接口设计缺陷。
腾讯方面表示已与DeepSeek团队取得联系并计划在后续版本中修复该问题。
在此期间已有网友提出临时解决方案：通过在API调用时添加特定提示词来规避问题：”禁止如下符号序列模式：[空格][几个token][占位符/省略符号]”——该方法主要适用于第三方平台调用场景，在官方环境则无需此操作。
关于故障成因分析方面，知乎用户阶跃星辰黄哲威给出了高赞解读：这种异常现象并非孤例，在小模型蒸馏训练及早期R1模型测试阶段就曾出现类似情况。
他指出这可能与大模型编程任务中的特殊终止模式有关——当模型陷入无限列举场景（如素数序列）时会出现异常终止行为：”素数表 2, 3, 5, 7 … 997, 极长”。
进一步观察显示该故障触发概率约千分之一，在思考过程末尾循环时突然插入”极”字符并终止输出流——疑似某种特殊终止标记机制失效所致。
黄哲威通过大量实验数据推测问题根源在于训练数据清洗不彻底：在监督微调(SFT)及预训练阶段未能清除包含”极长数组描述”类脏数据；
而强化学习(RL+)阶段又错误将该字符习得为终止符或语言切换标记。
其研究还发现伴随该故障存在超长响应、空白字符泛滥、英文思考标记破碎化等连锁异常现象，并认为若迭代过程中未彻底清理训练数据污染源，则蒸馏过程可能将此类缺陷传播至正常输出路径——这为理解当前DeepSeek V3.1异常提供了重要线索。
这一被戏称为”极你太美””极速版”的问题最终仍需等待DeepSeek官方版本更新解决。（参考链接见原文末尾）
评论列表 (0条)：
加载更多评论 Loading...