NLP数据去重与污染检测最小复现：从n-gram到语义向量

做 NLP 数据工程或大模型训练的人，基本都绕不开两件事：一是给训练集去重，二是判断测试集有没有被训练数据污染。这两件事看起来是两条业务线，但落到实现上其实共享同一套核心能力——如何衡量两条文本“够不够像”。这也是为什么数据去重与污染检测经常被放在同一个技术框架里讨论。

这篇文章讲的不是一个大而全的平台，而是一套“最小复现”的完整链路：从 n-gram 这种最朴素的字符重叠度开始，先解决字面重复；再引入语义候选，用 embedding 和向量检索把“被改写但意思一样”的文本也捞出来。整个方案不需要分布式集群，不需要大规模标注，一两台普通机器就能跑起来。适合刚接触数据清洗的算法工程师，也适合负责数据治理、训练集质量管控的工程同学参考。

先说一句大实话：这类需求没有一个万能参数能一劳永逸。不同数据分布、不同业务场景，阈值基本都要重新校。但底层的处理思路是通用的，把这套流程吃透了，后面换语言、换场景、换模型，都是改配置的事。

1. 整体思路设计：为什么去重和污染检测共用一套相似度框架

1.1 两个任务目标不同，技术本质却一致

数据去重，目标是让训练集里尽量不出现重复或高度相似的样本，避免模型对高频信息过拟合。污染检测的目标则更聚焦：某一条或某几条测试样本，是否已经出现在大规模训练语料中。如果出现了，拿到的评测分数就不真实。

但无论哪种场景，操作对象都是“文本对”，核心动作都是判断两条文本是否相似、相似程度有多高。去重可以视为“全量语料内部的任意两两比较”，污染检测可以视为“测试集与训练语料之间的交集检索”。差异只在比对范围，计算逻辑基本可以复用。

所以最小复现的第一步，就是想清楚用一个可插拔的文本相似度组件去支撑这两个任务，而不是为去重写一套、为污染检测再写一套。我见过不少团队把两件事拆成两个项目，最后数据管道维护成本翻倍，明显不划算。

1.2 从 n-gram 到语义候选，是一条由浅入深的技术递进路线

n-gram 的做法是把文本切成连续的 n 个字符或 n 个词，然后比较集合的重叠程度。它快、稳定、完全可解释，而且不需要任何模型推理，适合做第一道粗筛。但它的天花板也很明显：只认字面，不认语义。同一件事换个说法，n-gram 相似度可以低到和两段无关文本差不多。

语义候选则试图理解“这段文本在说什么”。基本思路是把文本编码成稠密向量，再通过向量距离判断语义相似度。它能抓住“北京是中国的首都”和“中国的首都是北京”这类改写，但代价是需要加载模型、跑推理，还要建向量索引，计算成本比 n-gram 高几个量级。

工程上不能二选一，而要串联。我的做法是两层漏斗：先用 n-gram 粗筛，把所有相似度明显偏低的候选对直接排除；留下的少量候选对再做语义向量精排。比如一千万条语料，n-gram 粗筛后可能只剩几万对候选，这时候再跑 embedding，算力完全扛得住。

1.3 最小复现的边界

“最小”的意思是：不追求极致的工程性能，先把链路跑通。你不需要 Spark、不需要向量数据库集群，只需要 Python 环境、一个字符 n-gram 工具、一个轻量 embedding 模型、一个单机向量索引库。数据量在百万级以内这套方案都够用；如果未来数据量涨到亿级，再横向扩展底座也不迟。

2. n-gram 去重的最小实现：从 shingle 到 MinHash

2.1 shingle 切分与 Jaccard 相似度

n-gram 在英文场景常按词切，但在中文场景我更推荐按字符切。原因很简单：中文分词本身就有误差，一旦分词错了，后续的 n-gram 集合就会带偏；按字切则完全不需要分词，鲁棒性更好。比如对文本“数据清洗与去重”，如果取三元字符 n-gram，可以切成“数据清”“据清洗”“清洗与”“洗与去”“与去重”这 5 个 shingle。

然后两条文本的相似度用 Jaccard 系数来度量，公式很简单：

[
J(A, B) = \frac{|A \cap B|}{|A \cup B|}
]

也就是两个 shingle 集合交集的大小除以并集的大小。完全相同为 1，完全无关趋近于 0。这个指标的好处是天然在 0 到 1 之间，方便定阈值。

最小复现的代码其实很短：

python复制def create_shingles(text: str, n: int = 3) -> set:
    text = text.strip()
    if len(text) < n:
        return {text}
    return {text[i:i+n] for i in range(len(text) - n + 1)}

