Embedding 模型切换后旧向量为什么不能直接混用

把 Embedding 模型从 A 换成 B 后，旧向量通常不能直接和新向量放进同一个检索集合。最容易被忽略的是：维度只是数组长度，不能证明两个向量处在同一个语义空间。即使新旧模型都输出 1536 维，坐标含义、训练目标、归一化方式和相似度分布也可能不同，混搜会让排序结果变得不可解释。

稳妥做法是把模型版本当成索引的一部分：保留原始文本，按新模型重新生成全量向量，建立新索引，完成抽样对照后再切换查询入口。

先看维度，但不要把维度当成兼容证明

向量数据库的集合通常会固定维度。旧模型输出 768 维、新模型输出 1024 维时，写入阶段就会因 shape mismatch 被拒绝；这类错误反而容易发现。真正危险的是两边恰好同维，系统接受了数据，检索结果却悄悄变差。

迁移前至少把下面几项写入配置或集合元数据：

维度相同，为什么相似度仍然不能混算

Embedding 的每一位不是通用坐标轴。模型 A 可能更强调词面关联，模型 B 可能更强调跨语言或任务语义；两者即便输出同样长度，向量之间的角度也没有直接可比的标尺。把 A 生成的文档向量和 B 生成的查询向量做 cosine，只能得到一个数学结果，不等于得到有意义的相关性。

代码层面建议让向量对象携带来源信息，在查询入口先做硬匹配。下面的示例不负责修复向量，只负责阻止不同空间进入同一次检索：

def ensure_compatible(query_meta, index_meta):
    # 模型和维度属于索引契约，任一项不符都停止混搜
    required = ("embedding_model", "dimension", "metric", "normalized")
    for key in required:
        if query_meta.get(key) != index_meta.get(key):
            raise ValueError(f"embedding contract mismatch: {key}")
    return True

生产系统还应把这次不匹配记录成可观测事件。它通常比“召回变差”更早暴露配置串线。

用重嵌入和新索引完成迁移

真正迁移时，原始文本或结构化文档才是唯一可靠的中间层。读取旧索引中的文本副本，使用新模型重新编码，写入新集合；不要从旧向量反推出新向量，也不要靠补零、截断或线性缩放伪造兼容关系。

推荐保留两个明确的集合名，例如 docs_v1 和 docs_v2，并让查询服务通过配置选择索引。迁移期间可以双写新文档，历史数据则分批回填。抽样对照时固定一批真实问题，比较命中主题、空结果比例和人工可接受的排序位置；确认新索引覆盖后，再把查询流量切到 v2，最后按保留策略下线 v1。

常见问题

只更换向量数据库，不更换 Embedding 模型，可以复用旧向量吗？

可以，前提是模型、维度、距离度量和归一化约定都不变，并且新数据库确实兼容原索引参数。换数据库本身不等于换语义空间。

新旧模型输出维度一样，能不能先混用再观察效果？

不建议。混用会让问题变成数据分布和模型契约同时变化，出现误召回时很难定位。至少先分索引做对照。

迁移时最应该保留什么？

保留可重建的原始文本、文档 ID、切片规则和模型元数据。只有向量而没有原文时，迁移通常只能重新获取数据，不能可靠修复。

因此，Embedding 切换应被当作一次索引迁移：先隔离契约，再从原文重嵌入，最后用新索引承接查询。这样即使模型继续迭代，也能明确知道每条召回结果来自哪个语义空间。