LLamaFactory 微调实战

LLamaFactory 微调实战

仓库地址

https://github.com/hiyouga/LlamaFactory?tab=readme-ov-file

本次任务是训练llm 抽取query中的实体

微调种类

llamafactory 目前是支持这些种类的微调

  • 列(Full / Freeze / LoRA / QLoRA / OFT / QOFT):讲的是“怎么更新参数”(参数高效微调 PEFT vs 全量微调)。
  • 行(SFT / Reward Modeling / PPO / DPO / KTO / ORPO / SimPO):讲的是“用什么训练目标/数据形式”(监督、偏好、RL 等)。

怎么更新参数

1) Full-tuning(全量微调)

做法:模型所有参数都更新。
优点

  • 表达能力最强,理论上效果上限最高(尤其是你要强改模型行为/风格/能力时)。
  • 训练/推理代码最简单(不用插 LoRA 模块)。
    缺点
  • 显存、训练成本最高;多卡/ZeRO/FSDP 常见。
  • 容易“灾难性遗忘”,也更容易把模型训歪(数据不够干净时)。
    什么时候用:数据量大、预算足、你想做“真正的模型版本迭代”。

2) Freeze-tuning(冻结主干,只训少量模块)

做法:大部分参数冻结,只训练很少一部分(常见:最后几层、LayerNorm、Adapter、小 head)。
优点

  • 成本低、稳定、不太容易把模型训崩。
    缺点
  • 可塑性有限,效果上限通常不如 LoRA/全量。
    什么时候用:快速适配、资源很紧、或者你只想“轻微对齐/轻微迁移”。

3) LoRA(最常用的 PEFT)

做法:冻结原权重,在注意力/MLP 的线性层旁边加一对低秩矩阵 A,B,只训练这部分“增量”。
优点

  • 性价比极高:显存大幅下降,效果通常接近全量微调(尤其做 SFT / DPO 这类)。
  • 可以为同一个基座模型保存多套 LoRA(切换任务很方便)。
    缺点
  • 仍然需要基座模型以 FP16/BF16 方式加载训练(比 QLoRA 贵)。
    什么时候用:几乎所有“常规微调”默认首选(SFT、DPO、ORPO、SimPO…都很常见)。

4) QLoRA(LoRA + 4bit 量化训练:超省显存)

做法:基座权重量化到 4bit(常见 NF4),仍然只训练 LoRA 参数;计算中用一些技巧保证训练稳定。
优点

  • 显存最省:单卡也能训更大的模型(比如 13B/34B 更现实)。
    缺点
  • 训练更“工程化”:依赖 bitsandbytes / 量化算子,速度可能慢一点,偶尔有数值/兼容坑。
  • 极端情况下效果可能比 LoRA 略差一点点,但很多任务差距不大。
    什么时候用:你想在有限 GPU 上把模型尺寸顶上去——现在非常非常常用

用什么训练目标/数据形式

1) SFT(Supervised Fine-Tuning)

数据:(prompt,response)(prompt, response)(prompt,response) 的标准监督数据(指令-答案)。
在干嘛:最大化参考答案的似然(cross-entropy)。
优点:最简单、最稳、最常用的第一步;能快速让模型“会按指令说话”。
缺点:只能学到“数据里长什么样”,不直接优化偏好/安全/有用性;数据质量决定上限。

一句话:把模型训练成“像数据集里的优秀助教”。


2) Reward Modeling(RM,奖励模型/偏好模型)

数据:偏好对比(同一 prompt 下 A vs B,标哪个更好),或打分数据。
在干嘛:训练一个 r(x,y)去预测“人类更喜欢哪个回答”。
用途:RM 本身不是最终模型,而是给后面的 RL(比如 PPO)提供 reward。
优点:把“人类偏好”变成可优化的标量信号。
缺点:训练/维护一个额外模型;reward 容易被“钻空子”(reward hacking)。

一句话:先学会“怎么评卷”,再用它指导学生练习。


3) PPO Training(经典 RLHF 的 RL 阶段)

数据:prompt(模型自己采样回答),再用 RM 给 reward。
在干嘛:用 PPO 最大化 reward,同时用 KL 约束别偏离原模型太多(稳定训练)。
优点:能直接优化“偏好得分”;在一些场景能带来明显提升。
缺点成本最高、最难调(采样+RL 不稳定);对实现细节很敏感。

一句话:真正“用奖励做强化学习”,但工程最重。

4) DPO/KTO/ORPO/SimPO 偏好优化

DPO(Direct Preference Optimization)— 现在超常用

