Qdrant 更换嵌入模型：迁移时同时守住新写入与查询一致性

先确认还保留着原始材料 向量迁移需要用于重新编码的原文或其他原始数据。官方示例假设内容保存在 payload 中，也可以来自主数据库。如果手里只剩旧向量，应先解决原始资料可用性，不能通过改变维度配置就让旧向量变成新模型的表示。 双集合路线的基本顺序 官方蓝绿迁移先创建适配新模型的集合，开启新旧双写，再后台遍历已有点重新嵌入。搜索继续使用旧集合，回填完成后再切换目标。该路线会重复存储 payload，还需要为双写中的任何失败保留补偿记录，不能把其中一次写成功视为全部完成。 回填不能盖掉更新后的资料 迁移过程中，旧记录可能已由在线写入更新。官方示例使用 insert-only 模式避免后台回填覆盖新集合中已经存在的点，并说明该模式有版本前提。编辑建议用同一记录在回填期间发生更新的样例验证，检查最终保留的是哪一份内容，而不是仅比较总点数。 用一条正在修改的记录演练竞态 给测试记录 P1 标上业务版本：回填读取的是 v1，在线服务随后把正文更新为 v2 并写入新集合，最后回填才尝试写入 v1。预期新集合保留 v2。官方蓝绿例子使用 insert-only 防止旧回填写覆已经存在的点；当前文档注明该模式从 1.16 起可用，应先确认部署支持，再按此路线实现。 反过来，如果 v2 向新集合的双写失败，insert-only 也不会替你补齐这次失败。回填先写入 v1 后，还需要重放失败更新，让新集合追到 v2。验收记录应包含业务版本、双写结果与补偿完成状态，不能只对照两边都有 P1。 命名向量也要确认向量代表的正文版本。若后台先读旧文本、在线再改新文本，不能只看到 point ID 相同就认为两次结果等价。应通过更新顺序、版本条件或其他并发控制防止旧文本的向量覆盖新表示，并检查 payload 与向量是同一内容版本。 删除与局部更新是另一类竞态 教程明确提醒，蓝绿示例直接适用于 upsert；删除和部分更新需要暂停或额外逻辑。否则先删除、后回填的顺序可能使旧数据重新出现。迁移设计应列全实际写入操作，逐一确定如何同步，而不是只覆盖新增记录。 命名向量路线有前提 所核对文档说明，原集合采用命名向量且部署版本为 1.18 或以上时，可以在同一集合增加新向量定义并回填。它保留点身份与 payload，但双写仍需同时更新新旧向量，查询切换时也要修改 using 及 embedding 模型。未满足前提时应采用适合当前结构的路线。 切换前检查两种一致性 第一种是数据一致性：新表示是否覆盖预期记录，失败写入是否补齐，删除是否生效。第二种是查询一致性：查询编码、目标集合或命名向量是否一起切换。建议保存几组已核对的查询结果，先比较语义效果再转移流量，避免把迁移完成当作质量提升的证明。 回退也要考虑后续写入 保留旧集合或旧向量有助于回退，但停止双写后，旧表示可能逐渐落后。应写清可回退时间与数据补偿方式，验证之后再安排旧数据清理。示例的连续服务目标依赖这些条件落实，迁移前仍需演练切换和恢复。

本篇涉及的工具1

Qdrant

维护更换 embedding 时的数据与查询一致性

适合场景

已有线上向量检索，计划更换 embedding 模型的开发者和维护人员。

需要留意

命名向量与更新模式有版本前提，删除和局部更新需独立设计。

了解项目 访问官网