Embedding 选型与评测：MTEB、维度与多语言

T2-3模块 2 · RAG 工程化面试权重 高更新于 2026-08
前置T0-4T2-2
关联题目Q2-06

这篇学完你能回答什么

  • 「你们 embedding 模型怎么选的？看哪些指标？」
  • 「维度越大效果越好吗？1536 维和 768 维差在哪？」
  • 「MTEB 榜第一就是最优选择吗？」——这是面试官最爱设的陷阱。

从一个真实决策讲起

你要给公司知识库选 embedding 模型。打开 MTEB 排行榜，第一名分数最高，直接用它？

三周后你发现：这个模型是 8B 参数的，向量化 50 万个 chunk 花了两天，线上每次查询要额外 200ms 编码延迟，GPU 账单比预算翻倍——而效果比一个 0.6B 的小模型只高了 1.5 个点。

Embedding 选型是典型的多约束优化，榜单分数只是其中一个约束。 面试官问这题，就是想看你有没有意识到另外几个。

榜首那 1.5 分，花了两天和翻倍账单
打开 MTEB 排行榜，第一名分数最高，直接用它 —— 三周后账单来了

  1. 打开 MTEB 排行榜

    第一名分数最高，直接用它

  2. 照榜首选型

    8B 参数的模型，向量化 50 万个 chunk

  3. 三周后账单来了断点

    跑了两天，GPU 账单比预算翻倍

  4. 一比才发现

    比 0.6B 的小模型只高 1.5 个点

效果差距榜首 8B只比 0.6B 高 1.5 个点
离线编码50 万个 chunk跑了两天
线上延迟每次查询额外 200ms 编码
GPU 账单原定预算翻倍
Embedding 选型是典型的多约束优化，榜单分数只是其中一个约束。面试官问这题，就是想看你有没有意识到另外几个 —— 成本、延迟、许可证，一个都不在 MTEB 榜上。

核心概念：Embedding 决定了什么

Embedding（文本嵌入）把文本映射成高维向量，让语义相近的文本在向量空间里距离更近。

关键认知：它决定了整个 RAG 检索精度的上限。语义在编码阶段丢掉了，后面的 rerank 和 LLM 都补不回来——检索不到的东西，排序排不出来，模型也编不出来。所以这一步的选型比大多数人以为的更重要。

检索精度的上限，在编码那一刻就封顶
同一件事的两种说法：左边是直觉，右边是面试官想听的那个词
说人话 · 它在干什么

把一段文字压成一串数字

意思近的挨得近 —— 但压缩总有取舍，这一步丢了就是真丢了

对应
Embedding · 文本嵌入

文本 → 高维向量

把文本映射成高维向量，让语义相近的文本在向量空间里距离更近

余弦相似度维度截断 MRLquery 侧指令前缀
说人话 · 它卡住了什么

这一步丢的，后面谁都补不回来

检索不到的东西，排序排不出来，模型也编不出来

对应
它决定检索精度的上限

rerank 和 LLM 都补不回来

语义在编码阶段丢掉了，后面的环节没有一个能找回来 —— 所以这一步的选型比大多数人以为的更重要

换模型 = 全量重建索引query 与文档同模型最大输入长度
记住这条因果链就够了：检索不到 → 排序排不出来 → 模型编不出来。所以效果差的时候，第一个该被怀疑的不是 LLM，是那 768 或 1536 维里没装下的东西。

原理拆解：四个选型维度

选模型不是挑榜首，是拧四个旋钮
检索精度看子榜、维度是成本旋钮、运营适配才是 2026 的分水岭
检索精度MTEB 综合分含分类、聚类这些和 RAG 无关的任务，做 RAG 只看 Retrieval 子榜第二个陷阱：榜单是通用语料，你的领域可能是法律条文、医疗记录、内部代号 —— 哪怕只有 100 条人工标注的「问题 → 正确文档」对，也比榜单可信
向量维度高维 = 表达能力强，同时 = 存储更大、检索更慢；不是越大越好很多场景 1536 维降到 512 甚至 256 维，召回率只掉 1–2%，存储和查询速度提升数倍 —— MRL（套娃表示学习）让直接截断不必重训
运营适配到 2026 年多语言覆盖已不再是差异化因素，分水岭换成了延迟、吞吐、许可证、部署方式每天 1 亿 token 的典型生产负载，闭源 API 与自托管开源模型的月成本可能差一个数量级以上
稀疏 / 稠密 / 混合稠密擅长语义泛化、弱在精确词匹配；稀疏保留词项，擅长专有名词与编号BGE-M3 这类三合一模型同时输出稠密、稀疏、多向量表示，一个模型撑起混合检索（T2-5），省掉维护两套系统

