微调还是提示词？大模型定制化的决策指南
很多团队在大模型项目初期都会纠结：要不要微调？微调听起来更“专业”，似乎能让模型真正掌握业务知识。但实际上，大多数问题用提示工程和检索增强就能解决，微调更适合解决“行为和格式”问题，而不是“知识”问题。 选错方案，往往意味着投入大量数据标注和训练成本，却得不到预期效果。
三种定制方式各解决什么问题
提示工程：告诉模型怎么做
通过系统提示、任务说明、示例和输出格式约束，引导模型完成任务。优点是零训练成本、迭代极快、随时可改。适合任务定义清晰、模型本身能力足够的场景。系统的写法可参考结构化提示词写法。
RAG：给模型提供资料
在回答前检索相关文档放进上下文。适合需要企业内部知识、频繁更新的信息、要求可追溯来源的场景。知识更新只需要更新文档库，不用重新训练。
微调：改变模型本身的行为
用特定数据继续训练模型，调整它的参数。适合以下情况：
- 需要稳定的特定输出风格或格式，而提示词很难完全约束；
- 某类任务需要大量示例才能讲清楚，放进提示词太长太贵；
- 希望用更小的模型达到接近大模型在特定任务上的效果，以降低推理成本和延迟；
- 需要模型掌握特定领域的表达方式、术语用法。
常见误区：用微调灌输知识
很多人希望通过微调让模型“记住”公司产品手册。这通常效果不佳：模型可能学到了语气和格式，却仍然会把具体参数记错，而且知识一旦更新就要重新训练。更合理的做法是用 RAG 提供知识，用微调（如果确实需要）规范回答方式。
一个逐步升级的决策流程
- 先用最好的通用模型 + 认真写的提示词做基线。很多人在这一步投入不够就急于微调。
- 建立评测集，量化当前效果，明确失败案例属于哪类问题：缺知识、格式不稳、推理错误还是风格不符。
- 缺知识 → 上 RAG；格式不稳 → 尝试结构化输出、少样本示例和程序校验。
- 提示词已经很长且效果仍不稳定，或推理成本过高 → 考虑微调，尤其是用较小模型做专项任务。
- 微调后用同一评测集对比，确认收益覆盖了数据、训练和维护成本。
微调的隐性成本
- 数据成本：高质量的训练样本需要人工整理和审核，通常是最耗时的部分，详见微调数据集构建指南；
- 维护成本：基础模型升级后，微调可能需要重做；
- 评测成本：需要持续验证微调没有损害模型的通用能力；
- 部署成本：自部署微调模型需要推理基础设施，使用厂商托管微调则可能有额外费用。
参数高效微调降低了门槛
LoRA 等参数高效微调方法只训练少量附加参数，显存需求和训练成本大幅下降，使得中小团队也能尝试微调开源模型。原理和实践可阅读 LoRA 微调原理与实践。
小结
把三种方式看成不同层次的工具：提示工程解决“怎么做”，RAG 解决“知道什么”，微调解决“习惯怎么表现”。先用低成本方案建立基线和评测，用数据证明需要微调时再投入，是最稳妥的路径。