语言模型微调实战（07）：评估与失败分析
评估的意义不是得到一个「好看的百分比」，而是得到可执行的改进清单。这一篇用抽象案例说明分析方法——不引用真实训练/验证样本原文。
先选对指标
| 任务类型 | 更合适的指标 | 不太合适的指标 |
|---|---|---|
| 结构化输出（JSON / 固定模板） | 可解析率、字段完全匹配、枚举合法性 | 纯字符相似度 |
| 开放文本 | 人工抽检、语义相似度、关键信息覆盖 | 字符串完全匹配 |
同一条验证集里若混有两类任务，应分别统计，否则开放文本会把总分拉得很「难看」，掩盖结构化任务其实已经不错的事实。
评估脚本建议具备的能力
- 加载合并模型（或基座 + 适配器）；
- 按统一采样参数推理（结构化任务建议低温度，甚至 0）；
- 分别计算：
- 结构化：解析成功？字段是否等于期望？
- 开放文本：可先只做抽检，避免被严格字符串匹配误导；
- 导出明细 JSON，便于离线归因（明细同样不要外发）。
失败归因的常见桶
把结构化任务的错误先归类，而不是逐条「感觉不对」：
1. 划分导致的「未见过说法」
验证集按输入互斥划分后，模型必须靠泛化。若训练集里同类标签的说法覆盖不足，验证集上的近义表达就容易错。
对策：补同义改写与对比样本；不是简单把验证句抄进训练集（那会让指标失真）。
2. 近义标签混淆
例如两个动作在自然语言里很像，但 schema 不同。模型会「猜错边」。
对策：在 system 提示与训练样本中显式消歧；构造成对对比样本。
3. 标签/别名不一致
训练数据写 a，提示词写 a-b，模型输出第三种拼写。评估时全算错。
对策：统一枚举表；推理侧做归一化。
4. 采样噪声
温度偏高时，即便学得还行，JSON 也会抖。
对策：结构化推理用低温度；评估与线上一致。
5. 任务边界误判
本该输出 JSON，却输出闲聊；或相反。
对策：加强「何时必须结构化」的监督；推理侧可对「疑似动作意图」做兜底。
分析流程（可复用）
1 | 跑评估 → 只筛结构化失败子集 |
小结
评估的意义不是得到一个「好看的百分比」，而是得到可执行的改进清单。
语言模型微调实战第 07 篇完。下一篇把「数据消歧 + schema 后处理」组合成更稳的上线方案。
本博客所有文章除特别声明外，均采用 CC BY-NC-SA 4.0 许可协议。转载请注明来源 WALL-E's Blog！
相关推荐
2026-08-02
语言模型微调实战（01）：为什么要微调与路线图
通用 Instruct 模型已经很会对话，但接到垂直任务时常常「不够稳」。这一篇先不写命令，而是把「为什么要微调、目标是什么、整条路线怎么走」讲清楚。 基座模型哪里不够？通用 Instruct 模型接到垂直任务时，常见短板是： 行为约束不够稳：角色、口吻、拒答边界容易漂移。 结构化输出不可靠：下游系统需要固定 schema（例如 JSON），模型却经常用自然语言「解释一遍」。 微调的目标，通常就是两件事同时推进： 让模型更贴合任务人设与领域表达； 让模型在「需要结构化输出」时，稳定产出可解析结果。 推荐路线图1234567891011定义任务与输出 schema ↓构造监督数据（Alpaca JSONL） ↓互斥划分 train / val ↓LLaMA-Factory：SFT + LoRA ↓合并适配器 → 完整模型 ↓离线评估 +（可选）推理侧校验 为什么起步用 LoRA，而不是全量微调？因为对中小规模监督数据，LoRA 通常已经够用：显存更省、迭代更快、产物更小。全量微调可以作为后续对比实验...
2026-08-04
语言模型微调实战（03）：Docker 里跑 LLaMA-Factory
微调的依赖链很长（CUDA、PyTorch、transformers、LLaMA-Factory），容器化能让「昨天能训、今天也能训」。这一篇讲怎么用 Docker 把环境固化下来，并在进容器后先做自检。 你需要什么 类别 建议 系统 Ubuntu（或其他 Linux） GPU NVIDIA GPU，建议 16GB+ 显存（LoRA 微调 3B 量级通常够用） 软件 Docker + NVIDIA Container Toolkit 磁盘 预留足够空间给基础镜像、基座模型与训练输出 具体型号、云厂商、镜像源不必写进文章；按你机器上的实际环境配置即可。 为什么用 Docker 宿主机干净，依赖锁在镜像里； 换机器时更容易复现； 代码与数据通过挂载目录注入，不必 bake 进镜像每一层。 典型目录挂载宿主机项目目录挂到容器内，职责大致如下： 宿主机 容器内 用途 models/ /app/models/ 基座模型（常只读） train_data/ /app/train_data/ 训练/验证数据 output/ /app/...
2026-08-07
语言模型微调实战（06）：看日志与选轮数
核心原则一句话：选验证集上更好的 checkpoint，而不是 train loss 最低的那一步。 这一篇讲怎么读日志、怎么看曲线、怎么把「几轮最好」从拍脑袋变成可复现实验。 核心原则Train loss 持续下降，只说明模型更「贴」训练集；eval loss 若开始回升，往往意味着过拟合。 读哪些文件训练输出目录里常见： 文件 用途 trainer_log.jsonl / trainer_state.json 逐步 loss、eval_loss、best checkpoint training_loss.png 训练损失曲线 training_eval_loss.png 验证损失曲线（若开启评估） train_results.json / eval_results.json 汇总指标 trainer_state.json 里通常能看到 best_model_checkpoint 与 best_metric。若开启了 load_best_model_at_end，最终导出的适配器应对齐该最优步。 曲线怎么读（定性）健康形态通常...
2026-08-01
语言模型微调实战（00）：系列导读
用 LLaMA-Factory 对 Qwen2.5-3B-Instruct 做一次 LoRA 监督微调（SFT），把「跑通流程 → 看懂评估 → 提升泛化」完整走一遍。这不是官方 README 的摘抄，而是一次可复现实验的方法论复盘。 这个系列讲什么 为什么要微调，而不是直接用基座模型？ SFT 和 LoRA 分别指什么？ 环境怎么搭、配置怎么写？ 训练日志怎么读、轮数怎么选？ 评估指标怎么选、失败案例怎么归因？ 如何用「数据增强 + 推理侧约束」提升结构化输出的可靠性？ 文中示例均为虚构示意，不引用真实业务语料，也不公开任何训练/验证样本。 技术栈（脱敏后） 项目 选型 基座模型 Qwen2.5-3B-Instruct 微调框架 LLaMA-Factory 训练阶段 SFT（监督微调） 训练方法 LoRA 运行环境 Ubuntu + NVIDIA GPU + Docker 数据格式 Alpaca 风格 JSONL（示意） 阅读路线 序号 主题 00 本篇：系列导读 01 为什么要微调，以及整体路线图 02 SF...
2026-08-03
语言模型微调实战（02）：SFT 与 LoRA，别把两个概念搞混
常见误区：「我这份数据到底叫 SFT 还是 LoRA？」正确理解是——数据属于 SFT（监督微调）数据，LoRA 是训练方法。这一篇把两个不在同一层的概念彻底分清。 两个词不在同一层 术语 指什么 配置里常见字段 SFT 训练任务：用「输入 → 标准答案」监督模型 stage: sft LoRA 参数高效微调：冻结基座，只训低秩适配器 finetuning_type: lora 所以规范的说法是：用 SFT 数据，做 LoRA 微调。 同一套数据，可以换多种训法 方法 含义 显存压力 备注 LoRA 只训适配器 低 本系列默认 Full 更新全部参数 高 适合更大盘数据或冲上限 QLoRA 量化基座 + LoRA 更低 显存紧张时 换方法时，数据集通常不用重做；主要改配置中的微调类型，以及学习率、batch 等超参。 配置对应关系（示意）1234567stage: sftdo_train: truefinetuning_type: loralora_rank: 8lora_alpha: 16lora_target: all 训练完成后...
2026-08-06
语言模型微调实战（05）：从配置到合并模型
环境和数据就绪，这一篇跑通第一次训练：LoRA SFT → 合并适配器 → 离线评估。「第一次训练」追求的是闭环，不是刷榜。 主流程三步在容器内依次执行（路径按你的挂载调整）： 12345678# 1) LoRA SFTllamafactory-cli train /app/configs/train_xxx_lora.yaml# 2) 合并适配器llamafactory-cli export /app/configs/merge_lora.yaml# 3) 离线评估（脚本名以仓库为准）python3 scripts/test_model.py --model_path /app/output/xxx-merged 训练配置里最值得盯的字段任务与方法12stage: sftfinetuning_type: lora LoRA1234lora_rank: 8lora_alpha: 16lora_dropout: 0lora_target: all 数据与模板1234dataset_dir: /app/LLaMA-Factory/datadataset: <your_...
