数据这块干过几年模型训练的人都有一个共识模型能力的上限八成在数据里就定死了。你调参调得再花哨学习率、batch size、warmup 折腾一整天最后发现还不如把训练集里那批脏样本清掉来得实在。而这两年随着 agentic 这套思路铺开合成数据和清洗数据的方式正在发生一个挺明显的变化——以前是写规则、跑脚本、人工抽检现在越来越多团队开始让 agent 自己去造数据、审数据、改数据。这篇就围绕agentic 方式合成与清洗训练数据这条线展开覆盖 SFT、mid-training、RL 三个阶段各自对数据的不同诉求以及怎么用 agent 化的流程把造和洗这两件事串起来。适合已经在做模型微调、正在被数据质量折磨、或者想搭一套半自动化数据流水线的同学。我不打算讲空泛的方法论重点放在为什么这么设计、每一步的坑在哪、参数怎么定这些真正上手才会遇到的问题上。1. 先搞清楚三个阶段到底要什么样的数据很多人一上来就问怎么合成数据但这个问题本身就不完整。SFT、mid-training、RL 对数据的需求差异极大用同一套合成和清洗逻辑去喂三个阶段基本等于白干。所以第一步必须把三者的数据画像拆开。1.1 SFT 阶段要的是格式正确 指令多样SFT监督微调本质是教模型怎么按人类期望的方式回答。这个阶段的数据核心诉求是指令-回复对的格式规范性和任务多样性而不是知识的绝对正确性。原因很简单SFT 主要塑造的是模型的输出风格、指令遵循能力、格式控制能力知识本身在预训练阶段已经灌进去了。所以 SFT 数据的合成重点在于覆盖足够多的任务类型分类、抽取、改写、推理、多轮对话等每条样本的指令表述要有多样性回复要符合目标格式。清洗的重点则是去掉格式错乱、指令与回复不匹配、回复过短或截断的样本。我见过最常见的错误是拿一堆百科式问答去做 SFT结果模型学会了背书但不会听话。SFT 数据里指令的措辞多样性比答案的深度重要得多。1.2 Mid-training 阶段要的是知识密度 领域覆盖Mid-training也叫 continued pre-training 或中间训练夹在预训练和 SFT 之间它的作用是往模型里注入特定领域的知识或者做能力上的预热。这个阶段的数据形态更接近预训练语料——长文本、连续段落、领域文档而不是问答对。它的核心诉求是知识密度高、领域覆盖全、噪声低。因为 mid-training 的 token 量通常比 SFT 大好几个数量级一条脏数据的负面影响会被放大。这里清洗的权重远高于合成去重、去模板化文本、过滤低信息密度内容、剔除机器翻译腔都是重头戏。合成在 mid-training 里更多是补覆盖——某个领域真实语料太少用 agent 基于已有知识生成一批结构化文档来填坑。但要注意合成语料一旦比例过高模型会出现自我中毒这个后面单独讲。1.3 RL 阶段要的是可验证 有区分度RL强化学习通常指 RLHF 或 RLVR 这类对数据的要求最苛刻。它不需要海量数据但每条数据都要能产生有效的奖励信号。也就是说样本必须满足两个条件一是答案可验证有明确的对错或可打分的标准二是难度适中太简单模型全对梯度为零太难模型全错也是零梯度。RL 数据的合成重点是构造有区分度的题目——通过控制难度、增加干扰项、设计多步推理链来制造梯度。清洗的重点则是剔除那些奖励信号饱和或完全无信号的样本。这个阶段数据量可能只有几千条但每一条都要精雕细琢。下面这张表把三个阶段的差异拉平对比一下方便你对照自己的项目定位维度SFTMid-trainingRL数据形态指令-回复对长文本/领域文档问题-可验证答案核心诉求格式规范、指令多样知识密度、领域覆盖可验证、有区分度数据量级万到百万条十亿到百亿 token千到万条合成占比可较高需严格控制可较高但需验证清洗重点格式、匹配度去重、去噪、去模板奖励信号有效性主要风险风格单一自我中毒奖励黑客把这张表贴在工位上每次造数据前先问自己我现在服务的是哪个阶段能省掉大量返工。2. Agentic 合成让 agent 自己当出题人传统合成数据的方式是模板 填充或者大模型批量生成前者多样性差后者质量参差且容易同质化。Agentic 合成的思路是把数据生成拆成多个角色让 agent 之间互相协作、互相挑刺从而在生成阶段就把质量往上抬一截。2.1 多角色协作的基本框架一个比较通用的 agentic 合成框架包含这么几个角色出题 agentGenerator负责根据种子或主题生成原始样本包括指令、问题、上下文。解题 agentSolver负责对生成的题目给出答案或回复。评审 agentCritic负责判断题目质量、答案正确性、难度是否合适。改写 agentRefiner对不达标的样本进行修正或重写。这套框架的关键不在于角色多而在于角色之间的信息隔离。出题 agent 不应该知道解题 agent 会怎么答评审 agent 不应该和出题 agent 共享上下文否则就会出现自己出题自己放水的情况。这一点和对抗生成网络的思路是相通的——只有让不同角色真正独立才能产生有效的质量压力。实际落地时这四个角色可以是同一个基座模型的不同 prompt也可以是不同规模的模型组合。我的经验是出题和改写用能力强的模型解题和评审可以用稍小的模型因为评审主要做的是判断而非生成对模型能力要求相对低这样能显著降低成本。2.2 种子设计合成质量的真正天花板很多人把精力全花在 agent 框架上却忽略了种子seed的设计。但实际情况是合成数据的多样性上限几乎完全由种子决定。你给 agent 十个相似的种子它生成一万条也是十个的变体。种子设计有几个实操要点。第一种子要覆盖任务的维度而非实例。比如做代码 SFT种子不该是写一个快排而应该是排序算法递归结构边界条件处理这样的维度标签让 agent 在每个维度下自由发挥。第二种子之间要有明确的区分度最好用聚类的方式先筛一遍把语义重复的种子合并。第三种子要留出演化空间——好的种子是能长出很多变体的而不是一个封闭的具体问题。我一般会准备两三百个高质量种子然后让出题 agent 在每个种子下生成几十到上百条变体最后通过去重和评审筛掉大部分留下质量最高的那批。这个广撒网 严筛选的比例通常在 10:1 到 50:1 之间。2.3 难度控制别让合成数据全是送分题合成数据最容易出的问题就是难度分布失衡——agent 倾向于生成它擅长的、模式化的题目结果整批数据都是中等偏简单的。这种数据拿去训练模型在简单任务上刷得很高一到难题就露馅。控制难度的做法是在评审 agent 里加入难度打分并且强制要求最终数据集里各难度档位的比例。比如简单:中等:困难 2:5:3。评审 agent 给每条样本打一个难度分然后按分档采样。如果某个档位样本不够就让出题 agent 针对性地补生成。难度打分本身也可以 agentic 化让解题 agent 先做一遍做对了说明偏简单做错了说明偏难多次采样统计正确率正确率在 30% 到 70% 之间的样本就是有区分度的好样本。这个方法在 RL 数据构造里尤其好用因为它直接对应了梯度信号。2.4 合成数据的自我中毒问题这是 agentic 合成绕不开的一个坑。当合成数据在训练集里占比过高模型会逐渐学习到合成数据的分布特征——用词习惯、句式结构、甚至某些固定的逻辑套路导致输出越来越AI 味多样性下降这就是所谓的模型崩溃model collapse或自我中毒。规避的核心原则是合成数据永远不能完全替代真实数据且合成比例要随训练阶段递减。我的经验值是SFT 阶段合成占比可以到 50% 到 70%mid-training 阶段最好控制在 20% 以内RL 阶段因为数据量小、验证严可以放宽但必须保证奖励信号来自真实标准而非模型自评。另外一个技巧是在合成流程里引入真实数据的锚点——定期用真实数据去校准评审 agent 的打分标准防止评审标准随着合成数据一起漂移。这个校准频率我一般设成每生成一万条校准一次。3. 清洗环节agent 怎么判断一条数据该不该留清洗是数据流水线里最枯燥但也最值钱的部分。传统清洗靠规则和分类器agentic 清洗则是让 agent 去理解数据、做判断。两者不是替代关系而是规则做粗筛、agent 做精判的分工。3.1 规则粗筛先把明显垃圾扔掉不管后面 agent 多聪明前面一定要有规则层做粗筛否则 agent 的算力全浪费在明显垃圾上。粗筛的规则包括长度过滤太短少于阈值 token或太长超过上下文窗口的直接丢。字符过滤乱码比例、特殊符号比例超标的丢。重复检测用 MinHash 或 SimHash 做近似去重重复度超阈值的丢。格式校验SFT 数据里指令或回复字段缺失、JSON 解析失败的丢。这一步能干掉 30% 到 60% 的原始数据成本极低。我见过有人跳过粗筛直接上 agent 清洗结果 agent 调用费用翻了好几倍效果还没好多少。3.2 Agent 精判从像不像到对不对粗筛之后剩下的数据才是 agent 发挥的地方。Agent 精判的核心能力是理解语义层面的质量这是规则做不到的。具体判断维度包括指令与回复的一致性回复是否真的回答了指令有没有答非所问。事实正确性回复里的关键事实是否准确这个需要 agent 有知识或能调用检索。逻辑连贯性多步推理的样本推理链是否自洽。信息密度内容是不是车轱辘话来回说有没有实质信息。风格匹配是否符合目标场景的语气和格式要求。实操上我会让评审 agent 对每条数据输出一个结构化的评分包含上述各维度的分数和一个总评然后按总分卡阈值。阈值不是拍脑袋定的而是先用一批人工标注的样本去校准——让 agent 打分和人工标注对比调整 prompt 和阈值直到 agent 判断和人工判断的一致率达到可接受水平一般 85% 以上。3.3 清洗的可解释性为什么要留痕Agent 清洗有个容易被忽视但极其重要的点每一条被丢弃的数据都要记录丢弃原因。这不是为了审计而是为了迭代。当你发现模型在某个能力上表现差回头查清洗日志很可能发现是某类数据被误杀了。我一般要求清洗流水线输出一个结构化的日志每条数据记录原始 ID、各维度评分、最终判定、丢弃原因、agent 版本号。有了这个日志你才能做清洗策略的 A/B 测试——同一批数据用两套清洗策略跑对比下游模型效果用数据说话而不是凭感觉。3.4 清洗与合成的闭环清洗和合成不该是两条独立的流水线而应该形成闭环。合成出来的数据要经过清洗清洗中发现的问题要反馈给合成环节。比如清洗时发现大量样本都是指令过于笼统那就该去调整出题 agent 的 prompt让它生成更具体的指令。这个闭环的自动化程度可以很高清洗 agent 统计出的高频问题类型自动生成反馈报告喂给出题 agent 作为下一轮的约束条件。跑上几轮之后合成数据的初始质量会明显提升清洗的压力随之下降。这套机制我在几个项目里跑过通常三轮之后合成数据的通过率能从 40% 左右提到 70% 以上。4. 把三个阶段串成一条流水线前面分开讲了三个阶段和合成清洗两条线但真实项目里它们是交织的。这一节讲怎么把它们组织成一条可维护的流水线。4.1 数据版本管理别让数据变成一笔糊涂账数据流水线最怕的就是这版模型用的哪版数据说不清。所以第一件事是给数据打版本而且要像代码一样管理。每次合成或清洗产出的数据集都要有唯一的版本号、生成时间、使用的 agent 版本、种子版本、清洗策略版本。我推荐用类似 DVC 或者简单的 manifest 文件来管理核心是保证任何一个训练出来的模型都能追溯到它用的确切数据版本。这样当模型出问题时你才能定位是数据的问题还是训练的问题。这个习惯看起来麻烦但真出事的时候能救命。4.2 分阶段的数据配比策略一条完整的训练流水线三个阶段的数据配比需要提前规划。我的经验配置大致是这样Mid-training真实领域语料为主80%合成语料作为补充20%清洗以去重去噪为主。SFT真实高质量指令数据 合成数据混合合成占比 50% 到 70%清洗重点在格式和一致性。RL以可验证的真实任务为主合成题目用于扩充难度分布清洗重点在奖励信号有效性。这个配比不是固定的要根据你的真实数据存量调整。真实数据越少合成占比越高但自我中毒的风险也越大需要更频繁地用真实数据校准。4.3 成本控制agent 调用不是免费的Agentic 流程最大的现实约束是成本。每个 agent 调用都是真金白银一条数据过四个 agent成本就是单次调用的四倍。所以成本控制必须从设计阶段就考虑。几个实用的降本手段第一分级处理简单判断用小模型复杂判断才上大模型。第二缓存复用相同或相似的样本直接命中缓存不重复调用。第三批量处理把多条数据打包成一个 prompt 让 agent 一次判断摊薄 token 成本。第四采样校验不是每条数据都要过全部 agent可以按比例抽样做深度评审其余走轻量流程。我一般会把单条数据的清洗成本控制在可接受范围内然后反推整个数据集的处理预算。如果预算不够宁可缩小数据集规模也要保证质量因为 RL 和 SFT 阶段数据质量比数量重要得多。4.4 人工介入的时机Agentic 不等于全自动。完全放手让 agent 跑迟早会出问题。人工介入应该卡在几个关键节点种子设计人工定维度和质量基线、评审标准校准人工标注一批做对齐、以及最终数据集的抽检人工看一批确认没有系统性偏差。抽检的比例不用高1% 到 5% 就够但一定要做而且要随机抽 分层抽结合——随机抽看整体分层抽看各个难度档和任务类型有没有被系统性忽略。我踩过的坑就是只做随机抽检结果某个小众任务类型的数据全是坏的因为它在整体里占比低随机抽根本抽不到。5. 几个真实踩过的坑和对应的处理理论讲完了说几个我在实际项目里真金白银换来的教训这些是文档里不会写的。5.1 评审 agent 的老好人倾向评审 agent 有个很讨厌的毛病它倾向于给高分。你让它判断一条数据好不好它十有八九说还不错。这是因为模型在训练时被对齐成了友善、肯定的风格做评审时会不自觉地放水。解决办法有两个。一是在 prompt 里明确要求它找问题把任务从判断好坏改成找出这条数据至少三个问题逼它挑刺。二是引入对比评审一次给它两条数据让它选哪条更好相对判断比绝对打分稳定得多。我后来基本都用对比评审效果好很多。5.2 合成数据的格式趋同跑了一段时间 agentic 合成后我发现生成的数据有个隐蔽问题格式高度趋同。所有指令都是请帮我……所有回复都是好的我来……。这种趋同规则检测不出来但会让模型学出一套僵化的输出模式。处理办法是在出题 agent 的 prompt 里强制注入格式多样性约束比如要求指令的开头方式在若干种里随机选回复的结构在若干种模板里轮换。更彻底的做法是维护一个已用格式的列表让 agent 避开已经用过的格式。这个细节很小但对最终模型的输出自然度影响很大。5.3 难度分布的隐形塌陷前面说了要控制难度分布但实操中还有个更隐蔽的问题难度分布会随着合成轮次逐渐塌陷。第一轮生成的数据难度分布可能还挺好但 agent 在后续轮次里会不自觉地往它擅长的方向生成导致中等难度样本越来越多两端越来越少。对策是每轮生成后都重新统计难度分布并动态调整出题 agent 的约束。如果发现困难样本不足就在 prompt 里明确要求生成需要至少五步推理才能解决的问题。这个动态调整必须自动化靠人工盯是盯不过来的。5.4 清洗阈值不能一劳永逸清洗阈值比如评分卡在多少分以上才保留不是定一次就完事的。随着合成数据分布的变化、agent 版本的更新、甚至基座模型的迭代原来的阈值可能就不再适用。我一般会每个大版本重新校准一次阈值用一批新的人工标注样本去对齐。有个具体的信号可以帮你判断阈值是否需要调整如果清洗后的数据集规模突然大幅波动比如通过率从 60% 掉到 30%那多半是阈值或者 agent 出了问题该查了。6. 关于工具和框架的选型思路最后聊聊工具选型。这块我不推荐具体产品因为迭代太快今天推荐的明天可能就过时了。但选型的判断标准是相对稳定的。第一看它是否支持多 agent 编排。单 agent 的框架做不了角色隔离直接排除。第二看它是否支持结构化输出。评审 agent 要输出评分必须是可靠的 JSON 而不是自由文本否则后面没法自动化处理。第三看它是否有缓存和重试机制。agent 调用会失败没有重试的框架在生产环境里没法用。第四看它是否方便记录日志。前面强调的清洗可解释性全靠日志支撑。至于自己搭还是用现成的我的建议是流程验证阶段用现成框架快速跑通生产阶段该自己写的部分自己写。因为 agentic 数据流水线的很多逻辑是高度定制化的通用框架到了细节层面往往不够用硬套反而增加维护成本。选型时还要考虑一个现实问题你的团队里有没有人能维护这套东西。Agentic 流水线不是搭完就完事的它需要持续调优、校准、迭代。如果没人能接手再先进的框架也是负担。这一点比技术选型本身更重要。数据这条线说到底是个慢功夫。Agentic 方式能帮你把效率提上去但它替代不了对数据的理解和对质量的判断。工具再聪明方向还得人来定。我自己的体会是把种子设计和评审校准这两件事做扎实后面 agent 跑起来就顺这两件事偷懒后面全是坑。