数据:偏好对 (x,y+,y−)(同一 prompt 下更好/更差)。
在干嘛不训练 RM、不跑 PPO,直接用一个“对比式”的目标让模型更偏向 y+而不是 y−。
优点:实现简单、训练稳定、效果强;很多团队用它替代 PPO。
缺点:仍然依赖高质量偏好数据;对“偏好覆盖面”敏感。

一句话:用“更像好答案、远离差答案”的概率比,直接把模型拉过去。

KTO(偏好优化的另一种口味)

数据:可以用偏好对,也常见“单条回答 + 好/坏标签”(不一定要成对)。
在干嘛:用更简单的方式把“好/坏反馈”变成优化信号(比 DPO 在某些数据形态上更灵活)。
优点:当你只有“这条好/这条不好”的反馈时更方便。
缺点:生态和默认程度不如 DPO;不同实现细节差异较大。

一句话:不强依赖成对比较的偏好优化方案。

ORPO / SimPO(更“轻量”的偏好优化变体)

它们可以理解为:把 SFT 和偏好项合在一个目标里(或者让偏好目标更简洁/更好训)。
优点:训练更省事、更稳,很多时候能拿到接近 DPO 的收益。
缺点:不同论文/实现差异大;不一定在所有任务上都稳赢 DPO。

一句话:更像“带偏好项的 SFT++”。

环境配置

我走的环境是docker

hiyouga/llamafactory:latest

 注意这个docker 拉下来自带llamafactory代码,不过因为权重放本地了所以我还是挂载本地目录了

/workspace/code/LlamaFactory

数据处理

具体看 readme_zh.md 

总之自定义数据记得往 dataset_info 里面塞个

训练参数

lora

--lora_rank

rank (r) 是 LoRA 低秩矩阵的秩,决定 LoRA 的“容量”。

  • LoRA 把一个线性层的权重更新写成:ΔW=BA
    其中 A∈Rr×d, B∈Rd′×r
  • r 越大 → 可学习参数更多 → 更能拟合你的任务,但更占显存、也更容易过拟合。

经验:

  • 轻任务/小数据:r=4/8
  • 多一点规则/结构化输出:r=16 常用
  • 很难的迁移/很大数据:r=32/64 才可能有意义

--lora_alpha 

alpha 是 LoRA 的缩放系数,控制 LoRA 更新幅度。

常见实现里会用一个缩放:

  • alpha 大 → LoRA 更新更“猛”
  • alpha 小 → 更新更“温和”

经验:

  • 经典搭配:alpha = 2*r(比如 r=16 → alpha=32),很常见、也比较稳。
  • 如果你发现模型输出开始乱飘/格式崩:可以减小 alpha 或学习率。

--lora_target

这个决定:LoRA 插到哪些线性层上(也就是你让哪些模块“可塑形”)

注意力层(Attention)

q_proj, k_proj, v_proj:把 hidden 投影成 Q/K/V

o_proj:注意力输出再投影回去

这些层决定模型“怎么注意、注意谁”,对改行为很有效。

前馈层(MLP / FFN)

gate_proj, up_proj, down_proj:对应 LLaMA/Qwen 这类常见的 gated-MLP 结构
MLP 是模型的“计算/表达”主力,占参数也多,给它上 LoRA 通常会更有力。

为什么不建议 lora_target all

all 会把一堆不关键的层也插 LoRA,慢、占用多、还可能不稳

常见默认就是只打在 attention + MLP 这些“最值钱”的线性层

调参技巧

想更准 / 规则更复杂:先加 rank(8 → 16),再看是否要加 alpha

输出格式容易崩:降低 learning_rate 或降低 alpha/r(比如 alpha=16 或 lr 从 5e-5 降到 2e-5)

过拟合(train 好、dev 差):加 dropout(0.05 → 0.1)或减 rank

evaluation

因为数据比较结构化,所以我就拿acc 来计算的

--do_eval \  # evaluation= True

--eval_strategy steps \ #拿步为单位,否则epoch

--eval_steps 20 \ 

--compute_accuracy true \   #是否计算acc

--val_size 0.1 \  #数据集划分

Read more

Microi吾码:从零到服装ERP:低代码打造企业级系统的实战之旅

Microi吾码:从零到服装ERP:低代码打造企业级系统的实战之旅

