1. 为什么“造数据”成了模型训练的新瓶颈做过一轮完整模型训练的人都有一个共同感受算法架构的迭代速度远远快于数据准备的速度。以前大家拼的是网络结构、损失函数、优化器现在你打开任何一个训练脚本模型部分往往是几行调用真正吃掉你百分之七十时间的是数据——数据从哪来、怎么洗、怎么标注、怎么配比、怎么保证质量。我最近在做的这个项目核心就是用agentic 的方式去合成和清洗训练数据覆盖三个阶段SFT监督微调、mid-training中期训练、RL强化学习。这三个阶段对数据的需求完全不同如果还用一套流水线去处理基本等于自找麻烦。SFT 要的是“指令-回答”配对的高质量样本mid-training 要的是大规模、多样、带一定噪声容忍度的语料RL 要的是能给出偏好信号或奖励信号的对比数据。用 agentic 的思路来做本质上是把“数据工人”从人换成一组有分工、有工具、有反馈回路的智能体让它们自己去规划、执行、检查、修正。这篇文章适合谁看如果你正在为微调数据发愁或者手头有一堆原始语料但不知道怎么变成可训练格式又或者你已经在跑 RL 但偏好数据质量上不去那这篇内容应该能给你一些可以直接抄的思路。我不讲空泛的“数据很重要”只讲具体怎么让 agent 把脏活干了以及干的过程中哪些坑我替你踩过了。2. 整体设计思路把数据流水线拆成“智能体车间”2.1 为什么是 agentic而不是传统 ETL传统 ETL 的思路是写死规则过滤、去重、格式化。这套东西在结构化数据上很好用但放到自然语言训练数据上就捉襟见肘了。原因很简单——语言的质量判断是模糊的。一条样本“好不好”很难用正则表达式说清楚。你写“长度小于 10 个字符就丢掉”结果把“好的”这种短小精悍的优质回答也扔了你写“包含问号才算指令”结果大量祈使句指令全被过滤。Agentic 方式的核心差异在于让模型自己来判断和决策而不是靠人预先写死的规则。一个数据清洗 agent 可以读一条样本然后输出“保留 / 丢弃 / 改写”的决策并且给出理由。这个理由本身又可以作为下一轮迭代的信号。更关键的是agent 可以调用工具——比如调用一个去重工具、调用一个质量打分模型、调用一个改写模型——形成一个“感知-决策-行动”的闭环。我选择 agentic 而不是纯规则还有一个很实际的原因规则维护成本太高。数据分布一变规则就得重写。而 agent 的 prompt 只需要微调甚至可以通过 few-shot 示例快速适配新领域。这在 mid-training 阶段尤其重要因为那个阶段的数据来源极其杂今天爬的是论坛明天接的是文档规则根本追不上变化。2.2 三个阶段的数据需求差异与 agent 分工先把三个阶段的需求摆清楚不然后面设计 agent 就是瞎设计。阶段数据核心需求噪声容忍度典型数据量级Agent 主要任务SFT指令-回答配对回答质量高、格式规范极低万到十万级合成指令、生成回答、质量校验、格式修正Mid-training大规模、多样、领域覆盖广中等百万到千万级去重、去噪、领域分类、难度分层RL偏好对比对、奖励信号明确低但可接受一定噪声万到百万级生成对比对、偏好标注、奖励模型打分这个表是我在实际项目中反复调整后定下来的。一开始我把 SFT 和 RL 的数据 agent 混在一起做结果发现 SFT 要的“格式规范”和 RL 要的“偏好区分度”经常打架。后来拆成独立的 agent 流水线各自有独立的 prompt 和工具集效率才上来。Agent 的分工我采用的是“规划者-执行者-检查者”三层结构。规划者负责看一批原始数据决定这批数据该走哪条处理路径执行者负责实际调用工具做合成或清洗检查者负责抽样评估把不合格的反馈回去。这个结构不是拍脑袋想的而是因为单层 agent 在处理长流程时容易“忘记”前面的约束三层结构相当于给流程加了短期记忆和纠错机制。2.3 工具选型与基础设施工具层面我用的都是比较成熟的开源组件没有造轮子。合成环节主要靠一个指令生成模型加一个回答生成模型清洗环节用了 MinHash 做近似去重、用一个轻量分类模型做领域打标、用一个 reward model 做质量初筛。Agent 的编排框架我试过几个最后选了一个支持工具调用和状态管理的轻量框架核心要求是能方便地插入自定义工具和记录每一步的决策日志。这里有个经验不要一上来就追求全自动。我最初想让 agent 全自动跑完整个流水线结果发现中间某个环节出错后很难定位。后来改成“半自动”——agent 做决策但关键节点输出中间结果供人工抽查。这个改动让调试效率提升了很多尤其是 SFT 数据合成阶段人工抽查几十条就能发现 prompt 里的系统性问题。基础设施方面数据量大的时候一定要用分布式处理。我的做法是把 agent 的每个处理单元封装成一个可并行执行的任务用消息队列分发worker 数量根据数据量动态调整。存储上原始数据、中间结果、最终数据分三层存放每一层都有版本号方便回滚。这个设计在后来一次 prompt 大改时救了我——新版本效果不好直接切回旧版本的数据继续训练没有耽误进度。3. 核心细节解析合成与清洗的关键环节3.1 SFT 数据合成从种子到高质量指令对SFT 数据合成的起点是种子。种子可以是一小批人工写的指令-回答对也可以是从文档里抽出来的问答。我的做法是先用种子训练一个初版模型然后用这个模型去生成更多指令再用一个更强的模型去生成回答最后用检查 agent 过滤。这个流程听起来简单但每一步都有细节。指令生成阶段我让 agent 从一个主题列表出发每个主题生成多种类型的指令问答、改写、总结、推理、代码生成等。关键是控制指令的多样性不能让 agent 一直生成同一种句式。我的做法是在 prompt 里显式要求 agent 输出指令类型标签然后统计各类别的比例如果某类过多就调整下一轮的采样权重。这个反馈回路是 agentic 方式相比传统模板生成的最大优势——它能根据统计结果动态调整。回答生成阶段我用了两个模型一个强模型生成高质量回答一个弱模型生成“看起来像但可能有错”的回答。强模型的回答用于正样本弱模型的回答经过检查 agent 筛选后用于难负样本。这个设计是为了让 SFT 模型不仅学到“好回答长什么样”还能学到“差回答差在哪”。实测下来加入难负样本后模型在生成时的自我纠错能力有明显提升。质量校验阶段检查 agent 会从几个维度打分事实一致性、格式规范性、回答完整性、是否有害。每个维度用独立的 prompt 让 agent 打分最后加权汇总。这里有个坑不要让一个 agent 同时打所有分因为模型在多任务打分时容易顾此失彼。拆成多个 agent 分别打分虽然调用次数多了但准确率明显更高。3.2 Mid-training 数据清洗去重、去噪与领域分层Mid-training 的数据特点是量大、来源杂、质量参差。这个阶段的核心任务不是“精修”而是“粗筛加分层”。我的流水线是这样的先去重再去噪然后领域分类最后按难度分层。去重我用的是 MinHash LSH这个组合在文本去重上非常成熟。参数上我设置 Jaccard 相似度阈值 0.8 以上视为重复。这个阈值不是随便定的——我抽样了 1000 对样本人工判断发现 0.8 以上基本是重复或高度相似0.7 到 0.8 之间有一部分是“同主题不同表述”这部分我选择保留因为对 mid-training 来说多样性比纯净度更重要。去噪环节agent 会判断每条样本是否“可训练”。判断标准包括是否是完整句子、是否包含有效信息、是否是机器生成的乱码。这里我遇到一个典型问题有些样本看起来是乱码但其实是特定领域的术语或代码。纯规则会误杀agent 通过 few-shot 示例可以学会区分。我的做法是给 agent 提供一批正例和负例让它在 prompt 里学会“什么算噪声”。领域分类我用了一个轻量分类模型把数据分成十几个大类。分类的目的不是为了过滤而是为了后续配比。Mid-training 的数据配比很关键如果某一类数据过多模型会偏科。我的做法是统计各类别的 token 数量然后按目标配比做重采样。这个配比不是固定的而是根据下游任务的表现动态调整。比如发现模型在代码任务上弱就提高代码类数据的采样权重。难度分层是我后来加的一个环节。把数据按“简单、中等、困难”分层训练时先易后难。这个思路借鉴了课程学习实测下来对收敛速度有帮助。难度判断我让 agent 根据句子长度、词汇复杂度、逻辑转折数量来综合打分。这个打分不需要非常精确大致分层就够了。3.3 RL 数据构造偏好对的生成与筛选RL 阶段的数据核心是偏好对——同一个 prompt 下哪个回答更好。构造偏好对有两种方式一种是人工标注成本高但质量好另一种是模型生成成本低但需要筛选。我采用的是混合方式先用模型生成大量候选对再用一个 reward model 初筛最后人工抽查一部分。模型生成偏好对的关键是让两个回答有明确的优劣差异。如果两个回答差不多好标注出来也没意义。我的做法是让生成 agent 刻意制造差异一个回答更详细、一个更简洁一个更准确、一个有小错一个格式规范、一个格式混乱。这样生成的偏好对区分度高训练信号更强。Reward model 初筛阶段我用一个已经训练好的 reward model 给两个回答打分分差小于阈值的对直接丢弃。这个阈值我设的是 0.5假设 reward 范围是 0 到 1。实测下来分差小于 0.5 的对人工标注的一致性也很低说明这些对本身就没有明确的优劣丢掉不可惜。人工抽查阶段我按 5% 的比例抽样重点看两类分差特别大的对、分差接近阈值的对。分差特别大的对如果标错了说明 reward model 有问题分差接近阈值的对如果标对了说明阈值可以调低。这个抽查机制让整个偏好数据集的 quality 可控。3.4 Agent 之间的协作与反馈机制三个阶段的 agent 不是孤立的它们之间有一个反馈通道。具体来说SFT 阶段发现的高频错误类型会作为 mid-training 阶段数据筛选的参考RL 阶段 reward model 打分低的样本类型会反馈给 SFT 阶段调整合成策略。这个反馈通道是我用一套简单的日志系统实现的每个 agent 把决策日志写到统一存储另一个 agent 定期读取日志做统计分析输出调整建议。这个机制的价值在于让数据流水线有了“学习”能力。传统流水线是静态的跑完就完了。Agentic 流水线可以根据下游反馈动态调整上游策略。比如 RL 阶段发现模型在“多轮对话”场景下表现差反馈给 SFT 阶段后SFT agent 会自动增加多轮对话指令的合成比例。这个闭环让整个系统越跑越顺。4. 实操过程从零搭建一条 agentic 数据流水线4.1 环境准备与依赖安装先列一下我用的核心依赖版本就不写死了用比较新的稳定版即可。pip install datasets transformers sentence-transformers pip install minhash-lsh fastapi uvicorn pip install openai anthropic # 按你实际用的模型服务调整 pip install pandas numpy tqdmAgent 编排框架我用的是一个轻量级的开源方案核心是支持工具注册和状态管理。如果你不想引入框架用 Python 的类加装饰器也能实现但状态管理和日志会麻烦一些。我的建议是如果只是做实验手写就够了如果要上生产还是用框架。存储方面原始数据我放在对象存储上中间结果用 Parquet 格式存本地最终数据导出为 JSONL。Parquet 的好处是读取快、压缩率高适合大规模数据。JSONL 的好处是通用几乎所有训练框架都支持。4.2 SFT 数据合成流水线的搭建第一步准备种子数据。我用了 500 条人工写的指令-回答对覆盖问答、总结、改写、推理、代码五个类型。种子不需要多但质量一定要高因为后续合成会放大种子的特点。第二步搭建指令生成 agent。核心 prompt 大概是这样的INSTRUCTION_GEN_PROMPT 你是一个指令生成器。根据给定的主题和类型生成一条指令。 主题{topic} 类型{type} 要求 1. 指令要清晰、具体不要模糊 2. 指令要符合真实用户可能的提问方式 3. 输出格式为 JSON: {{instruction: ..., type: ...}} 这个 prompt 的关键是要求输出 JSON方便后续解析。另外“符合真实用户提问方式”这句很重要不加的话 agent 容易生成教科书式的指令和真实分布差距大。第三步搭建回答生成 agent。我用两个模型分别生成正负样本。正样本用强模型负样本用弱模型。负样本生成后用一个检查 agent 筛选只保留“有明确错误但看起来合理”的样本。第四步搭建质量校验 agent。拆成四个独立 agent事实性检查、格式检查、完整性检查、安全性检查。每个 agent 输出 0 到 1 的分数加权汇总后决定是否保留。第五步跑流水线并抽样评估。我一般抽 100 条人工看重点看三类分数最高的、分数最低的、分数在阈值附近的。这三类能覆盖大部分问题。4.3 Mid-training 数据清洗的完整流程Mid-training 的数据清洗我分五个步骤每个步骤都有对应的 agent 或工具。步骤一格式统一。把各种来源的数据统一成 JSONL每条包含text和source两个字段。这一步用脚本做不需要 agent。步骤二近似去重。用 MinHash LSH阈值 0.8。这一步也不需要 agent纯算法。但去重后我会让 agent 抽样检查确认没有误杀。步骤三噪声过滤。用 agent 判断每条样本是否可训练。Prompt 里给 10 个正例和 10 个负例让 agent 学会判断标准。这一步的准确率大概在 90% 左右剩下的 10% 靠人工抽查兜底。步骤四领域分类。用轻量分类模型打标分成十几个大类。分类模型是我用一批标注数据微调的准确率 85% 左右。分类结果用于后续配比。步骤五难度分层。用 agent 根据句子长度、词汇复杂度、逻辑转折数量打分分成简单、中等、困难三层。这个打分不需要很准大致分层即可。整个流程跑下来1000 万条原始数据大概能留下 600 到 700 万条。这个保留率是合理的太低说明过滤太狠太高说明清洗不够。4.4 RL 偏好数据构造与验证RL 偏好数据的构造我分四步。第一步Prompt 采样。从 SFT 数据里采样一批 prompt覆盖不同任务类型。采样时要注意多样性不能全是同一类任务。第二步回答生成。每个 prompt 生成两个回答用不同的温度参数或不同的模型确保两个回答有差异。第三步Reward model 打分。用 reward model 给两个回答打分分差小于 0.5 的丢弃。第四步人工抽查。按 5% 抽样人工判断偏好标注是否正确。如果错误率超过 10%说明 reward model 需要重新训练或调整。这里有个经验偏好数据的质量比数量重要得多。我试过用 10 万条低质量偏好数据训练效果不如 1 万条高质量数据。所以宁可多花时间筛选也不要为了凑数降低标准。4.5 流水线监控与迭代流水线跑起来后监控很重要。我主要看几个指标各阶段的保留率、agent 决策的分布、人工抽查的准确率。保留率突然下降说明上游数据分布变了agent 决策分布偏移说明 prompt 可能需要调整人工抽查准确率下降说明 agent 的判断标准漂移了。迭代方面我一般两周做一次 prompt 调优。调优的依据就是监控数据和人工抽查结果。调优后先在小批量数据上验证确认效果后再全量跑。这个流程虽然慢但稳。5. 常见问题与排查技巧实录5.1 Agent 决策不一致怎么办这是最常见的问题。同一个 agent同样的输入跑两次结果不一样。原因通常是模型输出的随机性。我的解决办法是降低温度参数把 temperature 设到 0.1 以下。如果还不行就在 prompt 里加“请严格按照示例格式输出”的强约束。另外对于关键决策我会让 agent 输出置信度置信度低的样本转人工。5.2 合成数据多样性不足Agent 生成数据时容易陷入“安全区”反复生成相似的样本。我的解决办法是在 prompt 里加多样性约束比如“不要重复使用相同的句式”“每次生成前先随机选择一个角度”。另外我会定期统计生成数据的 n-gram 分布如果发现某些 n-gram 频率异常高就调整 prompt 或换一个生成模型。5.3 清洗过度导致数据量骤减清洗太狠是新手常犯的错误。我的经验是分阶段清洗第一遍只做最基础的过滤去重、去空保留大部分数据第二遍做质量筛选但阈值设得宽松一些第三遍才做精细筛选。这样即使某一遍过滤太狠后面还有机会补救。另外每一遍清洗后都要抽样检查确认没有误杀。5.4 Reward model 打分偏差Reward model 如果训练数据有偏打分也会偏。我的做法是定期用人工标注的数据校准 reward model发现偏差就重新训练。另外我会用多个 reward model 打分取平均或投票减少单个模型的偏差。5.5 流水线跑得慢Agent 调用是串行的数据量一大就慢。我的解决办法是并行化。把数据分片每个分片起一个 workerworker 内部再并行调用 agent。另外对于不需要 agent 的步骤如去重、格式转换用纯算法处理速度快很多。还有一个技巧是缓存 agent 的决策同样的输入直接读缓存不重复调用。5.6 常见问题速查表问题可能原因排查方法解决办法Agent 决策不一致温度过高、prompt 不明确同一输入跑多次对比降低温度、加格式约束合成数据多样性不足Prompt 约束不够、模型偏好统计 n-gram 分布加多样性约束、换模型清洗后数据量骤减阈值过严、误杀抽样检查被丢弃样本分阶段清洗、放宽阈值Reward model 偏差训练数据有偏人工标注校准重新训练、多模型投票流水线慢串行调用、无缓存计时各阶段耗时并行化、加缓存人工抽查准确率低Agent 标准漂移对比历史抽查结果调 prompt、重新校准5.7 几个我踩过的坑第一个坑一开始没做版本管理。数据、prompt、模型都没有版本号结果一次 prompt 改动后效果变差想回滚都回不去。后来我强制要求所有东西都打版本号数据存三层原始、中间、最终每层都有版本。第二个坑过度依赖自动评估。自动评估指标好看但人工一看发现一堆问题。后来我坚持每个阶段都做人工抽查哪怕比例低一点也要有人看。第三个坑忽略数据配比。Mid-training 阶段我一开始没做领域配比结果模型在某个领域过拟合。后来加了配比环节按目标比例重采样问题才解决。第四个坑Agent prompt 太长。Prompt 太长会导致 agent 忽略后面的指令。我的解决办法是把 prompt 拆成多个短 prompt分步执行。虽然调用次数多了但准确率上来了。6. 一些实操心得与后续扩展方向这套 agentic 数据流水线我跑了大概三个月最大的体会是数据工程正在从“写规则”变成“写 prompt 加搭流程”。以前做数据清洗核心工作是写正则、写过滤条件现在核心工作是设计 agent 的分工、写 prompt、搭反馈回路。这个转变对从业者的要求不一样了——你不需要精通正则表达式但你需要理解模型的行为特点知道它在什么情况下会犯错怎么用 prompt 和工具去约束它。另一个体会是人工抽查不能省。Agent 再聪明也会有盲区。我坚持每个阶段都做人工抽查比例可以低但不能没有。抽查不仅是为了发现错误更是为了理解 agent 的决策逻辑从而优化 prompt 和流程。后续我打算在这几个方向继续扩展一是把 agent 的决策日志做成可视化面板方便监控和调试二是引入主动学习让 agent 主动挑选“最不确定”的样本送人工标注提高标注效率三是把流水线做成可配置的不同项目可以快速复用。最后分享一个小技巧Agent 的 prompt 要定期“体检”。我每个月会把所有 prompt 拿出来重新读一遍看看有没有过时的约束、有没有可以合并的步骤、有没有可以简化的表达。Prompt 和代码一样会随着时间腐化定期维护很重要。