AI 的「长文本」能力：多长才算够用

把一份两百页的合同丢给 AI，问「违约金上限写在第几条」，它答得又快又像。翻回原文一核，条号错了，数字也错了。这类落差很常见：标称支持上百万字，和真正能在里面找到一句话，是两件不同的事。前者是容量，后者是检索质量，产品页只写前者。

窗口是容量，注意力是检索

上下文窗口决定一次能塞进多少 token，它是个硬上限，超了就截断或者报错。注意力决定这些 token 里有多少真正参与计算，它是个软约束，取决于内容怎么排、问题怎么问。容量可以标在参数表上，检索质量只能测。

两个指标分开之后，很多现象就好解释了。同样一份材料，问开头的内容答得准，问中段的内容开始含糊，这不是窗口不够，是注意力分配不均。窗口再扩一倍，中段照样容易被跳过，因为决定权重的是相关性计算，不是容器大小。

四个位置，四种失效

四行的共同点是：错误都以「通顺」的形式出现。它不会报错，不会说「这段我没读到」，而是给一段语法正确、逻辑连贯、事实错位的话。所以长文本场景里，核对成本不会因为窗口变大而下降。

中段为什么最先丢

注意力的权重是算出来的，算的依据是当前 token 与上下文各部分的关联强度。开头承担了「这是什么任务」的定位，结尾紧邻生成位置，两者天然获得更高权重；中段既不是任务定义，也不在生成位置附近，只能靠内容本身的相关性去争。

这个机制在短文本里几乎无害，因为总共就那么多内容，权重再分散也覆盖得到。长度一上去，稀释就明显了。经验上，关键信息落在材料前 10% 或后 10% 时被用到的概率明显更高，落在正中间最容易被略过。注意力机制那篇有更细的权重解释。

拆开读和整篇读，代价不同

整篇读的好处是能看见跨章节的关系，坏处是细节容易丢，且一次调用的 token 成本高。拆开读的好处是每一段都被认真对待，坏处是要自己把结论拼回去，容易漏掉章节之间的冲突。两种方式没有绝对优劣，取决于你要的是「整体判断」还是「某一条具体规定」。

做尽调、审合同、读论文这类任务，通常要跑两遍：先整篇读一遍拿结构和主线，再按章节拆开逐段核细节。第一遍的回答只用来定位，第二遍的回答才拿来引用。跳过第一遍，容易在细节里迷路；跳过第二遍，容易把概括当原文。

用三个问题实测容量

挑一份你自己很熟的材料，长度和你实际要处理的差不多。设计三个问题，答案必须读过才知道，而且分别落在开头、中段、结尾。三个都答对，这个长度对你就够用；中段那个答错，说明有效容量比你手里的材料短。

再补一个反向测试：问一个材料里根本没有的细节，看它会不会编。会编的，说明它在用先验补全，那么前面答对的部分也要打折扣，这和AI 幻觉里说的机制是一回事。这套测法比看参数表可靠，也比看别人的评测可靠，因为你的材料结构、你的问法才是变量。

标称字数之外的三笔成本

第一笔是钱。按 token 计费的接口，长上下文的单价随长度上升，一次塞十万字和分十次塞一万字，账单可能差出几倍，具体取决于缓存和批处理策略。第二笔是时间，输入越长，首字返回越慢，交互式场景里这个延迟很影响体验。第三笔是稳定性，越长的输入，同一问题两次回答的差异越大。

三笔成本叠起来，结论往往反直觉：把整本书丢进去，不如先检索出相关章节再问。检索增强那条路把「装多少」换成了「找得准」，代价是要先建索引。Token 那篇讲清了字数和 token 的换算，估算成本时用得上。

装得下不等于读得懂

窗口长度是可以堆的工程指标，读得准是能力指标，两者之间没有等号。一个标称两百万 token 的模型，在需要精确引用条款的任务上，可能不如一个窗口小一半但检索更稳的模型。选型时把「能装」当筛选条件，把「能找到」当决策条件，顺序不能倒。

材料本身的质量决定上限，这点常被忽略。扫描件 OCR 错字、表格串行、页眉页脚混进正文，这些噪声会挤占注意力，也会误导引用。清理输入的那半小时，往往比换一个更长的窗口更值。

速查：判断长文本够不够用

• 别看标称字数，用自己熟悉的材料测三个位置的问题
• 关键约束在结尾再说一遍，比只在开头说有效
• 要精确引用就拆章节，要整体判断才整篇读
• 问一个材料里没有的细节，看它会不会编