【2025最新AI大模型教程】全网最最通俗易懂的LLM大模型预训练+微调实战教程，手把手教你训练大模型，零基础小白也能轻松听懂！课程共8集，涵盖微调概念、适用场景、具体方法、轻量化技术、模型选择、数据管理、评估方法及实操步骤。
P01：什么是 Fine-tuning
1.1 微调的本质
- 微调属于模型训练：所有微调都会使模型参数发生变化，只要参数迭代，就属于模型训练
- 微调是在已训练好的基座模型参数基础上继续调整，是"在别人基础上微微调整每一个参数"
- 微调的门槛已大幅降低，普通研发工程师和专业算法工程师均可上手
1.2 开源模型 vs 闭源模型的微调区别
- 模型最值钱的东西就是那一大堆参数（如1750亿、671亿参数）
- 开源模型微调完成后，所有参数存储在若干文件中，完全归自己所有
1.3 什么是基座模型
- 基座模型：用于构建 AI 产品时选定的通用模型，包括通用语言模型、视觉模型、生图模型等
1.4 微调的重要认知
大多数情况下我们其实是不需要做微调的，应当优先使用应用层技术（如 RAG）。90% 以上我们认为需要微调的场景，最终发现用 RAG 等应用层技术就能解决。
- 微调工作基本都通过代码完成（Python），代码本身并不复杂，现成代码可直接下载使用
- 学习微调的核心价值在于：培养"什么时候需要微调"的判断能力，以及掌握数据相关的观念和 know-how
P02：什么情况下需要微调
2.1 确实需要微调的四种场景
场景一：项目性质决定必须微调
- 典型情况：企业或政府单位出于融资、估值、竞争力宣传等需求，必须拥有"自己的"大模型
- 将别人的模型微调后即可称为"行业大模型"（目前该领域缺乏统一监管和验证标准）
场景二：语言风格和沟通方式有特殊要求
- 当通过 prompt 无法稳定控制模型的语言风格时，可考虑微调
- 典型例子：AI 儿童讲故事（需要像父母讲故事的温柔风格，而非严谨正式的汇报风格）
- 前提：需先确认是基座模型能力偏弱导致，还是 prompt 设计问题
场景三：垂直领域知识严重缺失
- 基座模型在预训练或 SFT 阶段缺少垂直领域数据，导致无法完成专业任务
- 典型例子：军事领域——公开训练数据稀少，模型在军事相关的语言任务上表现差
- 与"缺知识"不同，这类问题可能需要微调补充专业知识
场景四：特定任务类型模型从未见过
区分两种根本不同的情况：一是"缺某种知识"，二是"从未做过某种类型的任务"。前者通常用 RAG 解决，后者才真正需要微调。
- 典型例子：RPA（机器人流程自动化）任务——让语言模型自动化操作电脑/手机完成多步骤任务
- 案例：用自然语言指令让模型在美团上点一杯美式咖啡，涉及启动 APP → 搜索 → 选择店铺 → 选规格 → 询问用户偏好等多个步骤
- 语言模型的训练数据中几乎不存在这种"一步步操作直到完成结果"的数据，因此任务类型确实是新的
2.2 判断是否需要微调的工作方法
- 先用应用层技术（Few-shot、RAG、Agent）尽全力尝试
2.3 微调不是一次性工作
- 基座模型迭代速度极快（如千问 2.5 → 3.0 → 3.5）
- 新版本模型能力更强、成本更低，可能需要重新基于新版本微调
- 建议将基座模型的 AI 能力理解为像水电煤一样的基础设施，我们的工作是在其上构建增值服务
P03：Fine-tuning 的具体用法
3.1 微调的主要类型
全量参数微调（Full Fine-tuning）
部分参数微调（Parameter-Efficient Fine-tuning）
3.2 SFT（有监督微调）
- SFT（Supervised Fine-Tuning）：最常见的微调类型
- 使用有标注的问答对数据，让模型学习特定的输入-输出映射
- 基座模型的训练通常用全量微调；应用层产品通常用部分参数微调（LoRA 等）
3.3 场景标签的重要性
场景标签是贯穿整个微调工作始终的核心概念，也是 AI 产品管理中极为关键的工作。
- 场景标签（子场景标签）：对微调数据按业务场景进行分类的标记
- 作用：管理微调前/微调后模型在每个子场景下的表现变化
- 在一个 AI 产品中，可能同时用到多个模型，场景标签帮助精细化管理每个场景下的模型效果
P04：轻量化微调
4.1 为什么需要轻量化微调
4.2 冻结部分参数
- 轻量化微调的核心思路：冻结（Freeze） 大部分参数，只训练少量参数
- 减少可训练参数数量 → 减少显存占用 → 降低硬件门槛和成本
4.3 全量微调的显存需求估算
以 7B 模型全量微调为例：
- 70亿参数 × 每参数4字节（32位浮点数）= 280亿字节 ≈ 26GB 显存（仅加载参数）
- 微调还需存储梯度等中间计算结果，约为参数本身的3倍
- 需要至少 4-8 张 4090 显卡（每张24GB显存，约2万多元）
一张 4090 显卡连加载一个 7B 模型都勉强，更别说 175B 或 671B 的大模型。
P05：LoRA 详解
5.1 Transformer 参数矩阵回顾
以 GPT-3 为例，每层包含6个核心参数矩阵：
- 每个参数矩阵（如WQ）展开后近似为 12288×12288 的正方形矩阵，约含1.5亿个参数
5.2 LoRA 的核心思想
LoRA（Low-Rank Adaptation，低秩适应微调） 的基本原理：
- 在原参数矩阵的每个参数上叠加一个偏移量（delta）
新参数矩阵 = 原参数矩阵（冻结） + 偏移量矩阵（可训练）
5.3 矩阵乘法基础（理解低秩的关键）
矩阵相乘规则：左矩阵行数 × 右矩阵列数 = 结果矩阵尺寸
关键发现：3×1 矩阵乘以 1×3 矩阵，可以得到一个 3×3 的矩阵
5.4 LoRA 的低秩分解
传统方式（不用LoRA）：
- 对 12288×12288 的 WQ 矩阵，每个位置加偏移量 → 需要 1.5亿个可训练参数
LoRA 方式：
- 构造矩阵 A（12288×R）和矩阵 B（R×12288）
- A × B = 12288×12288 的偏移量矩阵（尺寸与WQ相同，可做加法）
- 可训练参数仅为 A 和 B 中的元素，总数 = 12288×R + R×12288 = 2×12288×R
- 当 R=1 时，约 2.4万个参数，相比1.5亿降低了约6000倍
R（秩）的选择：R 可取 4、8、16、32 等值，R 越大精度越高，显存占用越大
LoRA 的精髓：用极少数可训练参数，通过低秩矩阵分解，影响极大的参数矩阵，实现高效微调。
5.5 QLoRA（量化 LoRA）
QLoRA 在 LoRA 基础上进一步减少显存占用，方式是降低参数的数值精度（量化）：
- 量化后：改用 8位整数 存储，占1个字节 → 显存降至原来的 1/4
量化的实现原理（举例）：
原始参数（浮点数）：1.6、2.4、1.2、0.8
找公共倍数（×5）后变为整数：8、12、6、4
QLoRA 的代价是损失了一定的数值精度，但换来了大幅降低的显存占用，使得在消费级显卡上微调大模型成为可能。
5.6 最常用的两种微调方式总结
- LoRA / QLoRA：效果接近，成本大幅降低，是目前最主流的微调方式
P06：模型选择与数据需求
6.1 开源 vs 闭源的选择
市场上95%以上的公司在做微调时选择开源模型。
优先选择开源模型的理由：
- 开源模型的能力已经与闭源模型相差无几（如 DeepSeek）
选择闭源模型的前提：必须有明确的理由，否则默认选开源
6.2 如何选择具体模型
持续性是关键：选择模型时，该模型背后公司的开源持续性比当前排名更重要
反面案例（智谱 GLM）：
- 原因：纯创业公司依赖模型盈利，最终不得不走 OpenAI 路线
讲师推荐：阿里千问（Qwen）——阿里云整体生态使得千问即便不靠模型赚钱也没有问题，开源持续性有保障。服务器、算力等配套服务也有完整支持。
6.3 选择模型尺寸的策略
6.4 微调数据管理（以零售门店场景为例）
数据质量原则：
- 优先从真实场景收集数据（录音、企业微信记录、客服工具记录等）
数据标注字段建议：
6.5 数据分布的合理性
核心原则：数据分布应与真实业务情况保持一致
例子：若门店实际情况为——
则微调数据集中各场景比例应尽量与此对应，避免某类场景数据过多导致模型"偏科"。
允许人为调整比例的例外情况：
- 某类场景一旦出错影响极大（如退换货、投诉处理） → 适当提高该类数据比例
- 某类场景对话复杂度高，微调后表现仍不佳 → 在下一轮微调时增加该类数据量
6.6 数据数量参考
数据量需求与知识密度高度相关。AI 面试场景知识密度低，数据需求相对少；医疗场景知识密度高，需要更多数据。上述数字仅为参考，非绝对标准。
P07：评估微调后的模型能力
7.1 数据集的三种划分
在微调之前，需将数据划分为三个部分：
- 训练集（Training Set）：用于实际训练模型参数
- 验证集（Validation Set）：训练过程中用于监控模型表现，帮助调整超参数，防止过拟合
- 测试集（Test Set）：微调完成后，用于最终评估模型真实表现，模拟真实场景
测试集必须是模型从未"见过"的数据，才能真实反映泛化能力。
7.2 过拟合 vs 欠拟合
过拟合（Overfitting）：模型在训练集上表现很好，但在验证集/测试集上表现差
- 表现：模型"死记硬背"训练数据，遇到新问题无法泛化
欠拟合（Underfitting）：模型在训练集和验证集上均表现不佳
7.3 评估方法
方法一：选择题正确率（客观评估）
- 优点：客观、可量化；缺点：无法评估语言风格、对话流畅度等主观质量
方法二：偏好数据（Preference Data）
- 对同一问题，收集多个不同质量的回答（优秀/一般/较差）
- 也是 RLHF（基于人类反馈的强化学习） 的数据基础
7.4 场景标签在评估中的作用
- 原因：某一场景的整体表现良好，可能掩盖了特定子场景的严重问题
例如：
- 但"投诉处理"子场景正确率只有 50% → 这在真实业务中可能造成严重后果
场景标签是微调评估的"放大镜"，帮助精确定位问题所在。
7.5 多轮迭代的工作方式
微调不是一次性工作，而是一个持续迭代的过程：
收集数据 → 数据清洗/标注 → 微调训练 → 评估（按场景） → 发现问题 → 调整数据 → 再次微调 → ...
- 每轮评估后，根据表现较差的场景，有针对性地补充该场景数据
P08：实操的具体步骤
8.1 整体流程框架
1. 需求分析与判断
↓
2. 选择基座模型
↓
3. 数据准备
↓
4. 配置微调参数
↓
5. 执行微调训练
↓
6. 评估与验证
↓
7. 部署上线
↓
8. 持续监控与迭代
8.2 步骤一：需求分析与判断
- 优先验证是否可用 RAG、Agent、Few-shot 等应用层技术解决
8.3 步骤二：选择基座模型
8.4 步骤三：数据准备（最重要的步骤）
数据收集：
数据清洗与标注：
数据集划分：
- 训练集 / 验证集 / 测试集（典型比例：80% / 10% / 10%）
检查数据分布：
8.5 步骤四：配置微调参数
选择微调方式：
关键超参数：
- 学习率（Learning Rate）：控制每次参数更新的步长
- 批大小（Batch Size）：每次更新参数使用的样本数量
- LoRA 的 R 值：秩的大小，影响可训练参数量（常用 4、8、16、32）
8.6 步骤五：执行微调训练
- 使用 Python 调用微调框架（如 LLaMA-Factory、transformers、unsloth 等）
- 监控训练过程中的 Loss 曲线（训练 Loss 和验证 Loss）
Loss 曲线的判断：
- 训练 Loss 和验证 Loss 同步下降 → 正常
- 训练 Loss 持续下降但验证 Loss 开始上升 → 过拟合，需停止训练
- Loss 下降很慢或不下降 → 欠拟合，检查数据或调整参数
8.7 步骤六：评估与验证
8.8 步骤七：部署上线
8.9 步骤八：持续监控与迭代
核心概念速查
| |
|---|
| Fine-tuning（微调） | |
| SFT（有监督微调） | |
| LoRA | 低秩适应微调，通过低秩矩阵分解大幅降低可训练参数量 |
| QLoRA | |
| 全量参数微调 | |
| 基座模型 | |
| 场景标签 | 对数据按业务子场景进行分类的标记，贯穿数据管理和模型评估全流程 |
| 过拟合 | |
| 欠拟合 | |
| RAG | 检索增强生成，大多数"以为需要微调"的场景实际用 RAG 即可解决 |
| 偏好数据（Preference Data） | 用于评估模型输出是否符合人类偏好的排序数据，也是 RLHF 的基础 |
| R（秩） | LoRA 中矩阵分解的秩，决定可训练参数量和表达能力的平衡 |
