把一份 50 页的 PDF 丢给 AI，让它找出某个数字。它答得头头是道，但那个数字刚好在文档正中间，它就是没找着。
不是它没读到。整个文档都塞进上下文窗口了，一个字都没少。问题出在它「读」的方式上。这个现象有个名字，叫 Lost in the Middle，出自 2023 年斯坦福大学的一篇论文。
现象是怎么被发现的
2023 年 7 月，斯坦福（Nelson F. Liu 等）在论文《Lost in the Middle: How Language Models Use Long Contexts》里做了一组实验。方法不复杂：准备多份文档，其中只有一份含答案，让模型做多文档问答，然后改变这份「答案文档」在整个输入里的位置，看成绩怎么变。
按常理，位置不应该有影响。答案就在输入里，找到就行，放前面放后面应该一样。
实际结果是一条 U 形曲线：答案在开头，成绩高；挪到末尾，成绩也不差；放到中间，明显下滑。论文原话是，模型能 robustly（稳健地）利用长输入里信息这件事，并不成立。
实验里还有个任务叫 key-value retrieval（键值对检索）：给模型一串「键-值」对，问其中一个键对应的值。换成这种更机械的任务，U 形曲线还在。说明这不是问答任务的巧合，位置偏差跟着输入走，跟任务关系不大。
「支持 200K」和「用好 200K」是两回事
厂家宣传的上下文窗口，说的是「能塞进去多少」，不是「塞进去之后都能用好」。
2024 年 NVIDIA 的 RULER 基准测了 17 个长上下文模型、13 种任务。这些模型全都声称支持 32K 以上上下文，测试结论是只有约一半能在 32K 长度上保持合格表现。原始的大海捞针测试（在一堆无关文本里找一句特定的话）大家分数都接近满分，但换成多跳追踪、聚合统计这类更复杂的任务，长度一加，成绩大面积跳水。
2025 年的 NoLiMa 基准把这件事推得更狠。之前的大海捞针测试里，问题和大海捞到的「针」往往共享字面词，模型靠字面匹配也能碰对。NoLiMa 故意把问题和针的词汇重叠降到最低，逼模型靠语义关联去找。结果 13 个声称支持 128K 以上上下文的模型，在 32K 长度时有 11 个掉到短文本基线的一半以下。GPT-4o 从 99.3% 掉到 69.7%，是表现最好的那批，也掉了将近 30 个百分点。
看榜单的时候留意一件事：厂商报的上下文长度是「窗口上限」，实测有效长度可能短不少。2026 年了，头部模型的数学比较能力确实比 2023 年那批强了很多，但「塞得进」和「用得好」之间的落差，到今天也没有完全抹平。
为什么会这样
主流解释落在注意力机制上。我之前写过多头注意力：模型处理每个词的时候，都要决定「往回看哪些词、各看多少」。这个「往回看」的动作，天然偏向序列的开头和结尾。
一种直观理解是：开头的词最早进入网络，参与了很多后续计算；结尾的词离输出最近，注意力天然容易够得着。中间的词既没有开头「先入为主」的地位，也没有结尾「近水楼台」的位置，被瞥到的概率就低。
这解释不了全部，但方向是对的：位置偏差是架构带来的，不是某家模型没做好。换模型、换厂家，曲线形状大体还在，只是程度不同。
三个能直接用的对策
把关键内容放开头。 让 AI 读长文档时，别把材料一股脑贴上去就完事。如果已知要找什么，把最相关的段落放在输入的开头或者结尾，中间留给次要内容。这是成本最低的一招，写提示词的时候手动就能做。
用 RAG，别硬塞。 上下文窗口再大，也别把整本书塞进去。先用检索把最相关的几段挑出来，再交给模型。RAG、长上下文、微调怎么选我之前专门写过一篇：资料放不下的时候，检索比硬塞更可靠，还省钱。
控制上下文长度。 对话轮数一多，历史消息全都在占窗口。定期开新对话、把必要的背景总结成几句话重新贴进去，比拖着一个几千轮的会话强。上下文窗口和 token 的关系之前写过，窗口大小直接决定你要付多少钱，钱和效果在这件事上是同一个方向。
给 API 用户加一条：上下文缓存能省重复前缀的钱，但它只解决「贵不贵」，不解决「中间内容找不找得到」。省钱的归缓存，效果的归检索，两件事别混。
小结
「支持 128K 上下文」的真实含义是「能接受 128K token 的输入」，不承诺中间部分都能用好。实验证据从 2023 年到现在一直指向同一件事：模型对输入开头和结尾记得牢，中间容易被略过。
你自己就能验证。拿一份长文档，把同一个问题里的关键词分别埋进开头、中间、结尾，各问一遍，比较答案。跑一遍比看十篇科普都有用。