大模型微调的100个关键点（二）数据篇：数据多样性、数据生产、数据飞轮、专项数据

大模型面试

已于 2024-10-26 17:59:00 修改

阅读量1.9k

点赞数 48

文章标签：人工智能 AI大模型大模型 LLM 大模型微调 ai agi

于 2024-10-19 08:45:00 首次发布

本文链接：https://blog.csdn.net/Code1994/article/details/143061341

版权

二、数据篇

分析数据和清洗数据是 sft 工作者的 90% 的工作量。

1、数据多样性

经历了一年多的磕磕绊绊，目前的 LLM 从业人员大多都会认同：sft 训练数据的核心是数据多样性和数据质量，数据数量并不重要。

数据质量就不谈了，prompt 可以不那么严谨，能看懂就行，但 answer 是尽量一个标点符号都不要有错误的，该中文引号就中文引号，该单引号就单引号，该把 GPT4 啰哩啰嗦的回复精简一下就精简。

我们重点说说数据多样性。即使到了今天，也没人能定义清楚说怎样的一份训练数据叫做数据多样性足够好。我们能做的只能是从先验的角度，把模型能遇到的各种任务类型都让它见一次。从个人经验来说，我认为数据多样性主要包含两个维度，“数据用途”和“数据形式”。

先说数据用途，也就是 task_type，可以结合这几个思路进行数据收集：

OpenAI 官网列出了 ChatGPT 擅长的所有任务项，诸如翻译、emoji 聊天……之类的。我们就每个任务项都想办法来一点数据，照着尖子生的作业抄；
LLM 毕竟是个语言模型，传统的每个 NLP 模型它都应该能胜任，那就把什么 NER、机器阅读理解、意图识别等传统的 NLP 任务也给模型补充一点，如果已有类似任务就不补充了。训练数据也很好搞，传统 NLP 数据集质量都很高，直接拿来用就行；
参考业务需求，下游业务需要某个特殊场景的任务，那就让 sft 阶段提前见一见，这种数据的典型代表就是过年前给模型灌一些对春联、猜灯谜的的数据。只要数据质量没问题，一般都不会破坏模型能力；
……

重点来了，每一条 sft 训练数据必须要 task_type 类型， 千万别搞大杂烩，否则对后续的 case 分析简直是灾难性的伤害。在实际工作中，双层 task_type 都很常见，比如“逻辑推理 - 常识推理”，“逻辑推理 - cot 多步骤推理” 这种。至于每种 task_type 的数据量，别搞平均主义：难 task_type 酒数据多点，简单 task_type 就数据少点，也要结合自己的 base 模型能力动态调整。

task_type 的划分就是 sft 数据最重要的基建工作，没有之一。

我们还需要从数据形式的角度来兼顾数据的多样性：

prompt 表达方式多样性，不要千篇一律的“把中文句子 A 翻译成英文”，也要适当有一些“我在英国旅游，我现在需要向路人问路，我想表达 A 的意思，该怎么说”，“我是一个英文老师，我需要向我的学生讲解句子 A 用英文怎么写，请你用最正宗的表达方式帮我完成。”这么做的目的是防止模型只认识 prompt 中的几个关键 token，进而导致训练过拟合或者泛化性变差；
prompt 长度均衡，既要有短数据，也要有长数据，避免模型的 attention 退化到无法聚焦长 prompt。长数据还不能是字面意思的长，要有那种关键信息藏在开头 / 中间 / 结尾的各种数据场景，避免模型在训练时偷懒，只对 prompt 的起始 token 或结束 token 有 attention；
answer 长度均衡，不能让模型没出输几个 token 就停止，适当的有一些语料让它学会输出尽量长的 answer，否则模型会很难 follow “不少于2000字” 这种指令；
多轮聊天的切换 topic 能力，也就是说，有的数据当前 query 是和 session 有关系的，有的数据则是当前 query 和 session 毫无关系，要让模型自己学会判断 query 是否和 session 有关。类似的数据还要有 system 是否生效，有些数据 system 是个摆设，有些数据的 answer 则和 system 直接相关；
answer 分布的多样性，这最重要，千万别总共一万条训练数据，一千条数据的 answer 都说同一句话，answer 可是算 loss 的，太单一的话会严重让模型过拟合；
……

概括起来，所有的数据形式多样性都可以总结为一句话：数据形式不能让模型找到规律，关键信息在 prompt 中的位置分布要足够随机。目的是避免模型在训练时退化，只聚焦于某些或某些位置的 token，而不是聚焦于完整的 prompt。模型和人一样，骨子里都是有偷懒倾向的。

