Datatrove项目中Minhash去重实现差异分析

背景介绍

在数据预处理领域，去重是一个关键步骤。Datatrove作为Hugging Face生态系统中的一个数据处理工具，提供了基于Minhash算法的去重功能。本文探讨了Datatrove与其他实现（如Spark版本）在去重效果上的差异问题。

问题现象

用户在使用Datatrove对StackMathQA数据集进行Minhash去重时发现，与基于Spark的实现相比，Datatrove的去重率明显较低。具体表现为：

• Spark实现去除了88%的原始内容
• Datatrove仅去除了60%的内容

参数配置分析

两种实现使用了相同的核心参数配置：

• n-gram大小：5
• 桶数量(r)：60
• 每个桶的哈希数量(b)：13

理论上，这种配置下两个实现应该产生相似的去重效果，但实际结果差异显著。

技术实现对比

Datatrove实现特点

1. 采用四阶段处理流程：

   • 计算Minhash签名
   • 按桶匹配签名
   • 创建重复簇
   • 过滤重复文档

2. 使用Union Set算法进行簇合并，该算法简单可靠且经过充分测试

3. 文档处理包含额外元数据字段，如文件路径等

Spark实现特点

1. 基于GraphFrame进行文档相似性分析

2. 使用不同的ngram生成逻辑（特别是min_length参数处理）

3. 输出格式更简洁，不含额外元数据

差异原因探究

1. 文档计数方式差异：文件大小比较可能不准确，因Datatrove输出包含额外元数据

2. ngram生成逻辑：Spark实现中的min_length参数可能导致ngram生成方式不同

3. GraphFrame潜在问题：测试发现Spark无法从Datatrove的去重结果中找到更多重复，暗示GraphFrame实现可能存在隐藏问题

4. 保留文档选择：不同实现在簇中选择保留哪个文档的机制不同，但不应导致如此大的差异

验证建议

1. 使用文档计数而非文件大小比较去重率

2. 对两种实现的去重结果互相验证：

   • 检查Spark是否能从Datatrove结果中找到更多重复
   • 检查Datatrove是否能从Spark结果中找到更多重复

3. 统一ngram生成逻辑进行对比测试

结论

经过分析，Datatrove的Minhash实现是正确的，差异更可能源于Spark实现的潜在问题或比较方法的不一致。对于关键任务的数据去重工作，建议：

1. 优先使用经过充分验证的实现如Datatrove

2. 采用文档计数等更精确的比较方法

3. 必要时进行交叉验证以确保去重质量

数据去重是数据预处理中的关键步骤，理解不同实现的细微差异对于确保数据质量至关重要。通过本文的分析，开发者可以更明智地选择和使用合适的去重工具。