很多候选人聊到 RAG，最容易卡住的问题不是“有没有向量库”，而是：

“Embedding 模型怎么选？为什么是它？Rerank 又是怎么配的？”

面试里最常见的一种失分方式就是：

先说“我们用了 BGE”
被追问“哪个版本”
再被追问“为什么不是 GTE”
最后被问“有没有 Rerank，怎么验证选型”

然后整段回答就开始发散。

这类问题之所以高频，不是因为它有多冷门，而是因为它非常适合区分两类人：

只是听说过 RAG 流水线的人
真正做过检索选型和效果验证的人

所以这篇文章，我们不准备写成“模型名大盘点”，而是更贴近真实技术面的方式来讲：

Embedding 在 RAG 里到底决定了什么
BGE、GTE 这类模型真正差在哪
为什么很多系统还要加一层 Rerank
MTEB 应该怎么看，才不会显得像在背榜单
如果你在 Interview AiBox 这种面试场景里做选型，应该怎么讲得更像真做过

先看流程：Embedding 和 Rerank 在链路里分别负责什么

一、先别急着背模型名，先说清 Embedding 在解决什么

很多人会把 Embedding 解释成“把文本转成向量”，这没有错，但太浅了。

在 RAG 里，Embedding 模型本质上决定的是：

系统认为什么叫“相似”。

比如用户问：

“保单现金价值怎么算？”

知识库里有一段材料讲的是：

“现金价值是保单在退保或特定条件下可领取的金额……”

如果模型能把这两段语义对齐，检索就容易命中；如果模型把“现金价值”更多理解成泛财务语义，而不是保险场景下的专业术语，召回就可能开始偏。

所以 Embedding 选型从来不是“选一个大家都在用的名字”，而是选一种更适合你语种、文档形态、检索架构和时延预算的相似性定义。

二、BGE 和 GTE，真正要怎么区分

如果你只回答“我们用了 BGE”，面试官通常很快会继续问：

是 bge-m3 还是 bge-large-zh-v1.5？
你们为什么没选 gte-multilingual-base？
你们是只做 dense retrieval，还是 hybrid retrieval？
文档长一点时，模型的上下文长度够不够？

这几个问题其实都在考你：你有没有把模型能力和业务场景真正对应起来。

BGE-M3 更像一个“检索能力更完整”的通用底座

从 BAAI 的官方模型卡来看，bge-m3 有几个很鲜明的特点：

支持超过 100 种语言
最长输入长度可以到 8192 tokens
同时支持 dense retrieval、sparse retrieval 和 multi-vector retrieval
官方在 RAG 场景里明确建议用 hybrid retrieval + reranking

这意味着什么？

如果你的场景不是单纯“把一句短 query 和一段短文本做 dense 相似度匹配”，而是更接近：

中英混合资料
文档长度差异较大
既想保语义，又想保关键词命中
后面可能会接 Hybrid Search

那 bge-m3 往往是一个很省心的起点。

对 Interview AiBox 这类面试场景来说，它的价值不只是“多语言”，更在于它给检索链路留下了更大的架构余地。

GTE-multilingual-base 更像“长上下文多语言 + 资源更克制”的选择

从阿里官方的 gte-multilingual-base 模型卡来看，它也有几个很明确的特征：

支持超过 70 种语言
最长输入长度同样可到 8192 tokens
是 encoder-only 架构，官方强调相比一些更重的 decoder-only 方案，推理硬件要求更低
支持 elastic dense embedding，输出维度可以按需要裁到 128-768
同时支持 sparse vectors

这类模型更适合你这样去理解：

你有明确的多语言需求
你很在意部署资源和吞吐
你希望在存储成本和召回效果之间做更细的权衡
你不只是看单次效果，也看长期服务成本

所以如果面的是阿里，被问到 GTE 并不意外。面试官很多时候并不是要求你一定选它，而是想确认你有没有做过同量级竞品比较。

纯中文场景，不一定非要上最“全能”的模型

如果你的场景非常明确：

基本就是中文
chunk 长度控制得比较短
检索方式也比较标准

那像 bge-large-zh-v1.5 这种中文向量模型，依然可能是很务实的选择。

它的意义不在于“参数更大”，而在于：如果你的问题空间就是中文专业资料，过度追求多语言和多功能，未必比一个更聚焦的中文模型更划算。

所以面试里不要把答案说成：

“最强的是哪个，我就选哪个。”

更好的说法是：

“我先看语种、chunk 长度、检索形态和部署预算，再决定要不要上更通用的模型。”

三、别把 Embedding 讲成终点，很多系统还需要 Rerank

这是另一个很容易暴露经验深度的地方。

很多人说到检索，只会讲：

query 编码成向量 -> 去向量库召回 TopK

但如果你真的做过效果优化，就很少会把这一步当成终点。

因为大多数 Embedding 模型本质上还是 Bi-Encoder：

query 单独编码
文档单独编码
再做向量相似度匹配

这套方案速度非常好，适合大规模初召回，但它也有天然上限：

query 和文档是在各自独立编码后才比较的，细粒度交互不够。

这也是为什么很多系统会在初召回之后，再加一层 Rerank。

四、Rerank 解决的，不是“再排一次序”这么简单

Rerank 常见做法是 Cross-Encoder 风格：

把 query 和文档一起送进模型
直接输出一个相关性分数

这样做的代价是更慢，但收益是：

模型能看到 query 和文档放在一起时的真实交互。

这对什么场景最有用？

