一、上节回顾与问题分析

1. 模型的训练可能的问题

• 常见问题表现：
  • 喋喋不休现象：模型在回答完问题后会自动生成新问题并继续回答，形成无限循环
  • 重复叙述问题：模型会在回答末尾重复某些词语（如"好的好的好的"或"观光观光观光"）
• 问题根源分析：
  • 次要原因：小模型参数容易因小数据集调整而崩溃，微调本质上是参数清洗过程
  • 主要原因：使用Base模型进行微调时数据量严重不足（相比预训练阶段接收的数百GB/TB数据）

2. 大模型微调的难点与挑战

• 投入产出比问题：
  • 显存占用高，训练时间长（如GPT-4成本6300-7840万美元）
  • 微调失败率高，可能出现"不如不调"的情况
• 硬件配置建议：
  • 7B模型FP16精度需要20GB显存（推荐RTX 4090）
  • 13B模型FP16精度需要40GB显存（推荐A100 40GB）
  • 70B模型FP16精度需要200GB显存（需2块H100 20GB）

3. 大模型训练的几个阶段

• 训练阶段划分：
  • 预训练阶段：产出Base模型（需1000+GPU，月级别训练）
  • 有监督微调阶段：产出Instruct/Chat模型（需1-100GPU，天级别训练）
  • 强化学习阶段：人类偏好对齐模型
  • 微调阶段：适配垂直领域
• 模型选择建议：
  • 避免直接使用Base模型进行微调
  • 优先选择已完成有监督微调的Instruct/Chat模型
  • Base模型缺乏对话能力，需要极大数据量才能达到Chat模型效果
• 数据量对比：
  • 预训练阶段：数千亿单词（图书、百科、网页等）
  • 有监督微调阶段：数万用户指令+百万量级标注对
  • 垂直领域微调：通常仅使用十万量级用户指令

二、大模型微调实践与优化

1. 微调数据集的构建与处理

1）根据业务构建数据集

• 原生数据与衍生数据
  • 原生数据定义：指直接从业务场景或互联网获取的原始数据，包括新闻数据、资讯数据、聊天数据等公开数据以及公共数据集。
  • 衍生数据定义：通过模型生成的数据，如GPT等大模型生成的训练数据，具有特定格式和规范。
  • 典型区别：
    • 原生数据具有明确来源但存在隐私风险
    • 衍生数据通过模型生成可规避隐私问题
• 原生数据的问题
  • 隐私问题：可能包含身份证号、姓名、联系方式等敏感信息，直接用于训练会引发法律风险。
  • 清洗问题：需要投入大量成本进行数据清洗（如OpenAI清洗GPT数据花费数亿美金）。
  • 数据枯竭：GPT-4/5已耗尽互联网可用数据，垂直领域数据（如医疗、金融）因隐私限制难以获取。
• 数据清洗的挑战与现状
  • 清洗成本：Scalar AI等专业数据公司兴起，反映清洗成本已成为行业瓶颈。
  • 法律风险：即使用户数据清洗后，海量数据中的差错率仍可能导致模型泄露隐私信息。
  • 商业限制：企业（如阿里、字节）因担心数据泄露，拒绝将业务数据提供给云厂商。
• 衍生数据的概念与优势
  • 生成方式：通过prompt让大模型生成符合需求的数据（如100条"吃饭/睡觉"意图识别数据）。
  • 核心优势：
    • 零隐私风险：不包含真实用户信息
    • 低成本：API调用成本远低于人工清洗
    • 格式规范：自动符合微调范式要求
  • 应用场景：适用于意图识别、文本摘要等NLP任务的数据补充。
• 衍生数据生成实例
  • 实例演示：通过DeepSeek生成

    Q:AQ:AQ:A

    格式的意图识别数据：
  • 改写应用：可将少量业务数据输入模型，生成符合微调要求的衍生数据集。
• 大模型厂商对原生数据与衍生数据的使用
  • 风险规避：头部厂商（如阿里）优先使用衍生数据，避免：
    • 法律风险（隐私泄露）
    • 商业风险（客户数据保护）
  • 成本考量：清洗海量原生数据的成本远高于API调用生成数据。
• 衍生数据的问题与强化学习微调
  • 质量保障：
    • 通过RLHF（强化学习人类反馈）对齐人类偏好
    • 过滤有害内容（如脏话、负面情绪）
  • 版权争议：如OpenAI指控部分厂商使用GPT生成数据训练模型
• 世界模型与数据生成
  • 新型解决方案：世界模型专门生成具有逻辑/空间关系的数据（如自动驾驶场景数据）
  • 技术特点：
    • 可生成传统模型难以产生的复杂数据
    • 解决互联网数据枯竭问题
  • 应用前景：将成为未来核心数据生产渠道
• 微调数据集构建与业务相关性
  • 构建原则：需紧密匹配下游任务需求
  • 数据选择：
    • 垂直领域优先使用衍生数据
    • 通用领域可结合清洗后的原生数据
  • 成本平衡：根据业务价值决定数据投入规模

