AI 一次读的资料越多越好吗?给一大摞,中间的它根本不看

标称 128K，有效利用率可能不到一半

过去三年，大模型厂商的发布会上有一个数字被反复刷：上下文窗口。8K、32K、128K、200K、1M——每次翻一倍，发布会PPT上就多一行加粗的数字，媒体就多一篇"长上下文时代来了"的稿子。企业采购方被这个数字牵着走，好像谁的窗口大，谁就更先进。

但很少有人问一个朴素的问题：这个标称的上下文窗口，模型到底能用满多少？

先把这条军备竞赛的时间线理一遍。2023年初，GPT-4刚发布，上下文窗口是8K——一次最多塞大概6000个英文单词进去，差不多是一篇中篇小说的长度。那时候企业用户的抱怨是"连一份合同都塞不下"。同年7月，OpenAI推出GPT-4的32K版本，把窗口翻了四倍，发布会的说法是"可以一次性处理更长的文档"。Anthropic那边动作更快，Claude 2直接跳到100K，号称能一口气读完一本《哈利·波特》——大概25万字，折合约30万token。那半年媒体的标题清一色是"大模型进入长文档时代"，RAG团队开始焦虑，觉得自己的工作要被长窗口取代了。

2024年是这条赛道彻底发疯的一年。5月，OpenAI发布GPT-4o，上下文窗口拉到128K，主打的卖点是"能同时看图片、听音频、读长文档"。Anthropic紧跟，Claude 3系列把窗口推到200K。最猛的是Google，Gemini 1.5 Pro直接喊出1M token——后来又在技术演示里展示了塞进2M token的能力，相当于一次读完整本《战争与和平》还有富余。每次发布，科技媒体的反应都差不多：开头惊叹"这怎么可能"，中段分析"对RAG行业意味着什么"，结尾乐观预测"不久的将来所有文档都能直接丢给模型"。

2025到2026年，窗口数字继续膨胀。Claude 3.5、Claude 4代系列、GPT-4o的后续版本、Gemini 2.0 Pro，标称窗口从200K往2M走。但这时候行业内部已经开始有人嘀咕了：窗口是大了，可真把一份500页的PDF塞进去，模型能答对多少需要翻到第300页才能找到答案的问题？

梳理这条时间线你会发现一个规律：每次窗口翻倍，发布会上的话术都高度一致——"现在你可以把整本书、整个代码库、整套财报都丢给我们了"。媒体的解读也高度一致——"RAG要过时了，长上下文直接干掉检索增强"。企业采购方听到这种话，第一反应是那我还搭什么RAG系统，直接买最大窗口的API不就行了？但几乎没有哪家厂商在发布会上同时说一句："当然，塞进去的中间那部分，我们模型其实不怎么看。"

这不是厂商故意隐瞒，而是这个问题在技术上太新、太反直觉。窗口大小是一个硬指标，能写在合同里；有效利用率是一个需要跑实验才能测出来的软指标，没法在PPT上用一行数字概括。两边的信息不对称，就这样持续了三年。

2026年 Duerinckx、Geshkovski 和 Rossi 发的那篇论文，从数学上回答了这个问题。他们用动理论严格推导出：大模型对上下文里不同位置的信息，关注度呈U形分布——开头最高，结尾次高，中间有一个全局最低值。这意味着，你花大价钱买进来的那几十万 token 的上下文，中间一大段模型根本就没在认真看。

厂商说"支持128K上下文"，意思是模型在技术上能接收128K个token的输入——它不会报错、不会截断、不会崩溃。但"能接收"和"能利用"之间，差着一个U形曲线。

论文证明的是：上下文最开头的token，注意力权重最高，而且这个首因效应在数学上是发散的——越靠近起点，模型越关注。最末尾的token，因为离当前生成位置最近，注意力也是正的。但在中间某个唯一的位置，注意力掉到全局最低。这个凹陷不是平滑的小波动，是一个结构性的盲区。

更关键的是，论文里有一个发现特别值得采购方注意：只算到平均场层，这个U形根本看不出来；必须算到二阶关联——也就是token之间两两配对的影响——中间那个凹陷才浮现。这说明什么？说明这个盲区不是模型"不小心忽略"了中间，而是注意力机制本身的数学结构决定的。它不是bug，是特性。你靠调prompt、调temperature、调system message，都绕不过去。

这个结论不是凭空来的。早在2023年，Liu等人就做了一系列实验，系统测试了大模型在不同上下文长度下的检索准确率。他们的做法很直接：在一份长文档里随机位置埋一个关键句，然后问模型这个关键句是什么，看它能不能找出来。这就是后来业内说的"大海捞针"测试（needle in a haystack）。

