模型训练与微调
# 模型训练与微调
假设客服收到 “帮我查快递” ，却总是直接编一个物流状态。你希望它先问订单号，再根据查询结果回答，就可以准备这类正确示范，训练模型学习这个回应模式。
微调就是在已有模型上继续训练，让它更稳定地完成特定任务。 但这个例子应先尝试 Prompt 和程序规则；只有效果仍不稳定、并且有足够高质量示范时，才评估微调。
# 做一次客服微调，要得到什么
- 准备业务问题和正确回答，同时留出不参与训练的测试题。
- 选择基座模型，用 LoRA / QLoRA 等方式训练。
- 得到 Adapter，也就是学习到的附加参数，而不是得到一个新的完整知识库。
- 部署时把同一个基座与 Adapter 一起加载，让客服接口调用。
- 用相同测试题比较微调前后，确认追问和回答确实改善。
训练在开发或更新模型时进行，不是每个用户发消息时重新训练一次。用户聊天时发生的是推理：使用已经训练好的参数生成回答。
# 训练发生在什么阶段
| 方式 | 学什么 | 例子 |
|---|---|---|
| 预训练 | 从大量数据学习通用模式 | 预测文本中的下一个 Token |
| 持续预训练 | 在已有模型上继续学习特定领域的文本分布 | 学习专业语料的表达，仍需评估通用能力退化 |
| SFT | 从示范答案学习怎样回应指令 | 客服遇到缺少订单号的问题，先追问订单号 |
| 偏好优化 | 在多个候选回答中学习偏好 | 更偏好准确、简洁、不编造承诺的回答 |
SFT 是 Supervised Fine-Tuning（监督微调）：训练数据明确提供输入和期望输出。DPO 等偏好优化方法使用偏好数据，和普通问答 SFT 不应混为一谈。
全参数微调与 LoRA 则是另一个维度：它们决定修改哪些参数，不是决定训练任务。SFT 可以全参数训练，也可以使用 LoRA。
所以 “Qwen3-8B + QLoRA + SFT” 可以拆成三句话：Qwen3-8B 是原模型，QLoRA 是省资源的训练方式，SFT 表示用输入与示范答案来教它。不是三个互相竞争的模型。
# 先决定是否需要微调
方案边界见 Prompt、RAG 与微调怎样选择。以客服为例：
- 回答语气和追问步骤不稳定，可以先改 Prompt，再评估 SFT。
- 商品知识需要引用资料，适合 RAG。
- 订单、库存和物流随时变化，要调用业务工具。
- 退款和修改地址涉及权限，应由后端业务规则校验，不能靠训练保证。
只有稳定任务、训练数据和独立测试集都明确后，才有办法判断训练是否值得。先建立原模型的效果、延迟和成本基线。
# 这一组笔记怎样读
| 笔记 | 主要内容 |
|---|---|
| LoRA、QLoRA 与显存 | 更新哪些参数，为什么省显存，量化和 Adapter 是什么 |
| 训练数据、参数与效果评估 | 数据格式、划分、训练参数、Loss、过拟合和验收 |
| 智能客服微调项目实战 | Qwen3-8B、LLaMA-Factory、FastAPI 与 Mastra 的真实代码链路 |
| YOLO 视觉模型训练 | 图像检测的标签、训练、评估和导出，与语言模型微调的区别 |
# 基座模型怎样选
Base 通常指偏向预训练目标的模型，Instruct 指经过指令训练的模型，但不能只凭名字判断具体能力。例如 Qwen3 (opens new window) 原始系列的 Qwen/Qwen3-8B 支持思考与非思考模式，不能自行给它补成不存在的 Qwen3-8B-Instruct 标识。
Dense（稠密模型）通常在一次前向计算中使用大部分模型参数；MoE（混合专家）每个 Token 只激活部分专家，但总权重的存储和调度仍有成本，不能只看激活参数量估算显存。
选型应比较目标语言、任务效果、模型许可、上下文长度、硬件和服务成本。较小模型经过高质量微调可能足够，但不能先认定一定比更大的通用模型好。
# 工具分别负责什么
| 工具 | 职责 |
|---|---|
| LLaMA-Factory (opens new window) | 用配置和 CLI 组织多种训练与评估流程 |
| PEFT (opens new window) | LoRA 等参数高效微调与 Adapter 加载 |
| TRL (opens new window) | SFT 和偏好训练等训练组件 |
| Unsloth (opens new window) | 为支持的模型优化训练和推理效率，需检查兼容范围 |
| DeepSpeed / FSDP | 在多 GPU 场景切分状态和组织分布式训练 |
| vLLM | 高吞吐推理服务，支持范围取决于模型与量化方式 |
| llama.cpp / Ollama | 适合部分本地推理与模型管理场景，不是通用 GPU 训练框架 |
不要同时引入所有工具。先选一条能够复现的训练和部署链，再固定模型 revision、依赖与配置。
# 从一条示范到一次参数更新
以 “用户没提供订单号，客服先追问” 为例，SFT 不是把这段文字存成问答字典，而是反复执行下面的过程：
- Tokenizer 把系统要求、用户问题和示范回答转换为 Token ID，按模型对话模板拼接。
- 模型根据前面的 Token 预测下一个 Token，训练时使用示范序列提供前文，这叫 teacher forcing（教师强制）。
- 损失函数比较预测与示范答案；反向传播计算梯度，优化器调整允许训练的参数。
- 用新问题验证模型是否也会先追问。只会复述原题，不算学会了这个行为。
训练时能看到标准答案，推理时看不到，只能接着自己已经生成的内容继续预测。所以训练 Loss 很低，真实对话仍可能跑偏；需要测试连续多轮，而不只测试第一句问候。计算细节见 数据与效果评估。
# 一次值得做的微调实验怎么定目标
不要把目标写成 “客服更聪明” 。可以定义成：缺少查询参数时先追问，已有工具结果时不改动关键事实，工具失败时不编造成功，同时保留原模型的常用问答能力。
先固定测试题和通过条件，再比较 Prompt 基线与微调版本。如果原模型已经能稳定完成，新增的训练、显卡服务、数据维护和回归成本可能不划算；如果问题主要来自工具数据错误，继续训练模型也解决不了根因。
评估成本要同时看一次性的整理与训练，以及长期的推理、模型更新和回归测试。开源权重不等于零成本，自部署也不自动比 API 便宜。低请求量时闲置 GPU 可能占主要成本；持续大流量时则要看吞吐、并发和单个成功任务的总成本。
# 面试问答
1. 你怎么向别人解释模型微调？参考答案
微调不是从零教模型说话，而是在现有能力上，用业务示范继续训练。比如客服没拿到订单号时，应该先追问而不是猜状态，我会用这类输入和正确回应教它稳定执行。训练得到的参数用于后续推理，实时订单仍由工具查询，不能靠微调记住。
2. 微调是不是把业务知识记进参数里，就不需要查数据库了？参考答案
训练确实可能让模型记住部分知识，但参数不是可以按订单号可靠查询的数据库，也不能实时更新。我会让微调学习稳定的回答行为，让工具查询实时订单，让 RAG 提供有出处的产品资料。例如订单今天发货，必须以业务接口为准，不能用训练时的旧答案回应。
3. 为什么不直接换一个更大的模型？参考答案
我会把换模型和微调放在同一测试集上比较，不预设微调一定更好。大模型可能直接解决复杂理解问题，但费用、延迟和部署要求也可能更高；小模型微调更适合边界清晰、重复量大的任务。如果主要是实时知识或权限问题，两种方案都不能替代工具和后端校验。
4. 为什么客服系统微调了模型，仍然需要工具和 RAG？参考答案
微调主要让模型更稳定地理解业务表达、追问缺失信息和组织回答。库存、订单状态需要实时查询，产品文档需要检索来源，这些不能靠模型记忆保证。我的设计会把回答行为、知识检索和业务执行分开，权限与写操作仍由后端控制。