03. Fine-tuning 详解

版本：v1.1
最后更新：2026-07-06
适用对象：希望理解微调决策、数据建设、SFT / DPO / RFT / LoRA / QLoRA、评测和生产上线的 AI 应用开发者。

1. 什么是 Fine-tuning

Fine-tuning 通常译为“微调”，指的是：

在已有基础模型之上，用特定任务或特定风格的数据继续训练，让模型更稳定地表现出你希望的行为。

它不是从零训练模型。基础模型已经在大规模通用语料上学到了语言、知识和推理模式，微调是在这个基础上做“定向适配”。

更直观地说：

text

Base Model
 -> General Language Ability
 -> Fine-tuning Data
 -> Customized Behavior

OpenAI 的 supervised fine-tuning 文档把 SFT 描述为用示例输入和已知优质输出训练模型，使模型更可靠地产生期望的风格和内容。这个定义抓住了微调最常见的工程价值：

不是让模型知道所有新知识。
而是让模型更稳定地按你的任务方式工作。

2. 微调到底改变什么

微调会更新模型参数，或者在参数高效微调里更新少量附加参数。

它可能改变：

输出格式
语气风格
指令遵循方式
分类边界
结构化抽取习惯
拒答边界
工具调用倾向
特定任务的解题步骤

它不适合直接承担：

高频更新的业务知识
实时数据
需要权限过滤的企业文档
必须引用来源的事实问答

这些通常更适合 RAG、数据库查询、工具调用或工作流。

3. 微调和预训练的区别

维度	预训练	微调
目标	学通用语言和知识模式	学特定任务、风格或行为
数据规模	极大	相对小，质量更重要
成本	极高	低很多，但仍需评测和迭代
训练对象	通常全模型	全量参数或少量适配参数
结果	基础模型	定制模型或适配器

预训练像打地基，微调像装修成适合某个业务的工作间。

4. 微调、Prompt、RAG、工具调用怎么选

一个常见误区是把所有模型效果问题都归到微调。

更稳的判断方式如下：

问题类型	优先方案
模型不知道最新知识	RAG / 数据库 / 工具调用
输出格式偶尔跑偏	Prompt / Structured Outputs
需要长期稳定的固定格式	SFT
公司文风不统一	SFT
分类边界稳定但难以靠提示词说清	SFT + 评测集
用户偏好主观，需要比较好坏	DPO / preference tuning
任务能用程序打分，且需要优化推理策略	RFT / RL 类方法
需要调用外部系统获取实时状态	工具调用
需要减少长提示词和 few-shot 示例	SFT 可考虑

一句话：

Prompt 解决“怎么说清任务”。
RAG 解决“知识从哪里来”。
Tool 解决“需要做什么动作或查什么实时数据”。
Fine-tuning 解决“模型长期应该怎么表现”。

5. 什么时候值得微调

满足越多，越值得考虑微调：

任务重复且稳定。
输出规范长期不变。
已经有高质量输入输出样本。
Prompt 已经优化过，但仍不稳定。
few-shot 示例很多，导致 token 成本高。
需要统一品牌语气或专业表达。
有评测集能证明微调前后差异。
错误类型可以通过训练样本表达清楚。

例如：

客服回复风格统一。
工单分类。
合同条款风险标签。
医疗文本结构化抽取。
法务初筛说明格式。
代码审查评论风格。
工具调用参数格式。

6. 什么时候不该先微调

这些情况先别急着微调：

6.1 任务定义不清

如果人都说不清什么是好答案，微调会把混乱固化进模型。

6.2 数据质量差

低质量样本会让模型学到坏习惯。

6.3 主要问题是缺知识

如果答案依赖频繁更新的产品文档、内部制度或数据库状态，优先 RAG 或工具。

6.4 没有评测集

没有评测，就无法判断微调是否真的变好。

6.5 任务变化很快

任务规则每周都变，微调迭代成本会很高。

7. 微调方法总览

现代 LLM 微调不只有一种方式。

