text-embedding模型有哪些

做 RAG 或语义搜索时，卡点往往不是「有没有模型」，而是「我该选哪个、怎么比较、换掉旧的要动多少东西」。这篇不堆名词，先把选型维度列成表，再给一条从试跑到上线的动作清单：怎么定基线、怎么小样本对比、切换时改哪几处配置，以及什么情况下这套思路不适用。

做 RAG 或者语义搜索的时候，真正卡人的从来不是「有没有模型可用」，而是站在一堆名字前面不知道挑哪个，以及哪天想换掉旧的，得动多少东西。这篇不打算给你背名词，先把选型的比较维度摊开，再给一条从试跑到上线的动作清单：怎么定基线、怎么用小样本对比、切换时改哪几处配置，以及什么情况下这套思路根本用不上。

全文不会出现任何具体数字，价格、跑分、版本号这类东西时效性太强，写死了反而误导你。需要看当时的实际情况，直接去站内对应页面核对，本文只负责把「该看什么、该怎么比」讲清楚。

选之前先固定几个比较维度

很多人选型的第一个错误，是拿一个大模型硬扛所有场景。语义检索、聚类去重、分类打标、推荐召回，对向量的要求其实不一样：检索看重的是「相关的排前面」，分类看重的是「同类聚得紧」，两者对维度和距离度量的偏好并不一致。先想清楚你要解决的是哪一类问题，再去挑模型，能省掉一半来回。

把维度当成一项成本来看会更有感觉：维度越高，向量库占的存储越大，检索时的计算也越重。如果你的向量库支持改维度、也支持降维，那选型时可以宽松一点；如果维度一旦建库就锁死，那选模型前务必先确认这一点，否则后面换模型会变成一次全库重建。

常被提到的几类文本嵌入模型

闭源商用接口

不公开权重，按调用量计费，接入方式基本是 HTTP 接口，适合不想自己运维、要稳的场景

开源权重

可以本地部署或托管跑，数据不必出内网，适合调用量大、数据敏感的团队，代价是要自己承担运维和扩容

多语言/跨语言模型

做中英混合语料、跨境业务时才真正需要，纯中文语料用它不一定划算

对话模型顺带的向量能力

接入方便，但通常不是为检索优化的，做小规模验证可以，正式检索一定要单独测过再定

这里刻意不列具体品牌和型号，第一是这类名单变动快，第二是每个团队真正可用的候选受私有化、合规、已有云厂商关系影响很大，别人能用的你未必能用。想知道当时市面上在售的都有哪些、各家口径怎么标，去站内的嵌入模型列表页对一遍再定候选，别凭记忆列清单。

• 先从你的底线条件里筛出可用的一批，通常剩下 2 到 4 个就够了
• 再看语言和输入长度是否卡你的真实语料，卡就直接排除
• 最后才比维度和计费口径，前两步就出局的不用浪费精力
• 拿不准的先记进候选表，别急着下结论，等下的小样本对照环节来分胜负

没有榜单也要能自己比：三步小样本对照

外部的评测榜单参考价值有限，因为它测的语料和你的业务语料往往不是一回事。更靠得住的办法是自己搭一个小评测集，规模不用大，但要真实。评测方法上的细节，站内有专门讲嵌入模型评测方法的文章，这里只给可直接执行的三步。

1. 备一份自己的评测集从真实文档里切出几十条切片，再配二十条左右真实用户会问的问题，人工标出每个问题应该召回哪几条。这份标注就是后面唯一的裁判，标得认真比标得多重要。
2. 同一批数据跑两到三个候选切片策略、问题、评测集全部保持一致，只换模型。只看一个指标：该被召回的内容有没有出现在前几条。同时把延迟和单次调用成本一起记下来，长文档还要额外观察一条长文本会被切成几片。
3. 结果不稳就换一批问题重跑如果两个候选的差距很小，说明这点差异可能是评测集太小带来的噪声，换一批问题重跑。只看一次的结果别当成定论，尤其是只测了十几条的时候。

换模型时要动哪些地方：一份清单

换模型之所以比想象中麻烦，根子在向量空间不通用。不同模型对同一句话生成的向量，方向和尺度都对不上，新旧向量混在一个库里，检索结果会变得莫名其妙。所以核心原则只有一条：切换时整库重算，不要想着增量补。

• 向量必须全量重算，旧索引和新索引不要混用
• 配置里通常有三处要改：模型名、接口地址、向量维度，维度对不上是最常见的报错来源
• 改完先跑一遍检索连通性验证，确认返回条数和字段正常，再考虑放真实流量
• 保留旧索引一段时间做回滚，确认新结果稳定后再清理；调用日志里把模型名带上，方便事后复盘

这里有个容易被忽略的点：如果你的向量库维度是建库时固定的，那么换模型可能意味着新建一个集合而不是原地更新。动手前先去确认向量库这条限制，能避免做到一半才发现要迁移数据。

这些情况下别急着换模型

换个模型就能救召回，这个念头在实操里经常是错的。下面这几种情况，先解决别的问题比换模型更值。

反过来说，如果上面的问题你都排除了，评测集也显示新模型在老问题上稳定更好，那切换是合理的。唯一别做的是夹在中间反复横跳——每次换都重建一遍索引，团队会被折腾得没脾气。