假设你刚收到一份200页的尽调报告，打算让AI一口气读完并找出所有风险点。模型宣传自己的上下文窗口是128K token，"相当于10万字"。于是你把PDF传上去，开始提问。第一个问题它答对了。第二个问题，它引用了一段不存在的条款。第三个问题，它干脆说& quot;报告中没有提到该事项"——而那段内容明明就在第118页。
这不是偶然。过去两年，多家机构做过系统性测试，结果都指向同一个让人不太舒服的结论：能装下10万字的模型，往往只擅长记住开头和结尾，中间部分会被系统性忽视。
上下文窗口是容量，不是理解力
很多人把上下文窗口跟& quot;记忆力& quot;划等号，觉得窗口越大，模型就能记住越多内容，回答就越聪明。这个直觉只对了一半。
上下文窗口本质上是模型在生成下一个token时，能同时& quot;看到& quot;的最大token数量。但它只是容量上限，不保证模型会平等地处理每个token。就像一个能装100本书的书架，不代表你找书时能立刻定位到想找的那一页——模型面对10万token时，它的注意力资源是有限的，它得决定把& quot;注意力& quot;花在哪些token上。
2023年，斯坦福等机构发表了一篇论文Lost in the Middle: How Language Models Use Long Contexts，直接戳破了这个泡沫。他们测试了GPT-3.5-turbo等多种模型，把需要回答的事实放在输入文档的不同位置，结果发现：
当相关信息位于输入序列的开头或结尾时，模型表现最好；当位于中间时，性能急剧下降。而且随着整个文档变长，这个恶化会更加明显。
论文链接在arXiv。我最早看到这个结论时，以为只是测试方法的问题——毕竟我自己用长文档时偶尔失败，但没系统统计过。后来我在一个真实的合同审查场景里，把一份30页合同丢给模型，问第15页上的违约条款。它 confidently 回答了一个完全不同的条款，还给了个看起来合理的理由。那一刻我才意识到，这不是& quot;偶尔出错& quot;，而是模型的注意力分布本身就有系统性的偏差。
注意力机制为什么会& quot;看漏& quot;中间内容？
要理解这个现象，得回到Transformer的注意力机制。你可以把注意力想象成：模型在读一句话时，每个词都要跟其他所有词& quot;打招呼& quot;，然后根据相关性强弱决定自己该多看谁。
问题是，当序列变长，这种& quot;打招呼& quot;会变得非常拥挤。假设序列有N个token，每个token要跟其他N-1个token计算关联度，总共N²次计算。但更关键的是，注意力权重用softmax归一化——相当于给所有token打分，然后让这些分数加起来等于1。当N很大时，即使某个token确实很关键，它分到的权重也会被无数个不重要的token摊薄。
打个比方：你在一个100人的会议室里喊& quot;小王，你妈妈让你回家吃饭& quot;，小王能听见。但如果把会议室换成10万人的体育场，你还能保证小王听清吗？模型也一样——它的注意力被大量无关信息稀释，真正重要的信息反而淹没在噪声里。尤其是在文档中间，前面有大量上下文& quot;压着& quot;，后面又有新内容不断涌入，模型很容易& quot;忘了& quot;它早先见过但没重点标记的内容。
位置编码：模型对距离的感知比你想的弱
还有一个隐藏问题：位置编码。
Transformer本身没有顺序感，它靠给每个token注入位置信息来理解词序。常见的旋转位置编码RoPE、ALiBi等，都是让模型感知& quot;距离& quot;。但这里有个两难：训练时见到的序列长度是有限的，比如模型在8K token上限下训练，那它对位置编码的& quot;外推& quot;能力就有限。你硬把128K的文本塞进去，相当于让一个只在小区里开过车的司机直接上高速——他可能会开，但完全不知道远距离的路况该怎么处理。
有的模型通过调整位置编码做长度外推，效果确实不错，但依然存在精度衰减。比如论文Position Interpolation里就提到，直接把位置编码线性扩展到更长距离，会严重损害已有的性能。所以很多长上下文模型用了特殊的位置编码策略，但代价往往是局部的注意力模式变得不再精确。
大海捞针测试为什么能骗过所有人？
你可能听说过& quot;大海捞针& quot;测试：在长文档里随机插入一句关键信息，然后让模型把它找出来。不少模型靠这个测试证明了自己的长上下文能力，分数高达99%。
但这个测试有致命缺陷：它只测& quot;提取& quot;，不测& quot;理解 & quot;。你能从一本书里找到某个句子，不代表你理解了整本书的论证逻辑。更严重的是，测试用的& quot;针& quot;往往是一句独立的话，跟上下文没有复杂关联。而真实任务里，关键信息是分布式的——比如一份合同的违约条款可能分布在三处，需要模型综合推理，而不是简单查一个词。
还有个更扎心的问题：有些模型可能在训练时见过类似的大海捞针任务，或者对插入位置有偏好。有研究发现，当& quot;针& quot;被放在文档的固定位置（比如每隔1000个token）时，模型寻找成功率会异常地高，但换个随机位置就明显下降。这说明模型学到的是& quot;大海捞针测试的模式& quot;，不是真正的长文本理解能力。
Anthropic在发布Claude 2.1时，专门在技术博客里强调过这点。他们提出了effective context window（有效上下文窗口）的概念，并设计了一系列包含多步推理、信息综合的评估任务，发现模型的事实回忆能力会随着上下文长度增长而下降，特别是在需要把信息跨段落关联时。这篇文章值得一读：Claude 2.1 Prompting。
长上下文 vs RAG：该用哪个？
既然长上下文模型并不完美，那实际项目中该怎么选？我经常跟人讨论这个问题。简单粗暴的做法是：
| 维度 | 长上下文 | RAG（检索增强生成） |
|---|---|---|
| 适用场景 | 单文档通读、整体风格理解、跨越大量内容的综合推理 | 知识库问答、多文档检索、需要精准引用事实 |
| 成本 | 随长度线性增加，且注意力计算近似平方增长（实际有优化） | 只需检索少量相关片段，成本相对固定 |
| 准确性 | 位置偏置明显，中间信息易丢失 | 依赖检索质量，但可定位到具体来源 |
| 信息更新 | 需重新输入全量内容，无法增量更新 | 可随时更新知识库 |
| 核心瓶颈 | 注意力稀释 + 位置外推 | 检索召回率、重排序质量 |
我个人的经验是：如果你的任务需要模型对长篇材料给出一个整体判断，比如 & quot;这份研究报告的结论是什么 & quot;，那长上下文是合适的；但如果你要精确回答 & quot;第X条规则说了什么 & quot;，RAG往往更可靠，因为它天生就是为了定位而设计的。
当然，两者也可以结合。很多系统先用RAG从百万级别文档里捞出几千个相关片段，再塞进长上下文模型做深度融合。这比单纯的堆窗口要实在得多。
我现在的判断：不要为& quot;大& quot;而买单
回到开头的问题——长上下文窗口真的越大越好吗？我的答案是：对于绝大多数实际任务，100K和1M的差别远小于你想象。因为瓶颈不在容量，而在模型的注意力质量和位置信息处理能力。
目前很多模型声称的上下文长度，更像是& quot;技术指标的极限 & quot;，而不是& quot;有效能力的边界& quot;。真正值得关注的是：模型在什么长度下还能保持稳定的准确率？评测任务是否贴近你的真实场景？
如果你正在选型，我建议你做两个实验：一是把关键信息放在文档中间，看它能不能找到；二是构造一个需要跨段落推理的问题，看它能不能把分散的信息串起来。这两个实验能很快暴露模型的真实水平。上下文窗口就像硬盘容量——大没什么不好，但你不能因为硬盘大就以为数据永远不会损坏。
未来的模型一定会逐步扩展有效上下文，因为这是各家竞争的焦点。但至少在现在，别把& quot;能装下& quot;当成& quot;能理解& quot;。装下只是第一步，怎么在装下的同时保持清醒，才是真本事。
原创文章，作者：guanweilu，如若转载，请注明出处：https://guanweilu.cn/article/342.html