每周一道 Agent 面试题：RAG 的 Embedding Model 怎么选？先看业务，别先看榜单

开场

上一篇聊完 chunk 怎么切，接下来就要把这些切片转成向量，写入向量数据库。此时绕不开一个问题：Embedding Model 用哪个？

市面上的选择很多。既有商业 API，也有可以本地部署的开源模型；有的强调中文能力，有的面向多语言，有的支持长输入，有的允许调整向量维度。公开榜单还会给出平均分和排名。看起来，挑一个排名靠前的模型接入系统，再拿几个问题试搜，差不多就能完成选型。

但实际选型通常没这么直接。

假设知识库里有一份差旅制度。用户问：“特殊情况下可以先订票再补审批吗？”系统返回的却是普通差旅申请流程。两段内容里都有“差旅”“订票”和“审批”，从字面上看很接近，但用户真正想找的是特殊场景下的例外规定。

第一反应往往是模型不够好，换一个排名更高的试试。原来的问题可能因此命中，但继续测试后，新的问题又出现了：中文制度检索变好，英文文档却不稳定；召回率只提高一点，向量维度、存储空间和推理延迟却明显增加。

还有一种情况是，换了几个模型，结果都没有改善。继续排查才发现，特殊审批条件在解析时已经丢失，或者 chunk 恰好把适用条件和审批要求切到了两个片段里。Embedding Model 根本没有看到完整证据，自然无法把它检索出来。

“哪个 Embedding Model 最好”不能脱离场景回答。问题应该换成：在现有语料、查询方式和工程约束下，哪个模型更适合当前系统。

---

1、先理解 Embedding Model 在系统中的作用

Embedding Model 的任务是把查询和文档映射到向量空间，让系统根据语义相似度找到候选内容。

在 RAG 系统里，一般会有两类输入：

• **文档侧：**经过解析和切分后的 chunk；
• **查询侧：**用户输入的问题、关键词或改写后的查询。

模型分别生成文档向量和查询向量，向量数据库再根据余弦相似度、点积或其他距离算法返回相近的文档片段。

这里有一个常见误解：向量相近，不代表内容一定能够回答问题。

用户问“合同提前终止需要承担什么责任”，模型可能返回“合同终止流程”“合同到期续签”和“提前终止赔偿条款”。它们都与合同终止相关，但只有最后一段真正回答了责任问题。

Embedding Model 主要负责从大量文档中筛出候选内容，并不能完成所有判断。它修复不了已经丢失的文本，也不能保证准确区分所有例外条件、否定关系和适用范围。检索效果还会受到文档解析、chunk、查询表达、过滤条件、Top K 和重排策略的影响。

**模型选型不该从模型名称开始。**先弄清它在系统中负责什么、不负责什么；只有问题出在语义表示和初步召回阶段，更换模型才可能直接见效。

2、先把业务场景说清楚

比较模型之前，至少要先回答四类问题。

2.1、知识库里是什么内容

先弄清文档使用什么语言，是否混合多种语言，以及系统里有没有中文查询英文文档、英文缩写和中文名称混用等情况。

内容形式也会影响选型。普通段落、产品手册、制度文件、代码、表格和扫描 PDF，对模型与解析流程的要求各不相同。表格的行列关系一旦在解析时被破坏，换模型通常也恢复不了。

领域特征同样不能略过。内部简称、产品型号、医学术语、法律条款和行业缩写，都是通用评测难以覆盖的内容。一个模型在公开语料上表现很好，不代表它理解企业内部的叫法。

文档更新频率也会影响取舍。内容相对稳定时，全量编码速度影响有限；每天都有大量新增文档时，批量编码、API 费用和索引更新就更值得关注。

2.2、用户怎样提问

即使知识库相同，用户提问方式不同，合适的模型也可能不同。

用户可能输入简短关键词，如“差旅报销”；也可能输入完整问题，如“试用期员工去高原地区出差，住宿标准能否上浮”；还可能使用口语、省略句、错别字、内部简称或英文缩写。

如果用户查询通常很短，而文档 chunk 很长，模型需要把短查询和长文档中的核心含义对齐。如果存在跨语言检索，模型还要把不同语言中的同一概念映射到接近的位置。

这些特征要从真实查询里总结，不能只靠团队想象。线上日志、客服问题、业务人员整理的重点问题和历史漏答案例，都可以用来了解用户怎么提问。

2.3、系统有哪些硬约束

