替换嵌入模型后向量维度不一致，怎样迁移索引而不混用旧向量？

同时核对向量长度与模型来源

常见症状是向量写入报维度错误，或者请求能成功但原来准确的查询突然返回无关记录。先保存一条实际生成的向量长度及索引定义，确认错误发生在生成、写入还是查询阶段。不要仅依据模型名称相似，就认为旧向量与新查询可以互相比较。

抽查文档和查询的两端流程

检查嵌入服务的具体版本与输出维度配置，再抽取几条文档记录，看是否有部分仍由旧模型生成。文档嵌入与查询嵌入可能经过不同的程序或环境变量，两端都要核对。向量长度一致只是结构检查，还需要记录同一文本在新旧流程中的模型来源。

重建新索引后同步切换查询

为新模型建立独立字段或新索引，保留原索引作为恢复条件，按文档ID重新生成全部向量。重建期间验证记录总数和失败重试，避免只有一部分资料迁移成功。查询端应随目标索引同步更换嵌入模型；不支持指定维度的服务不能靠裁剪向量凑成字段长度。

比较候选排序并保留恢复条件

使用带已知相关文档的固定问题集，对比新旧检索的候选和排序，确认精确编号及自然语言问题都能找到目标资料。验证没有维度错误只是第一步，还需确认所有记录已经迁移，引用仍对应正确文档。切换后保留恢复入口，继续检查实际查询中的异常。

本文给出索引迁移方法，没有重建用户现有知识库，也不把不同模型的相似度分数视为统一置信度。某些模型支持可变维度，仍需按官方接口显式配置并保持两端一致。重新生成向量可能消耗服务额度，实际迁移前应按既有环境确认资源条件。