方法	核心思想	适合场景
Full Fine-tuning	更新全部模型参数	小模型、研究、强领域适配
SFT	用正确答案示例训练	格式、风格、分类、抽取、指令遵循
Instruction Tuning	用指令数据训练模型遵循任务	通用助手能力、任务泛化
LoRA	冻结原模型，只训练低秩适配矩阵	开源模型低成本微调
QLoRA	量化基座模型 + LoRA	显存受限的开源模型微调
DPO	用偏好对训练模型偏向更好回答	主观偏好、风格、排序偏好
RLHF	奖励模型 + 强化学习优化	对齐人类偏好，流程复杂
RFT	用可编程 grader 给候选输出打分	可自动评分的推理或专业任务
Vision Fine-tuning	图像输入相关的微调	视觉分类、图文任务风格

OpenAI Model optimization 文档也把 supervised fine-tuning、vision fine-tuning、DPO 和 reinforcement fine-tuning 列为模型优化方向。不同平台支持情况会变，实际落地前要以当前官方文档为准。

8. Supervised Fine-tuning

SFT 是最常见的微调方式。

它需要准备：

输入
理想输出

模型学习的是：

text

在这种输入下，应该产生这样的输出。

8.1 适合 SFT 的任务

固定格式生成
分类
信息抽取
文风统一
结构化问答
特定行业表达
工具调用格式
长提示词压缩

8.2 SFT 不适合什么

学最新知识
解决实时查询
学复杂业务权限
替代数据库
替代检索系统

8.3 SFT 数据样例

一个对话式样本通常长这样：

json

{
  "messages": [
    {
      "role": "system",
      "content": "你是企业客服助手，回答要简洁、礼貌、可执行。"
    },
    {
      "role": "user",
      "content": "我付款了，但是发票信息开错了。"
    },
    {
      "role": "assistant",
      "content": "可以为你处理发票更正。请提供订单号、正确的发票抬头和税号，我会协助提交更正申请。"
    }
  ]
}

关键不是 JSON 长什么样，而是样本必须代表你希望模型长期模仿的行为。

9. Instruction Tuning

Instruction tuning 是用大量“指令 -> 回答”数据训练模型，让模型更会理解不同任务指令。

它和 SFT 的关系很近，可以理解为一种更广义的 SFT。

典型样本：

text

Instruction: 把下面内容总结成 3 条要点。
Input: [原文]
Output: [高质量总结]

Instruction tuning 的价值在于：

提升指令遵循能力。
让模型适配更多任务格式。
让模型更像助手。

InstructGPT 论文展示了用人工示范和人类偏好反馈改进模型指令遵循的路线，也说明单纯扩大模型规模并不必然让模型更符合用户意图。

10. DPO 与偏好微调

DPO 是 Direct Preference Optimization。

它使用的不是单一正确答案，而是偏好对：

text

Prompt
 -> Chosen Response
 -> Rejected Response

模型学习：

在同一个问题下，更偏向 chosen，远离 rejected。

OpenAI DPO 文档说明，DPO 适合基于 prompts 和成对 responses 学习更主观的人类偏好。DPO 论文则提出用更简单的分类式目标替代复杂的显式 reward model + RL 流程。

10.1 适合 DPO 的场景

两个回答都能用，但一个更好。
风格偏好难以写成硬规则。
输出质量需要靠比较判断。
需要减少啰嗦、幻觉、语气问题。
需要强化某类拒答或安全偏好。

10.2 不适合 DPO 的场景

没有稳定偏好标准。
chosen / rejected 质量差距很小且标注不一致。
问题是事实缺失。
应该用程序校验格式而不是靠偏好学习。

10.3 DPO 样例

json

{
  "prompt": "用户：我的订单还没发货，怎么办？",
  "chosen": "我可以帮你确认处理路径。请先提供订单号；如果超过承诺发货时间，可以申请催发或退款。",
  "rejected": "你再等等吧，物流有时候会慢。"
}

chosen 更具体、可执行、语气更专业。

11. RLHF 与 RFT

RLHF 是 Reinforcement Learning from Human Feedback。经典流程包括：

收集人类示范数据，做 SFT。
收集多个模型回答的人类排序。
训练 reward model。
用强化学习优化模型，使输出更符合 reward。

InstructGPT 就是这一方向的代表工作之一。

11.1 RFT 是什么

OpenAI Reinforcement fine-tuning 文档描述的 RFT 路线，是用你定义的 feedback signal 或 grader 对候选输出评分，再让训练过程提高高分输出概率。

它和 SFT 的差异：

