什么是长上下文外推？模型怎么「看得更长」

大模型能一次读多长的文本，训练时就定下了。但你可能见过这样的产品：训练窗口只有几万字，宣称却能读几十万字，靠的就是长上下文外推——用位置编码的处理技巧，让模型处理超出训练长度的输入。这项技术实用，但有明确的代价。把原理和失效方式讲清，再看产品宣传就不会被数字带偏。

问题根源：位置编码没见过那么远

模型靠位置编码知道每个字排第几。训练时只见过 8K 个位置，突然让它处理第 50000 个位置，它对那个位置就没有概念——像一个只走过家门口那条路的人，突然被扔进陌生城市。所以窗口长度这个数字，本质是位置编码见过的最大距离，处理范围一旦超出，输出质量就没有保证了。这也是为什么有的产品会「偷偷」把超长输入截断——超出窗口的部分要么丢弃要么压缩，用户却以为模型全读了。

三种把窗口拉长的办法

插值：把超出的位置按比例压缩回训练见过的范围，相当于把新地图缩放到熟悉的比例尺上，实现成本低，远处精度会打折。改编码方式：换一种能自然延伸到更长距离的编码设计，效果可以更稳，但要动模型结构，兼容性要重新验证。继续训练：用长文本再训一段，让模型真正见过长距离，效果实在，数据和算力成本也实在。三条路之外还有工程侧的办法：把超长文档切成语义段分批处理，这不算外推，但不少实际产品在用。

这张表的重点在第三列：没有白白得到的长度，每一种办法都在别处付了成本。

中间遗忘：外推的典型代价

强行拉长之后，模型常常「记得开头、记得结尾，中间一段记不清」。这种体验有据可循，是长上下文模型的普遍现象：注意力在超长序列上分布不均，中间位置的权重会往下掉。应对办法直接：关键信息放在文档开头或结尾，比塞在中间可靠得多；重要长文档分段提问，让每段都落在模型真正记得住的区域。

一个自查技巧：拿到长文答案后，挑一个只在文档中间出现过的数字或条款名，直接问「这个数字在原文里的上下文是什么」。答得上来，说明中间区域它确实读到了；答不上来或者张冠李戴，就把相关段落单独贴出来再问一遍。两分钟就能测出一个产品在长文档中部的真实表现。

外推还有连带成本：窗口越长，单次请求的计算量和显存占用越大。塞满 128K 的请求和几百字的请求，等待时间完全不在一个量级，长上下文对速度的影响在生成速度与 token这篇里有展开。

宣传数字与实测效果的差距

「支持 100 万字」不等于「100 万字里每一处都答得准」。窗口数字只回答塞不塞得进去，答不答得准要看实测。看产品时做两件事：其一，自己准备一份长文档，问几个只有中间部分才有答案的问题，看它答不答得出；其二，认准官方入口，警惕把窗口数字当卖点夸大宣传的产品，套壳应用的识别见什么是套壳应用。不同档位在窗口和额度上的差异，免费版和付费版大模型差在哪里有对照。

普通人的使用策略

三条可直接执行。其一，贴文档之前先想清楚要问什么，把问题写在消息开头，文档跟在后面。其二，超过窗口一半的长文档主动切段，按章节或条款切，切口落在语义边界上。其三，拿到答案回原文核对关键数字，长上下文里的引用错位比短文本更容易发生。长上下文是实打实的进步，但「能塞进去」和「能记住」之间，永远隔着验证这一步。

长上下文外推速查

• 窗口数字只说明塞得进去，不说明记得住
• 关键信息放开头或结尾，别放中间
• 超长文档切段提问，切口落在语义边界
• 窗口越长越慢越贵，128K 和短文本不在一个量级
• 拉长办法三种：插值、换编码、继续训练