向量数据库缺失的外键：模型版本一致性危机

向量数据库允许来自不同模型版本的嵌入向量在同一索引中共存，因为它们在类型上完全有效，即使几何意义已相互矛盾。在数据仓库规模下，模型升级后重新嵌入数十亿行数据是一场漫长而昂贵的批处理作业，这意味着混合版本索引并非边缘情况，而是每次迁移期间的默认状态。

模式在说谎

嵌入不是普通数据，它们是由特定模型定义的几何空间中的坐标。两个向量之间的余弦相似度只有在它们由同一函数映射到同一空间时才有意义。更换模型——新检查点、新分词器，甚至只是归一化步骤的改变——就会产生一个形状相同但空间不同的嵌入。一个来自某模型版本的1536维浮点数组，在结构上与下一个版本产生的数组完全一样。数据仓库的类型系统无法区分它们，因为它从未被设计来区分。

问题在于：关系模式强制结构约束——类型、可空性、表间外键，却没有“由模型X在检查点Y经预处理Z生成”的概念。当嵌入列被部分重新生成时，仓库看到的是一列有效的干净向量，向量数据库看到的是一个干净的索引。最近邻搜索不会报任何错误。唯一的症状是检索质量缓慢下降，看起来像是模型漂移或数据质量腐化，而实际上是两个不兼容的坐标系被当作一个来比较。

嵌入向量是深度神经网络将离散对象（文本、图像、音频）映射到高维实数空间后得到的稠密向量。其核心假设是：语义相近的对象在向量空间中的距离也相近，因此余弦相似度或欧氏距离可作为语义相关性的代理。然而这个假设有一个隐含前提——所有被比较的向量必须由同一个映射函数产生。嵌入模型通常包含分词器、编码器权重和归一化步骤三部分，任意一部分改变都会使整个映射函数发生变化，从而在相同维度上产生语义坐标完全不同的新空间。这就是为什么向量维度一致并不等于空间兼容：维度只是容器形状，坐标含义才决定几何关系。

为什么这不是小规模问题

在小规模下，这个问题几乎不存在。重新嵌入一千万行数据，换掉表，一个下午就能完成。过渡几乎是原子性的，没人会注意到接缝。

但在仓库规模下——数十亿行数据积累多年，嵌入列依附于历史事实表、特征表和文档档案——重新嵌入不是一下午的工作，而是一个持续数天甚至更久的批处理负载，取决于吞吐量和成本约束。在整个窗口期内，生产索引中混合着新模型重新嵌入的行和仍携带旧向量的行，因为没人能承受在回填完成前让索引离线。

这意味着混合版本索引不是罕见的迁移事故，而是每次仓库规模系统升级嵌入模型时的默认运行状态。仓库越大，这个窗口越长，检索质量无声退化的时间也越久，而没人能指出原因——因为索引中每一个向量单独来看都完全有效。

**回填（backfill）**指用新模型对历史数据重新计算嵌入并向索引写回的过程。它与普通批处理的关键区别在于：回填的输入规模等于全量历史数据，而在线推理的输入规模只等于当前查询量。两者的成本曲线完全不同——推理成本随流量线性增长且可弹性伸缩，回填成本随数据总量单调递增且不可通过增加并发来压缩总计算量。在实际系统里，回填通常受限于吞吐上限（GPU 队列、API 速率限制）和成本预算，很难在数小时内完成，因此不可避免地与在线查询重叠。这正是混合版本窗口期产生的物理原因。

重新嵌入是计算预算中的隐藏项目

这里有一个大多数容量规划忽略的成本维度。推理服务成本随查询量扩展，可以预测、设上限、自动伸缩。重新嵌入成本随历史数据总量扩展，而总量只增不减。每次采用更好的嵌入模型，你支付的不仅是新数据的边际成本，而是从头重新处理之前所有数据的成本，回溯到保留策略允许的最远处。

对于一个持有多年文档、支持工单、日志或转录的仓库，这次回填可能使持续推理账单相形见绌。那些把重新嵌入当作一次性脚本、交给碰巧负责向量数据库的人处理的团队，最终会在迁移中途、在预算已按“嵌入是已解决的廉价预处理步骤”设定后，以艰难的方式重新发现这笔成本。

实际后果是，重新嵌入需要像任何大型回填一样被预算和调度：有自己的SLA、计算分配和负责人，而不是被视为模型升级的附带副作用。

蓝绿部署是一种将新旧两套环境并行维护、验证通过后再切换流量的发布策略。在向量检索场景中，蓝绿意味着在旧索引继续服务的同时，用新模型身份在另一套索引中完整构建全部向量，验证召回率、延迟等指标达标后再原子切换查询路由，出问题时回退到旧索引。与之相对的是就地更新（in-place update），即在同一个索引里逐行替换向量，这会产生前文所述的长窗口混合状态。蓝绿切换的代价是临时双倍存储和双倍回填计算，但它把“不可见的质量退化”转化为“可控的切换瞬间”，把回滚能力纳入了架构设计。

溯源作为约束，而非元数据字段

解决方案并不新奇。它和关系数据库几十年前决定参照完整性不应是可选项时所做的动作一样：让依赖显式化，从结构上强制执行，而不是依赖人们记得。

具体来说，每个嵌入列都应携带一个复合身份，与向量并存——模型标识符、检查点或版本哈希、预处理哈希——并且这个身份应是向量索引分区和查询方式的一等公民，而不是附属表中的可选标签。跨越两个不同身份的相似性搜索不应无声成功；系统应默认拒绝或大声标记，就像类型不匹配的连接被拒绝而不是默默强制转换。

从操作层面看，这体现为几个具体习惯：

• 将重新嵌入视为具有血缘、监控和明确完成状态的一等ETL管道，而不是某人运行一次就忘记的脚本。
• 在切换之前，完全以新模型身份构建新索引——向量索引的蓝绿交换，与模式迁移已采用的标准纪律相同。
• 在过渡窗口期间按模型身份过滤或分区检索，这样即使回填仍在运行，查询也永远不会无声混合两个不兼容的空间。
• 将模型身份记录为每个嵌入溯源记录的一部分，像查询列血缘一样可查询，以便质量回归能在几分钟而非几天内被追溯到“哪个模型写了这个向量”。

这些都不需要新基础设施。它需要决定：模型身份是模式应强制执行的依赖，而不是生活在变更日志中、事故期间没人会读的事实。

参照完整性是关系数据库保证外键指向有效主键记录的约束机制。它的价值不在于记录了什么，而在于数据库会拒绝违反约束的写入，使错误无法静默通过。将模型身份建模为外键，本质上是把“哪些向量属于同一空间”这一语义规则转化为数据库可强制执行的硬约束。实现上，可以在嵌入表中引入模型身份表作为主表，嵌入列的外键指向该表；向量索引按模型身份分区；查询时先确定模型身份再命中对应分区。这样跨模型比较在物理层面就不可能发生，而不是仅靠文档提醒或代码审查来避免。

真正的教训

向量数据库继承了仓库的信念：如果类型检查通过，数据就是可靠的。这种信念在嵌入场景中站不住脚。模型版本不应是事后补记的元数据，而应是嵌入列的结构性外键。只有当系统拒绝跨模型版本的相似性搜索、或至少大声警告时，检索质量才不会在无声中崩塌。