最近一直在折腾训练数据的生产方式，核心关键词就一个：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里的BC（Behavior Cloning，行为克隆）。很多团队在RL阶段会先用BC做初始化，让模型模仿一些高质量的示范，避免RL一开始就自由探索导致崩溃。Agentic数据合成能为BC提供大量演示数据，让起点更高，这是容易被忽略的应用点。
3. 一个可落地的Agentic数据合成/清洗流水线
3.1 完整架构：生成-批评-改进-筛选
整套流水线我设计成五个模块：生成器、批评器、改进器、过滤器、去重器。Mock流程大致如下：
pipeline = [] # 阶段1：生成候选 candidates = generator.generate(seed_pool, num_return_sequences=8, temperature=1.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_threshold=0.85)需要注意，这里四个模块可以由同一个底层模型承担，关键是每个模块使用不同角色设定和prompt模板，避免上下文污染。比如批评器的prompt要完全脱离生成器的指令，只针对“数据质量”本身评判。
3.2 关键环节一：生成器设计，温度与pass@k
生成器负责产出候选样本，参数选择直接影响数据多样性。温度太低，输出千篇一律；温度太高，模型胡言乱语。我用下来相对稳的组合是：生成阶段temperature = 0.8 ~ 1.0，top_p = 0.95，每个seed指令生成4到10个候选（pass@k），然后全部交给评判器选优。
有个细节值得强调：生成器最好使用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回流机制做得更细，让每个生产环境的失败样本都能自动变成下一轮训练的高价值数据，形成真正的数据飞轮。
