RAG、长上下文、微调：什么时候该用哪个
先分清三个方案各自解决什么
很多讨论把 RAG、长上下文、微调当成「三选一的竞品」，其实它们解决的是三个不同问题：
| 方案 | 解决的问题 | 一句话 |
|---|---|---|
| RAG | 知识不在模型里，且会变 | 先检索，再让模型基于检索结果回答 |
| 长上下文 | 知识能塞进去，但量大 | 把资料直接放进 prompt |
| 微调 | 风格/格式/任务模式不对 | 用数据改变模型的输出习惯 |
判断依据只有一个：你的问题到底是"不知道"还是"不会"？
- 不知道（知识缺失、时效性）→ RAG 或长上下文
- 不会（格式总错、语气不对、任务做不利索）→ 微调
- 都不是（模型本来就会）→ 别做任何改造，直接调 API
一、RAG vs 长上下文：不是替代关系
「上下文都 1M 了，还要 RAG 吗？」——这个问题的答案取决于三件事。
什么时候长上下文够用
- 资料总量稳定且不大（比如一份 50 页的产品手册，2 万 token）
- 每次都要通读全文，而不是只查某一段（如全文摘要、整体风险评估）
- 请求量不大，成本可接受
这种情况下，全塞进上下文最简单、效果最稳：没有检索遗漏，没有分块切坏语义的问题。
什么时候必须 RAG
| 情形 | 为什么长上下文不行 |
|---|---|
| 知识库很大（几百 MB 文档） | 塞不下 |
| 请求量大 | token 是 O(n)，成本线性爆炸 |
| 知识频繁更新 | 每次都塞全量，还得管缓存失效 |
| 需要引用出处 | 检索结果天然带来源 |
| 上下文长了准确率下降 | 「大海捞针」失效，中间内容被忽略 |
核心经济账：RAG 通常只把 1~3K token 的相关片段喂给模型；全塞是 50K~500K token。同样的任务，成本差 20~100 倍。
混合方案（很多生产系统的真实形态）
先用 RAG 检索 → 把 top-k 片段（1~3K token）塞进上下文 → 模型只读这一小块
既控制了成本，又保留了「基于原文回答」的可信度。这才是默认应该选的方案，除非你的资料确实很小。
二、微调：解决"不会"，不解决"不知道"
这是最容易被误用的一项。很多人想用微调「灌知识」，结果发现：
- 微调很难可靠地注入事实性知识，模型会记住大概，但细节容易错
- 知识一变就得重训，维护成本高
- 微调后的模型在通用能力上可能退化（灾难性遗忘）
微调真正擅长的是：
| 场景 | 例子 |
|---|---|
| 格式约束 | 稳定输出特定结构的 JSON / 特定模板 |
| 风格与语气 | 品牌口吻、客服话术、特定文体 |
| 任务模式 | 复杂的分类体系、行业术语理解 |
| 降本 | 用微调的小模型替代大模型的 prompt 工程 |
判断标准：如果「告诉它怎么做」就能做好，就不要微调。只有当 prompt 里塞不下那么多规则、或者规则太多导致不稳定时，才考虑微调。
三、决策树
模型完全不知道这件事？
├── 是 → 知识量小且稳定？
│ ├── 是 → 长上下文（全塞）
│ └── 否 → RAG（检索后塞片段） ← 大多数情况
└── 否 → 输出格式/风格/任务模式不对？
├── 是 → 规则能不能写进 prompt？
│ ├── 能 → 改 prompt + few-shot（先试这个）
│ └── 不能 → 微调
└── 否 → 什么都不做，直接调 API
顺序很重要：总是从便宜、可逆的方案往上走 —— 改 prompt → RAG → 微调。反过来做，经常是花了三周训模型，最后发现改两行 prompt 就解决了。
四、成本与工程复杂度对比
| 改 prompt | RAG | 长上下文 | 微调 | |
|---|---|---|---|---|
| 一次性投入 | 小时级 | 天级（分块+向量库+评测） | 小时级 | 周级（数据+训练+评估） |
| 每次调用成本 | 低 | 低（1~3K token） | 高（O(n)） | 低（小模型） |
| 知识更新 | 改 prompt | 更新索引即可 | 重新塞 | 重新训练 |
| 可解释性 | 一般 | 好（有来源） | 中 | 差 |
| 主要风险 | 规则堆太多不稳定 | 检索质量 | 长文准确率衰减 | 灾难性遗忘 |
五、RAG 的三个真实坑
如果你选 RAG，这三个坑基本躲不掉：
1. 分块策略决定上限
按固定字数硬切，会把一句话、一个表格切成两半，检索出来的是残缺信息。
- 优先按语义边界切（标题、段落、列表项）
- 块不要太小（丢上下文）也不要太大（噪声多），常见 300~800 字
- 加重叠（overlap 10%~20%）防止边界信息丢失
2. 检索质量 > 模型质量
检索错了，再强的模型也只能基于错误材料回答。常见失效：
- 用户用词和文档用词不一致（需要 query 改写或同义词扩展）
- 只有一个关键词命中，语义其实不相关（需要 rerank 重排序）
建议：先上向量检索，再加一层 rerank 模型，召回率提升通常很明显。
3. 必须要求"引用 + 拒答"
不要求引用，模型会拿检索片段自由发挥；不给拒答出口，检索不到时它会编。
规则：
1. 只依据【参考资料】回答，不得引入外部知识
2. 每个结论后标注来源片段编号，如 [3]
3. 若参考资料不足以回答，输出"资料中未提及"，不要猜测
六、一句话总结
- 不知道 → RAG（资料大）或长上下文（资料小）
- 不会 → 微调（规则写不进 prompt 时）
- 都会 → 别改造，直接调 API
- 顺序：prompt → RAG → 微调，从可逆到不可逆