他们测出来的趋势性数据大致是这样（以下为多组实验汇总后的示意值，非单次精确测量）：上下文在4K长度时，不管把针藏在哪个位置，模型的准确率都在80%上下浮动，中间位置略低但不明显。到了16K，中间位置的准确率掉到70%左右，开头和结尾还能稳住80%。拉到32K，中间位置的准确率进一步掉到60%上下。等到128K，中间位置的准确率可能只有50%——说白了跟瞎猜差不太多。而开头和结尾的准确率，始终维持在80%以上。

这个下降不是线性的。从4K到16K，中间准确率掉了10个百分点；从16K到32K，又掉10个；但从32K到128K，中间掉了10个百分点的同时，两端反而还稳住了。也就是说，窗口越长，两端和中间的剪刀差越大。这就解释了为什么标称128K的模型，你拿它做中间位置的问答，体感上跟标称32K的模型没区别——因为真正在工作的还是首尾那两段，中间那段你塞了等于没塞。

这个数据说明的问题很直白：窗口越长，两端和中间的准确率差距越大。模型不是随着窗口变大而"整体变笨"，它是在两端保持了能力，在中间持续掉链子。你塞进去的文档越长，中间那段的占比越大，模型看不见的信息就越多。

▲ "大海捞针"测试：把一句话藏在长文档中间，看模型能不能把它找出来

后来各家厂商在发布自己的长上下文模型时，也都会跑一遍这个测试。Anthropic在Claude 2发布时放了一张图，横轴是文档位置，纵轴是检索准确率，画出来一条漂亮的U形——两端接近100%，中间也有80%多。Google在Gemini 1.5 Pro的演示里更夸张，号称1M窗口下全程准确率接近100%。但你仔细看那些测试的设置：它们通常用的是结构非常规整的文档，针是一句非常突兀的陈述句，和上下文形成强烈对比。换成你公司200页的合同，关键条款埋在密密麻麻的条款编号中间，模型的表现会比这个演示差一大截。

还有一个变量常被忽略：针和上下文的相似度。如果藏的那句话和周围段落用词差异很大——比如周围全是法律术语，藏的针是一句"公司应在30天内支付违约金"——模型容易找到。但如果藏的信息和上下文风格接近，比如在一堆财务数字里藏一个"第47条约定的违约金比例为万分之三"，中间位置的准确率会再掉一截。真实业务场景里，关键信息恰恰是和上下文风格接近的那种——它埋在一堆相似的条款中间，这才是最难捞的针。

所以看厂商的长文档基准分数，一定要问两个问题：针埋在什么位置？针和上下文的相似度有多高？如果测试把针放在开头或结尾，那这个分数没有任何参考价值。如果针是一句和上下文格格不入的话，那个分数也高估了真实场景的表现。

长上下文不是免费的。每多塞一个token进去，KV cache就要多存一份键值对，显存占用线性增长；prefill阶段要处理的token多了，首token延迟也跟着涨。你为128K窗口付的钱，包括了GPU显存、包括了推理延迟、包括了单位时间能处理的请求数下降。

但如果中间那60%的token模型根本不看，你等于花了128K的钱，只买到了首尾两段的有效信息处理能力。中间那几十万token的显存、算力、延迟成本，全打了水漂。

这跟买房子一个道理。标称面积128平，中间60平是承重墙和过道，你实际能用的只有50平。但物业费、取暖费、房产税，是按128平收的。

下面把API定价摊开算一笔细账。以下价格为2024年中的公开定价，后续可能有调整，以厂商官网为准。

注意Gemini的定价结构——它在50K以上档位直接翻倍。这不是随便定的价，是因为长窗口的KV cache显存成本和prefill计算成本确实随窗口涨。Google把这个成本显性地写进了价格分层，OpenAI和Anthropic没有明说，但长窗口请求在他们后端的算力开销也是一样的。

算一笔具体的账。一次请求，输入100K token，输出1K token，用GPT-4o。输入费用：100K × $2.50 / 1M = $0.25。输出费用：1K × $10 / 1M = $0.01。合计大约$0.26，折合人民币不到两块钱。看起来不贵。但如果中间60%的token——也就是60K——是模型注意力到不了的盲区，那这部分输入对应的费用是60K × $2.50 / 1M = $0.15。一次请求两毛六，有一毛五打了水漂。一天跑一万次这样的请求，就是$1500的浪费，一个月四万多美元。这个数字对中小公司可能不敏感，但对每天处理几十万次请求的平台级产品，一年就是几十万美元的纯浪费。

