简介text2vec-base-chinese 是 shibing624 推出的中文句向量预训练模型面向语义相似度计算、文本检索、问答匹配与句子聚类等 NLP 场景适合算法工程师、学术研究者和 NLP 初学者。资源将完整模型文件打包在一起省去从模型社区逐项下载权重、配置文件并拼装的环节便于用 transformers 或 sentence-transformers 等常见工具直接加载使用。压缩包共 198 个文件涵盖大量 json 配置与 lock 校验文件、txt 词表及说明文档、bin 格式的 PyTorch 权重以及 onnx 格式的部署文件整体体积约 732.69MB部分哈希文件是 Git LFS 指针不影响实际训练、推理与部署。已有 1387 人学习下载适合需要快速搭建中文向量表示能力的项目。同时支持本地推理、后续微调和跨平台部署使用者可依据需求选用 bin 或 onnx 权重并借助说明文档理解目录结构、核验文件完整性降低文本向量化的落地门槛。1. 中文句向量模型把“你好”和“您好”算成相似的那块拼图做语义搜索、文本去重、客服知识库匹配时最头疼的不是分词而是近义表达。关键词匹配把“我要退款”和“订单怎么取消”当两句话换成 embedding 之后它们应该在向量空间里离得很近。这份 model 文件就是干这个的——text2vec-base-chinese 中文句向量模型。它基于预训练语言模型微调而来输入一句中文输出一个定长向量用余弦相似度就能衡量语义距离。适合刚入门 NLP 的开发者也适合给现有系统补语义能力的后端工程师。base 版本在效果和资源消耗之间取了一个比较舒服的点CPU 也能跑。2. 模型文件构成与选用为什么我坚持用 base 而不是一口吃下 large2.1 解压后看到的文件清单与各自作用下载这份模型文件后解压目录里一般是六个文件这是标准的 HuggingFace 结构。别小看这些文件缺一个都跑不起来。文件作用容易忽略的点config.json记录模型结构参数层数、注意力头数、hidden_size 等加载时若配置与权重不匹配直接报错pytorch_model.bin模型权重文件最大的那个完整性校验靠它损坏则模型加载一半就崩vocab.txt词表决定 token 怎么切分不能随便换必须与预训练一致tokenizer_config.jsontokenizer 行为配置如最大长度、特殊 token和 vocab.txt 配套改了会乱special_tokens_map.json特殊 token 映射 、 等缺少时默认值可能不对sentence_bert_config.json句向量池化配置不是所有模型都有有的话优先用它项目正文里没写这些但实际加载时都要用到。我一般会先打开 config.json 看 hidden_size确认它是 768 还是 1024再决定下游适配层怎么写。这个动作花不了十秒钟但能避免后面维度对不上时的翻车。2.2 base 与 large 的取舍算力、时延与效果的真实对照用句向量模型时大家都会纠结到底是 base 还是 large。我两种都跑过直接说结论中文语义相似度任务上large 在硬测试集上确实高一点但没到“质的飞跃”的程度可参数量翻了几倍推理时间也跟着涨一倍以上。如果业务是内部知识库检索、客服问句去重baseline 往往够用。拿我自己跑过的某图像处理 Demo 来说需要给图片自动打标签用 base 编码一段 50 字的中文描述CPU 单条大约 20 毫秒换 large 直接变成 45 毫秒而准确率提升不到百分之一。这就是典型的性价比悬崖。所以选型逻辑应该是先看现有硬件再看业务对时延的容忍度最后才看排行分数。如果你是做智能客服这种高并发场景base 加上批量推理比 single 线程跑 large 划算得多。如果你是离线的聚类任务不在乎多等几秒large 也可以。另外提醒一点模型文件自己的 README 里通常会区分“无监督”和“有监督”版本。text2vec 系列里的 base-chinese 有专门用 CoSENT 方法训练过的权重比直接拿 BERT 的 cls 或者 mean pooling 靠谱很多。这也是为什么我宁可直接用这份模型文件也不自己去现成模型后面加池化层——后者是一个大坑后面避坑章会细说。3. 加载与推理from_pretrained 之后的三行代码3.1 安装依赖时最容易踩的版本雷文本向量化在 2024 年之后生态趋于稳定。我习惯用 sentence-transformers 加载它封装了编码和池化逻辑。先建一个干净的虚拟环境避免和项目里其他库冲突。python -m venv text2vec_env source text2vec_env/bin/activate pip install torch --index-url https://download.pytorch.org/whl/cpu pip install sentence-transformers3.0.1这里的 torch 我特意装 CPU 版因为很多场景下推理瓶颈不在 GPU而在于数据清洗和调用频率。如果机器有 CUDA可以把第一句换回官方默认源但注意 torch 和 CUDA 驱动版本要匹配。sentence-transformers 版本我锁到 3.x因为 4.x 之后某些接口行为有变化老代码容易踩坑。装完验证一下 import 是否正常python -c from sentence_transformers import SentenceTransformer; print(ok)如果报错缺少 sentencepiece直接补一下pip install sentencepiece3.2 正式加载模型并计算相似度模型文件放在本地目录比如./text2vec-base-chinese。加载的时候直接指向这个目录它会自动识别 config.json 和 pytorch_model.bin。如果第一次跑时联网它会去拉 tokenizer 相关文件之后全部走本地。from sentence_transformers import SentenceTransformer import numpy as np model SentenceTransformer(./text2vec-base-chinese) sentences [ 我想办理退款, 订单怎么取消, 今天天气真不错 ] embeddings model.encode(sentences, normalize_embeddingsTrue) sim_ab float(np.dot(embeddings[0], embeddings[1])) sim_ac float(np.dot(embeddings[0], embeddings[2])) print(f退款 vs 取消: {sim_ab:.4f}) print(f退款 vs 天气: {sim_ac:.4f})逻辑很简单model.encode 把每句话编码成一个向量normalize_embeddingsTrue 让向量长度缩放到 1这样点积就等价于余弦相似度。第一条和第二条语义相近相似度应该明显高于第三条。这就是句向量的核心用法。3.3 参数细节max_length、batch_size 与 deviceencode 方法里还有几个需要关注的参数写错了结果会很诡异。max_length控制输入 token 截断长度。默认是 128但如果你处理长文本比如客服对话记录建议设成 256 或 512。注意这个值不是越大越好超过模型训练时的长度位置编码会失效效果反而下降。text2vec-base-chinese 在预训练时一般用 128 或 512看你场景。短文本任务 64 就够长文本再往上提。batch_size在单条推理时无所谓但在批量场景下能显著提速。模型内部会 pad 到同一长度batch 越大GPU 利用率越高。但 CPU 上 batch 太大会卡死我一般 32 起步看内存压力再调。device参数可以直接指定cuda:0。如果机器有 GPU但你不小心让模型跑在 CPU 上速度会慢十倍以上。加载后可以先打印 model.device 确认。还有一个很容易被忽略的点encode 之后拿到的向量默认是 numpy 数组还是 torch tensor取决于convert_to_numpy参数。我习惯设成 True方便后续存数据库或算近邻。4. 常见问题避坑这些边界问题值得记到自己的笔记里4.1 现象加载权重时报“size mismatch”错误原因config.json 里层的数量和 pytorch_model.bin 里实际保存的权重数量不一致。常见场景是你把 base 版本的 config 换到了 large 版本的权重上或者反过来。解决检查 config.json 里的num_hidden_layers、hidden_size和intermediate_size再核对模型目录里文件的大小。base 版本权重文件一般几百 MBlarge 超过 1 GB。还有一种情况是原本只下载了模型文件的一部分比如某个分片没拉全重新下载完整的 bin 文件。4.2 现象余弦相似度算出来总是负数或者接近 0原因没有做 normalize_embeddings或者直接用了模型输出的原始 hidden state 而没有经过池化层。如果用 SentenceTransformer 加载上述代码是不会出这个问题的但如果你绕过去用 transformers 库 load 原始模型再自己取 last_hidden_state就会踩到。原始 BERT 每个 token 的位置向量差异很大mean pooling 才能得到句向量。解决统一走 SentenceTransformer 的 encode或者自己写池化时用 mean pooling同时加上 normalize_embeddingsTrue。我之前在某跨平台系统的文本审核模块里就是因为少了一行归一化导致相似度阈值怎么调都不对后来加上才正常。4.3 现象encode 速度慢CPU 风扇狂转原因没有设置 batch_size导致模型均匀地把每条文本当独立 batch 处理无法利用向量化的矩阵计算。另一个原因是 max_length 设得过大比如文本就几十个字你设成 512等于把每个 batch 都 pad 成满长度。解决批量编码时把 batch_size 提到 64 或 128max_length 根据实际文本分位数来设。先看语料长度的 p95也就是百分之九十五的样本不超过多长然后定在那个附近不要盲目往上加。4.4 现象模型加载成功但第一次 encode 特别慢后续恢复正常原因这是正常的预热现象。模型第一次做前向计算时要初始化缓存机制包括 PyTorch 的 cuDNN 等。如果是 CPU 上第一次还涉及内存页分配。不算 bug但如果你写的是定时任务每次跑完进程就退出那么每次都要承担预热开销。解决常驻一个进程或者用 warmup 脚本在服务启动时先编码一条空文本把模型预热。常见做法是在初始化时调用一次model.encode(预热)这样后续的真实请求就不会卡在第一次。4.5 现象文本里包含 emoji编码后相似度出现异常原因tokenizer 对 emoji 的处理和普通汉字不一样它可能被拆成多个 token或者直接映射到 。比如“你好”和“你好”可能会因为 emoji 的存在向量差异被拉大。解决在编码前做简单的正则清洗把非中英文字符、数字、常用标点之外的东西过滤掉。如果业务必须保留 emoji那就得保证训练和推理时都经过相同的清洗流程否则线上结果会很玄学。5. 把模型接到业务里批量计算与缓存优化5.1 批量编码的正确姿势与性能实测实际业务中不会一条一条文本调 encode而是成百上千条一起处理。用 sentence-transformers 的 encode 接口传入 list 即可自动分批。import time lines [f这是第{i}条待编码文本 for i in range(10000)] start time.time() emb model.encode(lines, batch_size64, max_length128, normalize_embeddingsTrue) cost time.time() - start print(f编码 {len(lines)} 条耗时 {cost:.2f} 秒平均 {cost/len(lines)*1000:.1f} ms/条)在 CPU 上单线程跑 10 条可能需要 200 毫秒但打包成 batch 后平均每条能压到 20 毫秒左右。核心原因是矩阵运算的并行度提高了。如果你有 GPUbatch_size 可以放到 256吞吐能再翻几倍。这里有个值得注意的细节encode 里的batch_size只决定一次跑多少条但它内部可能还会继续拆分。如果文档说支持 512但你显存不够会自动缩小。表现就是速度达不到预期但不会崩溃。5.2 结果缓存避免重复计算给相似度加一层后悔药在线上服务里用户输入的问题和家长已经存过的问题很多是重复的。如果每次请求都重新编码一遍性价比极低。常见做法是用向量数据库或者简单的 dict pickle 做缓存。import pickle from pathlib import Path cache_path Path(./emb_cache.pkl) if cache_path.exists(): with open(cache_path, rb) as f: cache pickle.load(f) else: cache {} def encode_with_cache(text: str): if text in cache: return cache[text] vec model.encode([text], normalize_embeddingsTrue)[0] cache[text] vec with open(cache_path, wb) as f: pickle.dump(cache, f) return vec缓存键直接用原始文本简单直接。但要注意如果文本里有细微空格、换行或者全半角差异会被当成不同 key。所以缓存之前先做文本归一化比如把全角转半角、去掉首尾空白。这样命中率才能上去。pkl 文件虽然简单但并发写会有问题。如果服务是多进程部署建议用 Redis。缓存 key 可以设定文本的哈希value 是 float 列表。Redis 里存 numpy 数组会吃大亏要么转 list要么用 bytes 序列化后再存。建议直接 list因为几百维 float 也就几 KB。5.3 与向量库结合百万级检索也没问题当数据量超过十万条暴力计算余弦相似度就开始吃力了。常见方案是接一个开源向量检索服务比如 faiss。把每条文本的向量全部写入索引搜索时用同一条文本的向量去查 topK。import faiss import numpy as np dim embeddings.shape[1] index faiss.IndexFlatIP(dim) index.add(embeddings.astype(np.float32)) def search(query, k5): qvec model.encode([query], normalize_embeddingsTrue)[0].astype(np.float32) scores, ids index.search(qvec.reshape(1, -1), k) return ids[0], scores[0]IndexFlatIP 就是内积索引配合 normalize_embeddingsTrue 等价于余弦相似度。千万注意数据类型faiss 只接受 float32你用 float64 会直接报错。这是最常见的坑。对于百万级别IndexFlatIP 速度还行但如果想要更好的召回效率可以用 IVF 索引但训练阶段会多一个聚类参数。我更推荐先用 Flat 版本测通流程再优化索引否则一开始就调 IVF很容易因为 nlist 参数不对导致召回率下降。6. 进一步优化无监督语义搜索提升召回的小技巧用了 text2vec 之后并不是直接把相似度阈值定在 0.7 就完事。文本清洗对向量质量影响很大。我在某个客服项目里发现去掉停用词无助于提升相似度反而导致“我不要退款”被编码成“不退款”语义翻转。正确做法是不做激进的停用词过滤最多统一全半角、小写化数字、去掉连续空白。阈值设定也需要靠数据来说话。拿一批历史标注数据画出相似度分布看正负样本的重合区。一般中文句子同一意思的改写相似度在 0.8 以上完全不相关的大概 0.5 以下。但临界区很多比如“我要的是蓝色”和“蓝的给我”语义相近却可能只有 0.6。这时候与其调阈值不如用多个候选召回再重排。我还有一个小习惯把用户输入问题扩展成三个变体分别编码后取平均值再做检索相当于做了一次查询融合。比如原始问题“手机丢了怎么找”扩展成“手机丢失查找方法”“怎么定位手机”三个向量平均之后检索结果的稳定性明显更好。这个技巧不需要重新训练模型只在查询端多花一点时间。从那以后我每次接入新的文本匹配需求都会先跑一遍全量数据的相似度分布再决定阈值和清洗方式而不是直接把默认的 0.7 拿过来用。这个习惯帮我躲过了很多次线上召回质量问题希望帮到你。本文还有配套的精品资源点击获取 
长河君 · 2026/10/13 18:26:31 · 阅读 1.2k text2vec-base-chinese中文句向量模型：加载、推理与工程实践避坑指南
简介text2vec-base-chinese 是 shibing624 推出的中文句向量预训练模型面向语义相似度计算、文本检索、问答匹配与句子聚类等 NLP 场景适合算法工程师、学术研究者和 NLP 初学者。资源将完整模型文件打包在一起省去从模型社区逐项下载权重、配置文件并拼装的环节便于用 transformers 或 sentence-transformers 等常见工具直接加载使用。压缩包共 198 个文件涵盖大量 json 配置与 lock 校验文件、txt 词表及说明文档、bin 格式的 PyTorch 权重以及 onnx 格式的部署文件整体体积约 732.69MB部分哈希文件是 Git LFS 指针不影响实际训练、推理与部署。已有 1387 人学习下载适合需要快速搭建中文向量表示能力的项目。同时支持本地推理、后续微调和跨平台部署使用者可依据需求选用 bin 或 onnx 权重并借助说明文档理解目录结构、核验文件完整性降低文本向量化的落地门槛。1. 中文句向量模型把“你好”和“您好”算成相似的那块拼图做语义搜索、文本去重、客服知识库匹配时最头疼的不是分词而是近义表达。关键词匹配把“我要退款”和“订单怎么取消”当两句话换成 embedding 之后它们应该在向量空间里离得很近。这份 model 文件就是干这个的——text2vec-base-chinese 中文句向量模型。它基于预训练语言模型微调而来输入一句中文输出一个定长向量用余弦相似度就能衡量语义距离。适合刚入门 NLP 的开发者也适合给现有系统补语义能力的后端工程师。base 版本在效果和资源消耗之间取了一个比较舒服的点CPU 也能跑。2. 模型文件构成与选用为什么我坚持用 base 而不是一口吃下 large2.1 解压后看到的文件清单与各自作用下载这份模型文件后解压目录里一般是六个文件这是标准的 HuggingFace 结构。别小看这些文件缺一个都跑不起来。文件作用容易忽略的点config.json记录模型结构参数层数、注意力头数、hidden_size 等加载时若配置与权重不匹配直接报错pytorch_model.bin模型权重文件最大的那个完整性校验靠它损坏则模型加载一半就崩vocab.txt词表决定 token 怎么切分不能随便换必须与预训练一致tokenizer_config.jsontokenizer 行为配置如最大长度、特殊 token和 vocab.txt 配套改了会乱special_tokens_map.json特殊 token 映射 、 等缺少时默认值可能不对sentence_bert_config.json句向量池化配置不是所有模型都有有的话优先用它项目正文里没写这些但实际加载时都要用到。我一般会先打开 config.json 看 hidden_size确认它是 768 还是 1024再决定下游适配层怎么写。这个动作花不了十秒钟但能避免后面维度对不上时的翻车。2.2 base 与 large 的取舍算力、时延与效果的真实对照用句向量模型时大家都会纠结到底是 base 还是 large。我两种都跑过直接说结论中文语义相似度任务上large 在硬测试集上确实高一点但没到“质的飞跃”的程度可参数量翻了几倍推理时间也跟着涨一倍以上。如果业务是内部知识库检索、客服问句去重baseline 往往够用。拿我自己跑过的某图像处理 Demo 来说需要给图片自动打标签用 base 编码一段 50 字的中文描述CPU 单条大约 20 毫秒换 large 直接变成 45 毫秒而准确率提升不到百分之一。这就是典型的性价比悬崖。所以选型逻辑应该是先看现有硬件再看业务对时延的容忍度最后才看排行分数。如果你是做智能客服这种高并发场景base 加上批量推理比 single 线程跑 large 划算得多。如果你是离线的聚类任务不在乎多等几秒large 也可以。另外提醒一点模型文件自己的 README 里通常会区分“无监督”和“有监督”版本。text2vec 系列里的 base-chinese 有专门用 CoSENT 方法训练过的权重比直接拿 BERT 的 cls 或者 mean pooling 靠谱很多。这也是为什么我宁可直接用这份模型文件也不自己去现成模型后面加池化层——后者是一个大坑后面避坑章会细说。3. 加载与推理from_pretrained 之后的三行代码3.1 安装依赖时最容易踩的版本雷文本向量化在 2024 年之后生态趋于稳定。我习惯用 sentence-transformers 加载它封装了编码和池化逻辑。先建一个干净的虚拟环境避免和项目里其他库冲突。python -m venv text2vec_env source text2vec_env/bin/activate pip install torch --index-url https://download.pytorch.org/whl/cpu pip install sentence-transformers3.0.1这里的 torch 我特意装 CPU 版因为很多场景下推理瓶颈不在 GPU而在于数据清洗和调用频率。如果机器有 CUDA可以把第一句换回官方默认源但注意 torch 和 CUDA 驱动版本要匹配。sentence-transformers 版本我锁到 3.x因为 4.x 之后某些接口行为有变化老代码容易踩坑。装完验证一下 import 是否正常python -c from sentence_transformers import SentenceTransformer; print(ok)如果报错缺少 sentencepiece直接补一下pip install sentencepiece3.2 正式加载模型并计算相似度模型文件放在本地目录比如./text2vec-base-chinese。加载的时候直接指向这个目录它会自动识别 config.json 和 pytorch_model.bin。如果第一次跑时联网它会去拉 tokenizer 相关文件之后全部走本地。from sentence_transformers import SentenceTransformer import numpy as np model SentenceTransformer(./text2vec-base-chinese) sentences [ 我想办理退款, 订单怎么取消, 今天天气真不错 ] embeddings model.encode(sentences, normalize_embeddingsTrue) sim_ab float(np.dot(embeddings[0], embeddings[1])) sim_ac float(np.dot(embeddings[0], embeddings[2])) print(f退款 vs 取消: {sim_ab:.4f}) print(f退款 vs 天气: {sim_ac:.4f})逻辑很简单model.encode 把每句话编码成一个向量normalize_embeddingsTrue 让向量长度缩放到 1这样点积就等价于余弦相似度。第一条和第二条语义相近相似度应该明显高于第三条。这就是句向量的核心用法。3.3 参数细节max_length、batch_size 与 deviceencode 方法里还有几个需要关注的参数写错了结果会很诡异。max_length控制输入 token 截断长度。默认是 128但如果你处理长文本比如客服对话记录建议设成 256 或 512。注意这个值不是越大越好超过模型训练时的长度位置编码会失效效果反而下降。text2vec-base-chinese 在预训练时一般用 128 或 512看你场景。短文本任务 64 就够长文本再往上提。batch_size在单条推理时无所谓但在批量场景下能显著提速。模型内部会 pad 到同一长度batch 越大GPU 利用率越高。但 CPU 上 batch 太大会卡死我一般 32 起步看内存压力再调。device参数可以直接指定cuda:0。如果机器有 GPU但你不小心让模型跑在 CPU 上速度会慢十倍以上。加载后可以先打印 model.device 确认。还有一个很容易被忽略的点encode 之后拿到的向量默认是 numpy 数组还是 torch tensor取决于convert_to_numpy参数。我习惯设成 True方便后续存数据库或算近邻。4. 常见问题避坑这些边界问题值得记到自己的笔记里4.1 现象加载权重时报“size mismatch”错误原因config.json 里层的数量和 pytorch_model.bin 里实际保存的权重数量不一致。常见场景是你把 base 版本的 config 换到了 large 版本的权重上或者反过来。解决检查 config.json 里的num_hidden_layers、hidden_size和intermediate_size再核对模型目录里文件的大小。base 版本权重文件一般几百 MBlarge 超过 1 GB。还有一种情况是原本只下载了模型文件的一部分比如某个分片没拉全重新下载完整的 bin 文件。4.2 现象余弦相似度算出来总是负数或者接近 0原因没有做 normalize_embeddings或者直接用了模型输出的原始 hidden state 而没有经过池化层。如果用 SentenceTransformer 加载上述代码是不会出这个问题的但如果你绕过去用 transformers 库 load 原始模型再自己取 last_hidden_state就会踩到。原始 BERT 每个 token 的位置向量差异很大mean pooling 才能得到句向量。解决统一走 SentenceTransformer 的 encode或者自己写池化时用 mean pooling同时加上 normalize_embeddingsTrue。我之前在某跨平台系统的文本审核模块里就是因为少了一行归一化导致相似度阈值怎么调都不对后来加上才正常。4.3 现象encode 速度慢CPU 风扇狂转原因没有设置 batch_size导致模型均匀地把每条文本当独立 batch 处理无法利用向量化的矩阵计算。另一个原因是 max_length 设得过大比如文本就几十个字你设成 512等于把每个 batch 都 pad 成满长度。解决批量编码时把 batch_size 提到 64 或 128max_length 根据实际文本分位数来设。先看语料长度的 p95也就是百分之九十五的样本不超过多长然后定在那个附近不要盲目往上加。4.4 现象模型加载成功但第一次 encode 特别慢后续恢复正常原因这是正常的预热现象。模型第一次做前向计算时要初始化缓存机制包括 PyTorch 的 cuDNN 等。如果是 CPU 上第一次还涉及内存页分配。不算 bug但如果你写的是定时任务每次跑完进程就退出那么每次都要承担预热开销。解决常驻一个进程或者用 warmup 脚本在服务启动时先编码一条空文本把模型预热。常见做法是在初始化时调用一次model.encode(预热)这样后续的真实请求就不会卡在第一次。4.5 现象文本里包含 emoji编码后相似度出现异常原因tokenizer 对 emoji 的处理和普通汉字不一样它可能被拆成多个 token或者直接映射到 。比如“你好”和“你好”可能会因为 emoji 的存在向量差异被拉大。解决在编码前做简单的正则清洗把非中英文字符、数字、常用标点之外的东西过滤掉。如果业务必须保留 emoji那就得保证训练和推理时都经过相同的清洗流程否则线上结果会很玄学。5. 把模型接到业务里批量计算与缓存优化5.1 批量编码的正确姿势与性能实测实际业务中不会一条一条文本调 encode而是成百上千条一起处理。用 sentence-transformers 的 encode 接口传入 list 即可自动分批。import time lines [f这是第{i}条待编码文本 for i in range(10000)] start time.time() emb model.encode(lines, batch_size64, max_length128, normalize_embeddingsTrue) cost time.time() - start print(f编码 {len(lines)} 条耗时 {cost:.2f} 秒平均 {cost/len(lines)*1000:.1f} ms/条)在 CPU 上单线程跑 10 条可能需要 200 毫秒但打包成 batch 后平均每条能压到 20 毫秒左右。核心原因是矩阵运算的并行度提高了。如果你有 GPUbatch_size 可以放到 256吞吐能再翻几倍。这里有个值得注意的细节encode 里的batch_size只决定一次跑多少条但它内部可能还会继续拆分。如果文档说支持 512但你显存不够会自动缩小。表现就是速度达不到预期但不会崩溃。5.2 结果缓存避免重复计算给相似度加一层后悔药在线上服务里用户输入的问题和家长已经存过的问题很多是重复的。如果每次请求都重新编码一遍性价比极低。常见做法是用向量数据库或者简单的 dict pickle 做缓存。import pickle from pathlib import Path cache_path Path(./emb_cache.pkl) if cache_path.exists(): with open(cache_path, rb) as f: cache pickle.load(f) else: cache {} def encode_with_cache(text: str): if text in cache: return cache[text] vec model.encode([text], normalize_embeddingsTrue)[0] cache[text] vec with open(cache_path, wb) as f: pickle.dump(cache, f) return vec缓存键直接用原始文本简单直接。但要注意如果文本里有细微空格、换行或者全半角差异会被当成不同 key。所以缓存之前先做文本归一化比如把全角转半角、去掉首尾空白。这样命中率才能上去。pkl 文件虽然简单但并发写会有问题。如果服务是多进程部署建议用 Redis。缓存 key 可以设定文本的哈希value 是 float 列表。Redis 里存 numpy 数组会吃大亏要么转 list要么用 bytes 序列化后再存。建议直接 list因为几百维 float 也就几 KB。5.3 与向量库结合百万级检索也没问题当数据量超过十万条暴力计算余弦相似度就开始吃力了。常见方案是接一个开源向量检索服务比如 faiss。把每条文本的向量全部写入索引搜索时用同一条文本的向量去查 topK。import faiss import numpy as np dim embeddings.shape[1] index faiss.IndexFlatIP(dim) index.add(embeddings.astype(np.float32)) def search(query, k5): qvec model.encode([query], normalize_embeddingsTrue)[0].astype(np.float32) scores, ids index.search(qvec.reshape(1, -1), k) return ids[0], scores[0]IndexFlatIP 就是内积索引配合 normalize_embeddingsTrue 等价于余弦相似度。千万注意数据类型faiss 只接受 float32你用 float64 会直接报错。这是最常见的坑。对于百万级别IndexFlatIP 速度还行但如果想要更好的召回效率可以用 IVF 索引但训练阶段会多一个聚类参数。我更推荐先用 Flat 版本测通流程再优化索引否则一开始就调 IVF很容易因为 nlist 参数不对导致召回率下降。6. 进一步优化无监督语义搜索提升召回的小技巧用了 text2vec 之后并不是直接把相似度阈值定在 0.7 就完事。文本清洗对向量质量影响很大。我在某个客服项目里发现去掉停用词无助于提升相似度反而导致“我不要退款”被编码成“不退款”语义翻转。正确做法是不做激进的停用词过滤最多统一全半角、小写化数字、去掉连续空白。阈值设定也需要靠数据来说话。拿一批历史标注数据画出相似度分布看正负样本的重合区。一般中文句子同一意思的改写相似度在 0.8 以上完全不相关的大概 0.5 以下。但临界区很多比如“我要的是蓝色”和“蓝的给我”语义相近却可能只有 0.6。这时候与其调阈值不如用多个候选召回再重排。我还有一个小习惯把用户输入问题扩展成三个变体分别编码后取平均值再做检索相当于做了一次查询融合。比如原始问题“手机丢了怎么找”扩展成“手机丢失查找方法”“怎么定位手机”三个向量平均之后检索结果的稳定性明显更好。这个技巧不需要重新训练模型只在查询端多花一点时间。从那以后我每次接入新的文本匹配需求都会先跑一遍全量数据的相似度分布再决定阈值和清洗方式而不是直接把默认的 0.7 拿过来用。这个习惯帮我躲过了很多次线上召回质量问题希望帮到你。本文还有配套的精品资源点击获取