随着 Gemini 1.5 Pro、GPT-4o、Claude 3.5 Sonnet 等模型支持百万级上下文，企业开始把整个知识库“塞进”单次对话。但长上下文不等于好用，我们做了一组严格对照实验，测量真实 RAG（检索增强生成）场景下的表现。
一、测试方法与数据集
测试数据集包含：
- 内部技术文档：12 万行
- 公开法律合同：3 万条
- 多语言产品手册：8 种语言
查询类型分为：精确事实检索、跨文档推理、多跳查询。
二、关键指标对比
| 指标 | Gemini 1.5 Pro | GPT-4o | Claude 3.5 Sonnet |
|---|---|---|---|
| 支持上下文 | 2M token | 128K token | 200K token |
| 精确检索准确率 | 78.3% | 82.1% | 84.6% |
| 跨文档推理准确率 | 71.5% | 76.8% | 79.2% |
| 平均延迟（首 token） | 1.2s | 0.8s | 1.1s |
| 百万 token 成本 | $3.50 | $5.00 | $3.00 |
三、实测中的常见陷阱
1. “大海捞针”幻觉：即使能塞进 1M token，模型在长文本中段或尾段的精确信息提取仍会出现幻觉，尤其是插入在文档中间的表格数据。
2. 成本失控：把全部知识库放入单次请求，成本是传统 RAG 的 3-10 倍，且延迟线性增长。
3. 缓存失效：长上下文的 prompt caching 收益有限，尤其是当文档频繁更新时。
四、工程落地建议
建议采用“混合路由”策略：
- 简单事实查询走传统向量检索，成本低、延迟小。
- 复杂推理或法律/医疗场景，使用 200K-1M 上下文，但必须做“答案溯源”校验。
- 对成本敏感的场景，优先 Claude 3.5 Sonnet，准确率和成本平衡最好。
— IMAI 编辑部 | 2026-08-28
互动讨论：
1. 你的 RAG 系统目前使用多长的上下文窗口？遇到过哪些幻觉或成本问题？