def jaccard(set_a: set, set_b: set) -> float:
    if not set_a or not set_b:
        return 0.0
    inter = len(set_a & set_b)
    union = len(set_a | set_b)
    return inter / union

这段代码在几千条数据上做两两比较没什么问题，但数据量一上来就尴尬了。假设有一万条文本，两两比较就是一亿次集合运算，每次还要做交集并集，运行时间会肉眼可见地变长。这时候就需要 MinHash。

2.2 MinHash 签名：大规模近似去重的基础

MinHash 的核心思想很简单：我不直接比较 shingle 集合，而是把每个 shingle 集合压缩成一个固定长度的签名向量，用签名向量的重合比例来近似估计 Jaccard 相似度。

具体做法是准备 k 个哈希函数，对集合里每个 shingle 依次做哈希，记录每个哈希函数下的最小值，得到一个 k 维向量。两个集合的签名向量中，取值相同的维度占比，就是 Jaccard 相似度的无偏估计。k 越大，估计越准。

Python 里最常用的库是 datasketch：

python复制from datasketch import MinHash

def minhash_from_text(text: str, n: int = 3, num_perm: int = 128) -> MinHash:
    m = MinHash(num_perm=num_perm)
    shingles = create_shingles(text, n)
    for shingle in shingles:
        m.update(shingle.encode("utf-8"))
    return m

m1 = minhash_from_text("数据清洗与去重")
m2 = minhash_from_text("数据清洗与去重方案")
print(m1.jaccard(m2))

这里 num_perm=128 是比较常规的配置，精度足够且内存占用不大。实际操作中我通常对全部文本生成 MinHash 签名，然后再借助 LSH（Locality Sensitive Hashing）做候选对召回，避免 O(n^2) 的全量两两比较。

不过最小复现阶段，如果数据量只有几万到十几万条，直接用双重循环或分块比较也不是不能接受。我个人的经验是：先跑通，再优化。直接上 LSH 容易把逻辑复杂度推高，调试成本也大。

2.3 n-gram 阈值怎么选才不冤枉人

n-gram 阈值和 n 的选择强相关。我常用的经验值：

• n=3（字符三元组）时，Jaccard 达到 0.5 以上基本是明显重复。
• n=5 时，因为 shingle 更稀疏，Jaccard 达到 0.3 就需要警惕。
• 如果只做文本去重，且语料是网页正文这类长文本，阈值可以调高一些；如果是短文本（如 query、评论），阈值要适当降低。

但经验值大概率没法照搬。最靠谱的做法是抽几百对“你认为是重复”和“你认为不重复”的样本，把 n-gram 相似度都算一遍，看分布是否分得开。这个操作很朴素，但确实比拍脑袋定阈值可靠得多。

2.4 n-gram 方法的边界

n-gram 处理不了同义改写和语序调整。举一个很典型的例子：“我喜欢猫”和“猫是我最喜欢的动物”，字面上完全不一样，n-gram Jaccard 可能连 0.1 都不到，但语义上高度一致。如果你做的是新闻去重、评测数据污染检测这类任务，这种改写非常常见，只靠 n-gram 必然漏检。

另外 n 如果设得太小，比如 n=1，文本里高频字太多，几乎所有句子相似度都不会低，噪声极大；n 设得太大，改写稍微一变就匹配不上。不同场景需要多做几次实验找平衡点。

3. 语义候选的实现：embedding 召回与相似度精排

3.1 语义候选要解决的问题

语义候选不是要替代 n-gram，而是补上它的盲区。当两条文本字面差异很大、但信息内容等价时，我们需要在向量空间里发现它们的相似性。

一个很常见的污染检测场景是：测试题目的题干被稍微改了几个同义词后混进了训练语料。n-gram 匹配不上，但语义层面几乎是同一道题。这种问题不做语义候选根本没法发现。

另一个场景是网页正文的转载改写。很多内容农场会把一篇新闻换换句式、换换形容词再发布，单看字符重叠度不算高，但语义内容完全重复。语义候选就是为这类情况兜底的。

3.2 Embedding 模型怎么选

中文文本相似度场景里，我常用的模型包括 text2vec-base-chinese、m3e-small、bge-small-zh 等。个人体验是，bge 系列在中文语义匹配上稳定度更好，bge-small-zh 的体量也适合单机跑。如果文本里中英文混杂，可以考虑多语言模型，但向量维度和推理耗时都会涨，需要权衡。

用起来很简单，以 sentence-transformers 为例：

python复制from sentence_transformers import SentenceTransformer

model = SentenceTransformer("BAAI/bge-small-zh-v1.5")
docs = ["我喜欢猫", "猫是我最喜欢的动物", "今天天气很好"]
embeddings = model.encode(docs, normalize_embeddings=True)

