1.1 为什么向量模型对比成为语义检索与 RAG 基础设施的关键
我刚开始做 RAG 项目那会儿，觉得只要把文档切好、丢进向量数据库、接上大模型就完事了。真跑起来才发现，检索回来的内容经常答非所问。用户问“怎么申请退款”，系统却把“退款政策历史版本”排在最前面。折腾了两周，换了个文本嵌入模型，命中率直接涨了一截。那是我第一次意识到，向量模型对比不是学术圈的游戏，它直接决定 RAG 的下限。
后来跟几个做语义搜索的同行聊，大家都有类似经历。有人用开源模型省了钱，但召回率掉得厉害；有人死磕榜单第一名，上线后延迟高得没法用。向量模型对比这件事，慢慢从“选哪个”变成了“怎么选、比什么、在什么条件下比”。RAG 的基础设施里，向量模型是那个把人类语言翻译成机器可计算空间的翻译官。翻译官水平不行，后面的大模型再强也白搭。
我现在带团队做检索增强生成，第一步永远是拉一个候选向量模型列表。不是迷信对比，而是踩坑踩多了。同一个业务问题，不同模型给出的向量空间差异巨大。有的模型擅长短查询匹配长文档，有的在中文垂直领域表现突出，有的对否定词和数字极不敏感。不对比，你根本不知道自己的数据适合谁。
1.2 向量模型、文本嵌入模型与开源模型的概念边界
我刚开始写技术方案时，把“向量模型”“文本嵌入模型”“开源模型”混着用。评审会上被问了一句“你说的是多模态向量模型还是纯文本嵌入”，当场卡住。下来查了查，发现这三个词确实有交集，但边界值得说清楚。向量模型是个大口袋，图像、音频、文本都能往里装。文本嵌入模型是其中专门处理文本的那一类，输出的是文本的稠密向量表示。
开源模型又是另一个维度的事。它强调许可证开放、权重可下载、能自己部署。一个文本嵌入模型可以是开源的，也可以是闭源的 API。一个向量模型可以是开源的，但只支持图像。我见过不少团队在选型文档里写“对比开源向量模型”，实际需求却是中文文本检索。范围没划清，后面评测基准、硬件预算、合规审查全都会跑偏。
我自己现在习惯这样区分：先问模态，是纯文本还是多模态；再问交付形式，是 API 调用还是本地部署；最后问许可证，能不能商用、能不能改。这三个问题问完，候选池基本就清晰了。概念边界不是抠字眼，它决定了你后面拿什么数据去测、用什么指标去比。
1.3 对比评测的目标：效果、成本、性能与工程可落地性
早几年我做模型对比，眼里只有效果。拿 MTEB 榜单一看，谁分高就用谁。结果有一次选了个榜单前列的模型，单条查询延迟 300 毫秒，QPS 一上来直接崩。老板问我为什么不用那个便宜的轻量模型，我答不上来。那之后我变了，对比评测的目标变成四个字：效果、成本、性能、落地。
效果不只是检索准确率。语义相似度、聚类质量、分类边界，不同任务看不同指标。成本也不只是 API 单价。自部署的 GPU 显存、量化后的精度损失、运维人力，全是钱。性能这块，吞吐和延迟要分开看。离线批量嵌入和在线实时检索，对模型的要求完全不同。工程可落地性最容易被忽略，但它最致命。模型支不支持 ONNX、有没有 SentenceTransformers 接口、社区 issue 回复快不快，这些细节能决定项目是两周上线还是两个月难产。
我现在做对比表格，会强制自己填四列：效果分、单百万 token 成本、P99 延迟、部署复杂度。少一列都不行。有时候效果最好的模型，成本那一列直接爆表，那就得重新想业务上能不能接受。向量模型对比从来不是找最强，是找最合适。合适的前提，是把这四个维度放在同一张桌子上谈。
1.4 文章结构导读：从评测方法到开源模型再到选型决策
接下来我会按一条线往下聊。先讲对比方法论，评测维度怎么拆、基准怎么选、实验怎么设计才算公平。这部分我踩过不少坑，比如忘了归一化、距离度量用错、硬件环境不一致，结论全废。聊完方法，进入开源向量模型的实战对比。BERT 系、E5、BGE、GTE、Jina、Nomic、Instructor 这些主流阵营，我会按英文、多语言、中文、长文本、轻量级几个角度分别说。
再往后是选型决策。从业务目标倒推模型需求，用小样本验证代替盲目看榜，针对 RAG、语义搜索、推荐、去重、分类等场景给出不同的筛选逻辑。微调和蒸馏也会涉及，尤其难负例构造和对比学习策略，这些是让通用模型适配垂直领域的关键动作。部署优化那块，向量数据库、索引、量化、批处理、混合检索，我会结合自己踩过的坑讲。
最后收在结论和趋势上。没有万能最优模型，只有场景最优解。这句话是我做了十几个 RAG 项目后最深的体会。开源向量模型对比评测会持续迭代，文本嵌入模型选型也会越来越依赖自动化评估和人工抽检的结合。多模态嵌入、长上下文、稀疏稠密融合、端侧部署、智能体应用，这些方向正在改变对比的维度。我会尽量把每个环节讲透，让你拿着这篇文章就能搭起自己的评测流水线。
写第1章的时候我反复提效果、成本、性能、落地这四个词。真到动手对比，这四个词要拆成能测量、能复现的维度。我刚开始做评测时，拿一个检索指标跑完所有模型就下结论。上线后业务方问“为什么聚类效果这么差”，我答不上来。那之后我明白，对比方法论不是学术流程，是防止自己骗自己。
2.1 能力维度：语义相似度、检索、聚类、分类、重排序
语义相似度是我最早接触的评测任务。给两个句子，让模型判断它们意思接近不接近。这个任务看起来简单，实际很考验模型对同义替换、否定、语序的敏感度。我拿中文客服数据测过一批模型，有的模型把“我要退款”和“我不想退款”判成高度相似，这种错误在检索里就是灾难。语义相似度是地基，地基不稳，上面盖什么楼都晃。
检索任务比语义相似度更贴近真实场景。它要求模型在候选文档库里找出和查询最相关的那些。我平时用 Recall@K、MRR、NDCG 这几个指标。不同业务对 K 的敏感度不一样。RAG 场景里，前 5 条命中就够用。法律检索可能要看到前 20 条。我见过团队直接拿 MTEB 检索分数选模型，上线后发现自己的查询长度分布和榜单差异很大。检索评测必须用自己的查询-文档对，哪怕只有几百条。
聚类和分类经常被忽略。我早期对比模型只看检索，结果做用户意图聚类时，向量空间一团糟。聚类看的是模型有没有把相似语义压到相近区域。分类看的是线性可分性。重排序是两阶段检索的第二步，用交叉编码器对粗排结果精排。重排序模型通常比双编码器大，延迟也高。我现在的习惯是：检索任务测双编码器，重排序任务单独测交叉编码器，不混为一谈。有些模型检索强，重排序弱，选型时要分开看。
2.2 工程维度：向量维度、吞吐、延迟、显存、量化与部署成本
向量维度直接影响存储和计算。我做过一个项目，从 768 维换到 1024 维，召回率涨了 2 个点，但索引文件大了三分之一，内存成本每月多出几千块。老板问我这 2 个点值不值，我拿不出数据。后来我学乖了，评测时把维度、存储、内存一起算。维度不是越高越好，有些模型通过池化策略在低维下也能保持不错的效果。
吞吐和延迟要分开测。吞吐是单位时间能处理多少条文本，延迟是单条请求从进到出要多久。离线批量嵌入看吞吐，在线检索看延迟。我踩过一个坑：某个模型在 A100 上吞吐很高，换到 T4 上延迟直接翻倍。硬件环境一变，结论就变。显存也是硬约束。大模型 batch size 开不大，吞吐上不去。量化能降显存，但精度损失要测。我试过 int8 量化，有的模型掉点很少，有的直接崩。量化后的模型必须重新跑一遍能力维度评测。
部署成本不只是 GPU 钱。模型支不支持 ONNX、TensorRT，有没有现成的推理服务框架，社区维护活不活跃，这些隐性成本很大。我对比过两个效果接近的模型，一个用 SentenceTransformers 两行代码就能跑，另一个要自己写池化层和 tokenizer 适配。后者多花了三天工程时间。三天人力换算成钱，可能比省下的 GPU 费用还高。工程维度必须放进对比表，不能只当备注。
2.3 数据维度：训练语料、上下文长度、多语言与领域适配
训练语料决定模型的先天倾向。有的模型在网页文本上训练，口语化查询表现好。有的在学术论文上训练，长难句处理强。我做医疗 RAG 时，拿通用模型跑病历检索，效果惨淡。换成在 PubMed 上微调过的模型，召回率立刻上来。看模型卡里的训练数据描述不是走过场，它能帮你判断这个模型和你的领域有没有交集。
上下文长度是另一个分水岭。早期模型只能处理 512 个 token，长文档必须切块。切块会丢上下文，检索时经常找不回完整答案。现在不少模型支持 8K 甚至 32K 上下文。我测过 8K 模型直接嵌入整篇合同，效果比切块好，但显存占用和延迟也上去了。上下文长度不是越长越好，要看业务文档的平均长度和关键信息分布。有些任务，切块加重叠反而更稳。
多语言能力容易被高估。一个模型在多语言榜单上分数高，不代表中文就好。我见过英文强的模型在中文语义相似度上落后一大截。中文还有分词、成语、网络新词这些特殊问题。领域适配更细。金融、法律、医疗、电商，每个领域的术语和表达差异很大。我现在的做法是：通用榜单看个大概，然后用自己的领域数据跑小样本验证。几百条标注数据就能看出模型适不适合。
2.4 评测基准：MTEB、BEIR、C-MTEB 与中文垂直领域榜单
MTEB 是我最常用的公开基准。它覆盖检索、聚类、分类、重排序、语义相似度等多种任务，语言也多。刚入门时我天天刷 MTEB 排行榜，后来发现总分有欺骗性。一个模型可能在检索任务上排第一，在聚类任务上排到五十名开外。总分是加权平均，权重怎么定，榜单作者说了算。你的业务权重和榜单权重很可能不一样。我现在看 MTEB 只盯子任务排名，不看总分。
BEIR 专注零样本检索。它用一组不同领域的数据集测试模型在没有见过目标领域数据时的泛化能力。这个基准对我的启发很大。很多模型在训练分布内表现好，换个领域就崩。BEIR 分数高的模型，跨领域迁移能力通常更强。C-MTEB 是中文版的 MTEB，包含中文检索、分类、聚类等任务。做中文 RAG 的话，C-MTEB 比 MTEB 更有参考价值。我一般两个都看，英文任务看 MTEB，中文任务看 C-MTEB。
中文垂直领域榜单越来越多了。法律、医疗、金融、电商都有各自的评测集。这些榜单的数据更贴近真实业务，但质量参差不齐。我遇到过某个垂直榜单，查询和文档的标注标准很模糊，模型排名波动大。用这类榜单时，我会先看它的数据构建方式、标注一致性、有没有数据泄露。榜单只能当参考，不能当决策依据。真正的决策依据是你自己业务数据上的小样本评测结果。
2.5 公平对比原则：模型版本、提示词、归一化、距离度量与硬件环境
模型版本必须锁死。我有一次对比了三个模型，结论写进方案里。两周后复现，发现其中一个模型更新了权重，分数变了。整个对比要重跑。现在我评测前会记录模型的确切版本号、权重文件哈希、甚至 commit id。开源模型迭代快，不锁版本，结论就是流沙。API 模型也一样，供应商悄悄更新后端，你根本不知道。
提示词对某些模型影响巨大。有的模型需要加“query:”和“passage:”前缀，有的加了反而掉点。我试过同一个模型，换一种提示词模板，检索分数差了五个点。评测时必须为每个模型找到合适的提示词，不能一套模板走天下。归一化也是坑。有的模型输出向量已经归一化，有的没有。距离度量用余弦还是点积，要和归一化状态匹配。我犯过错：用余弦距离测一个未归一化的模型，结果全乱。
硬件环境要一致。我在 A100 上测的延迟，和 T4 上测的完全不是一回事。CPU 和 GPU 的差距更大。显存带宽、CUDA 版本、推理框架版本，都会影响结果。公平对比不是喊口号，是把这些变量全部控制住。我现在的评测清单包括：固定版本、固定提示词模板、统一归一化、统一距离度量、同一台机器、同一个推理框架。少一项，结论的可信度就打折扣。
这些方法论听起来琐碎，但每次评测前过一遍清单，能省掉后面无数扯皮。我团队现在有新同学做模型对比，我会让他先填一张实验配置表。表填完，再跑代码。第3章我会进入具体开源向量模型的实战对比，那时候这些维度会变成一张张分数表和曲线图。
第2章末尾我说要把评测维度变成分数表和曲线图。这章就干这件事。我拉过十几个开源向量模型，在英文、中文、长文本、跨领域几个场景里反复跑。跑完最大的感受是：向量模型对比不能只看一个总分，每个模型都有自己擅长的战场。
3.1 开源向量模型谱系：BERT 系、E5、BGE、GTE、Jina、Nomic、Instructor 等
我最早接触的开源向量模型是 Sentence-BERT 那一支。它把双编码器结构带进语义检索，后面很多模型都沿着这条路走。BERT 系模型参数不大，向量维度常见 768，部署简单。我拿它在小规模 FAQ 库上跑过，召回够用。它的短板也明显：上下文 512 token，中文原生训练少，长文档要切块。切块丢上下文，检索答案经常缺胳膊少腿。
E5 出现时，我注意到它强调弱监督对比学习。e5-base-v2 和 e5-large-v2 在英文检索榜单上表现很稳。它的提示词要求严格，query 和 passage 要加不同前缀。我试过去掉前缀，分数立刻掉。多语言版 mE5 在跨语言检索上有优势，英文查中文文档能跑。团队里同学问我 E5 和 BGE 怎么选，我会说先看语言分布和提示词工程愿不愿意做。
BGE 是中文社区绕不开的一族。BGE-large-zh、BGE-small-zh、BGE-M3 我都在项目里用过。BGE-M3 支持多语言、多粒度、长文本，还能输出稀疏向量。GTE 系列由阿里推出，GTE-large、GTE-multilingual 在英文和中文榜单都有位置。Jina 的 v2、v3 支持长上下文。Nomic 的 nomic-embed-text-v1.5 有 Matryoshka 表示，可以按需降维。Instructor 用指令控制嵌入方向，适合任务定制。这些家族名字像，脾气完全不同。向量模型对比时，版本号和提示词模板要一起记。
3.2 英文与多语言检索能力对比
英文检索我主要看 BEIR 和 MTEB 的 retrieval 子任务。BGE-M3、E5-large、GTE-large 在零样本检索上咬得很紧。我的测试集里，BGE-M3 在问答式查询上强，E5-large 在短关键词查询上稳。差异没有榜单总分看起来那么大。多语言场景要复杂得多。我拿英文 query 去搜中文、法文、德文文档。mE5 和 BGE-M3 的跨语言召回明显好于单语言模型。GTE-multilingual 在某些语对上追得很近。Jina v3 在多语言长文本上也有特点。
我踩过一个坑：某个模型在多语言 MTEB 上分数高，我直接上线。业务方反馈西班牙语用户搜不到结果。我查了数据，训练语料里西班牙语占比低，榜单分数被其他语言拉高了。向量模型对比不能只看总分，要看目标语言的子任务分数。我现在的做法是：把业务涉及的语言列出来，每个语言找一百条查询，跑 Recall@10。这个结果比榜单更可信。
多语言模型还有 tokenizer 问题。中文、日文、泰文的分词方式不同，同一个模型在不同语言上的 token 长度差异很大。长文本场景下，token 效率低的模型会提前截断。我测过同样 8K 上下文，有的模型能放下一万字中文，有的只能放三千字。向量模型对比时，我会把 tokenizer 信息也放进表里。
3.3 中文场景、长文本与跨领域泛化能力对比
中文场景我优先看 C-MTEB。BGE-zh 系列长期靠前，GTE-zh、M3E、Conan 也有自己的位置。BGE-M3 在中文检索上很能打。我拿客服对话、商品标题、法律条文三套数据跑过。客服对话里，BGE-large-zh 和 BGE-M3 差距不大。商品标题检索，M3E 的短文本匹配更利落。法律条文查询，BGE-M3 的长文本优势出来了。中文成语、网络新词、缩写，不同模型表现分化。向量模型对比在中文场景不能只测新闻语料。
长文本能力是这两年的分水岭。BGE-M3、Jina v3、Nomic v1.5 都支持 8K 以上。我拿整篇合同直接嵌入，和切块加重叠方案对比。整篇嵌入在找“违约责任”这种跨段落信息时更准。显存和延迟也涨得厉害。A100 上跑 8K 文本，batch size 只能开到 4。切块方案 batch size 能开到 64。我的选择是：关键文档整篇嵌入，普通文档切块。向量模型对比要区分这两种用法。
跨领域泛化我吃过亏。通用模型在医疗病历检索上召回很低。换成 PubMed 微调过的嵌入模型，指标立刻上来。金融公告、法律判决、电商评论，每个领域都有自己的黑话。公开榜单覆盖不了这些。我现在的流程是：通用榜单缩小候选范围，再用领域数据跑小样本验证。几百条标注就能看出模型是龙是虫。向量模型对比的终点是业务数据，不是榜单。
3.4 轻量模型与大规模模型的性价比对比
轻量模型我常用 bge-small-zh-v1.5、gte-small、e5-small、jina-v2-small、nomic-embed-text-v1.5。参数从 30M 到 140M 不等。大模型像 bge-large-zh、e5-large、gte-large、bge-m3，参数 300M 往上。T4 上小模型能跑到每秒上千条，大模型每秒两百条左右。显存占用差四倍到八倍。在线语义搜索 QPS 高，小模型更合适。离线聚类、批量去重，大模型可以慢慢跑。
性价比不是单纯看分数除以参数量。我做过一个推荐去重任务。小模型召回率 92%，大模型 96%。4 个点听起来不多，业务侧每天少几千条重复推荐。我算过 GPU 成本，大模型每月多花两千块，人力审核成本省下八千。这个账要算完整。换一个高并发搜索场景，小模型延迟 8ms，大模型 45ms。用户体验差一截，大模型分数再高也不能用。向量模型对比必须绑定场景。
量化是性价比的另一个杠杆。int8 量化后，大模型显存降一半，吞吐涨三成。精度掉多少要看模型。BGE-large-zh 量化后掉 1 个点，E5-large 掉 2 个点，有的模型直接崩。我建议量化后重新跑一遍业务评测集。Matryoshka 表示允许把 1024 维降到 256 维，存储省四分之三。Nomic 和 BGE-M3 都支持这种降维。降维后分数掉一点，工程成本降很多。向量模型对比表里我会加一列“可降维”。
3.5 许可证、社区维护、生态兼容与可商用性评测
许可证我每次都会看。BERT 系多数 Apache 2.0，E5 是 MIT，BGE 是 MIT，GTE 是 Apache 2.0，Nomic 是 Apache 2.0。Jina 的 v3 许可证标了 CC-BY-NC-4.0，商用需要单独授权。Instructor 是 Apache 2.0。有些模型只允许研究使用。我见过团队上线半年才发现许可证问题，被迫换模型。向量模型对比不能漏掉许可证这一栏。商用项目直接排除非商用模型，省得后面返工。
社区维护看 HuggingFace 下载量、最近更新时间、issue 响应速度。BGE 和 E5 的生态最成熟，SentenceTransformers 直接加载。GTE、Jina、Nomic 也有官方示例。冷门模型可能要自己写池化层和 tokenizer 适配。运维同学关心镜像大小、ONNX 支持、TEI 兼容性。我部署过没有 ONNX 的模型，CPU 推理慢得离谱。向量模型对比时，我会把“部署路径是否顺畅”当成一个维度。
生态兼容还看向量数据库和框架集成。Milvus、Qdrant、Weaviate、Chroma 对 BGE、E5 的支持最好。LangChain、LlamaIndex 的默认嵌入模型列表里常见这些。混合检索需要稀疏向量，BGE-M3 能同时输出稠密和稀疏表示。Jina v3 支持 late interaction。这些特性影响架构选型。社区活跃的模型遇到问题能搜到答案。冷门模型只能自己啃源码。向量模型对比走到落地，看的是工程兼容，不是榜单排名。
上一章跑了一堆模型，分数表有了，曲线图也有了。真到项目里选型，表格帮不了全部。我经历过拿榜单第一的模型上线翻车，也见过小模型跑出惊喜。向量模型对比最终要回到业务需求。这章聊怎么从需求走到落地。
4.1 选型前置：业务目标、语言、领域、延迟、预算与合规要求
我一般先拉业务方开会，问清楚五件事。业务目标是搜索、问答、推荐、去重还是分类。目标不同，模型要求差很远。语义搜索看重召回，分类看重特征质量，去重看余弦相似度阈值。语言分布要列出来，中文、英文、小语种各占多少。领域也要明确，医疗、法律、电商、客服，每个领域黑话不同。延迟要求决定模型大小。在线搜索 QPS 高，延迟 50ms 以内，小模型或量化模型优先。离线聚类可以慢慢跑，大模型随便上。预算包括 GPU 成本、标注成本、运维人力。合规要求看许可证，商用项目避开非商用模型。我见过团队用了 CC-BY-NC 的模型，上线前法务拦下来，连夜换模型。选型前置清单做好，后面少踩坑。
语言这块我吃过亏。业务方说“主要中文，少量英文”。我选了中文榜单最强的模型。上线后英文 query 搜中文文档效果差。英文用户占比 15%，投诉不少。后来补了多语言模型。向量模型对比时，语言分布要精确到百分比。领域适配也要提前问。通用模型在医疗术语上召回低，换领域微调模型才解决。延迟要求跟模型大小直接相关。T4 上 bge-small 延迟 8ms，bge-large 45ms，bge-m3 80ms。业务方要求 30ms 以内，大模型直接出局。预算够不够买 A100，也影响选择。合规方面，Apache 2.0 和 MIT 最省心。GTE 是 Apache 2.0，BGE 是 MIT，E5 是 MIT。Jina v3 商用要授权，我一般先排除。选型前置做好，候选范围缩一半。
4.2 候选模型筛选：榜单参考、小样本验证与人工评估
榜单我只看子任务。MTEB 总分高不代表业务场景强。我先把业务语言和任务对应的榜单子集拉出来。中文检索看 C-MTEB retrieval，英文看 BEIR，多语言看 MIRACL。榜单前十名里挑五到八个候选。版本号要记清楚，bge-large-zh-v1.5 和 bge-large-zh 是两回事。提示词模板也要统一，E5 要加 query 和 passage 前缀，BGE 不加也能跑。归一化、距离度量、硬件环境固定。公平对比原则上一章讲过，这里不重复。
小样本验证是筛选核心。我从业务数据里抽五百条 query，人工标注相关文档。每个候选模型跑 Recall@10、NDCG@10、MRR。五百条不够统计学显著，但能看出模型方向。有一次 bge-small 和 bge-large 分数只差 2 个点。我加了一百条难负例，bge-large 拉开 8 个点。难负例构造后面细说。人工评估也不能省。我让标注同学看 top10 结果，标注“相关”“部分相关”“不相关”。人工评估能发现榜单看不出的问题，比如模型对否定句不敏感，或者对数字不敏感。向量模型对比走到这一步，候选从八个缩到三个。
小样本验证有个坑：查询分布要接近线上。我拿历史搜索日志抽样，覆盖头部查询和长尾查询。只测头部查询，模型分数虚高。长尾查询才是真实考验。人工评估要控制标注员偏差。我一般让两个人独立标，不一致的讨论。评估指标选 Recall 还是 NDCG，看业务。召回优先用 Recall，排序优先用 NDCG。分类任务看准确率和 F1。聚类看轮廓系数和人工可解释性。去重看相似度阈值下的精确率和召回率。候选筛选没有银弹，多轮迭代才靠谱。
4.3 场景化选型：RAG、语义搜索、推荐、去重、分类与聚类
RAG 场景我优先看长文本和混合检索。RAG 要把文档切块嵌入，检索相关块喂给大模型。BGE-M3 支持 8K 上下文，还能输出稀疏向量，适合混合检索。E5-large 和 GTE-large 在短块检索上稳。Jina v3 的 late interaction 对长文档排序有帮助。RAG 还要看嵌入模型和重排序模型的配合。我常用 BGE-M3 做召回，bge-reranker-large 做精排。向量模型对比在 RAG 里要测端到端问答质量，不是只测检索指标。
语义搜索场景看延迟和召回平衡。在线搜索 QPS 高，我选 bge-small-zh 或 gte-small。用 int8 量化后延迟降到 5ms。召回不够就上 bge-base，再不够上 bge-large。混合检索能补稠密向量的短板。BM25 加稠密向量，召回率涨 5 到 10 个点。推荐场景看物品嵌入和用户嵌入的匹配。去重场景看余弦相似度阈值。分类和聚类看嵌入质量。分类任务我拿嵌入向量训一个逻辑回归，效果不差。聚类任务用 K-means，嵌入质量决定簇的纯度。不同场景选型逻辑不同，向量模型对比要绑定场景指标。
推荐去重我做过一个例子。每天百万级商品去重，用 bge-small 召回 92%，bge-large 召回 96%。4 个点对应每天少几千条重复推荐。GPU 成本每月多两千，人力审核省八千。这个账算下来选大模型。换成高并发搜索，小模型 8ms，大模型 45ms，用户体验差一截，大模型分数再高也不能用。分类任务我试过用 bge-large 提取特征，逻辑回归准确率比微调 BERT 低 1 个点，但训练成本低很多。聚类任务用 bge-small 就够，簇边界清晰。选型没有万能答案，场景决定选择。
4.4 微调与蒸馏：领域适配、难负例构造与对比学习策略
通用模型在垂直领域经常不够用。医疗病历、法律判决、金融公告，术语和表达方式特殊。微调嵌入模型能涨 10 到 20 个点。我一般用对比学习，正例是同一文档的不同表述，负例是随机文档。难负例构造是关键。随机负例太简单，模型学不到东西。难负例用 BM25 召回但标注不相关的文档，或者用当前模型检索排名靠前但不相关的文档。我拿医疗数据试过，难负例让 Recall@10 从 65% 涨到 82%。
微调数据量不用很大。几千条到几万条就能见效。标注成本高的话，可以用弱监督生成。比如用大模型生成 query，或者用点击日志构造正例。蒸馏是另一个思路。大模型教小模型，小模型学大模型的相似度分布。我试过用 bge-large 蒸馏 bge-small，小模型在业务数据上追平大模型 90% 的效果。蒸馏后小模型延迟低，适合在线。微调要注意过拟合。领域数据太少，模型会忘记通用能力。我一般混合通用数据和领域数据一起训。对比学习温度系数、批大小、学习率都要调。微调不是必须的，先跑通用模型，不够再微调。
难负例构造我踩过坑。负例太相似，模型学到的是噪声。负例太简单，模型学不到区分。我一般用 BM25 召回 top50，去掉正例，取 top10 作为难负例。再用当前模型检索 top50，取排名靠前但不相关的作为动态难负例。动态难负例每轮更新，效果更好。对比学习策略上，我常用 InfoNCE 损失。批大小越大，负例越多，效果越好。A100 上批大小能开到 256。小显存用梯度累积。蒸馏时温度系数设 2 到 5。微调后要重新跑业务评测集，不要只看损失曲线。
4.5 部署优化：向量数据库、索引、量化、批处理与混合检索
模型选好了，部署是下一关。向量数据库选 Milvus、Qdrant、Weaviate、Chroma。Milvus 适合大规模，Qdrant 轻量，Chroma 适合原型。索引类型选 HNSW 或 IVF。HNSW 查询快，内存占用高。IVF 内存低，查询慢一点。我一般用 HNSW，参数 M 和 efConstruction 调一调。量化能省显存和存储。int8 量化后大模型显存降一半，吞吐涨三成。精度掉多少要看模型。BGE-large-zh 量化后掉 1 个点，E5-large 掉 2 个点。量化后要重新跑评测集。批处理提高吞吐。在线服务 batch size 小，离线任务 batch size 大。混合检索结合稠密和稀疏向量。BGE-M3 能同时输出两种表示。BM25 加稠密向量，召回率涨 5 到 10 个点。部署优化没有终点，压测调参反复来。
向量数据库选型看数据规模和团队熟悉度。千万级向量用 Milvus，单机 Qdrant 也能扛。索引参数影响召回和延迟。HNSW 的 M 越大，召回越高，内存越大。efSearch 越大，召回越高，延迟越高。我一般先设 M=16，efConstruction=200，efSearch=64，再压测调。量化用 Scalar Quantization 或 Product Quantization。SQ 简单，PQ 压缩率高。我常用 SQ int8，精度损失小。批处理注意显存。在线服务 batch size 设 1 到 8，离线设 128 到 512。混合检索需要向量数据库支持稀疏向量。Qdrant 和 Milvus 都支持。部署优化要平衡召回、延迟、成本。向量模型对比走到部署，才是真正落地。
4.6 选型决策表与常见误区：避免只看榜单、忽略成本与场景错配
我做一个选型决策表，列上模型名称、语言、领域、维度、上下文、延迟、显存、许可证、榜单分数、业务分数。业务分数最重要。榜单分数参考。决策表帮团队对齐信息。常见误区有几个。只看榜单总分，忽略子任务。榜单第一的模型在业务数据上可能排第五。忽略成本，大模型上线后 GPU 账单爆炸。忽略场景错配，拿分类模型做检索。忽略许可证，商用项目用非商用模型。忽略版本，bge-large-zh 和 bge-large-zh-v1.5 差别大。忽略提示词，E5 不加前缀分数掉。忽略归一化，距离度量不一致。忽略硬件，模型在 A100 上快，在 T4 上慢。向量模型对比不是选一个冠军，是选一个适合业务的队员。
选型决策表我一般做成 Excel 或 Notion。每行一个候选模型，每列一个维度。权重按业务定。延迟权重高，就选小模型。召回权重高，就选大模型。业务分数用小样本验证和人工评估得出。决策表要定期更新，新模型出来重新跑。常见误区里，我最想提醒的是场景错配。拿语义搜索模型做分类，效果可能不如逻辑回归。拿去重模型做推荐，相似度阈值不对。拿长文本模型做短文本检索，浪费算力。向量模型对比要回到业务目标。没有万能最优模型，只有场景最优解。选型决策表是工具，不是答案。落地验证才是终点。
跑完前面几章的评测和选型流程，我坐下来整理整个向量模型对比的收获。说实话，折腾了这么久，最大的体会就一句话：别指望找到一个通杀所有场景的模型。榜单上排第一的那个，换个业务场景可能连前三都进不去。我见过太多团队拿着 MTEB 榜首的模型硬套，结果上线效果平平。向量模型对比不是体育比赛，没有冠军奖杯，只有适合你业务的那个选手。
5.1 核心结论：没有万能最优模型，只有场景最优解
向量模型对比做到现在，我手里攒了一堆评测数据。bge-large 在中文检索上确实稳，e5-large 在英文任务里表现好，gte-large 多语言均衡。这些结论都有前提条件。换一批数据、换一个领域、换一种硬件，排名就可能翻转。我做过一次实验，同一个模型在电商数据和医疗数据上的检索分数差了十二个点。模型本身没变，数据分布变了，效果就变了。向量模型对比不能脱离数据谈优劣。
业务目标也在变。今天做语义搜索，明天加一个推荐模块，后天要上 RAG 问答。一个模型打不了天下。我现在的做法是准备两到三个模型，按场景切换。在线搜索用 bge-small 保延迟，离线聚类用 bge-large 保质量，RAG 用 bge-m3 保长文本和混合检索。向量模型对比的价值不在于选出唯一最优，而在于搞清楚每个模型的适用边界。边界清楚了，选型就是查表的事。
还有一个容易被忽略的维度：成本。榜单不显示 GPU 账单，也不显示运维复杂度。bge-large 比 bge-small 召回高四个点，显存多三倍，延迟多五倍。这四个点值不值，要看业务能不能消化。我算过一笔账，日均千万次查询的场景，换大模型每月多花两万块 GPU 费，召回提升带来的转化收益如果不到两万，这个升级就是亏的。向量模型对比要算经济账，不能只看技术分。
5.2 开源向量模型对比评测的持续迭代建议
开源模型的迭代速度太快了。去年 bge 还是中文检索的标杆，今年就有新模型在 C-MTEB 上刷榜。我每季度重新跑一轮评测，更新候选池。评测流程固定下来，换模型不换方法，数据对比才有意义。我一般把评测脚本封装好，新模型出来改一个配置就能跑。评测集保持稳定，不要每次换数据，否则分数没法比较。
评测维度也要跟着业务走。通用榜单只能做初筛。我现在的评测管道分三层。第一层跑 MTEB 和 C-MTEB 子任务，快速筛掉明显不行的。第二层跑业务小样本，五百到一千条 query，看真实场景表现。第三层做人工评估和线上 AB 测试。三层跑完，一个模型能不能用就清楚了。这个管道我每半年优化一次，加新指标，去旧指标。向量模型对比评测不是一次性项目，是持续运营的基础设施。
社区维护度也要持续跟踪。有些模型发完论文就没更新了，issue 没人回，版本不兼容。我优先选活跃维护的模型。bge 系列更新频繁，社区活跃。e5 和 gte 背后有微软和阿里，维护有保障。jina 和 nomic 更新节奏慢一些，但文档质量高。向量模型对比要看长期维护成本，不能只看当前分数。一个没人维护的模型，半年后可能就是技术债。
5.3 文本嵌入模型对比与选型的落地清单
选型落地我整理了一个清单，每次项目启动照单走一遍。第一步明确业务目标、语言分布、领域特点、延迟要求和预算范围。第二步拉榜单子集，选五到八个候选。第三步跑业务小样本评测，选二到三个进入下一轮。第四步人工评估和难负例测试。第五步压测部署，看量化后精度和延迟。第六步算总拥有成本，包括 GPU、人力、运维。第七步线上 AB 测试，灰度放量。八步跑完，选型决策基本靠谱。
这份清单不是死的。有的项目卡在预算，第二步就要筛掉大模型。有的项目要求多语言，候选池里只留多语言模型。有的项目数据敏感，只能用可私有化部署的开源模型。清单是骨架，血肉要按业务填。我见过团队跳过业务小样本评测，直接拿榜单第一上线，结果召回率比预期低二十个点。也见过团队不做量化测试，部署后发现显存不够，临时换模型。落地清单能防住大部分低级错误。
选型决策表要定期更新。新模型出来，花半天跑一轮评测，更新表格。表格里标注每个模型的适用场景、注意事项、已知问题。团队新人拿到表格就能上手。我现在的表格里，bge-small-zh 适合高并发短文本，bge-large-zh 适合质量优先的离线任务，bge-m3 适合长文本和混合检索，e5-large 适合英文多语言混合场景。每个推荐都带前提条件。向量模型对比的落地清单，本质是把经验沉淀成可复用的流程。
5.4 未来趋势：多模态嵌入、长上下文、稀疏稠密融合、端侧部署与智能体应用
未来向量模型会往几个方向走。多模态嵌入已经起步。jina-clip 和 bge-vl 能把文本和图像映射到同一空间。电商搜图、视频检索、跨模态推荐，这些场景会越来越多。我试过用 bge-vl 做图文匹配，效果比分别嵌入再对齐好不少。多模态嵌入模型对比会比纯文本复杂，评测维度要加跨模态检索和生成质量。
长上下文是另一个方向。现在主流模型支持 512 到 8K token，未来会往 32K 甚至 128K 走。长文档不用切块，直接嵌入整篇，检索时保留更多上下文。bge-m3 的 8K 在长文档场景已经比 512 的模型强。上下文再拉长，模型架构和显存管理都要改。我关注几个开源项目在做长上下文嵌入，效果还在验证。向量模型对比的评测集要加长文档子集，不然测不出差异。
稀疏稠密融合会成为标配。bge-m3 已经支持稠密、稀疏、多向量三种输出。后面的模型大概率都会带稀疏表示。混合检索不再是外挂 BM25，而是模型内置能力。部署时一个模型出多种向量，向量数据库统一存储和检索。向量模型对比的评测要加混合检索子任务，单独看稠密分数不够全面。
端侧部署也在推进。手机、边缘设备、IoT 终端需要本地嵌入。小模型量化后放到端侧，延迟低，隐私好。我试过把 bge-small 量化到 int8 跑在骁龙芯片上，单条嵌入 15ms。端侧模型对比看的是功耗、内存、精度三者的平衡。未来会有更多专为端侧设计的嵌入模型。
智能体应用会给向量模型提新要求。Agent 要记忆、要规划、要调用工具。记忆检索靠嵌入模型，规划需要推理，工具调用需要意图理解。嵌入模型在 Agent 里不只是检索，还要做状态表示和动作空间映射。我最近在试把嵌入模型接到 Agent 的记忆模块，检索历史对话和工具调用记录。效果还在调。向量模型对比未来要加 Agent 场景的评测维度，比如记忆召回准确率和动作预测相关性。
这几个方向不是孤立的。多模态加长上下文加稀疏稠密融合，可能是下一代模型的标配。端侧部署和智能体应用会催生新的模型架构。向量模型对比的方法论要跟着演进。评测集、评测维度、评测流程都要更新。我现在每季度花两天时间看新论文和新模型，保持手感。向量模型对比没有终点，技术在跑，评测也要跟着跑。
