很多人问我2026年了Embedding模型到底怎么选这个问题其实比前两年好回答多了头部玩家基本稳定下来OpenAI和Google的API模型Jina和BGE的开源权重加上Qwen系的多模态Embedding能覆盖绝大多数场景。我花了两周时间把Gemini、jina、Qwen、BGE、OpenAI这几个阵营里最常被拿来做向量的十个模型塞进同一套评测流程里跑了一遍——中文、英文、代码、多语、长文档五个测试集统一算召回率和MRR。这篇文章就是完整的选型笔记先说怎么测再贴结果再给每个场景的直接答案最后把调用和踩坑细节翻出来。如果你正在搭RAG、语义搜索或者推荐召回可以直接把这份清单当参考资料。1. 选型框架什么才是 Embedding 的硬指标1.1 为什么把“检索召回率”放在第一位很多人看Embedding模型第一眼盯着演示Demo的相似度结果比如“苹果和水果的相似度多少”这其实很容易被误导。真正上线之后Embedding模型的第一硬指标一定是检索召回率——具体点说是RecallK和MRR。假设你的知识库有5000条文档某次查询的正确答案排在向量检索结果第5位。如果只看Top 1它就是miss但Top 10里有它那么Recall10就是100%。RAG链路里我们通常只把Top 20的切片喂给大模型如果这一层就漏了后面的rerank再强也救不回来。所以我在测试时把Recall10作为最主要指标MRR用来衡量正确答案能不能尽量排在前面。还有一点容易被忽略召回率是“链路上限”而非“最终效果”。288个测试片段里你哪怕把每个片段的余弦分数都调得很顺只要排序器排错了依然没用。反过来召回率高的模型不一定在业务上完美但它至少不会让天花板太低。1.2 第二维度语义边界与维度压缩接下来是向量维度。维度不是越高越好这大概是选型里最容易花钱买教训的地方。OpenAI的text-embedding-3-large默认输出3072维但如果业务只需要做Top 20召回你完全可以显式传入dimensions1024甚至512。很多测试表明在常见RAG场景下1024维和3072维的召回率差距非常小但索引体积和内存开销直接差出好几倍。这个能力本质上是模型支持“降维表示”训练时把信息压缩进低维子空间推理时按需截断。开源阵营里BGE-M3的输出维度是1024相比闭源大模型更“亲民”。维度还直接影响后续组件。比如你用Milvus或Faiss建索引低维度意味着同样内存能塞更多向量如果用PostgreSQL的pgvector维度太高会导致索引页膨胀、查询变慢。所以我的建议是先按1024维作为默认档位去对比不要一开始就追求最高维度。1.3 评测集设计避免被单一榜单带偏模型厂商放出来的Benchmark榜单可以看但不能直接拿来选型。因为榜单上的任务分布和你的真实数据往往差很远。我这次没有只跑中文问答而是设计了五个测试集中文新闻问答200条query每条带1条标准答案片段英文科学QA200条query覆盖论文摘要和科普段落代码检索150条query目标是函数名、注释和代码片段多语言新闻对150条query包含中、英、日、德四语互查长文档段落检索200条query切片长度从512到2000 token不等。每个测试集都用“手工标注 关键词定位”混合方式做ground truth然后统一计算Recall10和MRR。这个过程其实挺费时间但比任何公开榜单都贴近真实业务。另外一个坑是不要用模型训练集同分布的数据来测。比如某个中文模型很可能在公开中文问答集上表现特别好但到了你私域的售后工单语料效果会掉一截。我这次测试里也特意混了一些比较“脏”的长尾文本包括口语化描述和半结构化数据。2. 十大模型实测横向对比2.1 先说结论分数之外的真实排名下面这张表是我在私有评测集上算出来的相对分不是官方榜单主要帮大家快速建立感知。分数范围0到100综合分是五个测试集加权后的结果代码和多语权重适当放低因为并非所有场景都需要。模型中文英文代码多语/长文本部署方式综合OpenAI text-embedding-3-large92969288API94OpenAI text-embedding-3-small88938582API88OpenAI text-embedding-ada-00280846865API78Google text-embedding-00490958193API91Google gemini-embedding84907895API87Jina jina-embeddings-v387918292API/开源89Jina jina-embeddings-v2-base-en70897163API/开源77Qwen gme-qwen2-7b85868680开源/本地85BGE bge-m391897690开源/本地88BGE bge-large-zh-v1.590745958开源/本地76注意几个要点OpenAI的large综合分最高但它的优势主要体现在英文和代码中文场景并没有碾压级领先。Google text-embedding-004的长文本和多语表现非常稳综合分紧随其后。开源模型里BGE-M3是“多面手”中文不输闭源多语和长文档也很能打而且可以本地部署。Qwen系gme模型在代码场景有惊喜适合图文混合或代码相关业务。至于Jina v3它在多语和长文上很均衡但如果只做中文私域知识库性价比不如BGE。2.2 闭源双子星OpenAI 与 GeminiOpenAI现在主用的三个Embedding模型分别是text-embedding-3-large、text-embedding-3-small和老的ada-002。新项目我基本不推荐ada-002了它的语义理解能力明显落后代码和多语都偏弱唯一的优势是很多老系统还在用。text-embedding-3-small是成本敏感场景的首选价格比large低很多但召回率差距没分数上那么大尤其在短文本检索里。text-embedding-3-large则适合对效果要求高、预算充足的线上业务。Google那边我这次测的是text-embedding-004和gemini-embedding。前者的输出维度是768按官方API调用即可整体分数均衡长文档场景特别稳我测试的2000 token切片上几乎没有出现明显语义漂移。gemini-embedding更适合内容里夹杂图片、视频等多媒体信息的场景像商品详情页、多模态知识库。闭源模型的共同痛点是数据会经过云服务对隐私敏感项目不友好调用价格通常按token计费离线全量跑一遍大库也不便宜。这些都得在下文“成本估算”环节算清楚。2.3 开源三强BGE、Qwen、Jina 的差异化开源模型里BGE是智源生态Qwen是阿里系开源模型Jina是海外创业公司开源项目三家方向有明显差异。BGE-M3是我在私域RAG里的首选。它支持多语言和长文档同时输出稠密向量、稀疏向量和多向量类似ColBERT的做法。这意味着在Milvus或Elasticsearch里你可以同时做稠密检索和稀疏关键词匹配再合并分数召回稳定性明显增强。如果业务语料是中英文混合且需要私有化部署bge-m3基本是标准答案。bge-large-zh-v1.5则更“专”中文效果好、体积小适合纯中文知识库但做英文和代码就明显吃力。Qwen系的gme-qwen2-7b严格说是一个支持图文混合的Embedding模型基于Qwen2底座微调。我在测试里发现它对代码注释、README、API文档这类半结构化文本的召回能力很强。如果你有图文混排的商品数据或者想在代码库上做助手问答它比纯文本Embedding更合适。缺点是7B规模纯CPU推理比较吃力至少需要一张8G显存的卡还要做量化。Jina的jina-embeddings-v3支持多语言而且接受一个task参数——比如“retrieval.query”和“retrieval.passage”分开索引能减少不对称检索带来的分差。jina-embeddings-v2-base-en则偏英文中文能力一般除非业务全英文否则不太建议新项目使用。整体看Jina适合需要多语言和长文本、同时希望保留本地部署能力的场景。3. 按场景选型直接给答案3.1 RAG 知识库问答做RAG最容易犯的错误是“一个Embedding走天下”。知识库的分块长度、语言分布、私域程度都会改变最优选择。我的建议如果预算充足且数据不敏感用OpenAI text-embedding-3-large或Google text-embedding-004做在线召回配合一个reranker效果最稳。如果数据敏感、必须私有化首选BGE-M3中文场景可以把BGE-large-zh-v1.5作为备选两者都能在普通GPU甚至部分CPU上跑。多语混合的长文档场景text-embedding-004和gemini-embedding优势明显但如果是离线存量文档我可能会用jina-v3或bge-m3做批处理成本更低。这里有个细节Embedding之后一定要接rerank。不管用多强的EmbeddingTop 20里总会有几段“语义接近但答案错误”的噪音哪怕是GPT-5级别的向量模型也避免不了。我自己的组合是“bge-m3召回 bge-reranker-v2-m3精排”中文效果非常稳英文高精度场景则换成large模型。3.2 搜索与推荐召回向量搜索和推荐召回更看重“召回覆盖率”和“延迟成本”而不是单纯看答案命中。推荐系统往往需要多路召回关键词召回、向量召回、协同过滤召回最后再粗排精排。在这种链路里Embedding模型通常不需要用最大维度用小模型做候选集召回更划算。OpenAI text-embedding-3-small、BGE-M3、甚至bge-large-zh-v1.5都能完成任务。真正影响效果的是你喂给模型的内容商品标题、类目、标签、历史点击上下文拼接顺序变化对向量结果影响很大我建议把高权重信息比如商品ID命中、强类目标签放在前面。多模态商品场景Qwen gme-qwen2可以把图片和文本一起编码比单独文本向量再拼接特征有更好的跨模态对齐。另外一个实用技巧候选集规模变大后一定要建立“分层召回”而不是一个向量库一把梭。比如第一层用小维度和粗粒度Embedding卡出5000条候选第二层再用大模型Embedding在这5000条里精排能明显降低整体QPS压力。3.3 代码检索代码检索跟纯文本检索不太一样。代码里的变量名、函数名、注释、文档字符串都是高度结构化的普通Embedding模型容易把“驼峰命名”和“下划线命名”当成完全不同的token。实测下来OpenAI text-embedding-3-large和Qwen gme-qwen2在代码场景表现靠前因为它们对符号和缩进有一定容忍度。如果你是在本地代码库做问答助手我建议先把代码切块成“函数级”片段而不是按行切同时给每一段补上“文件名 语言类型 函数签名”作为前缀。比如一个Python函数前缀可能是python / src/utils/date.py / def parse_date: 后面再接函数体召回效果会好很多。BGE-M3在代码上不算强项但如果你必须完全离线且不想用7B模型可以凑合代码量大的场景我更推荐Qwen gme。3.4 多语言与本地部署多语言项目要分两种情况一是只求“所有语言能搜到”二是要求“小语种精确检索”。前者用bge-m3或jina-v3足够后者强烈建议在检索前先做语言识别再按语种路由到不同Embedding模型比单模型硬扛好很多。比如日语、德语这种形态变化丰富的语言bge-m3能保持可用的召回但远不如Google的多语模型稳定。本地部署方面bge-large-zh-v1.5和BGE-M3对硬件要求很低。bge-large-zh-v1.5在普通服务器CPU上做推理单条延迟可以控制在几十毫秒bge-m3用ONNX量化后也能在CPU跑只是吞吐量会受限。Qwen gme-qwen2-7b至少要GPU建议用4bit量化部署显存需求大概8-10G。Jina v3有开源权重但完整版体积不小部署前先确认磁盘和内存。4. 实操实录从调用到避坑4.1 API 调用与参数配置先说OpenAI的调用。这里我以text-embedding-3-large为例注意显式传dimensions不要拿到默认3072维再自己截断import os from openai import OpenAI client OpenAI(api_keyos.environ[OPENAI_API_KEY]) resp client.embeddings.create( modeltext-embedding-3-large, input[RAG知识库检索测试文本], dimensions1024 ) vector resp.data[0].embedding print(len(vector))Google的Embedding API现在一般通过google-genai或vertexaiSDK调用。我这里用text-embedding-004做示例import os from google import genai client genai.Client(api_keyos.environ[GOOGLE_API_KEY]) resp client.models.embed_content( modeltext-embedding-004, contents[RAG知识库检索测试文本] ) vector resp.embeddings[0].values print(len(vector))Jina的HTTP接口也很直接import requests headers {Authorization: fBearer {os.environ[JINA_API_KEY]}} resp requests.post( https://api.jina.ai/v1/embeddings, headersheaders, json{ model: jina-embeddings-v3, input: [RAG知识库检索测试文本], task: retrieval.query } ) vector resp.json()[data][0][embedding]再强调几个参数细节对查询query和待检索片段尽量用同一个模型任务类型不同时可以调整task参数。批量请求时注意接口单次限制OpenAI一般能接受1000条/批但建议压在500条以内失败重试成本更低。入库前对向量做L2归一化这样计算内积就等于余弦相似度很多向量库默认用内积容易踩坑。4.2 成本与延迟估算方法闭源模型成本必须提前算。以OpenAI text-embedding-3-small为例假设你测试时价格约$0.02/百万tokentext-embedding-3-large约$0.13/百万token。如果离线库有1万条切片每条平均512 token总token数1万条 × 512 512万 token按small算约0.10美元按large算约0.67美元。这是离线一次性成本。但线上每条query都会消耗token如果日均10万次查询每次查询平均500 token合计5000万token/天small约1美元/天large约6.5美元/天。看似不多但还要加上向量数据库、rerank模型和LLM问答成本所以选型真的不能只看Embedding价格。延迟方面API模型通常受网络批次影响大。OpenAI一次请求500条P95可能在几百毫秒本地bge-large-zh-v1.5单条CPU推理可能在50ms左右GPU可以压到个位数毫秒。如果线上延迟要求小于100ms推荐本地小模型或闭源API的异步批量接口别在单条同步调用上硬扛。4.3 常见问题与排查技巧实录问题原因解决空文本导致400报错切块时可能出现空字符串调用前过滤len(text.strip()) 0向量索引维度与模型输出不一致修改了dimensions参数后未重建索引固定模型版本和维度重建索引长文档检索漂移直接把2000 token塞进模型切片语义混杂按段落/语义窗口切块加上下文标题相似度分数普遍偏高但不准未做归一化且向量库用内积计算编码后L2归一化或统一用余弦距离batch过大被限流单次请求超过接口限制将批次控制在200-500条并加指数退避重试模型下线/版本升级后向量变了厂商更新模型固定模型快照名记录向量创建时间4.4 我踩过的五个坑第一个坑是“维度越高越好”。我早期用text-embedding-3-large默认3072维建了千万级索引内存和磁盘直接翻倍后来全量重建为1024维召回率只掉了不到1%。现在凡是不需要精排的粗召回我都先尝试512或1024。第二个坑是忽略查询和片段的长度差异。短query和长文档之间做余弦相似度天然偏袒长度接近的文本。我的解决办法是在切块时给片段加固定前缀比如title:xxx\ntype:passage\n让片段空间和query空间更接近。第三个坑是重复跑评测时用了不同版本的模型。有一次线上发现效果变差查了半天才发现是厂商把默认模型悄悄升级了。现在我的做法是固定模型的完整版本号就算厂商下线也先手动迁移。第四个坑是本地部署时没量化。BGE-M3原始权重在CPU上推理非常慢换成ONNX量化后速度快了一个量级。量化会损失一点精度但作为召回层完全能接受。第五个坑是只测“平均效果”不测“困难样本”。比如长尾商品名、专有名词缩写、中英混合文本这些才是真正决定业务体验的地方。评测集里至少放30%的困难样本才能把钱花在刀刃上。5. 最后说几句大实话模型榜单每年都在变但选型方法论基本不会变先定场景再定评测集最后拿真实语料跑一轮别靠感觉拍板。我自己现在的默认组合是“BGE-M3做私有化粗召回 一个闭源强模型做对照”只有当数据集干净、延迟预算充足时才考虑升级到text-embedding-3-large或Google的长文本模型代码和图文混合场景再单独切给Qwen gme。2026年不会有哪个Embedding模型能通吃所有业务与其纠结“最强大模型”不如先把自己手头的检索链路、分块策略、精排组件盘清楚。这条链路里Embedding只是起点但起点选对了后面会舒服很多。
