【学习笔记】如何选择 Embedding 模型？从维度、中文能力到成本-07

        很多团队选择 Embedding 模型时，第一反应是看一个排行榜，或者直接使用项目示例里出现的模型。

        但Embedding是检索系统的基础。一旦模型选定，文档会按它的方式被向量化，向量库会围绕它设置维度和索引，后续更换模型往往意味着重新生成全量向量。

        所以，Embedding 选型不能只问“哪个模型分数最高”，而要问：

哪个模型最适合我的语言、数据、检索目标、部署约束和预算？

        还要增加一个工程问题：这个模型准备以什么方式运行？模型选型不仅决定召回质量，也决定 GPU 显存、批处理吞吐、API 依赖、数据是否出域和后续重建向量的时间。

        一、先明确 Embedding 模型的任务

        Embedding 模型不是一个单一用途的组件。常见任务包括：

        同一个模型在通用语义检索上表现不错，不代表它适合代码搜索或商品推荐。先确定任务，再看模型。

        二、维度不是越高越好

        Embedding 输出的向量可能是几百维、上千维甚至更多。维度越高，理论上可以表达更复杂的空间结构，但也会带来成本：

•  单条向量占用更多存储；

•  索引构建和查询计算量增加；

•  网络传输数据变大；

•  Milvus、pgvector 等系统需要更多内存；

•  批量导入和备份时间增加。

        一个简单的存储估算是：

向量存储量 ≈ 向量数量 × 维度 × 每个元素字节数

        如果使用 32 位浮点数，每个元素通常占 4 字节。100 万条 1536 维向量，仅原始向量数据就约为：

1,000,000 × 1,536 × 4 ≈ 6.1 GB

        这还没有计算索引、元数据、副本和存储系统开销。

        因此，维度应该与召回质量、延迟和成本一起评估，而不是单独追求更大的数字。

        三、中文能力要用真实中文数据验证

        如果系统主要服务中文用户，不能只看英文公开榜单。中文检索可能包含：

•  简体中文和繁体中文混杂；

•  中英文缩写和产品名称；

•  数字、单位、版本号和日期；

•  行业术语、内部简称和部门黑话；

•  口语提问与正式制度文本之间的表达差异。

        例如，用户问：

“入职不满一年，年假怎么算？”

        文档可能写成：

“新入职员工当年度应休年休假，按照在本单位剩余日历天数折算确定。”

        好的模型应该能识别两者的业务关系，而不是只匹配“年假”三个字。

        评测时要使用真实中文问题、真实文档和真实的相关性标注，不能用几组人工编写的同义句替代。

        四、查询向量与文档向量是否对称？

        有些 Embedding 模型把查询和文档视为相同类型的文本；有些检索模型则会针对查询和文档使用不同的编码方式，甚至要求加入不同的前缀。

        常见形式包括：

query: 用户提出的问题
passage: 知识库中的文档片段

        这不是可以随意添加的提示词。是否需要前缀、使用什么前缀，必须以模型卡片或官方文档为准。

        如果建库时使用了文档模式，查询时却按普通文本编码，向量空间可能失配，最终表现为“向量库有答案，但检索不到”。

        五、最大输入长度会影响切分策略

        每个 Embedding 模型都有输入长度限制。文档片段超过限制时，可能被截断、报错或需要拆分。

        这会直接影响 Chunk 设计：

•  Chunk 太小，语义上下文不完整；

•  Chunk 太大，容易超过模型限制或稀释主题；

•  重叠太多，会增加向量数量和重复检索结果；

•  没有按标题、段落和表格边界切分，语义可能被破坏。

        Embedding 模型选型和文本切分不能分开做。应先确认模型限制，再用真实文档测试切分后的召回表现。

        六、API 模型、本地模型和混合方案

        6.1 API 模型

        优点：

•  接入速度快；

•  不需要自行维护推理服务；

•  模型升级和扩容由服务商承担。

        需要考虑：

•  按调用量付费；

•  网络延迟和服务可用性；

•  数据是否允许发送到外部服务；

•  服务商接口、区域和合规要求。

        6.2 本地部署模型

        优点：

•  数据可以留在内网；

•  调用成本更可控；

•  可自行管理版本和服务策略。

        需要承担：

•  GPU 或 CPU 资源；

•  推理服务部署和升级；

•  并发、队列、监控和故障处理；

•  模型文件、依赖和安全管理。

        6.3 混合方案

        可以按数据敏感度和任务类型混合使用：