注意这里 normalize_embeddings=True，归一化之后用内积就能等价 cosine 相似度，后面接 faiss 检索会更方便。

选模型唯一的硬性要求是：先拿自己业务里的正负样本跑一遍，别只看公开榜单。语义相似度模型在不同领域数据上的表现差异很大，领域术语多的场景尤其明显。

3.3 向量索引与候选召回

向量化之后，如果数据量不大，直接两两算 cosine 也勉强可以。但做“最小复现”至少要留一点扩展余地，所以我建议直接用 faiss 建索引。

python复制import faiss
import numpy as np

dim = embeddings.shape[1]
index = faiss.IndexFlatIP(dim)
index.add(embeddings)

# 对单条 query 做 top-k 召回
query_vec = model.encode(["我喜欢猫"], normalize_embeddings=True)
scores, idx = index.search(query_vec, k=10)
print(scores, idx)

IndexFlatIP 是暴力精确检索，复杂度依然是 O(n)，但 faiss 底层做了大量矩阵运算优化，单机百万级向量查询一次也就几毫秒，非常够用。如果想更进一步提高性能，可以换 IndexIVFFlat 或 IndexHNSWFlat，但最小复现阶段没必要。

需要提醒的是，faiss 索引一旦建立，要想增量添加数据会比较麻烦，通常的做法是定期批量重建索引。对离线去重和污染检测这类任务来说，这完全不是问题。

3.4 语义相似度的阈值参考

语义相似度阈值也和业务强相关，但大体上：

• cosine 达到 0.9 以上，基本可以判定为同一意思的改写。
• 0.8 到 0.9 之间，大概率是语义相近，需要结合具体业务决定是否判重。
• 0.7 以下，通常不算重复，但短文本场景要小心，短句的向量分布更密集，相似度普遍偏高。

这里我踩过一个坑：长文本的 embedding 向量容易被平均池化“稀释”。一篇几千字的文章和它的摘要，向量相似度有时反而不高。所以如果处理长文本，建议先切片或抽关键句，再对向量做聚合，而不是整段丢进去。

4. 最小复现的完整链路：粗筛 + 精排的一套可落地骨架

4.1 整体处理流程

我还是用文字把这个链路先描述清楚，方便你对照自己项目里的环节。

输入是一个文本列表，每一行表示一条样本。第一步做文本归一化，比如去掉多余空白、统一全角半角、去除 HTML 标签等。第二步生成每条文本的 n-gram shingle，以及对应的 MinHash 签名，做一次粗筛召回，把所有 n-gram Jaccard 超过低阈值的候选对捞出来。第三步对候选对做 embedding 编码，用 faiss 或直接对向量做精确匹配，计算语义相似度。第四步根据一套组合规则输出最终的疑似重复/污染列表。

这套流程整体上是两阶段漏斗。n-gram 负责用极低的成本排除绝大多数无关样本，语义模型只处理真正需要判断的候选对，计算量完全可控。

4.2 代码骨架

下面是一个浓缩版的可运行骨架，重点在结构清晰，不追求极致性能：

python复制import hashlib
from datasketch import MinHash
from sentence_transformers import SentenceTransformer
import faiss
import numpy as np

def normalize_text(text: str) -> str:
    text = text.strip().replace("\u3000", "").replace(" ", "")
    return text

def build_minhash(text: str, n: int = 3, num_perm: int = 128) -> MinHash:
    m = MinHash(num_perm=num_perm)
    shingles = create_shingles(normalize_text(text), n)
    for s in shingles:
        m.update(s.encode("utf-8"))
    return m

def recall_by_minhash(docs, threshold: float = 0.3):
    minhashes = [build_minhash(doc) for doc in docs]
    candidates = []
    for i in range(len(docs)):
        for j in range(i + 1, len(docs)):
            sim = minhashes[i].jaccard(minhashes[j])
            if sim >= threshold:
                candidates.append((i, j, sim))
    return candidates

def semantic_verify(docs, candidates, model_name: str = "BAAI/bge-small-zh-v1.5"):
    model = SentenceTransformer(model_name)
    vecs = model.encode(docs, normalize_embeddings=True)
    results = []
    for i, j, base_sim in candidates:
        cos_sim = float(np.dot(vecs[i], vecs[j]))
        results.append({
            "pair": (i, j),
            "n_gram_sim": base_sim,
            "semantic_sim": cos_sim,
        })
    return results

# 使用示例
docs = ["我喜欢猫", "猫是我最喜欢的动物", "今天是个好天气", "今天天气很好"]
candidates = recall_by_minhash(docs, threshold=0.2)
results = semantic_verify(docs, candidates)
for r in results:
    print(r)

