企业官网建设流程全解析

做爬虫采集、新闻聚合或者语料库清洗的朋友，大概率都遇到过同一个问题：抓下来的文本重复率能到30%甚至更高。同一篇新闻被不同网站转载，改个标题、换一下首段、插入几条广告，内容主体几乎一模一样。这个时候拿MD5做精确去重根本没用，因为文件内容没有一个比特是相同的。我当时在一个十万量级的文档集上做研究，需要去除这些近似重复内容，最后落地了一套Python最小哈希去重方案——用MinHash把每篇文档压缩成一组固定长度的签名向量，再用签名估算文档之间的Jaccard相似度，既绕开了两两全文比较的巨大开销，又比SimHash在短文本和局部修改场景下可解释性强很多。整套代码从数据预处理到哈希签名再到相似度判定，跑下来效果非常稳。这篇就把我的实现思路、完整代码和踩过的坑都捋一遍，给同样在做文档去重的朋友做个参考。

如果你是第一次接触MinHash，可能会觉得名字有点唬人，但其实核心思想不复杂。文章会从最基础的Jaccard相似度概念讲起，推导出为什么“最小哈希相等”可以代表“集合相似”，再给出可以直接复制的Python实现。看完之后，你应该能围绕这套代码封装出属于你自己的去重模块，处理万到百万量级的文档都没有问题。

Python最小哈希实现海量文档去重

1. 项目概述与方案选型

1.1 我为什么要做这套去重方案

做文本采集和数据分析的人，最烦的不是数据少，而是数据里塞满了“看起来不一样、其实是一个东西”的重复内容。早期我偷懒，直接用MD5/SHA1做哈希去重，写十几行代码就把“完全相同”的文档过滤掉了。结果很快发现现实世界根本没有那么多完全相同的文件——同一篇文章换个标题，MD5就完全变了；插入一段广告文字，哈希值也完全变了；哪怕只是把段落顺序换一下，整个文件内容就跟原来没有任何关系了。

后来我尝试过编辑距离、公共子串这类序列比对算法。它们在两三篇文档上效果不错，一旦文档数量上千，两两比对的时间复杂度直接变成O(n²)，根本跑不动。那种感觉就像手里有个锤子，看什么都是钉子，但钉子太多，一锤一锤敲下去效率太低。

真正让我下决心用最小哈希，是因为它把“两两比较全部文档”这个问题，变成了“每篇文档只处理一次，生成定长摘要，再比较摘要”。MinHash在数学上跟Jaccard相似度有严格的理论对应——它有可证明的近似保证，不是拍脑袋调参出来的经验算法。我当时的需求是：十万级文档、单机处理、允许少量误判但要求速度快，这几乎是给MinHash量身定做的场景。

1.2 常用去重方案横向对比

为了说明为什么选MinHash，我把踩过的几种方案放在一起做个对比：

从表格里能看出来，SimHash和MinHash都算近似去重方案，但两者的侧重点不同。SimHash赢在压缩率和检索效率，本质上是用向量夹角模拟语义相似度，但它对文本顺序很敏感，短文特别是只有几句话的片段，用起来经常不准。MinHash基于集合重叠度，天然对“增删改部分词、调整语序、截断正文”这类情形更鲁棒，也更符合我们对“转载文章”这类重复的定义。所以在做爬虫去重、新闻聚合这种任务时，我最终选了MinHash。

1.3 最小哈希适合解决什么问题

MinHash这套方案特别适合下面几类问题：

• 爬虫抓取的多源内容去重：同一事件被多家媒体报道，正文高度相似但标题、导语、图片来源各不相同。
• 语料库清洗：需要构建高质量训练集时，过滤掉搜索引擎收录的重复页面，避免模型学到重复分布。
• 文档聚合与检索优化：新闻App把同一事件的不同转载聚成一条，展示时只保留质量最高的源文。
• 内容治理：检测站内是否有用户直接把别人文章改改标题再发一遍。

