RAG vs 长上下文 vs 微调：选型决策
「想让模型用上我的知识，到底该用 RAG、把资料全塞进长上下文，还是微调？」这是大模型落地与面试的高频选型题。三者不是互斥的「三选一」，而是解决不同问题、可叠加组合的手段。本文讲清各自原理边界、核心对比与决策路径。RAG 见 RAG 基础与流程，长上下文见 长上下文专题，微调见 微调范式（SFT / PEFT）。
一、先分清：它们各自解决什么
一个常见误区是把三者当成同类。其实：
- RAG：在推理时外挂知识库，解决「模型不知道某些事实/知识更新快/要可溯源」。
- 长上下文（Long Context）：把相关资料直接放进 prompt，解决「单次任务需要一大段完整上下文」。
- 微调（Fine-tuning）：改模型权重，解决「要稳定的风格/格式/领域语感/特定行为」，本质是教能力，不是塞知识。
一句话记忆：RAG 管「知道什么」、微调管「怎么表现」、长上下文管「这次给它看什么」。
二、RAG：原理与边界
通过检索把相关片段拼进上下文再生成（见 RAG 基础与流程）。
- ✅ 知识可实时更新：改库即生效，无需重训。
- ✅ 可溯源：答案能标注出处，企业合规友好。
- ✅ 成本可控：只把 Top-K 相关片段进上下文，token 省。
- ✅ 数据隔离：按权限/租户过滤检索，天然支持多租户。
- ❌ 依赖检索质量：召回不到就答不对，对全局性问题（"总结整本书")弱。
- ❌ 链路复杂：切分、嵌入、检索、Rerank 都要工程化（见 RAG 生产化与系统设计）。
三、长上下文：原理与边界
直接把长文档/多文档塞进模型的超长上下文窗口（几十万 token）。
- ✅ 简单：不用建检索系统，整篇喂进去。
- ✅ 保全局：跨段落推理、全文总结、长代码库理解更强（信息不被切碎）。
- ❌ 成本与延迟随长度增长：注意力开销随序列变大，长 prompt 又贵又慢；KV Cache 显存吃紧（见 推理优化与部署）。
- ❌ 「迷失在中间」（lost in the middle）：关键信息落在长上下文中部时，模型容易忽略。
- ❌ 知识不持久：每次都要重新塞，且窗口再大也有上限，海量知识库塞不下。
- ❌ 难溯源/难隔离：一锅烩，不好标注出处与做权限过滤。
四、微调：原理与边界
用领域数据更新权重（全量或 LoRA/QLoRA，见 LoRA / QLoRA 详解）。
- ✅ 稳定的风格/格式/行为：固定输出格式、领域口吻、特定任务范式，效果稳定。
- ✅ 领域语感/术语：让模型「说行话」、贴合专业表达。
- ✅ 推理时无额外开销：知识/能力内化进权重，不占上下文。
- ❌ 不擅长注入事实知识：硬塞新事实易灾难性遗忘且记不牢，知识一变就得重训。
- ❌ 更新慢、成本高：要准备数据、训练、评估、部署，迭代周期长。
- ❌ 不可溯源：答案来自权重，说不清出处，幻觉难定位。
关键认知：微调适合教「怎么做」（格式/风格/能力），不适合教「最新事实」——后者交给 RAG。
五、核心对比
| 维度 | RAG | 长上下文 | 微调 |
|---|---|---|---|
| 解决什么 | 外挂可更新知识 | 单次大段上下文 | 风格/格式/能力 |
| 知识更新 | 改库即时生效 | 每次重新塞 | 需重新训练 |
| 可溯源 | ✅ 强 | ❌ 弱 | ❌ 无 |
| 推理成本 | 中（只进 Top-K） | 高（随长度涨） | 低（内化进权重） |
| 前期成本 | 中（建检索链路） | 低 | 高（数据+训练） |
| 数据隔离/多租户 | ✅ 易 | ❌ 难 | ❌ 难 |
| 全局性任务 | 弱 | 强 | — |
| 注入新事实 | ✅ 强 | ✅（临时） | ❌ 弱 |
| 改风格/格式 | 弱 | 弱（靠 prompt） | ✅ 强 |
六、组合策略（实战里通常是「既要又要」）
- RAG + 长上下文：用检索缩小范围，把召回到的较长片段塞进长窗口，兼顾精准与全局——主流做法。
- RAG + 微调：微调让模型更会用检索内容（遵循引用格式、领域口吻），知识仍走 RAG 保持时效。
- 长上下文 + 微调：微调固定任务范式，长上下文喂具体材料。
- 三者皆可叠：微调定行为 + RAG 供知识 + 长上下文承载本次材料。
七、选型决策路径
按问题性质快速判断：
- 要不要用最新/私有事实知识？ → 要 ⇒ 上 RAG。
- 要不要可溯源、可按权限隔离？ → 要 ⇒ RAG（长上下文/微调都难）。
- 是不是单次任务需要一整篇/整库的全局理解？ → 是 ⇒ 长上下文（或 RAG 召回大块 + 长窗口）。
- 是不是要稳定的输出格式/领域风格/特定行为？ → 是 ⇒ 微调（LoRA 起步）。
- 知识更新频繁吗？ → 频繁 ⇒ 别用微调装知识，用 RAG。
- 预算与时效：先用 RAG / 长上下文 + Prompt 快速验证；确有稳定行为需求且数据充足，再补微调。
经验法则：能用 RAG/Prompt 解决就别先微调；微调是「最后一公里」的行为对齐，不是知识灌输的首选。
高频追问
- RAG、长上下文、微调能不能互相替代？ 不能，解决的问题不同：RAG 管知识与时效，长上下文管单次大材料，微调管风格/格式/能力，实战常组合。
- 为什么不推荐用微调来注入事实知识？ 易灾难性遗忘、记不牢、不可溯源，且知识一变就要重训；事实知识交给 RAG 更合适。
- 长上下文会取代 RAG 吗？ 不会全面取代：长上下文成本/延迟随长度上升、有「迷失在中间」、窗口有上限、难溯源与隔离；海量可更新知识仍靠 RAG，二者更多是组合。
- 什么时候该选微调？ 需要稳定输出格式、领域口吻、特定任务行为，且有足够高质量数据时；优先 LoRA/QLoRA。
- 「迷失在中间」是什么？ 关键信息位于长上下文中部时模型易忽略，是长上下文方案的已知弱点，可用重排/把要点前置缓解。
- 预算有限怎么排优先级？ 先 Prompt/长上下文 → 再 RAG → 最后才微调，能不训练就不训练。
- RAG + 微调怎么配合？ 知识走 RAG 保时效与溯源，微调让模型更会遵循引用格式与领域风格，各司其职。