何时不该微调：RAG、提示或API更好的5种情况

Ertas是一个微调平台。我们构建它是因为微调解决了提示和RAG无法解决的真实问题。但我们也看到团队花数周微调模型用于更简单方法本可以更好解决的任务。那是浪费的时间和金钱。

我们宁愿你用正确的方法成功，也不愿你用微调失败。以下是五种你不应该微调的情况——以及应该怎么做。

情况1：你的知识库频繁变化

场景： 你在为电商公司构建客服机器人。产品目录、定价、退货政策每周变化。

为什么微调在这里是错的： 微调在训练时将知识烘焙到模型中。要保持模型最新，你需要每次变化都重新训练。

替代方案：RAG。 检索增强生成在查询时从知识库检索相关文档。更新文档，模型在每次请求时看到当前信息而无需重新训练。

情况2：你需要模型引用来源

场景： 你在为咨询公司构建研究助手。每个声明必须可追溯到来源。

为什么微调在这里是错的： 微调模型将信息吸收到权重中。它无法指向支持其输出的特定文档。

替代方案：带检索元数据的RAG。 RAG系统从已识别的文档中检索特定文本块，每个块携带元数据。引用是真实的。

情况3：你只是偶尔需要一次性任务

场景： 你需要一次性迁移5,000个产品描述。

为什么微调在这里是错的： 微调有固定的前期成本。对于只运行一次的任务，这个投资通常超过直接使用API的成本。

替代方案：使用精心设计的提示的API。 对于一次性批处理任务，API方法设置更快、更容易迭代、成本大致相同。

情况4：你的任务需要广泛的世界知识

场景： 你想要一个能回答从小学到研究生水平跨数十个学科的通用问题的模型。

为什么微调在这里是错的： 微调缩窄模型。它通过将权重专门化向训练分布来使模型在特定任务上更好。7B模型微调在5,000个示例上无法在广度上与大型模型竞争。

替代方案：通过API使用大型前沿模型。

情况5：你还没先尝试好的提示工程

场景： 你有一个任务。你写了基本提示。输出不好。你得出需要微调的结论。

为什么微调在这里是错的： 这是我们看到的最常见错误。团队在写了200字的系统提示并测试10个示例后就跳到微调。他们没有尝试少样本示例、思维链提示、结构化输出指令或迭代提示改进。

好的提示工程比微调更快更便宜迭代。提示更改需要几秒钟测试。微调更改需要几小时。始终在投入训练之前穷尽提示优化。

决策流程图

1. 你是否彻底优化了提示？ 如果没有，先做那个。
2. 你的任务需要频繁更新的知识吗？ 如果是，使用RAG。
3. 你需要来源引用吗？ 如果是，你需要检索组件。
4. 这是一次性或低量任务吗？ 如果每天少于50个请求且没有持续需求，使用API。
5. 任务需要跨多领域的广泛知识吗？ 如果是，使用大型前沿模型。
6. 你的任务是狭窄的、高量的、且需要一致行为吗？ 如果三个都是，微调。这是微调擅长的地方。

何时组合方法

RAG + 微调模型。 用RAG做知识检索，用微调模型做响应生成。这通常是最佳架构。

微调 + 提示工程。 即使微调模型也受益于系统提示。

微调 + API后备。 对于90%狭窄和10%广泛的任务，微调处理90%，将剩余10%路由到前沿API。

诚实评估

微调是强大的技术。但不总是正确的工具。成功的团队是那些将技术匹配到问题的——不是那些将最爱的技术应用到每个问题的。

---

相关阅读：

• 微调 vs RAG：何时使用哪个（以及何时组合）
• 提示工程有上限。之后是什么。
• 为客户推荐微调 vs RAG：代理商指南