嵌入模型怎么选：升级嵌入层不踩全库重嵌的坑

嵌入模型是 RAG 检索质量的天花板：查询和文档都被压进它定义的那个向量空间里，空间质量不行，后面 reranker 调得再细、prompt 写得再花也补不回来。所以不少团队迟早会面对同一个决定——换掉手上的嵌入模型。麻烦在于，换模型从来不是改一行配置的事：新旧模型输出的向量不在同一个空间里，不能混用，换模型等于全库重嵌。S5 Labs 在讨论 EmbeddingGemma 2 迁移时把话说得很直白：migrating means full re-embed。

既然重嵌成本这么高，决策就必须一次做对。这篇 SOP 聚焦"换嵌入模型"这一件事，按顺序走六步：第零步对表现状，然后是选型决策、新旧双跑对比、灰度切流、全量重嵌，最后补上评估闭环。检索平台怎么搭（Dify 实操）和文档怎么分块，本站此前已有专文；想了解本批刚发布的 EmbeddingGemma 2 模型本身，看开源篇；想横向对比几款主流嵌入模型的参数与许可，看横评篇。

一、第零步：对表现状，别急着看榜单

选型的第一步不是打开评测榜，而是把现有检索库的底细摸清。至少回答四个问题，写下来，后面每一步都要用到：

一是现有模型与维度。 库里的向量是哪个模型、多少维产出来的？这决定了新向量库的 collection 是重建还是并行新建——不同模型的向量空间不可互换，即使维度恰好相同也不能混。

二是上下文长度。 旧模型上下文短，分块往往切得很碎；新模型如果上下文长得多，分块策略要不要跟着放大？放大意味着连分块层一起重做，工作量翻倍，要提前算进决策（分块思路见分块篇）。

三是是否支持 MRL。 MRL（套娃表示学习）允许把一条高维向量裁短再用。老模型没有这个能力；换到支持 MRL 的新模型，等于白拿一个存储压缩选项——EmbeddingGemma 2 官方口径是 768 维可裁至 128 维，向量存储最多省 6 倍。

四是部署形态。 现在是 API 调用还是自部署？迁移路径完全不同：API 换 API 最省事，但议价能力和数据自主权都最弱；自部署换自部署要重算显存与吞吐预算；跨形态迁移则两头都要重做。

摸完底再补一个提醒：产线上流传的一条经验（转述口径）是，检索效果不对，先加 reranker，再考虑换嵌入模型——reranker 分钟级生效，换嵌入模型是全库重嵌的大动作。如果 reranker 能救回来，这一整套 SOP 都可以不用启动。

二、选型决策：五个硬指标

先把候选模型的关键参数摊在一张表上。注意：各家分数各引各的、不同榜单口径不可跨表排名，这里只列参数与许可这类客观项：

表之外，决策要过五道关：

指标一：许可与部署门槛。 自部署路线上，EmbeddingGemma 2 与 Qwen3-Embedding 均为 Apache 2.0，BGE-M3 为 MIT，均为 Hugging Face API 于 2026-10-09 实核、全部无需门控。EmbeddingGemma 2 有一处细节值得知道：Apache 2.0 声明写在仓库 metadata 与模型卡链接里，仓库根目录并没有 LICENSE 文件，模型卡还保留一行要求遵守 Gemma Prohibited Use Policy——与一代的 Gemma 自定义许可加门控下载相比是实打实放开，但合规审查别只看根目录有没有那个文件。选闭源 API 则零运维，代价是数据出域和按 token 计费。

指标二：上下文与维度的匹配。 上下文决定单个分块能塞多少内容，维度直接决定存储和检索开销。长文档多、追求少切块，Qwen3-Embedding 的 32,768 上下文占优；端侧或小机器部署，EmbeddingGemma 2 的 270M 纯文本档更现实——同一份权重还有 440M、570M、740M 三档可以按需加载多模态能力。

指标三：MRL 与存储弹性。 EmbeddingGemma 2（768 裁至 128）、Qwen3-Embedding（1024/2560/4096 三档均支持 MRL）、text-embedding-3-large（3072 裁至 256）都支持裁维；BGE-M3 固定 1024 维，但一模三吃，dense、sparse、multi-vector 三种检索形态一个模型全给。裁维的用法是"从低往高试"：先用最低维跑评估，精度不达标再回上一档，存储弹性立刻不一样。

