128K上下文，100K文档还是答错：大模型的长

一个号称能处理 128K 上下文的模型，你丢给它一份 100K 的长文档，结果它连开头写明的内容都能答错。

这几年上下文长度涨得跟坐火箭似的，从早先的 4K 一路飙到 1M token。长文档问答、代码仓库分析这些应用也都被带起来了。可气的是，那些顽固的错误并没有因为窗口变大就消失。

问题不在窗口本身。窗口只是输入长度的硬性上限，超出的部分直接截断或丢弃。真正决定模型能不能用上这些信息的，其实是另一个概念——注意力跨度。说白了，就是模型在实际可见范围内能维持多远、多久的语义关联。打个比方：窗口是舞台大小，跨度是演员的专注范围。窗口决定能看到多少，跨度决定能用好多少——可产品页上最显眼的，大概率还是那个窗口数字。

这里头还卡着数学边界。标准 Transformer 的自注意力复杂度是 O(n²)，拿 128K tokens 算，注意力矩阵得占几百 GB 显存，单卡根本别想。更麻烦的是，序列一长，注意力权重会自发往局部聚拢，对远处 token 的关注掉得飞快。窗口再大，模型也容易把中间信息当空气，或者被一堆无关内容带跑偏。

LooGLE 基准测试的数字更扎心：商业模型在长依赖任务上的平均准确率只有四成左右，开源模型更是只有一成。所以别迷信大窗口——窗口越大≠越可靠。可厂商宣传页上还是写着大大的 128K，这账怎么算？

判断长文本能力，与其盯着宣传页上的数字，不如直接看第三方基准里长依赖任务的实测分数。