维度那一档的加分答法：「维度是精度和成本的旋钮，我会用评测集测几个档位的 recall@k，选拐点，而不是默认用最大维度。」

许可证是能让整个项目返工的合规问题。部分高分开源模型采用 CC-BY-NC 协议（不可商用），企业场景选型前必须确认 —— 面试时顺口提一句，专业度立刻不一样。

四个维度里只有第一个能在榜单上查到，其余三个都得在你自己的环境里量。所以这题的答案里如果只有一个模型名，等于另外三个约束一个都没考虑过。

维度一：检索精度——**看子榜，别看综合分**

MTEB（Massive Text Embedding Benchmark）是最权威的通用基准，涵盖分类、聚类、检索、重排序、语义相似度等多类任务；中文场景对应 C-MTEB。

这里是第一个陷阱：MTEB 综合分包含大量与 RAG 无关的任务（分类、聚类）。做 RAG 应该只看 Retrieval 子榜。一个模型可能靠聚类拉高了综合分，检索却不如榜下的模型。

第二个陷阱：榜单是通用语料，你的领域可能完全不同（法律条文、医疗记录、内部代号）。最终依据只能是你自己的评测集——哪怕只有 100 条人工标注的「问题→正确文档」对，也比榜单可信。

维度二：向量维度——不是越大越好

维度高 = 表达能力强，但也 = 存储更大、检索更慢。

一个反直觉但重要的事实：很多场景把 1536 维降到 512 甚至 256 维，召回率只掉 1–2%，而存储和查询速度能提升数倍。 现代模型普遍支持维度截断（MRL，套娃表示学习——训练时就让前 N 维承载主要信息，所以可以直接截断而不必重训）。

面试加分答法：「维度是精度和成本的旋钮，我会用评测集测几个档位的 recall@k，选拐点，而不是默认用最大维度。」

维度三：运营适配——2026 年真正的分水岭

到 2026 年，多语言覆盖已经不再是差异化因素（主流开源模型普遍支持 90–100+ 语言），选型决策更多取决于运营适配：延迟、吞吐、许可证、部署方式。

其中最容易被忽略的是成本量级差：一个典型生产负载（每天 1 亿 token），用闭源 API 的月成本与自托管开源模型可能相差一个数量级以上。数据量大的场景，自托管往往是唯一可持续的选择。

还有一个能直接踩雷的点：许可证。 部分高分开源模型采用 CC-BY-NC 协议（不可商用）。企业场景选型前必须确认许可证类型——这是能让整个项目返工的合规问题，面试时提一句会显得很专业。

维度四：稀疏 or 稠密 or 混合

  • 稠密向量（Dense）：主流，擅长语义泛化，弱在精确词匹配。
  • 稀疏向量（Sparse / learned sparse）：保留词项信息，擅长专有名词、编号。
  • 三合一模型：如 BGE-M3 同时输出稠密、稀疏、多向量表示，一个模型撑起混合检索（见 T2-5），省掉维护两套系统的麻烦。

工程实践（截至 2026-08）

主流候选（生态变化很快，具体分数请以最新 MTEB 榜和官方文档为准）：

方向 常见选择 特点
中文 RAG 通用 BGE-M3 稠密+稀疏+多向量三合一，中文强，开源可自托管
多语言 / 长文档 Qwen3-Embedding 系列（0.6B–8B） MTEB 多语言榜曾登顶（8B 约 70.6 分），尺寸可选，支持自定义指令
快速接入 OpenAI text-embedding-3-small / large 免运维，支持维度截断
多语言 API Cohere embed 系列 多语言与长文档表现好
私有化 / 数据不出内网 BGE-M3、Qwen3-Embedding、GTE 本地部署

一个重要变化：2025–2026 年开源模型在主流基准上已追平甚至反超闭源 API。所以「用 OpenAI 更保险」这个默认假设在 2026 年需要重新论证，尤其在中文和成本敏感场景。

避坑清单：

  • query 和 document 必须用同一个模型编码，否则向量空间不一致，结果全乱。
  • 部分模型要求 query 侧加指令前缀（如「为这个句子生成表示用于检索：」），漏加会明显掉点，这是新手最常见的静默错误。
  • 换模型 = 全量重建索引，几百万向量重跑一次成本不小，所以选型要在项目早期慎重定。
  • 注意模型的最大输入长度，chunk 超限会被静默截断。
  • 归一化：多数模型输出已归一化，此时余弦相似度和内积等价——库的距离度量要配对，配错了排序会莫名其妙。