指标四：任务前缀，最容易被忽略的硬要求。 EmbeddingGemma 2 的 task prompt prefixes 是硬要求：查询要拼成 task: {task description} | query: {content}，文档要拼成 title: {title} | text: {content}；retrieval、QA、fact verification、classification、clustering、semantic similarity、code retrieval 七种任务各有专属前缀，具体前缀串以官方模型卡为准。漏掉的后果不是报错，而是静默掉精度——这是第一代就有的成例，第二代沿用同一口径。Qwen3-Embedding 同样主打任务指令前缀，换到这一类模型，前缀拼接必须写进预处理代码，不能靠人肉执行时才想起来。

指标五：生态与流行度。 EmbeddingGemma 2 发布即接入 sentence-transformers 6.1.0+ 与 transformers 5.19.0+，Ollama、llama.cpp、vLLM、MLX 等运行时同步就位；生产部署流行度方面，一份转述 LangChain 与 LlamaIndex 遥测数据的口径给出的排序是 BGE-M3 第一、Qwen3-Embedding 第二、OpenAI text-embedding-3-large 第三。流行度决定了踩坑文档和社区答案的密度，冷门模型的隐性运维成本要计入决策。

三、动手前：新旧双跑对比

决策别拍脑袋，用自己语料上的数据说话。核心做法是让新旧两套模型在同一批真实数据上各自完整跑一遍检索，再对比结果。

先装工具链。EmbeddingGemma 2 需要 sentence-transformers 6.1.0 及以上版本（项目仓库明文地址：github.com/UKPLab/sentence-transformers，也可直接进官方仓库）：

pip install -U "sentence-transformers>=6.1.0"

模型权重在 huggingface.co/google/embeddinggemma-2（模型权重页），Apache 2.0、无需门控，首次加载会自动拉取：

from sentence_transformers import SentenceTransformer

model = SentenceTransformer("google/embeddinggemma-2")

# 查询侧：task 前缀是硬要求，漏掉会静默掉精度
# 七种任务各有专属前缀串，以官方模型卡为准
query = "task: {task description} | query: 员工差旅报销标准是什么"

# 文档侧：title 没有就留空，但格式不能省
docs = ["title: {title} | text: 差旅费应在返程后按时提交发票。"]

q_vec = model.encode([query])
d_vecs = model.encode(docs, truncate_dim=512)  # MRL 裁维：512/256/128 任选

一个细节：查询和文档的 truncate_dim 必须一致，两边维度不同就没法算相似度。

双跑按四步走：第一，新建一个独立 collection，用新模型把同一批文档重嵌一份，旧 collection 原样不动；第二，准备一批人工核过答案的测试查询，覆盖高频问题与历史 bad case；第三，两套 collection 各自跑同一批查询，对比 top-k 命中与排序差异，人工抽检分叉明显的条目；第四，下判断——新模型在真实语料上提升是否明显、裁维后是否还稳。提升不够就停在这一步，这是整个流程里退出成本最低的位置。

双跑还有一个附带好处：它产出的对比数据，就是后面向团队解释换型决策的最好材料。评测榜只能说明模型在公共数据集上的表现，你的语料分布、查询习惯、文档质量，只有自己语料上的双跑数据能回答——拿它说服人，比引用任何一篇评测文章都有力。

四、灰度切流：走流程框架，不拍脑袋

双跑数据过了关，再动线上。灰度切流没有万能比例数字，这里给的是流程框架，每一档放量的尺度以自己业务的指标表现为准：

第一，应用层加路由开关。 检索入口按查询特征分桶，一部分请求走新 collection，其余走旧的。开关必须支持秒级切回，回滚路径在开工前先演练一遍。

第二，从小流量开始观察。 第一档放量只覆盖低风险的查询类型，盯三样东西：检索命中率、端到端延迟、bad case 反馈。任何一档放量，都以上一档指标平稳为前提，指标不稳就停在原档排查。放量节奏宁可慢：嵌入层出问题的暴露往往滞后，问题查询可能要在真实流量里泡上一阵才会浮出来。

第三，按文档域逐块扩。 与其按用户比例切，不如按知识域切：先切语料风格稳定的域，语料混杂、更新频繁的域放最后。这样定位问题时，天然知道该去哪个域找原因。