如果文档数量上了百万，单纯用MinHash做全量两两签名比较还是有点吃力，我会在第四部分专门讲用LSH(局部敏感哈希)先缩小候选对规模，再精确估算相似度的方法。这套组合拳是工业界处理海量文本去重的标准路线。

2. 最小哈希原理与核心概念

2.1 Jaccard相似度到底怎么算

聊MinHash之前，必须先把Jaccard相似度说清楚。它的定义极其简单：两个集合的交集大小除以并集大小。

假设文档A的Shingle集合是SetA，文档B的Shingle集合是SetB，那么Jaccard相似度就是：

J(A, B) = |SetA ∩ SetB| / |SetA ∪ SetB|

取个简单的例子。SetA = {"我今天", "今天去", "去爬山"}，SetB = {"我今天", "今天去", "去跑步"}。交集是{"我今天", "今天去"}，大小是2，并集是{"我今天", "今天去", "去爬山", "去跑步"}，大小是4，所以Jaccard相似度就是2/4=0.5。

用生活里的话说，Jaccard衡量的是“两个集合的行李有多重叠”。如果两个人去超市买的商品一模一样，相似度是1；如果一样都没重合，就是0。放在文本去重场景里，Shingle就是我们拆出来的“商品”，重叠度越高，说明两个文档越像。

2.2 最小哈希：一个值的碰撞概率等于Jaccard

理解了Jaccard，再来看最小哈希。首先给集合里的每个元素打一个随机哈希值，然后取集合内部最小的那个哈希值，这个值就叫该集合的最小哈希（MinHash）。这里有一个非常漂亮的性质：两个集合的最小哈希值相等的概率，恰好等于这两个集合的Jaccard相似度。

这个性质乍看有点反直觉，我当初学的时候也愣了半天。来捋一下证明思路：

把两个集合并起来，一共n个不同的元素。现在给这n个元素随机打乱排成一行，然后看排在最前面的元素。因为哈希函数可以看成是给每个元素分配了一个随机排列位置，所以最小哈希值对应的就是“排在最前面的那个元素”。如果这个元素落在两个集合的交集里，那不管从集合A还是集合B看，最小值都是同一个元素，所以两个最小哈希相等。如果这个元素落在差集里，比如只属于集合A，那集合A的最小值就比集合B小，两个值不相等。

那么排在第一位的是交集元素的概率是多少？就是交集大小除以并集大小，也就是Jaccard相似度。于是最小哈希相等的概率，天然等于Jaccard相似度。

理解了这个点，你就能明白最小哈希为什么叫“最小”——它其实是在做一个“随机抽签”，抽到交集元素就说明两个集合撞上了，抽到差集元素就说明没撞上。一次抽签的结果有随机性，但多抽几次取频率，就能稳定逼近真实的Jaccard相似度。

2.3 签名向量：多抽几次签就是签名

既然一次最小哈希只是概率事件，那就要多做几次独立实验。具体做法是准备k个独立的哈希函数，对每个集合分别计算k个最小哈希值，最终得到一个长度为k的向量，这就是文档的“签名”。

比如取k=128，每篇文档就会有一个128维的整数签名向量。要估算两篇文档的Jaccard相似度，只需要统计两个签名向量中对应位置相等的个数，再除以k。签名里相等的比例，就近似等于真实的Jaccard相似度。

k的取值直接决定了估计精度。理论上方差跟1/k成正比——k越大，估计越准，但计算和存储成本也越高。根据我的实测经验，k=32在短文本上波动明显，k=64能应付一般场景，k=128已经相当稳定，再往上提升有限，但存储开销和哈希计算时间成倍上涨。日常项目我建议直接从k=128开始跑。如果文档集特别大，可以先k=64做一轮粗筛，命中候选再用k=512做二次精排，这个属于工程上的进阶玩法。

3. 完整实现过程

3.1 项目结构与模块划分

整个去重流程可以拆成五个阶段：文本清洗、Shingle切分、哈希函数构造、签名计算、相似度估计。我在工程上是按模块划分的，方便后续替换某一块逻辑。

