过滤、去重与组级划分

本节目标

建立可审计的“隔离—验证—过滤—去重—分组—划分”流程,避免低质量、重复和同源变体进入独立测试。

直觉解释

生成器的原始输出是候选池,不是成品数据集。一个样本即使结构正确,也可能答案矛盾;两条文字不同,也可能只是同一模板改写。清理必须保留拒绝原因和来源,否则无法判断质量损失或重跑。

核心概念

  • quarantine:原始候选的隔离区,未通过 gate 前不进入正式数据。
  • schema validation:检查字段、类型、枚举和格式。
  • semantic validation:用规则、模拟器或人工检查任务与标签是否成立。
  • exact / normalized duplicate:原文或规范化后完全相同。
  • near duplicate:词面或语义高度相似,但并非完全相同。
  • family grouping:将同一模板、原事件、文档或改写链归组。
  • rejection log:记录样本 ID、规则、原因、处理版本和是否复核。

去重不是一个布尔开关

建议按成本从低到高建立候选对:稳定 ID/来源重复、规范化精确哈希、字符或 token n-gram、编辑距离、Embedding 近邻,再由规则或人工判断。相似度只能提出“可能同源”,不能决定哪个样本正确;阈值要在已标注的重复/非重复对上校准,并按语言和任务分层检查。

去重单位也取决于用途。训练时重复样本会改变权重;评测时同源变体会夸大证据量;RAG 问题还可能与源文档或答案泄漏同源。报告应同时给出行数、family 数、条件格数与拒绝率,避免删除大量改写后仍宣称有同样的有效规模。

分步骤方法

  1. 原始输出只追加保存,赋予稳定 candidate ID 和 provenance。
  2. 先做解析/schema gate;错误进入拒绝日志,不静默填默认值。
  3. 做业务不变量、标签可验证性、敏感内容和禁止动作检查。
  4. 规范化空白、大小写和已知等价格式后做精确哈希去重。
  5. 在全候选池检查近重复;方法可用 n-gram/MinHash、编辑距离、Embedding 检索与人工复核。
  6. 为剩余样本确定 family ID;相似不是自动删除依据,要看是否保留有意义条件变化。
  7. 以 family 为单位划分 train/dev/test,确保一组只在一侧。
  8. 输出每道 gate 的输入数、拒绝数、原因和版本,保留可重放清单。

划分时先确定真实的生成单位:同一用户/会话、文档、模板、原始事故、代码仓库或时间窗口都可能构成 family。若合成器由测试答案反向改写 prompt,生成文本再不同也已污染测试。无法确定 lineage 的样本应隔离或标记不确定,不能靠哈希“证明无泄漏”。

示例

下面三条应归同一 family,而不是被当成三个独立测试证据:

“帮我查 A-1”
“查询一下订单 A-1”
“订单 A-1 到哪了?”

若第二条增加了“工具超时”环境条件,它可能值得保留,但仍共享 family;划分时三条不能跨开发和测试。去重键也不应包含模型生成的答案,否则相同输入配不同错误答案会被误判为不同任务。

常见错误与排查

  • 只在每个 split 内去重:跨 split 仍泄漏;先做全局相似审计并按 family 划分。
  • 近重复阈值一刀切:可能删除关键边界;抽查临界对并记录决策。
  • 模型 judge 通过就保留:补充确定性规则和人工校准。
  • 拒绝样本直接删除:失去生成器质量证据;保存日志但不要混入发布集。
  • 随机逐行切分:变体跨集;按 group/family ID 切分。

练习

  1. 为 JSON 工具调用样本写 5 个 schema/业务 gate。
  2. 设计规范化文本函数,并列出两个不应被规范化掉的语义差异。
  3. 给同一文档的多个 chunk 与多轮问答设计 family ID。

自测

  1. 近重复一定要删除一条吗?不一定,若它覆盖不同关键条件可保留,但必须防止跨划分和重复加权。
  2. 去重会不会改变分布?会,需报告前后分层统计。
  3. 先划分再生成改写安全吗?只有每个改写被严格限制在其原 family 的同一 split,并保持 lineage。

小结与下一步

过滤和去重将“生成量”转化为可审计的有效候选,组级划分保护独立性。下一步用 质量、效用与真实数据校准 判断数据是否真的有用。

参考资料