SFT 模仿固定答案。
RFT 根据评分函数优化行为。

11.2 RFT 适合什么

答案能用程序或 grader 评分。
任务需要特定推理过程。
正确答案不止一种，但质量可评估。
领域任务有明确评分标准。

例如：

数学题按最终答案和步骤评分。
代码题按测试用例评分。
法规问答按引用和结论一致性评分。
工具调用任务按参数合法性和执行结果评分。

11.3 RFT 的风险

grader 写得不好，模型会优化错误目标。
评分函数可能被模型钻空子。
训练和评估成本更高。
调试难度比 SFT 大。

12. LoRA

LoRA 是 Low-Rank Adaptation。

LoRA 论文的核心思想是：

冻结原始模型权重。
在部分权重旁边注入可训练的低秩矩阵。
训练时只更新这些小矩阵。

直觉图：

text

Original Weight W  frozen
Update ΔW = A × B  trainable low-rank matrices
Effective Weight = W + ΔW

12.1 为什么 LoRA 有用

全量微调大模型成本很高。LoRA 通过训练少量参数降低：

显存
存储
训练成本
多任务适配成本

LoRA 论文报告了相比全量微调显著减少可训练参数和显存需求的效果，并且推理时可以合并权重，不一定引入额外延迟。

12.2 LoRA 常用位置

在 Transformer 里，LoRA 常加在：

attention 的 Q / K / V / O projection
FFN projection
有时只加 Q/V

具体位置要看模型、任务和框架。

12.3 LoRA 适合什么

开源模型微调
多个业务任务分别保存 adapter
资源有限但要定制模型
不希望复制整套模型权重

13. QLoRA

QLoRA 是在 LoRA 基础上的进一步省显存方法。

QLoRA 论文的核心是：

把预训练模型量化到 4-bit。
冻结量化后的基座模型。
通过 LoRA adapter 反向传播和训练。

它还提出了 NF4、double quantization、paged optimizers 等技术来降低显存占用。

13.1 QLoRA 适合什么

单卡或小资源环境微调较大模型。
希望尽量保留大模型能力。
对训练成本敏感。

13.2 QLoRA 的注意点

量化会增加工程复杂度。
训练速度和显存受实现影响很大。
仍然需要高质量数据和评测。
部署时要考虑 adapter 和量化格式兼容。

14. 数据是微调的上限

微调最关键的资产不是训练脚本，而是数据。

OpenAI fine-tuning best practices 强调，当微调结果不强时，应优先审查样本质量、数据覆盖、数据平衡和剩余失败案例，而不是盲目继续训练。

14.1 好数据的特点

特点	说明
目标一致	样本都在教同一种行为
输出高质量	assistant 输出就是你想上线的答案
边界清晰	包含难例、拒答、冲突、异常输入
风格统一	不同标注人也遵循同一规范
覆盖真实分布	接近线上用户输入
没有脏信息	不含错误事实、敏感泄露、无关模板

14.2 坏数据会造成什么

模型学会啰嗦。
模型格式更乱。
模型错误拒答。
模型过度自信。
模型继承标注人的不一致。
模型把旧规则当成新规则。

15. 数据集设计

微调数据不是越多越好，先要设计好分布。

15.1 样本类型

建议覆盖：

正常样本
边界样本
失败样本
拒答样本
冲突样本
安全样本
长输入样本
用户表达混乱样本

15.2 训练集、验证集、测试集

至少拆成：

集合	用途
Train	训练模型
Validation	训练过程中观察效果和过拟合
Test / Holdout	最终评估，不能参与训练

Holdout 集非常重要。没有它，就容易把模型训练成“会背训练集”。

15.3 数据量怎么估

没有统一数字，取决于任务复杂度和模型能力。

经验上：

简单格式或风格任务，少量高质量样本可能有效。
分类和抽取任务，要覆盖每个类别和边界。
复杂推理或领域任务，需要更多高质量、多样化样本。

比起先追求样本数，更应该先做：

小规模高质量数据
微调
评测
失败分析
针对性补数据

16. 数据标注规范

没有标注规范，数据集很快会变成多人风格混杂。

标注规范至少要写清：

任务目标
输入字段含义
输出格式
语气要求
拒答规则
类别定义
优先级规则
不确定时怎么写
禁止出现的内容

