1. 从零理解句子相似度到底在算什么很多人第一次接触句子相似度任务时脑子里浮现的画面是给两句话模型吐出一个0到1之间的分数分数越高越相似。这个理解没错但如果你只停在这一层后面写代码时一定会踩坑——因为“相似”这个词本身就有歧义。两句话可以字面重叠度很高但意思相反也可以用词完全不同但语义等价。你到底想让模型学哪一种相似直接决定了数据构造、模型选型和损失函数的设计。我在实际项目里见过太多人一上来就调SentenceTransformer的预训练模型跑出来发现效果不达预期然后开始怀疑模型不行。其实问题往往出在他根本没想清楚自己的业务场景需要的是语义相似还是字面相似。比如做FAQ匹配用户问“怎么退款”和知识库里“如何申请退货”这是语义相似而做论文查重你关心的是字面重合度语义模型反而不合适。从技术路线上看句子相似度大致经历了三个阶段。最早是基于统计的方法比如TF-IDF加余弦相似度或者编辑距离、Jaccard系数这类字符串层面的度量。这类方法快、可解释性强但完全抓不住语义。第二阶段是词向量时代把句子里的词向量做平均或者加权平均比统计方法好一些但丢失了词序信息“狗咬人”和“人咬狗”会算出一样的结果。第三阶段就是现在主流的基于预训练语言模型的方法通过BERT、RoBERTa这类模型拿到上下文相关的句子表示再配合对比学习或者交互式编码来计算相似度。这里有个关键分水岭你需要知道双塔架构Bi-Encoder和交互式架构Cross-Encoder。双塔是两句话分别过同一个编码器各自得到一个向量然后算余弦相似度。优点是快句子向量可以预先算好存起来线上检索时只做向量召回。缺点是两句话在编码阶段没有任何交互精度上限受限。交互式架构是把两句话拼在一起送进模型让注意力机制在两层之间充分交互精度高但慢因为每来一个新句子都要和库里所有句子重新组合推理。实际工程中常见的做法是用双塔做粗筛召回Top-K再用交互式模型做精排。这个思路和推荐系统里的召回-排序两阶段是完全一致的。提示如果你只是做离线的小规模相似度计算比如几百条数据直接用Cross-Encoder就行别折腾双塔。双塔的价值在于大规模检索场景几百万条候选句子的情况下你不可能每来一个query就和全库做交互式计算。再往下拆句子相似度的核心难点其实有三个。第一是各向异性问题BERT输出的句子向量往往集中在一个狭窄的锥形区域里导致所有句子的余弦相似度都偏高区分度不够。这个问题在Sentence-BERT的论文里有详细讨论解决方案包括白化处理、对比学习训练等。第二是长度差异一个短句和一个长句的语义相似度怎么算短句可能是长句的子话题也可能完全不相关。第三是领域迁移通用预训练模型在特定领域比如医疗、法律、金融上表现会明显下降因为专业术语的语义空间和通用语料差异很大。理解了这些你才能在做项目时做出正确的技术决策而不是盲目跟风用最新最火的模型。2. 环境搭建与基础依赖的版本陷阱动手写代码之前环境配置这一步看似简单实际上坑最多。PyTorch生态里版本兼容性问题非常突出尤其是涉及到transformers、sentence-transformers、torch三者之间的版本匹配。我踩过最典型的一次坑是sentence-transformers2.x版本要求transformers4.6.0但某个特定版本的transformers又和torch1.8有冲突导致加载预训练模型时直接报RuntimeError。先给出我实测下来比较稳的一套版本组合截至我写这篇内容时仍然可用pip install torch2.0.1 torchvision0.15.2 --index-url https://download.pytorch.org/whl/cu118 pip install transformers4.35.0 pip install sentence-transformers2.2.2 pip install scikit-learn1.3.2 pip install numpy1.24.3为什么锁定这些版本torch2.0.1是一个长期支持版本CUDA 11.8的兼容性最好大多数显卡驱动都能直接跑。transformers4.35.0对BERT系列模型的支持非常稳定而且API没有大的破坏性变更。sentence-transformers2.2.2是我用过最稳的一个版本它内部对池化策略和相似度计算做了很好的封装同时不会强制升级transformers到不兼容的版本。如果你用的是GPU装完之后一定要验证CUDA是否可用import torch print(torch.cuda.is_available()) print(torch.cuda.get_device_name(0)) print(torch.version.cuda)这三个输出分别应该是True、你的显卡型号、11.8。如果第一个是False大概率是你装了CPU版本的torch需要卸载重装。很多人在这里浪费时间以为是代码问题其实是环境问题。还有一个容易忽略的点是tokenizer的缓存路径。默认情况下transformers会把预训练模型下载到~/.cache/huggingface/目录下。如果你在服务器上跑home目录空间有限很容易被撑爆。建议在代码开头就设置环境变量import os os.environ[HF_HOME] /your/large/disk/hf_cache os.environ[TRANSFORMERS_CACHE] /your/large/disk/hf_cache这个设置必须在import transformers之前执行否则不生效。我见过有人把它写在import之后然后纳闷为什么缓存还是往home目录写。另外如果你在国内网络环境下下载模型比较慢可以使用镜像源。但注意镜像源的模型版本可能不是最新的下载前先确认一下你要的模型在镜像上有没有。具体配置方式是在环境变量里设置HF_ENDPOINT这里不展开网上教程很多。注意不要混用conda和pip安装PyTorch相关包。conda装的torch和pip装的transformers经常会出现动态库链接错误表现为ImportError: libcudart.so.11.0: cannot open shared object file。统一用pip管理或者统一用conda别混着来。环境搞定之后先跑一个最小的验证脚本确认整个链路是通的from sentence_transformers import SentenceTransformer model SentenceTransformer(paraphrase-multilingual-MiniLM-L12-v2) sentences [今天天气真好, 今天的天气非常不错] embeddings model.encode(sentences) from sklearn.metrics.pairwise import cosine_similarity print(cosine_similarity([embeddings[0]], [embeddings[1]]))如果输出一个0.8以上的相似度分数说明环境没问题。这个模型是轻量级多语言模型下载快、推理快适合做验证。正式项目再换更大的模型。3. 模型选型不同预训练模型的实际表现差异模型选型是句子相似度项目里最关键的决策之一。市面上的预训练模型五花八门从BERT-base到各种蒸馏版本、多语言版本、领域特化版本到底选哪个我的经验是没有最好的模型只有最适合你场景的模型。下面这张表是我在实际项目中对比过的几个常用模型测试数据是中文语义相似度任务约5000对标注数据硬件环境是单卡RTX 3090。模型名称参数量向量维度推理速度句/秒语义相似度Spearman适用场景paraphrase-multilingual-MiniLM-L12-v2118M384约28000.78快速验证、多语言、资源受限text2vec-base-chinese102M768约12000.82中文通用场景BAAI/bge-base-zh-v1.5102M768约11000.86中文检索、语义匹配BAAI/bge-large-zh-v1.5326M1024约3500.89高精度要求、离线计算shibing624/text2vec-base-chinese-sentence102M768约12000.83中文句子对任务这张表里的Spearman相关系数是在我自己的测试集上跑的不同数据集上排名可能有变化但整体趋势是一致的大模型确实比小模型好但提升幅度和资源消耗不成正比。bge-large比bge-base的Spearman只高了0.03但推理速度慢了3倍多显存占用多了2倍。如果你的场景是线上实时服务bge-base通常是性价比最高的选择。这里重点说一下BGE系列模型。BGE是智源研究院开源的模型在中文语义相似度任务上表现非常突出。它的训练方式有一个特点在对比学习中使用了大规模弱监督数据所以泛化能力很强。但使用时有一个细节需要注意——BGE模型在计算相似度时建议在query前面加一个指令前缀比如“为这个句子生成表示以用于检索相关文章”。这个前缀不是可有可无的实测下来加了前缀之后检索准确率能提升2-3个百分点。很多人不知道这个细节直接拿原始句子编码效果打了折扣。from sentence_transformers import SentenceTransformer model SentenceTransformer(BAAI/bge-base-zh-v1.5) query 为这个句子生成表示以用于检索相关文章什么是机器学习 passage 机器学习是人工智能的一个分支研究如何让计算机从数据中学习规律 query_emb model.encode(query) passage_emb model.encode(passage)对于英文场景all-MiniLM-L6-v2和all-mpnet-base-v2是两个经典选择。前者快后者准。如果你的场景是中英混合paraphrase-multilingual-MiniLM-L12-v2是入门首选但它的中文能力确实不如专门的中文模型。还有一个选型维度是是否支持长文本。标准BERT的最大输入长度是512个token超过会被截断。如果你的句子经常超过这个长度比如段落级相似度需要考虑Longformer或者对句子做分段处理后聚合。实际项目中我建议先统计一下你的数据里句子长度的分布如果95%的句子都在128个token以内那512的限制根本不是问题。提示不要盲目追求大模型。我做过一个实验在FAQ匹配场景下bge-base和bge-large的Top-1准确率只差了1.2%但bge-large的响应时间从15ms涨到了50ms。对于QPS要求高的服务这个差异是致命的。另外如果你有标注数据微调永远比直接用预训练模型效果好。哪怕只有几百对标注数据用对比学习微调一轮效果提升往往比换更大的模型更明显。这个后面会详细讲。4. 双塔与交互式两种计算范式的代码实现与性能对比前面提到了双塔和交互式两种架构这里展开讲具体怎么实现以及什么场景下用哪种。先看双塔的实现这是最常用的方式import torch import torch.nn as nn from transformers import AutoModel, AutoTokenizer class BiEncoder(nn.Module): def __init__(self, model_name): super().__init__() self.encoder AutoModel.from_pretrained(model_name) self.tokenizer AutoTokenizer.from_pretrained(model_name) def mean_pooling(self, model_output, attention_mask): token_embeddings model_output.last_hidden_state input_mask_expanded attention_mask.unsqueeze(-1).expand(token_embeddings.size()).float() return torch.sum(token_embeddings * input_mask_expanded, 1) / torch.clamp(input_mask_expanded.sum(1), min1e-9) def forward(self, sentences): encoded self.tokenizer(sentences, paddingTrue, truncationTrue, max_length128, return_tensorspt) encoded {k: v.to(self.encoder.device) for k, v in encoded.items()} output self.encoder(**encoded) embeddings self.mean_pooling(output, encoded[attention_mask]) return nn.functional.normalize(embeddings, p2, dim1)这段代码的核心是mean pooling。BERT输出的last_hidden_state是每个token的向量你需要把它聚合成一个句子向量。常见的池化策略有三种取[CLS]位置的向量、mean pooling、max pooling。实测下来mean pooling在句子相似度任务上最稳定[CLS]向量在未经微调的模型上往往表现较差因为预训练阶段[CLS]主要是为下一句预测任务服务的不是为相似度设计的。双塔的推理流程是先把候选库所有句子编码成向量矩阵存起来线上来一个query编码后和矩阵做矩阵乘法取Top-K。这个矩阵乘法可以用FAISS加速百万级向量也能在毫秒级返回结果。import faiss import numpy as np # 假设corpus_embeddings是N x D的numpy数组 corpus_embeddings np.array(corpus_embeddings).astype(float32) index faiss.IndexFlatIP(corpus_embeddings.shape[1]) # 内积索引因为向量已归一化 index.add(corpus_embeddings) query_embedding model.encode([query]).astype(float32) scores, indices index.search(query_embedding, top_k10)FAISS的IndexFlatIP做的是精确内积搜索因为向量已经L2归一化内积等价于余弦相似度。如果数据量超过百万可以考虑IndexIVFFlat做近似搜索牺牲一点精度换速度。再来看交互式架构class CrossEncoder(nn.Module): def __init__(self, model_name): super().__init__() self.encoder AutoModel.from_pretrained(model_name) self.classifier nn.Linear(self.encoder.config.hidden_size, 1) self.tokenizer AutoTokenizer.from_pretrained(model_name) def forward(self, sentence_pairs): encoded self.tokenizer(sentence_pairs, paddingTrue, truncationTrue, max_length256, return_tensorspt) encoded {k: v.to(self.encoder.device) for k, v in encoded.items()} output self.encoder(**encoded) cls_vector output.last_hidden_state[:, 0, :] score torch.sigmoid(self.classifier(cls_vector)) return scoreCross-Encoder把两句话用[SEP]拼在一起送进模型取[CLS]向量过一个线性层输出相似度分数。因为两句话在每一层注意力里都充分交互所以精度通常比双塔高5-10个百分点。但代价是你没法预计算每来一个query都要和所有候选句子重新组合推理。1000条候选就是1000次前向传播延迟直接爆炸。实际工程中的标准做法是两阶段双塔召回Top-100Cross-Encoder对这100个做精排。这样既保证了速度又保证了精度。我实测过一个FAQ匹配系统纯双塔的Top-1准确率是82%加上Cross-Encoder精排后提升到91%而整体延迟只增加了20ms因为只对100个候选做精排。注意Cross-Encoder训练时需要正负样本对推理时输出的是相似度分数而不是向量。不要试图用Cross-Encoder生成句子向量它的[CLS]向量没有经过对比学习训练直接拿来做余弦相似度效果很差。5. 训练数据构造与对比学习损失函数的选择如果你手头有标注数据微调是提升效果最直接的手段。但句子相似度任务的训练数据构造有很多讲究不是简单地把正负样本丢进去就完事。先说数据格式。对比学习最常用的格式是三元组anchor, positive, negativeanchor和positive是语义相似的句子对negative是和anchor不相似的句子。训练目标是让anchor和positive的向量距离尽可能近和negative的距离尽可能远。另一种格式是句子对加相似度分数比如0到5分的标注这种适合做回归任务。数据构造的第一个坑是负样本的选择。随机负样本太简单了模型很快就能学会区分梯度消失训练没效果。真正有用的是难负样本hard negative也就是和anchor字面很像但语义不同的句子。比如anchor是“苹果手机电池续航怎么样”随机负样本可能是“今天天气不错”难负样本应该是“苹果这种水果的营养价值”。后者和anchor共享“苹果”这个词但语义完全不同模型必须真正理解语义才能区分。构造难负样本的常用方法是用当前模型对候选库做检索取Top-K中不是正样本的作为难负样本。这个过程可以离线做也可以在训练过程中动态挖掘。动态挖掘效果更好但实现复杂离线挖掘简单实用。from sentence_transformers import InputExample, losses from torch.utils.data import DataLoader train_examples [] # 假设你有三元组数据 for anchor, positive, negative in triplets: train_examples.append(InputExample(texts[anchor, positive, negative])) train_dataloader DataLoader(train_examples, shuffleTrue, batch_size32) model SentenceTransformer(BAAI/bge-base-zh-v1.5) train_loss losses.TripletLoss(modelmodel, triplet_margin0.1) model.fit(train_objectives[(train_dataloader, train_loss)], epochs3, warmup_steps100)这里triplet_margin是一个关键参数。它定义了正样本对距离和负样本对距离之间的最小间隔。margin太小模型学不到区分性margin太大训练不稳定。我的经验是0.1到0.3之间比较合适具体取决于你的数据分布。可以先跑一个epoch观察loss曲线如果loss下降很慢说明margin太小如果loss震荡严重说明margin太大。除了TripletLoss还有MultipleNegativesRankingLoss这个在sentence-transformers里叫MultipleNegativesRankingLoss。它的思路很巧妙在一个batch里每对正样本的其他样本的positive都当作自己的负样本。这样batch_size32时每个anchor就有31个负样本训练效率极高。这个损失函数在BGE和Sentence-BERT的训练中都被广泛使用效果非常好。train_loss losses.MultipleNegativesRankingLoss(modelmodel)用这个损失函数时数据只需要正样本对anchor, positive不需要显式构造负样本。但batch_size要尽量大因为负样本数量等于batch_size-1。如果显存不够可以用梯度累积来模拟大batch。还有一个细节是温度系数。在对比学习里温度系数控制softmax的锐度。温度越低模型对难负样本的惩罚越大。MultipleNegativesRankingLoss默认的温度是0.05这个值在大多数场景下都工作良好。如果你发现模型对难负样本区分不够可以适当降低温度。提示微调时学习率不要设太大。预训练模型微调通常用2e-5到5e-5的学习率太大容易灾难性遗忘。warmup_steps设为总步数的10%左右比较稳。6. 相似度阈值设定与线上服务的工程细节模型训好之后下一个问题就是相似度分数多少算相似这个阈值怎么定我见过太多项目在这里翻车——离线评测F1很高上线后用户投诉不断。原因往往是阈值设错了。阈值设定不能拍脑袋必须基于你的业务场景和评测数据来定。具体做法是在验证集上画出不同阈值下的精确率和召回率曲线然后根据业务需求选择。如果是一个严格的去重场景宁可漏判不可误判那就选高阈值保证精确率如果是一个宽松的推荐场景宁可多推不可漏推那就选低阈值保证召回率。import numpy as np from sklearn.metrics import precision_recall_curve # y_true是0/1标签y_scores是模型输出的相似度分数 precision, recall, thresholds precision_recall_curve(y_true, y_scores) f1_scores 2 * precision * recall / (precision recall 1e-9) best_threshold thresholds[np.argmax(f1_scores)] print(f最佳阈值: {best_threshold}, F1: {max(f1_scores)})但F1最大的阈值不一定是你业务上最优的。比如做内容安全去重误判一条正常内容为重复的代价很高那就应该选一个精确率在99%以上的阈值哪怕召回率低一些。线上服务还有几个工程细节需要注意。第一是向量归一化。如果你用余弦相似度务必在编码后做L2归一化然后用内积计算。这样可以用FAISS的IndexFlatIP加速比手动算余弦快很多。第二是批处理。线上请求往往是单条来的但你可以做一个微批处理队列攒够一定数量或者等待超过5ms就一起编码吞吐量能提升好几倍。第三是缓存。热门query的向量可以缓存起来避免重复编码。from functools import lru_cache lru_cache(maxsize10000) def get_embedding(text): return model.encode([text])[0]这个简单的缓存能挡掉大量重复请求。但注意如果模型更新了缓存要清空。还有一个容易被忽略的问题是数值精度。FAISS默认用float32如果你的向量是float64需要显式转换否则会报类型错误。另外不同版本的FAISS对numpy版本有要求装的时候注意看文档。注意线上服务不要用model.encode()的默认参数。默认batch_size32单条请求时会浪费显存。设置batch_size1或者根据实际QPS调整。另外show_progress_bar参数在线上一定要关掉否则日志会被刷屏。7. 效果不达预期时的排查路径模型上线后效果不好怎么排查我总结了一套从外到内的排查路径按顺序走一遍基本能定位到问题。第一步检查数据质量。把模型判断错误的case拿出来看是标注错了还是模型真的判断错了。我遇到过好几次排查半天发现是标注数据里有噪声把“今天天气不错”和“今天天气很好”标成了不相似。数据清洗永远是最值得投入的环节。第二步检查文本预处理。你的句子有没有做清洗特殊字符、HTML标签、多余空格有没有处理中文分词对BERT类模型不是必须的但全角半角转换、繁简转换这些基础清洗还是要做。我见过一个case用户输入里带了不可见字符导致编码结果完全偏离。第三步检查向量质量。把句子向量拿出来算一下所有句子对的平均余弦相似度。如果平均相似度在0.9以上说明模型陷入了各向异性问题所有句子向量都挤在一起区分度不够。解决方案包括用白化处理Whitening对向量做变换或者换一个经过对比学习训练的模型。def whitening_embeddings(embeddings): mu embeddings.mean(axis0) cov np.cov(embeddings.T) U, S, V np.linalg.svd(cov) W np.dot(U, np.diag(1 / np.sqrt(S 1e-6))) return np.dot(embeddings - mu, W)白化处理能把向量空间的各向异性消除让相似度分布更合理。但注意白化矩阵是在你的语料上估计的换一个语料需要重新估计。第四步检查阈值。前面说了阈值不对是效果差的常见原因。重新在验证集上画PR曲线看看当前阈值是不是偏了。第五步检查模型是否适合你的领域。如果通用模型在你的专业领域上表现差考虑用领域数据做微调或者换一个在该领域预训练的模型。比如医疗领域有medbert法律领域有law-bert这些模型在各自领域的效果远超通用模型。第六步考虑Cross-Encoder精排。如果双塔的精度始终差一口气加一个Cross-Encoder精排通常能带来5-10个百分点的提升。这是投入产出比最高的优化手段之一。整个排查过程要养成记录的习惯。每次改动后在固定的验证集上跑一遍指标记录改动内容和指标变化。这样你才能知道哪个改动真正有效而不是凭感觉调参。8. 从单机脚本到线上服务的部署考量最后聊一下部署。很多人在本地Jupyter Notebook里跑通了一到线上就各种问题。这里有几个关键点。模型序列化与加载。sentence-transformers的模型可以用model.save()保存加载时用SentenceTransformer.load()。但注意保存的模型包含了tokenizer和pooling层的配置加载时不需要额外指定。如果你用的是自定义的PyTorch模型建议用torch.jit.trace做一次脚本化推理速度能提升20%左右。model.save(/path/to/saved_model) # 加载 from sentence_transformers import SentenceTransformer model SentenceTransformer(/path/to/saved_model)服务框架选择。简单的场景用Flask或者FastAPI就够了。FastAPI的异步特性在高并发下表现更好而且自带OpenAPI文档调试方便。如果QPS很高考虑用Triton Inference Server或者ONNX Runtime做推理加速。from fastapi import FastAPI from pydantic import BaseModel import numpy as np app FastAPI() model SentenceTransformer(/path/to/saved_model) class SimilarityRequest(BaseModel): sentence1: str sentence2: str app.post(/similarity) def compute_similarity(req: SimilarityRequest): embs model.encode([req.sentence1, req.sentence2]) score float(np.dot(embs[0], embs[1]) / (np.linalg.norm(embs[0]) * np.linalg.norm(embs[1]))) return {similarity: score}显存管理。如果多个模型共享一张显卡要注意显存分配。PyTorch默认会占满所有显存可以通过torch.cuda.set_per_process_memory_fraction(0.5)限制每个进程的显存使用比例。另外推理时用torch.no_grad()上下文管理器避免不必要的梯度计算和显存占用。监控与告警。线上服务一定要监控推理延迟和相似度分数的分布。如果延迟突然飙升可能是某个请求的文本特别长导致OOM。如果相似度分数分布突然偏移可能是数据分布变了模型需要重新训练。这些监控指标比单纯的QPS和错误率更有业务价值。提示部署时把模型加载放在服务启动阶段不要放在请求处理函数里。每次请求都加载模型会导致第一次请求超时而且浪费内存。用全局变量或者依赖注入的方式在启动时加载一次。从单机脚本到线上服务中间隔着的不是技术难度而是工程细节。把这些细节处理好你的句子相似度服务才能真正稳定运行。
