RAG 中如何选择 Embedding 模型在 RAGRetrieval-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. 首先看语言和业务场景这是选择模型最重要的一步。如果主要处理中文知识库那么应该优先考虑中文能力较好的模型例如BGEGTEM3EJina EmbeddingsE5例如中文 RAG 项目中经常使用 BGE 系列bge-small-zh bge-base-zh bge-large-zh但是不要简单理解成中文项目 一定选择 BGE真正应该比较的是你的业务数据上的召回效果。例如通用中文问答 企业内部知识库 医疗文档 法律文档 电力行业文档 机械设备说明书 高校课程资料不同领域的最佳模型可能并不一样。所以模型排行榜只能作为第一轮筛选依据不能直接作为最终选择依据。2. 再看向量维度不同 Embedding 模型输出的向量维度不同。例如BGE-small → 384维 BGE-base → 768维 BGE-large → 1024维维度越高并不意味着一定越好。高维向量通常能够表达更多信息但同时也会带来更高的存储和计算成本。例如有 100 万个 Chunk768维 × 100万和1024维 × 100万后者需要存储更多数据向量索引和检索成本也会增加。因此实际项目中不要为了追求更高维度直接选择大模型。比较合理的思路是先选择一个效果和性能比较平衡的模型 ↓ 跑自己的召回测试 ↓ 效果不够再升级模型而不是维度越高 ↓ 一定越好3. 注意最大输入长度Embedding 模型通常存在最大输入长度限制。例如模型可能只支持512 tokens如果一个 Chunk 远远超过模型支持的长度就需要提前进行文本切分。所以 Embedding 模型实际上会影响 Chunk 的设计。例如原始 PDF ↓ 文本提取 ↓ Chunk 切分 ↓ Embedding如果模型输入长度较短那么 Chunk 就不能无限增大。但也不能认为Embedding 支持的长度越长越好。因为 Chunk 过长以后里面可能包含很多不同主题的信息最终得到的向量可能出现语义稀释。例如Chunk A 介绍产品型号、安装方式、故障代码、售后政策……用户只问这个产品出现 E03 故障怎么办这么大的 Chunk 虽然没有超过模型最大长度但语义已经比较分散。所以 Embedding 模型选择和 Chunk 切分应该一起考虑。三、不要只看排行榜真正应该测试 RecallK这是 Embedding 选型中最容易被忽略的一点。MTEB、C-MTEB 等排行榜可以帮助我们了解模型的大致能力但不能直接说明这个模型放到我的 RAG 项目里一定最好。原因很简单公开测试集 ≠ 你的业务数据假设你正在做一个工业设备知识库。你的数据可能包含设备说明书 维修手册 故障代码 技术参数 操作规程 内部培训资料某个模型在通用中文数据集上排名第一并不代表它一定最擅长理解这些专业内容。所以真正可靠的方法是自己建立一套测试集。例如Query 设备出现 E03 故障应该如何处理 正确文档 设备维修手册-故障处理-第12页然后分别使用不同 Embedding 模型进行召回模型A → Top 5 是否找到正确文档 模型B → Top 5 是否找到正确文档 模型C → Top 5 是否找到正确文档重点关注RecallK例如Recall5 90%可以简单理解为正确资料是否能够进入前 5 个召回结果。对于 RAG 来说这是非常重要的指标。因为正确资料没有被召回 ↓ LLM 根本看不到 ↓ 后面再强也无法凭空找到所以 RAG 的问题很多时候不是模型不会回答而是前面的检索没有把正确资料找出来。四、实际项目中怎么选 Embedding可以按照下面的流程来做。第一步确定业务数据先弄清楚自己的知识库是什么中文 / 英文 / 多语言 通用知识 / 垂直领域 短文本 / 长文档 是否包含大量专业术语 是否包含产品型号、编号、代码第二步筛选 24 个候选模型例如中文 RAG 可以先选择BGE GTE M3E Jina Embeddings不需要一开始测试十几个模型。第三步统一 RAG 参数测试的时候必须保持其他条件一致相同数据 相同 Chunk 相同 Query 相同 Top-K 相同向量数据库 相同相似度算法只替换 Embedding 模型。否则最后无法判断到底是哪一个因素导致结果变化。第四步统计召回效果可以记录模型Recall3Recall5Recall10平均延迟Model A82%89%94%30msModel B85%92%96%45msModel C87%94%97%80ms如果 Model C 的效果只比 Model B 高一点但延迟和资源消耗明显增加那么 Model B 可能更加适合生产环境。所以最终选择不是谁的排行榜最高就用谁。而是在自己的数据上效果、速度、成本综合最合适的模型。五、一些实际项目中的经验1. 不要只依赖向量检索Embedding 对语义搜索非常有效但对于下面这些内容产品型号 错误代码 订单编号 文件编号 版本号 专业缩写关键词搜索往往更加可靠。所以实际 RAG 中经常采用Embedding BM25 Rerank也就是Query ↓ Hybrid Search ↓ 初步召回 ↓ Reranker ↓ 最终 Top-K ↓ LLM2. 不要一开始就追求最大的 Embedding 模型如果项目刚开始可以先使用一个效果和性能比较平衡的模型建立基线。例如先跑通 RAG ↓ 建立测试集 ↓ 统计 RecallK ↓ 发现召回效果不足 ↓ 再换更大的 Embedding这样比一开始就上最大的模型更加合理。3. Chunk 和 Embedding 必须一起调Embedding 选得再好如果 Chunk 切得很差最终召回效果一样可能很差。例如Chunk 太大 → 一个向量包含太多主题 → 语义不集中 Chunk 太小 → 上下文信息不完整 → 检索到的内容缺少上下文所以实际调 RAG 时不应该只调 Embedding。通常应该一起测试Embedding 模型 Chunk 大小 Chunk overlap 检索 Top-K Rerank总结Embedding 模型选择可以简单归纳成四句话第一看语言和业务领域 第二看向量维度和输入长度 第三用自己的数据测试 RecallK 第四结合效果、速度和成本做最终选择完整的 RAG 检索链路可以理解为文档 ↓ Chunk 切分 ↓ Embedding ↓ 向量数据库 ↓ 用户 Query ↓ Query Embedding ↓ 向量检索 / BM25 ↓ Hybrid Search ↓ Rerank ↓ 相关文档 ↓ LLM ↓ 最终答案其中 Embedding 只是整个检索链路的一环。不要把“选择 Embedding 模型”理解成单独选一个模型的问题。真正的目标是让 Query 能够稳定地找到正确的 Chunk。因此对于实际 RAG 项目来说最可靠的选型标准不是模型名字也不是排行榜而是在自己的业务数据上谁能够用更低的成本把正确资料稳定召回谁就是更适合自己的 Embedding 模型。
RAG 中如何选择 Embedding 模型
RAG 中如何选择 Embedding 模型在 RAGRetrieval-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. 首先看语言和业务场景这是选择模型最重要的一步。如果主要处理中文知识库那么应该优先考虑中文能力较好的模型例如BGEGTEM3EJina EmbeddingsE5例如中文 RAG 项目中经常使用 BGE 系列bge-small-zh bge-base-zh bge-large-zh但是不要简单理解成中文项目 一定选择 BGE真正应该比较的是你的业务数据上的召回效果。例如通用中文问答 企业内部知识库 医疗文档 法律文档 电力行业文档 机械设备说明书 高校课程资料不同领域的最佳模型可能并不一样。所以模型排行榜只能作为第一轮筛选依据不能直接作为最终选择依据。2. 再看向量维度不同 Embedding 模型输出的向量维度不同。例如BGE-small → 384维 BGE-base → 768维 BGE-large → 1024维维度越高并不意味着一定越好。高维向量通常能够表达更多信息但同时也会带来更高的存储和计算成本。例如有 100 万个 Chunk768维 × 100万和1024维 × 100万后者需要存储更多数据向量索引和检索成本也会增加。因此实际项目中不要为了追求更高维度直接选择大模型。比较合理的思路是先选择一个效果和性能比较平衡的模型 ↓ 跑自己的召回测试 ↓ 效果不够再升级模型而不是维度越高 ↓ 一定越好3. 注意最大输入长度Embedding 模型通常存在最大输入长度限制。例如模型可能只支持512 tokens如果一个 Chunk 远远超过模型支持的长度就需要提前进行文本切分。所以 Embedding 模型实际上会影响 Chunk 的设计。例如原始 PDF ↓ 文本提取 ↓ Chunk 切分 ↓ Embedding如果模型输入长度较短那么 Chunk 就不能无限增大。但也不能认为Embedding 支持的长度越长越好。因为 Chunk 过长以后里面可能包含很多不同主题的信息最终得到的向量可能出现语义稀释。例如Chunk A 介绍产品型号、安装方式、故障代码、售后政策……用户只问这个产品出现 E03 故障怎么办这么大的 Chunk 虽然没有超过模型最大长度但语义已经比较分散。所以 Embedding 模型选择和 Chunk 切分应该一起考虑。三、不要只看排行榜真正应该测试 RecallK这是 Embedding 选型中最容易被忽略的一点。MTEB、C-MTEB 等排行榜可以帮助我们了解模型的大致能力但不能直接说明这个模型放到我的 RAG 项目里一定最好。原因很简单公开测试集 ≠ 你的业务数据假设你正在做一个工业设备知识库。你的数据可能包含设备说明书 维修手册 故障代码 技术参数 操作规程 内部培训资料某个模型在通用中文数据集上排名第一并不代表它一定最擅长理解这些专业内容。所以真正可靠的方法是自己建立一套测试集。例如Query 设备出现 E03 故障应该如何处理 正确文档 设备维修手册-故障处理-第12页然后分别使用不同 Embedding 模型进行召回模型A → Top 5 是否找到正确文档 模型B → Top 5 是否找到正确文档 模型C → Top 5 是否找到正确文档重点关注RecallK例如Recall5 90%可以简单理解为正确资料是否能够进入前 5 个召回结果。对于 RAG 来说这是非常重要的指标。因为正确资料没有被召回 ↓ LLM 根本看不到 ↓ 后面再强也无法凭空找到所以 RAG 的问题很多时候不是模型不会回答而是前面的检索没有把正确资料找出来。四、实际项目中怎么选 Embedding可以按照下面的流程来做。第一步确定业务数据先弄清楚自己的知识库是什么中文 / 英文 / 多语言 通用知识 / 垂直领域 短文本 / 长文档 是否包含大量专业术语 是否包含产品型号、编号、代码第二步筛选 24 个候选模型例如中文 RAG 可以先选择BGE GTE M3E Jina Embeddings不需要一开始测试十几个模型。第三步统一 RAG 参数测试的时候必须保持其他条件一致相同数据 相同 Chunk 相同 Query 相同 Top-K 相同向量数据库 相同相似度算法只替换 Embedding 模型。否则最后无法判断到底是哪一个因素导致结果变化。第四步统计召回效果可以记录模型Recall3Recall5Recall10平均延迟Model A82%89%94%30msModel B85%92%96%45msModel C87%94%97%80ms如果 Model C 的效果只比 Model B 高一点但延迟和资源消耗明显增加那么 Model B 可能更加适合生产环境。所以最终选择不是谁的排行榜最高就用谁。而是在自己的数据上效果、速度、成本综合最合适的模型。五、一些实际项目中的经验1. 不要只依赖向量检索Embedding 对语义搜索非常有效但对于下面这些内容产品型号 错误代码 订单编号 文件编号 版本号 专业缩写关键词搜索往往更加可靠。所以实际 RAG 中经常采用Embedding BM25 Rerank也就是Query ↓ Hybrid Search ↓ 初步召回 ↓ Reranker ↓ 最终 Top-K ↓ LLM2. 不要一开始就追求最大的 Embedding 模型如果项目刚开始可以先使用一个效果和性能比较平衡的模型建立基线。例如先跑通 RAG ↓ 建立测试集 ↓ 统计 RecallK ↓ 发现召回效果不足 ↓ 再换更大的 Embedding这样比一开始就上最大的模型更加合理。3. Chunk 和 Embedding 必须一起调Embedding 选得再好如果 Chunk 切得很差最终召回效果一样可能很差。例如Chunk 太大 → 一个向量包含太多主题 → 语义不集中 Chunk 太小 → 上下文信息不完整 → 检索到的内容缺少上下文所以实际调 RAG 时不应该只调 Embedding。通常应该一起测试Embedding 模型 Chunk 大小 Chunk overlap 检索 Top-K Rerank总结Embedding 模型选择可以简单归纳成四句话第一看语言和业务领域 第二看向量维度和输入长度 第三用自己的数据测试 RecallK 第四结合效果、速度和成本做最终选择完整的 RAG 检索链路可以理解为文档 ↓ Chunk 切分 ↓ Embedding ↓ 向量数据库 ↓ 用户 Query ↓ Query Embedding ↓ 向量检索 / BM25 ↓ Hybrid Search ↓ Rerank ↓ 相关文档 ↓ LLM ↓ 最终答案其中 Embedding 只是整个检索链路的一环。不要把“选择 Embedding 模型”理解成单独选一个模型的问题。真正的目标是让 Query 能够稳定地找到正确的 Chunk。因此对于实际 RAG 项目来说最可靠的选型标准不是模型名字也不是排行榜而是在自己的业务数据上谁能够用更低的成本把正确资料稳定召回谁就是更适合自己的 Embedding 模型。
