AI产品开发中，微调模型往往被视为默认选择，但真的是最优解吗？本文通过真实案例揭示，80%的场景其实通过提示工程就能搞定，而微调不仅成本高昂，还可能导致模型能力缩水。从最小可行方案到知识蒸馏，作者以产品经理视角，为你拆解如何用更聪明的方式驾驭AI模型，把钱花在刀刃上。

1. 为什么微调不是最优选择？因为最优选择可能不是它

做AI产品这两年，我见过最多的场景就是：团队一上来就说“咱们微调一下模型吧”。好像不微调就显不出技术含量似的。可问题在于，绝大多数时候，微调的钱花得真不值。我做过一个项目，业务方想用大模型做客服问答，一开始就奔着微调去，花了十几万，调了两周，结果上线后用户问个“退款流程”，模型直接编了个不存在的政策。后来换成RAG——就是检索增强生成，简单说就是把知识库当外挂，模型不懂就去查——不仅回答准确了，还省掉了每次业务调整都要重新微调的苦力。

基础模型本身已经很强了，GPT-4、Claude 3.5这些，通用知识、推理能力摆在那里。你非要拿它去微调一个特定领域的任务，很容易给它“调傻了”。比如你只拿客服对话数据微调，模型可能就忘了怎么跟人聊天气、写邮件，能力范围越变越窄。我管这个叫“过拟合的诅咒”——你以为它在变聪明，其实它在变笨。做过产品的人都懂，一个能力缩水的模型，后期维护成本比你省下的那点训练费高得多。

从产品角度看，微调应该永远是最后手段，而不是默认选项。先问问自己：提示工程能不能解决？能不能在prompt里塞几个例子、加一段系统指令？大部分场景，80%的问题其实靠精心设计的prompt就能搞定。比如我们之前做一个文档摘要功能，团队想微调，我拦住了，只是在system prompt里写了“请用三句话概括，第一句说结论”，效果一样好，迭代还快——改prompt几分钟，微调一轮至少半天。

我不否认微调在某些场景下的价值，比如你要让模型学会一种全新的表达风格，或者处理极其专业的术语。但那样的场景，说实话，100个产品里未必有10个。微调的门槛被严重低估了——不是技术门槛，而是决策门槛：你真的需要为了那10%的效果提升，付出90%的灵活性代价吗？至少在我做的产品里，答案越来越清晰——不调，才是更聪明的选择。

2. 最小可行方案：用提示工程解决80%的问题

做产品六年，我踩过最深的坑就是动不动想微调。刚碰AI那会儿，接到任务第一反应就是“得训个模型吧”，好像不调一下就不配叫AI产品。直到有一次做客服意图分类，团队花了两周准备数据、跑微调，上线后准确率还不如一个写了两小时的提示模板。那个模板只有三条示例，零训练成本。从那以后我学乖了——先问自己：提示工程能搞定不？

提示工程听着玄乎，做起来其实特实在。核心就三件事：把任务说清楚、给几个好例子、定好输出格式。去年我们做合同条款提取，业务方要从2000份PDF里抽关键日期和金额。我让实习生先写个提示，配上GPT-4的API跑了一轮，准确率直接到了87%。业务方挺满意，说够用了。剩下的13%是格式不一致和漏提取，后来加了两轮few-shot就提到了94%。从头到尾，没花一分钱算力，没等一天训练时间。

有人会问，那剩下的20%咋办？我信奉先跑通再优化。最小可行方案的意义，不是让你永远停在80%，而是用最小成本验证“这事能不能做”。如果提示工程就能覆盖核心场景，那微调的钱和时间完全可以花在更关键的地方——比如打磨产品体验，或者搞定那20%里真正影响用户体验的少数case。我见过太多团队上来就微调，调完发现业务需求变了，又得重调，钱烧了，人累了，产品还没上线。

所以我现在带团队有个硬规矩：任何新任务，至少用提示工程跑一周再说。不试够一周，不准提“微调”二字。这一周里，你要迭代提示、收集bad case、看真实效果。很多时候，一周后业务方自己就说了：“好像够了，先上吧。”到这一步，你已经用最小成本锁定了80%的价值。剩下的可以慢慢优化，甚至可以等模型本身升级——毕竟大模型迭代这么快，说不定下个版本就自动搞定了。

