很多人第一次接触大模型微调第一反应是卡在代码上LoRA 怎么改、显存够不够、推理框架用哪个。我后台收到过不少类似的问题但聊到最后几乎都会绕到同一个真正的瓶颈——数据。模型架构基本是公开的训练框架也成熟了真正让模型拉开差距的是你喂给它什么内容。大模型学习这件事最难也最值得花时间的部分其实是搞清楚 AI 学什么数据以及这些数据怎么决定它能有多聪明。这话不是我拍脑袋说的。我早期做过一个很蠢的实验拿了几万条从各种渠道爬来的问答文本没怎么清洗就丢去微调结果模型是能跑了但答非所问、车轱辘话来回说甚至把脏数据里的广告腔都学了个十足。后来换成一批只有几千条、但逐条人工核对过的数据同样的模型结构、同样的显卡效果直接上了一个台阶。同一个模型换了一批数据表现天差地别。从那以后我养成了一个习惯拿到任何微调任务先别急着写 training loop先花时间把数据翻个底朝天。这篇文章就是我现阶段的大模型学习笔记聚焦在“数据”这条主线上。内容覆盖数据在模型训练中所处的位置、不同训练阶段吃的是哪几类数据、数据质量怎么把控以及我自己实操中积累的一套数据处理和验证流程。想入门大模型或者正在被微调效果折磨的朋友可以参考一下少走一些弯路。1. 大模型的智商上限在喂数据之前就定了一大半1.1 模型结构、算力、数据谁才是真正的天花板业内聊大模型总爱把参数规模挂在嘴边好像参数越大就越聪明。参数当然重要但它只是“可能性的容器”。一个模型的参数量决定了它的容量边界算力决定了你能在有限时间内让模型看到多少数据而数据决定了模型真正从这个世界上学到了什么规律。这三者的关系我用一个不太严谨但很直观的类比来说模型结构好比一个学生的学习方法和大脑容量算力是他每天能用来学习的时间数据就是摆在他面前的学习材料。学习方法好、学习时间长当然是优势但如果材料本身是错的、偏的、重复的那这个学生再努力学出来的东西也是歪的。反过来一份高质量的学习材料哪怕学生资质普通一点也能有扎实的进步。大模型也是这样——架构决定潜力的上限数据决定实际到达的高度。我在实践中的体感是绝大多数个人开发者或者中小团队根本还没到拼架构创新的阶段。大家都在用开源模型、跑差不多相同的微调流程最后效果好坏十有八九是数据工程的差距。这就像同一口锅、同样的火候有人做出来的菜好吃是因为食材处理得讲究。1.2 从 Chinchilla 法则看模型和数据量的匹配关系说到数据量2022 年前后那篇经典的 Scaling Law 研究常被称作 Chinchilla 法则给过一个非常关键的结论模型的参数量和训练数据的 token 数之间存在一个大致的最优比例——大约是 1B 参数对应 20B token。也就是说一个 7B 参数的模型想被充分训练理论上至少要准备 140B token 的数据如果数据不够模型就处在“欠拟合”状态能力发挥不出来。这个结论对普通人的启示不在于要我们真的去准备百亿级 token而在于理解一个普遍规律模型能力不是只靠调大结构而是要和你喂进去的数据量匹配。反过来说数据也不是越多越好如果模型容量有限喂太多低质量数据反而会造成“容量浪费”让模型记住一堆噪音。我在做小规模微调实验时就经常用这个思路来估算工作量。比如想在一个 7B 模型上做领域适配领域内的优质文本如果能有几十万到几百万条当然好但如果只有几万条也别硬凑——把这几万条质量做到极致比漫无目的地爬取百万条垃圾文本更有意义。1.3 为什么说“调提示词”和“换数据”是两码事很多人会问我既然模型能力取决于数据那我是不是可以通过写更好的提示词来弥补数据不足提示词当然有用它能引导模型把已经学会的知识更好地调用出来。但一个扎心的事实是如果模型根本没学过某个领域的概念、术语和推理模式你再怎么提示它也只能靠通才能力硬编。这就好比你让一个从没学过医学的人去答题你可以在题干上写“请运用医学知识”但不会就是不会。所以我的判断标准很简单如果模型输出的内容是你预期的格式不对优先调提示词如果模型输出的内容在事实上是错的、逻辑上不通的那大概率是数据层面的问题该补数据就补数据该清数据就清数据。搞反了这个顺序你会浪费大量时间在提示词上做无用功。2. 大模型训练的三个阶段吃的是三种完全不同的“饭”2.1 预训练数据决定模型的知识底子和语言能力大模型的第一次学习叫预训练目标是让模型从海量文本中学会语言规律和世界知识。这个阶段吃的是通用数据包括网页文本、书籍、论文、代码、多语种内容等等。预训练数据的基本特征是量大、面广、无需太多人工标注因为学习方式是无监督的——模型只干一件事看前面的文字预测下一个字是什么。在预训练阶段数据配比会直接影响模型的“体质”。代码数据占比高的模型逻辑推理能力往往更强数学和科学文本多的模型在理科任务上表现更好而如果某个语种的数据太少模型在该语种上的表现就会明显偏弱。所以开源社区里很多预训练模型发布时会公开一份数据配比说明这份说明比模型结构本身更值得研究。对个人开发者来说从头预训练一个大模型既不现实也没必要但理解预训练数据的逻辑很有价值——它决定了你拿到的基座模型擅长什么、不擅长什么。选基座模型的时候不要只看榜单分数还要看它的预训练数据构成是不是覆盖了你的目标领域。2.2 指令微调数据决定模型能不能听懂“人话”预训练出来的模型像一个满腹经纶但不知道怎么和人交流的学者你问它问题它可能接出一堆相关的文字而不是一句正经回答。这时候就需要第二阶段指令微调也就是常说的 SFT。这个阶段的数据是“指令-回答”的配对样本格式一般是 instruction、input、output 三件套目的是让模型学会遵循人的指令来回答问题。指令微调数据的质量要求比预训练高得多因为它相当于“标准答案”。一条好的指令数据问题要清晰、上下文要完整、答案要准确且符合目标风格。我记得有一次做垂直领域的客服机器人团队从真实对话里捞了几千条记录本以为是金矿结果发现大部分是用户和人工客服来回确认信息的口水话直接拿来微调模型也学会了绕圈子。后来我们花了一周时间逐条改写把口语噪音清理掉把答案补完整再微调效果立刻不一样。这也是新手最容易踩的坑以为数据量越大越好结果拿一堆低质量的问答对去训练模型反而把错误模式固化下来了。指令微调阶段宁缺毋滥绝对是一句真话。2.3 偏好对齐数据决定模型是会“答题”还是“好好说话”经过指令微调的模型已经能回答问题了但它的回答不一定符合人类的偏好——可能是正确的但啰嗦的可能是有用的但态度生硬的甚至可能是有害的。于是就有了第三个阶段偏好对齐常见技术包括 RLHF 和 DPO。这个阶段用的数据是“同一问题多个回答按人类偏好排序”的比较数据模型要学会偏好排名靠前的回答模式。偏好数据决定了模型的“性格”是简洁还是详细是严谨还是活泼是直接给答案还是先解释思路。很多做情感陪伴类应用的团队最大的工作量其实不在模型而在持续生产高质量的偏好数据。模型说什么话让人舒服、什么话让人反感这些都需要通过数据一点点调出来。我见过一个很有意思的产品细节同一款模型用不同风格的偏好数据对齐后用户留存率差了好几个百分点。这就是为什么现在很多团队把“数据飞轮”当成核心壁垒——模型谁都能微调但你积累的偏好数据是别人短时间抄不走的。2.4 三类数据怎么配比才算合理三类数据对应三个阶段但实际项目里不是严格割裂的。如果你只是用开源基座模型做领域微调通常只需要关注后两类指令数据和偏好数据。一个比较稳妥的思路是先准备几千到几万条高质量的指令数据跑通 SFT上线后收集真实用户反馈再筛选出对比样本做偏好对齐。这里有一个实操上的小细节很多人忽略基础能力保持的问题。如果你只用某一个窄领域的指令数据去做 SFT模型容易“灾难性遗忘”原来会的通用知识反而变差了。我的做法是在微调数据里混入一部分通用对话数据比例大概在 10% 到 20% 左右相当于给模型“复习旧功课”的时间。这个方法实测下来能明显减少能力回退。3. 数据质量才是真正的胜负手3.1 质量筛选的常用手段从规则过滤到模型打分决定数据质量高低的不是数据来源有多大牌而是你有没有一套系统的筛选方法。我自己的数据清理流程里质量筛选通常分三层走。第一层是规则过滤。这层最简单粗暴处理的是明显的问题文本比如空文本、纯标点、过长或过短的内容、URL 占比过高的内容、乱码文本、重复字符堆砌等。规则过滤可以过滤掉大部分低质量文本但它解决不了“文本完整但内容错误”的问题。第二层是分类器过滤。训练一个小型的文本质量分类器给每条数据打一个“质量分”低于阈值的直接丢弃。质量分类器的训练数据可以从你已清洗好的高质量语料和明显低质量的语料中各抽一部分做二分类。这一步对处理海量爬虫文本特别有效我试过用几千条样本训练的轻量分类器就能筛掉大量广告、营销号和机器生成的垃圾内容。第三层是用模型辅助评估。对质量要求高的场景我会抽取一部分数据让更强的模型来打分维度包括信息密度、逻辑性、语言规范性、是否含毒等。这一层成本高不适合全量跑但可以用来抽检分类器的效果也可以给规则阈值的调整提供依据。3.2 去重这件事远比你想的重要数据去重是最容易被忽略、但又影响极大的一个环节。爬虫数据里经常存在大量近似重复的文本——同一篇新闻被不同网站转载、同一个问题被反复提问、同一段代码仓库里的 copy。如果不去重模型会在训练时反复看到相同内容导致两个问题一是训练效率低下模型把容量浪费在记忆重复内容上二是模型容易过拟合回答时会不自觉地复述训练集中的重复段落这正是很多人觉得模型“答非所问、像在背稿子”的根源之一。去重不能只做精确去重因为网络文本几乎没有逐字节相同的绝大多数是近似重复。常用的方案是 MinHash LSH 做大规模文本去重先把文本转成特征集合再计算相似度相似度超过阈值的只保留一条。我在一个小项目中试过去重后数据量直接少了将近三分之一但下游任务效果反而提升了。这就是典型的数据减法带来效果加法的案例。有些数据集还会做更细的“质量去重”比如在指令数据集里如果同类问题太多而答案雷同模型会学着偷懒对相似问题给出套路化回答。遇到这种情况我会按语义聚类后做降采样保证数据分布足够多样。3.3 数据配比不同领域的内容该占多少比例数据质量和数量之外还有一个常被忽略的维度数据配比。这里说的不只是预训练阶段的多领域文本比例也包括微调阶段的任务类型比例。我在微调过程中踩过一个很深的坑为了提升模型在某个业务场景的表现我把该场景的样本比例加到了 80% 以上结果模型在这个场景下确实变“专业”了但只要用户的问题稍微偏离这个场景模型的表现就明显下降。后来我意识到这是数据比例失衡导致的“偏科”。模型的训练是一个全局优化的过程领域数据占比过高它会逐渐丢掉其他领域的表征能力。现在我调整数据配比时会先给所有任务做一个简单分类比如直接回答类、推理类、生成类、拒答类等然后观察基座模型在各类别上的基线表现再决定每类的增量数据比例。基本原则是哪类任务基线差就适当多补数据哪类任务已经不错就少补甚至不补。这个思路比盲目堆热门任务的数据要科学得多。3.4 脏数据与数据投毒比想象的更危险数据问题不只是“不干净”这么简单还存在主动作恶的样本。这几年有个词叫数据投毒指的是在训练数据里故意注入恶意样本让模型学习到某些特定触发词后产生错误行为。大模型投毒测试也成了安全圈的热门方向攻击者在公开数据集中藏入少量特殊文本模型训练后平时表现正常但一旦遇到某个触发条件就会输出攻击者预设的内容。对普通团队来说被国家级力量定向投毒的概率很低但被互联网上的恶搞数据污染的风险是真实存在的。如果你从公开渠道爬取语料尤其要小心那些包含大量重复指令、诱导性文本的页面。我的习惯是对来源不明的文本做更严格的过滤并且在上线前用一组包含触发词的安全测试集做巡检看看模型有没有被带偏的迹象。另外数据里的隐私和版权问题也值得留意。个人开发者用公开数据做实验问题不大但一旦要商用就得仔细审视数据来源的合规性。这不是技术问题但处理不好技术白做。4. 一套能直接上手的数据处理实操流程4.1 动手之前先明确任务类型和数据形态很多人问我数据处理的第一步是不是写爬虫我通常会反问一句你要解决的任务是什么大模型微调的应用场景差别很大有些是让模型学会特定领域的问答有些是希望模型按照固定格式输出结构化内容有些是教模型处理某类专业文本。任务类型不同需要准备的数据形态完全不同。我的建议是开工前先写一版数据规范文档哪怕只有半页纸也要写清楚每一条数据应该包含哪些字段正例和负例怎么区分回答长度有没有限制是否需要多轮对话结构以及数据的评价标准是什么。这个小步骤能帮你省掉后面大量的返工时间。我在实践中见过太多团队爬了半天数据结果发现格式不统一、字段对不上最后又回到人工清洗的老路。如果是视觉相关项目也遵循同样的逻辑。像 COCO、VOC 这类公开检测数据集为什么被大家当成基准不只是因为数据量大更关键的是标注规范统一、类别划分清晰、训练集和验证集划分固定。反观很多团队自建的多模态数据图片和文字匹配错位、标注标准漂移数据规模再大也难出效果。数据规范先行的原则放之四海皆准。4.2 清洗与过滤的标准动作流程流程上我一般把清洗分成几个标准动作按顺序执行。第一步是格式统一把 HTML 标签、特殊符号、多余空白处理掉统一全半角符号。第二步是做语言检测过滤掉和目标语言不一致的内容。第三步是规则过滤用前面提到的长度、符号占比、重复度等规则筛掉明显的垃圾文本。第四步是去重用 MinHash 做近似去重这一步放在前面规则过滤之后能减少计算量。第五步是内容层面的筛选借分类器或模型打分层过滤低质量内容。这里列一份我常用的规则过滤清单供参考过滤项常用阈值/规则说明文本长度中文字数小于 20 丢弃太短的内容通常信息量不足标点符号占比超过 50% 丢弃多为符号堆砌或乱码数据重复字符连续相同字符超过 10 个丢弃网络文本中的凑字内容URL 占比超过文本 30% 丢弃大量外链内容质量通常不高乱码检测使用编码检测工具爬虫数据中很常见敏感信息手机号、身份证号等脱敏处理隐私合规的基本要求这套规则不是死的不同领域要微调阈值。做技术文档类数据文本长度门槛可以设高一些做对话类数据长度过长的反而未必好。关键是每调整一个规则都建议先小范围抽样看看效果别一键全量执行。4.3 微调训练前的最后一公里格式化与 token 化数据清洗完还不能直接用要转成模型训练需要的格式。以指令微调为例现在主流做法是把样本整理成对话结构通常是 system、user、assistant 三段的 message 格式再按模型对应的 chat template 拼成训练文本。很多新手在这一步翻车用了 OpenAI 格式的数据却拿 Llama 的模板去拼接训练时 loss 都收敛了推理出来格式乱七八糟。这里有个细节值得提模板内容本身也会被当成训练数据。所以数据处理时不要把 system 提示和模板片段也当成有效内容去评估否则你会对模型的真实能力产生误判。我习惯于把 message 里的各角色内容拆分后独立统计长度和分布这样能更清晰地知道模型实际学到了哪些信息。另一个关键操作是 token 化统计。不同分词器对同一段文本切出的 token 数差别很大这会直接影响训练批次大小和显存占用。在真正开始训练之前我会先对全部数据做一次 token 化统计算出平均长度、最大长度、长度分布直方图然后根据这些数据决定 max length 和批次大小。实测下来这一步能避免大量训练中途 OOM 或者因截断导致的信息丢失。4.4 先用小规模数据做“试吃”再决定要不要全量训数据处理完不要急着上 GPU 全量训练。我先强烈建议做一轮小规模验证从总数据里抽 5% 到 10% 作为试验集在基座模型上做很短几个 epoch 的微调然后用一组固定的评测问题来看效果趋势。这就像下馆子先点几个菜尝尝味道不好吃就换厨子别等一大桌菜上齐了才发现难以下咽。小规模验证主要看三件事第一loss 是否正常下降如果 loss 一直在高位震荡可能是数据格式有问题或者标签错位第二抽样看模型输出确认回答风格是否符合预期第三跑一遍评测集看关键指标相比基座模型是否有提升或者回退。我自己的一套做法是准备两个评测集一个是公开的通用评测集用来检测模型能力有没有整体下滑另一个是业务自建的问题集50 到 100 条就够覆盖各种典型场景和边界情况。小规模验证跑通之后再上全量数据这样能把错误成本控制在最低。4.5 别忘了版本管理和数据备份数据处理是个反复迭代的过程今天觉得某个规则合理明天跑了评测发现效果变差了很可能就要回滚。所以数据版本管理不是加分项是必需项。我的习惯是给每个处理阶段的数据集一个带版本号的命名比如 raw_v1、clean_v2、dedup_v3同时用一份简单的清单记录每个版本的处理参数和生成时间。数据备份也是同样的逻辑。清洗和去重是不可逆操作一旦你后来发现自己把某个重要字段过滤得太狠或者去重阈值设错了没有备份就只能重新跑一遍流程浪费时间不说可能原始数据源都变了。我现在在本地做实验时都保留一个原始数据的只读副本任何处理都不直接修改它而是生成新版本。数据存放在机械硬盘或者移动介质上时备份更要谨慎macOS 系统日志里那些读写异常往往就是存储介质出问题的前兆重要数据多存一份到不同设备不吃亏。5. 常见问题排查与避坑实录5.1 微调后模型“变傻”了先查这五个地方做微调最怕的就是模型没变好反而变笨了输出重复、答非所问、甚至说胡话。遇到这种情况先别急着改模型超参数按下面的顺序排查数据问题。第一查数据格式和模板是否匹配。确认 message 结构和 chat template 拼接后和训练代码用的一致这一步能解决相当比例的“模型乱说话”问题。第二查标签一致性。检查 assistant 回答里是否存在错别字、截断、错误代码等模型会忠实地学习你给它的错误答案。第三查数据重复度。如果一条数据在训练集中出现了很多次模型会过拟合这条数据回答时就容易反复输出相似内容。第四查数据分布是否偏科。上一节说的配比问题模型在某个领域特别强、其他领域断崖式下跌大概率就是这个问题。第五查学习率和 epoch 是否过大。数据量小时尤其容易过拟合小数据配合大 epoch相当于把数据背下来了而不是学会能力。5.2 指令数据里常见的“隐形坑”指令数据看着简单实际有很多不容易察觉的问题。最常见的三类我分别说一下。第一类是“指令和答案不匹配”。有时候数据来源是文档片段你被强行包装成问答对模型学到的其实是某种“强行关联”结果一到真实场景就会胡说。第二类是“答案过长或过短”。如果训练集里全是长篇大论的回答模型就会啰嗦如果全是简短的答案模型又可能缺乏解释力。训练数据的答案长度分布应该和你希望的产品形态一致。第三类是“负例太少”。很多时候模型不敢说“不知道”是因为数据里只教了它怎么答没教它什么时候该拒答。在数据里适当加入一些“无法回答”的样本让模型学会承认知识边界反而能提升可信度。另外一个容易被忽略的点是数据里的“隐含偏见”。模型会从训练数据里学习到各种统计关联包括社会偏见。如果你发现模型的输出有某种倾向性的刻板印象大概率是数据本身就存在这种偏向。要修正这个问题光靠提示词是不行的必须在数据层面做平衡处理。5.3 大模型学习路线上的资源建议围绕数据这条线我梳理一下我自己觉得高效的学习路线供刚入门的朋友参考。第一步先弄清楚模型训练的生命周期预训练、指令微调、偏好对齐、推理部署。不要求你把每篇论文都啃完但要把每个阶段的目标和数据形态搞清楚。第二步找一个开源模型和一套公开数据集完整跑一遍微调流程。数据集规模不用大几千条指令数据就可以关键是端到端体验一遍数据如何变成模型能力。第三步尝试自己构造数据。从真实业务场景或者你自己的专业领域出发写几百条高质量问答体验“人工数据”和“爬虫数据”的效果差异。第四步再回头研究数据清洗、去重、配比这些工程细节。这时候你已经有体感了看工具文档和论文都会更有针对性。如果你手头没有合适的私有数据可以先拿 COCO 等公开数据集练手视觉任务的标注规范和数据组织或者拿开源的文本数据集做清洗和去重实验。工具方面常见的选择有数据处理框架、向量检索工具、去重算法库等不要追求大而全先把手头小规模数据流程跑顺再逐步升级。5.4 长期主义把数据当成资产来经营最后说一点我个人的感受。做模型实验越久我越觉得数据工作不像“一次性的准备工作”更像是在经营一份持续增值的资产。模型结构会更新底座会换新版本但你积累的高质量领域数据、清洗流程、评测集是可以跨模型复用的。换一个更强的基座模型把之前沉淀的数据重新微调一遍往往就能得到更好的效果。所以我给团队的建议一直是对外多花精力迭代数据和评测体系对内把数据处理流程沉淀成可复用的脚本和文档而不是每次项目都从零开始爬数据。数据生产的标准化程度越高后续项目的启动速度就越快。毕竟模型会层出不穷但真正稀缺的始终是那些经过验证的高质量数据以及你从一次次踩坑中建立起来的数据判断力。