dedup/ ├── preprocess.py # 文本清洗与Shingle切分 ├── hashers.py # 哈希函数族构造 ├── signature.py # 单文档签名计算 ├── compare.py # 签名相似度估计与去重判定 └── pipeline.py # 组装全流程

分模块的好处是，某个环节需要替换时不用动其他代码。比如我一开始用jieba分词做WordShingle，后来为了提速改成直接不分词的字N-gram，只改了preprocess.py，后面的签名计算和相似度判定完全不受影响。

3.2 Shingle切分：按词还是按字符

Shingle是文档去重的基本单元，可以理解为“滑动窗口切出的小片段”。切分粒度对结果影响非常大，我自己试过三种方式：

• 按词切分，做Word N-gram。比如“我今天去爬山”按词分成[“我”,“今天”,“去”,“爬山”]，取k=2的Word N-gram就是“我今天”、“今天去”、“去爬山”。这种方式语义完整，适合长文档，但需要分词器，中文场景下jieba分词会明显拖慢速度。
• 按字符切分，做Char N-gram。直接去掉空格和标点，按照连续n个字符切分。对于中文，取n=4或n=5效果不错；对于英文，取n=8到n=12比较好。这种方式完全不需要分词器，速度快，对微小改动也敏感。
• 混合方式。先做词级别Shingle，再对高频词或者疑似广告段落单独做字符Shingle。这种方式适合复杂场景，但实现成本高。

我最常用的还是字符N-gram，尤其在“追求速度、不做语义理解”的场景下。字符N-gram的好处在于它把文本看成纯字符串，任何语言的文档都能处理，不用额外装分词库。需要注意的点是n不能太小，否则单个字符的噪声会被放大；也不能太大，否则Shingle几乎不会重复，Jaccard相似度会失真。给大家一个参考范围：中文取4~6，英文取8~12。

import re from typing import Set def char_ngrams(text: str, n: int = 4) -> Set[str]: # 统一小写并压缩空白字符 text = re.sub(r"\s+", "", text.lower()) if len(text) <= n: return {text} return {text[i:i+n] for i in range(len(text) - n + 1)} def word_ngrams(text: str, n: int = 3) -> Set[str]: tokens = text.split() if len(tokens) <= n: return {" ".join(tokens)} return {" ".join(tokens[i:i+n]) for i in range(len(tokens) - n + 1)}

3.3 哈希函数族：别用Python内置hash()

有了Shingle集合，下一步就是构造多个哈希函数。网上很多教程直接用Python的hash()函数，这个坑我一开始也踩过——Python对字符串的hash()默认加了随机盐，每次进程启动的结果都不一样。哪怕你写死种子，不同Python版本或不同平台下结果也无法保证一致性。用它做文本签名，结果完全不可复现。

正确的做法是先给每个Shingle计算一个稳定的数值指纹，再套用形如h(x) = (a * x + b) % p的线性哈希函数。其中a和b是随机参数，p是一个足够大的素数。用不同的(a, b)组合，就能模拟一批“独立”的哈希函数。p我习惯用2^31 - 1，也就是梅森素数，因为它在很多语言里都有高效实现，而且能避免一些取模运算的溢出问题。

给Shingle算稳定指纹时，可以用zlib.crc32、mmh3、xxhash之类的非加密哈希算法。我实测下来xxhash速度最快，crc32是Python内置的、零依赖，二者碰撞率在文档去重场景下都足够低。这里我用crc32演示，因为它不需要额外安装第三方库。

import random import zlib def generate_hash_functions(k: int, mod: int = (1 << 31) - 1): """生成k个形如 h(x) = (a*x + b) % mod 的哈希函数。 返回一个二元组列表 [(a1,b1,mod), (a2,b2,mod), ...] """ funcs = [] used_a = set() while len(funcs) < k: # a必须是奇数，并且不能与之前重复 a = random.randrange(1, mod) if a % 2 == 0 or a in used_a: continue used_a.add(a) b = random.randrange(0, mod) funcs.append((a, b, mod)) return funcs