模型效果再好，只要不满足硬约束，就不能成为最终方案。

常见硬约束包括：

• 数据是否允许发送给外部 API；
• 模型许可是否满足商业使用要求；
• 单次查询延迟和并发量是否有明确上限；
• 当前服务器能否支持本地部署；
• 输入长度能否覆盖实际 chunk；
• 向量数据库是否支持模型输出维度；
• 系统能否承担重新生成向量和重建索引的时间。

例如，数据不能出网时，外部 API 模型即使榜单排名很高，也不能作为最终方案。知识库每天新增大量文档时，模型编码吞吐量可能比少量离线分数差异更重要。

2.4、哪些目标可以权衡

硬约束之外，还要明确哪些指标可以权衡。大家都希望召回质量更高、延迟更低、成本更少，但这些目标通常不能同时做到最好。

可以先设置质量底线。例如，核心问题的 Recall@5 必须达到要求，涉及合规和风险的关键案例不能退化。满足质量底线后，再在候选方案中比较延迟、成本和维护难度。

这样可以避开两种常见偏差：只选榜单分数最高的模型，忽略存储和算力；或者只选最便宜的方案，把漏检成本留给用户和人工处理。

---

3、怎样建立候选模型池

业务约束明确后，再筛选候选模型。

公共榜单、模型文档和社区经验都可以参考，**但它们的作用是缩小范围，不是直接给出答案。**候选模型不宜过多，通常保留三到五个有代表性的方案就够了。

一个合理的候选池可以包括：

• 当前正在使用的模型，作为基线；
• 一个公开评测表现较强的通用模型；
• 一个更擅长中文、多语言或跨语言检索的模型；
• 一个适合本地部署、成本较低的方案；
• 一个效果更强但延迟或价格更高的方案。

截至 2026 年 10 月，可以先用下面这些模型搭一个候选池。这里列的是评测起点，不是推荐顺序，更不是最终答案。

候选方向	模型示例	放进候选池的目的
当前基线	项目正在使用的模型	作为参照，确认换模型是否真的带来收益
商业 API	OpenAI text-embedding-3-large	评估通用文本和多语言检索场景
商业 API	Cohere embed-v5.0-pro、embed-v5.0-fast	分别观察质量优先和延迟、吞吐量优先的方案
本地多语言	BAAI/bge-m3	评估多语言、长文本和混合检索场景
本地不同规模	Qwen3-Embedding-0.6B、4B、8B	比较模型规模、部署资源和检索效果之间的取舍

**这些名称只是起点。**是否保留某个模型，还要看语言覆盖、输入方式、硬件条件、许可和业务测试结果。模型版本更新较快，正式评测前需要重新核对官方文档，不能照着一张旧名单直接开测。

筛选时要查看模型文档中的具体信息：

• 支持哪些语言和任务；
• 最大输入长度是多少；
• 推荐使用怎样的查询和文档前缀；
• 输出向量维度是否固定或可以调整；
• 是否需要归一化向量；
• 推荐使用余弦相似度还是点积；
• API 的限流、价格和版本策略；
• 本地模型的显存、内存和推理框架要求；
• 模型许可是否符合项目要求。

输入模板很容易被忽略。有些模型要求查询和文档使用不同前缀，有些模型在带有特定任务指令时表现更好。如果接入方式与官方建议不一致，测试结果可能反映不出模型的实际能力。

4、API 模型与本地部署怎么取舍

API 模型的优势是接入快，不需要管理推理服务，模型升级也相对方便。缺点是数据需要出网，调用费用会随规模增长，还要面对网络延迟、限流和供应商版本变化。

评估 API 时，不能只看单次查询价格。文档首次建库、日常增量更新、重新编码和测试环境调用，都会产生费用。还要确认接口是否提供固定版本，模型升级后向量空间是否变化，以及出现服务异常时是否有降级方案。

本地部署可以更好地控制数据和版本，长期大规模使用时也可能降低边际成本。但它会带来硬件、扩容、监控、升级和故障处理工作。模型能在一张 GPU 上运行，不代表能够满足真实并发；离线批量编码很快，也不代表在线查询延迟稳定。

具体怎么选，还是要看业务：

• 数据敏感、版本稳定性要求高，可以优先评估本地部署；
• 团队规模小、上线时间紧、调用量有限，可以优先评估 API；
• 文档规模很大、更新频繁，需要重点计算批量编码吞吐量；
• 查询并发高，需要重点测试在线服务的 P95 和 P99 延迟；
• 业务可能快速变化，需要考虑模型迁移和回滚是否方便。

