选 Embedding 模型，榜单只是入围名单，不是答案。MTEB/MMTEB 能告诉你哪些模型在公开任务上跑得高，但真正决定 RAG 效果的是五个维度：语言覆盖、向量维度与存储成本、上下文长度、 query/document 前缀约定、以及你的吞吐与预算。跳过这五项直接照抄榜首，最常见的结局是”线上效果远不如榜单”。
Hugging Face 在 embeddings 实践手册里把话说得很直白：Embedding quality moves fast — don’t trust a fixed list。下面把选型拆成可执行的判断顺序。
先搞清楚 MTEB 到底在测什么
MTEB（Massive Text Embedding Benchmark）是嵌入模型的标准评测套件，覆盖八大任务类别：
- Retrieval 检索
- Classification 分类
- Clustering 聚类
- Semantic Similarity（STS）语义相似度
- Reranking 重排序
- Pair Classification 、 Summarization 、 Bitext Mining
它的价值在于”广度”：一个在检索上碾压的模型，可能在聚类上很平庸，MTEB 能把这种偏科抓出来。所以它适合做 shortlist，不适合做采购决策。
五个决策维度
| 维度 | 要问的问题 | 不看它的后果 |
|---|---|---|
| 语言 | 语料是否含中文/多语言？是否要跨语言检索？ | 英文强模型在中文上召回断崖式下降 |
| 维度 | 向量维度多少？百万级向量的存储与内存能否承受？ | 4096 维 × 百万条 = 索引体积与成本失控 |
| 上下文长度 | 单个 chunk 最长多少 token？ | 超长 chunk 被截断，语义丢失 |
| 前缀约定 | query 和 document 是否需要不同前缀？ | 前缀写反/漏写，效果静默劣化 |
| 吞吐与成本 | 单位时间要向量化多少 token？GPU 预算多少？ | 离线建索引跑几天几夜 |
维度一：语言优先于分数
中文或中英混合语料，优先选明确支持多语言的模型族（如 multilingual-e5 系列、 bge-m3 、 Qwen3-Embedding 系列等），并在自己的语料上验证。不要因为某个英文模型在 MTEB 英文子集上高两分就选它。
维度二：维度决定存储账单
向量维度直接乘进索引体积。粗略估算：100 万条 1024 维 float32 向量约 4GB 内存/存储，换成 4096 维就是 16GB 。支持 Matryoshka（套娃）表示学习或自带降维能力的模型，可以在损失很小的前提下压缩维度，这类特性在高数据量时非常值钱。
维度三：上下文长度匹配你的切分策略
先定 chunk 大小，再选模型。如果切分策略是 512 token 一块，选一个最大长度 512 的模型才是匹配的；选最大长度 8192 的模型并不能带来收益，反而可能在长文本上浪费算力。
前缀约定：最容易静默翻车的一项
很多检索模型要求 query 和 document 使用不同的前缀，写错不会报错，只会让效果悄悄变差。 Hugging Face 手册里明确提醒：不要相信 model.prompts 属性——当前 sentence-transformers 会给没注册前缀的模型也注入一个空的占位符，导致 e5 、 nomic 、 bge 看起来”不需要前缀”，而真实约定只写在模型卡里。
| 模型族 | Query 前缀 | Document 前缀 |
|---|---|---|
| e5 系列（非 instruct） | query: | passage: |
| nomic | search_query: | search_document: |
| bge 英文系 | Represent this sentence for searching relevant passages: | （无） |
| bge-m3 | （无） | （无） |
验证前缀是否正确的土办法（展开）
吞吐：按 token 估，不按条数估
向量化的吞吐是 token 绑定的，不是行数绑定的。同一模型在短文本上能跑几千行/秒，在长文本上可能只剩几百行/秒——差 3 倍以上。因此估算成本必须换算成总 token 数，任何脱离文本长度的”rows/s”都没有意义。
另外一个反直觉结论：batch size 不是越大越快。实测中 batch 从 128 往上加，吞吐反而单调下降（padding 到最长成员的浪费 + 调度开销）。把 batch 定在 128 附近通常是甜点区。
- 明确语言范围与是否需要跨语言检索，先过滤掉不覆盖的候选。
- 按维度与上下文长度做第二层过滤，并估算百万级向量的存储成本。
- 在 MTEB/MMTEB 榜单上取 3–5 个候选，记录其许可证（商用是否被限制）。
- 读模型卡，确认 query/document 前缀约定，写进代码配置而不是硬编码。
- 用自己的语料与真实 query 做 recall@5 / nDCG@10 小样本评测，只留前两名。
- 压测吞吐：按总 token 数估算建索引时间，确认 batch size 在 128 附近最优。
换模型时的隐藏成本
- 必须全量重建索引：不同模型的向量空间不兼容，混用等于把语义空间搅乱。
- 相似度阈值要重调：新模型的分数分布不同，旧的过滤阈值大概率失效。
- 切分策略可能要跟着改：换了最大长度，chunk 大小也要重新验证。
MTEB 榜单第一名可以直接用于生产吗？
Embedding 模型为什么要区分 query 前缀和 document 前缀？
向量维度是不是越高越好？
更换 Embedding 模型需要重新切片吗？
批量生成向量的 batch size 应该设多大？
相关阅读
本文参考 Hugging Face 的 MTEB 官方博客与 embeddings 实践手册整理，选型维度与检查清单为本站工程实践总结；具体模型排名请以官方榜单当日数据为准。
评论 (0)