面经策

在 RAG 中，你如何选择 Embedding Model 嵌入模型，需要考虑哪些因素？ ​

  • 标签：AI、大模型、RAG

🏛 业务架构师 ​

选 Embedding 模型我主要看六个维度，按业务权重排序：

  1. 效果与语言匹配：中文为主的场景优先看 C-MTEB 中文榜单及检索子任务表现；榜单只是初筛，必须用自己领域的语料抽 100 条真实问答做离线评测——通用榜单第一不等于你的法务知识库第一。
  2. 上下文长度：模型支持的最大输入 token 数要覆盖你的分块大小，做长文档（合同、标书）检索时要重点核对。
  3. 部署与合规：金融、政务、医疗等数据不能出境的行业，只能选开源模型私有化部署（BGE、GTE）；互联网业务可用 API 降运维成本。
  4. 成本：Embedding 调用本身便宜，但海量文档（千万级分块）的入库向量化成本和增量更新成本要算总账。
  5. 检索维度与存储：输出维度影响向量库内存占用，支持降维（如 text-embedding-3 的 Matryoshka 能力）可以省存储。
  6. 生态兼容：与现有向量库、框架（LangChain、Spring AI）的适配成熟度。

我的原则：Embedding 选型是"60 分即可"的决策，别陷入榜单军备竞赛——先用两周验证闭环，跑通业务再回头精调，沉没成本最小。

🏗 系统架构师 ​

选 Embedding 模型我列一张架构决策清单，按优先级：

  • 领域效果：MTEB/C-MTEB 榜单只做初筛，拿自己业务的 200~500 条标注"query→相关 chunk"金标集，对比 Recall@10 / MRR。通用榜单排名和垂直领域表现经常不一致，这一步不能省；
  • 输入长度：256/512/8192 token 差异直接约束分块策略，长文档场景短窗口模型要多切多存；
  • 语言覆盖：纯中文、多语混合还是跨语言检索（中文 query 检英文文档），决定选多语模型与否；
  • 维度与成本：维度高表达强但存储和检索内存线性涨；支持 MRL 截断或二值量化的模型在亿级向量时能省一半以上成本；
  • 部署与合规：API 模型按 token 计费（建库是一次性大批量，查询是持续 QPS，两边都要算账）；数据出域要求决定必须开源自托管，那就要评估 GPU 吞吐（批量嵌入吞吐 × 每日增量决定建库时长）；
  • 生态兼容：与向量库、框架（LangChain/LlamaIndex）的集成成熟度。

一个重量级提醒：Embedding 模型的更换 = 全库重嵌入 + 效果回归，是数据迁移级操作，宁可前期多花一周选对，也不要频繁换。

💻 全栈开发专家 ​

我选 Embedding 模型看六个硬指标，全部拿自己数据验证：

  1. 业务语料实测效果：MTEB/C-MTEB 只是初筛，用 100~200 条真实 query + 标注文档跑 recall@10 对比，最终以这个为准。
  2. 语言匹配：中文为主一定选中文优化或多语种模型（bge-m3、Qwen3-Embedding），用英文模型跑中文是常见翻车点。
  3. 维度与成本：1536/1024 维的存储和检索成本线性相关；支持 Matryoshka（套娃）降维更好，可 1024→256 逐步缩。
  4. 最大输入长度：chunk 是 512 token 还是 4k？长文档场景 m3（8192）有优势。
  5. 部署方式与许可：数据不能出域就选开源（Apache/MIT）本地部署；允许 API 就商用模型省运维。
  6. 检索模式兼容：是否需要稀疏向量/ColBERT 多向量（配合混合检索），bge-m3 一个模型全包。

实操顺序：圈定 3~5 个候选 → 各自灌 1 万条业务 chunk → golden set 评测 → 留 top 2 做 rerank 组合测试 → 定型。还有个隐性因素容易被忽略：吞吐和延迟。批量入库 500 万文档时，API 限流会拖垮你，自部署 GPU 或高并发 API 配额要提前谈好。