2、数据生产

生产 prompt

说实话，我已经不太记得通用模型的 prompt 是怎么造的了，那都是去年的工作，感觉当时都是直接翻译英文数据集的 prompt 并重新标注完成的。印象里，斯坦福有一个 self-Instruct 的工作，给每个 task_type 准备一些 seed prompt，然后随机采样 seed，在喂给一个能力很强的 pretrain 模型，让它基于这些 seed 问题再续写出一些问题。其实也不必是 pretrain 模型，GPT4 模型的指令 follow 能力已经足够强了，让它基于一些 seed 问题直接仿写出一些 prompt 也是可以的。

今年的话，应该有很多现成的 sft 训练集，或者是 nlp 训练集，想个办法到处搜刮一下，然后简单筛选下质量就行，反正我们只要 prompt，并不要 answer。最近讨论的比较热的“合成数据”，基本也都是各种启发式规则造 prompt，可以重点留意一下。按照我前文中介绍的数据多样性，去搜集不同 task_type 的数据集集合，然后适当做做改写。实在是找不到合适的 prompt ，就自己动手写一点，answer 写不出来，prompt 还能写不出来吗？

特别要注意，收集或设计 prompt 的时候一定要结合实际情况，不要指望模型一次性写一篇万字爽文，这种事情连人都做不到。我们要把比较困难的任务提前拆解好 prompt ，比如：

prompt1 ：请设计一个重生故事的大纲，大纲包含“父母重男轻女，女主高考状元，弟弟彩礼”等要素；
prompt2 ：请基于给定的故事大纲，扩充内容，生成一篇不少于多少字的文章。

LLM 只是知识量比人多，而不是知识掌握度比人精细。如果普通人做起来都费劲，那这个 prompt 大概率是需要拆解的，这在“利用 sft 后的模型去对接业务”时格外重要。

生产 answer

GPT4 is all you need，这里的 GPT4 不仅仅是字面意思上的 GPT4，还可以理解为 good model 的意思，指的是利用一个效果好的模型来生产 answer。

不在乎成本，就选 GPT4 / Claude 3，用过的人都说好；
在乎成本，就在自己的机器上部署 Qwen_72B / deepseek_MOE，部署过的人都说好；
llama 系列的模型就算了，它的中文能力，体验过的人都说不好；
文心 / 豆包等效果不如 GPT4 的闭源模型，属于品味之选，为国产大模型助力，点赞。

这里需要注意，你一定要知道你喜欢的模型适合用什么 prompt，提前在 ChatGPT 的 playground 上多测一下，找到模型回复效果最好的 prompt，该加 few_shot 就加 few_shot （few shot 最好有一个种子池，不然模型的回复会比较单一），访问 GPT4 的 prompt 并不等价于喂给模型的 prompt。

然后，我们说最实用且最经济的一个方法：训个小模型，这里再次搬出万能公式：小模型 + SFT ≈ GPT4 + zero_shot / few_shot / cot（复杂指令和逻辑推理可能不行）

开卷考试就是这么无解，小模型知道考卷是什么，然后只学什么，就是能考出来好成绩。对于某种特殊需求的 task_type，我们利用 GPT4 生产一千条 answer，然后去训小模型，再利用小模型去预测出上万条数据，这个方法真的十分非常相当的好用。特别地、利用 GPT4 生产数据的时候，由于模型不 follow 格式，数据可用率大概只有 70% 左右，但是利用自己训的小模型生产数据，那可是 100% 的 follow 格式。

值得一提的是，任何模型在预测的时候，有 cot 确实比没有 cot 效果好很多，尤其是分类任务。这很容易理解嘛，直接说答案肯定不如分析完每个选项再说答案靠谱。我前面提到过，实际工作中，出于耗时的考虑，可能不会用 cot 来训模型，但是数据生产的时候，为了保证回复质量还是应该让 GPT4 用 cot 的方式进行回复，我们在训自己的模型的时候，省去 cot 环节即可。

最后，苦力还是要做的，GPT4 也好，自己训模型也罢，还是会出现出现数据质量不可用的情况，这时候必须要写规则，或者通过肉眼看来做个校验。数据去重环节也得做，因为一个模型针对一种 task_type 生产出来的数据，同质化十分严重，一定要避免 answer 过于相似的情况发生，实在看不过来就大批量剔除生产的训练数据吧。还是那句话，sft 数据要的是质不是量。

