面试官：为什么99%的项目，其实都不适合做微调

2023年，开源模型刚刚多起来的时候，上手AI做的最多的事情就是微调，那会儿我有一张3090，就足够微调GLM2-7B或者Llama2-8B的模型了，网上还有很多的教程，教你怎么找数据集、怎么构建数据集，怎么微调大模型。

仿佛只要学会了微调，我就一脚踏进了大模型工程师的门槛。

包括到现在，很多客户一开始就说：“我们要微调一个自己的模型，网上都这样说的。”然后14B也好，32B也好，拉一堆行业数据往里塞，觉得这样才算构建核心壁垒。

但连续了解几个项目之后，我现在的结论很清晰：对大多数做AI应用的团队来说，微调就是个坑。甚至面试的时候也会出现这个问题：为什么不建议微调？

到现在网上还有很多新发的教程，一张卡或者一台Mac mini部署14B模型，认为成本低、易控制、可试错。结果三个现实问题，让我们迅速清醒。

---

第一，真正消耗资源的不是训练，而是评估。

很多人觉得最贵的是那张卡。其实不然。真正昂贵的，是你如何验证模型“确实提升了”。在A问题表现不错，换到B问题就失灵了；今天刚调顺，明天数据一更新又开始波动。于是进入循环：调参、测试、改数据、再调参。

这个循环几乎没有边界，评估与维护的综合成本，可能是训练成本的数倍，甚至十倍。这会儿可能就会意识到，微调不是一次性投入，而是一种持续消耗的技术负担。

---

第二个问题更讨厌：底座模型一升级，你几个月的成果可能瞬间缩水。

你花时间精细优化的效果，厂商发布一个新版本，零样本能力直接超过你的成果。还记得我上面说的，GLM2吗，现在GLM5都发了，当时不管你拿多强的数据集微调的，现在都不一定打得过新版，这就是当前阶段的常态。底座模型的进化速度，远快于多数团队的优化节奏。

问题不在你不努力，而在于你用线性投入，对抗指数级跃迁。平台级模型每次迭代，都是算力、数据与算法的整体升级；应用团队，很难同步这种速度。

---

第三个问题：你在用应用层资源，对抗平台层能力。

当模型厂商一次升级投入是几十亿级时，一个小团队想靠参数微调构建护城河，本质是错位竞争。你调整的那部分参数，很可能在下一次版本发布时被覆盖。

而越来越多实践表明，很多场景根本无需改动参数。决定效果的，往往不是模型“是否被调过”，而是“输入是否足够好”：

模型效果≈底座能力×输入质量

如果把精力放在优化上下文结构、任务拆解方式、知识召回机制和反馈闭环，而不是修改参数，往往能获得更稳定、更可迁移、也更可升级的提升。

比如让系统自动沉淀经验，让模型在任务结束后进行反思与结构化总结；比如把行业知识整理为可检索、可复用的知识单元；比如优化上下文组织与行动路径。这些都是工程层面的增强，而不是参数层面的博弈。

---

踩过这些坑之后，我们的策略变得简单。

第一，把重点放在数据资产本身，而不是急着动模型。行业数据确实重要，但激活它的方式不一定是微调。通过结构化整理、知识抽象，再结合检索增强，把最相关的信息在合适的时机提供给模型，往往就能覆盖大部分垂直需求。

实际落地后发现，七八成的垂直场景，用“RAG+Prompt”就已经足够。效果稳定，而且模型升级后自动受益，无需重来。

第二，真正下功夫的是“上下文工程”。如今大模型的上下文窗口越来越大，竞争焦点正从“参数能力”转向“组织能力”。数据如何清洗、召回、压缩、排序，动作链路如何设计，这些决定了最终输出。结构化上下文加清晰任务设计，在很多场景下并不逊色于微调，而且更灵活。

第三，是心态问题。模型仍在快速进化，每天都有一个新的sota模型出现，与其在波动期做重资产投入，不如先把数据底座与业务闭环打牢。利用每一次模型升级带来的能力提升，让系统具备迁移性。等模型趋于稳定、微调框架标准化、成本结构更透明，再考虑深度定制，也不迟。

当然，微调并非毫无价值。

端侧小模型、资源受限设备、轻量分类任务，或者追求最后几个百分点准确率时，精调依然有意义。

但那是少数场景，而不是默认路径。现在这个阶段更合理的策略是：不要自己造船，而是借船远航。这就是现在Agent时代的特点，模型交给厂商，你真正的壁垒，在数据底座、场景理解、上下文工程能力，以及持续迭代的业务闭环。

与其花钱改模型，不如花精力改你喂给模型的内容。

对绝大多数团队来说，这才是更现实、也更稳健的选择。