2）微调数据集的构建

• 意图识别数据生成示例
  • 数据特点：包含"Q-A"形式的单轮对话，如"Q:听说公园的花都开了，我们去逛逛吧？A:出去玩"
  • 应用场景：用于训练模型识别用户意图，将多样化问法映射到有限的标准回答
  • 构建技巧：可通过业务日志收集真实用户query，人工标注标准回答类别
• 医疗问题回答与调模式
  • 调模式定义：调整模型输出格式，如从啰嗦回答变为简洁回答
  • 典型案例：针对"服药时间"问题，优化前会给出冗长安全声明，优化后直接回答"遵循医嘱/查看说明书"
  • 实现方法：构建包含理想简洁回答的数据集进行微调
  • 关键优势：相比知识注入，模式调整所需数据量更少、训练轮次更低
• 调风格：幽默风趣的数据集
  • 风格调整：改变模型输出语气特征，如从中规中矩变为幽默风趣
  • 数据要求：需要收集特定风格的语料（如段子、俏皮话等）构建数据集
  • 实现难点：需确保风格一致性，避免生成不恰当的幽默内容
  • 应用价值：适用于客服、教育等需要亲和力的场景
• 调知识：垂直领域知识灌注
  • 核心目标：将专业领域知识（如法律条文、医疗指南）注入模型
  • 数据特点：需要大量高质量专业知识数据，通常远多于模式/风格调整
  • 训练特点：
    • 需要更多训练轮次（epoch）
    • 知识覆盖要全面，避免碎片化
  • 典型应用：法律咨询、医疗问答等专业场景
• 调任务：意图识别与文本摘要
  • 任务类型：
    • 意图识别：如将用户query分类为"吃饭"、"睡觉"等
    • 文本摘要：生成文章要点
    • 语音识别：语音转文字
  • 数据要求：不同任务需要特定格式的数据集
  • 构建要点：任务定义要明确，避免模糊边界
• 微调数据对模型的负向影响
  • 本质影响：微调是"洗参数"过程，会改变模型原有参数分布
  • 双重效应：
    • 正向：提升目标领域能力
    • 负向：可能导致其他能力退化
  • 典型案例：专注金融问答可能导致代码生成能力下降
• 原有能力与现有能力的trade off
  • 权衡策略：
    • 单一任务模型：可接受其他能力下降
    • 通用能力模型：需谨慎平衡各能力
  • 解决方案：
    • 多能力数据集混合训练
    • 按需分配数据集比例（如金融问答50%，其他能力各16.7%）
  • 关键原则：下游任务决定微调策略，不是所有场景都需要微调
• 微调数据集构建策略
  • 数据来源：
    • 原生数据：业务积累的真实数据
    • 衍生数据：通过GPT-4等模型生成
    • 开源数据集：公开可用的标注数据
  • 数据划分：
    • 训练集70%：用于模型参数更新
    • 验证集30%：评估泛化能力
  • 注意事项：
    • 需清洗隐私/有害内容
    • 多轮对话数据需特殊处理
    • 数据量要与制作成本平衡

3）应用案例

• 例题:意图识别与槽位抽取数据集
  • 数据格式：包含输入文本和结构化输出，输出分为意图(intent)和实体(entities)两部分
  • 实体标注：采用键值对形式，如"time":"今天"，表示从文本中提取的时间实体
  • 生成方式：这类数据集通常由大模型生成，而非人工标注
  • 应用场景：用于训练模型理解用户查询意图并提取关键信息的能力
• 例题:文本摘要数据集
  • 基本结构：包含原始文本(text)和摘要(summary)两个部分
  • 示例说明：如将诺贝尔物理学奖的详细报道摘要为"2023年诺贝尔物理学奖授予三位科学家，表彰其在量子计算领域的突破性贡献"
  • 特点：摘要需保留原文核心信息，同时大幅缩短长度
  • 生成方式：可通过大模型自动生成原始文本与对应的摘要对
• 例题:工具调用数据集
  • 核心组件：
    • 功能描述：包含name(功能名称)、description(功能描述)和parameters(参数要求)
    • 对话历史：记录系统、用户和助手之间的完整交互过程
    • 函数调用：助手根据用户需求生成具体的函数调用请求
    • 执行结果：外部工具返回的执行结果
    • 最终响应：助手将执行结果转化为自然语言回复
  • 复杂特性：
    • 多工具调用：支持并行调用多个工具或串行调用多个工具
    • 槽位提取：需要从用户输入中准确提取函数调用所需的参数
    • 自主控制：整个调用流程完全由模型自主决定
  • 构建难点：
    • 数据稀缺：互联网上几乎没有现成的工具调用数据
    • 复杂度高：多工具调用的数据集构建尤为复杂
    • 生成方式：主要依赖大模型自身生成或从实际应用日志中收集
  • 典型示例：
    • 查询大学分数线：需要提取年份参数，调用外部API，再将结果转化为自然语言
    • 多条件查询：如同时查询不同年份的分数线，需要并行调用工具