16.1 分类标注示例

text

如果同时出现退款和投诉，优先标为 complaint。
如果用户只是询问退款流程，不算 complaint。
如果用户表达监管投诉、律师函、公开曝光，标为 risk。

16.2 抽取标注示例

text

字段不存在时返回 null。
不要根据常识补全公司名。
证据字段必须引用原文片段，不能改写。

这类规范会直接决定微调后模型的稳定性。

17. 微调数据格式

不同平台格式不同，但核心都是输入和目标输出。

17.1 对话格式

适合聊天模型：

json

{
  "messages": [
    {
      "role": "system",
      "content": "你是保险理赔助手。"
    },
    {
      "role": "user",
      "content": "我想申请车辆理赔，需要准备什么？"
    },
    {
      "role": "assistant",
      "content": "请准备保单号、事故时间、事故地点、现场照片、交警责任认定书和维修发票。"
    }
  ]
}

17.2 指令格式

适合开源模型训练：

json

{
  "instruction": "将用户反馈分类。",
  "input": "你们的系统又崩了，我已经第三次遇到了。",
  "output": "{\"category\":\"complaint\",\"priority\":\"high\"}"
}

17.3 偏好格式

适合 DPO：

json

{
  "prompt": "用户说：系统打不开，怎么办？",
  "chosen": "请先确认网络是否正常，并提供报错截图或错误码，我会帮你进一步定位。",
  "rejected": "你重启一下吧。"
}

17.4 RFT 评分格式

适合可程序评分任务：

json

{
  "prompt": "根据以下政策判断用户是否符合退款条件。",
  "response": "用户符合退款条件，因为申请时间在 7 天内且未使用服务。",
  "score": 1.0,
  "grader_notes": "结论和依据均正确"
}

实际平台可能不使用这个 JSON 形状，但它表达了 RFT 的核心：需要可评价的输出和稳定评分规则。

18. 数据清洗检查清单

训练前至少检查：

是否有重复样本。
是否有互相矛盾的答案。
是否有过期政策。
是否有隐私和敏感信息。
是否有格式损坏。
是否有空输出或无意义输出。
是否把 bad example 当成 good output。
是否类别极度不平衡。
是否包含不该模仿的语气。
是否训练集和测试集泄漏。

微调会放大数据习惯。数据里有一点懒，模型会学得很认真。

19. 微调流程

一个比较稳的微调流程：

text

Define Goal
 -> Build Prompt Baseline
 -> Build Eval Set
 -> Collect Failures
 -> Write Labeling Guide
 -> Prepare Training Data
 -> Train Small Experiment
 -> Evaluate
 -> Error Analysis
 -> Add Targeted Data
 -> Train Again
 -> Shadow Test
 -> Rollout

19.1 不要跳过 Prompt baseline

微调前先做强 Prompt baseline，有两个好处：

确认问题是否真的需要微调。
提供训练样本的行为标准。

19.2 小实验先行

不要一开始就投入大数据集。

先用小而高质量的数据验证：

任务是否可学
格式是否稳定
评测是否能区分效果
是否出现明显副作用

20. 超参数与训练观察

不同平台暴露的超参数不同，但你需要理解它们的作用。

参数	影响
learning rate	学得多快，过大容易破坏原能力
epochs	训练轮数，过多容易过拟合
batch size	训练稳定性和显存
warmup	前期训练稳定性
weight decay	正则化
LoRA rank	适配器容量
LoRA alpha	LoRA 更新强度
dropout	防止过拟合

20.1 过拟合迹象

训练集表现变好，验证集不升反降。
输出越来越像训练样本模板。
对新问题泛化差。
模型过度自信。
原本会的通用能力下降。

20.2 欠拟合迹象

格式仍不稳定。
任务边界没有学会。
训练集表现也不好。
输出仍像基础模型。

欠拟合不一定要加训练轮数，也可能是数据太少、标签不一致或任务定义不清。

21. 微调评测

微调没有评测，就像闭着眼睛调参。

21.1 至少要比较三个版本

版本	作用
Base model	基础能力基线
Prompt baseline	强提示词能做到什么
Fine-tuned model	微调是否带来净收益

21.2 评测维度