第四，算清并存的成本。 灰度期新旧两套向量并存，存储双份、嵌入计算双份，预算和旧库下线时间点要在开工前定好，避免灰度期无限拉长。

灰度期暴露的问题（比如某类查询在新模型下明显变差）要回流到双跑阶段重新验证，而不是硬着头皮放量。

五、全量重嵌：一次过，别留下混合空间

灰度全绿才做这一步，顺序错了前面全白干：

全量重嵌写新 collection。 用新模型把全部文档重嵌，统一前缀、统一 truncate_dim，写入独立的新 collection。切记不要往旧 collection 里混——混合空间是这个领域最难排查的事故，没有之一。

算力不够先把模型跑省。 EmbeddingGemma 2 的 270M 纯文本档在普通硬件上就能跑；更省的路线是量化或本地推理，第一代有 Q8_0 GGUF 经 Ollama 本地运行的成例，第二代生态里 Ollama、llama.cpp、vLLM 在发布当日就已就位。

重嵌完先对账。 文档条数、向量条数、向量维度三处核对一致；再抽查若干条入库向量的原始输入，确认前缀格式没有跑偏——前缀错误是静默错误，对账时数字上看不出来，必须抽查原始输入。

全量切流与旧库退役。 切流完成后，旧 collection 保留一个观察期，期间线上已完全走新库；观察期结束确认无回滚需求，再下线旧 collection 释放成本。观察期长短由自己业务定，原则是覆盖一个完整的语料更新周期。

六、评估闭环：切完不等于完

全量切换不是终点。嵌入模型的效果会随语料和业务演化而漂移，评估必须变成长期机制：把双跑阶段用过的测试查询固化成回归集，每次语料大版本更新后重跑一遍；再用 Ragas、DeepEval 这类评估框架把检索质量指标例行化——指标怎么选、评估集怎么建，评估篇里有完整方法。

闭环的价值不止于防守：下一次要不要换模型、什么时候换，靠的就是这份长期积累的对比数据。毕竟换嵌入模型的成本永远是全库重嵌，手里有数据的人，才有资格把决策做对。

如果团队里有多条业务线共用同一个嵌入服务，评估还要按业务线分别看：同一套向量空间，对不同业务的语料友好程度可能完全不同，整体均值好看不等于每条线都健康，按线拆分指标才能暴露真实的短板。

常见问题

Q1: 换嵌入模型后，新旧向量能混在一个 collection 里用吗？

不能。不同模型的向量各自定义在独立的语义空间里，即使维度恰好相同也不可互换，混用后相似度计算完全失真。这也是"换模型等于全库重嵌"的根本原因：迁移对象不是增量，是全库。

Q2: EmbeddingGemma 2 的 task 前缀漏了会怎样？

不会报错，而是静默掉精度：检索质量无声下降，日志里毫无异常。查询侧按 task: {task description} | query: {content} 拼接，文档侧按 title: {title} | text: {content} 拼接，七种任务各有前缀，具体串以官方模型卡为准。上线前抽查入库向量的原始输入，确认前缀没有跑偏。

Q3: MRL 裁维会损失多少精度？

没有统一答案，取决于具体语料和任务。官方口径是 EmbeddingGemma 2 的 768 维可裁至 128 维，向量存储最多省 6 倍；实际掉多少精度必须用自己的双跑数据测，不要拿别人的榜单代替自己的验证。可行做法是逐档裁维跑评估，选精度可接受的最低维。

Q4: 检索效果差，是先加 reranker 还是直接换嵌入模型？

按产线转述口径的经验：先 reranker，再考虑换模型。reranker 在检索结果之后重排，分钟级就能上线；换嵌入模型是全库重嵌的大工程，两者的决策成本不在一个量级。reranker 调完仍不达标，再回到本文的六步流程。

Q5: 中文为主的场景，选型上要额外注意什么？

多语言支持上，EmbeddingGemma 2、Qwen3-Embedding、BGE-M3 均覆盖 100+ 语言，其中 Qwen3-Embedding 以强中文为特色，OpenAI 未公布语言总数。但中文好不等于全维度都好，仍然要回到本文流程：先对表、再双跑，用自己语料的对比数据做决定；MTEB 分数各家自报口径互不可比，不要跨榜单排名。