生产 RAG 中嵌入模型漂移的隐藏风险

有一类生产故障永远不会发告警。不会抛出异常，监控面板上不会出现延迟高峰，断路器也不会跳闸。系统会返回结果——看起来合理的结果——而用户却在悄悄收到更差的答案。Embedding 模型漂移正是这种故障，而且它比 ML 社区承认的要常见得多。

什么是这里的"漂移"

工程师说"模型漂移"时，通常指的是数据漂移：输入的统计分布相对于模型训练时已经发生了偏移。这是个真实的问题，但不是我们这里讨论的。Embedding 模型漂移更简单，也更机械：存储向量的编码模型与查询时运行的模型不再是同一个模型。

这种情况有几种发生途径。Embedding 提供商静默更新了他们的托管模型——端点相同，权重不同。你升级了一个附带更新版默认模型的库依赖。你完全迁移到了另一个提供商。你对基础模型进行了领域数据微调，却忘了重新编码索引。每种情况下，向量数据库执行的余弦相似度计算都变得毫无意义：它在两个不同的几何空间中测量距离，却把结果当作在同一个空间里处理。

更隐蔽的是，这种降级是渐进的、局部的。如果新的编码器是旧版的轻微更新，大部分查询仍然能正常工作。困难查询的尾部——那些需要精确语义对齐的查询——悄悄地开始失败。你在聚合指标里看不到这个问题，只会在难以复现的用户投诉里，或者在没人再跑的评估集里看到它。

为什么向量数据库救不了你

理性的工程师可能会期望向量数据库层强制某种 schema 契约：将模型标识符与索引一起存储，拒绝来自不匹配编码器的查询。有些系统确实开始朝这个方向移动，但整个生态的主流做法是将向量视为不透明的浮点数数组。数据库对向量出处没有任何意见。

这不是数据库作者的懒政。这反映了一个真实的设计张力。Embedding 模型没有通用的标识符格式。一个模型名不是内容哈希——同一个名字在不同提供商、版本和量化级别下可以指向不同的权重。在这个模糊性之上建立可靠的标识层确实很难，而且大多数团队也没有大声疾呼要解决这个问题。

结果是责任完全落在了应用基础设施上，在这里它很容易被忽略。你的检索管道没有内置的预警机制。你必须自己建一个。

检测：哪些方法真正有效

最可靠的检测策略是使用已知检索预期的金丝雀语料库。选取一小套查询-文档对——五十到一百个——在这些对上，你确切知道哪些文档应该排在前三名。在每次部署时重新编码查询和文档，与存储的索引进行比较，并跟踪平均倒数排名随时间的变化。突然下降是编码管道发生变化的有力信号。

一种互补的方法是 embedding 指纹。选择一小套固定的参考句子——多样化、稳定、非领域特定。在索引构建时和查询服务时，编码这些句子并存储产生的向量。在服务任何查询之前，计算当前参考向量与存储参考向量之间的余弦相似度。如果相似度低于阈值，则发出告警。这很便宜、确定性高，能捕获提供商端的静默更新，也能捕获你自己的依赖升级。

这两种方法都不需要单独的 ML 平台。它们只是断言，就像你会断言数据库 schema 迁移正确完成一样。工程规范是相同的，只是领域不同。

不太可靠的是监控检索延迟或结果数量。漂移的索引仍然以相同的速度返回结果。监控用户参与度指标太滞后、太嘈杂。等业务指标变动时，损害已经累积了数周。

Contain the Damage 的架构模式

检测是必要但不充分的。你向量索引周围的架构需要使重新编码足够便宜，以至于在检测到漂移时你真的会去做。

将原始内容存储与向量索引分离。这说起来显而易见，但在实践中经常被违反。如果你的规范文档表示是向量，那么重新编码需要从源系统重新摄入。如果你的规范表示是原始文本（或结构化数据），重新编码就是对本地存储的批处理任务。前者是为期数周的项目；后者是周末就能完成的任务。从第一天起就按后者来设计。

对索引进行显式版本控制。将每个索引视为带有精确模型标识符的不可变产物——最好的是模型权重的内容哈希，而不仅仅是名字。当你更新编码器时，在并行构建一个新索引，用金丝雀语料库验证它，然后将流量切过去。这就是蓝绿部署在向量基础设施上的应用。它增加了运维开销，但使回滚成为可能，并将漂移作为刻意的转换而非静默的变异呈现出来。

为高风险检索考虑双编码。对于精确度最重要的查询，同时运行词法检索阶段（BM25 或等效方案）和语义阶段。词法检索天生对 embedding 漂移免疫——它在 token 上操作，而不是几何空间上。混合排序器对两个信号进行加权，在语义组件漂移时会优雅降级，而不是完全失败。这不是永久修复，但在你解决根本原因时是有意义的韧性层。

组织维度

上述技术模式一旦决定实现就很直接。更难的问题是组织层面的：Embedding 模型漂移落在团队之间的缝隙里。拥有向量数据库的团队不是管理模型依赖的团队。监控面向用户质量指标的团队不是管理基础设施升级的团队。没有人明确的职责来监控这种特定的故障模式。

解决方法是让金丝雀语料库和指纹检查成为部署检查清单的一部分，而不是单独的监控关注点。每次触及检索栈的部署——依赖升级、提供商迁移、模型微调、基础设施变更——都应该在流量切换前重新运行金丝雀并比较指纹。这是一个五分钟的自动化检查。跳过它的代价是数周的静默降级。

还有助于将 embedding 管道作为一等公民系统而非 RAG 应用的实现细节来分配明确的所有权。记录模型标识符、编码参数、索引构建日期和金丝雀基线。用你对待数据库 schema 的方式来对待这些：版本化、可审计、有所有者。

Embedding 模型在 ML 堆栈中占据着不寻常的位置。它们被当作基础设施使用——稳定、可靠、被认为是一致的——但它们作为模型被维护，会受到更新、弃用和静默改进的影响。这种心智模型的错配才是风险所在。

被 embedding 漂移坑过的工程师并非粗心。他们对基础设施应用了正确的心智模型（搭建好、监控正常运行、然后放手），却用在了需要训练产物心智模型的组件上（跟踪出处、更改时验证、定期重新评估）。缩小这个差距不是工具问题，是概念问题。

一旦你将 embedding 模型视为你的索引有硬依赖的版本化、可变产物——而不是你调用的稳定服务——正确的工程实践就会自然跟进。金丝雀语料库、指纹检查、版本化索引：这些不是高级技术。它们只是依赖管理的标准实践，应用于一个尚未迫切要求它们的领域。