敏感合同、客户数据 → 内网 Embedding 服务
公开资料、低敏内容 → 外部 API

        但混合方案要注意向量空间隔离：不同模型生成的向量不能直接放在同一个索引里进行无条件比较。

        6.4 模型服务需要单独评估什么？

        不要只测单条文本。Embedding 服务通常会对批量请求做 padding，长度差异很大的文本放在同一批中可能浪费算力。应分别测试短查询、长 Chunk、混合语言和不同批量大小。

        七、如何比较调用成本？

        Embedding 成本通常与输入文本量、调用次数、模型价格和重建频率有关。

        可以粗略估算：

总成本 ≈ 建库文本 Token × 单价
      + 查询次数 × 平均查询 Token × 单价
      + 文档更新产生的重复向量化成本

        不要只估算首次建库成本。企业文档会更新，知识库会重建，用户搜索会持续发生，查询成本可能长期超过一次性索引成本。

        同时还要计算基础设施成本：

•  向量存储；

•  索引内存；

•  本地模型推理资源；

•  消息队列和 Worker；

•  备份、日志和监控。

        八、模型评测不能只看“最相似的一条”

        建议建立一个小型评测集：

问题 Q1 → 相关文档 D1、D2
问题 Q2 → 相关文档 D7
问题 Q3 → 没有答案

        对每个 Embedding 模型执行相同的建库和查询，比较：

•  Recall@K：前 K 条里是否出现相关文档；

•  MRR：第一个相关文档排在多前面；

•  nDCG：多条结果的相关性排序是否合理；

•  无答案问题的误召回情况；

•  查询延迟和吞吐；

•  向量生成耗时与成本。

        还要测试困难样本：

•  同义表达；

•  否定和条件；

•  长问题；

•  版本号和错误码；

•  相似主题但不同结论；

•  中英文混合；

•  无答案问题。

        九、模型升级为什么不是改一个配置就结束？

        假设原来使用模型 A，新模型 B 的维度相同。也不能直接把一部分 A 向量和一部分 B 向量混在一个索引里比较。

        原因是两个模型生成的向量空间没有天然对齐。即使维度一样，坐标含义和距离分布也可能完全不同。

        更稳妥的升级流程是：

保留旧索引
  ↓
用新模型重新生成全量向量
  ↓
建立新 Collection 或新索引
  ↓
使用同一评测集比较质量和成本
  ↓
灰度切换查询流量
  ↓
确认稳定后再下线旧索引

        如果文档量很大，可以通过双写、后台重建和按租户灰度等方式降低切换风险。

        十、Embedding 选型常见误区

        误区一：只看维度

        维度高不等于中文语义更好，也不等于业务召回更准确。

        误区二：只看公开榜单

        榜单数据集、语言、任务和指标可能与你的业务完全不同。

        误区三：忽略查询与文档的编码差异

        检索模型的前缀和输入方式往往是效果的一部分。

        误区四：建库时一个模型，查询时另一个模型

        除非模型明确保证空间兼容，否则不能这样做。

        误区五：只测有答案的问题

        知识库无法回答的问题同样重要。系统应该知道什么时候不应该召回或生成确定答案。

        十一、一个可执行的选型流程

确定语言和业务场景
  ↓
收集真实文档和问题
  ↓
筛选 2～4 个候选模型
  ↓
固定切分、指标和 Top K
  ↓
比较 Recall、MRR、延迟和成本
  ↓
测试无答案、权限和版本场景
  ↓
选择上线模型并记录版本
  ↓
为未来重建和回滚保留方案

        十二、上线前检查清单

• 明确模型用于检索、聚类、推荐还是其他任务；

•  使用真实中文或业务数据评测；

•  确认向量维度、最大输入长度和距离指标；

•  确认查询与文档的编码方式；

•  估算建库、查询和重建成本；

•  确认 API 或本地部署的合规要求；

•  记录模型名称、版本和配置；

•  升级时建立新索引，不混用不同模型向量；

•  保存旧索引，支持灰度和回滚；

•  评测无答案问题和相似但错误的文档。

•  已测试批量吞吐、P95 延迟和失败重试；

•  已记录模型、Tokenizer、维度、距离和归一化配置；

•  已设计模型升级时的新旧向量隔离方案；

        十三、结语：最合适的模型来自真实评测，不来自名词热度

        Embedding 选型不是一次性的模型采购，而是对语言、数据、检索目标和工程约束的综合判断。

        维度决定资源成本，中文能力决定基础召回，输入长度影响切分，部署方式影响合规和运维，版本管理影响未来迁移。只有把这些因素放到同一套评测流程里，选择才有意义。

        下一篇我们继续讨论两阶段检索中的关键角色：

        《Reranker 重排序是什么？为什么向量检索后还要再排一次》

参考资料

7.如何选择 Embedding 模型？从维度、中文能力到成本