训练数据的质量直接决定了模型能力的上限这个判断在SFT、mid-training和RL三个阶段都成立但每个阶段对好数据的定义完全不同。SFT要的是指令跟随的示范mid-training要的是知识密度和领域覆盖RL要的是可判别的偏好信号。用同一套清洗流水线处理三个阶段的数据是我见过最常见的资源浪费。这篇内容围绕agentic方式合成与清洗训练数据展开把三个阶段的数据需求差异、agentic流水线的设计逻辑、以及实际跑起来会遇到的问题拆开讲清楚。适合正在搭建数据管线、或者准备从人工标注转向自动化合成的朋友参考。1. 三个阶段对训练数据的诉求根本不是一回事很多人把SFT、mid-training、RL的数据处理混在一起做结果就是SFT数据太干净导致模型学不到多样性RL数据太脏导致奖励信号噪声过大。先把三者的差异理清楚后面流水线的设计才有依据。1.1 SFT阶段要的是像人一样回答的示范质量SFT的本质是行为克隆模型学的是面对这类输入应该输出什么样的回复。这个阶段的数据核心指标不是知识量而是格式一致性、指令跟随度、回复风格稳定性。一条SFT样本如果知识密度很高但格式混乱对模型的伤害大于收益因为模型会学到不稳定的输出模式。实际操作中SFT数据的清洗重点在几个维度指令和回复是否语义对齐、回复是否完整有没有截断、是否包含不该出现的元信息比如作为一个AI这类模板残留、多轮对话的轮次边界是否清晰。这些检查用规则能做一部分但语义对齐和完整性判断必须靠模型来判这就是agentic方式介入的第一个切入点。1.2 Mid-training阶段要的是知识密度和领域覆盖广度Mid-training介于预训练和SFT之间目标是把通用基座往特定领域推一把同时保持语言能力不退化。这个阶段的数据需求跟SFT完全相反要的是高知识密度、长文本、领域覆盖广格式反而没那么重要甚至适度的噪声能提升鲁棒性。典型场景是垂直领域模型比如法律、医疗、工业检测。mid-training数据往往来自领域文档、技术手册、专业论文清洗的核心是去重、去模板化、保证知识准确性。这里agentic方式的价值在于用agent去判断一段文本的知识密度、是否包含有效领域信息、是否存在事实性错误比单纯用规则过滤精准得多。1.3 RL阶段要的是可判别的偏好信号RL这里主要指RLHF/DPO这类偏好优化的数据核心是偏好对的质量。一条偏好样本包含prompt、chosen、rejected三部分模型学的是为什么chosen比rejected好。这个阶段最怕的是chosen和rejected差异太小模型学不到信号或者差异来自无关因素比如长度差异而非质量差异。RL数据的清洗难点在于偏好判断本身是主观的需要agent模拟人类偏好判断同时要控制偏差。比如如果所有chosen都比rejected长模型会学到长就是好这个错误信号。agentic方式在这里要做的是多维度偏好评估而不是单一打分。阶段核心指标数据形态清洗重点agentic介入点SFT格式一致性、指令跟随度指令-回复对语义对齐、完整性语义质量判定Mid-training知识密度、领域覆盖长文本语料去重、事实性知识密度评估RL偏好信号可判别性偏好三元组差异有效性、偏差控制多维度偏好判断2. Agentic合成流水线的骨架怎么搭Agentic方式的核心思路是不再用固定的规则或单一模型做一次性过滤而是让多个agent分工协作每个agent负责一个维度的判断通过多轮交互逐步提升数据质量。这套思路在三个阶段通用但具体agent的配置不同。2.1 为什么不用单一模型做端到端清洗我最早的做法是拿一个强模型做端到端的数据打分输入一条样本输出一个质量分低于阈值就丢掉。跑了一段时间发现两个问题一是打分不稳定同一条样本换个prompt分数能差0.3二是无法定位问题分数低但不知道为什么低没法针对性修复。Agentic方式解决的就是这两个问题。把清洗拆成多个独立维度每个维度一个agent每个agent只回答一个具体问题比如这条回复是否完整判断的稳定性和可解释性都大幅提升。而且多个agent的判断可以交叉验证减少单点误判。2.2 合成agent和清洗agent的分工流水线里其实有两类agent合成agent负责生成数据清洗agent负责评估和过滤。合成agent的输入是种子数据或领域知识输出是候选样本清洗agent的输入是候选样本输出是质量标签和修复建议。合成agent的设计要点是多样性控制。如果让一个agent反复生成输出会高度同质化。常见做法是给合成agent配置不同的角色和风格参数比如同一个问题让agent分别以专家口吻、新手口吻、简洁风格、详细风格生成这样产出的数据分布更接近真实场景。清洗agent的设计要点是维度正交。每个agent只负责一个维度维度之间尽量不重叠。比如事实准确性和逻辑一致性是两个维度不要合并成一个质量维度否则判断会互相干扰。2.3 多agent协作的编排逻辑Agent之间的协作方式直接决定了流水线的效率和效果。我试过三种编排方式各有适用场景。串行编排agent按顺序执行前一个的输出是后一个的输入。适合有明确依赖关系的维度比如先判断完整性再判断语义对齐截断的样本没必要做语义判断。优点是省算力缺点是前面的误判会传导到后面。并行编排多个agent同时评估同一条样本最后汇总。适合独立维度比如事实性和格式规范可以并行判断。优点是快缺点是无法做依赖判断。投票编排同一个维度用多个agent或同一agent多次采样判断取多数结果。适合主观性强的维度比如偏好判断。优点是稳定缺点是算力开销大。实际生产里通常是混合编排先并行做基础维度过滤再串行做深度判断关键维度加投票。下面是一个典型的编排配置# 伪代码示意展示编排逻辑 pipeline { stage_1_parallel: [ {agent: completeness_checker, threshold: 0.9}, {agent: format_validator, threshold: 0.95}, {agent: dedup_checker, threshold: 0.85} ], stage_2_serial: [ {agent: semantic_alignment, depends_on: completeness_checker}, {agent: knowledge_density, depends_on: semantic_alignment} ], stage_3_voting: [ {agent: preference_judge, samples: 3, vote: majority} ] }注意阈值不是拍脑袋定的要先用一批人工标注的样本做校准找到每个维度上agent判断和人工判断的一致率再反推阈值。我一般要求关键维度的一致率在0.85以上才敢上线。3. SFT数据合成从种子到高质量指令对SFT数据合成的难点在于既要保证质量又要保证多样性。纯人工写成本太高纯模型生成又容易同质化。Agentic方式的思路是用种子数据驱动让agent在种子基础上做受控扩展。3.1 种子数据的选取和扩展策略种子数据是整个合成流程的起点质量直接决定上限。我一般从三个来源取种子真实用户日志脱敏后、人工精写的少量高质量样本、领域专家整理的典型问题集。种子数量不用多几百条就够关键是覆盖要广。扩展策略上我常用的是指令改写回复重生成和场景迁移两种。指令改写是保持任务意图不变改变表达方式比如把帮我写一个排序算法改写成我需要对一个数组排序给我个实现。场景迁移是保持任务类型不变改变应用场景比如把Python排序迁移到Java排序。这里有个坑改写幅度要控制。改太小数据同质化改太大可能改变任务意图导致指令和回复不匹配。我的经验是改写后的指令和原指令的语义相似度控制在0.6到0.85之间比较合适低于0.6可能跑偏高于0.85等于没改。3.2 用agent做指令多样性的主动控制被动等待agent生成多样化数据效率太低更好的做法是主动控制。具体来说给合成agent维护一个已覆盖意图的向量库每次生成前先检索当前样本和已有样本的相似度如果太相似就换一个生成方向。这个机制实现起来不复杂把每条已生成样本的指令做embedding存起来新样本生成前先算和库里的最大相似度超过阈值就重新生成。阈值一般设在0.9左右太严会导致生成效率极低太松起不到去重作用。更进一步的做法是给agent显式指定生成维度。比如维护一个任务类型×领域×难度的三维网格每次生成时选一个还没充分覆盖的格子让agent在这个约束下生成。这样能保证覆盖的均衡性避免某个类型的数据过多。3.3 回复质量的agent评估链路指令生成完之后回复质量是决定SFT数据能不能用的关键。我设计的评估链路分四步第一步是完整性检查判断回复是否被截断、是否答非所问。这一步用规则轻量模型就能做成本低。第二步是事实性检查判断回复中的事实陈述是否正确。这一步需要agent有领域知识或者能调用外部工具验证。对于代码类回复直接跑一遍测试用例是最可靠的。第三步是风格一致性检查判断回复风格是否符合目标场景。比如客服场景要礼貌专业技术问答要直接准确。这一步用agent做风格分类。第四步是指令跟随度检查判断回复是否真的完成了指令要求。这一步最容易出问题因为模型经常答了但没完全答。我一般让agent逐条对照指令的要求点检查回复是否都覆盖了。# 指令跟随度检查的prompt设计示意 follow_instruction_prompt 给定指令和回复逐条检查回复是否完成了指令的每个要求。 指令{instruction} 回复{response} 请输出 1. 指令包含的要求点列表 2. 每个要求点是否被回复覆盖是/否/部分 3. 整体跟随度评分0-1 提示指令跟随度检查是最容易被忽略但最重要的一步。我见过太多数据指令和回复看起来相关但实际没完成要求这种数据训出来的模型会假装回答表面流畅但答非所问。4. Mid-training数据清洗知识密度优先Mid-training数据的清洗逻辑和SFT完全不同。SFT是少而精mid-training是多而广但要保证知识有效。这个阶段的数据量通常比SFT大一到两个数量级清洗策略必须考虑吞吐。4.1 知识密度的agent判定方法知识密度是mid-training数据的核心指标但它的定义很模糊。我的操作化定义是单位文本中包含的有效领域信息量。有效领域信息指的是能提升模型领域能力的知识比如专业术语、领域事实、技术细节而不是套话、过渡句、重复表述。用agent判定知识密度我用的方法是让agent做信息抽取而不是打分。具体来说让agent从一段文本中抽取所有领域相关的知识点然后看抽取出的知识点数量和文本长度的比值。这个方法比直接打分稳定因为抽取是相对客观的任务打分太主观。实际操作中我会让agent输出结构化的知识点列表然后统计知识点数量、知识点平均长度、知识点之间的独立性是否重复。这三个指标组合起来能比较准确地反映知识密度。4.2 去重不只是文本相似度Mid-training数据的去重比SFT复杂得多因为领域文档里大量存在换种说法讲同一件事的情况。单纯用文本相似度去重会漏掉语义重复用语义相似度去重又容易误杀把相关但不同的内容当成重复。我的做法是分层去重第一层用精确匹配和n-gram相似度去掉明显重复第二层用embedding相似度去掉语义高度重复的第三层用agent判断两段文本是否在讲同一个知识点这一层只对前两层判定为疑似重复的样本做控制成本。第三层的agent判断要设计好prompt让agent关注知识点而不是表述。比如两段文本都在讲梯度下降的学习率设置即使表述完全不同也应该判为重复。而一段讲学习率设置一段讲动量优化即使都涉及优化器也不应该判为重复。4.3 事实性错误的检测与修复Mid-training数据里的事实性错误是最危险的因为模型会把这些错误当成知识学进去。检测事实性错误纯靠模型判断不可靠因为模型本身可能就不知道正确事实。我的做法是结合外部知识源。对于有明确知识源的领域比如有权威手册、标准文档用检索比对的方式检测。把待检测文本里的关键事实抽出来去知识源里检索比对是否一致。对于没有明确知识源的领域用多agent交叉验证让多个agent独立判断某个事实陈述是否正确取多数结果。修复比检测更难。有些错误能自动修复比如明显的笔误、单位错误有些只能丢弃。我的原则是能确定正确值的自动修复不能确定的直接丢弃不要试图猜正确值猜错了危害更大。错误类型检测方法处理策略数值/单位错误规则知识源比对可确定则修复否则丢弃事实陈述错误多agent交叉验证多数判错则丢弃过时信息时间戳知识源标注时效性谨慎使用逻辑矛盾agent一致性检查丢弃或人工复核5. RL偏好数据的构造与偏差控制RL阶段的数据构造是三个阶段里最微妙的因为偏好本身是主观的而且很容易引入系统性偏差。Agentic方式在这里的价值是能做多维度的偏好评估而不是单一打分。5.1 偏好对的构造chosen和rejected怎么来偏好对的来源主要有三种人工标注、模型生成对比、真实用户反馈。人工标注质量最高但成本高模型生成对比成本低但需要控制质量真实反馈最真实但噪声大。模型生成对比的常见做法是同一个prompt用不同模型或不同参数生成多个回复然后让agent判断哪个更好。这里的关键是确保对比的回复在质量上有明确差异如果两个回复质量接近偏好信号就很弱模型学不到东西。我的经验是chosen和rejected的质量差异要足够大让agent判断时能有明确的理由。如果agent判断时犹豫不决这条样本大概率是低效的应该丢弃或重新构造。5.2 用agent模拟人类偏好的多维度评估单一维度的偏好判断比如哪个更好信息量太低而且容易受表面因素影响。我用的方法是让agent从多个维度分别评估然后综合。常用的评估维度包括准确性事实是否正确、有用性是否解决了问题、完整性是否覆盖了要点、表达质量是否清晰流畅、安全性是否有不当内容。每个维度单独打分最后加权综合。这样做的好处是能定位偏好差异的来源。如果chosen在准确性上更好但表达质量更差这条样本可以用来训练模型准确性优先如果差异主要来自表达质量那这条样本训练的是表达优化。不同来源的样本对模型的影响不同分类管理能让训练更可控。5.3 长度偏差和位置偏差的识别与消除偏好数据里最常见的两个偏差是长度偏差和位置偏差。长度偏差是指chosen系统性地比rejected长模型会学到长就是好。位置偏差是指在标注时排在前面或后面的选项更容易被选为chosen。识别长度偏差很简单统计chosen和rejected的长度分布如果差异显著就说明有偏差。消除的方法是做长度匹配在构造偏好对时控制chosen和rejected的长度差异在一定范围内或者对长度差异大的样本做降权。位置偏差的识别需要做对照实验把同一对样本正序和逆序各标注一次看选择是否一致。如果正序选A逆序也选A说明是真实偏好如果正序选A逆序选B说明有位置偏差。消除方法是在训练时随机打乱chosen和rejected的顺序或者在标注时做双向标注取一致结果。# 长度偏差检测示意 def check_length_bias(preference_data): chosen_lens [len(d[chosen]) for d in preference_data] rejected_lens [len(d[rejected]) for d in preference_data] avg_chosen sum(chosen_lens) / len(chosen_lens) avg_rejected sum(rejected_lens) / len(rejected_lens) bias_ratio avg_chosen / avg_rejected # bias_ratio 接近1说明无明显偏差 # 大于1.2或小于0.8说明有明显长度偏差 return bias_ratio注意长度偏差在RL训练里特别隐蔽因为模型确实可能学到详细回答更好这个合理偏好但过度了就会变成啰嗦。我一般会把长度偏差控制在1.1以内超过就做长度匹配处理。6. 流水线跑起来之后的真实问题前面讲的都是设计层面的东西实际跑起来会遇到一堆设计时想不到的问题。这部分分享几个我踩过的坑和对应的处理方式。6.1 Agent判断的一致性和稳定性问题Agent判断不稳定是最大的痛点。同一条样本同一个agent换个时间跑结果可能不一样。这个问题在温度参数大于0时尤其明显。我的处理方式是关键维度用温度0跑牺牲一点多样性换稳定性非关键维度可以用温度0.3左右但要做多次采样取多数。另外prompt的措辞对稳定性影响很大我一般会把prompt固定下来改动前先做一致性测试。还有一个容易被忽略的点是agent的疲劳效应。如果让一个agent连续判断大量样本后面的判断质量会下降可能是上下文累积导致的。我的做法是定期重置agent的上下文或者用多个agent实例轮换。6.2 合成数据的同质化陷阱合成数据跑一段时间后你会发现生成的数据越来越像。这是因为合成agent在生成时会受到已有数据的影响形成正反馈循环。打破同质化的方法有几个一是定期引入新的种子数据给流水线注入新鲜血液二是给合成agent加随机性比如随机选择生成风格、随机组合任务要素三是定期做多样性审计统计生成数据的分布发现某个类型过多就调整生成策略。我一般每周做一次多样性审计看几个指标指令的embedding分布熵、任务类型的覆盖度、回复长度的分布。如果熵下降或者覆盖度收窄就说明同质化在加剧需要干预。6.3 成本控制和吞吐优化Agentic流水线的成本主要来自模型调用。如果每个维度都用大模型成本会高到不可接受。我的优化策略是分层用模型简单维度用轻量模型或规则复杂维度用大模型。具体来说完整性检查、格式校验、去重这些用规则或小模型就够语义对齐、知识密度、偏好判断这些需要大模型。另外能批处理的尽量批处理能缓存的尽量缓存比如同一条样本的embedding算一次就存下来。吞吐优化上并行化是关键。多个agent能并行跑的绝不串行多个样本能批量处理的绝不单条处理。我用的是异步任务队列把每个agent调用封装成任务统一调度这样能充分利用并发。优化方向具体做法预期收益模型分层简单维度用小模型/规则成本降50%以上批处理样本批量送agent吞吐提升3-5倍缓存embedding、判断结果缓存重复计算减少并行独立维度并行执行延迟降低采样非关键维度降低采样率成本可控6.4 人工抽检怎么做才有意义完全依赖自动化是不现实的人工抽检是最后一道防线。但抽检怎么做很有讲究随机抽检效率太低因为大部分数据是合格的。我的做法是分层抽检对agent判断置信度低的样本重点抽检对置信度高的样本少量抽检。置信度可以用agent多次采样的方差来衡量方差大说明agent自己都不确定这些样本最值得人工看。另外抽检要关注边界样本也就是刚好在阈值附近的样本。这些样本是判断标准最模糊的地方也是错误最容易发生的地方。我一般会把阈值附近的样本单独拿出来人工确认判断标准是否合理。抽检的结果要反馈到流水线里。如果发现某类样本误判率高就调整对应的agent prompt或阈值。这个反馈循环是流水线持续优化的关键不能省。7. 一些实操层面的经验补充最后分享几个零散但实用的经验都是实际跑流水线时积累的。关于prompt设计我最大的体会是具体比抽象好。让agent判断质量好不好不如让它判断回复是否包含指令要求的全部三个要点。具体的判断任务agent做得更准也更容易验证。关于阈值设定不要追求一步到位。先设一个宽松的阈值跑起来看数据分布再逐步收紧。我一般会先跑一批数据看agent打分的分布然后根据目标保留率反推阈值。比如想保留70%的数据就取打分的70分位数作为阈值。关于数据版本管理这个太重要了。每次调整流水线改prompt、改阈值、换模型都要记录并且保留调整前后的数据样本做对比。不然出了问题根本不知道是哪次改动导致的。我用的是简单的版本号变更日志够用。关于评估不要只看流水线的通过率要看下游任务的效果。流水线通过率高不代表数据好最终还是要看训出来的模型在目标任务上的表现。我一般会做小规模的训练验证用少量数据快速训一版看效果再决定是否全量跑。关于迭代节奏数据流水线不是一次搭好就完事的需要持续迭代。我的节奏是每周做一次小调整调阈值、改prompt每月做一次大调整改架构、换模型。调整的依据是抽检结果和下游效果。这套agentic数据流水线我从最初的手工规则一路迭代到现在最大的感受是没有一劳永逸的方案只有持续迭代的流程。每个领域、每个阶段的数据特点都不同照搬别人的配置大概率水土不服。核心是把判断-反馈-调整这个循环跑通让流水线能自己进化。