Embedding 模型怎么选？选错它，RAG 天花板直接锁死

做 RAG 时大家的注意力都在生成模型上但真正决定检索质量上限的是 Embedding 模型——它负责把文档和问题变成可比的向量。选错了 Embedding后面重排序调得再花召回就是上不去。这篇聊选型的实操维度。为什么它这么重要RAG 的第一环是「把对的资料找回来」。用户问题和文档能否在向量空间里相遇完全由 Embedding 模型决定。生成模型再强拿不到资料也只能编。行业里的常见教训RAG 效果不好八成先去换了生成模型实际上该先看召回命中率。选型的四个维度一是中文能力与领域匹配。通用 Embedding 在通用语料上训练垂直领域医疗、法律、代码的表现要实测。中文场景优先看 C-MTEB 榜单BGE 系列是国内语境的稳妥选择开源免费、中文效果长期第一梯队。二是维度与存储成本。Embedding 维度从 384 到 3072 不等维度越高区分度越好但存储和检索成本线性上涨。百万级文档场景1024 维和 1536 维的体感差异很小存储成本差一半。三是长文本支持。文档切块通常几百字问题不大但如果你要直接嵌入长段落注意模型的最大输入长度很多是 512 token超了会被截断尾部信息直接丢失。四是部署形态。商用 API如 text-embedding 系列省心但按量付费、数据出境要评估开源模型本地部署零边际成本、数据不出门。企业内部知识库本地开源是默认答案。换模型的代价要提前想Embedding 模型一旦更换全部文档向量必须重建——百万级文档的重嵌入是一笔实打实的算力账还要处理新旧向量并存的过渡期。所以选型时想清楚这个模型能不能陪你走两年最后的忠告Embedding 的效果评估必须用自己的业务数据拿五十对「真实用户问题 对应文档块」测召回命中率比看任何榜单都实在。不同模型在同一份业务数据上的命中率差距经常大到直接决定选型。