大模型圈最顺手的解释是：上下文越长，模型越笨，这看起来已经是常识。2025 年 Chroma 的技术报告在 18 个前沿模型上把这种退化命名为 "context rot"，而 Du 等人那篇《Context Length Alone Hurts LLM Performance Despite Perfect Retrieval》给出了更干净的证据：把无关 token 从注意力里屏蔽掉、只保留位置索引，模型在数学、问答、代码任务上照样掉 13.9% 到 85%。既然把干扰全藏起来还会掉，那长度本身就是元凶。
2026 年 11 月 3 日，UC San Diego 的 Yinuo Liu 在 arXiv 上放出正好冲着这个结论来的一篇论文（arXiv:2611.04169）。设计只有一条原则：所有对比都锁死长度和证据位置，只换证据周围填的东西。五个开源模型、0.5B 到 3B、四个模型家族，任务是键值检索——上下文里藏一句「The secret code of the river is 4821.」，结尾问河的密码是多少，算正确值在 teacher forcing 下的对数概率。四种条件：什么都不填、填中性内容（随机数字、随机词、一句重复话）、填同格式的竞争性陈述（键从 51 个普通名词里抽）、以及把填充物从注意力里屏蔽掉但保留位置。
长度几乎不要钱，竞争才要命
在 Qwen2.5-1.5B 上，把中性填充物留在上下文里，8K 到 32K 每个长度档的中位损失都压在 0.006 nats 以内，准确率 0.96 到 1.00；同样长度换成竞争性陈述，中位损失直接跳到 2.82、3.94、4.03、4.76 nats，准确率掉进 0.11 到 0.21。让检索崩掉的从来不是那几万 token 本身，而是里面有没有跟证据抢注意力的话。
更狠的对照是把冲突和格式拆开。论文把「共享查询键、但给出不同值」的陈述单独拎出来：五个模型上，不含任何同键冲突的上下文平均损失 0.02 到 0.34 nats，至少含一条的则是 1.38 到 3.24 nats；准确率一边 0.97 到 1.00，一边 0.25 到 0.52。在 2,048 token 固定长度上，同键冲突从 0 条加到 6 条以上，Qwen2.5-1.5B 的损失沿着 0.03、1.37、2.24、2.48、2.71、3.26、3.45 nats 一路爬。反过来，只共享格式、不共享键的干扰项，能解释的损失方差不超过 0.3%。
作者自己在仓库里交代了一个意外：生成竞争填充物时，键是从 51 个词里抽的，没排除被查询的那个键，于是大约每 51 句填充里就有一句会用另一个值重述被问的键——上下文自己跟自己打架。作者写得很直白，这是 accident。仓库里有修掉这问题的 measure_v4.py，加了受控的单冲突实验臂，但它没被跑过，仓库里也没有任何 v4 结果。
抢走多少注意力，决定了掉多少分
论文把「注意力还剩多少在证据上」这个量接进回归：在短上下文里挑出对证据注意力最大的八个层头对，读出最后一个 query token 打在证据上的注意力质量 a*。126,473 次试验跑下来，log(1/a*) 能解释损失方差的 35% 到 58%，而 log 长度最多解释 2% 到 8%。逐模型看，Qwen2.5-1.5B 是 0.58 对 0.05，OLMo-2-1B 是 0.35 对 0.02，Llama-3.2-3B 是 0.45 对 0.08。
还有两个细节值得记。证据上的注意力从短上下文的 0.51 到 0.77，掉到竞争填充下的 0.17 到 0.31；而且这条关系有拐点——在 Qwen2.5-1.5B 上，损失在 a* 掉到大约 0.35 之前几乎不涨，越过这个点之后陡然上去。模型能扛住丢掉一半注意力，但过了线就断崖式崩掉。
掩码不是长度的干净对照
这套设计最狠的一刀，是回头去审 Du 等人那条「屏蔽掉干扰也照样掉」的证据。论文把那个掩码协议原样复现到 MMLU：1,000 道题，插入 3,750 到 30,000 个被屏蔽的 token，Llama-3.2-3B 从 51.7% 掉到 40.5%，Qwen2.5-7B 从 65.8% 掉到 48.1%。复现成立，说明这不是某一个模型家族的事。
但同样的掩码丢进检索任务，结论就反了。32K token 处，被屏蔽的中性填充让准确率掉 46 分（0.98 掉到 0.52），而一模一样的填充物留在可见状态，一分不掉；三种中性填充平均下来，可见时 0.96 到 0.99，掩码后 0.48 到 0.54。论文的解释是，掩码留下的是训练里从不出现的长位置空洞，不是「无关 token」——它量出来的代价不是长度的代价。
MMLU 上也有反例：Qwen2.5-1.5B 在 4,096 token 处，不填 59.1%，填可见中性内容 57.5%，填被掩码的 53.9%；但填空格的话，直接掉到 36.0%。所以长度本身也不是完全无辜，只是它在推理任务上留下的伤，和它在检索任务上留下的伤，不是同一道。
所以呢
如果这份结论站得住，工程优先级就得反过来：上下文真正的预算不是 token 数，而是「有多少条在跟证据抢话」的陈述数。对检索增强、Agent 记忆、长文档流水线来说，入库前的去重和冲突消解，比把上下文截短更值得做。而且 a* 只需要一次前向传播就能算出来，可以当成上线前的体检指标——抢注意力抢过某个阈值，就该先去处理冲突，而不是扩容窗口。
边界论文自己也划清楚了：所有结论来自单一合成检索任务，模型最大只到 3B；a* 和损失是在同一次前向里量出来的，没有任何因果干预，所以它是预测关系而不是因果结论；冲突分析没有预注册；4,096 token 以上的上下文必然含至少一条冲突，所以 2K 以上的「纯格式竞争者」这条分支根本没被测到。上面那个每 51 句就撞一次键的意外，作者也承认是事故，真正的对照实验还躺在仓库里没跑。
所以更准确的说法不是「长度无害」，而是：在检索里，长度的账要重算，竞争才是那笔要付的钱。谁能把这笔账算清楚，谁就能解释为什么同样标称的上下文窗口，有的模型能用，有的模型一上手就废。