字节找到了DeepSeek时强时弱的原因

DeepSeek的神鬼二象性被字节Seed团队逮到了。

同一道题，什么都没改，只在前面多塞几个无关紧要的字符，模型突然就不会了？？？

Seed研究人员发现，DeepSeek-V4的表现竟然会随着信息的输入位置， 每隔4个Token周期性变化 。

啥意思？模型记不记得住一件事，居然还要看这件事在输入里站哪儿？？

前面多两个Token，答案可能从错变对，再多两个，又给你改回去。

在128K长上下文检索测试中，研究人员发现，同一条信息只是换了个位置，DeepSeek-V4系列模型的检索准确率 最高就能拉开40.2个百分点 。

团队进一步发现，这个问题与DeepSeek-V4采用的一项长上下文优化技术有关——

这项技术本来是为了让模型处理长文本更省内存、更高效。

结果压缩之后，倒让模型时神时鬼了（doge）。

字节Seed研究人员最开始是拿DeepSeek自己的代码做了个实验。

测试对象是 DeepSeek-V4-Flash-Base 。

他们从DeepSeek-V4的官方推理代码中截取了一段FP8量化函数，让模型补全最后一个Token。

任务的正确答案应该是8，因为这段代码需要完成FP8相关的类型转换。

为了搞清到底咋回事，研究人员在代码前面加了一段纯装饰性的文档字符串，里面放着一些重复的等号。

代码本身没改、要补全的位置没改、正确答案当然也没改……唯一的变化，就是前面多了这几个没什么实际意义的Token。

结果，DeepSeek的答案开始反复横跳。

当填充长度落在某些位置时，模型更倾向于回答错误的32。

往前挪一两个Token，又开始倾向于正确的8。

更具体地说，在论文测试的16种填充长度中，当长度模4的余数为0或1时，模型倾向于错误答案32；余数为2或3时，则倾向于正确答案8。

研究人员还统计了模型给两个候选答案分配的概率。

在一组位置上，错误答案32的平均概率达到71.3%，正确答案8只有26.4%。

正确答案8的平均概率升到91.5%，错误答案32只剩7.2%。

也就是说，前面几个无关字符的长度变化，足以让模型对同一道题产生截然不同的判断。

程序员调试代码，通常先检查逻辑、变量和依赖。

现在看来，可能还得顺手检查一下，前面是不是多打了两个等号。

不过单个代码补全案例，还不足以说明问题有多普遍。

他们把目光转向大模型长上下文能力里很经典的一项任务， 大海捞针 。

研究人员构造了一段长达128K Token的上下文，里面包含约 1.6万个键值对 。

然后让模型从中找出指定Key对应的Value。

测试过程中，键值关系不变，问题不变，上下文总长度也保持一致。

研究人员重点调整 目标信息相对于压缩窗口边界的位置 。

结果发现，DeepSeek-V4系列的准确率曲线，竟然呈现出非常明显的周期性起伏。

其中DeepSeek-V4-Flash-Base在不同位置之间的最大准确率差距达到40.2个百分点

DeepSeek-V4-Pro-Base也达到34.8个百分点。

DeepSeek-V4-Flash-0731的差距缩小到19.1个百分点，DeepSeek-V4-Pro-0813缩小到14.8个百分点。

而更新的DeepSeek-V4.1-Flash-0910，差距进一步降至6.1个百分点。

再往细看，DeepSeek-V4的波动周期是4个Token，DeepSeek-V4.1则变成了2个Token。

研究人员发现，这 恰好对应两代模型各自采用的KV Cache压缩步长 。

好嘛，连答题表现的起伏周期，都和底层压缩配置对上了。

大模型处理长上下文时，需要保存大量历史Token对应的Key和Value信息，供后续注意力计算使用。