RAG 链路里，大家把注意力给了大模型和向量数据库，嵌入模型往往随手选一个榜上靠前的。但嵌入模型有个特殊性：它决定了库里的每一个向量，而换它意味着全部重来。这让它更像一次数据库 schema 决策，而不是一次模型选型。

一、看榜之前先看三件事

MTEB 类榜单当然有参考价值，但直接照着第一名选会踩坑：

• 语言覆盖。很多高分行模型是英文单语或英文为主。中文语料要看 C-MTEB 或自己的评测；多语场景更麻烦——query 和文档语言不一致时，跨语言检索质量差异巨大。
• 长文本。嵌入模型有最大输入长度，8k 和 512 的差别直接决定切分策略：512 的模型被迫把一篇文档剁碎，上下文信息全靠切块技巧弥补。
• 维度与存储。维度越高通常越准，但百万级向量下，1024 维比 384 维多出的不只是精度，还有内存和索引构建时间。Matryoshka（套娃）类模型支持截断到低维使用，是很实用的折中。

二、评测要用自己的数据

公开榜单是别人的语料分布。真正该做的评测很小成本：拿一百条真实用户 query、几百篇真实文档，人工标注哪些文档是正确答案，然后对比两三个候选模型的召回率。半天的工作量，换来的是你自己的榜单——它比 MTEB 前二十名加起来都管用。

评测时还要看两个容易忽略的维度：相似度分布是否拉得开（好坏文档分数挤在一起，阈值就没法设），以及检索速度与索引占用。

三、重嵌入：被低估的成本

这是嵌入选型的隐藏条款。换嵌入模型时：

1. 全量重建向量库——文档要全部重新过一遍模型，按千万级文档算，这是实打实的 API 账单或 GPU 时间；
2. 索引重 建——HNSW 这类索引要推倒重来，期间服务要么降级要么双写；
3. 阈值与下游全部重调——相似度分布变了，原来调好的 cutoff、重排序参数、甚至 prompt 里的引用格式都可能要动。

所以选型时看「供应商存活周期」不是玩笑：一个停止维护的嵌入模型，是一笔挂在账上的迁移债。相对保守的策略是选广泛使用、有多家托管、且开源权重可自部署的模型，把「能自己跑」当成退出保险。

四、混合检索当缓冲

另一个降低单点依赖的办法是混合检索：BM25 关键词检索加向量检索并行，用 RRF 融合。它既补了嵌入模型在专有名词、型号、代码标识符上的短板，也让「嵌入模型质量波动」不再一票否决整个检索质量。

小结

嵌入模型选型的正确姿势：用自己的数据测，把维度和语言约束摆在前，把重嵌入成本当决策变量，并留一条自部署的退路。它不是链路里最亮眼的组件，却是最难换的那个。

说明：本文为公开资料的整理与评述，信息来源包括主流嵌入模型的技术报告、MTEB/C-MTEB 榜单说明与向量数据库官方文档，数据以各官方原文为准。本文由 AI 辅助整理，不构成技术选型或投资建议。