引言
2023 年，论文《Lost in the Middle: How Language Models Use Long Contexts》揭示了一个令人不安的事实：当上下文包含大量信息时，模型对中间位置的信息经常「视而不见」。
研究者做了一个实验：在一段长文本的不同位置放一个关键事实，然后让模型回答关于这个事实的问题。结果是：
信息位置 vs 模型准确率（示意）：
位置 0%（开头）: ████████████ 95%
位置 25%: ██████████ 85%
位置 50%（中间）: ██████ 55% ← 大幅下降！
位置 75%: █████████ 80%
位置 100%（结尾）: ████████████ 93%
结论：信息放在中间，模型经常忽略它。这个发现引发了 AI 社区的一场讨论：当模型支持超长上下文时，我们还需要 RAG 吗？
NL1997-
Nelson F. Liu
斯坦福大学博士，Lost in the Middle 论文共同作者
"当相关信息被放置在长上下文的中间位置时，模型的表现会显著下降。"
长上下文：把所有东西塞进去
长上下文的优势
优点：
✓ 简单——不需要向量数据库、不需要检索管线
✓ 完整——模型能看到所有信息
✓ 没有检索误差——不会漏掉重要文档
示例场景：
把一本 50 页的技术手册全部放进上下文
用户提问 → 模型直接在手册中找答案
不需要先做 chunking → embedding → 检索长上下文的代价
成本：
假设一份文档有 100K tokens
每次调用都要发送这 100K tokens 作为输入
GPT-4o 输入价格：$2.50/1M tokens
单次调用输入成本：$0.25
如果每天 10000 次调用 → 每天 $2500 → 每月 $75,000 💀
性能：
├── 推理延迟随上下文增长（注意力计算 ∝ N²）
├── Lost in the Middle 效应
└── 模型可能在大量无关信息中「迷失」长上下文擅长的场景
✅ 整文档分析
"帮我总结这份 100 页的报告"
→ 需要看完整文档，RAG 的片段检索不够
✅ 全局推理
"这份文档中有哪些相互矛盾的声明？"
→ 需要对比文档的不同部分
✅ 简单场景
文档不大（< 50K tokens），查询频率低
→ 不值得搭建 RAG 基础设施RAG：精准投喂
RAG 的优势
优点：
✓ 精准——只检索相关内容，减少噪音
✓ 低成本——每次只发送 3-5K tokens 的上下文
✓ 可扩展——文档库可以无限增长
✓ 实时——可以检索最新数据
成本对比（同样的 100K 文档库，每天 10000 次调用）：
长上下文：
每次发送 100K tokens → 每月 $75,000
RAG：
每次发送 3K tokens（检索结果） → 每月 $2,250
成本降低了 97%RAG 的劣势
✗ 检索可能遗漏
关键文档没被检索到 → 模型无法回答
✗ 上下文碎片化
文档被切成 chunk → 丢失全局上下文
"第三章提到的那个方案" → chunk 不包含第三章标题
✗ 基础设施复杂
需要：向量数据库、Embedding 管线、Chunking 策略、Reranker...
✗ 维护成本
文档更新 → 重新 Embedding → 更新数据库两条路线的选择
决策矩阵
| 维度 | 长上下文 | RAG |
|---|---|---|
| 实现复杂度 | 低 | 高 |
| 单次查询成本 | 高 | 低 |
| 大规模文档 | 不适合（成本爆炸） | 适合 |
| 全局推理 | 强 | 弱（碎片化） |
| 实时数据 | 不支持 | 支持 |
| 准确性 | 受 Lost in Middle 影响 | 受检索质量影响 |
选择建议
用长上下文当：
├── 文档 < 50K tokens
├── 查询频率低（每天 < 100 次）
├── 需要全局理解（总结、对比、推理）
└── 原型开发阶段（快速验证）
用 RAG 当：
├── 文档库 > 100K tokens
├── 查询频率高（成本敏感）
├── 文档频繁更新
└── 需要实时数据混合方案：长上下文 + RAG
最佳实践：两者结合
Step 1: 用 RAG 检索 top-K 相关 chunk
Step 2: 把这些 chunk 放入长上下文窗口
Step 3: 模型在充足上下文中做推理
优点：
├── 成本可控（只发送相关 chunk）
├── 信息精准（RAG 过滤了噪音）
├── 推理充分（模型有足够的上下文）
└── 可扩展（文档库可以无限增长）趋势：收敛
2023 年：长上下文和 RAG 是两条独立路线
2024 年：业界开始融合两者
2025 年：越来越多的系统采用混合方案
根本原因：
长上下文越来越长（128K → 1M → 2M）
但成本仍然是问题
RAG 精准 + 长上下文推理 = 最佳平衡
未来的可能性：
如果模型成本持续下降，长上下文可能覆盖更多场景
但对于大规模、高频率的生产系统，RAG 不会消失本节小结
| 概念 | 要点 |
|---|---|
| Lost in the Middle | 模型容易忽略上下文中间的信息 |
| 长上下文 | 简单但成本高，适合小文档和全局推理 |
| RAG | 精准且低成本，适合大规模文档库 |
| 选择依据 | 文档大小、查询频率、是否需要全局推理 |
| 混合方案 | RAG 检索 + 长上下文推理 = 最佳平衡 |
思考题
- 如果模型的上下文窗口可以免费扩展到 1000 万 token，我们还需要 RAG 吗？
- 你如何设计一个系统，自动判断应该用长上下文还是 RAG？
- 「Lost in the Middle」现象不仅影响 RAG，也影响长上下文。你在实际使用中遇到过这个问题吗？