再算显存账。一个70B级别的模型，每个token的KV cache大约占0.1到0.2MB显存（用了GQA分组查询注意力的模型会小一些，后面会展开）。128K上下文，单请求的KV cache就是12MB到25GB。一张A100 80G的卡，模型权重本身占了十几到二十几GB，剩下的显存要分给KV cache和激活值。算下来，一张A100 80G同时只能服务三到四个128K的长上下文请求。

▲ 一张A100 80G，跑128K长上下文请求只能同时服务三四个

而同样的卡，如果跑8K短请求，KV cache每个请求只占不到1GB，一张卡能同时塞十几个甚至二十个。这意味着长窗口不仅单请求API贵，还把GPU的并发量压下来了——单位时间能产出的回答数跟着掉。你付的GPU租金（不管是自建还是按API折算），有相当一部分在为那些模型根本不看的中间段token买单。

prefill时间这笔账也要算进去。所谓prefill，就是模型在生成第一个回答字之前，把你输入的整个上下文从头到尾扫一遍的过程。这个阶段是计算密集型的——128K个token要全部过一遍注意力网络，时间和上下文长度近似线性。在典型的70B模型上，128K的prefill可能需要5到10秒，取决于GPU型号和量化精度。这5到10秒里，用户盯着屏幕等第一个字出来，体感是"这个模型好慢"。而如果你的输入只有5K，prefill不到1秒，用户觉得模型"反应真快"。同样是聪明的模型，只是因为你塞了更多它不看的中间段，体验就从"快"变成了"慢"。

把这三笔钱加在一起——API调用费、显存占用导致的并发下降、prefill延迟导致的用户体验损失——你会发现，为长窗口付的每一块钱里，真正转化为"有效阅读"的比例低得惊人。这个比例，就是下一篇要展开算的账。

知道了盲区的存在，下一个问题自然是：市面上这几个主流长上下文模型，谁在"中间看不见"这件事上表现得好一点？下面这张表把几个常见模型放在一起对比。数据来自公开的基准测试和各家官方披露，具体数字会随版本更新浮动，这里给的是2024到2025年间的典型值。

从这张表能看出几个规律。第一，Gemini 1.5 Pro在超长窗口下的中间检索准确率相对最好，这跟Google在位置编码和注意力滑动窗口上的工程投入有关——它用了一组不同大小的注意力窗口叠加，让中间段也能被局部关注到。第二，Claude 3.5 Sonnet居中，200K窗口下中间位置还有65%左右的准确率，比GPT-4o的128K略好。第三，开源模型像LongLLaMA这类，虽然标称窗口能拉到100K，但中间检索准确率明显差一截——它们大多是通过位置编码外推（position interpolation）把短窗口"拉长"的，中间段的注意力分布并不自然。

但有一点要强调：这些准确率数字都是在受控测试里跑出来的。你自己的业务文档结构、术语密度、关键信息的埋法，都会让实际准确率上下浮动。厂商给的数字只能当参考，真正靠谱的是拿你自己的文档测。

为什么Gemini在超长窗口下的中间表现相对好？这背后是具体的工程选择。Google在Gemini 1.5里用了一种叫"滑动窗口注意力"的混合机制——一部分注意力层看全量上下文，一部分注意力层只看局部窗口。这相当于给模型配了两双眼睛：一双负责看全局首尾，一双负责盯住中间的局部段落。这种设计让中间段的token不会被完全忽略，但代价是计算量更大、推理更贵。OpenAI和Anthropic走的是另一条路——靠训练时喂更多长文档数据、靠位置编码的改进来缓解中间衰减，但没有从注意力结构上做局部窗口。所以它们的中间段表现不如Gemini，但短窗口下的综合推理能力更强。

这就引出一个选型上的实用结论：如果你的场景真的需要在超长文档中间定位信息，Gemini系列在这个具体维度上是目前公开模型里最能打的；如果你的场景主要是短文档综合推理，中间段定位不是核心痛点，那GPT-4o或Claude 3.5 Sonnet的性价比更好——你不需要为一个你用不上的2M窗口付溢价。

▲ 不管界面怎么迭代，中间段注意力衰减这个问题，至今没有被从根上解决

因为数字好讲。"支持128K上下文"是一个销售能在PPT上写出来、客户能在采购清单上打勾的指标。但"中间段注意力衰减30%"不是一个能写进marketing deck的数字。

