这篇笔记精读 Lost in the Middle: How Language Models Use Long Contexts（Liu et al., 2023）。

它讨论的不是“上下文窗口有多大”，而是一个更工程、更阴险的问题：同样塞进上下文，模型会不会真的用到？

结论很明确：在长上下文里，LLM 对信息位置有系统性偏好——首尾强、中间弱，最容易“丢在中间”。

1. 论文要解决的问题：能放进去 ≠ 能用起来

很多 RAG / 多文档问答系统默认假设：

  • 我把候选证据按某种方式拼接进 prompt
  • 模型就会在里面“找”到正确片段并使用

但真实系统里你会发现：

  • 证据越多，干扰越多
  • 上下文越长，模型越容易忽略一些本该用到的信息

这篇论文把这个现象系统化，提出一个可检验的问题：

关键证据所在的位置改变时，模型性能如何变化？

2. 核心实验设计：只改“证据位置”，其余尽量不动

精读这篇论文，最应该盯住的方法点是它的变量控制：

  • 把同一条关键证据（回答问题所必须的信息）
  • 放到长上下文的不同位置（靠前 / 中间 / 靠后）
  • 其它内容保持尽量一致（干扰段落、总长度、问题不变）

这样测出来的差异，才能归因到“位置偏差”。

你可以把它理解成一个很工程的 A/B：

  • A：答案证据在开头
  • B：答案证据在中间
  • C：答案证据在结尾

然后比较最终正确率。

3. 核心结论：U 型位置效应（首尾强、中间弱）

论文最重要的观察是：性能随“关键信息所在位置”呈 U 型：

  • 开头最好（或接近最好）
  • 结尾也很强
  • 中间最差（lost in the middle）

这意味着：

  • 长上下文并不是一个“均匀可用的存储空间”
  • 模型并非在内部做了可靠的随机访问检索

对系统设计来说，最致命的一句翻译是：

你拼接的上下文顺序，本身就是一个强特征；放错位置，等于没给。

4. 为什么会“丢在中间”：工程化解释（比理论更有用）

论文讨论了可能机制。对工程落地来说，我建议用下面这个模型来理解：

  • LLM 的上下文更像“顺序通道”，而不是“可索引内存”
  • 注意力与训练分布带来的 首因/近因效应（primacy/recency）叠加
  • 在长序列+干扰多的条件下，中间片段更容易被稀释

你不需要完全确认哪一个理论机制为真，才能落地改系统。

因为无论原因是什么，现象足够稳定：中间风险高。

5. 工程落地：如何把论文结论变成系统策略

下面是这篇论文最值钱的部分：它直接告诉你“拼上下文”这件事该怎么工程化。

5.1 证据重排（Evidence reordering）：把最相关放到两端

最简单、通常也是性价比最高的改法：

  • 把 Top-1/Top-2 证据放在 开头
  • 再把同一证据（或其压缩版）放在 结尾 做锚点

这相当于在 prompt 上做“端点冗余”，对抗中间丢失。

工程要点：

  • 重排是 deterministic 的（便于回放与评测）
  • 端点冗余要受 token 预算约束（不然你只是把上下文变更长）

5.2 两段式（select-then-generate）：先挑证据，再回答

把长上下文当“数据库”通常会失败。

更稳的模式是两段式：

1) Evidence selection：用检索/重排序/模型打分，把证据收敛到 Top-K 2) Constrained generation：回答阶段只允许使用 Top-K（并要求引用）

这会把问题从“模型在长序列里找针”变成“模型在短证据里组合”。

工程要点：

  • K 的选择要与预算绑定（例如 K=4，每条证据最多 N tokens）
  • 证据要带 doc_id/paragraph_id，便于引用校验

5.3 分块审阅（chunk-by-chunk）：把长上下文变成多轮短上下文

如果你必须处理很长的材料（多文档、长报告），可以采用分块审阅：

  • 每次只喂一个 chunk，让模型提取“候选证据/关键句”
  • 最后把提取结果汇总，进入回答阶段

这其实是在系统层做“外部检索与压缩”，而不是把责任推给模型内部的注意力。

5.4 引用校验（citation check）：让“用到了”变成可验证

长上下文的问题之一是：你很难知道模型到底用没用到关键证据。

建议把“引用”做成协议：

  • 输出答案必须带引用：[doc_id:para_id]
  • 后处理校验引用是否存在于上下文/证据集中
  • 发现缺失则触发重试或降级（例如重新检索、降低 K、改写问题）

这会把“模型是否利用上下文”变成可观测指标。

5.5 位置敏感评测（position-aware eval）：把 U 型风险纳入回归

论文提醒你：只测“平均正确率”是不够的。

建议把“证据位置”作为评测维度做回归：

  • 固定一批 QA 样本
  • 把关键证据放到前/中/后
  • 对比系统策略（重排/两段式/分块）在不同位置的鲁棒性

如果你的系统在“中间位置”崩掉，那就不是偶然 bug，而是结构性风险。

6. 一份可以直接照着做的改造清单

把这篇论文压缩成一张 checklist：

1) 拼接策略：Top 证据放两端；中间放长尾候选。 2) 预算策略：限制每条证据 token 上限；超出做摘要/抽取。 3) 流程策略：优先 select-then-generate；必要时 chunk-by-chunk。 4) 可观测性：记录 {证据列表、顺序、长度、引用、答案}，支持回放。 5) 评测策略：引入位置扰动评测（front/middle/back），纳入回归。

7. 我的一句话总结

Lost in the Middle 的价值在于：它把“长上下文不稳定”从经验抱怨变成了可复现的 U 型位置效应。工程上最直接的应对不是继续堆上下文，而是把长上下文拆成“可控的证据选择与结构化消费”：重排到两端、两段式检索-回答、分块审阅、引用校验，以及位置敏感评测。

References

  • arXiv Abstract: https://arxiv.org/abs/2307.03172
  • arXiv PDF: https://arxiv.org/pdf/2307.03172