蒸馏数据进入训练集以前至少要经过一次完整的质量检查。很多团队把JSONL文件成功导出当成任务完成真正训练后才发现字段缺失、格式漂移、教师答错或样本高度重复。数据质量检查的作用就是在消耗更多训练资源以前把这些问题暴露出来。先让每条样本可以追踪每条记录建议拥有唯一的item_id同时记录batch_id、数据集版本、输入来源、任务类型和生成时间。教师模型名称、版本、请求标识和尝试次数也要保存。这样一条样本即使重新生成也能看出它是新尝试还是原任务的重复写入。程序可以先检查JSON是否能解析、必填字段是否存在、字段类型是否正确、枚举值是否在允许集合内。随后还要检查输出是否真正回答了输入是否满足长度、结构和拒答要求。格式正确的错误答案仍然不能进入训练集。建议区分待生成、生成完成、待验收、合格、需修改、拒绝和已导出。状态变化要带时间和原因。失败请求不能直接标记为拒绝样本网络失败、参数错误和内容不合格需要分别处理因为它们对应的修复动作不同。拒绝原因和重复问题要放在一起看可以把拒绝原因分为事实错误、格式错误、任务越界、敏感信息、重复样本和人工无法判断。每一批数据结束后统计各类比例。如果格式错误集中出现优先修改输出约束如果事实错误持续增加需要重新评估教师如果重复率上升则应调整采样策略。完全相同的字符串容易去掉改了几个词的近似重复更容易混入。可以先做文本归一化再用相似度方法筛查最后对边界结果人工抽样。训练集和测试集之间也要做相似性检查否则模型可能只是记住了模板。报告、测试集和扩量要连起来报告至少包括样本总数、各任务类别占比、合格率、拒绝原因、重复率、教师版本和人工抽样结论。不要只保存一个平均分。典型失败样本能帮助训练人员判断应该补数据、改规则还是缩小任务范围。开发集可以用来比较教师、调整提示词和修改验收器最终测试集则应在方案冻结后使用。团队反复查看最终测试结果再修改训练配置这套题就已经变成开发集需要重新准备保留集。第一批数据应覆盖常见、边界和高风险输入。只有当格式、内容、成本和拒绝原因都在项目可接受范围内才进入下一批。数量不是质量的替代品扩量只会把已经存在的问题复制得更快。验收器本身也要接受检查不要让验收结果只停留在单独的报表里。每条样本可以保存规则检查结果、人工判断、拒绝原因和验收器版本最终状态由明确规则计算。这样训练文件出现异常时可以沿着item_id回到原始输入和教师输出不必依赖参与者回忆。状态更新还应避免覆盖历史。样本从待验收变成拒绝时保留上一状态、变更时间和操作者。后续修订通过应创建新的尝试或修订版本不要把第一次错误悄悄改成成功。验收脚本上线前准备一组故意缺字段、标签越界、内容为空、角色错位和答案截断的样本。确认脚本能拦住它们也不会误伤合格数据。验收器发生变化后重新跑这组固定样本并复算受影响的历史批次。生成任务还要防止评审器只偏爱更长或更像教师的答案。可以保留少量人工确认样本定期比较自动结果。自动得分与人工判断持续背离时应停止自动放行。训练结果要能反查数据训练完成后把学生错题按任务类别、数据批次和教师版本汇总。错误集中在某个批次优先检查那批数据多个批次都出现同类失败时还要同时检查任务定义、测试分布、学生容量和训练方法。建立这种关联后补数据会更有方向。如果新增一批数据后总体分数上升高风险类别却退步不能把它写成全面改善。数据质量报告和学生评测报告需要使用相同的任务分类才能看出新增样本究竟改善了哪里。在需要比较多个教师模型时147AI可以作为一个统一API入口候选减少不同接口的适配工作。团队仍应在本地保存item_id、验收状态和数据集版本再把调用日志中的模型、令牌、请求标识和花费与实验记录关联。统一入口能帮助核对调用不会自动完成内容验收。可靠的数据集由一组能说明来源、状态、质量和去向的记录组成。把失败样本留下把拒绝原因分类把测试集隔离训练结果才有解释基础。