构造哈希函数族时有一个细节：a必须尽量保证是奇数且互不相同。原因是线性同余哈希要求a与模数互质，才能尽量避免短周期。对于素数的模数，a不为0且不是模数的倍数就行。我额外要求a是奇数，是为了进一步减少碰撞路径上可能出现的退化情况，虽然这个要求不是必须的，但实测这样生成的函数分布更均匀。

3.4 签名计算的完整代码

有了哈希函数族，就可以计算文档签名了。针对一篇文档，遍历它所有的Shingle，对每个Shingle计算它在每个哈希函数下的值，保留每个哈希函数的最小值。这个过程可以写得很简洁：

import numpy as np def compute_signature(shingles: Set[str], hash_funcs, dtype=np.uint64) -> np.ndarray: """ 输入：文档的Shingle集合，哈希函数列表 输出：长度为len(hash_funcs)的一维数组，每个元素是其中一个哈希函数的最小哈希值 """ k = len(hash_funcs) sig = np.full(k, np.iinfo(dtype).max, dtype=dtype) for shingle in shingles: # 先把字符串映射成稳定的整数指纹 x = zlib.crc32(shingle.encode("utf-8")) for idx, (a, b, mod) in enumerate(hash_funcs): h = (a * x + b) % mod if h < sig[idx]: sig[idx] = h return sig

这段代码有两个值得注意的点。

第一个是sig的初始值。我把它初始化为当前整数类型的最大值，这样任何一个Shingle算出来的哈希值都会小于它，从而能正常被“最小值”更新覆盖。如果你初始化为0，所有最小哈希都会停在0，签名就废了。

第二个是为什么用numpy数组而不是Python列表。因为文档量上来之后，签名矩阵通常是一个大二维数组，直接用numpy的数组来存，后续做向量化计算会非常方便。如果用Python列表存储，做相似度比对时要么写循环，要么还得转一次numpy，白白多一步。

3.5 相似度估计与阈值判定

签名算出来之后，去重判定就极其简单了。两个文档签名的相似度，等于两个向量中对应位置相等的比例。代码写出来只有一行：

def estimate_jaccard(sig_a: np.ndarray, sig_b: np.ndarray) -> float: return float(np.mean(sig_a == sig_b))

然后根据相似度阈值判断是否重复。阈值怎么定，这个没有标准答案，取决于你的业务对“漏判”和“误判”的容忍度。我建议先随手抽几百对文档，人工标出哪些算重复，再画出不同阈值下的准确率和召回率曲线，选一个平衡点。

从我的经验看：

我实际跑新闻语料时，最终选的是0.75。低于0.75的，人工抽查后发现很多是不同主题但恰好共用段落模板的文章，不算真正的重复。高于0.75的，误判率就低多了。

3.6 一个可以直接跑的完整示例

把所有环节串起来，写一个从文本列表到相似度矩阵的完整例子。假设我们有4篇文档，想看看哪些是重复的：

import numpy as np import zlib import re import random # 1. 准备文档 docs = [ "Python是一门优雅的编程语言，适合数据分析与人工智能。", "Python 是一门优雅的编程语言，适合数据分析与人工智能。", "Java也是一门流行的编程语言，在企业级开发中广泛使用。", "Python是一门优雅的编程语言，适合数据分析与人工智能！", ] # 2. 生成Shingle def char_ngrams(text, n=4): text = re.sub(r"\s+", "", text.lower()) return {text[i:i+n] for i in range(max(len(text) - n + 1, 0))} or {text} shingle_sets = [char_ngrams(doc) for doc in docs] # 3. 生成哈希函数族 random.seed(42) hash_funcs = generate_hash_functions(k=128) # 4. 计算签名矩阵 signatures = np.column_stack([compute_signature(s, hash_funcs) for s in shingle_sets]) # 5. 两两比较，输出相似度矩阵 n_docs = len(docs) sim_matrix = np.zeros((n_docs, n_docs)) for i in range(n_docs): for j in range(i+1, n_docs): s = estimate_jaccard(signatures[:, i], signatures[:, j]) sim_matrix[i, j] = s sim_matrix[j, i] = s print(np.round(sim_matrix, 4))

