微调并不神秘：把任务定义清楚，把数据划干净，把训练跑稳定，再用评估驱动下一轮改进。这一篇收束到部署产物、上线检查清单与复盘要点。

你最终该交付什么

产物 说明
LoRA 适配器目录 体积小，需搭配同版本基座加载
合并后的完整模型目录 可独立部署，适合多数推理服务
推理入口 建议默认走 schema 校验；评估脚本可对比「原始 vs 后处理」

合并模型与适配器的关系可以记成：

1
基座模型 + LoRA 适配器  --export-->  合并后的完整模型

线上一般加载合并后的完整模型；若要快速试验多个适配器，也可以基座 + 适配器热插拔。

最小上线检查清单

  • 训练配置与评估脚本使用同一套 tokenizer / template
  • 验证集与训练集互斥（流程可审计）
  • 结构化任务用低温度推理
  • 枚举表、训练标签、后处理规则三者一致
  • 有回滚方案（保留上一版 merged 目录）
  • 日志中可区分「模型原始输出」与「后处理输出」（便于排障）

复盘：这套流程真正学到的点

  1. SFT 描述任务，LoRA 描述怎么训——术语别混用。
  2. 数据划分错误会制造虚假胜利——互斥比比例更重要。
  3. 指标要分任务——结构化看字段，开放文本别迷信全匹配。
  4. 上线质量 = 模型 + 约束——后处理不是作弊，是工程标配。
  5. 迭代应可复现——配置、脚本、checkpoint 对比要留痕。

可以继续探索的方向（仍保持脱敏）

  • 对比 LoRA / QLoRA / Full 在同一私有数据上的曲线；
  • 引入更合理的开放文本评估（语义相似度、LLM-as-judge，注意偏差）；
  • 多轮对话与工具调用格式；
  • 量化部署与吞吐优化；
  • 视觉-语言等多模态扩展（另开系列）。

敏感信息提醒

对外分享本系列或仓库说明时，请继续避免：

  • 具体业务品牌、场地、客户名；
  • 具体硬件型号（如无必要可写「消费级 / 数据中心 GPU」等级）；
  • 任何真实训练/验证样本、日志中的用户原话、评估明细里的原文。

操作手册可以留在私有 docs/；对外博客保持方法级叙述即可。

结束语

微调并不神秘：把任务定义清楚，把数据划干净，把训练跑稳定，再用评估驱动下一轮改进。希望这组文章帮你建立可复用的方法论，而不是一套绑死在某个业务上的「神秘配置」。