一批工单数据已经去掉空值、统一字段，是否就能交给训练团队？如果同一工单的不同回复分别进入训练集和测试集，或者输入包含处理结束后才出现的字段，模型可能在评估中取得好成绩，却不能应对新工单。本文的中心判断是：数据集验收是一份针对具体任务的证据链，需要同时证明样本可用、评估独立、版本可复现；文件完整只是起点。
一、先写任务契约：模型在什么时点看见什么
贯穿本文的构造示例是一个企业售后工单分类任务：在工单首次提交时，将其分为“交付咨询”“设备故障”“其他”，供人员分流。模型输入仅为提交时已有的标题和描述，最终人工确认的类别作为监督标签。以下样本、规则和验收目标均用于说明方法，没有运行代码、训练模型或取得实测结果。
示例记录 A 是工单 T01 的初始描述“设备无法启动”；B 是 T01 后续回复“重启后仍无法启动”；C 是另一导出文件中的 A 副本；D 是独立工单 T02 的“设备不能开机”。A 与 C 是精确重复候选，A 与 B 属于同一业务事件，A 与 D 可能只是正常的相似表达。不能因为文字接近就把它们全部删除。
任务契约还应说明数据时间范围、目标用户、允许使用的字段、标签定义、预期分布，以及不适用的任务。此数据即使适合工单分类，也不自然适合回答维修方案。Datasheets for Datasets 提倡记录构成、收集、处理、用途和维护信息；本文据此将任务说明和处理记录纳入交付，而不是只交一个数据文件。[1]
二、先验结构与来源，把不合格记录隔离
逐文件检查编码、可解析性、字段类型、样本编号唯一性及允许的标签值。对每条记录保留来源标识、工单编号、提交时间和标签修订信息，但应明确哪些元数据只用于治理，不会进入模型输入。工单编号本身不宜默认成为预测特征。
文本非空不等于可用。只有“见附件”的描述，若训练流程没有读取附件，就缺少必要信息；截断文本可能丢失否定词；描述与标签来自不同工单则构成关联错误。抽查应覆盖来源批次、类别和长度区间，不能只看文件开头。
来源与使用权限需要单独确认，敏感信息应按任务需要移除或处理。示例可将电话等字段排除，同时保留故障关键词。脱敏若误删设备型号或错误码，会改变任务信息量；应记录规则并复查受影响样本。无法确认来源或许可的记录先隔离，不以“技术上能读取”代替使用判断。[1]
修复应产生新记录状态或新版本，并保留排除原因；不要直接覆盖唯一原始副本。只隔离问题记录可能减少某一类别的覆盖，因此结构检查之后还需重新统计分布。
三、分三层去重，不把相似度当删除命令
第一层是精确重复：保存原文后，按事先固定的规则处理换行和无意义空白，对任务相关字段生成指纹，再核对同指纹记录。规范化不得随意删除数字、否定词或设备型号。示例中 A 与 C 可归为一组，并保留来源映射；若标签冲突，则先复核，不能任意保留其中一个。
第二层是近似重复：可使用字符片段重合、MinHash 等方法生成候选，再人工判断是否来自复制、改写或重复导出。语言模型去重研究使用近重复与重复子串检查，并讨论训练和验证重叠问题。[2] 其研究对象主要是网络文本上的语言模型，不能将论文中的收益数字或匹配阈值直接用于中文工单分类。
第三层是事件关联：A 与 B 未必文字重复，却共享工单 T01。若任务只使用首次提交内容，B 应从该任务的输入样本中排除；若另设多轮工单任务，同一工单的多条记录则应作为关联组处理。仅做文本去重无法建立这种业务边界。
近似阈值应通过人工判定的候选对校准，分别观察误合并和漏检。短句“无法启动”可能在大量独立事件中出现，过度删除会改变真实频率；训练集内是否保留这类重复表达，应由任务分布与采样目的决定。检查跨集合的相似样本时也要区分共享模板与泄露答案，不能把任何公共措辞都称为泄漏。
四、划分隔离要回答你想验证哪种泛化
先建立重复与事件关联关系，再分配集合；需要从数据学习参数的处理则在划分后仅用训练集拟合。训练集用于学习，验证集用于调参和选方案，测试集用于冻结方案后的评估。三者职责不能因为样本少而混用。
若目标是预测未来新提交的工单，宜按提交时间划分，并处理跨越边界的关联事件。若目标还包括服务未见过的客户，则需另外按客户分组检查。时间隔离与客户隔离回答不同问题，可以建立两个评估切片，不能用其中一个证明另一个。
scikit-learn 文档说明，相关样本分组时，应避免同组同时出现在对应的训练和测试集合；时间序列也不宜直接套用随机交叉验证。[3] 本例至少要求同一工单不跨集合。若客户会反复提交同一设备的问题，还需评估是否按设备或故障事件建立更高层的关联组。
排查泄漏要沿时间线检查每个输入字段。处理结论、最终责任部门和解决时长在首次提交时不可用，应从输入排除；最终类别可作为标签，但不能作为特征。再检查清洗、词表、归一化、特征选择等过程是否利用测试数据学习参数。官方文档明确指出，这类泄漏会造成过于乐观的评估。[4]
冻结测试集后，不应用其表现反复修改提示、规则或模型。若团队已围绕测试错误持续优化，就应将它视为开发材料，并建立新的独立测试集。对于来源不透明的预训练模型，即使本地划分干净，也不能证明底座从未接触相关公开材料；交付说明应明确这一限制。
五、验收指标要有分母、处理规则和适用前提
建议第一组检查结构与授权：可解析记录数除以提交记录数；必要输入完整数除以候选样本数；来源与用途可确认数除以拟纳入样本数。本例要求正式纳入的数据全部可解析、必要输入可用且使用依据可确认，依据是训练流程和交付责任需要。原始批次允许存在坏记录，但必须报告隔离数量，不能把隔离后合格率冒充原始质量。
第二组检查隔离：跨集合精确重复样本数、跨集合工单组数，以及已确认的跨集合近重复数。本例将前两项为零设为放行条件，因为它要评估新工单，导出副本或同事件重叠会破坏目标；近重复候选需要逐项处理或记录合理保留原因。这些零值只针对已定义的可检测问题，并不承诺不存在未知泄漏。
第三组检查标签与覆盖：分层抽查中标签与复核结论不一致的数量和比例，各类别、时间段及主要来源的样本量。两名复核者若对“设备故障”边界存在分歧，应先裁决和修订指南，再检查相关样本。复核者一致也不能证明标签绝对正确；复核仍需有足够业务依据。
标签差错容忍度应根据错分后果和修复成本事先约定，而非统一写成某个百分比。关键类别样本少时，单一准确率不可靠，应报告逐类结果和样本规模，必要时补采。增加抽样数量可以减小部分统计不确定性，但不能修复系统性标签偏差。
第四组检查追溯：每个交付分片是否有校验值，是否能恢复同一批数据和同一划分，排除记录是否有原因。数据验收通过只表示它符合约定输入和评估要求；模型是否达到业务目标，仍需后续训练与独立评估，不能由字段完整率替代。
六、交付的是可恢复版本，不只是文件名
交付清单应包括原始快照标识、清洗规则与程序版本、标签指南版本、随机种子或确定性划分规则、样本到集合的映射、排除清单、验收报告和各分片内容校验值。示例版本 v1 可记录 A、C 的归并和 B 的排除理由；若后来修订 A 的标签，应形成 v2，并说明受影响的划分和评估。
DVC 的 .dvc 文件记录数据路径、校验值等信息，并可随 Git 追踪。[5] 它是可选工具，团队也可用受控对象存储和清单实现类似目标。校验值只能帮助判断内容是否变化，不能证明标签正确、权限充分或数据质量合格；而只有清单没有保留的数据字节，也无法恢复版本。
常见失败可按影响处理：发现跨集合事件，重新按组划分并重做评估；发现预测时不可用字段，移除后重新训练，旧结果不得继续作为能力证据；发现标签指南变更，复核受影响样本并发布新版本；无法恢复旧数据，则该版本的结果应标为不可复现，而不是换个文件名继续交付。
当数据规模或用途改变，验收范围也要调整。多轮对话需检查会话关联，生成式任务需复核输入与目标答案，持续更新数据需锁定评估快照。本文的工单规则不能直接覆盖这些任务，但共同原则相同：每条放行结论都应能回答检查了什么、如何检查、失败怎样处理，以及哪些问题仍未被证明。