这段代码输出的相似度矩阵，对角线附近的值会接近1，而不同主题的文档相似度会很低。我在例子里特意放了两个“几乎相同但有一个标点或一个空格不同”的文档，可以看到它们的Jaccard相似度依然很高，这正好演示了MinHash对局部微小改动的包容能力。

4. 工程化性能优化与LSH扩展

4.1 海量数据下不能再做全量两两比较

上面示例里用了两层循环，对所有文档做两两签名比较。当文档数n比较小的时候没问题，但n一旦到了5万，两两组合就有12.5亿对。就算每个签名比较只用1微秒，也要3个多小时，完全不现实。

解决这个问题的标准方案是LSH，即局部敏感哈希。思路很简单：把一条完整的签名向量分成若干段（band），每一段分别做一次哈希，把哈希值相同的文档放进同一个桶。两条文档只要在任何一个band上哈希值相同，就会落进同一个桶，成为“候选对”。最后只需要对候选对做精确的签名相似度估计，因为真正相似的文档，很大概率会在至少一个band上完全一致。

LSH最大的意义是把O(n²)的比较降成接近O(n)的构建开销加一个很小的候选集。十万篇文档，构建LSH索引加比较候选对，单机运行通常几分钟内能完成。

4.2 Band和Rows的参数选择

签名长度为k，要分成b个band，每个band有r行，必须满足b*r=k。对于一条签名来说，在某个band内每行都相等，才能让整个band的哈希值一致。两条文档在某一个band中完全一致的概率是s^r，其中s是真实的Jaccard相似度；那么它们被至少一个band捕捉到的概率是：

P(s) = 1 - (1 - s^r)^b

这个函数是一条S形曲线。r越大，曲线越陡，说明算法对阈值越敏感——高于某一相似度的文档极大概率成为候选对，低于的极大概率不会。实际工程里有一个近似公式来选择参数：

t ≈ (1 / b) ^ (1 / r)

t就是我们希望捕获的相似度阈值。比如我希望0.75相似度的文档能成为候选对，可以选择b=10，r=8，这样t ≈ (1/10)^(1/8) ≈ 0.749。签名长度k就要取80。也可以选b=20，r=10，t≈0.741，此时k=200。我一般会让b、r的乘积在128~256之间，因为签名长度太短会影响Jaccard本身的估计精度。

下面是一段基于band哈希实现LSH的代码：

def build_lsh_candidates(signatures: np.ndarray, bands: int, rows: int): """ signatures: shape = (k, n)，k维签名，n篇文档 bands: 分段数量 rows: 每个band的行数 返回候选对列表 [(doc_idx_a, doc_idx_b), ...] """ k, n = signatures.shape assert bands * rows == k, "bands * rows 必须等于签名长度k" buckets = {} for band_idx in range(bands): # 取当前band对应的行 band = signatures[band_idx * rows : (band_idx + 1) * rows, :] for col in range(n): # 把这一band向量转成一个稳定哈希值 key = zlib.crc32(np.ascontiguousarray(band[:, col]).tobytes()) bucket_key = (band_idx, key) buckets.setdefault(bucket_key, []).append(col) candidates = set() for bucket_key, cols in buckets.items(): if len(cols) > 1: for i in range(len(cols)): for j in range(i + 1, len(cols)): candidates.add((cols[i], cols[j])) return list(candidates)

这里用zlib.crc32把每列的二进制内容转成哈希值，是为了避免依赖Python内置hash()的进程随机性。需要注意的另一个点是，同一band内哈希到同一桶的文档，只是“候选对”，最终是否判定为重复，还需要用完整签名计算精确的Jaccard估计值去二次确认，这一步不能省。

4.3 用numpy向量化加速签名比较

如果候选对数量还是不小，可以用numpy的向量化操作成批计算相似度。例如对一批候选对，取出对应列后逐位置比较，能比Python循环快几十倍。

