RAG面试必问：Embedding模型到底怎么选？

本文是「RAG 面试通关」系列的第 3 篇。 上一篇：第 2 篇《RAG 效果差，很多时候不是模型不行，是文档切错了》 下一篇预告：第 4 篇《做 RAG 为什么要用向量数据库，我直接上 MySQL 不行吗》

上周帮一个学员模拟 RAG 面试。

我问他：

“你们 RAG 系统里的 Embedding 模型是怎么选的？”

他说：

“我们用的是 OpenAI 的 embedding，效果还可以。”

我继续问：

“为什么不用 BGE？中文场景下怎么评估？维度越高是不是越好？模型升级后历史向量怎么办？”

他沉默了。

这就是很多人准备 RAG 面试时最容易掉进去的坑。

大家都知道 RAG 要做 Embedding，都知道 Embedding 是把文本转成向量。

但面试官真正想听的不是这句话。

他想知道的是：

你是否理解 Embedding 在 RAG 里的作用。

你是否知道不同模型的取舍。

你是否真的做过选型、评估和迁移。

今天这篇，我们就把 Embedding 面试题一次讲透。

01 语义地基怎么答

一、面试官问：Embedding 是什么？

新手回答

Embedding 就是把文本变成向量，然后通过向量相似度来检索相关文档。

这个回答不算错，但太浅。

高手回答

Embedding 是把文本、图片、代码等离散信息，映射到连续向量空间的一种表示方式。

在这个向量空间里，语义相近的内容距离更近，语义差异大的内容距离更远。

放到 RAG 里，Embedding 的作用是把“用户问题”和“知识库文档”放到同一个语义空间里，方便系统用相似度搜索找到相关内容。

所以 Embedding 不是简单的格式转换。

它决定了系统能不能理解“问法不同但意思相近”的问题。

比如用户问：

“怎么让大模型回答公司制度？”

知识库里写的是：

“员工可通过智能问答系统查询内部规章制度。”

这两句话没有多少关键词重合，但语义是相关的。

关键词检索可能找不到，好的 Embedding 模型可以找得到。

这就是 Embedding 在 RAG 里的核心价值。

二、为什么 RAG 需要 Embedding？

RAG 的检索阶段，本质是从大量文档片段里找出和用户问题最相关的内容。

如果只靠关键词，系统会遇到几个问题。

第一，同义词问题。

用户问“离职补偿”，文档写“经济补偿金”。

关键词不一样，但意思相关。

第二，口语化问题。

用户问“公司能不能随便开人”，文档写“解除劳动合同条件”。

表达方式差很多。

第三，跨语言或专业术语问题。

用户问“RAG 怎么防幻觉”，文档写“基于检索上下文约束生成结果”。

不做语义理解，系统很容易漏召回。

Embedding 的价值，就是让系统从“字面匹配”升级到“语义匹配”。

但注意，Embedding 不是万能的。

它擅长语义相似，不一定擅长精确匹配。

比如产品型号、合同编号、函数名、人名、数字这类内容，关键词检索往往更稳。

所以生产级 RAG 通常不会只靠 Embedding，而是会结合 BM25、元数据过滤、Rerank 等策略。

02 选型别只看榜单

三、Embedding 模型怎么选？

面试时，不要直接说“哪个模型最好”。

更专业的回答是：

Embedding 选型要看语言、领域、成本、延迟、部署方式、上下文长度和评估结果。

可以按这几个维度判断。

1. 看语言场景

如果主要是中文知识库，优先考虑中文表现强的模型，比如 BGE、GTE、text-embedding-3 系列等。

如果是中英文混合，要看模型的多语言能力。

如果是代码检索，还要考虑模型是否对代码语义有训练和优化。

2. 看业务领域

通用模型适合大多数通用知识问答。

但如果是法律、医疗、金融、专利、企业内部术语非常多的场景，通用模型可能理解不够准。

这时可以考虑领域数据微调，或者至少用业务测试集做评估。

3. 看部署方式

闭源 API 的优势是省事、稳定、开箱即用。

缺点是成本、延迟、数据合规和外部依赖。

开源模型的优势是可私有化部署、可控、可微调。

缺点是需要自己维护推理服务、显卡资源和版本升级。

4. 看成本和延迟

