Embedding 把文本映射成向量。检索时问题向量和文档向量需要使用相容的模型与处理方式。即使新旧模型输出维度相同，数值也不代表同一个语义空间；只替换查询侧的模型，旧索引的距离分数就失去原来的含义。
安全的迁移方式是给片段记录模型版本、切块版本和文档版本，建立独立的新索引。先用固定问题集对照新旧索引的召回、引用和延迟，再逐步切换读流量。写入期间要明确新文档进哪个版本，不能让一次增量更新把两种向量混进同一个集合。
删除也需要版本意识
重建索引不是只追加新向量。原文被删除、权限被撤销、章节被修改时，旧片段也必须失效。否则检索可能引用已经不存在或不再授权的内容。
发布时保留一段可回滚窗口，观察真实查询中的空召回、重复引用和延迟变化；确定新索引稳定后再清理旧索引。模型升级是一项数据迁移，不只是一次 API 参数更新。
双索引迁移的具体顺序
先冻结一份可重复的文档快照和评估问题集，记录当前模型、预处理、切块与索引配置。新模型在独立集合里重算文档向量；查询侧也分别用旧、新模型生成向量，各自只访问对应集合。这样 A/B 对照比较的是一条完整检索链路，不会混合两个空间。
增量写入是最容易漏掉的一步。全量重建需要时间，期间原文可能新增、修改或删除。可以记录变更事件并按顺序回放到新集合，再在切流前核对文档数、有效片段数和版本水位。若没有可靠事件流，至少要做一次尾部差异扫描；否则刚更新的文档会在新索引中消失。
评估不仅是相似度
不能拿新旧模型的原始相似度均值直接比较，因为分数尺度可能不同。应在相同授权身份和问题集下比较 Recall@K、被引用片段的正确性、无答案时的拒答，以及 P95 检索延迟。按文档类型拆分，尤其检查编号、缩写和中文专业术语；平均值提升可能掩盖少数关键查询的退化。
回滚也应是一项可执行操作：读流量切回旧集合后，确认其文档仍在合理的新鲜度范围内，或明确告诉用户这段时间的新文档暂不可检索。没有这个约束，所谓“双索引可回滚”只是配置开关的幻觉。
维度相同也不代表兼容
这是迁移里最容易误判的一点。向量维度只决定数据库能否存储和计算距离，并不保证坐标的语义一致。两个 768 维模型可能把同一句话映射到完全不同的位置；即使只改了文本前处理、截断长度或归一化方式，也可能改变排序。索引元数据因此要记录完整的向量生成契约，而不只是一个模型名称。
迁移完成后还要追踪线上查询的分布是否不同于离线题集。离线测试通常缺少错别字、简称和最近新增的文档。可以在不泄露原文的前提下记录两套索引返回的片段 ID 差异，对差异较大的查询做人工复核。若新模型只提高常见问题，却让某些关键编号查询消失，就需要保留关键词路径或调整召回策略，而不是盲目推广新模型。
什么情况下不值得迁移
新模型在公开榜单上更强，并不意味着对自己的文档和问题更好。如果当前主要故障是 PDF 解析丢表头、权限标签错误或查询里包含大量精确编号，换 Embedding 的收益可能远小于修数据链路。迁移的前置条件应是明确的失败样本和对照指标，而不是版本号更新。
还要算完整成本：全量重新向量化、双索引存储、增量同步、评估与回滚窗口。只有质量改进足以覆盖这些成本，或旧模型存在维护与安全问题时，迁移才是优先事项。