维度	示例指标
任务正确性	分类准确率、字段 F1、人工评分
格式稳定性	JSON 解析成功率、schema 通过率
风格一致性	人工偏好、风格规则命中
边界处理	拒答准确率、冲突处理正确率
安全性	越权输出、敏感信息泄露
泛化能力	未见样本表现
成本	prompt token 是否减少
延迟	总响应时间是否下降
回归风险	原有能力是否下降

21.3 自动化评测样例

json

{
  "input": "我已经取消订单了，为什么还扣费？",
  "expected": {
    "category": "refund",
    "priority": "high",
    "need_human": true
  },
  "checks": [
    "valid_json",
    "category_correct",
    "priority_correct",
    "no_policy_fabrication"
  ]
}

21.4 人工评测

风格、专业性、用户体验通常仍需要人工复核。

建议人工评分时用固定 rubric：

5 分：准确、完整、语气符合、可直接上线
3 分：基本可用，但有小问题
1 分：错误、危险或不可用

22. 微调后的上线策略

微调模型不应该直接全量上线。

推荐流程：

离线评测通过。
小流量 shadow test。
和旧模型并行记录输出。
人工抽检高风险样本。
分阶段灰度。
保留回滚开关。

22.1 需要监控什么

任务成功率
格式失败率
人工接管率
用户投诉率
拒答率
平均 token
延迟
成本
安全拦截次数
高风险类别漏判率

22.2 回滚条件

提前定义：

哪些指标下降要回滚
谁有权限回滚
回滚到哪个模型版本
数据和日志怎么保留

23. 微调版本管理

每个微调版本都应该记录：

json

{
  "model_base": "base-model-name",
  "fine_tune_method": "sft",
  "training_dataset": "customer-support-v3",
  "validation_dataset": "customer-support-holdout-v2",
  "labeling_guide": "support-labeling-guide-v4",
  "eval_report": "eval-2026-07-06",
  "owner": "ai-platform",
  "created_at": "2026-07-06",
  "rollback_to": "support-model-v2"
}

没有版本管理，后续很难回答：

这次模型为什么变好
为什么线上突然变差
是否能回滚
哪批数据造成了问题

24. 微调和安全

微调会把数据中的行为模式固化进模型，所以安全风险要前置处理。

24.1 数据安全

训练数据里要避免：

PII
密钥
内部敏感文档
未授权用户内容
错误政策
歧视性或不合规输出

24.2 行为安全

训练样本要覆盖：

应该拒答的问题
需要人工升级的问题
不确定时怎么说
高风险领域的边界
工具调用前的确认

24.3 偏好数据风险

DPO 或 RLHF 的偏好标注如果不一致，会让模型学到混乱偏好。

需要控制：

标注人培训
标注一致性
难例复审
高风险样本专家复核

25. 微调常见失败模式

失败模式	表现	根因	修复
没有提升	微调后和 baseline 差不多	任务本来可由 prompt 解决，或数据太弱	强化数据和评测
格式更乱	JSON / schema 失败	样本格式不一致	清洗数据，统一输出
过拟合	新问题表现差	样本少、epochs 多	增加数据、降低训练强度
风格漂移	语气不稳定	多人标注无规范	建标注指南
幻觉增加	更自信地编造	训练样本鼓励猜测	加拒答样本
安全下降	高风险问题没拦住	安全样本不足	加红队和拒答样本
成本没降	Prompt 仍很长	没重写线上 prompt	微调后简化 prompt
泛化差	只会训练集场景	数据覆盖窄	补真实分布和边界样本

26. 微调后 Prompt 还需要吗

需要。

微调不是取消 Prompt，而是把部分稳定行为内化到模型里。

微调后 Prompt 可以更短，但仍要保留：

当前任务目标
当前输入
输出格式或 schema
安全边界
当前上下文
工具调用规则

好的目标是：

把长期稳定规则放进模型训练。
把实时上下文和本次任务留在 Prompt 里。

27. 微调和 RAG 怎么组合

很多真实系统不是二选一，而是组合。

27.1 RAG 负责知识

产品文档
制度条款
FAQ
工单知识
最新政策

27.2 微调负责行为

回答格式
引用风格
拒答方式
语气
多文档综合习惯

组合方式：

text

Query
 -> RAG Retrieval
 -> Context
 -> Fine-tuned Model
 -> Structured Answer with Citations

