嵌入模型排行榜

做 RAG 的人常遇到这种情况：照着一份嵌入模型排行榜选了排名靠前的模型，灌进知识库后召回还是不准，换模型又不知道换哪个、换了会不会更差。榜单本身没错，错在它测的任务和你的语料不是一回事。这篇给一套读榜的方法：先分清榜单在测什么，再按语料语言、库规模、查询长短去筛，最后用你自己的问题集跑一遍小规模对照。

做 RAG 的人常遇到这种情况：照着一份嵌入模型排行榜选了排名靠前的模型，灌进知识库后召回还是不准，换模型又不知道换哪个、换了会不会更差。榜单本身没错，错在它测的任务和你的语料不是一回事。名次是别人在别人的数据上跑出来的，你的库里是中文合同、内部工单还是英文论文，差别比榜首和榜尾还大。

这篇不给你一份榜单，而是给你一套读榜的方法：先分清榜单在测什么，再按语料语言、库规模、查询长短去筛，最后用你自己的问题集跑一遍小规模对照。全程只动一个变量，结论才站得住。

排行榜上到底在比什么

打开一份嵌入模型榜单，第一件事不是看第一行是谁，而是看它用的是哪类任务。检索类任务（给一条查询，从一堆段落里找出正确的那条）和语义相似度类任务（判断两句话像不像）测的能力差别很大，一个在中文短句相似度上冒尖的模型，搬到长文档检索里未必还能打。

检索类指标

给查询找段落，最贴近 RAG 主流程，优先看这一类

相似度类指标

判断两句话是否同义，常用于去重和聚类，跟检索名次经常不一致

分类聚类类指标

把句子分堆，适合意图归类，不代表检索排序能力

• 看榜单有没有标注语言与领域：纯英文语料上跑出来的名次，不能直接搬到中文知识库
• 看输入长度限制：你的文档块如果本来就切得长，超出模型上限会被截断，名次再好也白搭
• 看向量维度：维度高往往更准，但存储和检索延迟跟着涨，窄领域里小模型未必输
• 看是否区分对称与非对称任务：查询短、段落长属于非对称，用错任务口径的分数没有参考价值

还有一条经常被忽略：榜单的测试集规模有限，榜首和榜眼之间的差距很可能落在噪声里。与其纠结第一还是第三，不如确认前十里有哪几个支持你的语言和输入长度，把范围缩小到三四个候选就够了。

按你的场景筛，而不是按名次筛

选型的第一步不是看榜，而是把自己这边三个数字写下来：语料主要语言、知识库条数量级、查询是短关键词还是整段问题。这三条一确定，候选范围通常能从几十个缩到几个。

库很大时，向量维度直接影响存储体积和检索延迟，高维模型未必划算。可以先用低维模型把链路跑通，等业务稳定了再评估要不要升级，而不是一上来就押注最贵的那个。另外，纯向量检索碰上长查询容易飘，配一个重排模型，收益往往比换个更贵的嵌入模型更明显，两者的取舍可以结合 /embeddings 里的说明一起判断。

换模型前先做一次小规模对照

榜单只能帮你把候选缩到三四个，真正决定换不换的，是你自己数据上跑出来的那组数字。这件事不需要大动干戈，一两个小时就能有结论，前提是方法别乱。

1. 攒一个小测试集从真实工单、搜索日志或客服记录里抽二三十条查询，手动标出每条应该命中的段落，存成一个表格。数量不用多，覆盖典型问法即可，这一步千万别省。
2. 固定其他变量切分方式、库内容、检索参数全部锁死，只替换嵌入模型重跑一遍。一次只动一个变量，否则分不清提升是谁带来的。
3. 记录三项结果不只是命中率，还要看正确段落在 Top 结果里的位置、以及单次检索耗时。命中率涨了但排到很后面、延迟翻倍，未必是划算的交换。
4. 对比后决定候选模型各跑一遍，选综合最稳的那个；如果新旧差距很小，优先不换，省下重建索引的功夫。

落地时要顺手算的三笔账

模型选定了，事情只做了一半。全量重新嵌入是一次实打实的数据迁移，动手前把下面三笔账算清楚，能避免上线当天才发现磁盘不够或者服务被打满。

• 向量存储：文档量乘以维度就是库的体积量级，换高维模型前先看现有向量库和磁盘余量够不够，扩容成本比模型调用费更隐蔽
• 重建索引的时间：全量重嵌入要把所有文档跑一遍，先估好耗时，再决定是直接替换还是新旧索引并行一段时间
• 调用口径：用托管接口还是本地部署，计费方式、限流额度、是否支持批量提交差别很大，到 /official-api 与 /models 核对当时的规格与计费
• 回滚预案：旧索引别急着删，留一个切换开关，新模型线上表现不对时能几分钟切回去

如果团队里没人专门盯这块，建议把重建索引排到低峰期，并提前用一小批文档做过一次试跑，把实际吞吐量摸出来再排全量计划。这些准备工作看起来琐碎，但比事后救火便宜得多。