长上下文不是越长越好：中间段落的损耗

窗口大，不等于全程记得住

现象很稳定：把一份长文档整份贴进去，问开头的内容，答得准；问结尾的，也还行；问正中间那段，开始含糊。让它引用原文，你翻一下就会发现，引的全是头尾，中间几十页像没读过。

这不是某一家模型的毛病，是注意力分配的通病。上下文越长，中间段落在整个输入里占的权重越低，模型分过去的心思越少。窗口标称值越大，能被晾在中间的内容就越多。

所以别拿窗口大小当记忆力。窗口只保证装得下，不保证都记得。

最省事的改法：把你最在乎的约束写在提示词开头，比如“只依据材料第三节的价格表回答”；材料贴完，结尾再补一句“回答只参考第三节的价格表”。

两头都钉住，中间丢的就是那些本来就允许丢的内容。这一招成本为零，实测能解决大半问题。

还有个细节：开头别只写约束，把任务背景也放进去。模型对开头一段读得最充分，把“你是谁、材料是什么、要干什么”压进开头，比压在中间任何位置都划算。

一份两百页的手册，别整本塞。按章节切成几段，每段单独问，问完把各段结论拼起来。

分段有讲究：按小节切，不按字数切；每段开头带上章节标题，让模型知道自己在读哪一部分；上一段问出的结论如果跟下一段有关，用一句话带进去。

代价是多几次调用。但中间段落召回差造成的返工，比多花的这点调用费贵得多。要不要分段，用两个数判断：材料超过五万 token、要问的问题超过三个，占齐就分段。

总结最容易暴露中间遗忘：整本塞进去让它总结，出来的结论空洞，覆盖不到中段。

改成两步。第一步，每章单独总结，两三百字一段；第二步，把所有小结拼在一起，让它基于小结出总纲。每章的内容都经过了单独一轮处理，没有哪段被晾在中间。

这个办法同样适用于评审类任务：逐章挑问题，最后汇总成清单。比一次性“找出全文所有问题”可靠得多。

有个自查办法：要求它先引用原文再回答。答案里引到的段落，就是它真正读到的部分。引文翻来覆去只有头尾两处，中间内容八成丢了。

补救按成本从低到高：把中间那段单独复制出来重新问一遍；还不行，就把那段挪到材料末尾再问；两步都无效，说明这段内容的关联信息也丢了，回到分段方案重来。

提醒一句：引用也可能被编。它有时会给一个“看起来像原文”的句子。核对引用是不是真的存在，跟核对数字是同一件事。

补充一句窗口大小只是及格线。同样一份长材料，会安排信息位置的人，用小窗口模型也能赢过整本硬塞的人。

窗口越大是不是越保险？

不是。窗口大只保证装得下，不保证记得住。窗口越大，被晾在中间的内容反而越多，关键信息的位置还得自己安排。

关键信息放开头还是结尾？

两头都放。开头交代一次，结尾重复一次，中间留给允许丢失的内容。只放一头，另一头附近的细节容易被带偏。

分段问会不会丢上下文？

每段带上章节标题，上一段的结论用一句话带进下一段。丢上下文的不是分段，是切的时候把结构切没了。