前阵子接手了一个库存管理系统的日志清洗任务里面有个需求很典型把客服提交的重复工单合并掉。工单内容不是完全一样而是“大致一样”——比如有人写“商品收到时外包装破损”另一个人写“外包装损坏商品本身没问题”再往后翻又有一条“外包装有破损痕迹”。三条内容电脑一眼看过去就知道是同类问题但传统数据库的等值查询完全抓不到。这时候就需要文本相似度计算。文本相似度这个领域说大也大说小也小。往大了说搜索引擎、问答系统、知识图谱实体对齐、推荐系统去重、代码查重全都离不开它往小了说核心问题就一个怎么用数值去衡量两段文本在语义或字面上的接近程度。我在实际项目里用过不少方案从最朴素的字符比较到后来深度学习时代的语义向量演进路线非常清晰。这篇文章就把我这些年实测过的、工业界真正在用的文本相似度算法梳理一遍把每类方案的原理、适用场景、代码实现和踩坑经验都讲透。不管你是刚入行的数据分析师还是在做搜索/去重/知识库问答的工程师这篇应该都能给你一个选型参考。1. 从拼写差异到集合重叠字符层面的相似度怎么算先聊最直接的一类思路不关心词义也不关心语法就把文本当成一串字符或者一个集合去算它们的重叠程度。对于短文本、拼写错误较多的场景这类方法反而又快又稳。1.1 编辑距离Levenshtein Distance文本之间的“最小手术次数”编辑距离的定义很朴素把字符串A变成字符串B最少需要多少次“增、删、改”操作。比如把“abc”变成“abd”只需要把最后那个c改成d一次操作距离就是1。这个算法用动态规划实现非常优雅状态转移方程写出来def edit_distance(s1: str, s2: str) - int: m, n len(s1), len(s2) dp [[0] * (n 1) for _ in range(m 1)] for i in range(m 1): dp[i][0] i for j in range(n 1): dp[0][j] j for i in range(1, m 1): for j in range(1, n 1): if s1[i - 1] s2[j - 1]: dp[i][j] dp[i - 1][j - 1] else: dp[i][j] min( dp[i - 1][j] 1, # 删除 dp[i][j - 1] 1, # 插入 dp[i - 1][j - 1] 1 # 替换 ) return dp[m][n]空间复杂度是O(m×n)不过实际工程中可以用滚动数组压缩到O(n)。这里dp[i][j]的含义是s1[:i]变到s2[:j]的最小操作次数边界条件里dp[i][0]i表示要删除i个字符才能变成空串。编辑距离拿到的是绝对差值不同长度的文本不好直接横向对比所以工程上更常用归一化编辑距离def normalized_edit_similarity(s1: str, s2: str) - float: d edit_distance(s1, s2) return 1 - d / max(len(s1), len(s2))实测下来长度差不多的短文本用归一化编辑距离非常直观比如比对身份证号、手机号、地址这种格式化的字段错一个字符就能精准识别出来。编辑距离的变体里Damerau–Levenshtein距离还额外把“相邻字符互换”算作一次操作。比如“ab”变“ba”经典编辑距离要两次替换加上互换后只要一次。英文文本里常见的拼写错误是顺序颠倒所以用这个变体效果会更好一些。提示如果处理的是纯文本字符串相似度并且文本长度基本一致编辑距离可以作为首选但比如一段500字的文章和一段50字的摘要去算编辑距离结果基本不可用需要换成后面讲的统计类或语义类方法。1.2 Jaccard相似度把文本看成集合Jaccard相似度是另一类常见思路计算公式很简单J(A, B) |A ∩ B| / |A ∪ B|A和B可以是字符集合也可以是分词后的词集合。分子是交集大小分母是并集大小取值范围永远是0到1。两段文本完全没有重叠的词相似度就是0如果词完全一样、只是顺序不同Jaccard是1。但这暴露了一个问题Jaccard对词序完全不敏感。“我打你”和“你打我”的Jaccard相似度是1.0可意思完全相反。不过在某些特定场景Jaccard依然好用。比如短文本去重、问答系统里用户问题与标准问题的匹配——前提是问答之间一般不会有太复杂的词序变化。另外它在推荐系统里算用户/物品的集合相似度也很常用因为那里的“文本”往往是标签集合顺序本来就无所谓。1.3 字符n-gram兼顾局部顺序的中间方案既然编辑距离对长文本不给力、Jaccard又不关注顺序有没有中间路线有n-gram。n-gram就是把文本按滑动窗口切成连续的n个字符然后把这些子串当成集合或特征。比如“你好世界”切成2-gram就是[你好, 好世, 界世]注意这里我没用边界符实际工程中通常会加上特殊字符标记开头和结尾。对两个文本分别生成n-gram集合后可以计算Jaccard或余弦相似度。n-gram的巧妙之处在于它通过连续字符保留了局部顺序信息又不像编辑距离那样要求全局对齐。实测中2-gram适合中文短文本3-gram适合英文单词级别的切分。字符n-gram还有个好处天然抗噪声。像上面客服工单的例子“外包装破损”和“外包装损坏”2-gram集合的重叠度就很高能直接命中不需要额外训练模型。算法核心思想优点典型局限适合场景编辑距离最小增删改次数精确到字符可解释性强对长文本敏感计算量大短文本、字段校验Jaccard集合交并比简单快速对词序不敏感完全丢失顺序信息标签集合、短文本去重n-gram Jaccard/余弦局部顺序保留抗拼写错误无需训练对语义无感知噪声较多的短文本匹配2. TF-IDF与余弦相似度为什么词频统计依然是工业界的基准字符层面的算法看不懂词义这导致它们有一个致命短板同义词完全匹配不上。比如“如何申请退款”和“怎么退钱”字面上几乎不重合但人一看就知道是一个意思。这时候就需要把文本从“字符序列”提升到“词语的统计特征”。2.1 TF-IDF的直觉词频与逆文档频率的平衡TF-IDF由两部分组成TF词频某个词在本文档中出现的次数。IDF逆文档频率log(总文档数 / 包含该词的文档数)用来衡量一个词在语料库中的稀缺程度。直觉很好理解“退款”如果只在少数投诉工单里出现IDF值就高说明它是区分文本主题的关键词而“的”“了”“我”这种词几乎每篇都有IDF值趋近于0天然被压制。在使用TF-IDF时一般还会对TF做归一化比如用词频除以文档总词数避免长文档天然有更高的词频。IDF也常用平滑版本IDF(t) log((N 1) / (df(t) 1)) 1这里的N是总文档数df(t)是包含词t的文档数。加1是防止除零公式最后再补一个1是保证IDF恒为正数——这样即使某个词在所有文档里都出现它的IDF也不至于变成0甚至负数。2.2 向量化与余弦相似度的计算过程把每个文档表示成一个向量向量的每一维对应一个词值是该词的TF-IDF权重。得到向量后计算两个文档的相似度最常用的就是余弦相似度cosine(A, B) (A · B) / (|A| * |B|)余弦相似度衡量的是两个向量的夹角而不是欧氏距离这意味着它只关心方向不关心模长。这在文本场景里极其重要——一篇500字的文章和它被截断成200字的摘要词的分布比例相近余弦相似度依然很高而欧氏距离就会因为维度数值大小差异变得不靠谱。用Python实现其实很简单直接用sklearn的TfidfVectorizerfrom sklearn.feature_extraction.text import TfidfVectorizer from sklearn.metrics.pairwise import cosine_similarity docs [ 如何申请退款, 怎么退钱, 商品收到时外包装破损 ] vectorizer TfidfVectorizer(token_patternr(?u)\b\w\b) tfidf_matrix vectorizer.fit_transform(docs) sim_matrix cosine_similarity(tfidf_matrix[0:1], tfidf_matrix[1:2]) print(sim_matrix[0][0]) # 如何申请退款 vs 怎么退钱这里需要注意token_pattern参数TfidfVectorizer默认按“单词边界”切分对中文来说必须设置token_pattern或者使用jieba先分词再传入否则中文会被切成单字效果大打折扣。2.3 为什么中文场景要先分词再算TF-IDF中文和英文不一样英文天然用空格分词中文没有明显的分隔符。直接按单字符切分词义信息就碎了。所以中文TF-IDF计算前必须分词import jieba def chinese_tokenize(text: str) - list: return [w for w in jieba.cut(text) if w.strip()] docs_tokenized [ .join(chinese_tokenize(d)) for d in docs] vectorizer TfidfVectorizer() tfidf_matrix vectorizer.fit_transform(docs_tokenized)做这个处理之后“退款”和“退钱”仍然会被当成两个独立的词TF-IDF并不能理解它们语义相近。所以TF-IDF解决的是“词频分布”层面的相似度而不是“词义”层面的相似度。真正要理解同义词就需要引入词向量和深度学习模型也就是下一节的内容。2.4 我在工单去重里的实测体会在我做的那个工单合并项目里一开始用的就是TF-IDF加余弦相似度效果比我预想中好。原因是客服工单往往集中在几个固定的投诉分类里“退款”“物流”“破损”“客服态度差”这些词的重复频率极高TF-IDF能很好地捕捉这些关键词的分布。但有两个环节必须注意停用词过滤必须做。工单里“请问”“你好”“麻烦问一下”这些客套话每篇都有如果不加停用词表这些词的TF值会被抬高反而稀释了真正关键词的权重。阈值需要抽样调。不同业务场景下相同意思的文本用词差异大小完全不同。我当时的做法是人工标注了200对相似/不相似样本在0.5到0.95之间画了一条精确率-召回率曲线最后选了平衡点0.82。3. 语义相似度才是终极解法从Word2Vec到Sentence-BERT的进化TF-IDF这类基于词频统计的方法本质是“文字的匹配”不是“语义的匹配”。当文本里大量使用同义词、口语化表达、甚至是不同语种混排时词频方法就会失效。要做语义层面的相似度必须先把文本映射成可以捕捉语义的向量。3.1 Word2Vec给词一个可以加减的向量2013年Google提出的Word2Vec是词向量时代的标志性成果。它基于一个核心假设一个词的意义可以从它周围的词推断出来。有两种训练模式CBOW用上下文预测中心词。Skip-gram用中心词预测上下文。训练完成后每个词被映射到一个低维稠密向量比如300维。这些向量有一个非常神奇的性质语义相近的词向量在空间中距离很近“国王”减“男人”加“女人”结果向量会落在“女王”附近。Word2Vec训练代码在gensim里写起来非常简洁from gensim.models import Word2Vec sentences [[我, 想, 申请, 退款], [怎么, 才能, 退钱]] model Word2Vec(sentences, vector_size128, window5, min_count1, sg1) vector model.wv[退款]注意Word2Vec给出的是词向量不是句向量。要计算整段文本的相似度常见的做法是把文本里所有词的词向量做平均。这个方法在短文本语义匹配上比TF-IDF已经有质的提升因为它能让“退款”和“退钱”这两个词在同一向量空间里“互相看得到”——前提是这两个词在训练语料里出现过相似的上下文。3.2 从词向量到句向量没那么简单把所有词向量简单平均效果虽然可用但有个问题无关紧要的词会稀释关键词的权重。比如“我想申请退款”这句里“我想”这种虚词对语义没贡献却占了50%的权重。针对这个问题学术界提出过SIF加权平均Smooth Inverse Frequency方法。思路是对词频高的词降低权重然后对得到的向量做一个主成分方向修正。实测下来SIF在短文本相似度任务上比普通平均有明显提升而且实现成本很低十几行代码就能搞定。不过话要说回来词向量平均得到的句向量本质上还是没有充分建模词序和句法结构。“我打你”和“你打我”里的词向量是完全一样的集合平均之后的结果一模一样这在前面的Jaccard部分就提到过词序问题不解决语义相似度就始终隔着一层。3.3 Sentence-BERT把整句编码成一个语义向量Transformer架构出现之后BERT这类预训练模型可以通过自注意力机制充分建模词序、句法、上下文信息。用BERT直接给句子编码取[CLS]位置的输出当句向量理论上很完美但直接这么用效果并不好——原因是BERT没有专门为一个句子生成语义向量这个目标做过优化它学习的目标是完形填空和句子关系判断因此[CLS]向量并不天然适合相似度计算。2019年提出的**Sentence-BERTSBERT**解决了这个问题。它的核心方法是让两个句子分别经过同一个共享权重的BERT编码器输出两个句向量然后通过孪生网络结构在有监督的标注数据上训练目标函数是让相似句对的向量距离更近不相似句对更远。用sentence-transformers库加载现成的SBERT模型非常简单from sentence_transformers import SentenceTransformer from sklearn.metrics.pairwise import cosine_similarity model SentenceTransformer(shibing624/text2vec-base-chinese) emb1 model.encode(如何申请退款) emb2 model.encode(怎么才能退钱) sim cosine_similarity([emb1], [emb2]) print(sim[0][0])这个模型是中文社区常用的Text2Vec中文模型实测效果比直接用开源BERT的[CLS]好非常多。“退款”和“退钱”的相似度SBERT能打到0.8以上而TF-IDF方法可能只有0.2。SBERT这类方法真正把文本相似度从字符串匹配带到了语义匹配的水平。搜同义问题、找相似文章、做智能客服的FAQ匹配工业界大规模落地基本都是这套东西。3.4 一种更轻量的替代BM25加相似度重排在一些没有GPU、不允许用大模型的业务场景里工业界还常用BM25粗召回SBERT精排这种组合方案。BM25是搜索领域经典的排序函数它类似TF-IDF的升级版考虑了文档长度和词频饱和因子。先靠BM25快速把候选集缩小到Top 200再用SBERT逐个精排既能控制延迟又能提升召回率。我后来做的工单合并系统就是这么设计的先用BM25针对每一条新工单从历史工单库里召回最相似的50条再用SBERT对这50条算精确相似度最后设定阈值合并。单条工单处理时间从全量两两比对的上百毫秒降到了几十毫秒准确率还更高了。4. 工程落地时的选型指南场景、阈值、性能一个都不能少聊完算法本身说说工程落地。我在实践中发现很多团队不是不懂算法而是不知道怎么根据场景选算法、定阈值、控性能。这部分把选型方法论讲清楚。4.1 不同业务场景应该选哪一类算法直接给结论表业务场景推荐算法理由身份证号/手机号等字段去重归一化编辑距离精确度高可解释短文本相似问题匹配客服FAQTF-IDF余弦 或 SBERT需要语义理解词频方法做baselineSBERT做提升长文本查重文章、报告SimHash 或 MinHash效率优先海量数据下可以做近似去重代码/文件片段查重编辑距离 token序列比对需要精确定位不能只靠语义用户评论聚类BERT句向量 K-Means需要语义聚类传统向量在口语化场景不够用4.2 相似度的阈值到底怎么定阈值设低了误报多设高了召回低这个平衡没有银弹只能靠标注数据调。我的标准流程是从业务数据里随机抽500条文本两两配对尽量让“相似”和“不相似”的比例接近1:1。人工标注这些配对是否应该被当成“相似”。用候选算法计算每对文本的相似度分数画出ROC曲线或者精确率-召回率曲线。根据业务的容错偏好在曲线上选阈值。如果误报的后果严重比如自动合并工单会删数据就选精确率高的阈值如果漏报更麻烦就选召回率高的阈值。我实际遇到最多的场景是业务方拍脑袋定了一个0.75的阈值结果上线后发现大量误合并。原因很简单阈值和算法、数据分布强相关不能用别的项目的经验直接套。4.3 性能优化文本相似度最大的敌人是两两比对文本相似度计算里最容易被低估的是复杂度问题。N条文本朴素两两比对复杂度是O(N²)。1万条数据就是1亿次计算10万条直接爆炸。工程中一般用以下策略分层过滤粗召回先做一轮快速筛选比如利用倒排索引只计算共享至少一个关键词的文本对或者对短文本用MinHash/SMASH进行近似集合相似度搜索把候选对从百亿量级降到百万量级。精排只对粗召回后的候选对做高精度的相似度计算比如SBERT向量余弦相似度或编辑距离。增量更新如果数据是流式进入的不要每次全量重算维护一个向量索引新数据进来时只计算它与已有数据之间的相似度。在向量存储层面如果使用的是SBERT产生的语义向量还可用FAISS或Milvus这类向量数据库做近邻检索。它们的核心思路是构建HNSW层次化可导航小世界图或者IVF倒排文件索引能在毫秒级返回Top-K最相似的向量避免全量暴力比对。用过FAISS就知道从10万条向量里找相似延迟从O(N)暴降到了几毫秒。4.4 预处理的重要性规范化做不好算法再好都白搭文本相似度项目里数据清洗的收益往往比换算法更大。我踩过一个很典型的坑电商评论里有人写“苹果”有人写“apple”TF-IDF和编辑距离全都匹配不上还有人写“苹 果”中间带了个空格以及全角半角标点混合的情况。所以预处理环节至少要做这几件事统一大小写英文全部转小写。统一全角半角中文和英文符号都转成半角。繁体转简体中文语料经常繁简混杂。去除空白符号把多个空格、换行、特殊符号规范化。同义词/别名映射建立业务词表比如“苹果”和“apple”映射到同一规范词。这些步骤不涉及算法但对结果的提升立竿见影。一个人工维护的业务同义词表能解决很多深度学习模型都不一定处理好的领域专有名词问题。5. 我在真实项目里踩过的几个坑以及对应的解法讲完主流程专门用一个章节写我在文本相似度落地过程中真实踩过的坑。这些坑在论文和官方文档里通常看不到但每一个都能让线上效果翻车。5.1 坑一中文直接套英文文本处理的默认参数用TfidfVectorizer算中文相似度时如果直接用默认参数会发现出来的相似度极其离谱。原因是我前面提到的token_pattern它默认匹配的是英文单词的正则。中文文本会被切成一堆单字比如“我想申请退款”变成“我”“想”“申”“请”“退”“款”六个独立的维度词义完全丢失。解法是使用jieba分词后用空格把分词结果拼接起来再传给TfidfVectorizer。另外一个隐藏细节是TfidfVectorizer的默认max_df1.0如果用一个小语料库去拟合会发现所有词都被当成有效词包括“的”“了”这类虚词设置max_df0.8可以过滤掉大多数文档中都出现的词对相似度计算更友好。5.2 坑二文档长度差太大余弦相似度失真我试过把一篇3000字的商品描述拿去和一段20字的主标题算TF-IDF余弦相似度结果几乎总是很低。原因不是语义不相关而是长文档的向量维度稀疏、词频权重分散和短文本的向量很难在方向上对齐。解决这个问题的办法是分窗口计算。把长文档按段落或者滑动窗口切成长度相近的片段分别和短文本算相似度取最大值或平均值。还有一种方法是放弃TF-IDF这类“稀疏高维”表示改用稠密向量模型比如SBERT它把文本压缩成固定维度的语义向量维度不随文本长度增加对长短文本之间的比较更友好。5.3 坑三评测指标只看准确率结果线上召回崩了在工单合并的测试阶段我一开始只用准确率评估模型阈值调到0.9准确率高达98%。上线后发现大量相似工单没被合并业务方抱怨“该合的没合”。原因很清楚我调阈值时只盯着“算法判定相似的样本里有多少是对的”完全没看“真正相似的样本里算法找回了多少”。后来我把评估改成同时看精确率和召回率并盯着F1值调阈值。具体到工单场景漏合并的代价用户重复投诉、工单翻了3倍比误合并大得多所以我最终把阈值降到0.75左右召回率从60%提升到90%F1明显变好。结论是阈值不只看曲线还要结合业务方的容忍度来定。5.4 坑四样本极度不平衡导致评估失真某些应用场景比如反欺诈文本识别“相似”样本可能只占总体配对的万分之一。如果直接算准确率哪怕把阈值设到0.99把所有样本都判成“不相似”准确率依然是99.99%但这个分类器毫无用处。这种情况需要从数据层面平衡样本或者在评估时使用假正例率/假负例率这类更敏感的指标。我在做相似度项目时通常会构建一个包含一半正样本、一半负样本的评估集虽然违背了真实分布但能更灵敏地观察到阈值变化对模型行为的影响。5.5 坑五模型更新后相似度分数分布漂移用Sentence-BERT这类模型时换一个版本的预训练模型或者把微调数据从1000条变成10万条都会导致输出向量的绝对分布发生变化。上一版模型里0.8的相似度可能算“相似”下一版模型里0.8可能已经算“非常相似”了。我维护的相似度系统里专门做了一个分数漂移监控每次模型更新时跑一个固定的基准数据集对比新旧模型在相同文本对上的相似度均值、方差、分位数。如果分布偏移超过某个阈值就要重新标注样本、重定阈值。这些细节不处理模型一升级线上业务就可能莫名其妙地出问题。5.6 坑六语义向量做相似度解释性不足深度学习模型的相似度结果只能给一个分数却不能回答“为什么这两条文本相似”。在某些场景比如需要审核、需要告警理由的合规系统这种不可解释性会带来很大问题。我现在的做法是混合方案用SBERT做语义召回同时保留TF-IDF的top关键词、字符n-gram的重叠信息生成一个“相似度证据链”。业务系统展示相似结果时在页面上列出重叠的高权重词和高相似片段既能利用语义模型的威力又保留了可解释性。这个方案在客服工单合并场景里业务方接受度特别高。6. 选型决策树与我的个人推荐清单最后整理一个可以直接照着用的选型决策路径。如果你只是需要一个“能用”的方案按着这个路径走基本不会踩大坑。如果做的是短文本、字段级别的精确匹配比如ID、手机号、地址、品牌名优先选归一化编辑距离文本还包含大量拼写错误就用Damerau-Levenshtein。如果做的是长文本去重文章、报告、商品详情的重复检测优先做一件重要的事——数据清洗和规范化然后用SimHash或MinHash做粗筛。如果做的是短文本语义匹配FAQ问答、客服工单、评论主题识别直接上SBERT类模型中文推荐text2vec-base-chinese更大语料用bge-large-zh配FAISS索引做向量召回。如果公司没有GPU也没有预算训练模型中文分词 TF-IDF 余弦相似度永远是性价比最高的基线先跑通再想升级。如果要求速度快、可解释性强但是语义要求又高就选择BM25粗召回 SBERT精排的混合架构。算法选型从来不是越贵越好。我在实际项目里见过不少团队一上来就用了大规模预训练模型结果推理延迟、成本全都顶不住业务方根本不买账。反而用TF-IDF先打底、模块化设计、留好升级接口的方案最后运维得最稳定。文本相似度算法这个方向核心并不是算法本身的复杂程度而是你有多了解你的数据和业务目标。数据长什么样、哪些字段需要归一化、哪些词在业务上下文里是等价的、阈值定在什么范围能让业务方满意——这些问题的答案才最终决定了一个相似度系统做得好不好。