这个骨架里 semantic_verify 直接用了向量点积，前提是已经归一化。如果候选对数量很大，可以先把所有向量加入 faiss 索引，再按候选对取对应向量算相似度，避免重复加载模型。

注意，我这里的粗筛阈值设置成 0.2 只是为了演示，真实场景需要根据样本分布去校准。如果粗筛阈值设得太低，后续语义精排的候选对会很多；设得太高，漏召回会增加。

4.3 阈值从哪来：用标注样本反向校准

“最小复现”不代表可以随便拍一个数值就用。我一般的做法是：

先随机抽 300 对文本，人工标注是“重复/相似/不重复”三分类。然后分别计算这些样本的 n-gram Jaccard 和语义 cosine。画出分布图，看哪个阈值能把重复和相似样本尽量区分开。如果两类指标都区分不明显，可能要考虑换 embedding 模型或调整 n-gram 的 n 值。

下面是一张我常用的决策表示意图：

这个表里的数字必须基于你自己的样本分布回调，不要照搬。它更重要的意义是提供一种结构化判断思路：高分直接过，中等分数转人工，低分看语义分是否极端。

4.4 混合判断规则的目的

混合规则不是为了让流程复杂，而是为了在两类错误之间取得平衡。n-gram 直接判重可以保证字面重复一定有很高的召回；语义模型单独处理改写场景，避免漏掉真正的语义重复。两者结合，误报和漏报都能压在一个可接受范围内。

实际工程中真正难调的不是某个算法的参数，而是两个算法之间如何衔接。比如候选对的生成，到底用 n-gram 召回还是用向量召回，取舍完全不同。在最小复现阶段，先用 n-gram 召回候选，再用语义精排，是这个场景里最简单也最不容易翻车的组合。

5. 常见问题与排查技巧实录

5.1 误判和漏判，哪个更不能忍

去重场景里，误判的代价是删掉一些不算重复但相似的样本，造成数据量无谓缩水。污染检测场景里，漏判的代价是脏数据混进训练集，评测分数虚高。因此两种场景对阈值的倾向不同：去重可以稍微保守一点，只在相似度很高时才判重；污染检测则应该把召回率放在第一位，哪怕多了一些候选交给人工复核，也不能放过真正的污染样本。

排查的时候，先随机抽 50 个被判定为重复、50 个被判定为不重复的样本，人工刷一遍。如果被判重复的大量是“只是话题相似但内容完全不同”的文本，说明阈值偏松；如果被判不重复的大量是同一篇新闻的明显改写，说明语义部分漏检严重。

5.2 工程实现里容易踩的坑

第一个坑是编码不一致。全角半角符号混用，中文引号、中文括号转换不彻底，会把本应重复的文本拆成不重复。我建议在预处理阶段统一做全角转半角，并把所有空白字符归一化。

第二个坑是 embedding 截断。很多模型有最大序列长度限制，比如 512 token，超长文本被直接截断，代表整篇内容的向量就会失真。处理长文本时，最好分句后取平均或按 tf-idf 加权聚合，而不是整段丢进去。

第三个坑是 faiss 索引和向量维度不一致。代码里如果混用了两个不同维度模型产出的向量，faiss 会直接报错。建议在建索引前打印一下 embeddings.shape，并保证所有向量来源是同一个模型、同一种预处理逻辑。

第四个坑是 datasketch 的 MinHash 对象不能直接做 pickle 持久化后再跨 Python 版本加载，升级环境后我遇到过签名不一致的问题。稳妥做法是保存 shingle 列表或临时重新生成 MinHash，不要长期复用序列化文件。

5.3 阈值不要一劳永逸，定期抽检很有必要

文本分布会随业务变化，尤其是舆情、资讯、电商评论这类数据，表达方式变化非常快。上个月的阈值下个月可能就不合适了。我建议每跑完一批数据，把阈值附近的样本抽出来人工过一眼，看看判定边界是否符合直觉。

如果想让阈值调整更规范，可以维护一个小型的回归测试集，包含固定数量的重复样本和污染样本。每次调整算法或模型后，都拿这个测试集跑一遍指标，确保没有把原本正确的判断改坏。这个步骤看似笨重，但在长期迭代里能省很多时间。

我个人在实际项目里的体会是：数据去重和污染检测最难的部分往往不是算法选择，而是你愿不愿意花时间把“什么是重复”这个业务定义理清楚。技术手段只是帮你把判断规模放大到百万、千万级别，但判断标准始终要由人来定。先把最小复现跑通，再逐步校准阈值、优化性能，这条路对绝大多数团队来说都是最务实的。