来源 1-2：96%。来源 5-6：52%。来源 9-10：94%。U 形注意力曲线。

当多个来源被拼接到一个长输入中时，模型能可靠地处理开头和结尾，但会丢失中间的信息。这就是 lost-in-the-middle 效应——一条 U 形注意力曲线，中间位置的内容纳入率降到 52%，而开头和结尾保持在 94% 以上。

数据

200 次运行、每次 10 个来源的发现纳入率：

这个模式是一致的，不是随机的。同一条发现放在不同位置，纳入率不同。决定可靠性的是位置，不是内容质量。

为什么会这样

这是模型处理长序列时固有的注意力分布模式。模型对输入的开头（首因效应）和结尾（近因效应）给予更强的注意力。中间内容获得的注意力更弱。

这不是容量问题。更大的上下文窗口不会消除这个效应——它们仍然呈现 U 形曲线。这个模式关乎注意力分布，不是上下文大小。

缓解策略

三种技巧，效果可叠加：

1. 开头摘要。 在输入开头放一份所有来源关键发现的摘要。中间来源的关键信息出现在注意力最高的位置。模型先可靠地处理摘要，然后有了详细章节的上下文。

2. 章节标题。 明确的标记如”## 模块 4：认证结果”帮助模型在整个输入中维持结构化注意力。标题创建注意力锚点，部分抵消 U 形曲线。

3. 来源标签和交叉引用标记。 当不同来源的发现互相关联时，显式标记并在开头摘要中注明关系。摘要中的”工具 3 和工具 11 的发现有关联”确保即使详细章节在中间位置，关联关系也会被处理。

什么不管用

“平等处理所有章节”指令。 注意力分布无法被 prompt 指令覆盖。Lost-in-the-middle 效应是基本的处理模式，不是行为选择。

随机打乱。 每次运行打乱来源顺序只是在概率上分散风险，不能在任何单次运行中防止丢失。开头摘要提供的是确定性保护。

更大的上下文窗口。 U 形曲线不管窗口大小都存在。200K token 窗口的中间注意力仍然弱于 100K token 窗口的开头和结尾。

什么时候分开处理

对于 12 个以上来源且所有发现都必须捕获、不需要交叉引用的场景，在单独的 API 调用中处理每个来源能完全消除注意力效应。但这会成倍增加 API 成本并丢失跨来源上下文。

结构化缓解方案（摘要 + 标题 + 标签）对大多数场景更经济——不需要架构改造就能把中间纳入率从 51% 提到 91%。

当确实需要交叉引用时（工具 3 的发现与工具 11 相关），来源必须在同一个输入中。分开处理会阻止关联。用开头摘要显式突出交叉引用。

一句话总结： 在开头放关键发现摘要并在全文加章节标题——这把中间来源的纳入率从 51% 提到 91%，缓解 U 形注意力曲线而不需要拆分成独立 API 调用。