选嵌入模型别只看排行榜：五个维度决定你的RAG到底准不准

几乎每个搭 RAG 的团队都会先打开 MTEB 排行榜，看第一名是谁，然后用那个。三个月后检索效果不行，又开始换模型，换完发现提升有限——因为问题往往不在模型排名，而在选型维度选错了。

一、维度与成本：大维度不是免费的

嵌入维度直接决定向量库的存储和内存占用。1024 维和 3072 维，同样的数据量内存差三倍，检索延迟也差一截。不少模型支持降低维度输出（Matryoshka 表示学习），先降到 512 或 256 维试跑，如果检索质量掉得不多，就用低维度，性价比极高。

实践数据：多数中文知识库场景下，1024 维与 3072 维的检索质量差异在 2–4 个百分点内，但成本差异是 3 倍。先测再定，别默认吃满。

二、语言覆盖：中文不是「顺便支持」

很多英文模型宣称支持中文，实际表现是「能编码，但语义颗粒度粗」。中文场景要重点测三件事：

• 近义词与同义改写：把「退款流程」改成「怎么退钱」，能否召回同一篇文档；
• 长实体匹配：中文专有名词、产品型号、人名混在一起的区分度；
• 中英混排：文档里常出现英文术语，模型能否把「LLM 推理延迟」和「大模型响应速度」放在同一语义空间。

建议直接用你自己的 50 条中文 query 做检索测试，这比任何榜单都准。

三、领域适配：通用模型在垂直领域会失灵

法条、医疗术语、工业型号、代码标识符，这些内容在通用训练数据里密度低，嵌入空间会挤在一起。表现就是「检索出来的都很像，但都不是我要的那个」。

两个处理方向：一是选在目标领域继续训练过的模型（如代码、法律、医学有专门的嵌入模型）；二是先做小样本验证，如果 top-5 里连一条正确的都没有，说明领域错配严重，换模型比调参数有用。

四、长度限制：切片策略要和模型对齐

模型的最大输入长度决定了你的切片大小。用 512 token 的模型去吃 2000 token 的切片，后半段会被截断，检索等于随机。

反过来，即使模型支持 8K 长输入，也不代表长切片效果好——信息被稀释后，向量会变得「都不太像」。经验值是：切片控制在 300–600 token，并与模型的训练长度分布对齐，长文档靠多切片+重排序解决，而不是靠喂长文本。

五、版本锁定：模型悄悄升级是隐形事故

这是最容易被忽略的一条。多数嵌入 API 会随模型迭代更新权重，而新权重的向量和旧向量不在同一空间。你今天用新版重新嵌入部分文档，库里就混了两套坐标系，检索结果会变得不可解释。

对策很简单也很重要：把模型版本号写进配置、写进向量库元数据；升级时必须全量重嵌，并保留旧索引做对比；能用固定版本的快照就用快照。这件事没做好，上半年发生过事故的团队不在少数。

六、怎么用一天时间做完评测

不要建复杂评测平台，用最朴素的方法：

1. 从真实日志里抽 50–100 条用户 query；
2. 每条人工标注 1–3 篇应该被检索到的文档；
3. 对每个候选模型计算 Recall@5 和 MRR；
4. 挑前三名，再人工看 20 条实际检索结果，确认「相关性」符合直觉。

这套流程半天能跑完，成本不到一杯咖啡，但比看榜单可靠得多。特别提醒：Recall@5 比准确率更重要，因为后面还有重排序和 LLM 兜底，把对的文档放进候选池是第一关。

结论

选嵌入模型的正确顺序是：先定切片长度和维度预算 → 再筛语言与领域匹配的候选 → 用自有数据跑 Recall@5 → 最后锁版本。榜单只用来生成候选名单，从来不用来做决定。