4）llamafactory数据集构建与配置

• 数据集存放路径
  • 数据位置：存放在/autodl-tmp/LLaMA-Factory-main/data目录下
  • 数据集类型：包含多种任务数据集如alpaca_zh_demo.json（中文示例）、dpo_zh_demo.json（强化学习技术DPO数据集）、kto_en_demo.json（强化学习技术KTO数据集）等
• 数据集相关参数说明
  • 注册文件：必须通过data_info.json文件注册数据集才能使用
  • 核心参数：
    • hf_hub_url：Hugging Face数据集仓库地址（优先级高于script_url和file_name）
    • ms_hub_url：ModelScope数据集仓库地址（优先级高于script_url和file_name）
    • script_url：本地数据加载脚本路径
    • file_name：本地数据集文件/文件夹名称（当无上述参数时必须指定）
    • formatting：数据集格式（默认alpaca，可选sharegpt）
    • ranking：是否为偏好数据集（默认False）
    • subset：数据集子集名称（如train/valid/test）
    • split：数据集切分方式（默认train）
    • folder：Hugging Face仓库二级目录名
    • num_samples：使用样本数量（默认全部）
  • columns配置：
    • 作用：定义字段映射关系（如prompt默认对应instruction字段）
    • tags配置：用于sharegpt格式，定义角色标签映射（如role_tag默认对应from字段）
• 数据集加载原理
  • 加载流程：
    • 在web UI选择数据集名称（如identity）
    • 系统查询data_info.json获取该名称对应的配置
    • 根据file_name定位具体数据文件（如identity.json）
    • 读取数据并显示在预览界面
  • 数据来源：
    • 可以是本地文件（通过file_name指定）
    • 也可以是远程仓库（通过hf_hub_url/ms_hub_url指定需要下载）
• 数据格式要求
  • alpaca格式：
  • sharegpt格式：
    • 基于对话轮次的结构
    • 需要定义messages、role_tag等字段
  • 格式转换：
    • 必须将原始数据转换为上述两种格式之一
    • 可通过Python脚本实现格式转换（示例见00:36:37.jpg）
• 注意事项
  • 必填字段：必须正确定义columns映射关系，否则无法识别自定义字段
  • 本地优先：推荐使用file_name直接指定本地文件路径
  • 数据混合：可通过调整不同数据集比例实现能力平衡（如50%代码数据+50%金融数据）
  • 格式严格：只支持alpaca和sharegpt两种格式，必须提前转换

三、大模型微调数据集格式详解

1. alpaca格式

• 核心字段：必须包含instruction、input、output三个字段，其中instruction是用户指令（必填），input是用户输入（选填），output是模型响应（必填）
• 字段映射：在dataset_info.json中可通过columns配置字段别名，如"prompt":"instruction"，"query":"input"，"response":"output"
• 特殊字段：
  • system：系统提示词（选填）
  • history：历史对话记录（选填），格式为["第一轮用户指令","第一轮模型响应","第二轮用户指令"...]
• 数据处理：实际使用时instruction和input会被拼接成完整输入，因此两者只需存在一个即可
• 构建原则：不需要的字段（如system/history）必须从columns和tags中移除，否则会因字段缺失报错
• 典型示例：
  • 指令："识别并解释给定列表中的两个科学理论：细胞理论和日心说"
  • 输出包含细胞理论（生物科学基础理论）和日心说（太阳系模型）的详细解释
  • 多轮对话示例可通过history字段实现

2. sharegpt格式

• 核心特点：专为多轮对话设计，但同样支持单轮对话
• 基本结构：
  • conversations列表包含对话轮次
  • 每轮对话包含from（human/gpt）和value（对话内容）
• 扩展字段：
  • system：系统提示（选填）
  • tools：工具描述（选填）
• 字段映射：
  • role_tag：标识发言者身份（默认"from"）
  • content_tag：标识内容键（默认"value"）
  • user_tag/assistant_tag：标识用户和助手角色
• 注册配置：
  • file_name指向实际数据文件
  • formatting必须设为"sharegpt"
  • columns需正确映射数据集中的键名
  • tags需配置角色标识和内容键
• 使用技巧：
  • 若不需要system/tools，需从配置中移除对应字段
  • 字段名修改需保持dataset_info.json与数据集一致
  • 建议优先使用原生字段名减少配置复杂度

3. 两种格式对比

• alpaca优势：
  • 结构简单，适合指令微调场景
  • 通过history字段也可实现多轮对话
• sharegpt优势：
  • 原生支持多轮对话，结构更清晰
  • 提供system和tools字段，适合复杂交互场景
• 选择建议：
  • 简单指令微调优先使用alpaca
  • 对话系统和工具调用场景使用sharegpt

四、知识小结