先理解
刚接触这个知识点
补齐先备概念,读原理与反例,再用自己的话解释为什么。
从核心原理开始 →理解 → 实现 → 排错 → 取舍
考察向量空间兼容、双索引、增量变更和删除一致性。
知识内容核对 2026-10-03 · 原题来源核对 2026-10-02
按当前基础选择起点,也可以依次深入。遇到不熟悉的概念,先回到核心原理;完成后用知识练习检查理解。
LEARN · PRACTICE · REFLECT
先沿着原理、问答和迁移案例阅读。需要检查理解时,再切换巩固练习或展开个人记录。
核心知识 · 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 只作为历史索引身份。新块保留来源范围,用映射跳回原文而非硬映射到“最相似”新块;无法匹配的旧引用明确失效。迁移评估需重标必要证据范围。
保持不变的原理:检索实现可变化,来源事实及引用定位不能靠相似度猜测。
改变的条件:迁移增加下游预算压力
延伸问题:召回率提高就应全量切换吗?
比较按问题分层的最终支持率、延迟和成本,尤其无答案和权限题。可按查询类型灰度,先保留能满足目标的旧配置;确定容量与预算足够再扩大。灰度需按完整配置固定请求,不能一半候选旧空间一半新空间直接混查。
保持不变的原理:变更要验证完整业务收益,表示空间的一致性不能因成本折衷而破坏。
依据公开技术资料设计;参考资料支持技术机制,场景与评分标准为本站设计,不代表某公司面试原题。 新增问答与迁移案例用于原理讲解,来源核查与案例运行验证分别记录。
读完后可以对照这些标准解释原理、边界和取舍。掌握程度由你自评;需要进一步验证时,再完成下方小任务。
画出 T 时刻快照后新增、更新、删除三种事件的迁移时序。