蒸馏实验如何验收，数据格式、拒绝原因与评测记录设计

蒸馏项目的第一版系统不需要追求高并发，但必须可追溯。每条输入从教师调用、原始输出、格式解析、内容验收到训练集发布，都应有稳定ID和明确状态。否则样本一多，就无法回答哪些数据真正可用。

JSONL只是记录容器

JSON Lines要求UTF-8编码、每行都是有效JSON值，并使用换行符分隔。它适合逐条处理和追加记录，但语法合法不等于训练质量合格。

一个建议记录可以这样设计：

{
"sample_id": "task-0001",
"dataset_version": "pilot-v1",
"prompt_version": "p03",
"teacher_model": "provider/model-version",
"input": {"text": "…"},
"raw_output": "…",
"status": "accepted",
"reject_reason": null
}

这是客户端示例，不代表任何训练框架的唯一格式。Hugging Face TRL的SFTTrainer支持语言建模、prompt-completion以及标准或对话式数据格式，实际字段应与所用训练工具和chat template匹配。

JSONL只解决一行一条记录的保存方式。训练质量首先取决于字段含义和版本关系。每条记录至少要能追溯输入来源、教师版本、生成时间、任务标签和验收结果。字段后来调整时，保留旧格式和转换脚本，避免历史数据无法重跑。

状态不要只设成功和失败

建议区分pending、running、generated、accepted、rejected、retryable_failed和permanent_failed。教师返回内容后进入generated，通过格式与内容验收后才进入accepted。

客户端超时不证明上游一定未完成。没有任务查询或幂等机制时，盲目重试可能产生重复数据与额外消耗。每次尝试要记录时间、错误、次数和请求标识。

建议把生成、待验收、需修改、合格、拒绝和已导出分开记录。状态变化要带时间与操作者，失败请求也要留失败原因。这样重试时不会把同一条样本误算成两条合格数据。

拒绝原因要结构化

可以设置empty_output、invalid_json、missing_field、invalid_fact、duplicate、unsafe_content和out_of_scope等代码。拒绝原因不能只写一段自由文本，否则难以统计教师问题和提示词问题。

修改验收规则后，可以从原始输出重新计算，而不是重新调用教师。因此原始层、验收层和训练发布层应分开。

拒绝原因可以分为事实错误、格式不符、任务越界、敏感信息和重复样本等类别，并允许补充说明。统计各类占比后，团队才能判断是教师质量不足，还是提示词和验收规则需要调整。

数据集怎么切分

先冻结最终测试集，再划分训练与验证数据。按用户、主题、时间或来源切分，减少相似样本跨集合泄漏。文本去重需要说明算法和阈值；格式相同不代表语义重复，语义接近也不一定应删除。

切分时同时考虑来源、时间、任务类别和难度。相同模板的不同改写不应被随意分到训练集和测试集两边。最终测试集在方案冻结前不要反复查看，否则它会失去独立验收作用。

评测记录至少包含什么

保存实验ID、代码版本、数据集版本、教师与学生版本、训练配置、评测器版本、硬件环境、质量指标、资源指标和典型失败。只保存最终分数，无法复现实验。

记录模型版本、数据集版本、评测脚本、硬件、随机种子和每类指标。总体分数旁边要保留失败样本和分层结果，便于解释一次提升究竟来自哪类输入。

放量前的自动检查

多教师测试需要统一API入口时，147AI可以作为候选工具辅助调用和消耗核对；状态机、重试、JSONL验收和训练流程仍由客户端实现。

一个能解析的JSONL文件只是起点。真正可训练的数据集，还必须能说明来源、质量、版本和拒绝过程。

导出训练集时不要带入什么

原始响应中的请求元数据、错误信息和内部审核备注，未必都应进入训练样本。发布脚本应按白名单选择字段，避免把API错误、评审意见或敏感标识一起写进prompt或completion。训练格式与审计记录可以通过sample_id关联，不必塞进同一条文本。

一个最小校验顺序

先逐行解码UTF-8并解析JSON；检查唯一ID和必填字段；验证状态只能来自允许集合；确认accepted才可导出；检查训练、验证和测试集合交集；最后输出条数、拒绝构成和数据集哈希。任何一步失败，导出任务都应停止而不是跳过。

验收器变更怎么处理

验收器从v1升级到v2时，不要覆盖原结果。保留validator_version，用原始层重新运行并生成新数据集版本。比较两版新增接受与新增拒绝的样本，人工抽查规则是否误伤。

验收规则调整后，先在固定样本上比较新旧结果，确认变化来自规则修正而非数据偶然。受影响的历史批次要重新计算，并在报告中注明新旧版本不能直接横向比较。

日志与数据如何分离

运行日志记录请求、错误和时间；数据记录保存训练相关对象。两者保存期限和访问权限可能不同。不要为了调试方便把密钥、完整敏感输入或鉴权头写入日志。

调用日志用于追踪请求、耗时、错误和费用，训练数据则保存经过授权和验收的内容。两者通过实验ID或样本ID关联，避免把完整敏感输入长期留在运行日志里。

训练前抽样报告

按任务类别、来源、长度和教师模型分层统计，检查某一类是否占比过高。随机打开一批接受样本与拒绝样本，确认程序统计和人工理解一致。数据分布报告应与dataset_version一起归档。

训练前抽样应展示各任务类别、难度、拒绝率、重复率和人工复核结果。发现某类样本过多时先调整数据组成，再开始训练，避免训练结束才发现覆盖失衡。

训练格式转换也要单独验证

验收层的数据结构与训练框架需要的结构不一定相同。转换脚本应明确输入字段、角色映射、特殊标记和缺失值处理，并用少量样本反向检查：转换后的文本是否仍保留原意，system、user、assistant等角色有没有错位，截断是否删掉关键答案。不要把“脚本执行成功”当成“模型实际读到了正确内容”。

数据集发布时再生成一份只读清单，记录文件名、条数、哈希、输入批次、转换脚本版本和目标训练格式。训练任务只引用这份清单，不在运行中临时改写数据。这样即使之后更新模板，也能判断某次实验究竟使用了哪一版输入。