长上下文的位置效应是什么
Lost in the Middle 指的是长输入里的召回率并不均匀：模型对开头与结尾的信息记得较牢，对中段内容容易忽略，整体呈 U 形分布。工程上的应对有三条：关键指令与输出要求放开头或结尾；重要文档放在最前面；超长内容优先做分块检索而不是整篇塞进窗口。要记住窗口大小是容量指标而不是质量指标，同样的问题用检索方案控制在两万 token 内，答案准确率常常高于把十几万 token 全部塞进去。
基本信息
| 现象 | 中段召回率低于首尾，呈 U 形分布 |
|---|---|
| 输入排布 | 长文档在前，问题与输出要求在最后 |
| 替代方案 | 分块加检索优于整篇塞入 |
| 验证方法 | 用大海捞针测试验证自己的输入结构 |
| 成本影响 | 输入越长计费越高，延迟也上升 |
| 适用场景 | 长报告问答、多文档对比、条款定位 |
典型使用场景
- 长报告问答：定位散落在中段的数字与结论
- 合同条款核对：确认关键条款是否遗漏
- 多文档对比：多份材料同场比较时的排布控制
- 会议纪要汇总：多段记录合并成一份结论
- 检索增强：决定召回片段的数量与摆放顺序
推荐输入结构
推荐输入结构
<instructions>
只依据 documents 中的内容回答，找不到就回答未提及。
</instructions>
<documents>
（长文档内容放这里，最相关的材料放最前面）
</documents>
<question>
请根据以上文档回答问题：违约金比例是多少？
</question>
# 问题放最后，输出格式要求紧跟问题之后
# 关键约束可以在开头与结尾各写一次，对抗中段忽略
# 超长材料先切块检索，只把命中的片段放进来输入排布检查表
| 位置 | 放什么 | 原因 |
|---|---|---|
| 开头 | 角色与硬约束 | 首因位置注意力最强，约束最不容易丢 |
| 中部 | 参考资料主体 | 内容多时可接受，规模靠检索控制 |
| 结尾 | 问题与输出格式 | 近因位置对生成影响大 |
| 头尾重复 | 关键约束复述一次 | 降低被中段稀释的概率 |
用大海捞针自测自己的排布：把一条已知答案埋在文档不同位置，看模型能否稳定找出，再决定是调排布还是改分块。
窗口变大不等于可以省掉检索：检索方案还带来成本可控、可引用出处、可做权限过滤三个额外收益，长窗口只解决容量问题。