上下文窗口不是越大越好：长上下文里的「中间遗忘」与应对

把资料全塞进超长上下文，常常不如少而准地检索。本文讲清「中间遗忘」现象、它在工程上的表现，以及定位信息、分块摘要、分段提问三类可落地做法。

一个常见误判

「窗口够大，就不用检索了」——这是很自然的想法，但实测常常相反：把 10 万字资料一次性塞进去，模型对**开头与结尾**的信息利用得最好，**中间段**的召回明显偏弱。这类现象通常被称为「中间遗忘」。

结果就是：资料明明在上下文里，回答却漏了它，甚至与它矛盾。

**注意力被稀释**：序列越长，单个位置能分到的注意力越少；

**位置编码的偏好**：不少模型在训练时更多见到「关键信息在首尾」的样本；

**无关内容干扰**：塞进去的 90% 是无关段落时，它们会成为噪声而非背景。

**一、给结构，而不是给流水账**

把资料按标题分层组织，并在每段前加一句「这段讲什么」。模型不需要读完全文才能定位；实测里这一步的收益往往大于换模型。

**二、先摘要再回答（分段摘要 + 汇总）**

长文先逐段摘要（每段 2~3 句），把摘要连同**原文位置**一起给模型；需要细节时再按位置取原文。这样上下文里放的是「索引 + 要点」，而非全文。

**三、把一个大问题拆成多轮小问题**

「读完这些资料，给我一份分析」这类任务，改成「先列出资料里与 X 相关的全部事实 → 再基于这些事实回答」。每轮上下文更短、目标更单一，漏读概率显著下降。

以下场景适合直接塞长文：

需要**通篇一致性**的任务（长文改写、风格统一、全文校对）；

资料本身就短（几千字以内），拆检索反而增加误差；

需要跨段落推理（前后呼应、矛盾检测）。

反过来，**事实型问答、按条款作答、单点查询**这类任务，用检索 + 短上下文通常更准也更省。

挑 20 条需要「从长资料里找具体事实」的问题，做一次对照：

1. 全文塞入；

2. 检索后只给相关片段。

比较**正确率**与**成本**。多数项目会看到「检索 + 短上下文」在事实型问题上更准；而在改写类任务上，长上下文更好。**按任务类型选，不要一刀切。**