例如企业知识库问答：

RAG 找到证据。
微调模型学会“先答结论，再列依据，证据不足就拒答”。

28. 微调成本与收益

微调的收益可能包括：

减少 prompt token
减少 few-shot 示例
提高格式通过率
降低人工修正
提高小模型可用性
降低线上延迟

成本包括：

数据标注
数据清洗
训练费用
评测费用
版本管理
上线灰度
回归测试
安全审查

所以要算的是总成本，不只是训练任务本身多少钱。

29. 实战决策树

text

模型效果不好
 |
 +-- 缺最新或私有知识？ -> RAG / 工具 / 数据库
 |
 +-- 输出格式不稳定？ -> Structured Outputs / Prompt
 |
 +-- Prompt 很长且任务稳定？ -> SFT
 |
 +-- 风格或偏好难以写规则？ -> DPO
 |
 +-- 有程序化评分器？ -> RFT
 |
 +-- 开源模型资源有限？ -> LoRA / QLoRA
 |
 +-- 没有评测集？ -> 先建评测，不要先微调

30. 最小可行微调方案

如果你要第一次做微调，建议这样开始：

选一个稳定、重复、高价值任务。
做一个强 Prompt baseline。
准备 50-200 条高质量训练样本。
准备 50 条 holdout 评测样本。
写标注规范。
做一次小规模 SFT。
比较 base、prompt baseline、fine-tuned model。
分析失败样例。
有针对性补数据。
再决定是否扩大数据和上线。

别一开始就追求复杂训练方法。第一步要证明：

这个任务确实能被数据教会。

31. 推荐搭配阅读

32. 参考资料

以下资料在 2026-07-06 检查时可访问：

官方文档

OpenAI Model Optimization: https://developers.openai.com/api/docs/guides/model-optimization
OpenAI Supervised Fine-tuning: https://developers.openai.com/api/docs/guides/supervised-fine-tuning
OpenAI Fine-tuning Best Practices: https://developers.openai.com/api/docs/guides/fine-tuning-best-practices
OpenAI Direct Preference Optimization: https://developers.openai.com/api/docs/guides/direct-preference-optimization
OpenAI Reinforcement Fine-tuning: https://developers.openai.com/api/docs/guides/reinforcement-fine-tuning
Hugging Face PEFT: https://huggingface.co/docs/peft/index
Hugging Face TRL: https://huggingface.co/docs/trl/index

论文

Training language models to follow instructions with human feedback: https://arxiv.org/abs/2203.02155
LoRA: Low-Rank Adaptation of Large Language Models: https://arxiv.org/abs/2106.09685
QLoRA: Efficient Finetuning of Quantized LLMs: https://arxiv.org/abs/2305.14314
Direct Preference Optimization: Your Language Model is Secretly a Reward Model: https://arxiv.org/abs/2305.18290

33. 一句话总结

Fine-tuning 是把高质量任务数据转化为模型稳定行为的工程方法。它最适合固化格式、风格、分类边界和任务习惯；不适合替代知识库、数据库和实时工具。真正有效的微调，核心不在训练按钮，而在清晰任务、好数据、强评测、版本管理和安全上线。

03. Fine-tuning 详解 ​

1. 什么是 Fine-tuning ​

2. 微调到底改变什么 ​

3. 微调和预训练的区别 ​

4. 微调、Prompt、RAG、工具调用怎么选 ​

5. 什么时候值得微调 ​

6. 什么时候不该先微调 ​

6.1 任务定义不清 ​

6.2 数据质量差 ​

6.3 主要问题是缺知识 ​

6.4 没有评测集 ​

6.5 任务变化很快 ​

7. 微调方法总览 ​

8. Supervised Fine-tuning ​

8.1 适合 SFT 的任务 ​

8.2 SFT 不适合什么 ​

8.3 SFT 数据样例 ​

9. Instruction Tuning ​

10. DPO 与偏好微调 ​

10.1 适合 DPO 的场景 ​

10.2 不适合 DPO 的场景 ​

10.3 DPO 样例 ​

11. RLHF 与 RFT ​

11.1 RFT 是什么 ​

11.2 RFT 适合什么 ​

11.3 RFT 的风险 ​

12. LoRA ​

12.1 为什么 LoRA 有用 ​

