Embedding 模型选型与评估
RAG/语义搜索的质量，embedding 模型决定上限。但很多人随便选一个就上，效果不好还怪检索。本文讲清 embedding 选型的四个维度（语言/维度/领域/成本）、主流模型怎么挑，以及最重要的——怎么在自己的数据上评估，而不是迷信榜单。
本文要点
- 主题聚焦：大模型、RAG
- 适合人群：独立开发者、全栈工程师、AI 应用开发者
- 核心价值：快速理解背景、实践路径、常见误区和工程建议
RAG 的检索质量，链路里每一步都重要，但embedding 模型决定上限——再好的切分和 rerank，也救不了一个把相似内容编码得相距很远的 embedding。可惜很多人随便挑一个就用，效果不好就怪 rerank、怪切分，殊不知根子在 embedding。
这篇讲怎么选对 embedding。
一、选型四个维度
挑 embedding 模型，看四件事：
1. 语言支持。 你的内容是什么语言？
- 纯英文：选择多（OpenAI、Cohere、BGE-en）。
- 纯中文：选中文优化的（BGE-zh、m3e、通义/智源的中文模型）。
- 中英混合：选多语言模型（BGE-m3、Cohere multilingual、Jina multilingual）——别用纯英文模型硬上中文，召回会崩。
这是最常见的坑：用英文 embedding 处理中文，效果差一大截。语言匹配是第一原则。
2. 维度。 embedding 输出维度（768 / 1024 / 1536 / 3072）影响：
- 存储和检索成本：维度越高，向量越大，存储/计算越贵。
- 表达能力：通常维度越高表达越细，但边际递减。
- 1536（OpenAI small）是常见甜区；3072 多数场景没必要。
3. 领域适配。 通用 embedding 在专业领域（医疗、法律、代码）可能弱：
- 代码：选对代码友好的（如 voyage-code、Jina 对代码优化的版本）。
- 专业领域：通用不够时，考虑微调或领域专用 embedding。
4. 成本与部署。
- 商业 API（OpenAI/Cohere/Voyage）：省心，按 token 计费，但数据出境 + 依赖第三方。
- 开源自部署（BGE/Jina/m3e）：免费、数据自有，但要自己服务、有 GPU 成本。
二、主流模型大致图谱（2026）
| 类型 | 模型 | 适合 |
|---|---|---|
| 商业 API | OpenAI text-embedding-3 | 通用、英文好、中英可用 |
| Cohere embed v3 / multilingual | 多语言强 | |
| Voyage AI | 代码/领域优化、质量高 | |
| 开源 | BGE-M3 | 多语言、多粒度、综合强 |
| BGE-large-zh | 中文场景 | |
| Jina embeddings v3 | 长文本、多语言 | |
| m3e | 中文、轻量 |
榜单看 MTEB（Massive Text Embedding Benchmark），它是 embedding 界的 ImageNet。但——
三、最重要的：在自己数据上评估
MTEB 榜单不等于你的场景表现。 embedding 在公开基准上分高，不代表在你的领域/语言/查询分布上也好。所以选型最后一步必须是：在自己的数据上实测。
一套最小评估流程：
- 建检索评测集：50–200 条
query → 相关文档ID。 - 每个候选 embedding 跑一遍：用该 embedding 入库 + 检索评测集。
- 算指标：Recall@k（前 k 条里命中的比例）、MRR（倒数排名）、nDCG。
- 选综合最优，而非榜单最高。
# 伪代码
for model in [bge_m3, openai_3small, cohere_v3]:
embeddings = [model.embed(d) for d in docs]
for q, relevant in eval_set:
hits = vector_search(model.embed(q), embeddings, k=5)
recall += len(set(hits) & relevant) / len(relevant)
print(model, recall / len(eval_set))
这一步省不掉。我见过太多团队按 MTEB 选了"最高分"，结果在自己中文长文档场景召回率被一个榜单低的中文模型吊打。你的数据分布说了算。
四、几个被低估的点
1. 最大输入长度。 embedding 模型有输入上限（512 / 8192 token）。如果你切分的大于上限，要么截断（丢信息）要么换模型。长文档场景选输入长的（Jina、BGE-M3 支持 8K+）。
2. 指令前缀。 一些模型支持 instruction（如 BGE 的 "Represent this sentence for retrieving relevant documents:"）。query 和 doc 用不同指令，召回能提一截。别忽略这个特性。
3. 归一化。 多数模型要求用归一化向量算余弦。入库和查询都要归一化，别一边归一一边不归一，相似度会错。
4. 量化。 存储压力大时，向量量化（float32 → int8）能省 4 倍空间，质量损失通常可接受。pgvector/Qdrant 都支持。
五、要不要微调 embedding
通用 embedding 不够时，可以微调（用领域数据）。但微调 embedding 有门槛：
- 要"正负样本对"（相关/不相关文档对）。
- 要训练基础设施。
- 要评估验证。
先用领域专用模型（如代码用 voyage-code），不够再微调。多数场景领域专用模型已够，不必自训。
六、锁版本，别乱换
选定 embedding 后，长期锁定。换 embedding 维度变了，所有历史向量要重算（重新索引全量），代价大。所以选型时多花时间评估，选定后别轻易换。
小结
embedding 是 RAG 的地基，选型四步：
- 语言/领域匹配：中文用中文模型，代码用代码模型——别用通用英文模型硬上。
- 维度/成本权衡：1536 是甜区，3072 多数场景没必要。
- MTEB 参考，自己数据实测：榜单不等于你的场景，必须在自己评测集上对比 Recall/MRR。
- 锁版本：换 embedding = 全量重建索引，慎重。
记住一句：RAG 的天花板是 embedding 打的。 在 embedding 选型上多花一周评估，比之后花一个月调 rerank 和 prompt 更值。别在这步偷懒。
Related