def estimate_jaccard_batch(signatures: np.ndarray, pairs) -> np.ndarray: """ 批量估计候选对的Jaccard相似度 signatures: shape = (k, n) pairs: [(i, j), ...] """ pair_indices = np.array(pairs, dtype=np.int64) col_a = pair_indices[:, 0] col_b = pair_indices[:, 1] sig_a = signatures[:, col_a] # shape = (k, m) sig_b = signatures[:, col_b] return np.mean(sig_a == sig_b, axis=0)

这段代码的精髓在于，numpy的切片会把所有候选对一次性取出来，然后用广播机制做整块比较。我实测在10万候选对上，批量计算比循环快了将近20倍。

4.4 内存优化与数据存储细节

签名矩阵本身也占内存。一篇文档k=128时，每个签名用uint64存储就是8字节，100万篇文档就是1288100万=1GB。看着不多，但如果还要叠加原始文本和中间向量，单机内存还是会告急。这时候可以考虑几个方向：

• 把签名向量从uint64降到uint32。很多模数场景下，32位整数足够用，内存直接砍半。
• 用float16存储Shingle权重这类中间特征？签名本身是整数，不建议动类型精度，但可以用uint32压缩存储。
• 如果文档实在太多，可以把LSH桶记录写进SQLite或磁盘文件，而不是全放内存。内存在现代机器上也不算太贵，优先用内存做计算，效果更好。
• 签名矩阵按列存储，因为后续签名比较、LSH分band时，频繁按列取数据，按列连续存储能提高缓存命中率。

我在真实项目中处理500万篇文档时，采用了“分批签名+LSH落盘+候选对去重”的流水线：先分批次读入文档，每批5000篇，生成签名后立刻追加写入HDF5文件；构建LSH时按band扫描签名矩阵，桶信息写SQLite；最后从SQLite读候选对，重新加载对应签名做精确比较。这样每步都在稳定可控的内存范围内。

5. 常见问题与踩坑记录

5.1 环境准备：从头搭一套可复现的Python环境

既然热词里大家总在问Python环境，这块我就多说两句。我做这个项目时用的Python版本是3.10，依赖只有numpy和可选的中文分词库。建议不要直接用系统自带的那个Python，而是用venv或conda单独建一个虚拟环境，避免依赖冲突：

python -m venv dedup_env source dedup_env/bin/activate pip install numpy

如果你在国内，直接pip安装经常遇到网络超时，可以先把pip源切到国内镜像，速度会快很多。手动执行一次：

pip config set global.index-url https://mirrors.aliyun.com/pypi/simple/

配置好之后，再装numpy、pandas这类常规库基本就是秒下。很多python安装教程只讲了怎么装Python，没讲怎么配源，其实这一步对后面开发效率影响非常大。

5.2 内置hash()的坑，再强调一次

这是我和同事都踩过的大坑。Python的hash()对字符串默认使用随机盐，同一个字符串在不同进程里长得不一样的哈希值。如果你用它生成签名，今天跑出来的去重结果，明天换个进程可能就变了。我在网上看到不少文章拿hash()举例子，可以理解，毕竟写起来方便，但他们通常忽略了可复现性问题。在工程上，不可复现的签名几乎就是事故。所以统一用zlib.crc32或xxhash这类输入输出完全确定的哈希函数来打指纹。

5.3 短文本与空文档怎么处理

短文本是Shingle机制的天然短板。一篇文档本身只有几个词，切不出几个合法Shingle，签名估计值方差会非常大。比如“你好世界”四个字，用n=4切出来就一个Shingle，签名向量几乎完全押在这个Shingle上，随机波动极大。

我的处理方式有两种：一是对短文本改用更短的n值，比如n=2或n=3；二是干脆不直接用MinHash，而是先用规则判断长度，太短的文档直接走精确匹配或直接标记为“需人工确认”。空文档的处理更简单，给一个全零的签名向量，同时在相似度比较时跳过。