小结

数据质量就是 sft 工作最核心的内容，数据生产工作一定不能当甩手掌柜，把 excel 给到标注同学后，等他们标完看都不看就直接拿来用。有时候，把想办法“造数据/ 洗数据”的时间拿来手动标数据，工作早做完了，还能加深自己对数据的理解，所以不要把事情复杂化，也不要排斥去做那些所谓的“脏活”。

prompt 的表达方式，answer 的回复风格，训练者一定要烂熟于心。

3、数据飞轮

模型的上线不并代表着 sft 工作的结束，它反倒代表着 sft 真正工作的开始。只有到了这一刻，我们才开始接触“最真实的用户 prompt”。

前面说了，prompt 的生产是需要有 seed 种子的，也就是终归是有限的，但用户的脑洞是无限的啊，用户的 query 就是我们的候选 prompt 数据集。尤其是多轮聊天数据，自己生成的多轮对话数据，通常都默认模型回复的是正确的，用户会 follow 模型的回复。但线上可不是这种情况，你聊你的，我聊我的是时有发生的事情。

以代码任务为例，我让 GPT4 模型给我写个代码，它写了，我复制粘贴加执行，然后报错了，我把报错复制粘贴发给 GPT4，它修改了代码，我又执行还是报错 …… 重复了这个流程4、5 轮之后，它写的代码终于执行成功了。显然，我和模型的这 5 轮对话数据，就是最好的多轮理解 + 代码生成数据，但它几乎没有任何能标注出来的可能性，只能靠捞用户日志来获得。

不仅如此，用户日志往往还配了“点赞 / 点踩”的选项，甚至还能为 dpo / rlhf 生产数据呢（一定要清洗，这种数据很脏，我朋友说他每次都是反着点的，就是故意要污染 OpenAI 的训练数据）。

用户的 prompt 天然比我们自己准备的 prompt 复杂，我们自己的 sft 训练集可能就是让模型翻译一个句子，但是用户的需求可不这么简单，用户会让模型把翻译后句子的某个单词换一个表达方式，或者是提问这个句子中某个的单词是什么意思。因此，基于用户 log 生产的训练数据，是很适合培养模型的话题转移能力，自我纠错能力，坚持己见能力，结合新需求重新改写答案的能力，等等。

只有把“定期拉取用户日志，利用规则筛选有价值的 prompt，访问 GPT4 获取答案，加入新数据更新模型”这样的数据飞轮 run 起来了，我们的 sft 工作才进入到了一个良性循环状态。

这里再额外说一个东西，我们的训练数据最好有一些“鲁棒性数据”：也就是 answer 很正常，但 prompt 表达很差劲的训练语料。prompt 差指的是，它或者是有错别字，或者是话没说完整，亦或者是中文英文拼音夹杂着表达。不用担心会破坏模型效果，毕竟 prompt 根本不算 loss，这么做的目的是适应线上用户的糟糕表达，没有一个用户会希望听到“不是我们的模型不行，而是你 prompt 写的不行”这种观点（我试了一圈，糟糕 prompt 的理解能力，感觉国内模型和 GPT4 的差距挺大的）。

鲁棒性数据可以直接从线上拉取，也可以手动修改原本的 prompt。切记给这类数据打上一个专属标签，千万别让新人看见之后直接给当成脏数据给清洗了

4、专项数据

所谓专项数据，也就是我们老生常谈的 RAG、长文本、Agent、复杂指令、function_call 等 sft 数据。这些 sft 的进阶任务，在训练上几乎没有任何额外的技巧（除了长文本训练要学会变 rope 基底和 sequence_parallel），它们所有的工作难点一半在数据生产，另一半在工程开发，而后者和算法同学也没啥太大关系。

既然这些专项都是数据工程，那就不要把它们想的那么高大上，大胆的尝试吧。这里我针对每个专项简单介绍两句它们是什么，如果想更深入的了解还需要去实操，遇到几次瓶颈也就会了。

RAG

rag 的核心工作在于建库，知识库检索的准确性决定了这个工作的上限。此外，rag 需要外挂两个模型：

知识 / 聊天二分类模型，用于判别该不该做 rag。不要纠结说自己的模型知道世界最高山是什么，这个知识不用做 rag。你根本没办法测出来哪些知识是模型具备且正确的，所以是知识问题就必须做 rag；
传统的 IR 模型，快速从库里面进行检索出候选候选文档，没太多说的，老 NLP 技能了。

