做LLM训练这行当最近圈子里聊得最多的其实不是模型结构而是数据。尤其是当你同时推进SFT、mid-training、RL三条线的时候会非常直观地感受到一个扎心现实模型能力的天花板经常不是网络设计决定的而是喂进去的数据决定的。人工写数据已经跟不上节奏而传统模板化合成数据又不够用做出来的东西重复率高、覆盖面窄、还带着一股机器味儿。我今年三季度开始系统性转向agentic方式来做训练数据合成与清洗从SFT指令对到mid-training领域知识再到RL偏好数据跑通了一套完整流程。这个项目代号就叫【09-14】前后迭代了差不多两个月踩了不少坑也沉淀了一些真正能用的经验。这篇就把我的完整做法和思考过程写出来不吹不黑都是实测过的东西。1. 为什么数据团队最终绕不开agentic合成这条路先说一个背景。我们的项目同时涉及三个训练阶段的数据需求SFT需要高质量的指令-回答对mid-training需要大量领域相关且事实准确的语料RL需要能表达偏好差异的对比数据。三个需求摆在一起你很快会发现它们有一个共同点都需要懂业务、能推理、会判断的标注方式而这些东西恰好是大模型自己擅长的。传统合成数据的做法是模板填充和规则改写。比如定义几十个句式模板把实体、动作、场景往里套一条数据几秒钟就能生成。但这个路子的问题很明显生成的数据分布非常窄模板痕迹重模型很容易学到表面模式而不是真正的能力。尤其SFT数据如果指令都是请说明XX这种句式微调出来的模型面对真实用户的开放式提问就会露怯。agentic方式的核心差别在于它把数据生成从一次性生成改成了多角色协作、分步推理、带反思修订的流程。生成器先产出候选数据评审器针对多个维度打分修订器根据意见改必要时还会调用检索工具查证事实。每一批数据都要过这套流程而不是生成完就直接进训练集。这个转变本质上是在用过程质量换数据质量和我们平时做业务系统里质量控制、多级审批是一个逻辑。对于单条数据来说成本确实变高了但放到整体训练流程里看它的ROI是明显划算的——脏数据进训练集导致的bad case修复成本远高于生成阶段多花的那点token费用。2. 生成器-评审器-修订器一套能落地的agentic数据管线我最终定的管线结构是三个角色加两层门控。三个角色分别是生成器(Generator)、评审器(Reviewer)、修订器(Refiner)两个门控分别是规则校验和模型校验。所有角色都基于同一个基座模型但prompt和temperature完全不同这样能保证视角差异。2.1 三个角色的职责划分生成器负责从无到有。它的输入是一批种子样例或需求描述输出是原始数据候选。这个角色要求发散性所以我通常把temperature设置在0.8到1.0之间让输出尽量多样化。生成器的prompt里会明确告诉它你正在为训练数据生产候选样本宁可是有瑕疵的也不要和已有样本重复。评审器负责挑毛病。它的输入是多条候选数据我会一次性给5到10条输出是逐条的打分和具体修改意见。评审器的temperature要低0.2左右要求它严格按照评分维度逐项打分。评分维度对三类数据各不相同但都有一个公共框架正确性、多样性、真实性、难度梯度。修订器负责改到过。它拿到评审意见后逐条修改候选数据。它会看到原始版本和评审意见输出修订版本。如果修订后仍然不过关可以再回到评审器循环。我设置的最大轮数是3轮超过3轮直接丢弃避免算力被坏数据拖死。2.2 第一道门控规则校验规则校验跑在评审器之前目的是用最小成本把明显不合格的数据挡在门外。比如SFT数据里必须包含用户指令和模型回答两个字段回答不能为空mid-training数据必须有明确的文档来源标识RL偏好数据必须区分chosen和rejected两个答案且不能完全相同。规则校验的代码逻辑很朴素就是字段检查加简单启发式判断。但它有一个隐藏好处大幅减少评审器的无效工作量让评审把注意力集中在语义质量上。我试过跳过规则校验直接把原始数据丢给评审器结果评审经常被低级的格式问题干扰打分质量明显下降。2.3 第二道门控模型评审模型评审是整个管线的核心环节。我设计过一个比较稳的评审prompt结构大致包含五个部分任务背景、被评审数据、评分维度定义、输出格式约束、评审注意事项。其中评审注意事项是我实践下来觉得最有用的一个部分里面会写你正在对训练数据做质量把关烂数据会直接损害模型表现请勿放水这类施加责任的句子能有效提升评审严格度。评分维度我采用百分制加权正确性占40%多样性占25%真实性和规范性各占15%分项打分后加权汇总。这里有个细节评审器必须先理由后分数先写判断依据再给数值比直接给分要稳得多模型在被迫推理的状态下判断质量更高这也是我们后来做RL数据时的同一个套路——先推后断。3. SFT数据合成实操让agent模拟真实用户的提问方式SFT数据合成的核心难点从来不是答案而是指令。真实用户的提问方式五花八门有的人一句话里包含两个任务有的人表达含糊需要澄清有的人会连续追问。模板化数据永远模拟不出这种复杂形态而agent能。3.1 从真实日志提炼提问人格我的做法是先收集线上产品的用户真实提问日志做一轮脱敏和聚类得到大约20种典型提问模式。比如模糊指令型、多任务叠加型、反讽或情绪型、背景信息省略型等等。每种模式写2到3条示例作为生成器prompt里的few-shot例句。这个步骤至关重要。如果你直接让生成器生成多样化的用户指令它产出的东西仍然会偏书面化、偏工整。而给了提问人格示例之后生成器会模仿这些模式输出明显更接近真实用户的口吻。我们统计过带提问人格示例生成的数据后续人工抽检通过率比不带示例的高了约18%。3.2 多轮对话的agentic展开单轮指令对只是SFT数据的一部分现在很多场景需要多轮对话数据。agentic方式在这里有一个天然优势可以让两个agent分别扮演用户和助手进行多轮对话第三方的评审器再检查对话质量。用户agent的prompt里会设定它自身的背景比如你是刚入门python的开发者目标你想完成一个数据处理脚本甚至性格你表达比较跳跃经常省略上下文。助手agent则被设定为专业、耐心、有边界感的客服型角色。两个agent交替发言生成器控制轮数上限一般4到8轮。这个方法的实际产出质量相当高因为它模拟出了真实对话里的信息逐步补全过程用户第一句可能很模糊助手通过追问澄清需求后续对话围绕真实意图展开。这种渐进式澄清的模式是模板化合成完全做不到的。3.3 指令的难度梯度设计另一个对SFT效果影响很大的细节是难度梯度。如果合成出来的指令全是简单直白型模型微调后处理复杂问题的能力就不会有提升。我在生成器prompt里会要求它按照困难度分层生成分为基础、进阶、挑战三个层级每个层级设定具体的考察能力点。基础层考察单点能力比如解释什么是梯度消失进阶层考察多点组合比如比较L1和L2正则化在稀疏特征场景下的表现挑战层考察综合推理或反直觉判断比如当数据量极小且特征维度极高时你会选择哪些正则化策略为什么。评审器的评分维度里加入了难度识别一致性检查评审会判断生成数据实际难度和标注难度是否匹配。如果差异过大这条数据会被打回重新生成。这个机制有效防止了生成器偷懒——它倾向于把数据往容易的方向上靠如果没人检查难度标注最终数据集会整体偏简单。3.4 SFT数据的答案校验环节答案校验是SFT数据合成里最不能省的步骤。生成器写的答案可能存在事实错误或逻辑漏洞直接进训练集就是在教模型犯错。我采用双通道校验规则通道检测答案长度、格式、敏感词模型通道由评审器对照评分维度中的正确性标准做复核。对于需要事实查证的数据我会加入第三通道——检索校验。agent在评审阶段如果发现答案涉及具体数据、法规条文或特定产品的功能参数会调用搜索工具查证后再下结论。这个设计初期成本确实高但有效挡住了好几个一本正经胡说八道的答案进入训练集。4. mid-training数据合成用agent挖出领域知识盲区mid-training中间训练这个阶段经常被低估。它的目标是让模型在特定领域内补充知识、强化能力同时又不能破坏已学到的通用能力。mid-training数据的核心诉求和SFT完全不同SFT要的是会说话mid-training要的是懂知识——事实密度、覆盖广度、表述形式三个维度都跟SFT不一样。4.1 基于文档的agentic QA生成我的主打方案是基于领域文档合成图文对照数据。流程是先对领域文档做分块处理把每个文本块连带上下文一起喂给生成器要求它基于这段内容生成若干问题-答案对。但这里有个关键约束生成的问题必须依赖文档信息才能回答不能是通用常识问题。这个约束靠评审器来把关。评审器会检查每个QA对是否确实以给定文档块为信息源如果问题不依赖文档就能回答会被打回。做了这个约束之后产出的mid-training数据才真正具备知识补充效果而不是又一批通用知识问答。4.2 知识关联扩展从单点到连片单块文档生成的QA对只是知识点距离知识面还有距离。第二阶段的扩展我用了一个简单但有效的做法把同一主题下的多个文档块合并成更大的上下文窗口让生成器产出跨文档的综合型QA要求答案是多个来源信息的整合并标注每个论断的来源。这种数据一旦合成mid-training的效果会明显好于单点数据因为它训练的是模型跨段落检索信息并整合的能力。模块融合本身就是大模型在专业场景里的核心痛点你把这部分能力在mid-training阶段强化了下游SFT才能更好地发挥出来。4.3 事实性校验的三层防线mid-training数据最怕的就是事实错误——模型记住错误知识比没记住更糟。我在这个环节设了三层防线。第一层是上面提到的检索校验凡是涉及具体数字、时间、名称的内容都要求agent查证。第二层是交叉验证同一知识点的QA对如果存在多于两条会随机抽两条检查是否矛盾。第三层是人工抽检不是说全量人工而是对每个批次按5%比例抽检发现错误率超过阈值的批次整批退回。三层防线走下来最终进入训练集的数据事实错误率控制在了千分之三以下。5. RL训练数据构造偏好对、过程奖励与agentic debateRL阶段的数据需求和前两个阶段又不一样。这个阶段的核心不是教模型怎么答而是教模型什么答案更好。你的数据形态从单一的正样本变成了成对或成组的对比数据复杂度直接上升。5.1 偏好对的agentic构造流程偏好对构造的传统做法是让多个模型生成答案再让人或奖励模型打分排序。agentic的做法是在此基础上增加评估推理过程。具体流程是针对一个指令让两个不同的生成模型各产出一个答案然后评审agent先分别分析两个答案的优缺点再给出胜负判断。这个先分析后判断的设计很关键。直接让评审模型比较两个答案然后说哪个好它经常犯偏好强者的错误——哪个答案长、写得工整就认为哪个好。而强制它先逐条分析每个答案是否解决了用户的核心问题、是否有事实错误、是否有遗漏环节判断质量会显著提升。我们在人工盲测中验证过带推理过程的评判准确率比直接评判高出约11个百分点。5.2 过程奖励数据拆解到步骤级的标注针对推理密集型任务我们把手、脚训练数据做到了步骤级别——不再只给整个答案一个偏好标签而是把答案拆成若干推理步骤对每一步的质量进行标注。这也就是过程奖励模型需要的训练数据格式。agent在这里扮演的角色是步骤分析员。它先读完整答案再把答案拆分成步骤序列然后对每一步的自我纠偏、逻辑衔接、信息利用等维度打标签。最终产出的数据是步骤标签理由的结构。这类数据合成成本比偏好对高不少但对于数学推理、代码调试类任务的效果提升是全方位的——过程奖励模型能定位到具体出错步骤而不是整个答案一起否定。5.3 agentic debate让模型自己吵出答案质量说到RL数据构造里我最满意的一个设计其实是一套agentic debate方案。具体做法是针对一个复杂问题让三个agent分别充当三个不同立场的回答者每个回答者尝试给出最合理的答案同时还要专门批判另外两个答案的漏洞。最后再由裁判agent综合三方的论点在表述上完成一个完整答案的构建。这套方案产出的数据天然就带有对比属性一张数据可以同时拆出偏好对和步骤级正负样本。更重要的是通过辩论暴露出来的错误模式和反驳理由比单模型生成的标准答案更有教学价值——RL模型能从中学到边界在哪里、错误是什么样。当然debate方案的花费也比较可观一次完整的三方辩论大约要消耗上万token。所以我没有全量启用只用于那些高难度、强推理类型的数据约占RL数据总量的15%。6. 数据清洗的agentic改造从筛掉到改写数据清洗这个环节传统思路是坏的丢掉agentic思路则是坏的分析原因能改则改。两者对数据资产的利用率差了不止一个量级。6.1 传统清洗的局限传统清洗主要靠规则和分类器长度过滤、重复检测、关键词黑名单、困惑度过滤。这套组合拳能挡掉低质量数据的八成左右但剩下一成半的数据是貌似合格、实则有害的——比如逻辑前后矛盾的回答、看似流畅但没解决用户问题的答案、融会了错误事实的段落。这些坏数据靠规则根本筛不出来而直接丢掉又可惜。6.2 agentic清洗的三步走我的agentic清洗管线分三步。第一步是诊断评估agent读一条数据输出诊断报告标注问题类型事实错误、逻辑断裂、跑题、信息冗余、有害内容等。第二步是分类决策根据诊断结果决定这条数据是直接通过、需要修订还是彻底丢弃。第三步是修订对需要修订的数据由修订agent按照诊断报告逐条修改修改后再过一遍评估。这套流程跑下来的实际结果是原本会被规则过滤丢弃的数据中约有40%通过修订重新达标。要特别提醒的是修订后的数据不要直接混入数据集必须经过一轮完整的质量评估确认达标不然容易把修订得似是而非的数据漏过去。6.3 一致性检查与去重清洗环节还有一个容易忽略的点一致性检查。同一份数据如果出现多个版本比如原始版、修订版、二次修订版要确保最终进入训练集的是最后一个版本且旧版本不会残留在别的数据分区里。我在实践中就吃过这个亏——某个epoch里同时混入了原始数据和修订数据模型被两个矛盾答案搞糊涂了下游指标不升反降。去重也不是简单算个文本相似度就完事而是要做语义去重。我用embedding模型把全量数据向量化再按余弦相似度做聚类同一簇内只保留多样性得分最高的那条。这一步跑一次大概需要大几小时但值清洗完的数据集体量通常会缩水到原来的60%到70%留下来的都是高纯度样本。7. 质量评估、成本账与一次失败复盘讲完了方法必须说说验证和成本。这两件事做不扎实前面的流程再漂亮也会翻车。7.1 人工抽检体系怎么搭人工抽检不能只给标注员一个这条数据好不好的问题那样标准太主观。我这边把抽检表单拆成四个维度信息正确性有无疑点事实、逻辑连贯性分论点推进是否连续、语言自然度是否符合目标人群的表达习惯、指令覆盖度是否贴题、是否解决用户核心需求。每个维度按1到5分打分总分低于12分的数据视为不合格。抽检按批次进行每批抽5%。良率低于85%的批次整批返回重做这是硬规矩——它逼着生成环节保持紧张感。后面我们发现把抽检结果和生成参数关联起来分析还能反过来优化各角色的prompt。比如某段时间评审器评分普遍虚高我们就把评审prompt里请勿放水的语气加重下一批评分分布马上就正常了。7.2 自动化评估指标选哪些人工抽检是低频高精度自动化指标是高频低精度两者缺一不可。我日常盯的自动化指标有三个语义多样性用embedding距离的分布宽度衡量防止数据同质化、难度分布每个难度层级的占比是否合理、修订率评审后被打回重做的数据占比例。修订率这个指标容易被忽略其实它是判断生成器和评审器是否在良性对抗的关键。如果修订率趋于零说明评审在放水如果修订率长期居高不下说明生成器产出质量不达标或者prompt给的示例有问题。我理想的修订率区间在25%到45%之间低于或者高于这个区间都会让我警觉。7.3 成本拆分agentic到底贵不贵这个问题经常有人问我直接给一组实测数据。我们按100万条有效数据为基准折算SFT数据的平均单条合成成本含生成评审修订抽检大约是传统模板合成的8到12倍但整体预算并没有爆掉因为我前面提到的清洗环节把最终进入训练集的数量压缩到了合格样本。RL偏好数据的成本会更高一些因为涉及多模型采样加agentic评审平均单条的合成成本大概是SFT的3到5倍。但比起请外包团队标注同样规模数据的费用按条计费而且质量不可控agentic方案综合算下来仍然便宜不少而且交付速度快了不止一个量级——几天就能完成以前要数周才能做完的量。7.4 一次失败复盘agent的自我强化陷阱必须坦白讲这个方案也不是一开始就顺。第一个版本踩的最大的坑是agent陷入自我强化陷阱。现象是某次跑完一批SFT数据后模型微调效果反而变差了人话讲就是变笨了。排查了很久发现是生成器和评审器在长期配合中形成了一个隐蔽的固定模式——评审器对生成器特定的句式风格给了稳定的高分生成器就越来越依赖这种句式结果整个数据集风格高度同质化模型学完之后输出变得呆板。后来我引入了两个机制解决这个问题。第一个是评审器的匿名化评审给评审器的输入里隐去生成来源和元信息让它看不到这条数据是谁生的、哪个批次出的从源头上减少熟人打分的倾向。第二个是评审器轮换制同一个评审器连续使用超过一定次数就会换一个不同基座或不同prompt风格的评审器替代让管线保持视角新鲜度。这俩机制上线后修订率回升到了正常区间数据多样性也恢复了。8. 几条实战经验小技巧、边界和值得投入的方向最后分享几个实操中的微小经验和判断比较零散但都是真金白银换来的。第一个是工具选择。agentic管线不需要特别复杂的编排框架我初期用python脚本加异步调度就够跑。后面数据量大起来才迁移到任务队列的方式用分布式worker并行跑不同的合成任务。不建议一开始就上重框架先把数据和prompt迭代到稳定再考虑工程化顺序反了你会在调试框架和调试数据之间疲于奔命。第二个是prompt版本管理。agentic合成本质上是prompt驱动的生产线各角色的prompt每天都在改。我强烈建议给prompt做版本管理每次改动记录前后差异和评估结果。没有版本管理的agentic数据管线后期排查问题会非常痛苦——你不知道哪条数据对应哪个prompt版本也无法回溯质量波动的origin。第三个是边界意识。agentic合成不是万能的有些数据类型它做得并不好。比如高度依赖真实世界最新信息的任务agent存量的知识容易过时就算有检索工具检索覆盖率也有限。再比如极其细分的专业领域模型本身在该领域的知识就不足让它在数据里自产自销只会固化和放大错误。这类数据还是得靠专家标注agent只能做辅助清洗。下一阶段我打算朝两个方向继续投入一是把管线里的评审标准从人工定义变成半自动发现让agent主动找出当前数据分布里的薄弱维度并建议新的评审项二是尝试把agentic合成和在线RL反馈打通让模型在真实环境里的表现数据回流到数据合成管线形成闭环。这两个方向目前都有一些初步尝试等多跑几个迭代有了稳定的数据我再单独写文章分享。