先试最便宜的办法

很多团队第一次做模型微调时，第一反应是调学习率、LoRA 秩、量化参数。但真正决定项目成败的，往往是训练开始前和结束后的工作，而不是训练本身。这份手册适用于任何模型、任何任务，从驾驶数据的视觉语言模型，到领域问答的小型文本模型，再到强化学习式偏好调优，硬件从单张消费级显卡到租用云服务器都跑过。

打开网易新闻 查看精彩图片

微调是整个技术栈里最贵的干预手段，所以必须放在最后。更便宜的路径依次是：改进提示词、引入检索、换更大或不同的基础模型。一个带三个优质少样本示例的系统提示，通常能补上人们想靠微调解决的一半差距，成本只要一个下午。如果问题是缺知识而不是缺行为，检索增强生成比改权重更合适，因为知识会变，微调后的模型不会跟着变。

换基础模型时要诚实对比：用零样本的大模型去比想象中微调后的小模型。作者见过未改动的开源模型，在微调模型自己的基准上反而赢了领域微调版，这种情况比排行榜显示的更常见。只有当所需行为确实不在基础模型里，也无法靠检索或提示词补上时，才轮到微调。比如输出格式合规、领域特定推理模式、必须撑过数千轮对话的人设、延迟预算逼着用小模型。

先写一句话，再决定要不要训练

动手前，用一句话写下：前面三步的哪个失败，证明了微调的必要性。写不出来就停。这句话之后还会变成评估目标，这才是写它的真正原因。

评估要先于数据集构建。这个顺序看起来反直觉，但它是整份手册里杠杆最高的决定。在收集训练数据之前，先搭一个留出集评估，用来衡量前面写下的那句话，并让基础模型跑一遍。这个数字就是基线，它有三个作用：告诉你差距的真实大小；偶尔当场杀死项目，因为基础模型其实已经够好，只是没人测过；还能验证评估框架本身，一个从没给已知模型打过分的评估，只是会吐数字的未测试代码。

评估有两条规则不能再破。第一，测试集在训练前设计好，训练中的任何东西都不能碰它，不能用来选超参数，不能用来挑检查点，一次都不行。这些事用验证集做。如果切分之间共享源文档、场景或会话，你测的是记忆，却把它叫泛化。第二，跑一个健全性对照：删掉输入再测一次。如果视觉模型去掉图像后得分仍远高于随机，说明基准通过先验泄露了答案。

数据质量比数量更关键

训练数据要围绕那句评估目标来收集，而不是先攒一堆数据再想评估。每条样本都要能对应到目标行为上，否则就是噪声。作者反复犯过的错，是花大量时间清洗数据格式，却忽略了数据本身是否在教模型做对的事。

微调不是把知识灌进模型，而是改变行为。如果目标是让模型学会某种输出格式，数据里就必须有大量格式正确的示例；如果目标是领域推理，数据里就要有推理过程，而不是只有最终答案。数据来源要尽量贴近真实使用场景，合成数据可以用，但必须经过人工抽检，否则模型会学会合成数据的毛病。

训练过程中的检查点选择，同样不能看测试集。用验证集挑最好的检查点，然后只在最后用测试集跑一次。多次偷看测试集，等于把测试集变成了训练集的一部分。

训练结束后还要做三件事

训练跑完不是终点。第一件事是回到那句评估目标，看微调后的模型在留出集上到底提升了多少，和基线比，而不是和训练损失比。第二件事是上线前做人工评测，尤其是生成类任务，自动指标常常骗人。第三件事是记录失败案例，这些案例会变成下一轮数据收集的起点。

作者强调，这套流程的价值在于顺序：先证明微调必要，再建评估，再收数据，最后训练。顺序错了，项目大概率会在某个环节返工。手册刻意保持通用，因为无论什么模型、什么任务，这套顺序都能用。