WALL-E's Blog

微调并不神秘：把任务定义清楚，把数据划干净，把训练跑稳定，再用评估驱动下一轮改进。这一篇收束到部署产物、上线检查清单与复盘要点。 你最终该交付什么 产物 说明 LoRA 适配器目录 体积小，需搭配同版本基座加载 合并后的完整模型目录 可独立部署，适合多数推理服务 推理入口 建议默认走 schema 校验；评估脚本可对比「原始 vs 后处理」 合并模型与适配器的关系可以记成： 1基座模型 + LoRA 适配器 --export--> 合并后的完整模型 线上一般加载合并后的完整模型；若要快速试验多个适配器，也可以基座 + 适配器热插拔。 最小上线检查清单 训练配置与评估脚本使用同一套 tokenizer / template 验证集与训练集互斥（流程可审计） 结构化任务用低温度推理 枚举表、训练标签、后处理规则三者一致 有回滚方案（保留上一版 merged 目录） 日志中可区分「模型原始输出」与「后处理输出」（便于排障） 复盘：这套流程真正学到的点 SFT 描述任务，LoRA 描述怎么训——术语别混用。 数据划分错误会制造...

目标：让结构化输出在未见过的说法上更稳。泛化不是玄学，是「覆盖 + 消歧 + 约束」的工程问题。文中规则与样例均为示意，不对应真实业务语料。 为什么「只靠再训几轮」往往不够轮数增加主要加强记忆与收敛；对「近义混淆 / 覆盖不足 / 格式漂移」帮助有限。更有效的组合通常是： 123模型能力（SFT + LoRA） + 消歧数据与统一 schema + 推理侧校验 / 修复 把 100% 理解成「生产链路对结构化请求的可靠交付」，而不是「裸模型在任意开放域永远完美」。 第一层：统一 schema 与提示 维护一份合法枚举表（类别 → 允许取值）； system 提示与数据标签使用同一套拼写； 对易混对写清规则（抽象示意）： 123标签 A ≠ 标签 B：- 表达族 X → A- 表达族 Y → B 第二层：消歧与对比样本（仍保留互斥验证）为易混标签构造成对样本：相近说法映射到正确且不同的结构化结果。注意：补充的是新说法，不要直接污染验证集原句，否则「泛化」再次变成「背题」。 第三层：推理侧后处理推荐流水线： 123456用户输入 → 模型生...

评估的意义不是得到一个「好看的百分比」，而是得到可执行的改进清单。这一篇用抽象案例说明分析方法——不引用真实训练/验证样本原文。 先选对指标 任务类型 更合适的指标 不太合适的指标 结构化输出（JSON / 固定模板） 可解析率、字段完全匹配、枚举合法性 纯字符相似度 开放文本 人工抽检、语义相似度、关键信息覆盖 字符串完全匹配 同一条验证集里若混有两类任务，应分别统计，否则开放文本会把总分拉得很「难看」，掩盖结构化任务其实已经不错的事实。 评估脚本建议具备的能力 加载合并模型（或基座 + 适配器）； 按统一采样参数推理（结构化任务建议低温度，甚至 0）； 分别计算： 结构化：解析成功？字段是否等于期望？ 开放文本：可先只做抽检，避免被严格字符串匹配误导； 导出明细 JSON，便于离线归因（明细同样不要外发）。 失败归因的常见桶把结构化任务的错误先归类，而不是逐条「感觉不对」： 1. 划分导致的「未见过说法」验证集按输入互斥划分后，模型必须靠泛化。若训练集里同类标签的说法覆盖不足，验证集上的近义表达就容易错。 对策：补同义改写与对比...

核心原则一句话：选验证集上更好的 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，最终导出的适配器应对齐该最优步。 曲线怎么读（定性）健康形态通常...

环境和数据就绪，这一篇跑通第一次训练：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_...

对 SFT 来说，数据几乎就是上限：格式乱，模型学不到稳定模式；划分泄漏，验证分数虚高。这一篇只讲方法与原则——不展示、不摘录任何真实训练/验证样本。 数据在微调里的位置 格式乱 → 模型学不到稳定模式； 划分泄漏 → 验证分数虚高； 类别不均衡 → 某类任务永远学不好。 推荐格式：Alpaca 风格 JSONL每行一条 JSON，字段示意如下（内容为虚构占位）： 123456{ "instruction": "<用户输入>", "input": "", "output": "<期望输出>", "system": "<系统提示，可选>"} 字段 作用 instruction 用户侧主输入 input 补充上下文（可空） output 监督目标 system 全局角色与规则（可全库共用） 在 LLaMA-Factor...

微调的依赖链很长（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/...

常见误区：「我这份数据到底叫 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 训练完成后...

通用 Instruct 模型已经很会对话，但接到垂直任务时常常「不够稳」。这一篇先不写命令，而是把「为什么要微调、目标是什么、整条路线怎么走」讲清楚。 基座模型哪里不够？通用 Instruct 模型接到垂直任务时，常见短板是： 行为约束不够稳：角色、口吻、拒答边界容易漂移。 结构化输出不可靠：下游系统需要固定 schema（例如 JSON），模型却经常用自然语言「解释一遍」。 微调的目标，通常就是两件事同时推进： 让模型更贴合任务人设与领域表达； 让模型在「需要结构化输出」时，稳定产出可解析结果。 推荐路线图1234567891011定义任务与输出 schema ↓构造监督数据（Alpaca JSONL） ↓互斥划分 train / val ↓LLaMA-Factory：SFT + LoRA ↓合并适配器 → 完整模型 ↓离线评估 +（可选）推理侧校验 为什么起步用 LoRA，而不是全量微调？因为对中小规模监督数据，LoRA 通常已经够用：显存更省、迭代更快、产物更小。全量微调可以作为后续对比实验...

用 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...