先说结论：多数团队的微调失败，不是因为超参没调好，而是在动手之前就没想清楚"这件事该不该用微调来解决"。LoRA 成本低、门槛低，恰恰让人容易跳过判断直接开训，最后拿到一个 loss 很漂亮、上线却不敢用的权重。

一、先判断：这件事该不该微调

微调改变的是模型的行为分布——输出风格、字段格式、领域术语的叫法、拒答的边界；它并不擅长往模型里注入事实知识。要模型知道"我们公司今年的退货政策怎么算"，正确做法是检索增强；要模型稳定输出符合内部规范的 JSON、按你们的话术回复客户，微调才划算。三个自查问题可以用：这个任务用提示词加少量示例，能不能达到八成效果？错误主要来自"不知道"还是"不照做"？前者走检索，后者才走微调。最后一个问题更现实——一个任务攒不出三五百条高质量样本，就先别开训，先把标注流程跑起来。

二、数据比超参重要一个数量级

参数高效微调对数据质量极其敏感：五百条"指令—理想输出"配对的干净样本，通常胜过几万条从日志里直接扒下来的脏数据。可执行的做法是从线上真实请求里采样，让人工把模型当时的输出改写成"你希望它给出的样子"，而不是另起炉灶造题——分布不一致是微调后线上效果打折的首要原因。三条硬要求：答案唯一可核验，有客观对错，不含"看情况"；输入必须完整复现线上上下文，包括 system prompt、工具定义和少样本示例；训练集与验证集按来源去重，同一份文档切出来的问答不能跨集，否则验证指标会虚高。还有一条最容易踩：chat template 必须与基座完全一致，模板错位会让效果直接归零。

三、LoRA 参数：从保守值起步，别一次调十个

工程上比较稳的起点是 rank 取 8 到 16、alpha 取 rank 的两倍、学习率 1e-4 到 2e-4（比全参微调高一个量级）、epoch 2 到 3。target_modules 不要只挂 q_proj、v_proj，把 k_proj、o_proj 和 MLP 层的 gate/up/down 一起打开，表达能力差别很明显，显存代价却可控。序列长度按业务真实长度的 P95 设 cutoff_len，按最长样本设，等于把显存浪费在极少数长尾上。训练时盯验证集而不是训练 loss：loss 一路降而验证集不涨，基本就是过拟合或者在背答案。想再省一点，可以先在 1% 数据上跑通全流程，确认数据管线和评估脚本没问题，再上全量——大部分返工都发生在管线而不是模型本身。

四、验收：拿五十条业务题卡住它

微调最容易被忽略的一步是"验"。建议固定一份五十到一百条的业务验收集，人工标注期望结果，同时跑基座和微调版逐条比对，只看 loss 曲线等于没验。还要做两件事：一是通用能力回归，问二十个与业务无关的常识和指令跟随问题，确认没有灾难性遗忘；二是想清楚上线形态，挂 adapter 便于多租户和多版本热切换，合并权重则吞吐更好、部署更简单，按并发量和版本迭代频率来定，别默认合并。

写在最后

微调不是能力升级的捷径，它更像一把手术刀：把基座已有的能力收窄、校准到你的具体场景。判断清楚该不该做、把数据做干净、参数从保守值起步、用业务题验收——这四步走完，LoRA 才是低成本高确定性的工具，而不是又一个躺在仓库里不敢上线的权重。

——文/吴佳文，广东省人工智能与机器人学会副秘书长，长期关注AI产业落地与人工智能人才培养。