RAG 中如何选择 Embedding 模型

在 RAG（Retrieval-Augmented Generation，检索增强生成）系统中，Embedding 模型负责把文本转换成向量，然后通过向量之间的相似度找到与用户问题相关的文档。

因此，Embedding 模型选得好不好，会直接影响 RAG 的召回效果。

很多人在选择 Embedding 时只看模型排行榜或者向量维度，其实真正需要考虑的是：语言、业务领域、向量维度、输入长度，以及实际召回效果。

一、先搞清楚 Embedding 到底在做什么

Embedding 可以简单理解成：

文本 ↓ Embedding 模型 ↓ 向量

例如：

小猫在吃鱼 ↓ [0.12, -0.35, 0.71, ...]

Embedding 的核心不是简单地把文字变成数字，而是希望语义相近的文本，在向量空间中的距离也比较近。

例如：

小猫在吃鱼 猫咪正在进食鱼肉 汽车在高速公路行驶

前两个句子的意思比较接近，因此对应向量通常也比较接近；第三句话和前两个语义差异较大，对应向量距离也会更远。

这就是 RAG 中语义检索的基础。

Embedding 和关键词检索有什么区别？

传统关键词检索，例如 BM25，更关注关键词是否出现。

比如用户搜索：

猫咪吃鱼

而文档中写的是：

小猫正在进食鱼肉

两个文本虽然意思接近，但关键词并不完全一致，单纯依靠关键词检索可能无法很好地匹配。

Embedding 则更加关注语义：

猫咪吃鱼 ≈ 小猫进食鱼肉

所以 RAG 通常会使用向量检索。

不过 Embedding 也不是万能的。对于产品型号、编号、专业术语、错误代码等内容，关键词检索反而可能更准确。

因此实际项目中比较常见的方案是：

用户 Query ↓ ┌──────────────┐ │ 向量语义检索 │ ├──────────────┤ │ BM25关键词检索│ └──────────────┘ ↓ Hybrid Search ↓ Rerank ↓ LLM

二、选择 Embedding 主要看这几个指标

1. 首先看语言和业务场景

这是选择模型最重要的一步。

如果主要处理中文知识库，那么应该优先考虑中文能力较好的模型，例如：

• BGE
• GTE
• M3E
• Jina Embeddings
• E5

例如中文 RAG 项目中经常使用 BGE 系列：

bge-small-zh bge-base-zh bge-large-zh

但是不要简单理解成：

中文项目 = 一定选择 BGE

真正应该比较的是你的业务数据上的召回效果。

例如：

通用中文问答 企业内部知识库 医疗文档 法律文档 电力行业文档 机械设备说明书 高校课程资料

不同领域的最佳模型可能并不一样。

所以模型排行榜只能作为第一轮筛选依据，不能直接作为最终选择依据。

2. 再看向量维度

不同 Embedding 模型输出的向量维度不同。

例如：

BGE-small → 384维 BGE-base → 768维 BGE-large → 1024维

维度越高，并不意味着一定越好。

高维向量通常能够表达更多信息，但同时也会带来更高的存储和计算成本。

例如有 100 万个 Chunk：

768维 × 100万

和：

1024维 × 100万

后者需要存储更多数据，向量索引和检索成本也会增加。

因此实际项目中不要为了追求更高维度直接选择大模型。

比较合理的思路是：

先选择一个效果和性能比较平衡的模型 ↓ 跑自己的召回测试 ↓ 效果不够再升级模型

而不是：

维度越高 ↓ 一定越好

3. 注意最大输入长度

Embedding 模型通常存在最大输入长度限制。

例如模型可能只支持：

512 tokens

如果一个 Chunk 远远超过模型支持的长度，就需要提前进行文本切分。

所以 Embedding 模型实际上会影响 Chunk 的设计。

例如：

原始 PDF ↓ 文本提取 ↓ Chunk 切分 ↓ Embedding

如果模型输入长度较短，那么 Chunk 就不能无限增大。

但也不能认为：

Embedding 支持的长度越长越好。

因为 Chunk 过长以后，里面可能包含很多不同主题的信息，最终得到的向量可能出现语义稀释。

例如：

Chunk A： 介绍产品型号、安装方式、故障代码、售后政策……

用户只问：

这个产品出现 E03 故障怎么办？

这么大的 Chunk 虽然没有超过模型最大长度，但语义已经比较分散。

所以 Embedding 模型选择和 Chunk 切分应该一起考虑。

三、不要只看排行榜，真正应该测试 Recall@K

这是 Embedding 选型中最容易被忽略的一点。

MTEB、C-MTEB 等排行榜可以帮助我们了解模型的大致能力，但不能直接说明：

