腾讯微信多模态嵌入模型开源：wemm-embedding

Embedding 模型选型完整指南

核心选型维度：​语言能力、向量维度、检索精度、速度、显存/内存开销、业务场景、长短文本、多语言、是否支持量化​。

国内RAG绝大多数场景优先选中文优化模型，不要盲目用OpenAI ada‑002。

一、先明确你的业务约束（选型前先回答4个问题）

1. ​主要文本是什么​：中文文档？中英混合？表格、代码、PPT摘要、扫描OCR文本？
2. ​数据规模​：十万级chunk / 百万级 / 千万级chunk？硬件显存多少？
3. ​检索目标​：高精度召回（企业知识库），还是快速轻量（对话机器人）？
4. ​部署方式​：API调用（OpenAI/硅基流动等），还是本地私有化部署？

二、主流模型对比（中文RAG最常用）

重点：​向量维度≠效果越好​。维度越高：向量磁盘占用越大、检索速度越慢、索引构建更耗内存。1024维已经足够绝大多数中文企业RAG。

三、关键评估指标怎么看

1、上下文窗口（max_seq_len）

• bge‑large‑zh‑v1.5 默认 512 token；​chunk不要超过模型最大输入长度​，否则会截断丢失信息。

• 如果你的chunk设置1024、2048 tokens，必须选支持长上下文embedding：jina、bge‑m3。

  坑：很多人 chunk_size=1000，还用bge‑large‑zh(512上限)，输入直接截断，检索效果暴跌。

2、检索精度

评测集：CMTE、C‑MTEB（中文嵌入评测榜）

• C‑MTEB分数越高，中文检索能力越强。

  但是：榜单分数只是参考！​你的业务数据才是金标准​。一定要拿自己真实文档做召回测试。

3、硬件&存储代价（结合你前面100GB文档场景）

以bge‑large‑zh‑v1.5（1024维）

• float32单向量：4KB；SQ8量化后向量2KB

• bge‑small‑zh（512维）float32单向量：2KB，SQ8后1KB

  维度减半，向量库磁盘占用直接减半，检索速度提升。

4、推理速度

• 小模型：chunk编码速度快，大批量构建向量库耗时短；
• 百万级以上chunk，优先考虑推理速度，不然建库跑几天。

四、分场景选型建议

场景1：企业私有化知识库（PDF/Word/PPT/Excel，合同、研报、制度文档）【最常见】

✅ 推荐：bge‑large‑zh‑v1.5

• chunk_size建议：400‑512 tokens，不要超过512；
• 如果经常有超长文档片段，切换：bge‑m3 / jina‑zh‑v2

场景2：资源有限，服务器显存小（8G显存以内），百万chunk以内

✅ 推荐：bge‑small‑zh / m3e‑base牺牲一点精度，换取速度与资源。

场景3：大量长文本，大chunk（800‑2048 token），法律、标书、年报

✅ 推荐：jina‑embeddings‑zh‑v2 、bge‑m3

不能用原版bge‑large‑zh‑v1.5，会截断。

场景4：中英混合文档

✅ 推荐：bge‑m3，jina‑zh‑v2；不优先ada‑002。

场景5：不想本地部署，直接API调用

✅：OpenAI text‑embedding‑3‑small；国内：硅基流动、通义千问embedding API。

五、实操落地最佳实践

1. 不要只靠embedding提升效果，Embedding负责召回，再搭配Reranker重排模型做二次过滤

   典型组合：bge‑large‑zh‑v1.5 embedding + bge‑reranker‑large；召回top‑10，rerank取top‑3，效果提升巨大。

2. 必须做业务自测简单自测流程： 1）拿10‑20个真实用户提问； 2）看top‑3检索结果是否包含答案原文； 3）换2‑3个embedding模型对比召回结果，选出在你文档上表现最好的，不要迷信榜单。

3. 向量库开启量化 Milvus/Qdrant SQ8量化，​几乎不损失检索效果，磁盘减半，强烈生产开启​。

4. 避坑清单

• ❌ chunk size > embedding模型max_seq_len；
• ❌ 中文业务盲目选用ada‑002；
• ❌ 一味追求高维度模型，造成存储和索引压力暴涨；
• ❌ 只看C‑MTEB榜单，不在自有业务数据验证。