LoRA 微调（参数高效）
使用场景: 在单张 GPU 上微调的开发者
基座模型冻结；只训练小的适配器权重
数据集：几千条任务特定样本
训练可在一张消费级或云 GPU 上完成
输出：小的 LoRA 适配器，而非完整模型副本
部署：服务时加载基座模型 + 适配器
这样组织的原因: LoRA 是最易上手的微调方法——图表展示基座模型冻结、只训练适配器，这正是它能在普通硬件上运行、并产出小而可替换的适配器（而非完整模型）的原因。
真实案例
全量监督微调（SFT）
使用场景: 有预算更新全部模型权重的团队
训练期间更新所有模型参数
需要多 GPU 和更大的精选数据集
按间隔把检查点保存到仓库
更重的评估：对基座能力做回归测试
输出：完整的微调模型工件
这样组织的原因: 全量 SFT 更新每个权重——图表增加检查点和回归评估，因为改变所有参数有损害基座模型通用能力的风险，必须在部署前衡量。
偏好微调（RLHF / DPO）
使用场景: 把模型对齐到人类偏好的团队
阶段 1：在示范数据上做 SFT
阶段 2：收集偏好对（被选 vs 被拒）
阶段 3：DPO 或 RLHF 针对偏好优化
奖励模型（RLHF）或直接优化（DPO）
评估：相对 SFT 基线的胜率
这样组织的原因: 偏好微调在 SFT 之后增加第二个训练阶段——图表展示偏好数据和奖励信号，因为对齐到人类偏好与模仿示范是不同的目标。
持续微调
使用场景: 随新数据到来而重训的团队
生产反馈回流进数据集
在不断增长的数据集上定时重训
每次运行都对线上模型评估
冠军-挑战者：新模型必须胜过当前
评估回退时自动回滚
这样组织的原因: 持续微调闭合了从生产回到训练的循环——图表增加反馈路径和冠军-挑战者关卡，于是新模型只有在可衡量地胜出时才替换线上模型。
使用技巧
- 把基座模型作为独立输入画进训练阶段——微调适配的是已有模型，不是从零训练。
- 把评估关卡画出明确的「不达标回训练」路径；总是部署的流水线根本没真正评估。
- 区分数据集准备与预处理——数据收集 / 清洗和分词是不同阶段，失败模式也不同。
- 把模型仓库放在训练和服务之间，让部署可版本化、可回滚。
在线开始编辑
回到模板页，直接替换成你的课程主题、章节和复习重点，就可以继续使用这套结构。
使用这个模板： /editor/new?template=llm-fine-tuning-pipeline
编辑此微调流程图模板