这个模型放到我的 RAG 项目里一定最好。

原因很简单：

公开测试集 ≠ 你的业务数据

假设你正在做一个工业设备知识库。

你的数据可能包含：

设备说明书 维修手册 故障代码 技术参数 操作规程 内部培训资料

某个模型在通用中文数据集上排名第一，并不代表它一定最擅长理解这些专业内容。

所以真正可靠的方法是自己建立一套测试集。

例如：

Query： 设备出现 E03 故障应该如何处理？ 正确文档： 设备维修手册-故障处理-第12页

然后分别使用不同 Embedding 模型进行召回：

模型A → Top 5 是否找到正确文档？ 模型B → Top 5 是否找到正确文档？ 模型C → Top 5 是否找到正确文档？

重点关注：

Recall@K

例如：

Recall@5 = 90%

可以简单理解为：

正确资料是否能够进入前 5 个召回结果。

对于 RAG 来说，这是非常重要的指标。

因为：

正确资料没有被召回 ↓ LLM 根本看不到 ↓ 后面再强也无法凭空找到

所以 RAG 的问题很多时候不是模型不会回答，而是：

前面的检索没有把正确资料找出来。

四、实际项目中怎么选 Embedding

可以按照下面的流程来做。

第一步：确定业务数据

先弄清楚自己的知识库是什么：

中文 / 英文 / 多语言？ 通用知识 / 垂直领域？ 短文本 / 长文档？ 是否包含大量专业术语？ 是否包含产品型号、编号、代码？

第二步：筛选 2～4 个候选模型

例如中文 RAG 可以先选择：

BGE GTE M3E Jina Embeddings

不需要一开始测试十几个模型。

第三步：统一 RAG 参数

测试的时候必须保持其他条件一致：

相同数据 相同 Chunk 相同 Query 相同 Top-K 相同向量数据库 相同相似度算法

只替换 Embedding 模型。

否则最后无法判断到底是哪一个因素导致结果变化。

第四步：统计召回效果

可以记录：

如果 Model C 的效果只比 Model B 高一点，但延迟和资源消耗明显增加，那么 Model B 可能更加适合生产环境。

所以最终选择不是：

谁的排行榜最高就用谁。

而是：

在自己的数据上，效果、速度、成本综合最合适的模型。

五、一些实际项目中的经验

1. 不要只依赖向量检索

Embedding 对语义搜索非常有效，但对于下面这些内容：

产品型号 错误代码 订单编号 文件编号 版本号 专业缩写

关键词搜索往往更加可靠。

所以实际 RAG 中经常采用：

Embedding + BM25 + Rerank

也就是：

Query ↓ Hybrid Search ↓ 初步召回 ↓ Reranker ↓ 最终 Top-K ↓ LLM

2. 不要一开始就追求最大的 Embedding 模型

如果项目刚开始，可以先使用一个效果和性能比较平衡的模型建立基线。

例如：

先跑通 RAG ↓ 建立测试集 ↓ 统计 Recall@K ↓ 发现召回效果不足 ↓ 再换更大的 Embedding

这样比一开始就上最大的模型更加合理。

3. Chunk 和 Embedding 必须一起调

Embedding 选得再好，如果 Chunk 切得很差，最终召回效果一样可能很差。

例如：

Chunk 太大 → 一个向量包含太多主题 → 语义不集中 Chunk 太小 → 上下文信息不完整 → 检索到的内容缺少上下文

所以实际调 RAG 时，不应该只调 Embedding。

通常应该一起测试：

Embedding 模型 + Chunk 大小 + Chunk overlap + 检索 Top-K + Rerank

总结

Embedding 模型选择可以简单归纳成四句话：

第一，看语言和业务领域 第二，看向量维度和输入长度 第三，用自己的数据测试 Recall@K 第四，结合效果、速度和成本做最终选择

完整的 RAG 检索链路可以理解为：

文档 ↓ Chunk 切分 ↓ Embedding ↓ 向量数据库 ↓ 用户 Query ↓ Query Embedding ↓ 向量检索 / BM25 ↓ Hybrid Search ↓ Rerank ↓ 相关文档 ↓ LLM ↓ 最终答案

其中 Embedding 只是整个检索链路的一环。

不要把“选择 Embedding 模型”理解成单独选一个模型的问题。真正的目标是让 Query 能够稳定地找到正确的 Chunk。

因此，对于实际 RAG 项目来说，最可靠的选型标准不是模型名字，也不是排行榜，而是：

在自己的业务数据上，谁能够用更低的成本把正确资料稳定召回，谁就是更适合自己的 Embedding 模型。