文本 Embedding 模型怎么选？维度、中文效果和成本怎么看？
选模型前，先搞清楚你要解决什么问题
上篇我们聊完向量空间和余弦相似度，你应该已经理解了一件事：Embedding 就是把文字"翻译"成一串数字，这串数字的"距离"决定了文字的相似程度。
道理懂了，但新问题来了。
现在市面上的模型多得很，OpenAI 有 text-embedding-v3，国产有 BGE、M3，同样是把文字变成向量，输出维度有的 1024 维，有的 2048 维，价格差了好几倍。怎么选？
今天就帮你把选型逻辑理清楚。
Embedding 是什么？它解决什么问题？
先快速过一遍基础概念。
Embedding 本质上是一个转换器。你喂进去一段文字，它吐出来一串数字。关键是：语义相近的内容，转换后这串数字也"长得像"。
这么说还是有点抽象。换个思路：
想象你给图书馆的每本书都发一张"指纹卡"。两本书内容越相似，指纹就越像。你不需要一个字一个字地比对，只要把指纹往机器上一放，相似度数值就出来了。
Embedding 就是那个生成指纹的过程，而指纹上的纹路——就是那串数字。
这个能力是 RAG、语义搜索、文本分类这些功能的底层支撑。没有 Embedding，这些系统就无从谈起。
四个主流模型横评：参数差距一目了然
选模型跟买车差不多，你得看几个核心参数。
维度是最直观的指标。维度越高，模型对语义的理解越精细。1024 维和 2048 维听起来差不多，但处理方式和对细节的捕捉能力确实有差距。
不过，高维度也意味着更高的存储和计算成本。你需要在"效果"和"成本"之间找平衡。
输入长度是第二个关键参数。大部分模型的输入上限是 512 tokens，大概对应 300-400 个中文字。一旦文档超过这个长度，要么截断，要么就得换模型。
BGE-v1.5 就是个典型例子，512 tokens 是它的硬上限。长文本用户得绕道走。
成本方面，API 调用和自部署差别很大。用 API 按量付费，500 万 token 差不多 3.5 元；自部署则是一次性 GPU 投入，适合调用量特别大的场景。
| 模型 | 输出维度 | 最大输入 | 成本特点 |
|---|---|---|---|
| text-embedding-v3 | 1536 | 长文本支持 | API 按量付费 |
| bge-large-zh-v1.5 | 1024 | 512 tokens | 开源免费 |
| embedding-3 | 1024/2048 | 长文本支持 | API 按量付费 |
| bge-m3 | 1024 | 8192 tokens | 开源免费 |
选哪个？不是越贵越好，也不是维度越高越强。得看你的场景。
中文效果怎么判断？四个维度讲清楚
参数是死的，效果才是关键。
中文 Embedding 的评测绕不开这四个维度：
多义词消歧。比如"苹果"，在水果文案里是一个意思，在手机评测里是另一个意思。模型能不能根据上下文准确理解？
同义表达。口语说"多少钱"，书面语写"价格是多少"，Embedding 应该识别出来这是同一件事。
网络用语和专有名词。"996"、"内卷"、"干饭人"这些词，模型能不能正确理解？这考验的是模型训练语料的丰富度。
繁简混用。有些企业文档里繁简体混着来，模型能不能正确处理？这一点对港台和海外业务场景尤其重要。
把中文效果想象成一场"方言考试"。能同时听懂普通话、网络用语、行业黑话的模型，才是真正的高手。
怎么验证？最笨的办法：找一批你业务场景的真实语料，跑几个测试 query，看召回结果靠不靠谱。
场景化选型：API 还是自部署？
核心问题来了：数据要不要出网？
这是选型的第一个分叉口。
如果数据可以出网——比如做的是公开内容的语义搜索，或者对接的是用户主动提交的数据——API 方案是首选。
按量付费，3.5 元 500 万 token，成本可控。没有 GPU 运维的麻烦，效果也有大厂背书。
如果数据必须留在内网——比如企业知识库、医疗记录、财报数据——那就只能自部署。
开源模型里 BGE-m3 是个不错的选择，支持 8192 tokens 的超长文本，多语言能力也强。但你得有自己的 GPU 服务器和运维团队。
接下来看调用量。
500 万 token/月是个分水岭。在这个量级以下，API 的性价比明显更高；超过这个量级，自部署的均摊成本才开始显现优势。
最后看文档平均长度。
文档动不动就几千字？那 text-embedding-v3 和 embedding-3 更适合，它们对长文本的支持更好。文档普遍不长，那选哪个都差不多。
做决策其实就三步：先问数据能不能出去，再看月调用量大小，最后看文档长不长。
实战建议：量小先用 API，量大了再迁移
给个实在的建议：起步阶段，先用 API 验证效果。
500 万 token 以内，没必要自建。买个套餐试试水，看召回效果达不达标，不行就换模型。确认这个工具真的适合你，再考虑迁移。
这里有个坑要提醒：很多场景下召回效果差，不一定是模型不行，而是切块策略出了问题。
文档切成 500 字一块还是 1000 字一块？块与块之间要不要有重叠？这些都会直接影响 Recall@K 这个指标。
一般企业知识库场景， Recall@K 需要达到 0.8 以上才合格。达不到就先调 chunk size，调完还不行再换模型。
最后给个成本参考：假设月调用量 1000 万 token，API 成本大概 7 元/天，一年 2500 左右。自部署的话，一块 H100 显卡的月租就得好几千。量级不够的时候，真没必要折腾。
选型没有标准答案，关键是优先级要理清
说了这么多，不是为了给你一个"标准答案"。
选 Embedding 模型，核心是回答三个问题：
- 我的数据能不能出网？
- 我的月调用量大概是多少？
- 我的文档平均有多长？
把这些问题回答了，选型方向就清晰了。
至于具体用哪个模型、要不要微调、chunk size 怎么定——这些是后面要精细化的事情。先跑起来，在实际业务里验证效果，比纸上谈兵强得多。
对了，下一篇我们会聊 Embedding 在 RAG 系统里是怎么串起来的。选好模型只是第一步，怎么把它用好才是关键。
敬请期待。