做模型训练的人最清楚一件事现在真正卡脖子的已经不是算力而是数据。尤其是你要做一个垂直领域模型或者产品级模型时靠外包标注和人工写 Prompt 的数据生产方式慢、贵、质量还不稳定。我今年先后帮两个团队搭过面向 SFT、mid-training、RL 三个阶段的训练数据管线最终能跑出稳定效果靠的都是同一套思路用 agentic 方式去合成和清洗数据——让模型在受控环境里调用工具、拆解任务、自我校验再决定哪些数据能进训练集。这篇文章把我们的完整方案、管线设计、以及踩过的一些坑写出来。适合正在做垂直大模型、想自己造训练数据、或者被数据质量差反复折磨的团队参考。全文不涉及某个特定平台所有环节都以可复现为目标也会顺便解释为什么有些看似高效的方案实际上一用就翻车。1. 数据不再是标注问题而是生产问题agentic 方式背后的逻辑1.1 先想明白一个转折你在做数据标注还是数据生产很多人第一次听到 agentic 数据合成会以为就是用大模型批量写训练数据。这个理解会害死人。用大模型批量生成数据这种事self-instruct 那批工作早在 2022 年就已经普及了给定少量 seed 种子让模型自己写出更多指令和答案。但纯文本生成面临一个天花板——模型只能凭记忆输出遇到垂域场景时它要么一本正经地编造要么在不同问题之间反复说车轱辘话。比如让一个通用模型直接生成数控机床维修问答它连主轴定位误差刀库乱刀这类故障的真实表现都未必能说准更别说给出可用的排查步骤。agentic 数据合成的根本区别在于它把生成一条数据从单次文本生成任务变成了一个多步执行任务。agent 要先去查资料、调工具、拆任务、做校验最后才产出结论。它不再是凭印象写答案而是做完研究再写答案——这跟真实工程师处理问题的过程是一致的。所以我们内部一直用一句话来区分普通生成是写agentic 是做。数据不是被写出来的是做出来的。1.2 为什么 agentic 比直接让模型生成更可靠拿训练数据最常见的两个痛点来说正确性和覆盖度。正确性方面agentic 方式通过外部工具约束了模型的发散空间。比如让 agent 生成一段代码题数据它可以在沙盒里编译执行跑不过就重新生成直到通过测试用例才允许输出。比如生成医疗问答数据它要求必须从给定的权威文档里检索到对应段落才能作答否则就拒绝回答。这些约束是普通的单次 Prompt 生成完全做不到的。覆盖度方面agentic 方式可以主动规划生成方向。一个简单的 agent 至少包含任务拆解-执行-校验三个环节。在任务拆解阶段它可以先把我要生成一批 SFT 数据这个模糊目标拆成数据包含哪几个领域、每个领域覆盖哪类知识、每类知识对应哪些难度梯度、需要多少条数据再逐个子任务去执行。拆出来的子任务清单本身就能保证覆盖度而不会像盲写一样把 90% 的算力浪费在少数热门话题上。这个差异用生活经验类比一下你让一个新编辑写一批科技类目文章他大概率会写一堆手机评测和 AI 新闻你让他先列出科技类目下的一级分类每个分类对应的人群、核心话题、信息缺口再逐类做选题和查证产出的内容结构会完全不同。agentic 数据合成本质上就是把后者的工作流自动化了。1.3 但 agentic 不是银弹什么时候不该用也得说实话agentic 数据合成的代价是——慢且贵。一次普通的数据生成调用如果是单次 Prompt 直接出结果成本可能是几厘钱。换成 agent 模式一次生成需要多轮推理、多次工具调用成本可能直接放大 5 到 20 倍延迟也从秒级变成几十秒甚至分钟级。所以我们在项目启动前都会先做一个 ROI 判断。如果任务满足以下条件就别用 agentic数据量需求只有几百条人工一天就能写完任务是纯改写类比如把口语改成书面语、把短句扩写成长句不需要外部知识对答案正确性要求不高只需要风格多样性。反过来说只要数据规模上千、领域知识密度高、或者模型会拿这些数据做 RL 这种一步错步步错的训练agentic 的投入就非常值得。边界划清楚了下面讲具体管线。2. SFT 数据合成让 agent 先拆任务再写答案2.1 SFT 数据真正挑的不是多而是结构SFT监督微调阶段对数据的要求跟很多人想的并不一样光有指令和答案还不够关键是——指令分布能不能覆盖真实使用场景、答案能不能体现正确的推理过程、以及格式能不能保持一致。真实使用场景这一点最容易被忽视。很多团队做 SFT 数据时喜欢让大模型生成一堆高质量专家问答结果模型上线后用户问的是你帮我看看这个报错是什么意思这个按钮点不了怎么办这类具体问题数据里根本没有。Agent 在拆任务阶段能帮我们解决这个问题它可以从产品需求、用户反馈工单、竞品常见问答里提炼出真实用户的提问模式再基于这些模式生成 SFT 数据。答案的推理过程也一样。数据里如果只有结论模型学到的就是抄答案如果答案带分析-查证-推导的过程模型学到的才是解决类似问题的能力。Agent 恰恰可以把这种推理过程显式地写进数据生成流程里。2.2 我们实际用的一套 agentic SFT 数据管线下面是我们目前跑得比较顺的一条 SFT 数据合成管线步骤写出来供参考也方便做改造第一步准备领域知识库。把产品文档、工单记录、技术手册、规范文件全部清洗后存入向量库并做好来源分级官方文档优先级 技术博客 论坛帖。这一步决定了后续 agent 检索的上限知识库质量差后面生成的数据再好也是空中楼阁。第二步让 agent 做任务拆解和知识缺口分析。给 agent 一个选题规划任务它会先读取一批真实用户问题再对照知识库输出一个生成计划包含今天要覆盖哪几个主题、每个主题下有哪些子问题、哪些问题在知识库中检索不到答案、需要额外补充什么资料。我们会人工过一眼这个计划再放行避免生成方向跑偏。第三步检索增强 答案生成。agent 针对每个选题先从知识库检索相关文档片段然后把检索到的内容 用户提问 思维链指引拼接成生成 Prompt。生成时要求 agent 写出完整的分析过程并且必须标注每个关键结论引用了哪份文档。这一步有个小技巧对同一个问题让 agent 用三种不同的思维链模板各生成一遍再人工/模型挑选最好的一条。多样性会显著提升。第四步自我校验。agent 会把自己生成的答案重新读一遍对照原始检索内容检查是否存在结论与引用不符、是否遗漏了用户提问中的关键条件、是否有逻辑跳跃。校验不通过就回到第三步重写最多重试 3 次。第五步规则引擎 judge 模型双重过滤。规则引擎负责处理硬性指标比如长度过短、包含敏感词、与已有数据高度重复用 MinHash 或 embedding 相似度。Judge 模型负责质量打分维度包括指令清晰度、答案正确性、逻辑完整度、格式合规每项 1-5 分低于阈值直接删除。伪代码大概是这种感觉pipeline AgentPipeline([ TaskPlanner(plancover_high_freq_topics, sourceuser_feedback), KnowledgeRetriever(top_k5, sourcevector_db), AnswerGenerator(chain_of_thoughtstructural), SelfChecker(max_retry3), RuleFilter(min_length50, dedup_threshold0.85), JudgeScorer(min_score4.0) ]) records pipeline.run(num_records5000)2.3 质量过滤的几道关卡一个都别省我见过不少团队在生成环节花了大精力却在过滤环节偷懒最后数据一锅端进训练集效果自然惨淡。我们现在的过滤是四层结构关卡方法拦截目标第一层规则过滤器长度、字段完整性、敏感词黑名单结构性垃圾数据第二层重复清洗MinHash、embedding 聚类去重语义重复数据第三层Judge 模型打分指令清晰度、答案正确性、格式合规低质量生成结果第四层黄金集人工抽检每天随机抽 3% 人工标注审核评估整条管线健康度第三层的 judge 模型我们用的是比生成模型小一档的开源模型。为什么一方面省钱另一方面是防止生成模型和判断模型是同一个出现自说自话的偏差。实际跑下来小模型打分和大模型打分的一致性在 90% 左右但成本差了近 10 倍很划算。每层的通过率也要监控。比如第三层 judge 打分低于阈值的比例如果超过 20%通常不是数据质量问题而是上游知识库太弱或选题计划出了问题要回溯修复而不是硬调过滤阈值。2.4 一组参考效果加了 agentic 清洗之后SFT 效果提升多少这里给一个我们项目里的真实参考数据方便大家心里有个预期。同样是用 2 万条 SFT 数据做微调对照组是普通 self-instruct 批量生成 规则去重实验组是上面这套 agentic 管线。在垂直领域的测试集上实验组的整体准确率提升了约 9 个百分点更明显的是指令遵循率模型能不能严格按用户指定的格式输出提升了近 20 个百分点。原因并不玄学。普通批量生成的答案经常是洋洋洒洒一大篇但没回答真正的问题agentic 管线由于每一条都经过了检索→生成→自检→判分的流程天然把答案是否回答了问题是否有证据支撑固化进了生成要求里模型学到的自然就更听话、更准确。3. mid-training 数据的清洗与重构agent 的身份是编辑不是作家3.1 mid-training 和 SFT 的数据要求完全不是一个画风mid-training也叫领域继续预训练或连续预训练是这几年才开始被更多团队重视的阶段在通用预训练之后、SFT 之前用大规模领域文本继续训练模型让模型先学会领域语言和领域知识再去做指令跟随。它和 SFT 的核心区别在于——SFT 学的是怎么回答mid-training 学的是这个领域长什么样。这个区别直接决定了数据处理的策略。SFT 数据追求的是指令-答案的配对质量mid-training 数据追求的是领域文本的覆盖度、正确性、结构完整性。你给 mid-training 塞一堆噪声大、术语乱、章节断裂的文档模型先学会了错误的领域表达后续 SFT 和 RL 怎么拉都拉不回来。幻灭的是很多团队把爬下来的原始文本直接灌进模型根本没有做语义级清洗。3.2 从规则清洗到语义级清洗agent 能多做哪些事传统清洗做的是规则层面的工作去 HTML 标签、去乱码、去超短段落、按语言过滤。这些做完了文本看起来是干净了但语义层面的问题一点没解决——术语前后不一致、文档章节顺序错乱、技术内容已经过时、把广告和正文混在一起。Agent 在这种场景下最适合扮演的角色不是作家而是编辑。我们让 agent 处理一份技术手册时会给它这样的工作流通读全文识别文档类型和结构用户手册/API 文档/故障排查指南抽出关键术语表检查术语在全文中的使用是否一致不一致的标注出来并统一成最规范的形式检查文本逻辑顺序比如先报错再给解决方案的步骤是否被拆到了不同章节如果拆散了就重组把明显的过时信息比如已废弃接口、旧版本参数标记出来如果知识库里有新版本资料就把过期段落替换或删掉输出清洗后的文本 一份变更说明。这套流程放到纯规则工具里是不可能实现的但 agent 天然擅长。成本确实更高但 mid-training 是一次性投入清洗质量直接决定后面所有阶段的上限这笔钱值得花。3.3 用 agent 给领域文本做结构化——很多人忽略的高收益操作除了清洗agent 还能给 mid-training 文本做一层结构化增强这是比较容易被忽略但收益很高的操作。做法是让 agent 在清洗完一段文本后额外生成一段结构化元信息——这段文本所属的领域标签、知识类型事实性知识/流程性知识/经验性知识、难度等级、适用的下游任务类型。然后把这些元信息和原文拼接后一起送入 mid-training。这样做的好处很直接模型在 pre-training 阶段就能建立领域-知识类型-语言风格的关联后续 SFT 时它已经预判了不同场景下该用什么知识体系和表达方式。我们做过对比实验加了元信息结构的 mid-training 数据在后续 SFT 的领域测试集上比不加速率高出 3~5 个百分点。成本几乎为零效果却很稳定。3.4 清洗质量怎么验证不能靠看起来干净了清洗完的数据不能只看网络爬虫抓下来的文本变干净了就放行。我们一般做三个维度的检查第一个是困惑度检查。用一个固定的预训练语言模型分别计算清洗前后文本的平均困惑度。如果清洗后困惑度显著降低说明文本更符合自然语言的统计规律这个方向是对的如果困惑度异常高说明清洗可能破坏了文本结构比如过度删减导致句子不完整。第二个是知识性抽测。把清洗后的文本作为知识源让一个 RAG 模型在上面回答人工设计的问题看能答对多少。这能直接验证清洗过程中有没有误删关键内容、术语统一有没有引入错误。第三个是人工抽检。每天抽 50 篇清洗结果人工快速判断结构是否保留、术语是否正确、是否有多删或漏删。我建议在 mid-training 期间一定要留一个专职的数据质检角色哪怕是兼职。数据管线不是跑起来就完事要持续盯指标。4. RL 阶段用 agent 规模化生产偏好对绕开人工标注的泥潭4.1 RL 数据是什么它为什么比 SFT 数据更难搞RL强化学习阶段需要的数据和 SFT 完全是两个物种。SFT 需要的是问题和标准答案RL 需要的是偏好对——同一问题下哪个回答更好、好在哪里。传统做法是找人标注偏好但人类标注的问题非常明显不同标注员对好回答的标准不一致同一个标注员在不同时间也会漂移尤其面对两个都还行的回答时标注人会崩溃最终给出一堆噪声标签。所以我一直认为RL 数据生产是最适合 agentic 化的环节因为偏好判断本质上需要做事的能力而不只是打分的能力——你得先能判断这个回答在实际场景中是否可行才能判断哪个更好。而这正是 agent 可以发挥作用的地方。4.2 让 agent 在环境里做任务用轨迹自动构造偏好对我们做的最多的偏好对生产方式是让 agent 去执行任务然后根据执行结果产生正负样本。这里借用了 RLVR可验证奖励强化学习的思路。以代码生成模型的 RL 数据为例Agent 拿到一个问题描述后生成一段代码然后在沙盒里实际执行编译、跑单测如果编译失败或单测跑不过这条数据自动标记为 rejected 样本如果跑通了并且产物逻辑正确自动标记为 chosen 样本最终形成的偏好对是同一个问题上成功路径 vs 失败路径的对比而不是两个模型输出的人工主观比较。这个方案的精妙之处在于偏好信号的来源是环境反馈编译是否通过、测试是否通过而不是人的主观判断。它客观、可复现、天然规模化。类似的思路可以用在数学题上让 agent 生成题解再用另一个推理模型验证最终答案是否一致、工具调用场景agent 调用 API 后看是否返回预期结果。4.3 偏好对的两个致命陷阱对比不明显和标签错位偏好对生产出来了不等于可以直接用。有两个坑必须处理。第一个坑是对比不明显。如果 chosen 和 rejected 两条回答质量只差一丁点模型根本学不到东西。我们在生成偏好对时会强制要求两条回答在质量上有显著差异比如一条是完整执行并成功另一条是只写了开头或逻辑明显有误。对于差异不够大的数据直接丢弃不要硬凑训练集。第二个坑是标签错位——chosen 样本未必真的优于模型当前策略。RL 训练中如果偏好对里的 chosen 回答和模型自身产出差距过大模型会无所适从。我们会在每个偏好对上额外加一个 agent judger 做一致性检查让一个独立的判断 agent 对比chosen vs rejected和模型当前策略输出 vs rejected如果判断结果矛盾就剔除这条数据。4.4 用 RLVR 思路验证合成偏好数据的闭环质量最后说一个我们验证偏好数据整体质量的办法把偏好信号和可验证奖励连接起来做闭环。数学和代码场景里每个偏好对里的 chosen 回答要过一遍可验证奖励数学题用最后答案核验代码题用测试用例只有奖励通过的数据才能进入训练集。这样一来偏好数据里的 chosen 侧就有双重保证agent 路径执行成功 规则验证通过。这套闭环跑稳以后RL 阶段基本不依赖人工标注了。我们的实际体验是只要把偏好对的生产管线建好人工只需要做很小比例的抽检和异常分析产能提升非常明显。5. 整套管线落地时最容易踩的三个坑以及我的处理方法5.1 数据泄漏agent 合成数据污染测试集agentic 方式生成数据时最容易忽略的坑是数据泄漏。因为我们用了检索增强agent 在生成训练数据时可能会搜到测试集样本或测试集样本的变体导致训练集和测试集高度相似训练指标好看得离谱上线效果却一塌糊涂。我们的处理方法在启动 agentic 管线之前先把测试集锁定并且把测试集的所有文本做向量化、建立专属索引。每生成一条训练数据都要和测试集索引做一次相似度检索相似度超过 0.85 就直接删除。另外团队内部会严格执行训练数据生成时禁止引用测试集相关文件从源头上掐断泄漏路径。5.2 成本失控多步调用的开销比想象中大得多前面提到过 agentic 化会让生成成本放大 5 到 20 倍这里补充两个实际控制手段。第一是缓存和复用。检索结果、任务拆解结果、以及高频的中间推理片段都可以缓存同一批数据生成时直接复用避免每个问题都重新跑一遍全链路。实测下来缓存能把成本降低 40%。第二是小模型先粗筛大模型再精加工。先用一个便宜的小模型做初步生成和规则过滤把明显不合格的数据扔掉只让能力更强的大模型 agent 处理通过初筛的候选数据。这样做能去掉差不多 50% 的无效生成整体成本能控制在普通生成方式的 3~5 倍左右而不是 20 倍。5.3 幻觉被循环放大agent 从错误文档里学到了自信的谬误最后一个坑最隐蔽agent 在检索和生成过程中可能把一份本身错误或过时的文档当作权威来源然后生成一条看起来很自信但完全错误的训练数据。如果这条数据进了 SFT 或 RL 数据集模型会有样学样地输出自信的谬误。所以我们在 agent 任务里给引用来源设了硬性要求不标注来源的数据一律判定不合格。同时每天会跑一个交叉验证脚本随机抽 5% 的生成数据用一个不同的模型或不同 Prompt 的同一模型重新做一遍知识核验不一致率超标的批次直接召回重做。这块我多说一句数据管线不是一锤子买卖要像运维线上服务一样持续监控。我们每周都会统计各环节的通过率、成本、抽检不一致率任何指标出现明显波动都要立刻回溯排查。很多团队把数据管线搭完就当自动运行了往往就是在这个环节翻车的。最后分享一个我在实际使用中的心得体会如果你只打算从这篇文章里带走一样东西我希望是这句话agentic 数据管线真正的价值不在于把生成过程变复杂而在于把不可控的模型发挥变成了可控的生产流程。模型仍然会犯错但你有机会在数据进入训练集之前通过检索约束、执行验证、多级过滤把错误拦截下来。另外坦白讲这套体系不是一上来就能跑通的。我们最开始也是从简单的 self-instruct 开始一步步加检索、加自检、加 judge、加 RLVR 验证中间推翻过两版管线才形成现在这套相对稳定的方案。当前这套虽然不能覆盖所有场景但只要你抓住拆任务、查资料、做校验、看证据这四板斧适配到自己的领域只是时间和工程投入的问题。祝大家都能造出干净、可控、够用的训练数据。