rag 的训练 sft 数据构造主要有几个细节需要留意：

检索内容为空的时候模型会怎么回复，别让它自由发挥出一些奇怪的结果；
检索内容相互矛盾的情况，别让他只盯着第一条 / 最后一条的内容回复；
检索内容和 query 完全无关的情况，也是需要让模型见过，防止出奇怪的结果；
检索内容错了。那就让模型照着错的答案念，千万别想着让模型自己判断 rag 的知识和自己的知识谁更正确。我们做 rag 的大前提就是默认“数据库知识准确率高于模型自己具备的知识”。这种取巧心理很容易把模型搞迷糊，到时候模型不 follow rag 内容就麻烦了。

Agent / function_call

我个人喜欢把 agent 和 function_call 理解为同一个东西，后者是前者的主要实现形式。实现起来真的也没什么复杂的，就是在 system 里加上一句这样的表达：“遇见数值计算任务你就输出 <special_token> + 调计算机”，然后再构造类似的数据就行了。

也就是说，在我们的训练数据里，除了有system，user，assistant 之外，还要有“调计算机”，“计算机返回结果”这两个轮次。如果需要其他的 function，就在 system 里写，在训练数据里补充对应样本。

我们团队的 agent 主要技术负责人，绝大多数时间的工作就是在培训数据标注同学，不是在对标准就是在对 case。可以说，数据就是 agent 最核心的内容。

我之前咨询过这个 agent 负责人，他给我说刘知远老师的面壁智能团队，是这个方向的主要贡献者，感兴趣的同学可以去留意下他们的工作，有几篇蛮经典的论文。

长文本

字面意思，模型能处理的 token 可长了，那怎么实现呢？

训练上利用 ntk 外推：增大 rope 基底，找一些长文本数据让模型适应新基底（我一直不太理解，为什么只需要一点点语料就能让模型适应新的基底，有没有数学大佬看见了科普一下）。因为 attention 的计算量和数据长度呈平方关系，所以显存会不够用，训练的时候要使用 sequence_parallel 技术。

数据的话，想方设法构造长文本理解数据吧，不能是短数据 concat 的，前面说了模型有偷懒倾向，所以我们需要让模型不知道候选答案会出现在 200K prompt 的哪个位置。paper 数据，书籍数据，甚至是 RAG 数据都是比较好的长文本数据胚子。

简单的长文本任务就是“背密码”，随机把密码插入到 200K 文本的任意一个位置让模型来复述；
复杂点的长文本任务就可以是让模型概括 paper 的 instruction 内容，让模型列举出所有林黛玉出场的章节；
挑战性的任务则直接让模型去算林黛玉的出场次数。

长文本往深了做是很有学问的，和 agent 一样有很多工程上的工作，我没做过就不瞎分析了。kimi 在这一方向上做得不错，同为清华系，希望它能和面壁 / 智谱一样大方点，多纰漏点技术细节吧。

复杂指令

复杂指令通常指的是“prompt 里包含了非常多的限制”：既要不少于多少字，又要在什么什么场景下插入 emoji，说话还要押韵，时不时还要模型自己输出一些 special_token ……

具体怎么做，说实话我也不是特别知道，我就是一股脑的堆 sft 数据，但我之前的一个同事好像在用 rlhf 来解决这个问题。这个怎么说呢，目前的技术路线还不明晰，我个人觉着做好复杂指令必须要借助 cot 或者自我纠错能力。模型在 next_token_prediction 的时候，很难找到一个完美 token 满足所有的限制条件，所以要么提前 cot 打好草稿，要么让模型意识到“已经输出的结果不可能再满足某个限制条件”时进行纠错。所以我觉着，o1 的技术路线可能就是复杂指令的正确解法。

在 o1 的技术路线成熟之前，我觉着硬造 sft / rlhf 的数据，应该也能凑合着应付大多数用户需求。这里分享一个造数据的小技巧：先射箭，再画靶。

意思就是：你搞了一个很复杂的 prompt ，但即使是 GPT4 的回复，也没有 follow 所有的限制，那怎么办呢？重写答案是很麻烦的，所以就直接去修改 prompt。原本的 prompt 要求模型输出不少于 200 字，实际上只输出了 189 个字，那就把 prompt 改成不少于 180 字（很多复杂指令模型模型根本无法精准回复，限制输出字数这种本来就是学个大概，没必要特别认真，改改 prompt 凑合着用就行了）。