同一个问题答案忽对忽错根子是相位敏感性普通用户怎么绕开这个坑
最近,知乎热榜上挂着一个让技术圈直呼内行的问题:如何评价字节Seed团队发现DeepSeek性能漂移。点进去是一篇让普通用户直呼内行的技术论文。很多人用DeepSeek都有这种体验,同一个问题,有时答得漂亮,有时答非所问。字节跳动Seed团队说,根子可能不在服务器,而在模型自己记东西的方式。这个问题不只困扰普通用户,也困扰拿它写代码、做助手的开发者,因为出错没有规律,最难防。
![]()
Seed团队在预印本平台arXiv提交了论文Periodic Weak Spots,讲一个叫相位敏感性的现象。他们做了个简单实验:让DeepSeek-V4补全一段FP8量化函数代码,正确答案应该是8。代码本身不动,只在前面加一段没用的等号装饰,答案就开始横跳。
填充长度模4余数为0或1时,模型倾向答错成32;余数为2或3时,又答回正确的8。整个过程以4个Token为周期反复。换句话说,模型记不记得住一件事,居然要看这件事在输入里站哪个位置。这在普通人眼里就是:我问题没变,你咋还抽风了。更麻烦的是,这种故障跟问题难度无关,再简单的任务也可能中招。
论文说,问题出在DeepSeek-V4用的分块KV缓存压缩。这项技术为了省内存,把连续Token窗口压成更少的缓存条目,代价是引入了一个新的位置坐标,叫Token的相位。模型对不同相位的信息检索能力有系统性差异,部分注意力头甚至专门盯着某些相位。说白了,压缩省了显存,却让记忆变成了带周期的筛子,某些位置的信息容易漏。
大规模大海捞针测试证实了普遍性。128K长上下文里,DeepSeek-V4-Flash-Base不同位置的检索准确率最大差40.2个百分点,V4-Pro-Base差34.8个。后训练的V4.1-Flash把差距收到6.1个,但周期性还在。一个漂亮的平均分,可能正好掩盖了它在某个位置系统性失灵。其他采用类似分块压缩的长上下文模型,也可能存在同类隐患,只是没被量化出来。
![]()
实用经验其实有了。不少用户发现,把提示里最关键的内容放在最前面,模型抓到的概率明显更高;凌晨时段比高峰顺畅,一部分也是相位碰巧落在好区间。字节的建议更硬核:评估这类模型不能只看平均分,得把同一条信息放到不同相位分别测。对做产品的团队,这意味着要在测试集里加位置扰动,否则上线后才爆雷。
对普通人来说,记住两件事就够了:重要信息往前放,一次答不好换个说法再问。你被DeepSeek或者别的模型抽风坑过吗?评论区说说你是怎么把它掰回来的。
【参考来源】
界面新闻《DeepSeek抽风原因找到了,字节Seed团队论文揭示相位敏感性》(2026-10-09);量子位《字节找到了DeepSeek时强时弱的原因》(2026-10-09);腾讯网相关报道(2026-10-10);arXiv论文 Periodic Weak Spots。
特别声明:以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布,本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.