12.2 LoRA 常用位置 ​

12.3 LoRA 适合什么 ​

13. QLoRA ​

13.1 QLoRA 适合什么 ​

13.2 QLoRA 的注意点 ​

14. 数据是微调的上限 ​

14.1 好数据的特点 ​

14.2 坏数据会造成什么 ​

15. 数据集设计 ​

15.1 样本类型 ​

15.2 训练集、验证集、测试集 ​

15.3 数据量怎么估 ​

16. 数据标注规范 ​

16.1 分类标注示例 ​

16.2 抽取标注示例 ​

17. 微调数据格式 ​

17.1 对话格式 ​

17.2 指令格式 ​

17.3 偏好格式 ​

17.4 RFT 评分格式 ​

18. 数据清洗检查清单 ​

19. 微调流程 ​

19.1 不要跳过 Prompt baseline ​

19.2 小实验先行 ​

20. 超参数与训练观察 ​

20.1 过拟合迹象 ​

20.2 欠拟合迹象 ​

21. 微调评测 ​

21.1 至少要比较三个版本 ​

21.2 评测维度 ​

21.3 自动化评测样例 ​

21.4 人工评测 ​

22. 微调后的上线策略 ​

22.1 需要监控什么 ​

22.2 回滚条件 ​

23. 微调版本管理 ​

24. 微调和安全 ​

24.1 数据安全 ​

24.2 行为安全 ​

24.3 偏好数据风险 ​

25. 微调常见失败模式 ​

26. 微调后 Prompt 还需要吗 ​

27. 微调和 RAG 怎么组合 ​

27.1 RAG 负责知识 ​

27.2 微调负责行为 ​

28. 微调成本与收益 ​

29. 实战决策树 ​

30. 最小可行微调方案 ​

31. 推荐搭配阅读 ​

32. 参考资料 ​

官方文档 ​

论文 ​

03. Fine-tuning 详解

1. 什么是 Fine-tuning

2. 微调到底改变什么

3. 微调和预训练的区别

4. 微调、Prompt、RAG、工具调用怎么选

5. 什么时候值得微调

6. 什么时候不该先微调

6.1 任务定义不清

6.2 数据质量差

6.3 主要问题是缺知识

6.4 没有评测集

6.5 任务变化很快

7. 微调方法总览

8. Supervised Fine-tuning

8.1 适合 SFT 的任务

8.2 SFT 不适合什么

8.3 SFT 数据样例

9. Instruction Tuning

10. DPO 与偏好微调

10.1 适合 DPO 的场景

10.2 不适合 DPO 的场景

10.3 DPO 样例

11. RLHF 与 RFT

11.1 RFT 是什么

11.2 RFT 适合什么

11.3 RFT 的风险

12. LoRA

12.1 为什么 LoRA 有用

12.2 LoRA 常用位置

12.3 LoRA 适合什么

13. QLoRA

13.1 QLoRA 适合什么

13.2 QLoRA 的注意点

14. 数据是微调的上限

14.1 好数据的特点

14.2 坏数据会造成什么

15. 数据集设计

15.1 样本类型

15.2 训练集、验证集、测试集

15.3 数据量怎么估

16. 数据标注规范

16.1 分类标注示例

16.2 抽取标注示例

17. 微调数据格式

17.1 对话格式

17.2 指令格式

17.3 偏好格式

17.4 RFT 评分格式

18. 数据清洗检查清单

19. 微调流程

19.1 不要跳过 Prompt baseline

19.2 小实验先行

20. 超参数与训练观察

20.1 过拟合迹象

20.2 欠拟合迹象

21. 微调评测

21.1 至少要比较三个版本

21.2 评测维度

21.3 自动化评测样例

21.4 人工评测

22. 微调后的上线策略

22.1 需要监控什么

22.2 回滚条件

23. 微调版本管理

24. 微调和安全

24.1 数据安全

24.2 行为安全

24.3 偏好数据风险

25. 微调常见失败模式

26. 微调后 Prompt 还需要吗

27. 微调和 RAG 怎么组合

27.1 RAG 负责知识

27.2 微调负责行为

28. 微调成本与收益

29. 实战决策树

30. 最小可行微调方案

31. 推荐搭配阅读

32. 参考资料

官方文档

论文