AI 向量入库怎么防止维度漂移：模型切换、批量校验与回滚边界

线上知识库替换 Embedding 模型的时候，大家最容易忽略的点往往不是模型本身的效果，而是向量输出的维度。旧模型输出 1536 维，新模型直接输出 3072 维，如果代码没做适配就直接把两类向量往同一张向量表或者同一个索引里写，批量任务大概率跑到半中间就抛错；更棘手的是不少系统只在应用层存了模型名称，数据层完全没留可校验的维度约束规则。

比较稳妥的方案是把模型标识、输出维度、距离度量方式和索引名称绑定为同一个版本单元：写入前先对单条数据和整批数据做前置校验，模型迁移阶段同时跑新旧两套索引，等抽样验收全部通过之后再切换查询别名。这样就算后续发现新模型效果达不到预期，也能快速切回旧索引，不用临时紧急清空线上存量数据。

先把向量维度写成不可变契约

“模型能正常返回向量”不等于“这个向量可以直接写入目标索引”。入库接口至少要验证四件事：模型标识是否匹配当前批次，数组长度是否等于索引定义的维度，元素是否为合法的有限浮点数，距离度量规则是否和查询侧完全一致。

不要只在配置文件中保存 dimension=1536。配置会被改，历史数据不会自动跟着改。把契约写进集合元数据或数据表，并让每次写入都带上批次版本，排查时才能回答“这条向量是谁生成的”。

批量入库前完成三层预检

批处理场景下最麻烦的就是处理到第 800 条才发现第 801 条来自另一套不同参数的模型。预检流程应该在真正往库中写入前完成，至少分为结构、数值和业务版本三层。

第一层：检查数组长度

const EXPECTED_DIM = 1536;

function validateEmbedding(item, expectedModel) {
  if (item.embedding_model !== expectedModel) {
    throw new Error(`model mismatch: ${item.embedding_model}`);
  }
  if (!Array.isArray(item.vector) || item.vector.length !== EXPECTED_DIM) {
    throw new Error(`dimension mismatch: got ${item.vector?.length}`);
  }
  if (!item.vector.every(Number.isFinite)) {
    throw new Error("vector contains non-finite number");
  }
}

for (const item of batch) validateEmbedding(item, "text-embedding-prod-v2");
// 所有条目通过后，再提交 bulk 写入

这里的核心要点不是抛出什么类型的异常，而是“校验不通过就绝对不提交”。如果接口支持 bulk 批量写入，先在内存中完成整批校验；如果单批次数据量太大，就按固定大小切片拆分，每个切片也必须全部校验通过之后再执行写入。

第二层：检查数值和边界

NaN、正负无穷或被错误序列化的字符串，可能绕过简单的长度检查。归一化也要统一：如果写入侧对向量做了 L2 归一化，查询侧必须使用同样约定，否则距离结果没有可比性。别把“数值存在”误当成“数值可检索”。

第三层：检查批次版本

给任务记录 batch_id、输入文档数、成功数、拒绝数和模型版本。拒绝项写入隔离队列，主任务返回失败原因；不要为了让任务变绿而把异常向量静默降维、补零或截断。

模型切换时用双索引承接新旧数据

直接修改线上索引的维度通常没有安全的“瞬间切换”效果。更可控的路径是创建 docs_v2，用新模型回填历史文档，同时让新写入按版本路由到对应索引。

1. 冻结新模型的契约：模型名、维度、距离和版本号写入迁移单。
2. 创建新索引并只允许符合新契约的向量进入。
3. 从文档源重算向量，记录成功、失败和跳过的文档 ID。
4. 用固定问题集比较召回结果、延迟和空结果率。
5. 把查询别名从 docs_v1 切到 docs_v2，保留旧索引一段观察期。

如果业务要求迁移期间不能遗漏新文档，可以采用“源文档变更事件 + 历史回填”的组合方案：事件流负责追上新增和更新内容，回填任务负责补齐历史存量数据。两条路径的流量都要经过同一个维度校验器，不能因为是补偿任务就放宽校验规则。

用可量化的门禁决定是否切换

迁移完成的判定标准绝不是“新索引里已经有数据”这么简单。至少准备一组固定查询集，提前保存旧索引的基线结果，再比对新索引的命中情况、延迟和错误率表现。

阈值要按自己业务的基线来定，不要随便照搬网上“召回率必须 95%”的通用数字。重点是迁移前后用同一批问题、同一套过滤条件和相同的 Top-K 参数，避免把评测流程的变化误判成模型效果变化。

相关问题：常见误区与回滚边界

为什么补零或截断不能解决维度不一致？

补零会直接改变原有向量空间的语义，截断则会丢失模型输出的原始信息；两种操作都有可能让写入流程跑通，却让后续的相似度排序在悄无声息中出现偏差。正确的处理方式是让向量回到生成它的模型契约规则，或者直接重算整条向量数据。

新索引写入成功，为什么仍然不能立即切换？

写入成功只代表底层存储结构能正常接收数据，不能证明分段、过滤、距离计算和查询延迟都符合预期。至少完成固定问题集校验和失败批次复核，再切换查询别名。

什么情况下应该立刻回滚？

出现持续的维度拒绝、查询错误率上升、空结果占比明显增加，或者核心问题集的相关性大幅下降时，要直接把别名切回旧索引，同时暂停新模型的写入流程。保留所有失败批次和迁移日志，修复契约问题之后再重新跑迁移任务。

上线前的向量迁移速查

• 模型名、维度、距离度量、版本号是否已经落到数据元信息里。
• 单条和整批写入流程是否都能拒绝长度错误、非有限值、模型混批的异常数据。
• 新旧索引是否支持独立查询，别名切换流程是否完全可逆。
• 固定问题集、P95 延迟、空结果率和失败批次是否已经提前建好基线。
• 回滚操作完成后是否能自动停止新模型写入，并且快速定位到待重算的文档。

把维度漂移当成数据契约问题来处理，模型切换就不再是一次“改完配置就祈祷不出错”的发布操作。真正需要守住的是写入边界、查询验收和可逆切换这三道防线。