考察点
这道题出自美团后端 Agent 开发岗位一面，通常接在「介绍你做过的 RAG 项目」之后。面试官想确认两件事：一是你的模型选型是有依据的决策，不是随便抄了个默认配置；二是你有真实的调研广度和评测方法，知道业界主流选项各适合什么场景。追问一般会往「怎么验证效果」「为什么不用 OpenAI 的」「rerank 加了有多大提升」这些方向走。
参考答案
先讲清楚要选型的是哪几个模型
RAG 里涉及选型的不止一个模型，面试时我会先拆开讲，显得对全链路有概念：一是 embedding 模型，负责把文档 chunk 和用户 query 编码成向量；二是 rerank 模型，对粗排结果做精排，通常是 cross-encoder 架构；三是生成侧的 LLM。这道题考的主要是前两个。
我实际选了什么，为什么
以中文为主的业务场景，我的默认组合是 BGE-M3 做 embedding + bge-reranker-v2-m3 做 rerank，都是智源（BAAI）开源的。
选 BGE-M3 的理由很实际：多语言支持好，中英文混合语料不用换模型；输出 1024 维稠密向量，最长支持 8192 token 的输入，长文档 chunk 不用截断；而且它一个模型同时产出稠密向量、稀疏向量（类 BM25 的词权重）和多向量（ColBERT 式），可以做混合检索，相当于一个模型把稠密召回和关键词召回都覆盖了。开源、可自部署，数据不出内网，这对公司场景基本是硬性要求。
rerank 用 bge-reranker-v2-m3，cross-encoder 结构，query 和候选文档拼在一起过模型算相关性分数，比 embedding 的双塔余弦相似度精细得多。代价是不能全库跑，只对粗排的 top 20-50 个候选精排。
调研过哪些，怎么对比的
embedding 侧我调研过的主流选项：
| 模型 | 特点 | 适用场景 |
|---|---|---|
| BGE-M3 | 多语言、8192 长度、混合检索 | 中文为主、需自部署，我的首选 |
| OpenAI text-embedding-3-large | 3072 维，效果好，英文强 | 数据可出境、不想维护推理服务 |
| GTE / gte-Qwen2 | 阿里系，多语言，MTEB 排名靠前 | 备选方案 |
| M3E | 早期中文常用 | 已被 BGE 系列超越，历史项目 |
| Jina embeddings v3 | 长文本、多语言 | 长文档场景备选 |
调研方法上我强调两点：一是看公开榜单只看个大概——MTEB、C-MTEB 的排名能筛掉明显不行的，但榜单分数和你的业务数据相关性有限；二是必须自建评测集实测。做法是收集 100-300 条真实业务 query，每条人工标注相关文档（或从历史点击日志挖），然后跑各候选模型算 Recall@10、MRR 这类指标。往往榜单第二第三的模型在你的垂类语料上反而更好，比如法律、医疗文本和通用语料差异很大。
rerank 侧对比过 bge-reranker-v2-m3、bge-reranker-large，以及直接用 LLM 做相关性打分。结论是专用 rerank 模型性价比最高：比粗排召回直接喂 LLM 的准确率提升明显（常见几个点的命中率提升），又比 LLM 打分便宜一两个数量级。
决策时还要交代的非技术指标
面试官很吃这一套：说明你的选型考虑了工程约束。包括——推理成本（BGE-M3 自部署一张消费级显卡就能扛中小规模 QPS）、license（BGE 系列 MIT 可商用）、运维成本（API 方案省事但有网络延迟和稳定性风险）、数据合规（内部文档不能出内网基本一票否决 API 方案）。
可能的追问
- embedding 和 rerank 为什么是两阶段，不能一步到位？ 答：双塔 embedding 把文档离线算好向量存起来，查询时一次编码加 ANN 检索，毫秒级；cross-encoder 要 query 和每个文档联合编码，全库跑成本不可接受，所以只能对粗排的几十个候选用。
- 怎么验证你的选型真的更好？ 答：建带标注的评测集算 Recall@K 和 nDCG；上线后看业务指标，比如 RAG 回答的采纳率、用户改写重问率。
- 向量维度 1024 和 3072 差别大吗？ 答：精度差异没有维度数字看上去那么大，但存储和检索成本差 3 倍；百万级 chunk 以上就要认真权衡，也可以看模型是否支持维度截断（如 text-embedding-3 的 Matryoshka 特性）。