面经策

如何判断微调效果是否达到预期？ ​

  • 标签：大模型、AI、微调、评估指标

🏛 业务架构师 ​

评估微调效果我坚持"三层漏斗"，每一层对应不同的业务决策：

1. 自动化基准（回归测试）：在领域评测集上对比微调前后——分类任务看准确率/F1，生成任务看 BLEU/ROUGE 这类参考指标，更重要的是用 LLM-as-Judge 评"与标准答案的语义吻合度"。这一层决定"有没有变好"，是继续迭代的门禁。

2. 业务化人工评估：业务专家盲评微调版 vs 原版（A/B 侧盲对比），关注格式遵从率、术语准确率、话术合规性。这层决定"业务认不认"——很多自动指标漂亮但业务方不买账的案例，都缺了这层。

3. 线上 A/B 验证：小流量灰度，看真实业务指标——客服场景看解决率、转人工率；分类场景看人工纠正率。这层决定"值不值得上线"，也是向管理层证明 ROI 的最终依据。

必须同时盯住的负面指标：灾难性遗忘（通用能力是否退化，用通用 Benchmark 抽测）、过拟合（训练集分数高、测试集不涨）。微调最常见的失败不是"没效果"，而是"领域涨了、通用废了"。

我的原则：没有评测集不启动微调项目——先花一周建 200 条以上的黄金评测集，再谈训练，否则连"效果好坏"都无法客观回答。

🏗 系统架构师 ​

判断微调是否达标，我坚持三层评估，只看 loss 是最常见的错误：

第一层：训练健康度（过程指标）。training loss 平稳下降、eval loss 不回升——eval loss 回升 = 过拟合信号；梯度范数无爆炸。这只说明"训了"，不代表"训好了"。

第二层：任务效果（离线评测）：

  • 建独立测试集（训练集绝不能当测试集），覆盖真实分布；
  • 客观任务看准确率/F1/EM（分类、抽取）；生成任务用 LLM-as-Judge 评质量维度 + 关键字段结构化校验（格式合规率）；
  • 必须和对照组比：同任务下 zero-shot、few-shot、RAG 方案的基线——微调版要比 few-shot 提升明显（如准确率 +10 个点以上）才值得付出微调的维护成本，否则 few-shot 就够了。

第三层：回归与业务指标（上线判据）：

  • 通用能力回归：跑通用 benchmark 抽查，确认没有灾难性遗忘（微调后连基本指令都不会跟了是真实事故）；
  • 灰度 A/B：线上解决率、用户采纳率、人工接管率、单次推理成本。

工程纪律：评估集与训练数据同版本管理，每次模型迭代跑同一套回归；建立"微调模型卡"记录底座、数据、超参、评测结果——没有可复现的评估，微调就是一次性赌博。

💻 全栈开发专家 ​

我判断微调效果用「三道关」：

第一关：训练过程指标（离线，每天看）

  • train loss / eval loss 曲线：两者分叉（train 降 eval 升）= 过拟合，回头加正则或减 epoch；
  • eval loss 连续若干 step 不降 = 到达容量或 lr 不合适。
  • 经验：SFT 一般 1~3 个 epoch 就到顶，第 4 个 epoch 还在「提升」多半在背训练集。

第二关：任务指标（决定性）

  • 有标准答案的任务（分类/抽取）：accuracy/F1，直接脚本跑；
  • 生成任务：自动指标（BLEU/ROUGE 只做参考）+ LLM-as-Judge 盲评（与基线模型成对比较，交换位置跑两次防位置偏差）+ 抽 10% 人工校准；
  • 格式类需求：结构化输出解析成功率（我们卡 99%+）。

第三关：上线前后对照（最终裁决）

  • 灰度 A/B：任务完成率、人工接管率、用户负反馈率；
  • 回归测试：拿 200 条通用能力集测「有没有变笨」（灾难性遗忘的哨兵）；
  • 成本延迟：小模型微调后能否真省钱。

最实在的一条：微调前先记录 baseline（zero-shot/few-shot/RAG 各一组），微调的价值 = 相对 baseline 的净增量。没有 baseline 对照的「效果不错」都是自嗨，这是我带团队立的规矩。