Embedding 模型怎么选：RAG 场景选型指南
做 RAG 第一步就卡在选 embedding 模型：维度、价格、上下文长度、多语言支持怎么权衡？这篇给出一条可执行的选型路线，附接入代码和评测方法，避免拍脑袋换模型。
做 RAG（检索增强生成）的第一步不是买向量数据库，是选 embedding 模型。选错模型的代价是隐性的：检索召回率上不去，你怀疑分块策略、怀疑数据库、怀疑提示词，最后才发现根因是向量化这一环。而换 embedding 模型意味着整库重灌，动一次成本不低。
这篇给一条可执行的选型路线：先定维度约束，再按语言和成本缩小范围，最后用自己的一百条数据实测，别信排行榜。
先说结论
- 中英文混合、通用文档检索：闭源 API 模型（如 text-embedding-3 系列）开箱即用，效果稳定
- 中文为主、追求性价比：国产开源向量化模型（bge、qwen 系列 embedding）自托管或走 API 都行
- 预算敏感、数据量大：小维度模型足够，别为用不上的精度多付钱
- 已经选定模型就别频繁换：换模型的收益通常不如优化分块和检索策略
选型四个硬指标
| 指标 | 说明 | 决策要点 |
|---|---|---|
| 维度 | 向量长度，如 1024、1536、3072 | 维度越高存储和计算越贵，但可截断（MRL 支持） |
| 上下文长度 | 单次能编码的文本长度 | 长文档分块后 512–1024 tokens 足够，超长上下文是锦上添花 |
| 多语言 | 中英混合检索是否保持召回率 | 中文场景重点验证，不少模型英文强中文弱 |
| 价格 | 每百万 tokens 的向量化成本 | 一次性灌库 + 增量查询，通常远低于生成成本 |
一个容易被忽略的事实：embedding 的成本通常只是 chat 成本的零头。以 text-embedding-3-small 这类小维度模型为例，灌一个十万文档的知识库，成本往往不到一次 GPT-4 级摘要的钱。所以选型的主要矛盾不是价格，是召回质量和换模型的迁移成本。
常见候选怎么分
闭源 API 系列（OpenAI 兼容接口可调）：
text-embedding-3-small：1536 维，性价比首选，多语言表现合格text-embedding-3-large：3072 维，精度更高，适合对召回率苛刻的场景- 国产模型生态里 bge 系列、qwen 系列的 embedding 模型，中文表现普遍更强
开源自托管：
- bge-m3：多语言、长上下文，社区生态成熟，是自托管的事实标准之一
- 适合数据敏感、不能出内网的团队；代价是要自己管 GPU 和推理服务
具体模型清单和挂单价见 价格页，以实时价格为准。
接入代码：OpenAI 兼容接口
embedding 接口同样遵循 OpenAI 兼容协议，一个 base_url 搞定（协议原理见 OpenAI 兼容协议详解）：
from openai import OpenAI
client = OpenAI(
api_key="sk-你的密钥",
base_url="https://api.zaimod.com/v1",
)
resp = client.embeddings.create(
model="text-embedding-3-small",
input=["如何配置 API 密钥", "支持哪些付款方式"],
)
vectors = [d.embedding for d in resp.data]
print(len(vectors), len(vectors[0])) # 2 1536批量灌库时把多个文本放进一个 input 列表，一次请求批量编码，比逐条请求快得多也省得多。注意单请求 token 总量有上限，分批即可。
换模型只需改 model 参数——但向量维度变了整库必须重灌，这也是前面说「别频繁换」的原因。
用自己的数据实测：一百条就够
排行榜在通用基准上好看，不代表你的业务文档检索效果好。用一小时做一个小评测：
- 从知识库挑 50–100 条真实文档片段，人工为每条写 1–2 个「用户会怎么问」的查询
- 记录每个查询对应的正确片段 ID
- 分别用候选模型向量化，算 Top-3 / Top-5 命中率
def hit_rate(query_vecs, doc_vecs, labels, k=3):
hits = 0
for qv, gold in zip(query_vecs, labels):
sims = cosine_scores(qv, doc_vecs)
top_k = sorted(range(len(sims)), key=lambda i: -sims[i])[:k]
if gold in top_k:
hits += 1
return hits / len(labels)两个候选模型命中率差距不到 3% 时，选便宜的那个，把时间花在分块策略上。
RAG 效果不好，先排查这三处
实际项目里，检索质量差的原因排序大致是：
- 分块不合理：块太大稀释语义，块太小丢失上下文。从 512 tokens 加 15% 重叠起步
- 查询和文档风格不一致：用户问句口语化，文档是书面语，中间加一层「查询改写」往往立竿见影
- embedding 模型不匹配：以上都排除了，再考虑换模型
先调前三者再动模型，因为换模型的代价是整库重建。
常见问题
Q：text-embedding-3-large 一定比 small 好吗？
通用基准上是的，但你的数据上未必。用上面的百条评测验证，很多场景 small 的 Top-3 命中率和 large 差距很小，而成本和存储低不少。
Q：已经灌了 100 万条向量，换模型代价有多大？
就是重灌一遍：重新调用 embedding 接口 + 重建索引。按批量请求算，几小时能完成，主要成本是 tokens 费用和时间。做好「模型-维度-库版本」的元数据记录，重灌才不慌。
Q：embedding 模型和 chat 模型必须同一家吗？
不需要。embedding 和生成是两个独立环节，分别选型即可，OpenAI 兼容协议下本来就可以混搭。
Q：中文场景闭源和开源怎么选？
能出内网就先测 API 的闭源模型，中文知识库用 bge、qwen 系列对比一遍，用实测命中率说话。数据不能出内网则只能自托管开源模型。
延伸阅读
- 2026 大模型 API 价格对比：主流模型实测数据
- OpenAI API Key 怎么购买：国内开发者完整指南
- 月预算 50 美元的大模型组合方案：主力+廉价+免费档
- 注册账户，开通后即可调用全部 embedding 模型