最近一直在折腾训练数据的生产方式核心关键词就一个agentic。具体来说是用一套能自我审视、能迭代改进的智能体流程去合成和清洗SFT、mid-training、RL三个阶段的训练数据。这个思路把我原来的“人工标注-规则清洗-人工质检”流程彻底改掉了整体效率和质量都上了一个台阶今天把整套方法论、关键参数和踩过的坑完整复盘一遍。先说明白这套东西适合谁如果你正在做大模型微调手头缺数据、缺标注人力或者发现模型在特定任务上表现不稳定那本文的流水线可以直接抄走如果你是数据工程师想搞一套可持续运转的数据生产机制也能从中找到架构层面的参考。我实际跑过的场景包括指令数据、领域预训练语料、RL偏好对三类下面会按不同阶段拆开讲。1. 先搞清楚Agentic数据合成到底解决什么问题1.1 传统数据生产流程的瓶颈大模型训练数据需求量大到离谱。SFT阶段往往需要几万到几十万条高质量的指令-响应对RL阶段需要大量偏好标注mid-training阶段则要成规模的领域文本。传统人工标注有三座大山贵、慢、一致性差。贵是显性的一条复杂指令的响应人工标注成本可能超过几块钱几万条就要十几万慢则体现在流程上从写标注规范、培训标注员到多轮质检一个批次动辄两周一致性更让人头疼同一个标准不同标注员的理解可能有偏差导致SFT数据里混入两种甚至多种风格模型学起来会“人格分裂”。有人会说那直接让模型批量生成不就行了吗我最早也这么干让一个开源模型一口气生成一万条问答结果就是大量重复、格式崩塌、逻辑错误而且最致命的是——不知道哪条数据是好的。单次生成的产线没有质量闭环劣质数据全混进了训练集最后模型效果反而下降。1.2 Agentic方式与传统方式的核心区别Agentic数据合成和普通“大模型生成数据”的区别在于多了一个“批评-改进-筛选”的闭环。它不是一次性把数据吐出来而是让多个角色或有明确角色的多轮循环参与先由生成器产出候选再由评判器打分并指出具体问题然后让改进器根据反馈修改最后只有通过质量门禁的样本才进入训练集。用一个类比来理解传统生成像是让一个新员工闭着眼睛写文案写完直接交付Agentic方式则是给他配了一个主编——先写初稿、主编批注问题、员工修改、再批注、再改直到达到发表标准。这个“主编”的成本由另一个模型承担比真实人工便宜得多。这套方案能同时覆盖“合成”和“清洗”两类目标。合成针对“没有数据怎么办”用seed样本扩展清洗针对“数据质量差怎么办”用评判器加规则筛选。很多团队只把agentic用在生成侧忽略了它作为清洗器的价值其实后者带来的收益往往更直接。2. 三种目标阶段的数据需求决定了合成策略完全不同2.1 SFT数据指令-响应对贵在多样与格式规范SFT阶段的核心目标是让模型学会“听从指令、格式正确、任务清晰”。这个阶段的数据不追求极端难度而追求任务多样性和格式一致性。我踩过的最大的坑就是合成了一堆高难度数学题式样本结果模型在普通问答上反而变蠢了因为普通场景的分布被高难度数据压过。SFT数据合成时要重点控制几个维度指令的清晰度、覆盖的任务类型写作、摘要、编码、结构化输出、对话等、响应的格式规范性JSON、Markdown、代码块等。每条指令最好带明确的约束条件比如“生成一个包含三个要点的列表”、“输出为JSON格式”。想让模型拥有某种能力不是给它看几个例子而是让它在海量带格式要求的样本中反复强化。2.2 Mid-training数据领域文本重构重在知识密度Mid-training通常指的是预训练和SFT之间的中间阶段目的是注入领域知识或特定格式能力。这个阶段的数据不一定是问答对甚至不一定要配合指令重点在于让模型在大量领域文本上继续学习。但直接拿原始文档训练吸收效率很低。我用agentic方式做过两件事一是把文档改写成“理解型问答对”比如从一套产品文档里抽出“参数含义”、“故障排查步骤”、“组件关系”三种类型的问答二是做信息浓缩把冗长段落改写成结构化摘要、实体关系说明。这样提炼出来的数据知识密度比原始文本高得多模型学起来效率也高。Mid-training数据的合成难点不是“生成”而是“保真”。文档里的关键数字、技术细节、因果关系一旦被模型改写时出错就会把错误知识注入模型。所以这个阶段合成必须配合检索校验或引用不能完全靠生成式模型自由发挥。2.3 RL数据偏好对与奖励信号难在排序质量RL阶段的数据形态完全不同它要的是偏好对对同一个问题给出两个回答标注哪个更好。这直接决定了奖励模型的判断边界。Agentic方式在这里的典型玩法是为每个prompt生成多个候选响应用评判器逐条打分然后构造chosen/rejected对。这里的核心难点是排序质量。如果两条候选答案分数差太多比如一个80分一个20分虽然好区分但学到的边界太粗糙模型只知道极端情况如果都是60分和61分区别又太小奖励模型学不出真正的信号。所以要用critic分数筛选出“差距适中”的对子我经验上通常保留分数差在1到3分10分制之间的配对。另外可以顺带提一下RL里的BCBehavior Cloning行为克隆。很多团队在RL阶段会先用BC做初始化让模型模仿一些高质量的示范避免RL一开始就自由探索导致崩溃。Agentic数据合成能为BC提供大量演示数据让起点更高这是容易被忽略的应用点。3. 一个可落地的Agentic数据合成/清洗流水线3.1 完整架构生成-批评-改进-筛选整套流水线我设计成五个模块生成器、批评器、改进器、过滤器、去重器。Mock流程大致如下pipeline [] # 阶段1生成候选 candidates generator.generate(seed_pool, num_return_sequences8, temperature1.0) # 阶段2批评器打分并给具体反馈 for cand in candidates: score, feedback critic.evaluate(cand) # 阶段3改进循环 for _ in range(Max_Improve_Rounds): if score Fine_Threshold: pipeline.append(cand) break cand improver.improve(cand, feedback) score, feedback critic.evaluate(cand) # 阶段4规则过滤 去重 pipeline rule_filter(pipeline) pipeline deduplicate(pipeline, similarity_threshold0.85)需要注意这里四个模块可以由同一个底层模型承担关键是每个模块使用不同角色设定和prompt模板避免上下文污染。比如批评器的prompt要完全脱离生成器的指令只针对“数据质量”本身评判。3.2 关键环节一生成器设计温度与passk生成器负责产出候选样本参数选择直接影响数据多样性。温度太低输出千篇一律温度太高模型胡言乱语。我用下来相对稳的组合是生成阶段temperature 0.8 ~ 1.0top_p 0.95每个seed指令生成4到10个候选passk然后全部交给评判器选优。有个细节值得强调生成器最好使用seed池驱动。不要每次都从空白发散而是准备几百条手工精选的种子样本让模型在种子基础上做变体、扩展、反向、改写。种子池的质量决定了合成数据的质量上限这就好比教育里“示范比说教更重要”。我第一次做时只给了20条种子结果生成的指令狭窄到让人崩溃后来扩到300条并覆盖不同任务类型多样性立刻好转。3.3 关键环节二评判器设计打分准则与可验证检查评判器是整个agentic流程的“质检员”它的设计决定了筛选标准。我建议给评判器一个明确的打分卡而不是让它自由发挥。以SFT指令数据为例打分卡大致包括指令清晰度、任务难度、响应正确性、格式规范性、逻辑一致性。每项单独0-5分最后按权重加权。可验证检查是评判器中最重要的部分。对于代码类任务要求实际运行代码并断言输出对于数学题要求算式可结算验证对于知识类任务必要时接检索结果做对照。这套硬校验逻辑能解决纯LLM评判器“睁眼说瞎话”的问题。实测下来加不加硬校验筛选出的数据质量完全两个等级。3.4 关键环节三清洗与去重比生成更重要的流程化过滤很多人把注意力放在“怎么生成更多数据”却忽视了“怎么筛掉差数据”。我自己的体感是清洗环节至少抵扣生成环节一半的工作量。清洗包括三部分规则过滤、语义去重、质量分流。规则过滤最简单长度筛选过长过短都剔除、格式检查JSON是否可解析、黑名单词检测。语义去重比较关键我通常用embedding模型计算样本相似度阈值设在0.85到0.9之间相似度高于阈值的样本集群只保留一条或少数几条防止训练集中出现大量“复读机”。质量分流则是按评判器打分把数据分为高、中、低三个池子高置信度的直接进入训练集中等的留给人工抽检低质量的不进训练集可能会进入负例样本库。4. 实操拆解SFT指令数据合成完整流程4.1 第一步从几百条种子指令出发我在做客服领域SFT数据时第一步是整理种子指令。手工写了大约300条真实场景问题覆盖售前咨询、售后问题、投诉处理、多轮追问、情绪表达五个大类。每条种子指令字数从几个字到几百字不等难度也刻意拉开。种子指令是合成系统的地基它不要求完美但要求真实、具体、可扩展。比如“用户询问退货流程”就比“问一个问题”好得多因为前者能自然地演化出各种变体。这一步不要偷懒花两天时间人工整理种子池后面能节约两个星期。4.2 第二步多轮进化与自我批评拿到种子指令后我采用的进化策略包含几类操作难度提升增加限制条件、话题迁移换一个对象但保持结构、角色反转从用户视角改为客服视角、格式改造改为多轮对话或JSON输出。每一轮进化后都交由评判器打分不达标的样本被改进器重写一次最多迭代五轮。值得说明的是进化不是为了把指令改得越难越好而是为了覆盖真实分布的边缘。比如“用户要求退款”是普通样本但如果加上“用户语气强烈、事件涉及第三方平台”这样的约束模型在未来真实场景中的泛化能力会明显增强。SFT数据需要的是这种“贴近真实又略有挑战”的样本而不是爬楼梯式无上限的难度。4.3 第三步质量阈值与人工抽检我最终设定的保留标准是评判器10分制分数不低于8分才进入训练集代码类任务必须能够运行成功JSON格式类任务必须能通过解析校验。维持这条门槛十万条生成候选中通常只能保留下两到三万条这也是预期高质量数据本来就不该有太高的产出率。人工抽检在这个流程中不可完全省略我通常按批次抽5%到10%的样本。这里的抽检价值不仅在于验证最终质量更在于发现评判器的“系统性偏好”——比如评判器偏好长答案或者偏好带特定词汇的答案。发现这种偏差后去打补丁调整评判器prompt而不是去改生成器否则很容易按下葫芦浮起瓢。5. Mid-training数据合成实践把领域语料变成训练信号5.1 从非结构化文档到结构化训练样本Mid-training阶段我最常处理的是非结构化文档产品手册、技术白皮书、历史工单文本等。直接把这些原始文档丢给模型继续训练不是不行但吸收效率低且难以检验。我的做法是用agentic流程把每篇文档转化为多种结构的训练信号让模型从不同侧面对同一知识进行多次学习。常见的结构输出包括理解型问答对围绕文档中的关键概念出题、摘要型句子用一两句覆盖一段话的核心信息、关系型描述“组件A依赖组件B原因是...”。生成这些结构化内容后再把它们与原始文档混在一起训练。这样做的好处是模型既看到原始知识又看到了“被抽过问题”的知识形态知识检索和复述能力都会增强。5.2 代码、文档转指令的注意事项Mid-training阶段如果涉及代码语料agentic合成要注意保留可运行性。我不建议随意把代码片段改成问答形式因为这很容易破坏代码的上下文依赖。更好的方式是让生成器基于代码文件生成“代码解释”、“调用场景”、“调试建议”这类周边内容代码本身保持原文。另外一个关键教训是不要对领域事实做过度的语言华丽化改写。mid-training阶段目标不是让文本更生动而是让信息更密集、更结构化。我早期在用agentic改写技术文档时生成器喜欢把“network timeout”改写成“网络在高峰时段出现了响应缓慢的现象”虽然流畅但信息熵下降而且引入了歧义。后来的方案是限定风格为“技术文档语气”并要求保留所有专有名词和数字。6. RL阶段的数据合成偏好对与Reward Model数据6.1 自动构造偏好对生成-打分-排序RL数据的核心是奖励模型的输入。我构建偏好对的标准流程是先从真实和SFT合成数据中抽取prompt池让同一生成器在中等温度约0.9下产出五到八个候选回答然后由评判器逐一打分并排序选择分数差适中的一对作为chosen和rejected。这里的base prompt池很关键。只靠搜索用户的日志当然最真实但数量不够。我通常的做法是把SFT阶段保留下来的高质量指令作为初始prompt池再通过agentic改写扩展出更多风格不同的表述。RL阶段prompt池的多样性直接决定了模型最终会不会“变成只能回答某类叫法的问题”如果prompt分布太窄RL后的模型对用户不同的提问方式会很脆弱。6.2 Hard Negative与难度控制奖励模型训练还有一个提升手段是构建hard negative样本两个回答表面上都合理但一个存在细微且关键的错误另一个完全正确。这种样本能逼奖励模型学习真正精细的判别能力而不是停在“明显胡扯 vs 正常回答”的粗糙边界上。Agentic方式天生适合造hard negative。我让生成器先输出一个高质量回答再让改进器在保留流畅性的前提下对该回答注入一个逻辑错误、一个数值错误或一个非常隐蔽的立场偏差形成新的错误样本。这一类样本我会控制占比一般占整个偏好数据集的10%左右。如果比例过高奖励模型会变得过于苛刻真实场景中许多尚可接受的中等回答都会被低分剔除。6.3 RL prompt集合的多样性扩充最后一个容易被忽略的点是prompt池的动态更新。RL训练过程中模型能力会逐步提升初始prompt池的难度分布会失真。我会每训练一个阶段就用agentic流程把上一轮产生的bad case转化为新的训练prompt并把当前模型回答不好的样本重新标为“待改进”流入下一轮数据合成。这种做法让数据和训练形成闭环相当于数据流水线也跟着模型一起进化。第一轮RL训练前的prompt池可能只有五千条经过三轮迭代后池子会膨胀到两万条以上而且难度分布明显更接近真实用户的挑战面。7. 常见问题与避坑经验实录7.1 合成数据导致模型塌缩一个严肃警告合成数据占比过高会引发模型退化乃至塌缩。当模型长期只学习自己生成的内容输出分布的多样性会逐渐降低这是一个工程性和统计学上都会出现的问题。我实测下来的经验是关键任务中合成数据占比尽量不要超过总数据的三成其余必须由真实用户请求、人工标注或经过严格验证的高质量样本补足。就算某个领域真实样本很难得也要至少保留一个固定的真实数据池防止模型越学越偏。7.2 评判器和生成器同源导致的“自己夸自己”如果生成器和评判器是同一个模型容易出现“互相包庇”——生成器产出的样本评判器总是给出虚高分数。这不是故意作弊而是模型对自身特征存在系统性偏好解码。破解办法有几招最有效的是让评判器使用完全独立的系统提示并在prompt中明确“你正在审核外部产出的数据可能包含故意设置的错误”如果预算允许用不同厂商或不同代际的模型充当评判在数据流中混入少量已知的、肉眼可察觉的错误样本如果评判器没有把它们挑出来说明评判器已经失灵需要重置或调整。7.3 数据同质化越合成越像合成数据最隐蔽的问题是同质化表面看上每条都不一样但语义空间里高度扎堆。我在去重时会用聚类方法把样本按embedding向量聚类同一类内最多保留若干条强制控制多样性。另外就是多模板、多温度、多角色视角并行生成别贪图省事固定一组prompt一直跑否则模型很快会学到这套prompt的“口音”。7.4 合成数据的事实性错误在知识密集型任务中生成式模型自带幻觉合成数据会不自觉地把错误知识注入模型尤其是mid-training阶段。我现在的做法是“所有关键事实必须可回溯”要求生成器在产出样本时附带来源索引或关键字段再通过检索工具验证。对于验证不了的内容直接降级到人工抽检环节。用真金白银换来的教训是不要相信生成器在事实性上的“自信”它越流利就越要警惕。7.5 什么时候必须人工介入最后聊一个边界问题agentic数据流水线不是万能药。在法律法规、医疗诊断、金融决策等对正确性和责任要求极高的场景模型评判器只能做辅助最终数据必须有人按严谨流程审核。我把人的作用定位成“对评判器进行持续校准”和“处理机器无法判断的边缘case”这两类工作才是人工介入的不可替代之处。建立一套“机器负责产出与初筛、人工负责关键确认”的分工既能享受agentic的效率又能守住质量底线。就我最近一个多月的实际体验来看agentic方式最大的价值不是帮我们生成更多数据而是把“数据质量控制”这件事从事后审查变成了流程内嵌。生成器每一轮进化、批评器每一次反馈、改进器每一轮重写都是一次质量上的筛选和再加工。这套体系跑顺之后你会发现原来需要十几个标注员团队三天完成的工作量现在可能一个算法工程师带两条产线就能扛下来而且数据的结构化和一致性反而更好。后面我打算把线上badcase回流机制做得更细让每个生产环境的失败样本都能自动变成下一轮训练的高价值数据形成真正的数据飞轮。