**部署方式没有天然的高下之分。**评估时把质量、成本、安全和维护放进同一张决策表即可。

---

5、面试时应该怎样表达

面对“现在市面上的 Embedding Model 怎么选择”，可以先这样回答：

我不会直接按公共榜单选择。会先明确业务语料、查询方式、语言分布、数据安全、延迟和成本约束，用这些条件排除明显不合适的模型，再保留少量候选进入自己的业务评测。

接着再讲候选池怎么建立，以及为什么公共榜单只能用来初筛。

如果面试官继续追问“你会选哪个模型”，不要急着报出一个名称。可以先说明：模型名称取决于数据是否允许出网、是否需要跨语言、chunk 长度、并发和成本。然后给出一个带条件的结论，例如：

如果主要是中文制度文档、数据不能出网，我会优先选择支持中文并可本地部署的候选模型；如果包含大量中英混合资料，会把多语言对齐能力作为重点评测项。最终仍然使用自己的查询和文档验证，而不是只根据榜单决定。

这类回答并没有回避问题，而是把选择模型所依赖的条件交代清楚。

面试官继续追问时

如果两个模型效果接近，先确认它们都达到核心质量门槛，再比较延迟、吞吐量、存储、版本稳定性和维护难度。实际项目里，通常会选择更简单、稳定，也更容易迁移和回滚的方案。

如果面试官问“为什么不直接选榜单第一”，可以明确回答：榜单任务、数据分布、语言比例和指标权重都可能与业务不同。排名靠前只能说明这个模型值得测试，还不能直接支持上线。

这些追问真正想确认的是，你能不能结合真实系统做判断，而不是背一个模型名称或榜单排名。选型时还要记下当时的假设和边界，业务条件变化后，团队才能快速判断是否需要重新评估。

6、怎样做一张候选模型初筛表

候选模型较多时，可以先建立一张初筛表，而不是边看资料边凭印象淘汰。

表格至少包含：

维度	需要确认的问题
语言能力	是否覆盖中文、英文和跨语言检索
输入长度	是否覆盖当前 chunk 的 P95 和最大长度
向量维度	是否固定，能否降维，现有向量库是否支持
接入方式	API、本地部署，还是两者都支持
数据安全	文档是否需要出网，服务端是否保留数据
性能	批量编码速度、在线延迟和并发能力
成本	API 费用、硬件资源、存储和运维成本
稳定性	模型版本是否固定，服务是否有限流和 SLA
许可	是否允许当前业务场景使用和再分发
迁移	是否需要调整输入模板、维度和索引配置

填写这张表时，要区分“文档宣称”和“已经验证”。模型文档写着支持多语言，可以记为候选能力；只有自己的跨语言测试通过后，才能记为已验证能力。

还可以给硬约束单独增加一列。只要某个候选违反硬约束，就直接停止评测。例如，数据不能出网时，不需要继续花时间比较外部 API 的检索分数。

**初筛表不是为了机械打分，而是为了把排除理由写清楚。**技术评审时，团队也能看明白为什么某个热门模型没有进入最终测试。

7、还有两个容易漏掉的问题

很多评测只盯着在线查询，忽略了文档批量编码、增量更新、索引构建和版本迁移。实际项目中，文档侧的成本可能比单次查询更高。

**退出成本也要提前算。**一个方案接入得快，不代表以后换得容易；供应商升级模型、向量空间发生变化时，可能需要全量重建索引。除了怎么接入，还要看以后怎么升级和替换。

这两点补齐后，进入业务评测的候选模型才更接近可以实际落地的方案。

---

下篇预告

完成业务约束和候选池，只代表知道“哪些模型值得测”，还不能说明“哪个模型更适合”。

下一篇会继续讨论：《每周一道 Agent 面试题：现在市面上的 Embedding Model 怎么选择（2）——怎样用自己的数据完成业务评测》。

重点包括：中文、英文和中英混合语料怎样分别设计问题，测试集应该怎样标注，Recall@K、MRR 和 NDCG 分别说明什么，以及为什么一定要保留具体失败案例。

结束语

Embedding Model 选型先要把业务边界写清楚。公共榜单用来建立候选池，硬约束用来排除不能落地的方案，剩下的候选再交给业务数据验证。下一篇就从业务测试集开始。