Embedding 迁移是新时代的 Schema 迁移

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

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

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

为什么“无缝替换”几乎总是一个谎言

厂商在发布公告时，通常会将新的嵌入模型描述为前一版本的无缝替换（drop-in replacement）。有时维度是匹配的，有时 API 签名是相同的。这暗示了旧向量和新向量生活在同一个世界，你可以用一个模型的查询来匹配另一个模型的文档。

这种观点在某种程度上是错误的，它会破坏生产系统。

维度完全相同的两个嵌入空间是不可互换的。查询向量和文档向量之间的余弦相似度（cosine similarity）只有在两个向量都来自同一个模型时才有意义——无论如何，数学计算都能运行到底，但参考系已经变了。细心监测这一点的从业者会发现，当模型混合时，相关对的余弦得分会从 0.85 以上崩溃到 0.6 左右；原本检索劳动法文档的查询，开始出现恰好共享表面词汇的房地产文档。系统一直在响应，但系统一直在出错。

“无缝替换”应该被解读为“数据库列类型相同”。它并不能说明存储在该列中的值的语义。从一个模型迁移到另一个模型是数据本身的迁移，而不仅仅是列标题的迁移。

无法捕捉异常的评估套件

大多数运行 RAG 的团队都有一套评估套件。它通常根据一组带标签的查询-文档对来计算 top-k 准确率或 NDCG。在迁移前运行一次，迁移后运行一次，比较差值。如果数字持平，就发布。

这里有一个陷阱：逐点相关性评估（pointwise relevance evals）旨在捕捉单个文档在空间中移动过远的情况。而嵌入迁移不会这样做。它们会旋转整个图谱，这种旋转通常很微妙，且在不同内容类型之间是不均匀的。每个文档都移动了一点。对于某个查询，最相关的单个文档在更换后通常仍然在 top-k 中。但 top-3 中可能会出现以前没有的新文档，而重排序器现在处理的候选集与它训练时使用的略有不同。逐点得分几乎没有变化，但下游的答案质量却大幅波动。

能捕捉到这一点的是一种评估两个索引之间结构关系的指标，而不是其中任何一个的绝对相关性。最简单的版本是 top-k 重合度（top-k overlap）：对于一个具有代表性的查询集，旧索引检索出的 top-k 文档中，有多少比例仍在新索引的 top-k 中？我们称之为邻域稳定性（neighborhood stability）。95% 的 top-10 结果得到保留的迁移，与只有 60% 保留的迁移是完全不同的操作。前者是常规更换；后者是架构重构，任何针对旧邻域进行调整的重排序器、提示词模板或下游组件，在流量切换之前都需要一套重新调整的计划。

能在嵌入迁移中幸存下来的评估准则应该是这样的：用逐点相关性衡量绝对质量，用邻域稳定性衡量结构漂移，并在留出的任务集上评估端到端的答案质量，以发现用户可见的回归。在这三个维度中，有两个几乎肯定需要在迁移开始前添加；如果你只有第一个，那么你就是在最重要的维度上盲目飞行。

先双写，再双读，然后切换

数据库迁移有一套公认的序列：添加新列、对两者进行双写、回填历史数据行、带校验的双读、切流、删除旧数据。嵌入迁移也应该遵循同样的流程。

一个可行的模式及其顺序如下：

• 建立一个由新模型填充的并行索引。 即使维度可能与旧索引匹配，也要将其视为独立的索引，拥有自己的别名、监控以及每个向量上的显式版本标签。为了节省存储空间而将新旧向量放在同一个索引中，这在操作上相当于在一个几何库中混合两种坐标系——最终总会有查询查错对象。
• 从并行索引存在的那一刻起，将所有新文档和更新文档双写到两个索引中。 双写窗口越长，当你准备切流时，回填（backfill）的积压就越少。
• 按优先级回填历史文档， 优先处理最热的内容。查询最频繁的 10% 的文档通常占据了大部分检索流量；优先处理这些文档意味着在回填完全结束之前，新索引就已经能对阴影流量（shadow traffic）发挥作用了。
• 在实时流量仍访问旧索引的同时，针对并行索引进行阴影查询。 比较 top-k 重合度、候选集重排序得分以及采样流上的端到端答案质量。这就是邻域稳定性指标发挥作用的地方——它们会告诉你新索引在结构上是否足够相似，可以原封不动地推出，还是下游组件需要先重新调整。

加载中…