READ · UNDERSTAND · TRANSFER
阅读理解，按需巩固
先沿着原理、问答和迁移案例阅读。需要检查理解时，再切换巩固练习或展开个人记录。
核心知识 · Embedding 迁移中的版本闭包与增量一致性
先理解核心原理
先备概念：版本化索引、变更日志与水位、灰度发布
一次查询的文本预处理、查询向量和文档向量必须属于兼容的表示契约；索引切换还必须保持更新、删除和权限约束，不只是搬完向量。
同维度只是能存，不代表能比较
把两个模型都输出的 768 维向量放进同一列，数据库也许能计算距离，但坐标语义不必相同。类比两个系统都用两个数字表示位置，一个是经纬度，另一个是投影坐标：类型匹配不等于可直接比较。模型、归一化、切块和预处理共同构成检索版本，查询向量也必须走对应契约。
回填与增量必须有共同时间线
从某个快照水位开始回填新索引，同时保存之后的更新、删除和 ACL 变更。每条文档携带来源 revision，新索引写入仅接受不更旧的版本，防止慢回填覆盖新更新。删除也要有版本化标记；只把“当前存在的文档”拷贝一遍，会在复制期间漏变更或复活已删除内容。
切换的是完整查询配置
索引别名能简化入口，Elastic 支持一组别名动作的原子切换，但应用仍要检查动作结果，且它不自动切换查询 Embedding 模型。用一个配置版本绑定模型、索引、查询预处理和缓存，请求开始时固定它。灰度与影子读取使用各自模型的向量，比较证据覆盖、权限与拒答，而非直接比不同模型相似度数值。
回滚不能恢复已撤销的数据
保留旧索引用于回滚时，旧索引也要继续接收删除、撤权与必要更新。反例是新版效果差，回滚到三天前索引后重新暴露已删文档。判断可切换的条件包括回填完整、增量追到约定水位、授权校验通过以及效果与费用合格；几十条示例查询通过不能证明几百万文档全部一致。
回到问题：怎样回答？
不同 Embedding 模型生成的向量通常不能直接混查，即使维度相同也不能假定空间兼容。我会建立新版本索引，记录模型、切块和预处理配置，先回填快照再追增量与删除事件。新查询使用匹配模型的查询向量，影子评测和灰度通过后切换索引别名；保留旧索引用于回滚，同时确保删除和权限撤销在两边都生效。
实现与取舍
索引是版本化数据产品
版本元数据包含模型标识、维度、归一化、距离度量、分词或预处理方式、切块策略与文档版本。维度相同不证明两个模型处于同一语义空间。查询向量必须由匹配的版本产生，否则索引可能正常返回结果却相关性完全错误，这类静默失败比接口报错更难发现。
回填和实时写入并行
在时间点 T 建立文档快照，记录变更流起点；新索引回填 T 的内容，同时重放之后的新增、更新和删除。事件按文档版本去重，旧事件不能覆盖更新结果。对删除保留可追踪的墓碑或等价版本规则，防止迟到的回填重新写入已删除内容。权限撤销需要快速影响可见性，不能等全量重建。
切流条件
校验文档数、缺失块、版本水位和删除传播，再用同一查询集比较检索与回答质量。影子查询不面向用户但也应遵守数据权限。灰度按稳定用户或任务分组，避免同一会话来回切换空间。观察质量、延迟和成本，达到事先定义的门槛才切换默认别名。
回滚与清理
回滚不仅改别名，还要恢复对应查询编码器、缓存命名空间和检索配置。旧索引在保留期仍需同步关键撤销与删除，不能成为过期数据泄露的备用通道。确认新索引稳定且没有未完成旧版本任务后再回收，记录可恢复范围和无法回滚的变更。
工程推演
- 场景
- 面试假设：知识库更换向量模型，要求在线查询持续可用。
- 设计决策
- 版本化双索引，快照回填后追变更，灰度切换查询编码器和索引。
- 验证目标
- 新旧查询均不返回已撤销文档，回滚恢复匹配配置。
- 适用边界
- 迁移时间和容量要按数据量及编码吞吐估算。
连续追问与解答
沿着问题的前提和约束继续向下读。先理解参考解答，再尝试收起答案，用自己的话解释因果和取舍。
第 1 层相同维度可以直接共用旧向量吗？
从迁移约束解释最容易误用的类型兼容。
参考解答
不能。相同维度只满足存储形状，模型训练和向量坐标语义可能不同。除非提供者明确保证空间兼容，或有经过验证的映射，否则重建文档向量并匹配查询模型。归一化方式和文本预处理变化也要一起验证；“接口没报错”不是兼容性证据。
第 1 层回填期间文档被删除怎么办？
快照迁移引入并发变更，删除需要独立的一致性规则。
参考解答
删除事件与文档 revision 一起进入持久变更流。新索引记住 tombstone 或删除水位，拒绝晚到的旧回填；旧索引同样处理删除。切换前对账来源与两边索引的存活状态及增量滞后，不能只比数量，因为数量相同也可能一删一多互相抵消。
沿着这个回答继续深入
第 2 层删除事件先到，新索引尚无该文档，直接忽略行不行？
父问要求删除传播，进一步暴露“删不存在记录”后的复活窗口。
参考解答
不行，后续回填可能带来旧版本。即便正文不存在也保存删除 revision 或水位，任何更旧的写入都拒绝。若索引不能保存 tombstone，可在可信元数据层维护并在写入前检查；同时处理批量重试，确保旧快照不会绕开检查。
沿着这个回答继续深入
第 3 层删除后用户重新创建同 ID 文档，怎样不被旧 tombstone 永久挡住？
tombstone 防复活还需允许合法重建，检验版本比较的完整语义。
参考解答
区分业务标识和记录代次。重新创建带更高 revision 或新 generation，写入条件按代次与版本比较；旧 tombstone 只阻止旧事实复活。若来源系统无法保证版本顺序，就采用新的稳定身份并明确关联，不能用到达时间推断哪次创建有效。
第 1 层回滚时缓存需要改吗？
切换不止索引，派生结果也属于版本契约。
参考解答
需要绑定缓存到检索配置版本以及知识、权限版本。回滚时使用旧配置对应的缓存，前提是它仍满足当前来源与权限；不能仅因为问句相同复用新模型的检索结果。回答缓存若缺依赖信息，应失效并重新生成，以免引用指向不同分块或已撤销资料。
举一反三：条件变了，怎样推导？
先找出改变的条件，再判断原方案中哪些前提仍成立。下面的案例是教学推演，便于将原理迁移到新问题。
切块同时改为结构块
改变的条件：除了模型，还改变块 ID 与证据位置
延伸问题：旧引用和用户收藏怎样保留？
推导与参考解答
为原文 document_id、source_version、段落锚点建立稳定定位，旧 chunk_id 只作为历史索引身份。新块保留来源范围，用映射跳回原文而非硬映射到“最相似”新块；无法匹配的旧引用明确失效。迁移评估需重标必要证据范围。
保持不变的原理：检索实现可变化，来源事实及引用定位不能靠相似度猜测。
新模型效果好但成本更高
改变的条件：迁移增加下游预算压力
延伸问题：召回率提高就应全量切换吗？
推导与参考解答
比较按问题分层的最终支持率、延迟和成本，尤其无答案和权限题。可按查询类型灰度，先保留能满足目标的旧配置；确定容量与预算足够再扩大。灰度需按完整配置固定请求，不能一半候选旧空间一半新空间直接混查。
保持不变的原理：变更要验证完整业务收益，表示空间的一致性不能因成本折衷而破坏。
易错点
- 新查询向量直接查旧空间
- 只回填新增忽略删除
- 只回滚索引别名不回滚编码器
参考资料
依据公开技术资料设计；参考资料支持技术机制，场景与评分标准为本站设计，不代表某公司面试原题。 新增问答与迁移案例用于原理讲解，来源核查与案例运行验证分别记录。
检查自己理解到哪一步
读完后可以对照这些标准解释原理、边界和取舍。掌握程度由你自评；需要进一步验证时，再完成下方小任务。
- 基础达标
- 能提出新建索引并保持编码器匹配。
- 中高级信号
- 说明快照、增量水位、版本去重和灰度。
- 资深信号
- 覆盖迟到回填、撤销同步、缓存与完整回滚。
巩固练习 按需完成 · 建议 15 分钟
画出 T 时刻快照后新增、更新、删除三种事件的迁移时序。
展开验收要求与检查点
- 无更新丢失
- 删除不会被回填复活
- 切流与回滚配置成套
重点检查
- 区分维度兼容与语义空间兼容
- 处理快照与增量交界
- 删除和权限撤销覆盖双索引