厂商的激励机制是拉大数据——窗口越大，能接的文档越多，demo越震撼，发布会越好看。至于这些文档中间那部分模型读没读进去，不在他们的KPI里。

这就导致一个行业错配：厂商在拼命延长那个"有效利用率不变、甚至下降"的中间段，而不是在优化首尾两段的注意力效率。赛道卷得热火朝天，但卷的方向可能从根上就偏了。

从商业角度看，厂商有充分的动机把窗口做大。第一，长窗口是一个差异化卖点——你有128K我有200K，数字上直接压你一头，销售在客户面前好说话。第二，长窗口是锁定客户的手段——客户为了用你的长窗口能力，会把文档、数据、工作流都迁到你的API上，迁移成本很高，客户就被绑住了。第三，长窗口是API溢价的理由——Gemini把50K以上的输入价格直接翻倍，这个溢价不需要解释成本，客户会觉得"长窗口本来就贵"。

这三条商业逻辑，没有一条和"模型能不能真正读好中间段"有关。厂商的KPI是窗口数字、是API调用量、是客户留存率，不是你的合同审查准确率。所以你不能指望厂商主动告诉你"中间段你别塞东西"——他们的商业模式决定了他们希望你塞得越多越好。

如果你是企业技术决策者，在选型大模型时，别只看厂商标了多少K的上下文窗口。下面给一套可落地的评估方法，分四步走。

第一步，用你自己的业务文档做"大海捞针"测试。从你真实的文档库里抽50份典型文档，把一条关键信息（一个条款编号、一个数字、一个人名）分别埋在文档长度的25%、50%、75%三个位置，每个位置各测50次，一共150次提问。记录模型答对的比例。不要用厂商给的测试集——他们的测试集是精心挑选过的，你自己的文档才是你要面对的真实情况。

第二步，算出你的"有效窗口"。把上面测试里准确率超过80%的最大上下文长度找出来，这就是这个模型在你的业务场景下的有效窗口。比如标称128K，但你的测试显示只有在40K以内的中间位置准确率才稳定在80%以上，那你的有效窗口就是40K，不是128K。后面所有成本测算都应该按40K来算，而不是按128K。

这一步很多团队会跳过，因为跑150次测试要花几天时间。但这笔投入绝对值。你花三天跑测试，换来的是未来一年在API费用上省下几万甚至几十万美元。更重要的是，你会知道这个模型在你的业务里到底能干什么、不能干什么——而不是被厂商的标称窗口牵着走。

第三步，算TCO（总拥有成本）。API费用只是其中一块。把延迟成本也算进去——长窗口请求的首token延迟可能从1秒涨到5秒，用户体验下降折算成流失成本。再把工程维护成本算进去——长上下文方案需要更长的系统prompt、更多的chunk处理逻辑、更复杂的错误重试。三块加起来才是真实TCO。

第四步，拿短窗口+RAG方案的TCO来对比。短窗口模型（32K以内）推理单价低一半到三分之二，延迟也短。加上embedding检索、rerank重排，把最相关的两三个chunk拼起来喂给模型，有效信息密度反而更高。把这个方案的TCO和上面的长窗口方案放一起比，哪个便宜用哪个。

这里给一个典型场景的案例（为匿名化做了合理改编，但数字量级是真实的）。一家做合同审查的公司，早期方案是直接把200页的合同PDF转成文本，整个塞进128K上下文让模型审。跑了三个月，发现一个问题：合同中间几十页里的违约条款，模型经常漏看，审查覆盖率上不去。后来他们换了方案：先用embedding把合同按章节切块，检索出和用户问题最相关的3到5个chunk（大约3K token），做重排后拼到32K窗口里，把关键条款放在首尾位置。换完之后，API成本降了60%——因为输入token从128K掉到了5K左右。更出乎意料的是，审查准确率反而升了15%——因为喂进去的每一段都是和问题强相关的，注意力资源集中在有效信息上，不再被中间几十页不相关的条款稀释。

这个案例的核心不是"RAG比长上下文好"，而是"有效信息密度决定了利用率"。你直接塞全文，信息密度被中间段稀释到几十分之一；你用RAG先筛一遍，信息密度提上来，模型首尾两段的注意力反而更管用。

▲ 合同审查场景里，关键条款埋在200页正中间，模型大概率漏看

