Data Deduplication at Web Scale — Your Pipeline?

Training on web-scale data without aggressive dedup gave us a model that memorized boilerplate and repeated itself. MinHash + suffix-array pipelines are standard, but the engineering to run them on billions of documents is real. What does your dedup pipeline look like, and how much data did you actually throw away?

我们做过类似规模的去重，最后扔掉的比例确实会吓人一跳：精确去重加近似去重叠加下来，原始网页数据经常能去掉 40% 到 60%，其中样板文本和跨站转载占大头。只看去重比例还不够，关键是分层做、每层留可回溯的样本。

我们的流水线分三层。第一层是精确去重：按归一化后的正文哈希去重，归一化时要先去掉导航、页脚和广告位，只保留正文，否则同一篇文章换个模板就被当成不同文档；同时保留首次出现的来源 URL 和抓取时间，方便事后审计。第二层是近似去重：用 MinHash 加 LSH 做文档级去重，相似度阈值不要一刀切，新闻和代码类文档的阈值要分开设，代码片段重复率高，阈值设得太低会误杀大量合法样本。第三层是段落级去重：对长文档内部的重复段落做切分去重，尤其是法律条款、产品说明书这类高频复用段落，不处理的话模型会把样板背得滚瓜烂熟。

工程上最容易被忽略的是增量更新：新一批数据进来时，不能只和新数据内部比，还要和历史库的签名索引比，否则跨批次的转载根本去不掉。我们用的是分片的签名索引加定期合并，合并时顺带清理过期签名，索引膨胀才能控制住。另外建议每层都抽样人工核查误杀率，只盯着“去掉了多少”很容易把去重做成过度清洗。