为什么不能只按 MTEB 排名选 embedding 模型？

MTEB 任务与业务数据分布不同，语言、领域、长度和查询形态都可能不匹配；要在自己的数据上做 recall@k/MRR 评估。

查询和文档的指令前缀不一致会怎样？

向量空间不匹配，查询向量和文档向量不在同一语义空间，召回质量下降；按模型卡使用正确的 query/passage 前缀。

换 embedding 模型后为什么必须重建索引？

不同模型的向量维度和语义空间不同，旧索引无法与新查询向量比较；必须重新生成向量并重建索引。

系统学习 AI 学习路径：从 GPU 运行时到推理、微调与 RAG 评估

embedding-models

嵌入模型选型：按语言、领域、维度、上下文长度和成本做取舍

补充说明

嵌入模型把文本映射成向量，决定 RAG 和语义搜索的召回上限。选型不能只看 MTEB 排名：还要看语言覆盖、领域匹配、最大输入长度、向量维度、是否支持指令前缀、归一化方式、推理成本和许可证。中文/多语言场景优先看 BGE-M3、GTE、E5、Jina 等；英文通用可以看 OpenAI、Cohere、Voyage 等托管模型。

维度影响存储和检索成本：1024 维比 768 维多约 33% 存储，但精度不一定更高；部分模型支持 Matryoshka 截断，可以在精度和成本之间折中。长文档还要看最大 token 数，超过会被截断。

常用示例

# 用 sentence-transformers 本地加载
from sentence_transformers import SentenceTransformer

model = SentenceTransformer("BAAI/bge-m3")
vectors = model.encode(
    ["如何排查磁盘满", "Pod 一直重启"],
    normalize_embeddings=True,
    batch_size=32,
)

# 指令前缀：部分模型需要 query/passage 不同前缀
query = "为这个句子生成表示以用于检索相关问题：磁盘满怎么排查"
doc = "df -h 查看分区使用率，du 统计目录占用"

选型检查清单：
1. 语言：中文、英文、多语言、代码
2. 领域：通用、法律、医疗、金融、代码
3. 最大输入：512/1024/8192 tokens，是否够一个块
4. 维度：768/1024/1536/3072，存储和索引成本
5. 归一化：是否已归一化，相似度用 cosine 还是 dot
6. 部署：本地 GPU/CPU、托管 API、私有化
7. 许可证与成本：商用许可、QPS、token 计费

在业务数据上构造 100–300 条查询-文档对，比较 recall@k 和 MRR；MTEB 只能做初筛。

易错点与排错

只看 MTEB 排名：榜单任务和业务数据分布不同；必须在自己的数据上评估。
语言不匹配：英文模型直接用于中文，召回会明显下降；选多语言/中文模型。
忽略最大输入长度：长块被截断，尾部信息丢失；按模型上限切分或换长上下文模型。
指令前缀不一致：query 和 passage 用了相同/错误前缀，向量空间不匹配；按模型卡说明处理。
归一化不一致：索引时归一化、查询时没归一化，余弦相似度结果错误；统一处理。
维度越高越好：高维增加存储、索引时间和检索成本；用业务评估决定是否截断。
换模型不重建索引：新旧向量空间不兼容，检索结果会乱；换模型必须重建并回归。
忽略成本：托管 embedding 按 token 计费，大批量重刷索引成本高；先估算再迁移。

参考链接

读完自测

合上页面，先回答，再展开对照。

为什么不能只按 MTEB 排名选 embedding 模型？
查询和文档的指令前缀不一致会怎样？
换 embedding 模型后为什么必须重建索引？

答案

MTEB 任务与业务数据分布不同，语言、领域、长度和查询形态都可能不匹配；要在自己的数据上做 recall@k/MRR 评估。
向量空间不匹配，查询向量和文档向量不在同一语义空间，召回质量下降；按模型卡使用正确的 query/passage 前缀。
不同模型的向量维度和语义空间不同，旧索引无法与新查询向量比较；必须重新生成向量并重建索引。