def safe_signature(text: str, hash_funcs, n: int = 4): if not text or not text.strip(): return None shingles = char_ngrams(text, n=n) if len(shingles) == 0: return None return compute_signature(shingles, hash_funcs)

5.4 哈希碰撞与签名退化

虽然crc32不是加密哈希，但它返回32位整数，在Shingle数量较大时，碰撞概率会上升。一个Shingle被错误映射成另一个Shingle，会让签名估计产生偏差。我在处理千万级Shingle时会换成64位的xxhash或mmh3，把碰撞概率压得更低。判断是否需要升级的方法是：统计Shingle总数，如果总数超过几百万，建议直接用64位哈希。另外，线性哈希函数的模数p要选得足够大，否则不同的x取模后碰撞也会加剧。我通常用2^61-1这样的大素数做模数，虽然会损失一点计算速度，但换来的是更稳的分布。

5.5 阈值不通用，别死抄别人的0.9

网上很多文章会写“相似度大于0.9就判重”，这种说法有一定误导性。阈值跟Shingle长度n、签名长度k、文档类型都有关系。同样是新闻正文，用字符N-gram和用词N-gram算出来的Jaccard分布完全不一样。抄袭别人的阈值，就像穿别人的鞋走路，尺码不合就是不舒服。

我自己的做法是：每次接到新的去重任务，先手工标注200~300对候选，把“是重复”和“不重复”分开，分别算出相似度分布，取分界点作为初始阈值。如果业务允许，再做一个小样本验证集，微调阈值直到效果满意。整个过程就是一次校准实验，花不了多少时间，但能显著降低后续上线后的误判率。

5.6 中文分词太慢怎么办

如果一开始用jieba做词级Shingle，你很快会发现jieba分词本身成了性能瓶颈。纯Python的分词器单线程处理一篇千字文档大约需要几十毫秒，百万文档就是几十万秒，完全跑不动。我在做大规模版本时，把分词这层整个去掉，直接用字符N-gram。

这个过程让我意识到一个事实：做去重不是做语义理解。我们只是想让“看起来重复”的文档被识别出来，并不需要真正理解文档在说什么。字符N-gram已经足够捕捉文字层面的重叠关系，而且速度快了不止一个数量级。当然，如果你处理的文档有大量同义词替换，字符N-gram会失效，这种场景还是需要结合词向量或者语义模型来处理，但那就不是一个真正的“文本去重”问题了。

6. 实操经验总结与后续扩展建议

最小哈希这套方案我在多个项目里都跑过，给我最大的感受是：理论部分看着绕，工程实现反而是最简单的部分。真正需要花时间调的是Shingle粒度、签名长度和相似度阈值这三个参数，它们互相影响，并且高度依赖数据本身。

如果读者想在现有项目上继续扩展，还有几个方向可以参考：

• 把MinHash签名和倒排索引结合，做增量去重。每天新来一批文档时，不需要和全量历史文档两两比较，只需要对新文档生成签名，去LSH桶里找候选对。这样就能支撑流式数据的持续去重。
• 对签名向量做聚类，把相似文档聚成主题簇，而不是简单地两两判定。这在新闻话题聚合场景下特别好用。
• 用多进程或PySpark并行化签名计算。每篇文档的签名计算是天然独立的，可以随意并行；但要注意LSH分桶的过程需要跨进程共享桶信息，最好在Spark里用byKey聚合操作实现。

我自己的体会是，这类型项目的成败往往不取决于算法多玄乎，而取决于你在工程细节上是不是较真。比如哈希函数是否稳定、签名矩阵的内存布局是否合理、阈值有没有经过数据校准。把这些细节一个个抠到位，整套系统跑起来就非常顺。最后再分享一个我调试时的习惯：在做大规模之前，先拿一小组数据算一遍真实Jaccard，再和MinHash估计值放到一张散点图里比对，如果两者偏离太远，说明实现或者参数有问题，要先解决这个再上工程。这个习惯帮我避开了很多看似“莫名其妙”的结果。