嵌入模型有哪些

做 RAG 的人大多卡在同一个地方：检索效果不好，第一反应是换更大的生成模型，其实问题常常出在嵌入模型上。向量质量不行，后面接多强的模型都是拿着错材料写答案。这篇不排名也不给结论，只把常见嵌入模型按来源和特点分成几类，讲清楚每类适合什么活、什么情况下别选它，并给一套按场景逐步收敛的选型顺序。

做 RAG 的人经常卡在同一个地方：检索效果不好，第一反应是换个更大的生成模型，其实问题常常出在嵌入模型上。向量质量不行，后面接多强的模型都是拿着错材料写答案。先想办法确认到底是召回没捞到，还是生成没写好，再决定要不要动嵌入这一层。

这篇不排名也不给结论，只把常见嵌入模型按来源和特点分成几类，讲清楚每类适合什么活、什么情况下别选它，再给一套按场景逐步收敛的选型顺序。所有具体规格，都得到站内页面核对当时的数字。

先分清嵌入模型在 RAG 里到底干什么

嵌入模型把文本压成向量，负责从库里捞出候选片段；生成模型只负责读这些片段写答案。两者分工明确，出问题的表现也不一样：答非所问多半是召回没捞到，答得啰嗦或者答偏才是生成环节的事。混在一起看，就会误判成模型不够强。

• 一句话定位：嵌入负责快而粗地缩小范围，重排在少量候选里精挑
• 检索差和生成差要分开归因，别一上来就换生成模型
• 什么情况下不用换模型：文档切分太碎、字段没清洗，换什么模型都救不回来
• 判断顺序先看检索返回的原始片段对不对，再看重排，最后才怀疑生成

常见嵌入模型分成哪几类

按来源和部署方式，常见的嵌入模型大致能归成几类。分类的意义在于帮你快速排除不合适的选项，而不是告诉你哪类更好。同一类里不同模型的实际表现，得用自己的数据试。

托管类省运维，代价是按量计费和受平台可用性影响；自部署类把控制权拿回来，代价是机器和运维。多语言优化的模型在中文短查询上通常更稳，但如果你的库和用户都只用英文，就没必要为此额外付出代价。专门训练的模型也一样，得先确认你的检索形态和它的训练目标对得上。

选型时按顺序问自己五个问题

按下面这个顺序问，前面的答案会直接砍掉后面一大半选项。每问的切入点是固定的，具体模型规格到站内模型库核对当时的数字，别凭印象做决定。

1. 第一问语种库里文档和用户提问主要是什么语言，跨语言检索算不算刚需。跨语言是刚需就优先看多语言优化那类。
2. 第二问部署边界数据能不能出内网。不能出，就只剩可自部署这一条路，托管类直接排除。
3. 第三问规模和预算向量库多大、每天查多少次。量大时自部署的固定成本才摊得平，量小就别背上运维负担。
4. 第四问维度与存储维度越高存储和检索越贵。具体数值到站内嵌入模型页看每家的实际规格，别凭印象选。
5. 第五问有没有重排如果已经上了重排，嵌入模型的边际收益会变小，先别急着换。

怎么用自己数据验证，而不是看榜单

榜单上的名次是在别人的数据上算出来的，和你库里的文档形态、查询长度、行业词都不一样。唯一能信的办法是自己搭一个小测试集。规模不用大，二三十条真实问题就够看出差别。

• 准备二三十条真实问题，人工标出每条对应的正确片段
• 对比时只换嵌入模型，切分、重排、生成模型全部保持不变
• 看正确片段有没有进前几名，以及同样库里检索耗时有没有明显变化
• 语料极少或全是短句时，几个模型的差距可能落在噪声范围，优先补语料而不是换模型
• 换完保留旧向量库或旧索引一段时间，别做完就删

测试集不用做得很正式，一张表记下问题、正确片段、每个模型的命中位置就行。比的是相对差异，不是绝对分数。

几个容易踩的坑和排查顺序

大多数「换模型没效果」的情况，问题不在模型本身。下面几个坑按出现频率排，先自查再动手换。

排查顺序固定：先看检索返回的原始片段对不对，再看重排有没有把好片段压下去，最后才怀疑生成模型。具体模型的规格与价格，到站内嵌入模型页和模型库核对当时的数字，不要拿记忆里的旧信息做决定。