很多团队选择 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 模型服务需要单独评估什么指标需要观察的实际问题吞吐批量入库每分钟能处理多少 Chunk高峰期是否排队延迟单条查询 P50/P95 是否满足在线问答要求资源CPU/GPU、显存、内存和模型加载时间稳定性超时、限流、重试和服务重启后是否可恢复版本模型文件、Tokenizer、维度和归一化配置是否可追踪合规文档是否允许发送到外部 API日志是否会泄露原文不要只测单条文本。Embedding 服务通常会对批量请求做 padding长度差异很大的文本放在同一批中可能浪费算力。应分别测试短查询、长 Chunk、混合语言和不同批量大小。七、如何比较调用成本Embedding 成本通常与输入文本量、调用次数、模型价格和重建频率有关。可以粗略估算总成本 ≈ 建库文本 Token × 单价 查询次数 × 平均查询 Token × 单价 文档更新产生的重复向量化成本不要只估算首次建库成本。企业文档会更新知识库会重建用户搜索会持续发生查询成本可能长期超过一次性索引成本。同时还要计算基础设施成本向量存储索引内存本地模型推理资源消息队列和 Worker备份、日志和监控。八、模型评测不能只看“最相似的一条”建议建立一个小型评测集问题 Q1 → 相关文档 D1、D2 问题 Q2 → 相关文档 D7 问题 Q3 → 没有答案对每个 Embedding 模型执行相同的建库和查询比较RecallK前 K 条里是否出现相关文档MRR第一个相关文档排在多前面nDCG多条结果的相关性排序是否合理无答案问题的误召回情况查询延迟和吞吐向量生成耗时与成本。还要测试困难样本同义表达否定和条件长问题版本号和错误码相似主题但不同结论中英文混合无答案问题。九、模型升级为什么不是改一个配置就结束假设原来使用模型 A新模型 B 的维度相同。也不能直接把一部分 A 向量和一部分 B 向量混在一个索引里比较。原因是两个模型生成的向量空间没有天然对齐。即使维度一样坐标含义和距离分布也可能完全不同。更稳妥的升级流程是保留旧索引 ↓ 用新模型重新生成全量向量 ↓ 建立新 Collection 或新索引 ↓ 使用同一评测集比较质量和成本 ↓ 灰度切换查询流量 ↓ 确认稳定后再下线旧索引如果文档量很大可以通过双写、后台重建和按租户灰度等方式降低切换风险。十、Embedding 选型常见误区误区一只看维度维度高不等于中文语义更好也不等于业务召回更准确。误区二只看公开榜单榜单数据集、语言、任务和指标可能与你的业务完全不同。误区三忽略查询与文档的编码差异检索模型的前缀和输入方式往往是效果的一部分。误区四建库时一个模型查询时另一个模型除非模型明确保证空间兼容否则不能这样做。误区五只测有答案的问题知识库无法回答的问题同样重要。系统应该知道什么时候不应该召回或生成确定答案。十一、一个可执行的选型流程确定语言和业务场景 ↓ 收集真实文档和问题 ↓ 筛选 24 个候选模型 ↓ 固定切分、指标和 Top K ↓ 比较 Recall、MRR、延迟和成本 ↓ 测试无答案、权限和版本场景 ↓ 选择上线模型并记录版本 ↓ 为未来重建和回滚保留方案十二、上线前检查清单明确模型用于检索、聚类、推荐还是其他任务使用真实中文或业务数据评测确认向量维度、最大输入长度和距离指标确认查询与文档的编码方式估算建库、查询和重建成本确认 API 或本地部署的合规要求记录模型名称、版本和配置升级时建立新索引不混用不同模型向量保存旧索引支持灰度和回滚评测无答案问题和相似但错误的文档。已测试批量吞吐、P95 延迟和失败重试已记录模型、Tokenizer、维度、距离和归一化配置已设计模型升级时的新旧向量隔离方案十三、结语最合适的模型来自真实评测不来自名词热度Embedding 选型不是一次性的模型采购而是对语言、数据、检索目标和工程约束的综合判断。维度决定资源成本中文能力决定基础召回输入长度影响切分部署方式影响合规和运维版本管理影响未来迁移。只有把这些因素放到同一套评测流程里选择才有意义。下一篇我们继续讨论两阶段检索中的关键角色《Reranker 重排序是什么为什么向量检索后还要再排一次》参考资料Milvus DocumentationEmbedding OverviewMilvus DocumentationEmbedding Function OverviewHugging Face DocumentationTokenizerPinecone DocumentationConcepts7.如何选择 Embedding 模型从维度、中文能力到成本