聊聊 Deepseek V3.1 的极你太美
万万没想到的是，DeekseekV3.1 引起的最大热度竟然是 极你太美。有很多人反映在 DeepseekV3.1 上很容易莫名其妙的输出各种各样的 极，并且这个问题可能最早在 0324 上就有了，见这个 #849 issue。
我们在本地部署了一个 FP8 满血版的 DeepSeekV3.1，尝试通过一些实验，看看能否找出规律，并看看是否能通过一些手段来规避或缓解。
老样子结论放前面：
在数据构造的场景里，持续的规律性长文本输出确实会让 DS 懵逼，并开始输出 极。
出现 极 的情况和输出的长度相关，在比较低的输出长度下不会出现这个问题。所以在数据构造的场景里，分批来构造就可以规避掉 极。
调整 temperature, top_p 等参数恐怕作用不大。在 logprobs 里很多场景 极 直接出现在了第一位。降低 temperature 和 top_p 搞不好是反而出来的更多了。
通过提示词可以一定程度缓解，但无法完全避免。
写作，代码，提问等场景里，只要不涉及持续的规律性的文本构造，即便是超长文本输出也基本上不会出现这个问题。
实验
实验 1：长序列输出
一个相对容易的复现方式是让大模型输出长序列，那很容易想到的是输出长度是否影响出现 极 的概率。
以下是一个测试请求的例子, 其中 temperature=0.6, top_p=0.95 是 generation_config.json 中的推荐参数。
由于输出出现第一个 极 后，显然对后续再输出 极 是有影响的。因此我们不统计单次响应中出现的 极 个数，只看某次响应是否至少包含了一个 极，我们暂且把这个东西叫做 含极率。
调整 max_tokens 的参数，我们得到如下实验结果：
极词的示例：
不和谐的网址我屏蔽了，这个真的很难撑。
从测试来看，显然更长的输出序列会显著提高输出 极 的概率。同时在未输出 极 的例子里，我们观察到了很多类似这样的例子：
又比如
可以看到在短输出的例子里，他很自然的应用省略号来处理这个问题，用相邻 token 错位似乎很难解释这个问题。
实验 2：#849 Case 复现
#849这个 issue 反馈在 Deepseek-V3-0324 上就已经出现类似的问题了，并给出了一个可以复现的例子。（然然而我在 0324 上并不能复现这个 case。。。V3.1 确实是可以稳定复现）
他的 prompt 大约是这样子：
在 DeepseekV3.1 上，执行参数 temperature=0.6, top_p=0.95,max_tokens=8192
这个 case 跑下来的情况是 13/20 ，概率显然比前面长序列生成要高了。这当然是因为在这个 case 里模型总是会输出比较长的内容。以下是一小段示例：
这个 case 比较有意思的点在于，我们可以清楚的看到什么数据被错误的极了。以下是一部分例子
输出 极 的位置无一例外都处于比较靠后的 insert 语句中，这和之前 1-2000 整数的 case 类似，问题总是出现在更靠后的文本里。
如果我们调整这个 case 中的 max_tokens 参数，则会得到这个结果。在这个 case 里影响 极 出现的 最低 token 长度可能在 2000 左右，相比实验 1 要来的更小一些。
实验 3：和结构有关系吗
在前面的实验里，我们生成的都是有显著规律性的长文本，在日常工作场景里，构造批量数据的时候会比较符合这个特性。
如果生成的是没有规律性的长文本呢，比如我们用如下的提示词来生成一段很长的代码：
在 temperature=0.6, top_p=0.95, max_tokens=8192 参数下，输出长度大概有 5000 token 左右。
我们沿用前面的脚本来尝试，尽管这个提示词本身已经挺极了，但最终测试的含 极 率为 0/20，没啥影响。
也就是说在大部分业务场景里，极你太美 并不会太影响实际的工作。但是在大批量构造数据的场景里，确实会产生明显的干扰。
看看 logprobs
我们在实验 2 的基础上增加 logprobs=True,top_logprobs=5 的请求参数，去观察当出现 极 的时候，他的概率分布情况。下面我们来看一系列例子：
销售渠道型/销售支持型分公司为保留销售费用，极不结转：
原本期望名字的 不，落在第二概率上，且概率很低。
Top logprobs:
Token:
极, Logprob:-0.03505263105034828Token:
不, Logprob:-3.368384599685669Token:
極, Logprob:-15.660050392150879Token:
极端, Logprob:-16.910051345825195Token:
极其, Logprob:-18.576719284057617
南京 x 数字极速有限公司
期望的技术是第一顺位，但没有被选中。这也是正常的，因为 技术 的概率还没有达到 95%，因此按 top_p=0.95，排序第二的 极 确实是进入采样范围的。
Top logprobs:
Token:
技术, Logprob:-0.11735430359840393Token:
极, Logprob:-2.200686454772949Token:
极端, Logprob:-13.242354393005371Token:
<｜end▁of▁sentence｜>, Logprob:-14.59652042388916Token:
极其, Logprob:-15.32568645477295
销售极速服务
期望的 支持 排序第二，能进入采样，但显然这里没有被选到。
Top logprobs:
Token:
极, Logprob:-0.1173519566655159Token:
支持, Logprob:-2.200687885284424Token:
极端, Logprob:-14.07568359375Token:
极度, Logprob:-15.742351531982422Token:
支, Logprob:-19.909019470214844
销售渠道极/销售支持型分公司为保留销售费用，不结转
期望的 型 和 极 的概率一样高，一起进入采样，但没有被选到。
Top logprobs:
Token:
型, Logprob:-0.6931471824645996Token:
极, Logprob:-0.6931471824645996Token:
極, Logprob:-19.026479721069336Token:
性, Logprob:-21.943147659301758Token:
极端, Logprob:-22.151479721069336
销售渠道型/销售支持型分公司为保留销售极速，不结转
期望的费用排序第二，能进入采样，但没有被选到。
Top logprobs:
Token:
极, Logprob:-0.506361722946167Token:
费用, Logprob:-0.9230258464813232Token:
费, Logprob:-14.25635814666748Token:
極, Logprob:-18.839693069458008Token:
用, Logprob:-19.048025131225586
‘202501’, ‘极 516’
期望的 202 和 极 的概率一样高，一起进入采样，但没有被选到。
Top logprobs:
Token:
极, Logprob:-0.6931473016738892Token:
202, Logprob:-0.6931473016738892Token:
極, Logprob:-16.943147659301758Token:
极端, Logprob:-16.943147659301758Token:
<｜end▁of▁sentence｜>, Logprob:-21.109813690185547
结论
原因猜测
结合我们上述的实验，我们大抵可以来做一些推测：
不太像是传言
token错位，在实验 1 输出整数的例子里，短上下文的情况里可以很准确的输出省略号。调整 temperature, top_p 等参数恐怕作用不大。在 logprobs 里很多场景极直接出现在了第一位。降低 temperature 和 top_p 搞不好是反而会加剧这个问题。
有一点儿像是和终止符/切换标记混淆了，很多时候
极确实在输出的结尾，以极长，极抱歉等情况终止了持续的输出。但是在在实验 2 输出 SQL 的例子里，也可以看到大量的技术,支持等词被误输出为极的情况，这些地方按理不太可能期望会输出终止符。在 logprobs 里我们也看到正牌的 EOS 出现了，但顺位不高。所以也不好说，更像是注意力涣散有点懵逼了。coding 场景里，有反馈用官方的 Anthropic API 跑 Claude Code，几千万 token 没有碰到过问题。也有反馈用第三方 API 高频的在 coding 里碰到 极。这很可能是第三方 API 给量化了，从而放大模型对 极 的敏感度。 对于官方 API，或者 FP8 满血部署的环境而言，
coding场景基本不受影响。
整体而言，最大的可能新还是有存在数据污染，特别是极速赛车的例子，这显然是爬网站的时候把网站里的暗链给一起爬下来了，然后在未严格清洗的情况下数据给喂进去了。
所以这可能导致模型训练的过程中，在很多本不该出现极的地方，实际数据存在很多极字，导致极在模型内的权重不太正常。在短文本输出的时候，模型的注意力还算集中，就不太容易出现这个问题。然而在输出长文本时，特别是规律性的长文本时（比如生成各种数据的时候），模型本来就容易注意力涣散，此时这个权重不正常的极就蹦出来了。。。。
分批处理
既然最容易出问题的场景是大批量的数据构造，那最有效的解决方案就是分批来构造数据。比如实验 2 的例子里，我们可以少量多次的输入要构造 SQL 的数据，只要把输出的长度控制的小一点，出现极的情况就会显著降低。比如我随便删少点，现在大概还有 17 条，在这个 prompt 下，含 极 率就能直接降低到 0。
提示词缓解
如果不调整提示词逻辑，可能有效的通用缓解方案是严格控制 极 字的使用，例如我们给这样一个 system prompt:
然后我们重新做实验 2 的测试，虽然不能完全消除 极 的情况，但含极率也确实明显下降了。
实验 2-含极率
从这个角度而言，极你太美 这个事情可能确实更多是数据导致的极字权重异常，从而在规律性的长文本输出场景下，模型注意力开始涣散以后的胡说八道行为。通过提示词能够一定程度上让模型注意力集中一点，或许有一些缓解作用。针对具体的场景再进一步的调教提示词，效果可能会更稳定一些。
以上
版权声明: 本文为 InfoQ 作者【冯骐】的原创文章。
原文链接:【http://xie.infoq.cn/article/db7fd3df6b952d743cc3bddd1】。
本文遵守【CC BY-SA】协议，转载请保留原文出处及本版权声明。
教育行业码农 2020-06-19 加入
一个教育行业的码农
评论