基于论文：Lost in the Middle: How Language Models Use Long Contexts (Liu et al., TACL 2023)
语言模型在长上下文中表现呈 U 形曲线：相关信息在开头或结尾时性能最高，在中间时显著下降——即使专门为长上下文设计的模型也一样。
2023 年，LLM 的上下文窗口迅速从 4K 扩展到 16K、32K 甚至 100K。直觉上，更长上下文 = 能处理更多文档 = 更好性能。但窗口大不等于用得好。
这篇论文问了一个简单但关键的问题：模型真的能用好长上下文吗？ 如果把答案信息放在输入的不同位置，性能会怎样？
核心思路：给模型一堆文档 + 一个问题，其中只有一份"金文档"含答案，其余是干扰文档。然后系统性地把金文档放到不同位置（第 1、第 5、第 10、第 15、第 20……），观察准确率怎么变。
问题在文档前后各放一次（让模型更好地关注上下文），金文档的位置是唯一变量。
实验结果揭示了一个清晰的模式——性能随金文档位置呈 U 形变化：
绿色 = 高准确率，红色 = 低准确率。开头和结尾最好，中间最差——这就是"Lost in the Middle"。
基于 NaturalQuestions 数据集。给模型 K 篇文档（K = 10, 20, 30），其中 1 篇含正确答案，其余 K-1 篇是从 Wikipedia 检索的相关但不含答案的文档。模型需根据文档回答问题。
结果：U 形曲线在所有 K 值下都出现。文档越多，中间位置的下降越严重。
构造一个 JSON 格式的键值映射（如 {"key_1": "value_1", ..., key_K": "value_K"}），模型需要根据指定的 key 返回对应的 value。把目标 key-value 对放到不同位置。
这个任务比 QA 更"纯粹"——不需要推理，只测试模型能否在长上下文中定位并提取特定信息。
结果：同样出现 U 形曲线。即使对长上下文模型，中间位置的准确率也大幅下降。
论文测试了多种专为长上下文设计的模型——MPT-30B-8192、LongChat-32K、GPT-3.5-turbo（16K）、Claude（100K）——它们全部表现出 U 形曲线。扩展上下文窗口不等于改善信息利用率。
更大参数量的模型（如 MPT-30B vs MPT-7B）在开头/结尾的绝对性能更高，但 U 形的相对下降幅度并未明显改善。模型变强了，但"中间遗忘"这个结构性问题仍在。
在键值检索任务中，答案不需要任何推理——只需找到正确的 key 并复制对应的 value。即使在这种"纯粹检索"场景下，中间位置的性能仍然显著下降，说明这不是推理能力的问题，而是注意力分配的问题。
这篇论文对检索增强生成（RAG）有直接而重要的影响。如果你的 RAG 管线把检索到的文档直接拼成 prompt，那么文档的排列顺序会显著影响回答质量。
很多人以为"给模型更多文档，模型自己会找到正确的那个"。这篇论文用数据证明：模型的"查找"能力是有位置偏差的——它天然偏向开头和结尾的信息，中间的信息容易被"淹没"。
回忆比重读更能形成长期记忆。先盖住上面，凭脑子答完再看解析。
📖 主要来源：Lost in the Middle 原始论文 (arXiv:2307.03172)
💡 相关概念：
💬 有疑问？ 随时向我提问！可以询问任何 unclear 的概念，或要求我深入解释某个技术细节。