假设你负责一个企业知识库问答系统，用户会提出诸如“ACME 公司在 2023 年第二季度的营收增长率是多少？”这样的问题。系统从知识库中检索出相关文档片段，拼接成上下文后交给大模型生成答案。你可能会认为，只要模型上下文窗口足够大，把所有相关文档都塞进去，答案自然准确。但实际生产中，你很快会发现一个令人困惑的现象：答案明明就在上下文的中间位置，模型却视而不见，给出错误或无关的回答。
这不是偶然的失误，而是大模型对上下文不同位置信息利用率存在系统性差异的表现。2023 年发表在 TACL 上的论文《Lost in the Middle: How Language Models Use Long Contexts》通过多文档问答和键值检索任务发现，当相关信息位于输入上下文的中间位置时，模型性能显著下降，即使对于专门为长上下文设计的模型也是如此。这一现象被称为“Lost in the Middle”，它直接挑战了“上下文窗口越大，模型越能利用更多信息”的直觉。
本文将以企业知识库问答为贯穿场景，分析这一现象背后的机制，包括注意力分布、位置编码和训练数据截断的影响，并对比重排、检索增强和滑动窗口等缓解策略，最后讨论在 RAG 流水线中的工程取舍。
基线方案：把更多上下文塞给模型
在 RAG 流水线中，最常见的做法是：将知识库文档切分成小块（chunk），用嵌入模型将每个块向量化，存入向量数据库。用户查询时，通过语义相似度检索出 top-K 个块，拼接后作为上下文输入给大模型。
这个方案的直觉是：只要检索到的块足够相关，模型就能从中找到答案。但问题在于，检索到的块数量往往有限（通常 3～10 个），如果答案分布在多个块中，或者检索结果不够精准，模型就可能遗漏关键信息。
为了提升召回率，一些团队会加大 K 值，甚至把整个相关文档都塞进上下文。这看似合理，因为长上下文模型宣称能处理数十万甚至百万 token。然而，这种“上下文堆砌”策略在实际中往往适得其反。
核心现象：U 型性能曲线
《Lost in the Middle》论文的核心发现是：模型性能随相关信息在上下文中的位置呈现 U 型曲线。当相关信息位于上下文开头（首因效应）或末尾（近因效应）时，模型表现最好；当信息位于中间位置时，性能显著下降，下降幅度可达 20 个百分点以上。
这一现象在多文档问答和键值检索任务中均被观察到。例如，在键值检索任务中，模型需要从上下文中找到与给定键对应的值。当键值对位于上下文中间时，模型准确率明显低于位于开头或末尾的情况。
值得注意的是，这种 U 型曲线并非旧模型的专利。Databricks 对 Llama-3.1-405B 和 GPT-4-0125-preview 的基准测试显示，Llama 在 32K token 后性能就开始明显下降，远低于其宣传的最大上下文长度；GPT-4 在 64K token 左右也开始下降。这意味着，模型的实际有效上下文长度往往远小于宣传值。
成因一：注意力分布的不均匀
为什么模型会忽略中间位置的信息？最直接的解释是注意力机制的不均匀分布。Transformer 的自注意力机制允许每个 token 关注上下文中的所有其他 token，但模型在训练中可能学会了将更多注意力权重分配给开头和末尾的 token。
这种偏好的形成与训练数据的特性有关。在自然语言中，关键信息往往出现在段落的开头或结尾，例如新闻报道的导语、技术文档的摘要。模型在训练中观察到这种模式，于是倾向于在推理时也优先关注两端。
此外，位置编码的设计也会影响注意力分布。绝对位置编码（如正弦位置编码）在长序列中可能产生较大的数值，导致注意力权重在中间位置被稀释。相对位置编码虽然缓解了部分问题，但并未完全消除位置偏置。
成因二：训练数据截断与长度外推
另一个重要成因是训练数据截断。大多数大模型在预训练时，由于计算资源限制，实际训练序列长度远小于其宣称的最大上下文长度。例如，一个宣称支持 128K 上下文的模型，可能在预训练时只使用了 4K 或 8K 的序列。
当模型在推理时遇到远超训练长度的序列，它需要依赖长度外推能力。但长度外推并不总是可靠，尤其是当模型没有经过专门的长上下文微调时。这导致模型在长序列上对中间位置的信息利用能力下降。
训练数据截断还意味着模型在训练时很少看到“长上下文中间位置包含关键信息”的样本，因此它没有充分学习如何在这种情况下定位信息。
成因三：检索噪声与上下文堆砌
在 RAG 场景中，还有一个额外的因素：检索噪声。当检索结果不够精准时，上下文中会混入大量与问题无关的文本。这些无关文本会分散模型的注意力，尤其是当它们位于关键信息附近时。
上下文堆砌策略（将大量相关或不相关的文档都塞进上下文）会加剧这一问题。研究表明，在上下文中填充部分相关的内容不仅无益，反而有害。模型的注意力会被无关材料分散，并且对于任何最终处于大型填充上下文中间的内容，都会触发 Lost-in-the-Middle 效应。
缓解策略对比：重排、检索增强与滑动窗口
针对 Lost in the Middle 现象，业界提出了多种缓解策略。下表对比了三种主流方法的原理、优势和适用场景。
| 策略 | 核心原理 | 优势 | 劣势 | 适用场景 |
|---|---|---|---|---|
| 重排（Reranking） | 检索后使用更精细的模型对候选块重新排序，将最相关的块置于上下文开头 | 提升检索精度，减少噪声；计算开销相对可控 | 需要额外训练或调用重排模型；仍受限于检索阶段的召回 | 检索结果较多、噪声较大的场景 |
| 检索增强（如 Contextual Retrieval） | 在嵌入前为每个块补充上下文信息，增强块与查询的语义关联 | 显著减少检索失败；可结合 BM25 与语义检索 | 需要额外的 LLM 调用生成上下文；增加索引构建成本 | 块缺乏上下文、依赖指代消解的场景 |
| 滑动窗口（Sliding Window） | 将长文档切分为重叠窗口，每个窗口独立处理，再合并结果 | 避免长上下文中间位置被忽略；适合流式处理 | 可能丢失跨窗口的依赖关系；增加推理次数 | 文档长度超过模型有效上下文长度的场景 |
重排策略的核心是“把最重要的信息放在模型最关注的位置”。通过重排，将最相关的块放在上下文开头，可以显著提升模型对关键信息的利用率。但重排并不能解决检索阶段召回不足的问题——如果关键块根本没有被检索出来，重排也无济于事。
检索增强策略则从源头入手，通过为每个块补充上下文信息（如文档标题、章节、前后文摘要），使块在嵌入空间中更接近用户的查询。Anthropic 在 2024 年提出的 Contextual Retrieval 方法，通过为每个块生成一段解释性上下文，将检索失败率降低了 49%，结合重排后降低 67%。
滑动窗口策略则是一种“分而治之”的思路，将长文档切分为多个短窗口，每个窗口独立输入模型，最后合并答案。这种方法避免了长上下文中间位置被忽略的问题，但可能丢失跨窗口的依赖关系，且推理成本随窗口数量线性增长。
RAG 流水线中的工程取舍
在实际的 RAG 流水线中，选择哪种策略需要综合考虑质量、延迟、成本和实现复杂度。
质量优先的场景（如法律审查、医疗问答）应优先采用重排和检索增强。重排能提升最终答案的准确性，检索增强能减少因块缺乏上下文导致的检索失败。但这两者都会增加额外的计算开销：重排需要调用一个独立的模型，检索增强需要为每个块生成上下文信息（通常需要 LLM 调用）。
延迟敏感的场景（如在线客服）则不宜过度堆砌上下文。长上下文模型的推理延迟随 token 数非线性增长，一个 160K token 的请求可能需要 20 秒，而 RAG 流水线通常能在 1 秒内完成。因此，应控制检索块的数量，并优先使用重排而非增加 K 值。
成本敏感的场景需要精打细算。长上下文请求的输入成本远高于 RAG 查询。例如，GPT-4.1 的输入价格为每百万 token 2 美元，一个 100K token 的请求仅输入成本就达 0.2 美元，而 RAG 查询的成本约为每次 0.00008 美元。对于每天处理数万次查询的应用，成本差异可达 1250 倍。
贯穿场景：企业知识库问答的优化实践
让我们回到开头的企业知识库问答场景。假设知识库包含大量 SEC 文件，用户查询“ACME 公司在 2023 年第二季度的营收增长率是多少？”。
一个典型的 RAG 流水线会检索出包含“The company’s revenue grew by 3% over the previous quarter.”的块。但这个块本身没有指明公司名称和时间，导致检索阶段可能无法匹配到该块，或者即使检索到，模型也无法正确关联。
优化步骤：
-
上下文增强：在索引构建阶段，为每个块生成一段解释性上下文，例如：“This chunk is from an SEC filing on ACME corp’s performance in Q2 2023; the previous quarter’s revenue was $314 million.”。这样，块在嵌入空间中与查询的语义距离更近，检索命中率提升。
-
混合检索：同时使用 BM25 和嵌入检索，融合结果。BM25 能精确匹配“ACME”和“Q2 2023”等关键词，嵌入检索能捕捉语义相似性。
-
重排：对检索到的 top-K 块进行重排，将最相关的块置于上下文开头。
-
控制上下文长度：只保留 top-3 到 top-5 个块，避免上下文堆砌。
下图展示了优化后的 RAG 流水线流程：
flowchart TD
A[用户查询] --> B[查询编码]
B --> C[混合检索: BM25 + 向量检索]
C --> D[候选块集合]
D --> E[重排: 按相关性排序]
E --> F[选取 top-K 块]
F --> G[拼接上下文: 相关块置于开头]
G --> H[生成答案]
在这个流程中，关键转折点是重排步骤。重排不仅提升了相关性排序，还通过将最相关的块置于上下文开头，利用了模型的“首因效应”，提高了模型对关键信息的利用率。
何时这些策略会失效
尽管上述策略能显著改善 Lost in the Middle 问题，但在某些情况下它们仍然会失效。
检索阶段召回不足：如果关键信息所在的块没有被检索出来（例如，因为块切分不当导致信息被分割），后续的重排和上下文增强都无济于事。此时需要优化分块策略，例如使用“小到大检索”模式：先检索细粒度的小块，再扩展到包含该块的更大上下文窗口。
多跳推理需求：当答案需要连接同一文档不同部分的事实时，基于块的检索可能会将相关事实分离到不同的块中，导致模型无法同时看到它们。例如，问题“ACME 公司在 2023 年上半年的总营收是多少？”需要将 Q1 和 Q2 的数据相加，而这两个数据可能位于不同的块中。此时，长上下文模型或全局文档理解可能更合适。
分布偏移：如果知识库的领域与模型训练数据差异较大，检索到的块可能包含模型不熟悉的术语或表达，导致模型无法有效利用。此时，需要针对领域进行微调或使用领域适配的嵌入模型。
可观测性与验证方法
在生产环境中，需要监控以下指标来评估 Lost in the Middle 的影响：
- 检索召回率：检索到的块中是否包含答案所在块。可以使用人工标注的测试集进行评估。
- 答案准确率：最终生成的答案是否正确。需要结合人工评估或自动评估指标（如 RAGAS 的忠实度）。
- 位置分布分析：记录答案所在位置在上下文中的分布，观察是否出现 U 型曲线。如果中间位置答案的准确率明显低于两端，说明 Lost in the Middle 仍然存在。
验证方法包括：
- 基准测试：使用《Lost in the Middle》论文中的多文档问答和键值检索任务，评估模型在关键位置上的性能。
- A/B 测试：对比不同策略（如是否使用重排）在真实查询上的表现。
结论与未解决问题
Lost in the Middle 现象揭示了长上下文模型的一个根本局限：上下文窗口大并不等于利用率高。在 RAG 流水线中，通过重排、检索增强和滑动窗口等策略可以缓解这一问题，但每种策略都有其适用边界和成本。
尚未解决的问题包括：如何让模型在训练中更均匀地利用上下文各部分信息？位置编码和注意力机制能否从根本上消除位置偏置？这些问题可能需要新的模型架构或训练方法来解决。
对于工程实践者，建议从 RAG 开始，严格控制上下文长度，精选进入 Prompt 的内容，并针对实际查询分布进行评估，而不是盲目相信宣传的上下文窗口大小。