query 很短，但候选文本很多都“差不多相关”
术语相近，但真正答案只有少数片段
需要从 Top50 / Top100 里再精排出真正能给 LLM 的 Top3 / Top5

对于面试场景，这一步尤其重要。

因为用户问的往往不是开放域知识，而是：

自己项目里哪段经历最贴这个追问
哪个 chunk 同时带背景、动作和结果
哪个版本是当前岗位真正该讲出来的版本

这时候，Rerank 不是锦上添花，而是帮你把“看起来都相关”的候选，重新拉回到真正可回答的少数片段。

五、BGE 系和 GTE 系的 Rerank，应该怎么理解

BGE Reranker 更适合从 BGE 检索链路顺手接上去

BAAI 的 bge-reranker-v2-m3 官方模型卡里有几个点很值得面试时提：

它是多语言 reranker
直接输入 query + passage 输出相似度
官方把它归类成轻量、易部署、推理较快的 reranker 选项

这类模型很适合这样讲：

“我们先用 Embedding 做大规模初召回，再用同系列 reranker 精排，把真正 relevant 的少数片段送进生成层。”

即使你最终没有用同系列，面试里也至少要说明你理解：

初召回和精排在做的是两种不同层级的判断
一层追求覆盖，一层追求精度

GTE 的 reranker 更强调多语言长上下文下的工程平衡

阿里官方的 gte-multilingual-reranker-base 模型卡同样强调了：

支持 70+ 语言
支持 8192 tokens
使用 encoder-only 结构，部署要求相对更可控

所以如果你的链路本来就偏：

多语言
长文档
更在意吞吐和服务成本

那 GTE 系的 embedding + reranker 会是非常自然的一条线。

“同系列搭配”不是铁律，但通常是更稳的起点

这点我会建议你在面试里说得克制一点。

不要绝对化地说：

“Embedding 和 Rerank 必须同系列。”

更稳的表述是：

“工程上通常会优先从同系列组合开始评估，因为官方用法、训练分布和调参经验通常更一致；但最终要不要混搭，还是要看我们自己的测试集结果。”

这种说法更像做过工程的人，而不是背结论的人。

六、对 Interview AiBox 这类面试场景，我们更关心什么

在 Interview AiBox 这类产品里，我们做的不是开放域搜索，而是：

候选人的简历
项目复盘
QA 素材
最近几轮追问

一起拼成一条高密度的回答链路。

所以我们看 Embedding / Rerank 选型，不会只看一句“某榜单第一”，而会更关心下面这些问题：

语种是不是和用户资料匹配

如果用户大量使用中文资料、夹杂英文技术词，模型的中英混合检索能力就很重要。

chunk 长度是不是和模型能力匹配

如果 chunk 设计本来就较长，模型最大输入长度就不能只当配置项看。

检索架构是不是 dense-only 还是 hybrid-first

如果链路后面会做关键词 + 向量混合召回，那像 bge-m3、gte-multilingual-base 这种本身支持 dense + sparse 的路线，就会更有优势。

有没有配 Rerank，以及 Rerank 放在哪一层

如果没有精排层，Embedding 选型本身就会被迫承担更多本不属于它的压力。

最后看的不是模型名，而是整条链路的结果

在我们看来，真正值得看的不是“用了谁”，而是：

Recall@K
MRR / nDCG
Precision@K
端到端延迟
多轮追问下的命中稳定性

这才更接近真实产品而不是 demo。

七、MTEB 应该怎么看，才不会在面试里显得像背榜单

很多人一被问“你们选型依据是什么”，就会说：

“我看了 MTEB 榜单。”

这句话不能算错，但如果只停在这，信息量还是不够。

更好的讲法是：

先把榜单当候选池，而不是最终答案

MTEB 更适合做第一轮筛选：

哪些模型值得进入候选名单
哪些模型明显不适合当前语种或任务

但它不应该替代你自己的业务评估。

要看 Retrieval 子任务，不要只看总分

RAG 最关心的是检索，而不是分类、聚类这些其他任务平均进去之后的总分。

所以你至少要表现出你知道：

要看 Retrieval 相关指标
要看跟自己语种更接近的榜单或子项

语言和数据分布比总排名更重要

英文榜第一，不代表就一定是中文保险条款、中文项目复盘里的最优解。

最终还是要回到自建评测集

真正能让面试官觉得你做过选型的，往往不是“我看过榜单”，而是：

“我先用 MTEB / C-MTEB 做 shortlist，再在自己的测试集上比较 Recall@K、MRR 和端到端时延，最后才定默认模型。”

这句话的工程味会重很多。

八、如果面试官问“你们是怎么选 Embedding 和 Rerank 的”，可以这样答

你可以用下面这套结构，不需要背参数，也不会显得空：

我们在选 Embedding 时，先看的是语种、chunk 长度、检索架构和部署预算，而不是先看谁最火。比如如果场景偏多语言、长文档、并且后面会接 hybrid retrieval，我会优先评估像 BGE-M3 或 GTE-multilingual-base 这种支持长上下文、dense+sparse 能力更完整的模型；如果场景更偏纯中文、chunk 也比较短，那中文专用模型也可能更合适。然后我不会只停在 Embedding，还会看要不要接 Rerank。因为 Bi-Encoder 更适合做大规模初召回，真正决定 Top 几结果质量的，往往是后面的 Cross-Encoder 精排。最后在评估上，我会用公开榜单做 shortlist，但真正定型还是回到我们自己的测试集，看 Recall@K、MRR、Precision@K、端到端时延，以及多轮追问下是否还能稳定命中。

这段话的好处是，它把四件事同时讲清楚了：