3. 最优可行方案：知识蒸馏或小模型适配，比全量微调聪明

聊个去年的项目吧，印象太深了。客户要做法律咨询助手，模型得准确引用法条，还得区分不同司法解释。团队里有人直接喊：微调一个7B大模型吧，效果好！我掰着手指头算了笔账：租A100，训一周，加上数据标注和迭代调试，光这一轮就得小十万块。而且呢，业务一调整——比如新增个司法解释——又得重来，成本根本兜不住。后来我们换了个路子：用GPT-4生成一万条高质量问答对，拿去训练一个300M的小模型，再搭个检索系统补知识。结果呢？准确率只比大模型微调低了2%，但推理速度快了一倍，训练成本不到原来的十分之一。业务团队两个月就上线了，到现在跑得稳稳的。

这事让我彻底想通了：最优可行方案，从来不是技术最炫的那个，而是让业务团队能最快用起来、成本可控的那个。知识蒸馏就是典型——用大模型当老师，教一个小模型学会核心能力，学生模型跑起来又轻又快。你不需要把整个大模型的能力都保留，只蒸馏出业务需要的那些知识。比如客服场景，只蒸馏意图识别和话术匹配，其他能力砍掉，模型体积能缩小十倍，部署成本直线下降。

如果必须保留大模型架构，那也得选参数高效微调，比如LoRA。LoRA的做法是冻结原始权重，只训练一小批低秩矩阵，参数量通常只有全量微调的1%到2%。我见过一个团队做代码补全，全量微调一个CodeLlama 7B要花12小时，用LoRA加个适配器，1小时就训完，效果几乎没差别。关键是业务调整时，你只需要换一个适配器文件，不用动基座模型，迭代成本极低。

所以我的判断是：如果业务场景需要模型具备特定能力，先别急着全量微调。优先试蒸馏，用小模型跑；不行再上LoRA这类轻量方法。把全量微调当作最后一张牌，轻易别打。这样你的预算能省下一大半，留给真正需要深挖的环节——比如数据质量、评测迭代。业务团队不用等几个月，几周就能看到效果，他们开心，你也省心。

4. 省钱的哲学：把微调预算砍掉一半，业绩反升

六年产品，两年在AI上。掏心窝子的话：微调预算砍一半，业绩反而往上窜。不是玄学。去年一个项目，团队八成钱砸微调里，模型来回刷了三轮。效果？不到5%。我直接叫停后续微调，把钱扔到数据清洗和用户反馈上。三个月后，用户满意度涨了12%。微调的边际收益，跌得吓人。第一轮能涨20%，第二轮就10%，第三轮只剩3%。越往后投，每分钱越不值。

过早搞微调，跟产品没验证需求就急着扩团队一个德性。我见过太多团队，模型刚跑通基线，领导一拍大腿：调一调吧。结果一调两个月，业务逻辑早变了，调出的权重全废。更坑的是沉没成本陷阱。你砸了50万，舍不得停，又追100万，最后模型过拟合到连训练数据里的噪声都记住了。用户吐槽它像复读机，团队还在那分析：是不是学习率没调好？不是，方向压根就错了。

省下的钱去哪？我倾向投数据质量。同样一批语料，清洗掉30%的垃圾、去重、做对抗样本，效果提升比再训一轮微调明显得多。用户体验优化也是好去处。比如给大模型加个校验层，或者把回复速度从3秒压到1秒。用户能直接感受到，微调后的参数调整，他们多半无感。去年我们砍了40%的微调预算，全砸在数据标注和A/B测试工具上，业务指标硬是涨了8%。

所以现在我看项目，第一反应不是能不能调，而是能不能不调。微调不是不能做，但你得想清楚：这笔钱投下去，换来的到底是什么？如果只是几个百分点的准确率提升，而用户压根不在乎，那就不如省下来。省钱的本质不是抠门，是把钱挪到产出更高的地方。做AI产品两年，我最庆幸的，就是学会了说不调。