很多朋友对LoRA、QLoRA这些训练手段已经玩得很熟了脚本一跑显卡一燃loss曲线嗖嗖往下掉感觉万事大吉。但等模型真正生成的时候才发现满嘴跑火车逻辑颠三倒四、格式错乱、复读机上线——这时候大多数人第一反应是“模型没调好”“学习率不对”“数据量不够”其实真凶十有八九埋在你的微调数据集里。做微调这件事模型架构和训练参数是下限数据才是上限。说得更直白一点大模型就是个“见人说人话见鬼说鬼话”的复读机你喂它什么它就学什么。喂了脏数据就学脏话喂了垃圾格式就学垃圾格式。这一篇作为系列的第二篇计划把数据集制作里最关键的三个环节一次讲透清洗逻辑、格式规范、以及做出“高信息密度”数据集的操作技巧。这篇内容不是我翻了几篇文档总结出来的是实打实跑过多次数据清洗流程、做过多个领域微调之后沉淀下来的经验。这套方法论不只适用开源模型你用闭源API去做fine-tune同样适用。好不废话了直接开始。1. 先想清楚你的数据到底脏在哪里拿到一批原始数据直接开洗是最容易翻车的。我看到太多人拿到数据就咔咔咔写正则、去重、截断一套流程下来数据量少了30%以为洗干净了其实真正的问题纹丝没动。所以清洗的第一步不是动手而是先给数据做一次“体检”搞清楚这批数据的脏点在哪里再去定清洗策略。1.1 指令微调场景下脏数据的几大典型类型我把脏数据粗略分成六类每一类的成因和处理逻辑都不一样混在一起用同一个策略处理一定会误伤。第一类是截断和不完整数据。来源大多是被爬虫半路断掉的文章、OCR识别漏掉换行的图像文本、从某个接口里拉出来后半段丢失的日志。这类数据的特征是开头有模有样结尾突然断在半句话上甚至没有结尾标记。第二类是格式污染。带HTML标签的页面内容、残留的Markdown标记、JSON转义符没处理好、全角半角混排这类数据属于“带病上岗”直接喂给模型会让它在生成时频繁产出无意义的尖括号和语法碎屑。第三类是语义重复。很多人以为严格去重就是判断“完全一样”但真实场景里大量数据是“近似重复”——同一篇新闻被不同网站改了标题同一个代码问题被换了变量名同一个客服对话模板只是换了个用户ID。这些近似重复对微调的危害远远大于完全重复它会让模型牢牢记住某一条数据模板直接引发复读机和套话问题。第四类是低信息密度内容。比如全是语气词和寒暄的对话、重复了十几遍的产品广告语、凑字数的洗稿文章。这类数据本身没有错误但不是有效的学习信号把它放进训练集只会稀释模型的注意力。第五类是敏感信息与隐私泄露。真实业务数据里最容易混入手机号、身份证号、公司内部账号、甚至是某人的姓名和家庭住址。这种数据不光有合规风险还会让模型直接把隐私信息“背”出来这是绝对不能容忍的。第六类是主题漂移。你想微调一个法律问答助手结果数据集里混进了美妆种草帖你想让它做代码生成结果40%是生活闲聊。这类数据从单条看完全正常但放在一个项目里就是巨大的噪声。1.2 给数据做体检别凭感觉用统计说话清洗之前我会先写一个快速统计脚本把下面的指标跑出来做到心里有数。字段级别要统计总条数、字段缺失率、每字段的平均字符数和分位数、最大最小长度。内容层面要统计包含URL的条数占比、含HTML标签的占比、含占位符如“TODO”“lorem ipsum”“待补充”的占比、重复文本的占比。这个阶段不需要跑任何模型用基础的正则和哈希就能完成。一个非常管用的体检项是“字符类型混合度”。可以计算每条数据里中文字符、英文字符、数字、标点、emoji各自的比例。如果你发现某一条数据只有英文没有中文但你的目标模型是中文模型那这条数据的语义采样很可能是从英文源未经翻译直接扒下来的质量堪忧。同理如果某条数据全是大写字母多半也是机器人生成的。做完这一步你已经知道该在哪个方向重点下刀了。2. 数据清洗流程规则优先模型兜底以前我迷信“高阶方案”总想着用embedding聚类去清洗后来发现大多数场景下性价比最高的是一套多级规则的组合拳。规则跑得又快又稳可解释性还强真正卡住的个例再交给模型打分处理。下面按执行顺序介绍整套清洗流水线。2.1 第一级格式与字符层清洗这级清洗处理的是“一眼就能看出不对”的问题目标是把所有文本统一成干净规范的底料。对抓来的网页数据先把HTML标签全部剥掉用标准库里的HTML解析器处理而不要靠肉眼正则去匹配标签。正则匹配HTML极其脆弱遇到嵌套标签和注释就会漏。剥完标签之后再清除Markdown残留符号特别是无意义的#、*、[]()结构和不可见的控制字符。这里有一件很容易被忽略的事——统一空白字符。全角空格、不断行空格U00A0、零宽空格U200B都是视觉上看不见、但会被tokenizer切成独立token的“幽灵字符”。这类字符进了训练数据模型就可能在生成时莫名其妙输出一个空白token。我习惯把所有字母统一转成小写除非是代码场景代码场景要保护大小写敏感把所有中文标点统一成全角把所有英文标点统一成半角。这一步能在后续清洗时大幅降低匹配难度。注意如果任务是代码生成这一步就不要做大小写归一化否则代码直接废了。2.2 第二级长度与完整性过滤做完字符层的清洗马上做结构化过滤。长度过滤的阈值取决于你的模型上下文窗口和任务形态。如果你微调的是128K上下文的模型但单条数据平均只有几百字符这显然不太合理反之如果输入输出加起来远超训练时的最大长度就要做截断或过滤。经验法则是保证训练序列长度覆盖目标长度的头部到尾部既要有短平快的简单问答也要有中等篇幅的分析题还要有接近上下文上限的长文任务。长度分布偏了模型在生成不同长度内容时就会出现明显的“舒适区”偏移。完整性过滤的核心是检查“该有的结构是否闭合”。对话数据有没有成对的role和contentJSON格式的字段是否完整HTML有没有配对的闭合标签代码块有没有结尾标记一个简单有效的方法是写一个“关键结构标记必现表”比如解析式JSON必须能成功parse对话数据必须包含至少一轮user和assistant多轮数据必须按顺序排列。2.3 第三级语义去重难就难在“近似重复”完全重复用哈希表就能秒去近似重复才考验功底。业界主流的方案大致有三个梯度首先是基于n-gram与Jaccard相似度的粗筛。把文本切成字符或词级别的n-gram中文建议用2~3字符算两两之间的Jaccard相似度超过阈值就认为是重复。优点是可以处理乱序和微变缺点是阈值需要反复调太高漏掉重复太低误删优质内容。其次是MinHashLSH。这个方案适合十几万条以上的大规模数据集能做到亚线性时间找到“候选重复对”商用场景里用得非常多。实测下来对客服聊天、百科词条这类模板化很重的数据召回效果不错。第三是embedding聚簇。用文本编码模型将每条数据转成向量然后聚类在每个簇内人工抽检。这个是“兜底方案”它对语义相同但表达完全不同的重复特别有效但计算成本比前两者高一个量级。在实际执行时我的顺序是先用准确匹配去重再用n-gram Jaccard去重最后用embedding聚簇抽检。三者叠加能把无效重复数据降到最低。这里还有一个取舍原则如果任务是让模型输出短答案重复的判断条件可以放宽松一点如果任务是生成文章、代码、报告这类长内容判定必须从严因为长文本里模型很容易学出复读机腔调。2.4 第四级质量打分与模型兜底规则法处理完脏数据之后剩下的“看起来没问题但总感觉不对劲”的数据需要让模型来打质量分。我的做法是构造一个统一的prompt模板给每条数据打分并说明理由。给模型的评分维度一般是包含有效信息与否、语言是否通顺、逻辑是否清晰、是否存在于目标任务领域无关的内容、是否有明显幻觉。最后筛选规则是只保留综合得分超过阈值且没有任何维度得低分的数据。这套方案我用了很久可靠。注意评分模型的选型不需要很大7B级别就足够如果数据量实在太大可以先随机抽样1000条打标签然后训练一个小分类模型做全量推理。用规则先筛掉最差的那批再做模型评分能让评分聚焦在“边界质量”上误杀率明显下降。2.5 清洗无法回避的安全底线前面说了这么多清洗逻辑最后必须强调一次安全红线。首先是隐私与合规数据必须无死角清除。手机号、身份证号、银行卡号、真实姓名、家庭住址、企业内部网络地址全部用正则做强制过滤并且过滤范围要在清洗报告的“日志”里留痕。不能只把字符串里的明文删掉还要检查是不是以不同格式出现的比如手机号中间加空格、身份证最后一位被替换成X。其次是潜在有害内容过滤。比如自伤自残、歧视言论、恶意攻击相关的语料即便你微调的是“什么都聊”的助手也不建议主动学习这类模式。可以通过维护一份敏感词表评分模型双保险做到判断和删除都有据可依。提示我强烈建议清洗完的数据再用人工抽检一遍全量抽检不现实的话就抽样1%逐条看。这个环节省不得规则永远会有盲区。3. 格式规范模型学的是“格式”不只是“内容”深度学习fine-tune里有一个很核心的概念——模型学的其实是数据的分布规律。在指令微调里分布的载体除了文字内容本身还有你组织这些文字的结构模板。如果训练时你的template是A推理时你用的template是B模型的表现会肉眼可见地变差因为它把“回答格式”和“回答内容”捆在一起学了。这也是我做数据集时最关注的事情之一训练和推理的提示格式必须完全一致。3.1 选对数据格式Alpaca、ShareGPT与ChatML现在市面上最常用的三种指令数据格式是Alpaca、ShareGPT、ChatML它们各自适用的场景有别。Alpaca格式是最经典的instruction-input-output三元结构适用于“单轮指令问答”。优点是结构简单、转换成本低缺点是表示多轮对话和带系统提示的场景时有点捉襟见肘。ShareGPT格式是多轮对话主流格式conversations数组里每项包含 fromuser或gpt和value。优点的表达能力强适合多轮对话和Agent轨迹。缺点是如果轮次很多训练序列很容易超出截断窗口就要做“轮次级截断”而不是“token级截断”。ChatML格式是带特殊token标记的模板结构显式地用|im_start|和|im_end|把system、user、assistant分开。它的最大优势是在预训练阶段就让模型见过非常稳定的标记所以指令微调时表现特别稳。三种格式的选择不能光看“哪个方便”核心判断标准是“你推理阶段打算用哪种方式调用模型”。如果你用的框架默认就是ChatML那就别为了省事把数据转成Alpaca。Respect格式一致性永远第一。格式主要特点适用场景缺点Alpacainstruction/input/output三字段单轮指令问答、SFT入门多轮能力弱缺少轮次结构ShareGPTconversations数组rolecontent多轮对话、奇幻角色扮演结构较重长轮次易截断ChatML特殊token标记整个上下文开源模型微调、Agent任务依赖模板完全匹配3.2 训练数据里的系统提示词要仔细设计很多人做微调的时候直接忽略system字段让模型“自然发挥”这样做太随意了。一个经过设计的system prompt是让模型理解“你是谁、你用什么语气回答问题、你有什么边界”最快的方式。我在清洗和构造数据时会对同一个任务故意安排若干组不同的system prompt变体。比如客服助手的数据集system可以是“你是售后客服请耐心简洁地解决用户问题”也可以是“你是技术专家请先复述用户问题再给出步骤化建议”。目的是让模型学会“系统指令改变了回答风格”而不是把某一个固定的system背下来。但实际操作中有一个两难系统提示词全部统一模型容易僵化全部各个不同又会稀释模型对指令的敏感度。我的经验是对80%的数据使用同一套主干system剩下20%使用变体比例保持在接近但不完全固定的状态。实测下来这样的模型在陌生system prompt下表现更稳定。3.3 损失函数计算时微妙但关键的区别格式问题还牵扯到训练时的计算细节多数初学者会在这一块埋坑。指令微调时一般只对assistant的输出计算交叉熵损失对system和user的输入部分做label屏蔽。表面上大家都遵守这个规则但不同训练框架对“哪些token被屏蔽”的实现存在差异。有些框架默认把system也参与loss有些把user的最后一个token也计算进去这都会导致最终的模型更倾向“背诵输入”而不是“学习输出”。我的建议是在跑训练之前先打印出batch里的input_ids和labels肉眼确认一下被mask的位置是否是你真正希望模型学习的输出区域。这个检查5分钟就能做完但能帮你避免整轮训练都学歪了还不自知的情况。另一个让很多人疑惑的点是“要不要在训练数据里去掉了EOS token”。如果训练时把每条assistant输出都以EOS结束而推理时生成代码却不追加EOS模型会在输出结束位置表现出“犹豫”和“重复”。正确的做法是数据里保留EOS推理时也跟随框架处理好停止符二者保持同步。3.4 数据模板归一化的四个要点对已有原始数据做格式规范化我总结了四个要点。第一role字段的值要严格统一user/assistant/system大小写必须一致不要出现“User”“Assistant”“SYSTEM”混用。一旦不一致模型会认为它们是不同的角色在生成时随机切换。第二多轮对话必须保持首尾格式一致例如第一轮是不是一定以system开始、最后一轮是不是assistant的输出这些结构必须是一个模板里严格的规则不要偶尔带不带。第三特殊标记要合理使用比如设置“思考过程标记”或“工具调用标记”时必须要确保最终训练模板和推理模板用的是完全一样的字符串。一个很常见的错误是训练时写“ ”推理时写“[think]”模型完全无法适配。第四文本内可能出现的占位符和换行问题比如用户指令里有代码块代码块里的缩进和代码里可能的括号嵌套不能因为格式清洗给破坏掉。代码相关数据在清洗阶段就要和自然语言数据分开处理走完全不同的流水线。4. 高质量数据集构造技巧数量堆不出来要“设计”出来数据清洗保证的是“干净”格式规范保证的是“一致”但一份好数据集还需要“信息密度高”这就要求在构造阶段主动设计数据的内容结构。我对高质量数据集的定义是五个向量多样性、正确性、一致性、难度梯度、有效信息密度。下面分别拆解。4.1 多样性让模型学会“分类应对”而不是“死记硬背”很多人在自己业务场景里收集数据时会发现大量样本长得很像。做车险问答的问来问去就是“出险了怎么办”“保费怎么算”做代码助手的查询请求全是“写一个排序函数”。这种数据集训出来的模型遇到偏离高频区间的输入就会开始胡言乱语。提升多样性的第一步是“意图盘点”。把业务里的用户问题先人工聚类一遍列出二十个相近意图然后统计每个意图的样本量。如果某个意图样本超过30%就需要对它做下采样同时去扩充其他意图的数据。多样性的本质是让每个合理的输入空间都有足够的覆盖而不是让某一个空间过度饱和。第二步是“句式改写”。同一个任务不要总是用同样的措辞提问。举个例子“帮我写一个Python快速排序”可以被改写成“需要一段快排代码”“Python里有内置的排序方式吗我想自己实现一个”“请用Python实现排序要求时间复杂度O(n log n)”等。在构造指令数据时每一条原始语义建议配3~5种不同表达这是提升指令泛化能力最笨也最有效的方法。4.2 难度梯度从“简单服从”到“复杂推理”都要有如果你的数据集里全部都是“一句话指令一句简短回答”模型可以学会听话但学不会推理。反过来说如果全是推理题模型在普通简单请求上就会表现出“过度思考”和“废话连篇”。一个健康的数据集难度分布应该呈梯形。第一步是简单指令集占20%左右训练目标明确输出可预测目的是让模型建立稳定的指令服从能力。第二步是中等难度任务占50%需要模型整合多个条件回答步骤化比如“给出实现方案并比较两种方法的优劣”。第三步是高难度任务占30%需要长上下文理解、多步推理、自我纠错比如代码调试、复杂逻辑分析。难度分级不一定要人工判断可以让评分模型按“所需推理步骤”1步、3步、5步以上对样本打标。然后按照预先设定的比例从各级随机抽样组合成训练集。这个分级的做法比单纯按长度判断可靠得多因为一段很长的文本可能只是简单的复述而一段200字的内容可能包含了因果推理。4.3 反馈与修正数据高质量数据集不能只有“标准答案”只喂“问题-答案”的样本模型会习惯“一次生成定终身”错了也不会改。想让模型具备“发现自己错了并修正”的能力约束就落在数据上——需要构造修正轨迹数据。一种可行做法是把同一问题设计成多轮第一轮给出一个包含小错误的回答第二轮在不破坏第一轮真实性的前提下指出问题第三轮给出修正后的版本。这样模型就学到了“答案不是静态的可以基于反馈进行迭代”。这类数据在做Agent、客服、教育辅导的时候特别有用。这个思路还能用在“拒绝回答”上。如果模型被问了超出能力范围的问题它应该学会诚实拒绝。数据里要特意构造一部分“无法回答”样本比如“我不知道”“我需要更多信息”“超出我的权限范围”。不喂这类数据模型就会被迫在所有问题上硬编一个答案幻觉率直线上升。4.4 合成数据的使用守则能造但要“验真”普通开发者没法攒到几万条真实高质量语料时让模型造数据几乎是必经之路。但合成数据最大的坑是“幻觉传染”如果老师模型在造数据时就胡说八道学生模型会把胡说八道当成标准答案。我的合成数据守则很简单可验证的做合成不可验证的只做改写。比如代码题、数学题、知识抽取、格式转换这些任务有明确的正误标准合成之后可以用程序校验输出正确性放心用。但像“给产品写一点文案”“这个政策怎么解读”这类开放性问题合成数据就直接当“候选”必须人工审核或者从真实内容里改写原始片段。另外一个降风险的方法是“真实基座合成扩展”。用一条真实业务数据做种子让模型生成该样本的若干变体换领域、换难度、换提问方式再拿回真实数据里校验一遍语义是不是还成立。这样做出来的合成数据既保留真实底料的语感又扩大了覆盖。4.5 配比、采样和规模不要盲目追求“更大”大家普遍关心一个问题“我到底应该准备多少条数据”我的答案是没有统一数字取决于任务的复杂度和模型的规模。指令微调的核心矛盾是“容量”和“泛化”的平衡。对于简单风格转换任务几千条高质量数据可能就够对于需要复杂推理和多场景覆盖的Agent任务十几万条也不算多。更关键的操作是把验证集按“意图类别”分层抽样。这能保证你在评估模型时覆盖到数据集的每一个意图簇不会出现“训练集中90%是问答验证集也90%是问答看起来效果很好实际别的意图一塌糊涂”的假象。采样方面对高频重复的模式做下采样对稀有但有价值的模式做上采样最好还要做“克制的上采样”不要简单重复同一个样本而是通过改写产生变体。直接用一条真实样本复制三遍放进数据集效果比删除它还要差模型会被迫记住那一条的精确表达产生过拟合。5. 实操全过程记录从原始语料到微调数据集理论讲了那么多下面用一个简化的客服语料例子把从原始数据到jsonl的完整流程演示一遍。5.1 用脚本把原始数据变成“可操作格式”假设从业务系统里导出的原始数据是csv文件包含两个字段date和content前者是时间后者是客服与用户的聊天记录。第一步先加载抽取content字段转成JSON数组。import json import re import pandas as pd df pd.read_csv(raw_records.csv) records df[content].tolist() print(f原始条数{len(records)}) # 输出原始条数38520第二步把文本拆成“对话轮次”。客服数据的特点是每条记录可能包含多次切换我需要按发言人的名字切分。def split_turns(text): pattern r(客服|用户)[:]\s* parts re.split(pattern, text) turns [] role_map {客服: assistant, 用户: user} for i in range(1, len(parts), 2): role role_map.get(parts[i]) content parts[i1].strip() if role and content: turns.append({role: role, content: content}) return turns parsed [split_turns(rec) for rec in records] parsed [t for t in parsed if len(t) 2] print(f解析成功并保留完整对话{len(parsed)})这步做完就有了一份可以直接看到“用户说了什么、客服回了什么”的中间结构。这一步容易踩的坑是正则在处理“客服”和“用户”的英文冒号/中文冒号时不稳定所以在解析前已经做了一轮标点归一化全部换成中文冒号作为切分标记。5.2 对每条对话做质量打分解析完之后用规则清洗和模型打分两级过滤。模型打分的方案是把对话转成一篇纯文本描述丢给评分模型让它按前面提到的多个维度打分。def quality_score(turns): # 规则初筛过短、无有效用户问题 if len(turns) 2: return 0.0 if len(turns[-1][content]) 2: return 0.0 # 实际项目中这里接入评分模型给5个维度分别打分 # 简化为示例返回 return 0.9 parsed [t for t in parsed if quality_score(t) 0.7] print(f过滤后条数{len(parsed)})5.3 组装成模型训练格式过滤之后按项目需求统一模板。这里我用ChatML风格作为示例模板。def to_chatml(turns, system_prompt): segment |im_start|sysstem\n system_prompt |im_end|\n for turn in turns: if turn[role] user: segment |im_start|user\n turn[content] |im_end|\n elif turn[role] assistant: segment |im_start|assistant\n turn[content] |im_end|\n return segment |im_start|assistant\n system_prompt 你是业务助理请针对用户问题给出清晰、简洁、可靠的回答。 formatted [to_chatml(t, system_prompt) for t in parsed]注意上面代码里我故意写错了“sysstem”这个单词吗这是我在实际调试时踩过的坑。模板字符串里一个字母的错漏你不会在训练loss里察觉明显异常但推理时模板一拼上模型表现就崩了。所以组装完格式之后一定要打印两三条完整样本从头到尾目测一遍。with open(train_data.jsonl, w, encodingutf-8) as f: for fmt in formatted: f.write(json.dumps({text: fmt}, ensure_asciiFalse) \n) print(写入完成)5.4 清洗前后的数据对比与验收清单数据处理不是糊弄完事一定要能给出前后对比。这里分享我常用的验收清单每一条都对应一个具体的体检项条数变化原始条数、解析成功条数、过滤后条数、最终组装条数要有记录。字段完整性经过完整清洗的数据集不应存在空content、空role、未闭合的特殊token。长度分布输出长度直方图应该覆盖短、中、长三个区间不能集中在某一个峰值。格式还原测试用你选择的tokenizer把样本套用apply_chat_template方法后再解析还原看能否得到原始role和content。这一步能抓住模板里的隐藏空格问题。差分抽检从清洗前和清洗后的数据里各抽出数十条放一起做人工盲测对比看看清洗操作是否真的提升了质量。隐私残留扫描对最终文件再跑一次手机号、身份证、姓名正则确保零残留。6. 实际踩坑与排查实录这一节专门列出做数据清洗和格式规范时最常遇到的问题每条都附上排查思路。6.1 损失正常下降但输出格式乱成一团这基本就是“训练和推理模板不一致”导致的。排查时先检查训练数据里的文本结构再检查推理侧使用的chat template。常见问题有推理时少了一个空格、训练时用的特殊token和推理时不一致、推理侧在开头多塞了一条无关的system。用一个最简单的办法排查把训练集里的正样本完整打印出来对照推理模板肉眼走一遍很快就能定位。6.2 模型变成复读机先确认是不是清洗阶段漏了“近似重复”文本。用MinHash或n-gram相似度在训练集里搜索几条最相似的数据对如果发现高度相似的样本成批出现模型就会把重复模式当成学习信号。另一个原因是长文本占比过高模型在生成大量文本时容易陷入循环这种情况下要适当增加短文本的占比。6.3 数据集中来自某个来源的数据占了60%单独一个来源的数据占比过高会让模型对该来源的风格过拟合。解决办法是在做全量训练前先按来源分组设定每个来源的上限比例我习惯设30%~40%超出部分进行下采样。注意下采样之前先看这个来源的质量如果质量特别高可以保留其在较高级别的配比上限。6.4 截断之后assistant的答案被拦腰斩断训练序列达到max_length时如果你的截断策略是“从尾部截断”那么一条长多轮对话的最后一轮答案可能被完全截掉模型实际看到的输入是不完整的。正确方案是“轮次级截断”优先保留最后一轮完整答案从对话开头删掉部分用户与助手的轮次而不要在中间斩断。如果用的是输入输出分离的训练方式输出部分必须保证完整即使输入牺牲一些长度。6.5 tokenizer不认识模板里的特殊标记直接往数据里塞|im_start|这种特殊token但tokenizer的词表里根本没有它会导致token被拆成一堆未知token碎片。排查方法是打印特殊token的ID确认它们在词表里对应的是单一token。如果不在就要扩展词表或者换一种模型本来就支持的模板。6.6 质量过滤误杀了一批好数据模型打分绝不是百分百可靠的尤其是针对专业性强的领域误杀率会更高。我的策略是“分级处理”打分结果分三档高分直接保留低分直接清除中间分数的样本走人工抽检或者“宽松阈值二次评分”宁可多留一些中等样本也不要武断删除。同时维护一份白名单规则凡是命中白名单模式的样本跳过模型评分直接保留。6.7 快速排查速查表问题表现优先排查方向常用解决手段生成格式混乱训练/推理模板不一致统一chat template打印样本对拍复读机近似重复未去净增加n-gram去重平衡长文本占比隐私泄漏正则漏覆盖或格式化变体补充正则变体二次扫描推理能力差数据集中简单样本过多构造难度梯度扩充推理数据对部分意图失灵意图分布不均衡意图盘点并做上/下采样幻觉高发合成数据未校验引入验证脚本控制合成占比长文截断异常截断策略切坏答案轮次级截断保证答案完整7. 最后分享一点我的实际体验做微调数据集是一个反复迭代的过程不是“洗一次、用一年”。我现在的习惯是每次数据集变更都用“版本号清洗规则文档”记录比如v1.1表示在v1.0基础上去除了低分文本并增加200条难度推理样本。这样当训练效果突然退化时你可以快速回溯到具体是哪一次数据改动影响的而不是在茫茫数据里大海捞针。另一个小技巧是保留一份“原始原始数据”完全不动。所有清洗、过滤、转换操作都在副本上执行不要直接覆盖原始文件。数据处理里最费时间的其实不是写脚本而是“数据改坏了但不知道从哪一步开始坏的”保留各个阶段的中间产物就相当于给自己留了后悔药。我不太建议一上来就追求“完美数据集”。先做一版干净的、格式统一的、覆盖核心场景的初版拿小模型跑通流程看生成样例再针对暴露出来的问题做第二轮增强。一次性想做到十全十美反而容易陷入“永远在洗数据从来没训练”的怪圈。动手做一版数据跑一轮小实验比读十篇文章都管用。祝大家都能喂出一口好数据。
