Appearance
5.1.4 Embedding 模型应该怎么选？
先给结论：Embedding 模型选型不能只看“排行榜谁更高”或“维度谁更大”，而要先看你的语言、领域、数据类型、延迟预算和检索目标是否匹配。
因为 embedding 模型不是越强越好，而是越适合当前任务越好。
选型前先问的 5 个问题
如果你准备选 embedding 模型，建议先问清这 5 个问题：
- 主要语言是什么，是中文、英文，还是多语言混合
- 数据类型是什么，是 FAQ、制度文档、代码、产品资料，还是混合知识库
- 检索目标是什么，是强调语义覆盖，还是强调术语精度
- 延迟和成本预算是多少，是否允许高维向量和大规模重算
- 数据是否稳定，后续会不会频繁更新和重建
这 5 个问题比“别人都用哪个模型”更重要。
一、先看语言匹配
这是最容易被忽略、但最该先看的因素。
如果你的主要语料是中文，就要特别关注：
- 中文语义表示是否稳定
- 中英混合时表现是否一致
- 术语、缩写、产品名在中文环境下是否容易失真
很多模型在英文表现不错，不代表在中文业务语料里也同样稳。
所以语言匹配通常应该排在非常靠前的位置。
二、再看任务匹配
不同 embedding 模型擅长的任务也不完全一样。
有的更适合：
- 通用语义检索
- 问答匹配
- 文档召回
有的可能更适合：
- 多语言检索
- 代码搜索
- 特定领域文本
所以你不能只问：
- 这个模型强不强
还要问：
- 它强在哪类任务上
- 和我当前的检索任务是不是同一种问题
三、看向量维度、成本和索引影响
向量维度越大，不一定效果就一定更好。
实际要一起考虑：
- 索引存储成本
- 写入和重建成本
- 查询延迟
- 向量库容量压力
尤其在知识库规模较大、更新又频繁的场景里，embedding 模型选型会直接影响：
- 全量重建成本
- 增量更新代价
- 长期运维预算
所以选型时不能只盯着召回分数，也要看系统层面的可维护性。
四、看是否匹配你的检索策略
如果你的系统是：
- 主要依靠向量检索做首轮召回
那么 embedding 模型的重要性会更高。
但如果你的系统是：
- 明确走 BM25 + 向量混合检索
- 对术语、编号、过滤边界要求很强
那么 embedding 模型虽然仍然重要，但它不再是唯一主角。
也就是说，选型要结合整个检索链路，而不是单看 embedding 这一层。
五、最好用真实问题集做小规模评估
真正稳的选型方式，通常不是拍脑袋决定，而是拿真实问题集做评估。
至少可以观察：
- 是否更容易召回正确文档
- 近义表达覆盖是否更稳
- 专有术语是否更容易误召回
- 中文问法变化下表现是否稳定
如果条件允许，可以准备一小批：
- 高频问题
- 易错问题
- 术语类问题
- 长尾问题
用这些问题去比较不同模型的召回效果，通常比只看公开榜单更接近真实情况。
一个更实际的选型顺序
如果你想把事情做得更稳，可以按这个顺序来：
- 先筛掉语言不匹配的模型
- 再筛掉成本和延迟明显不合预算的模型
- 选 2 到 3 个候选模型做小规模对比
- 用真实问题集看召回质量和误召回模式
- 结合后续索引成本和维护成本做最终决定
这样选出来的模型，通常比“谁最火就用谁”更稳。
一个常见误区
很多人会用下面这些标准直接拍板：
- 维度越大越好
- 排行榜越高越好
- 别人说某个模型最强就直接跟
这些标准都不够。
因为真实系统里更常见的失败原因是：
- 语言不匹配
- 任务不匹配
- 成本扛不住
- 召回模式和实际业务问题不一致
所以更稳的选型，不是找“理论上最强”的模型，而是找“在你当前数据和问题上最合适”的模型。
一句话总结
Embedding 模型选型要优先看语言、任务、成本、检索链路和真实问题集表现，而不是只看排行榜或维度大小。最好的模型不一定是公开最强的那个，而是最适合你当前知识库和检索目标的那个。