检索不是目的，单位智能成本才是。
定价对比
| 模型 | 输入 $/M | 输出 $/M | 上下文 | 场景定位 |
|---|---|---|---|---|
| Sonnet 4.5 | $3 | $15 | 1M | 通用主力 + 长文档 |
| Opus 4 | $15 | $75 | 1M | 深度推理 |
| Haiku 3.5 | $0.25 | $1.25 | 200K | 边缘 / 批处理 |
口诀Sonnet 能干的，就别上 Opus。
RAG 成本决策
以 50 万字的代码库问答场景为例：旧方案需要 chunk + embed + top-k 检索，单次查询约 $0.02；Sonnet 4.5 直填整库约 $0.015，且没有检索误差。对中等规模文档场景，直接塞已经赢分。
中等文档 (< 80 万字)
- 典型表现
- 纠结要不要 RAG
- 判断标准
- 单次推理 < $0.03
- 解决方向
- 直填 Sonnet 4.5，RAG 下沉到 fallback
大文档 (> 500 万字)
- 典型表现
- 直填超上下文
- 判断标准
- 检索准确率 > 90%
- 解决方向
- 保留 RAG，但召回后用 1M 窗口做 rerank
实时对话
- 典型表现
- 首 token 延迟敏感
- 判断标准
- P99 < 1.5s
- 解决方向
- Haiku 主响应 + Sonnet 异步总结
架构建议
✓推荐做法
- 重新跑一遍成本表，按用量分桶评估
- 把 Sonnet 4.5 作为默认模型，Opus 作升级路径
- 对长文档任务重写 prompt，利用完整上下文
✗不推荐
- 盲目砍掉 RAG，一些场景检索准确性仍占优
- 忽略输出端成本——长上下文生成更容易爆 token
⚠常见误区
- 1M 上下文的 prompt 工程和 200K 完全不同，长输入下指令遵循变弱
判断标准：单位任务成本下降 ≥ 30%，才动架构。
当上下文足够便宜，RAG 就从必需品变成可选项。
— toy