embedding 模型 排行榜

做 RAG 或语义搜索时，你多半搜过「embedding 模型 排行榜」，翻到几个榜单却发现口径不一样、名次还互相打架。这篇不给你答案，给你一套判断方法：榜该怎么读、哪些指标跟你业务有关、怎么用自己的一小份数据复现一遍，最后落到选型动作上。

做 RAG 或者语义搜索，选 embedding 模型这一步基本躲不掉。你多半也搜过「embedding 模型 排行榜」，翻到几个榜单却发现口径不一样、名次还互相打架。这篇不打算给你一个标准答案，而是给一套判断方法：榜单该怎么读、哪些指标跟你业务有关、怎么拿自己的一小份数据复现一遍，最后落到选型和降级动作上。

先说清一个前提——榜单的价值是帮你缩小候选范围，不是替你拍板。真正决定效果的是你的数据分布、查询形态和检索链路，这些榜单都不知道。所以下面的顺序是：先看懂口径，再挑指标，再自测，最后才做取舍。

榜单先看口径，再排名次

同一个模型在两个榜单上一个靠前一个靠后，通常是任务集不一样，而不是谁测错了。先确认这个榜单测的是语义相似度、检索排序，还是分类聚类，任务类型跟你对不上，名次就没有参考价值。

• 不同榜单的任务集不一样：有的偏语义相似度、有的偏检索排序、有的偏分类聚类，任务对不上就别比名次
• 注意是零样本还是微调后成绩，微调过的分数不能直接拿来当通用能力用
• 看榜单有没有写清向量维度、是否截断、距离度量，这几项不同会让同一模型分数差出一截
• 到 /embeddings 对照站内整理的模型规格，再去 /benchmarks 看榜单来源，两边对不上就以规格为准

跟你的业务真正相关的几个指标

总分高不等于你的场景好。检索类应用里，能不能把正确片段捞回前几条，几乎决定了下游大模型能不能答对。下面这几项建议按你业务的实际权重排个序，别平均用力。

这几项不是越高越好，而是要在你的约束下取平衡。维度高往往带来更好的区分度，但索引更大、内存更贵；小团队要先把这笔账算清楚，再去 /price-watch 核对当时的调用价格，把单价和向量条数乘出来看总成本。

拿自己的数据跑一遍：可执行清单

公开榜单只能筛掉明显不合适的，最终还得用你自己的数据说话。好消息是这件事不需要很大的工程量，一小份标注数据就够看出趋势。下面这套流程可以直接照着做。

1. 建私有评测集准备 50-200 条真实 query 和它对应的正确片段，标好答案落在哪。规模不用大，但要覆盖你线上最常见的几种问法，偏门问法可以少放几条。
2. 两个候选各建一次索引同一批文本分别用两个候选模型建索引，切分方式、检索条数等其余参数保持一致，只换模型这一个变量，否则比出来的差异说不清是谁造成的。
3. 只比两个数比 Recall@k 和最终答对率。前者看模型本身会不会漏，后者看整条链路能不能答对。两个数一起看，能区分是模型问题还是提示词问题。
4. 顺手量接口表现用 /tools/speed-test 测一下批量向量化的耗时和失败率。离线指标再好，接口慢或者频繁失败一样上不了线，这一项经常被忽略。
5. 结果沉淀成对照表把模型、参数、两个指标记成一张表。下次换模型直接跑同一套用例，不用每次从零重来。

这里有个容易踩的坑：评测集如果全是同一种句式，换哪个模型分数都差不多，看不出差异。尽量让 query 覆盖短句、长句、带错别字的口语问法，这样模型的真实差距才会暴露出来。

选型与降级：怎么定，什么时候不适用

测完之后就是取舍。做法是先把业务权重定下来：以召回为主就优先召回率，以成本为主就优先维度和单价，两者冲突时问自己一句——线上的失败更多是「没捞回来」还是「答得太贵」。

• 别只选一个模型，准备主选加备选两条路，主选限流或涨价时能切换
• 维度不同不能直接换，换模型意味着重新建库，要提前把重建流程和耗时估出来
• 把评测脚本和数据集留在仓库里，做成可重复执行的流程，而不是一次性实验
• 定期回看榜单，模型迭代快，但每次回看都走一遍上面的自测流程，别只看名次变化

什么情况下别照榜单选？数据量很小、query 是关键词式短句，或者你已经有一套成熟的关键词检索，这时候向量模型带来的收益有限，加进来反而多一层维护成本。先去 /ai-dict 把相关概念对齐，判断清楚自己的瓶颈到底在不在语义匹配上，再决定要不要上。