选Embedding模型只看MTEB分数？实际场景要考虑5个维度
搭RAG系统的时候，Embedding模型的选择直接决定检索质量。很多人打开MTEB排行榜，选个分数最高的就完事了。但实际跑起来发现召回率不达标、成本超预算、多语言场景效果差，根本不是那么回事。
MTEB分数只是参考。真正影响你选择的是维度、速度、价格、语言支持和上下文长度这五个因素。这篇文章拆开讲，帮你避坑。
MTEB排行榜怎么看
MTEB（Massive Text Embedding Benchmark）是Hugging Face维护的Embedding模型评测基准，覆盖56个任务、涵盖检索、分类、聚类、句子相似度等场景。排行榜地址在huggingface.co/spaces/mteb/leaderboard。
看排行榜有个关键细节：分数是各任务的加权平均。某个模型总分很高，但具体到”检索”这个子任务可能排名靠后。做RAG系统最该关注的是Retrieval这一列，不是总分。
举个例子，BGE-large-en-v1.5在MTEB总分上排名前五，但它的检索任务分数（59.89）比text-embedding-3-large（55.45）高。可如果你的文档是中英混合的，text-embedding-3-large的多语言能力反而更好。场景不同，结论不同。
维度：不是越高越好
Embedding维度从384到8192不等。直觉上维度越高信息越丰富，检索越精准。但实际不是这样。
OpenAI的text-embedding-3-large默认3072维，但他们官方文档里提到可以用shortening降到256维，在MTEB上的分数只下降约1%。这说明高维信息存在冗余。维度翻倍带来的精度提升可能只有1%-2%，但存储和计算成本线性增长。
选择原则：文档量小（1万条以下）选高维度无所谓。文档量大（10万条以上），维度对向量数据库的内存占用影响显著。3072维的10万条文档，按float32算需要约1.2GB内存。降到1536维只要600MB。
速度和价格：批量处理的关键
Embedding生成是一次性成本（文档入库时），但查询时的Embedding生成是实时成本。两者都要算。
OpenAI的text-embedding-3-small定价是每百万token 0.02美元，text-embedding-3-large是0.13美元。差了6.5倍。如果用large处理100万字（约75万token），花费约0.1美元。听着不多，但如果要做增量更新、频繁rebuild，成本会累积。
速度方面，OpenAI API的Embedding端点吞吐量大约每秒处理3000-5000 token。10万字的文档库约7.5万token，20秒能处理完。自托管模型如BGE-large-en-v1.5在单张A10 GPU上吞吐量可达每秒1万token以上，批量处理更快。
多语言：别用通用模型硬撑
如果你的文档包含中文，选模型要特别注意。不是所有模型都能处理中文。
MTEB排行榜上有单独的C-MTEB（中文）子榜。BGE-large-zh-v1.5在中文检索任务上表现很好，而BGE-large-en-v1.5在中文上明显退化。OpenAI的text-embedding-3-small和large支持多语言，但中文检索准确率不如专门的中文模型。
如果文档是纯中文，选BGE-zh系列或M3E。如果是中英混合，text-embedding-3-large或BGE-M3（支持多语言）更合适。
上下文长度：长文档怎么处理
Embedding模型的输入长度限制容易被忽略。text-embedding-3-small和large都支持8191 token，约6000字英文。BGE-large-en-v1.5最大512 token，BGE-M3支持8192 token。
512 token意味着一个几KB的文档必须切成小块。切块策略直接影响检索效果。块太小丢失上下文，块太大超出模型限制。
对于长文档，推荐的做法是：先用512 token的窗口滑动切分（重叠50-100 token），每块单独生成Embedding，查询时取Top-K块拼接喂给LLM。如果模型支持长输入（如8191 token），可以减少切分次数，但单个Embedding可能丢失文档内的细节信息。
实操对比：4个主流模型
把上面五个维度汇总，对比4个最常用的模型：
- text-embedding-3-small（OpenAI）：1536维，0.02美元/百万token，8191 token输入，多语言。适合快速起步、成本敏感场景。
- text-embedding-3-large（OpenAI）：3072维，0.13美元/百万token，8191 token输入，多语言。适合对精度要求高、预算充足的项目。
- BGE-large-en-v1.5（智源）：1024维，自托管免费，512 token输入，英文为主。适合英文文档、需要数据私有化、有GPU资源的团队。
- BGE-M3（智源）：1024维，自托管免费，8192 token输入，多语言。适合长文档、中英混合、需要稠密+稀疏+ColBERT三路检索的场景。
选型决策框架
别纠结哪个模型”最好”。问自己三个问题：
第一，文档是什么语言？纯英文选BGE-en或text-embedding-3-small。纯中文选BGE-zh。混合选text-embedding-3-large或BGE-M3。
第二，数据能不能发出去？合规要求高的选自托管模型。没限制的用API省事。
第三，预算和规模多大？1万条文档以下，随便选。10万条以上，仔细算存储和查询成本。100万条以上，维度和托管方式的选择直接影响每月账单。
选定之后，用你自己的数据跑个A/B测试。准备20-30个真实查询，对比两个模型的Top-5召回率。这比看任何排行榜都有用。MTEB是别人的数据，你自己的数据才是真实场景。
从零开始的3步实施路径
第一步，用text-embedding-3-small快速搭原型。价格便宜，多语言支持，API调用简单。先跑通整个RAG流程再说。
第二步，收集真实查询和反馈。记录用户问了什么、哪些结果不相关、哪些查询命中率低。这些数据是你后续优化的基础。
第三步，根据问题针对性优化。如果中文效果差，换BGE-zh。如果成本太高，评估自托管BGE-M3。如果长文档检索不准，调整切块策略或换长输入模型。不要一次性优化所有维度，一个问题一个问题来。
Embedding模型不是一锤子买卖。随着数据量和用户需求变化，选型也需要迭代。关键是先跑起来，再持续优化。