Embedding 不是只在用户提问时调用。

文档入库时，每个 Chunk 都要做一次 Embedding。

知识库越大，文档更新越频繁，Embedding 成本越明显。

所以模型越大不一定越适合生产。

很多项目里，768 维或 1024 维模型已经足够好。

5. 看真实评估

榜单只能参考，不能替代业务评估。

最靠谱的方式是构建一批真实问题和标准文档，比较不同模型的 Recall@K、MRR、NDCG，以及最终回答质量。

面试时可以这样说：

我不会只看模型排行榜，而是会拿业务里的真实问题做离线评估。重点看正确 Chunk 是否能进 TopK，是否排得足够靠前，以及最终回答是否更准确。

四、中文场景下有什么特殊问题？

中文 RAG 里，Embedding 选型有几个容易忽略的点。

第一，中文口语化表达多

用户不会总按文档里的正式说法提问。

文档写“报销审批流程”，用户可能问“打车钱怎么报”。

这要求 Embedding 模型有较好的语义泛化能力。

第二，专有名词很多

中文业务文档里常有产品名、部门名、制度名、缩写和内部黑话。

通用模型可能没有见过这些词。

这种情况下，只做向量召回可能不稳，需要结合关键词召回和元数据过滤。

第三，长文本截断问题

很多 Embedding 模型有最大输入长度限制。

如果 Chunk 太长，后面的内容可能被截断，导致向量没有覆盖完整语义。

所以 Embedding 模型选型不能脱离文档切分策略。

上一篇我们讲文档切分，就是为了给 Embedding 提供更合适的输入。

第四，标点、格式和噪声会影响效果

OCR 错误、目录噪声、页眉页脚、乱码、重复文本，都会影响 Embedding 质量。

所以 Embedding 效果差，不一定是模型差，也可能是文档清洗没做好。

五、主流 Embedding 模型怎么对比？

下面这个表可以作为面试回答参考。

注意，不要在面试里绝对化地说“某某模型最好”。

更好的说法是：

如果是中文私有化 RAG，我会优先评估 BGE、GTE 这类开源模型。如果想快速验证，可以先用商业 API。最终选型要看业务测试集上的召回指标、延迟和成本。

03 成本微调这些坑

六、Embedding 维度越高越好吗？

不是。

维度更高，通常意味着模型能表达更多信息，但也会带来成本。

第一，存储成本增加。

768 维和 1536 维相比，单条向量存储空间大约翻倍。

第二，检索成本增加。

向量维度越高，相似度计算越重，索引构建和查询都可能变慢。

第三，效果提升不一定线性。

从小模型换到大模型，可能有提升，但提升是否值得，要看业务评估。

所以面试里可以这样答：

Embedding 维度不是越高越好，而是要在效果、成本和延迟之间做权衡。生产环境里我会先用业务测试集比较不同维度或不同模型的召回质量，再结合存储和推理成本做选择。

七、Embedding 需要微调吗？

大多数项目一开始不需要。

如果没有高质量标注数据，盲目微调很容易负优化。

什么时候需要考虑微调？

可以看三个条件。

第一，通用模型在业务测试集上召回明显不够。

比如用户问了很多领域问题，但正确文档经常进不了 TopK。

第二，业务里有大量专有术语。

比如医疗、法律、金融、企业内部系统名。

第三，你有足够的高质量训练数据。

最好是 Query 和相关文档的匹配对，也包括一些容易混淆的负样本。

微调时最关键的是负样本。

随机负样本太简单，模型学不到真正的区分能力。

更有价值的是 hard negative，也就是看起来很像但其实不相关的文档。

面试时可以补一句：

我会优先做检索策略优化、文档切分优化和测试集评估，确认瓶颈确实在 Embedding 表示能力上，再考虑微调。

这句话比直接说“可以微调”专业得多。

八、Query 和 Document 要用同一个 Embedding 模型吗？

通常要。

因为向量相似度成立的前提，是 Query 向量和 Document 向量在同一个语义空间里。

如果 Query 用模型 A，Document 用模型 B，它们的向量空间不一致，直接算相似度通常没有意义。

但有一种情况例外。

双塔模型。