个人主页:chian-ocean 文章专栏 从零到服装ERP:吾码平台打造企业级系统的实战之旅 关键词:吾码平台、低代码、服装ERP、多表关系、自动化、开发实例 引言 在传统的服装行业管理中,ERP系统已成为提高效率、降低成本、优化资源分配的核心工具。然而,开发一个功能全面、覆盖采购、库存、销售、财务等模块的ERP系统,往往需要投入大量时间和人力资源。在吾码低代码平台的支持下,1人仅用1个月便完成了包含100+表的企业级服装ERP系统。本文将从项目概述、开发细节到关键代码段详细剖析整个开发过程,展示低代码技术的强大能力。 第一部分:项目概览 1.1 项目背景 * 项目需求: * 支持采购、库存、销售、客户管理、财务报表等多个模块。 * 包括100+数据表,涵盖复杂的业务逻辑与数据关联。 * 需实现流程自动化(如采购审批、库存提醒)。 * 开发目标: * 快速完成开发,并保证系统稳定性与扩展性。

龙虾机器人(OpenClaw)本地部署完全技术指南

龙虾机器人(OpenClaw)本地部署完全技术指南

龙虾机器人(OpenClaw)本地部署完全技术指南 前言:什么是“龙虾机器人”? 在开始部署之前,我们需要明确部署的对象。通常所说的“龙虾机器人”指的是开源项目 OpenClaw(曾用名:Clawdbot、Moltbot)。它由程序员彼得·斯坦伯格开发,是一个开源的、可本地部署的通用型AI代理系统。与ChatGPT等对话式AI不同,OpenClaw被赋予了操作系统的权限:它可以执行终端命令、读写文件、操控浏览器、安装软件,甚至通过MCP协议调用外部工具。 由于其强大的系统操控能力,安全性是部署时需关注的首要问题。官方及社区普遍建议:不要在主力机或存有敏感数据的生产环境直接裸奔部署,最好使用虚拟机、Docker容器或专用硬件(如Mac Mini或AI开发盒子)进行隔离。 第一章:环境准备与核心依赖 在安装OpenClaw之前,必须准备好运行环境。OpenClaw的核心由TypeScript编写,因此Node.js是必不可少的运行环境。此外,根据安装方式的不同,可能还需要Git、Docker或Python环境。 1.1 硬件建议与系统选择 * Linux

HY-Motion 1.0保姆级:Windows WSL2环境下部署Gradio WebUI全流程

HY-Motion 1.0保姆级:Windows WSL2环境下部署Gradio WebUI全流程 1. 为什么选WSL2?——给3D动作生成找一个稳当的“家” 你是不是也遇到过这些问题:想跑个前沿的3D动作生成模型,但本地Windows直接装PyTorch+CUDA环境像在拆弹?Anaconda里一堆包冲突,GPU驱动版本对不上,torch.cuda.is_available()永远返回False?或者好不容易配好,一跑模型就爆显存、卡死、报错OSError: [WinError 126] 找不到指定的模块? 别折腾了。HY-Motion 1.0这类基于DiT和流匹配的大模型,对Linux环境有天然亲和力——而Windows用户最平滑、最可靠、官方长期支持的Linux方案,就是WSL2(Windows Subsystem for Linux 2)。 它不是虚拟机,不占额外内存;不是Docker容器,不用反复构建镜像;它是内核级的Linux子系统,能直通NVIDIA GPU(通过WSLg

Java Web 影城会员管理系统系统源码-SpringBoot2+Vue3+MyBatis-Plus+MySQL8.0【含文档】

Java Web 影城会员管理系统系统源码-SpringBoot2+Vue3+MyBatis-Plus+MySQL8.0【含文档】

摘要 随着数字化时代的快速发展,影院行业对会员管理的需求日益增长。传统的会员管理方式依赖人工操作,效率低下且容易出错,无法满足现代影院对会员数据分析、个性化服务和高效运营的需求。影城会员管理系统通过信息化手段,实现会员信息的集中管理、消费记录的实时跟踪以及会员权益的精准发放,从而提升影院的服务质量和运营效率。该系统能够帮助影院更好地了解会员需求,优化营销策略,增强会员粘性,为影院创造更大的商业价值。关键词:数字化、会员管理、影院行业、信息化、运营效率。 该系统基于SpringBoot2框架开发,采用前后端分离架构,前端使用Vue3实现动态交互界面,后端通过MyBatis-Plus高效操作MySQL8.0数据库。系统功能涵盖会员注册与登录、会员信息管理、消费记录查询、积分管理、优惠券发放以及数据分析报表生成。通过Spring Security实现权限控制,确保系统安全性;利用Redis缓存提升系统性能;结合Vue3的响应式特性,为用户提供流畅的操作体验。系统还支持多维度数据分析,帮助影院管理者制定科学的营销策略。关键词:SpringBoot2、Vue3、MyBatis-Plus、My