微调（Fine-tuning）vs 提示工程 vs RAG：企业到底怎么选？

别急着改发动机，先练好驾驶技术

过去两年，我接触了近三十家尝试大模型落地的企业，发现一个普遍误区：手里一有业务数据，第一反应就是“我们要微调一个自己的模型”。结果往往是，花了三周清洗数据、两周调参，最终效果还不如直接在 Prompt 里写清楚规则，再外挂一个向量数据库。

这不是说微调没用，而是它的适用窗口比大多数人想的窄。要做出合理选择，得先把提示工程（Prompt Engineering）、检索增强生成（RAG）和微调（Fine-tuning）放到同一个坐标系里比较。简单来说：提示工程是驾驶技巧，RAG 是开卷考试允许带资料，微调则是改装发动机。多数路况，好司机加一本地图就够了。

五个维度的决策框架

在实际项目中，我会让客户先回答五个问题。

1. 数据量到底有多少？

高质量标注数据低于 1000 条，通常不建议微调。2023 年底，一家工业设备制造商拿 200 条内部 FAQ 做 LoRA 微调，期望能精准回答设备故障代码。结果模型把“E-302”和“E-320”的维修步骤混淆，准确率只有 62%。后来改用 RAG，把 8000 页技术手册切片进向量库，配合 Prompt 里强制要求“只基于检索内容回答”，准确率提升到 89%。数据量小且分散时，RAG 比微调更不容易过拟合。

2. 知识更新有多快？

如果你的业务知识按周甚至按天更新，微调的成本结构会让你崩溃。某券商合规部门曾试图用微调让模型掌握最新的监管条文，结果每季度要重新跑一遍训练，单次 A100 80G 四卡训练约 6 小时，加上数据验证和回滚测试，完整发版要两天。而 RAG 只需要在向量库里替换新文档，从文档入库到上线，半小时就能完成。更新频率高于每月一次，优先考虑 RAG。

3. 领域专有性体现在哪儿？

这是最容易误判的维度。如果“专有性”只是企业内部知识库（如产品规格、客户合同），RAG 完全可以覆盖；但如果需要改变模型的推理习惯、输出格式或行业黑话的理解深度，微调才有价值。举个例子，某三甲医院的病历生成系统，用 RAG 能检索到疾病指南，但模型总把“主诉”写成散文体。后来他们用 5000 份脱敏病历做全量微调，让模型学会了病历的 SOAP 格式和医学缩写，才解决了风格问题。要改“表达方式”而非“知识储备”，才轮到微调。

4. 成本账怎么算？

以 7B 参数级开源模型为例，一次完整的 LoRA 微调，云厂商 A100 实例按量计费约需 800–1200 元；但如果算上数据标注、实验迭代、模型评测和部署推理的 GPU 常驻成本，一个微调的 MVP 通常要烧掉 3–5 万元。而提示工程加 RAG 的方案，初期只需调用 API 和租用向量数据库，千次调用成本在几元到几十元之间，验证阶段的费用往往不到 5000 元。对于尚未验证 PMF 的场景，先用低成本方案跑通闭环，是更务实的选择。

5. 上线速度要求多急？

从项目 kickoff 到生产环境，提示工程 + RAG 的 POC 通常一周左右可以交付；微调则至少需要预留一个月——数据清洗占一半时间，调参和幻觉修复占另一半。去年一家跨境电商要做多语言商品描述生成，业务方给的时间只有 10 天。团队用 Prompt 模板加动态注入竞品关键词的 RAG 方案，第 7 天就上线了英文和德语版本。如果坚持微调，项目大概率会直接错过营销节点。

多数企业的合理路径

基于以上五个维度，我的建议很直接：除非你已经明确需要改变模型的行为模式或输出风格，否则一律先从“提示工程 + RAG”起步。这个组合能覆盖 80% 以上的企业应用场景，包括内部知识问答、客服助手、报告生成和合规检查。

什么时候该引入微调？通常是 RAG 已经遇到明显天花板之后：比如检索召回的上下文相互干扰，导致模型无法整合多段信息；或者业务要求低延迟、高并发，必须把知识压缩进模型权重以减少检索链路；再或者你手里有超过 5000 条、经人工校验的高质量数据，且业务规则半年内不会大变。这时，微调可以作为“第二阶段的优化”，而不是“第一步的标配”。

技术选型没有银弹，但有清晰的优先级。先让数据跑起来，让业务看到价值，再决定要不要花大力气改装发动机。