怎么建你的评测集（最重要的一步）：

  1. 从真实用户提问日志里抽 100–200 条，覆盖不同类型（口语化、专有名词、长问题）。
  2. 人工标注每条问题对应的正确文档（chunk 级别）。
  3. 用 recall@k、MRR、NDCG 对比候选模型，按问题类型分桶看，不要只看总平均。
  4. 同时记录编码耗时与存储成本，把效果和成本一起摆到桌面上做决策。
开源已追平闭源，默认假设该重新论证
主流候选各占一个位置；真正拍板的是你那 100–200 条标注集
主流候选 · 截至 2026-08
方向常见选择特点
中文 RAG 通用BGE-M3稠密+稀疏+多向量三合一，中文强，开源可自托管
多语言 / 长文档Qwen3-Embedding 系列（0.6B–8B）MTEB 多语言榜曾登顶（8B 约 70.6 分），尺寸可选，支持自定义指令
快速接入OpenAI text-embedding-3-small / large免运维，支持维度截断
多语言 APICohere embed 系列多语言与长文档表现好
私有化 / 数据不出内网BGE-M3、Qwen3-Embedding、GTE本地部署
避坑清单与评测集怎么建
编码要配对
query 和 document 必须用同一个模型编码，否则向量空间不一致，结果全乱
指令前缀
部分模型要求 query 侧加前缀（「为这个句子生成表示用于检索：」），漏加会明显掉点
换模型的代价
换模型 = 全量重建索引，几百万向量重跑一次成本不小，所以选型要在项目早期定
距离度量
多数模型输出已归一化，此时余弦与内积等价 —— 库里配错度量，排序会莫名其妙
评测集怎么建
真实提问日志抽 100–200 条，覆盖口语化 / 专有名词 / 长问题，人工标到 chunk 级
怎么比
用 recall@k、MRR、NDCG 按问题类型分桶看，同时记录编码耗时与存储成本
生态变化很快，具体分数请以最新 MTEB 榜和官方文档为准。这张表的用法不是照抄一行，是先拿「数据能不能出内网」和「许可证能不能商用」把候选砍掉一半。

面试视角

照榜单选和照标注集选，一问就分开
追问路径：怎么选 → 看什么指标 → 维度越大越好吗 → 换模型成本 → 领域词怎么验
  1. 先给三个约束精度、成本、合规
  2. 精度怎么看Retrieval 子榜 + 自建评测集
  3. 维度怎么定当成精度与成本的旋钮，测拐点
  4. 顺带提许可证CC-BY-NC 不可商用，一句话的事
  5. 最后一句定调「用自己的 100 条标注集拍的板」
只读过：这些答法露得最快
  • 「我们用的 MTEB 第一名」—— 综合分里全是和 RAG 无关的任务
  • 「维度当然越大越好」—— 不知道降到 512 召回也只掉 1–2%
  • 答不出换模型的代价 —— 没经历过几百万向量全量重建索引
  • 全程不提许可证 —— CC-BY-NC 那一刀能让整个项目返工
  • 说不清领域词效果怎么验 —— 只有榜单，没有自己的标注集
真做过：这些细节骗不了人
  • 明确说「只看 Retrieval 子榜」—— 知道综合分被分类聚类拉高过
  • 把维度讲成旋钮：测几个档位的 recall@k，选拐点再定
  • 主动提「换模型 = 全量重建索引」，所以选型要在早期慎重定
  • 顺口带一句许可证：高分开源里有 CC-BY-NC，企业不能商用
  • 报指标时带上分桶：recall@k、MRR、NDCG 按问题类型分开看
这题的加分点便宜得离谱：顺口一句「许可证确认过」就够。而真正答满的是那句「我们最终用自己的 100 条标注集拍的板，不是照榜单选的」—— 它同时交代了评测集和判断力。配套题：Q2-06。

典型追问路径：怎么选的（Q2-06）→ 看什么指标 → 维度越大越好吗 → 换模型的成本 → 你的领域词效果怎么样、怎么验证。

答题结构建议：先说「三个约束：精度、成本、合规」→ 精度部分点出「看 Retrieval 子榜 + 自建评测集」这两个专业信号 → 维度讲成本精度旋钮 → 顺带提一句许可证。能主动说出「我们最终是用自己的 100 条标注集选的，不是照榜单选的」，基本就把这题答满了。

配套题目：Q2-06；相关：Q2-10（混合检索）、Q2-15（召回率评估）。

小结与延伸

一句话总结：Embedding 决定检索精度的上限，但选型不是挑榜首——看 Retrieval 子榜、用自己的评测集拍板、把维度当成本旋钮、别忘了许可证。

下一篇 T2-4：向量存进去之后，千万级数据怎么在毫秒内检索——HNSW 与向量库选型。

继续深入

本篇归属第 2 章「RAG 工程化」，去做这一章的题。