为什么 Embedding 选型很重要

RAG 系统的天花板在很大程度上由 Embedding 模型决定。Embedding 不准，后面的 Rerank 和生成再厉害也救不回来。

中文场景比英文复杂：词的边界模糊、同义词多、行业术语差异大，对模型的理解力要求更高。

下面整理目前（2026 年初）值得选用的中文 Embedding 模型，按使用场景分类。

通用首选：BGE 系列

智源（BAAI）出品，目前中文 Embedding 的事实标准。

主力型号：

  • bge-large-zh-v1.5：1024 维，1.3GB，通用场景最佳
  • bge-base-zh-v1.5：768 维，400MB，性能/速度平衡
  • bge-small-zh-v1.5：512 维，100MB，资源受限场景

特点：

  • C-MTEB 中文榜单长期前列
  • 训练数据覆盖广，开箱即用
  • HuggingFace、ModelScope 都有，部署友好

典型用法：

from sentence_transformers import SentenceTransformer
model = SentenceTransformer('BAAI/bge-large-zh-v1.5')
embeddings = model.encode(texts, normalize_embeddings=True)

注意：BGE 在做相似度查询时，建议给 query 加前缀 "为这个句子生成表示以用于检索相关文章："，能提升 1-2 个点。

多语言场景：BGE-M3

如果业务有跨语言需求（中英混合查询、跨语言检索），BGE-M3 是最强选择。

核心特点：

  • 同时支持稠密向量、稀疏向量、ColBERT-style 多向量
  • 100+ 语言原生支持
  • 单模型出三种检索信号，下游融合方便

适合场景：

  • 跨境电商、出海业务
  • 中英文混合的技术文档检索
  • 需要多路召回的高级 RAG 系统

高性能选择：GTE 系列

阿里通义出品，性能在某些 benchmark 上反超 BGE。

主力型号：

  • gte-Qwen2-7B-instruct：7B 参数的 LLM-based embedding，性能极强
  • gte-large-zh：通用版，规模适中

LLM-based embedding 是 2025 年开始的趋势：用大语言模型本身做特征提取，能捕捉更细粒度的语义。代价是计算开销大，需要 GPU。

适合场景：

  • 对效果有极致要求、不在乎成本
  • 长文档、复杂查询
  • 已有 GPU 资源

商业 API：Cohere、OpenAI、智谱

不想自己部署可以调 API：

模型维度中文质量价格
OpenAI text-embedding-3-large3072良好$0.13 / 1M tokens
Cohere embed-multilingual-v31024良好$0.10 / 1M tokens
智谱 embedding-32048优秀0.5 元 / 1M tokens
阿里 text-embedding-v31024优秀0.7 元 / 1M tokens

经验法则：

  • 中文为主、对成本敏感：智谱或阿里
  • 多语言、技术文档：Cohere
  • 已经在用 GPT 生态：OpenAI

评估维度

不要看排行榜就下结论，自己业务上跑评估：

  1. 检索准确率（最重要）：在自己业务的标注数据上算 Hit@K、MRR、NDCG
  2. 同义词识别：测试同义改写、口语化、专业术语等
  3. 长文本压缩能力：1000 字段落的 embedding 是否还能精准检索
  4. 跨领域稳定性：在你的所有业务领域上效果是否一致
  5. 推理速度：单条 / 批量的 latency 和吞吐
  6. 维度成本：维度越高，向量库存储和检索成本越高

实战建议

新项目快速起步

直接用 bge-large-zh-v1.5 部署，搭配 bge-reranker-large 做 Rerank。这套组合已经能覆盖 90% 场景。

已有 RAG 想升级

按这个顺序尝试：

  1. 升级 Rerank 模型（最高性价比）
  2. 引入混合检索（BM25 + 向量）
  3. 升级 Embedding 模型（注意要重建索引）
  4. 加入 Query 改写

不要一次性全改，每步独立评估。

成本敏感场景

可以考虑双层架构：

  • 第一层用 small 模型快速召回 1000 条
  • 第二层用 large 模型精排 Top 100
  • 第三层用 Reranker 选 Top 10

兼顾速度和准确率。

一些不建议的做法

  • ❌ 维度盲目追求高：3072 维不一定比 1024 维好，但存储成本翻 3 倍
  • ❌ 用通用 embedding 处理代码检索：代码场景用专门的 code embedding（如 voyage-code-2、jina-code-v2）
  • ❌ 检索时不归一化：余弦相似度计算前必须 L2 归一化
  • ❌ 跨模型混用向量：升级模型时必须重建整个索引，不能新旧混存

趋势观察

2026 年值得关注的方向：

  • Matryoshka Embedding：一个模型输出可截断的多维度向量，灵活权衡精度和成本
  • 任务特化 Embedding：针对 RAG、聚类、分类等任务分别训练
  • 超长上下文 Embedding：32K、128K 上下文的 Embedding 模型陆续出现
  • 稀疏 + 稠密融合的端到端模型：BGE-M3 是开端，会有更多

总结

Embedding 选型没有银弹，先拿你自己的数据跑评估，再做决定。开源模型质量已经追上甚至超过商业 API，能自己部署就尽量自己部署 —— 数据安全、成本、延迟都更可控。