再展开算一下这个案例的TCO对比。方案A（128K直接塞全文）：每次请求输入约120K token，输出约500 token，用GPT-4o，单次输入费$0.30，输出费$0.005，合计约$0.31。按每月10万次请求算，API费用约$31000。延迟方面，128K prefill大约5到8秒，用户要等6秒以上才看到第一个字，客服场景下这个延迟直接拉低满意度。方案B（32K+RAG）：embedding检索一次约$0.01，rerank一次约$0.02，模型输入约5K token，输出500 token，单次模型费约$0.013，加上检索成本约$0.043。每月10万次请求约$4300。API成本只有方案A的七分之一。延迟方面，5K prefill不到1秒，加上检索的200毫秒，用户体验流畅得多。唯一多出来的成本是工程上要维护一套RAG管线——embedding模型、向量数据库、rerank服务——但这套东西是一次性搭建、长期复用的，摊到每次请求里不到方案A省下费用的零头。

当然，不是所有场景都适合这么切。如果你的需求是"通读整本小说然后写一篇读后感"，或者"分析整个代码库的依赖关系找出架构问题"——这类任务需要模型在长距离上建立关联，不是检索几个chunk能解决的，那长窗口确实有不可替代的价值。但即便是这类场景，你也应该把真正需要跨距离关联的部分控制在有效窗口以内，而不是盲目塞2M进去。

判断你的场景属于哪一种，方法很简单：问自己一个问题——"如果我只把最相关的三页文档给模型，它能完成任务吗？"如果答案是能，那你不需要长窗口。如果答案是不能，必须同时看几十页才能建立关联，那你才真的需要长窗口。大多数团队在选型的时候跳过了这个问题，直接按最大窗口买。这就是为什么我们说，长上下文不是越长越好。

还有一个容易被忽略的成本：长窗口模型的推理价格通常更贵。厂商不会明说，但你去看API定价就会发现，上下文越长的档位，每百万token的单价越高。这中间的差价，一部分是真的算力成本，一部分是厂商为"长窗口能力"收的溢价。如果你的业务实际有效利用率只有两成，这个溢价就是在为一个你用不上的能力付钱。

更现实的做法是：先拿一个中等窗口（32K到64K）的模型，配合RAG和chunk重排，把关键信息放在首尾。大部分企业场景跑下来，效果不会比128K直接塞全文差，成本可能只有三分之一。

长上下文这个赛道，现在的竞争逻辑是：谁窗口大，谁赢。但这篇论文告诉我们，窗口大不等于用得好。模型对中间信息的忽略是结构性的——你把窗口从128K扩到1M，中间那段盲区也跟着扩大了8倍。首尾两段的有效注意力区间，占总窗口的比例反而更小了。

真正有价值的技术方向，不是把窗口再翻一倍，而是怎么让中间段的信息被看到——是改进位置编码、是设计更均匀的注意力机制、是在推理时做中间段的重聚焦。这些方向不如"1M context"好讲，但它们才是真正在解决问题。

对采购方来说，这意味着一件事：下次厂商销售跟你说"我们支持128K上下文"的时候，你可以多问一句——"那如果我把关键信息放在正中间，你们模型能答对吗？"这个问题，比任何benchmark分数都诚实。

还有一个趋势值得关注。2024年以后，开源社区在长上下文方向做了不少工作——LongLLaMA、Mistral的长窗口版本、Yi的34B 200K模型，都在试图把窗口做大。但它们几乎都走了同一条路：通过位置编码外推，把原本只能处理4K或8K的模型"拉长"到几十K甚至上百K。这条路的问题是，拉长之后中间段的注意力分布并不自然——你相当于把一张本来只画了4K内容的画布，强行拉伸到128K，中间的画面是模糊的。真正从架构上改进中间段注意力的工作，比如混合滑动窗口、注意力重聚焦，进展还很慢。

所以短期内——未来一两年——企业采购方面对的局面不会变：窗口数字会继续涨，但中间段的盲区不会自动消失。你能做的，不是等厂商把中间段修好，而是在自己的系统设计里绕开它：把关键信息放首尾、用RAG控制喂进去的chunk长度、用自己的文档做基准测试、按有效窗口而不是标称窗口算成本。这套做法不性感，但它是目前唯一靠谱的做法。

说到底，长上下文不是一个伪需求——整本书摘要、整篇代码库分析、跨文档交叉推理，这些场景确实需要长窗口。但它是一个被过度营销的需求。大多数企业每天处理的文档，真正需要模型"从头读到尾"的不到一成。剩下九成，短窗口加检索就够了。把这一成和九成分开，按有效窗口算账，你会发现大多数公司在长上下文上花的钱，至少有一半是可以省下来的。

—— 窗口长度是厂商的指标，有效利用率才是你真正要算清楚的成本 ——