3 篇博文 含有标签「migrations」

一个新的嵌入模型发布了。基准测试数据提升了 4 %。一位 Staff 工程师提交了一个工单：“将 embedding 升级到 v3。”两周后，索引已完成重新嵌入，别名已切换，团队通过特性标志（feature flag）发布了变更。六周后，支持工单堆积如山。搜索结果“感觉不对劲”。复盘会召开了。没人能解释为什么出现了退化，因为没有系统崩溃，每个仪表盘显示的都是绿色。

问题不在于模型的更换。问题在于向量存储根本不知道哪些向量来自哪个模型。数据库里没有这一列。没有用于追踪哪些记录已回填的迁移表。没有 alembic_version 行，没有 schema_migrations 表，也没有先前状态的 pg_dump。团队将 embedding 升级视为一次简单的配置切换，而向量存储在模式（schema）层面缺乏能阻止他们犯错的概念。

Embedding 迁移需要数据库迁移二十年来一直依赖的相同产物：写入每个向量、在每次查询时检索、并作为切换和回滚准入准则的单条记录版本标签。这是大多数团队最容易忘记添加的一列，而后期补救的成本远高于前期添加。

大多数团队在生产环境中第一次更换嵌入模型（embedding model）时，都会将其视为批处理作业。重新运行嵌入器，构建新索引，切换别名，然后部署。延迟保持正常。错误率为零。每个查询都有结果。然而，检索质量会在数周内悄悄下降，而没人察觉。因为症状是“用户抱怨答案感觉不对”，而不是监控面板上的红报警报。

这不仅仅是部署问题，而是一个团队决定盲目进行的架构迁移（schema migration）。旧的嵌入空间和新的嵌入空间是不同的参考系；以前表示“这两个段落关于同一个话题”的余弦几何（cosine geometry）在数值置信度上不再具有相同的含义。以前聚集在一起的文档和查询会以非均匀的方式漂移。在旧分布上训练的重排序器（re-rankers）会开始处理那些不再符合其学习规律的样本。对逐点相关性（pointwise relevance）评分正常的评估套件会漏掉这一切，因为没有任何单个文档移动得太远，但整个图谱发生了旋转。

如果将这种更换视为数据库迁移，几乎所有出错的情况都是可以预防的。如果将其视为批处理作业，那么回归（regressions）就会按照无人负责的进度表悄然降临。

在某个预发布（staging）频道里，一位工程师写道：“将嵌入模型（embedder）升级到 v3，新模型在 MTEB 上的得分提高了 4 分，冒烟测试通过后合并。”两天后，客服工单开始陆陆续续出现，反馈搜索结果感觉“莫名其妙地不对劲”。一周后，检索精度下降了 14 个百分点，余弦相似度分数从 0.85 暴跌至 0.65 左右，而且没人能解释原因——因为这次部署看起来与过去五次模型升级完全一样。这根本不是一次普通的部署。而是一次披着部署外衣的数据库迁移。

嵌入模型轮转是 AI 基础设施中最容易被归类错误的变更类型。它通过与提示词（prompt）微调或生成模型版本更新相同的渠道进入你的系统——配置文件、PR、CI 检查——因此它遵循配置变更的治理流程。但从底层来看，新的嵌入模型并不会产生旧向量的更好版本。它产生的向量完全存在于不同的坐标系中，跨两个流形计算余弦相似度是一个范畴错误（category error）。正确的心理模型不是“升级依赖版本”，而是“在提供读取服务的同时，为一个拥有 5000 万行的表更换主键编码”。