双塔模型可以有一个 Query Encoder 和一个 Document Encoder，它们参数不一定完全相同，但训练目标是让相关的 Query 和 Document 在同一个空间里靠近。

也就是说，不是“随便两个模型”都能混用。

只有经过联合训练或空间对齐的模型，才能这样做。

面试时这样答最稳：

一般情况下，Query 和 Document 应该使用同一个 Embedding 模型，保证向量空间一致。如果使用不同编码器，也必须是联合训练过的双塔结构，不能随便混用两个模型。

九、模型升级后，历史向量怎么办？

这是项目里一定会遇到的问题。

比如你一开始用某个 Embedding 模型做了全库向量化。

后来新模型效果更好，你想升级。

能不能只把新 Query 用新模型编码，旧文档向量不动？

通常不行。

因为新旧模型的向量空间不同，直接混查会导致相似度失真。

常见方案有三种。

方案一：全量重算

把所有历史 Chunk 用新模型重新 Embedding。

优点是最干净、最准确。

缺点是成本高，数据量大时耗时长。

方案二：双索引灰度

保留旧索引，同时构建新索引。

一部分流量走新模型和新索引，观察效果和稳定性。

确认没问题后，再逐步切换。

这是生产环境更稳的方案。

方案三：增量迁移

新文档用新模型，旧文档后台慢慢重算。

迁移期间需要注意新旧索引隔离，不能把不同模型生成的向量混在同一个检索空间里直接比较。

面试时要强调：

Embedding 模型升级不是只换一个 API，而是涉及历史向量重建、索引迁移、灰度发布和效果回归测试。

04 项目落地怎么迁移

十、项目里怎么做 Embedding 选型？

可以按这个流程讲。

第一步，明确业务场景。

是中文还是多语言，是通用知识问答还是专业领域问答，是内部部署还是可以调用外部 API。

第二步，准备测试集。

从真实用户问题、客服问题、面试题、业务文档里整理一批 Query，并标注对应的正确 Chunk。

第三步，候选模型评估。

比较 Recall@K、MRR、NDCG、延迟、成本和部署复杂度。

第四步，小流量灰度。

看线上 bad case 是否减少，用户反馈是否变好。

第五步，版本管理。

记录每个 Chunk 的 embedding_model、model_version、created_at，方便后续迁移和回滚。

这个流程非常加分，因为它说明你不是只会调包，而是知道生产系统怎么落地。

十一、面试官追问清单

1. Embedding 和关键词检索有什么区别？
2. 为什么 RAG 不能只靠 Embedding？
3. 中文场景下选择 Embedding 模型要注意什么？
4. BGE、E5、GTE、text-embedding-3 有什么区别？
5. Embedding 维度越高越好吗？
6. Query 和 Document 能不能用不同模型？
7. 什么是双塔模型？
8. 什么情况下需要微调 Embedding？
9. 微调 Embedding 需要什么数据？
10. 模型升级后历史向量怎么处理？
11. 如何评估 Embedding 模型效果？
12. 如果召回不到正确文档，你怎么判断是不是 Embedding 的问题？

总结

最后总结一下。

Embedding 是 RAG 的语义地基。

它决定系统能不能把用户问题和知识库内容正确对齐。

但 Embedding 不是越大越好，不是榜单越高越好，也不是用了向量检索就万事大吉。

面试时记住五句话。

第一，Embedding 的本质是把文本映射到语义向量空间。

第二，RAG 需要 Embedding，是为了做语义检索，而不只是关键词匹配。

第三，模型选型要看语言、领域、成本、延迟、部署方式和真实评估。

第四，Query 和 Document 通常要用同一个模型，除非是联合训练的双塔结构。

第五，Embedding 模型升级要重建或迁移历史向量，不能简单混用。

下一篇我们讲 RAG 面经系列第 4 篇：向量数据库。

如果说 Embedding 决定“怎么理解语义”，那向量数据库决定“怎么在海量语义里快速找到答案”。

本文是「RAG 面试通关」系列的第 3 篇。下一篇预告：做 RAG 为什么要用向量数据库，我直接上 MySQL 不行吗，记得星标不走丢。

最近我把大家公认最容易翻车的 Agent 开发面试考点 整理成了一份 PDF，我自己面了不少人，也被面了不少次，这些东西说实话，外面那些面经基本看不到。