RAG 还是微调：如何为 LLM 应用选择正确方案

团队在构建基于 LLM 的应用时，我最常被问到的一个问题就是：应该用 RAG（检索增强生成）还是微调？诚实的答案是：看情况——但具体看什么呢？

核心区别

RAG 在推理时从外部知识库中检索相关内容，然后注入到提示词中。模型本身并不"知道"这些事实——它是实时读取的。

微调 则在训练阶段修改模型的权重，使其内化特定的模式、风格和知识。模型通过权重来"记忆"。

什么时候选 RAG

• 数据频繁变化 — 如果知识库每天甚至每小时都在更新，微调就成了维护噩梦。RAG 可以在不重训练的情况下随时替换语料。
• 知识库体量庞大 — 你不可能在数百万份文档上做微调，上下文窗口也装不下。RAG 在查询时提取最相关的片段。
• 需要可追溯性 — RAG 答案会标注来源。微调后的模型会自信地产生幻觉。在法律、医疗、合规等场景中，这一点至关重要。
• 成本敏感 — 微调的计算成本和后续 API 费用都很高。RAG 只需要一个标准 LLM 加上向量数据库。

什么时候选微调

• 需要一致的行为和语气 — 如果你希望模型无论在什么上下文下都按特定风格或格式回应，微调比提示词更可靠。
• 特定领域的推理模式 — 对于代码生成、法律分析、医疗诊断等专业推理任务，在领域样本上微调比单独使用 RAG 效果更好。
• 低延迟要求 — RAG 增加了检索步骤（通常 50-200ms）。如果需要亚 100ms 响应，微调模型可能是必要的。
• 离线或无连接场景 — 微调后的模型知识内化在权重中，不需要联网。

决策框架

我用一个简单的 2x2 框架来思考这个问题：

如果你的主要需求是大规模、动态语料上的知识准确性 → 选 RAG。如果你的主要需求是稳定领域中的行为一致性 → 选微调。

实际上，最佳的生产系统通常两者结合：RAG 提供最新事实，微调确保风格和推理模式一致。但先从其中一种开始，只有在有可衡量的证据证明需要时，才添加另一种。

给大多数团队的建议

从 RAG 起步。成本更低，迭代更快，调试更容易。只有在穷尽了更好的检索、更好的提示词和更好的评估之后，再考虑微调。

RAG 工具链已经非常成熟——CloudBase 向量数据库让索引和搜索数百万文档变得轻而易举，延迟还不到 100ms。先在那里构建，再看效果。