一个看似合理的问题
Gemini 1.5 Pro 支持 100 万 token 上下文，Claude 3.5 支持 20 万 token，GPT-4 Turbo 12.8 万 token。一部小说大约 15 万字，约 20 万 token，直接塞进去就能问。有人问：RAG 还有必要吗？
这个问题值得认真回答，因为它背后藏着一个真实的决策：给一个生产系统，我应该用 RAG 还是长上下文？
先把数字摆出来
大语言模型的上下文窗口（2024–2025）：
| 模型 | 上下文窗口 | 约合文本量 |
|---|---|---|
| Gemini 1.5 Pro | 1,000,000 tokens | ~750,000 词，约 1500 页 |
| Claude 3.5 Sonnet | 200,000 tokens | ~150,000 词，约 300 页 |
| GPT-4 Turbo | 128,000 tokens | ~96,000 词，约 190 页 |
| GPT-4o | 128,000 tokens | ~96,000 词，约 190 页 |
看起来很多。但一个企业知识库有多少内容？
- 中等规模公司的内部文档：数千篇，数百万字
- 大型代码库：数万个文件，十亿 token+
- 新闻/研究数据库：数百万篇文章
所有这些都超出了任何模型的上下文窗口。这是长上下文能力的物理上限。
长上下文的实际代价
“窗口大"不等于"免费”。每次请求都要处理所有 token，代价是真实的。
代价一：钱
按 2024 年末的价格粗估（输入 token）：
| 模型 | 每百万 token 价格 | 100 万 token 一次请求 |
|---|---|---|
| Gemini 1.5 Pro | $1.25 | $1.25 |
| Claude 3.5 Sonnet | $3.00 | $3.00 |
| GPT-4 Turbo | $10.00 | $10.00 |
对比 RAG 的成本：
- 检索阶段：只调用 Embedding API（< $0.001）
- 生成阶段：只发送 2,000–5,000 token 的检索结果 + 问题（< $0.05）
同样的问题，RAG 的成本可以比长上下文低 20–200 倍。
如果一天有 1,000 个用户查询企业知识库：
- 长上下文（1M token）：约 $1,250/天
- RAG（3K token 上下文）：约 $3–15/天
代价二：延迟
处理更多 token = 更慢的响应。首 token 延迟（TTFT）随输入长度线性增长：
100K token 输入 → TTFT ~2–5 秒 1M token 输入 → TTFT ~15–30 秒（视模型和基础设施）对话类应用 30 秒才开始输出，用户体验基本无法接受。
代价三：中间丢失问题
2023 年 Stanford 的研究 “Lost in the Middle”（Liu et al.）发现：当相关信息放在长上下文的中间时，LLM 的召回表现显著下降。信息在开头或结尾时表现最好，在中间时表现最差。
位置 vs 召回率（近似趋势）： 开头（0-10%） ████████████████ 高 中间（40-60%） ██████ 低 结尾（90-100%） ████████████ 较高这意味着你把 100 篇文档全塞进去，模型不一定能找到放在 50 号位置的那篇。
RAG 的实际代价
RAG 不是没有代价的。
代价一：检索不完美
向量检索是近似匹配，会出错：
- 漏检（False
