Cohere发布Embed 5：Pro与Fast共享向量空间，文档索引和在线查询可以分别选型
2026年9月30日，Cohere发布Embed 5模型家族。官方更新记录列出Pro与Fast两个版本：前者侧重检索质量，后者侧重低延迟与高吞吐。两者共享向量空间，官方推荐使用Pro建立资料索引，再使用Fast处理查询。产品已通过Embed API、Microsoft Foundry、Amazon SageMaker和Model Vault提供。
建库与搜索不必承担相同成本
嵌入模型把内容转换成可以比较的数值表示。知识库文档可能每天更新一次，用户搜索却可能每秒发生很多次，因此索引和查询是两种不同的工作负载。若两个模型的表示能够兼容，团队就有机会把更多计算投入到较少发生的资料处理阶段，同时缩短高频查询的响应时间。
这种能力尤其适合内容相对稳定、查询不断变化的资料库。例如，一批产品说明书入库后，销售、支持和工程人员会用不同说法提问。共享空间让文档端与问题端可以采用不同模型，但检索仍需围绕同一套表示约定运行；它并不意味着任意旧模型生成的向量都能混在一起比较。
AI模型生成的概念插图，以两种入口指向共同空间表现向量兼容，并非Cohere产品截图或发布照片。
多模态让一页资料保留更多关系
Embed 5支持文字、图片及混合输入，官方列出的上下文窗口为128k token，覆盖超过100种语言，并提供多种维度和数值输出类型。上述是产品规格；发行方宣称的质量提升，并不能直接代替某个企业内部资料的实际检索表现。
对带有表格、图示和注释的说明页，关键问题往往不是识别到了多少词，而是能否把图中的部件与附近的限制条件联系起来。即使嵌入保留了更多视觉信息，检索系统最后展示给用户的内容也不能只剩孤立缩略图。原始页、文档版本和前后说明，仍决定用户能否正确解释命中结果。
向量变小，索引管理也不能省略
较低维度或更紧凑的数值类型，可以减少向量存储体积，但实际系统还要存放文本、元数据和搜索索引结构。因而“向量少占一半空间”与“整个知识库成本减半”不是同一句话。延迟同样会受到过滤条件、候选数量与后续重排的影响。
迁移时值得明确记录每批向量的模型版本、维度、输出类型和内容版本。否则，一次只更新了查询端的配置，就可能让旧索引变得难以解释。对于需要逐步切换的应用，可以让新旧索引各自保持完整，在同一批真实问题上比较结果，再决定何时让用户流量进入新路径。
这次发布的实际意义，是把文档处理质量与在线查询速度之间的选择变得更灵活。它没有取消检索系统对资料组织的依赖，却让团队有机会分别优化不同时段发生的工作，而不必用同一个模型档位包办所有请求。
