两者解决不同问题
RAG 解决的是"知识"问题：让模型能访问它训练时不知道的信息。
微调解决的是"行为"问题：让模型以特定的方式、风格、格式来响应。
这个区分是选择的关键。
什么时候用 RAG
- 需要引用外部、动态更新的知识（产品文档、内部 wiki、最新资讯）；
- 需要可溯源——每个回答能标注来源；
- 知识库很大，且频繁变动；
- 缺乏足够的训练数据。
优势：更新知识库即刻生效，无需重新训练；成本低。
局限：受上下文长度限制；检索质量决定上限；模型仍需理解检索到的内容。
什么时候用微调
- 需要模型掌握特定的表达方式（品牌语调、行业术语、固定格式）；
- 需要模型学会特定的任务模式（如把非结构化文本转成特定 JSON）；
- 需要把大量稳定的领域知识压缩进模型（如法律条文、医学知识）；
- 希望减少提示词长度（把指令固化进模型，每次调用省 token）；
- 需要用小模型在特定任务上达到更好效果。
优势：推理时不需要额外的检索步骤，延迟低；行为一致性好。
局限：训练成本高；知识更新需要重新训练；可能损害模型的通用能力（灾难性遗忘）。
一个经典判断
微调教模型"怎么说"，RAG 给模型"说什么"。
如果你的问题是"模型不知道这些事实" → RAG。
如果你的问题是"模型说话的方式不对" → 微调。
微调的几种方式
全参数微调：更新所有权重。效果最好，但算力需求大，且每个任务都要保存一份完整模型。
LoRA / QLoRA：只训练少量低秩适配矩阵，冻结原始权重。
- 大幅降低显存需求和训练成本（QLoRA 可以在单张消费级显卡上微调大模型）；
- 训练出的适配器只有几十 MB，便于切换和分发；
- 效果通常接近全参数微调。
这是目前最实用的方案。
提示词微调（Prefix/Prompt Tuning）：只优化一段可学习的"虚拟提示"。参数量最少，但效果通常弱于 LoRA。
可以一起用
两者并不互斥：
- 先微调让模型掌握领域语言风格和输出格式；
- 再配合 RAG 提供最新的事实内容。
这是很多实际系统的做法。
起步建议
先做 RAG，再考虑微调。
原因：RAG 的验证周期短、成本低、可解释性强。很多"想微调"的需求，其实用好的提示词 + RAG 就能解决。
只有当确认瓶颈确实在"模型行为"而非"知识获取"时，才值得投入微调。
一个评估方法
在投入前，先手工做 20–30 个典型案例的测试：
- 用提示词 + RAG 能达到什么水平？
- 差距在哪？是知识不足，还是格式不对，还是理解偏差？
定位清楚问题，再决定手段。
说明：本文为大模型应用选型的知识整理。