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

Jenkins X + AI:重塑云原生时代的持续交付范式

Jenkins X + AI:重塑云原生时代的持续交付范式

目录 * 引言 * 一、Jenkins X核心架构解析 * 1.1 云原生设计哲学 * 1.2 智能流水线引擎 * 二、AI赋能的智能CI/CD功能矩阵 * 2.1 智能测试选择器 * 2.2 自适应部署策略 * 2.3 预测性资源优化 * 三、智能故障诊断系统 * 3.1 根因分析引擎 * 3.2 自愈流水线 * 四、AI增强的安全扫描 * 4.1 智能漏洞检测 * 4.2 合规性检查 * 五、未来展望:智能CI/CD平台演进 * 5.1 三层智能架构 * 5.2 颠覆性应用场景 * 六、

AI 直接解析 PDF 文档!OpenClaw 2026.3.3 新功能实测太强了

AI 直接解析 PDF 文档!OpenClaw 2026.3.3 新功能实测太强了 一、背景:PDF 处理为什么这么难? 你是否遇到过这些场景? * 下载了一份 50 页的行业报告,想快速提取核心观点,却只能手动一段段复制 * 收到了合作伙伴发来的 PDF 合同,需要逐页检查关键条款 * 学术论文动辄几十页,想定位某个特定概念要看花眼 * 工作群里的 PDF 资料越堆越多,却从来没时间整理 PDF,可能是大多数人日常工作中最"难搞"的文件格式。 它看似简单——不过是 pages + text 的组合。但正是因为"简单",反而带来了无尽的麻烦: * 文字无法直接选中复制 * 格式在不同设备上可能跑偏 * 里面的图表、图片需要额外处理 * 更别说那些扫描件了—

用约束驱动AI写好代码:OpenSpec 完全使用指南

OpenSpec 完全使用指南 用规格驱动 AI 编码 —— 让 AI 真正理解你要什么 如果你正在用 AI 写代码,却总觉得"沟通成本"比"写代码"还高——OpenSpec 可能是你一直缺的那块拼图。 目录 1. [为什么需要 OpenSpec](#一为什么需要 openspec) 2. 安装与初始化 3. 核心理念 4. 命令详解 5. 实战场景 * 场景一:需求清晰,直接开干 * 场景二:需求模糊,需要边探索边明确 * 场景三:并行开发多个功能 * [场景四:已完成未归档的 change 发现 Bug](#场景四已标记完成但未归档的

开发效率翻倍!JetBrains IDE 必备 AI 插件 Continue 安装配置指南

开发效率翻倍!JetBrains IDE 必备 AI 插件 Continue 安装配置指南

作为程序员,谁不想在写代码时少敲几行键盘、多省点时间?今天给大家推荐一款 JetBrains 系列 IDE(PyCharm、IntelliJ IDEA 等)的宝藏插件 ——Continue,它能靠 AI 帮你补代码、改逻辑、写文档,看完这篇就能上手用! 一、先搞懂:Continue 到底能帮你做什么? Continue 是专门为 JetBrains IDE 设计的 AI 辅助插件,核心是通过调用本地或云端的 AI 模型,帮开发者解决写代码时的各种 “麻烦事”,具体能实现这 5 个实用功能: * 代码快补 & 续写:比如你写了函数名,按下快捷键,AI 会根据文件上下文自动补全函数体,重复代码不用再手敲; * IDE 内直接问 AI:遇到代码报错、