让你的 A/B 测试整整一个季度都失效的嵌入模型轮换

你干净利落地运行了实验。两个实验组，一个功能开关，一个明确的指标，统计团队也认可了该设计。十二周后，你上线了胜出的方案，然而提升效果却在一个 Sprint 内悄然消失。复盘（Post-mortem）结果显示代码没问题，功能开关的滚动发布没问题，分析端也没问题。发生变动的是实验清单上没人负责的东西：你检索调用背后的托管嵌入模型（embedding model），在第三周、第七周，以及你开会审阅结果的那个早上，为同一个查询返回了略微不同的向量。你的 A/B 测试是真实的，但它运行的底层基座却不是。

这是每一个运行检索增强生成（RAG）的团队最终都会遇到的失败模式，而且几乎没人针对它进行设计。嵌入端点被视为像 Postgres 一样的稳定基座。但它不是。它是一个模型，其发布节奏由厂商控制，你不会去阅读它的更新日志，它的行为表现面（behavior surface）可能会发生偏移，而无需改变维度数量、SLA 或你签署的 API 合约。你以为实验测量的是功能变化，实际上测量的是检索机制的变迁，而功能开关带来的波动只是其上的噪声。

实验堆栈无法察觉的干扰因素

一个埋点完善的实验平台会记录用户分桶、功能开关值、请求路径、延迟以及下游业务事件。但它不会记录生成检索调用背后向量的嵌入模型版本。没有字段记录它，而且在公司任何一侧的职能部门中，都没有人的工作是去添加这个字段。实验团队将模型层视为基础设施。AI 团队则将实验平台视为他人的堆栈。嵌入模型版本就这样掉进了两者的缝隙中。

结果就是，当厂商轮换模型时，这种轮换对你的决策流水线是不可见的。你的仪表盘不断针对一个基座生成置信区间，而这个基座已经不再是当初推导出这些区间的那个基座了。这种干扰无法仅从实验数据中检测出来，因为世界发生变化的那个维度，并不在你的数据维度之中。

这种不对称性至关重要。代码更改会经过评审、获得开关、受到监控并留下审计追踪。而厂商端的嵌入模型升级只会留下一个发布说明并改变你的数据。其中一个是实验准则中的头等事件，而另一个只是“天气”。你无法在一个连风速都在不断调整的风洞里进行受控实验。

厂商更新日志是如何隐藏关键信息的

厂商的发布说明会提到“相关性提升”和“更好地处理多语言查询”。这两者都是事实，但都无法告诉你任何关于在变更后，你的特定语料库、特定查询分布以及特定下游 LLM 将如何表现的实用信息。你的 A/B 测试所设计的检测规模，其针对的边缘案例正是嵌入模型偏移时最容易发生变动的情况，因为这些案例正处于检索边界。

更糟糕的是，厂商经常在同一个端点名称下静默发布这些变更。合约写的是 "v1"，但 v1 背后的权重在不断升级，理由是 v1 是一种模式（schema），而模型只是一种实现。从厂商的角度来看，这是日常维护；从你的角度来看，这意味着你周二进行基准测试的端点已经不再是周四提供服务的那个了。

你的评估套件（你在采购期间运行并每月重新运行一次的那个）可能测量的是固定测试集上的任务级准确率。由于简单情况依然简单，那个数字在微小的嵌入模型偏移中会保持稳定。发生变动的是那些你只有通过查看检索分布而非聚合准确率才能察觉的情况。等到聚合指标发生波动时，你已经在这些偏移之上发布了好几个实验决策了。

没人审计的“快照与生产环境”差异

一个常见的模式：离线检索评估使用三个月前捕获的嵌入模型快照，因为重新对语料库进行嵌入成本很高，而且为了速度，评估流水线运行在本地快照上。在线系统则使用今天的嵌入模型，访问实时端点。快照拍摄时厂商的模型处于一种权重状态，而今天的端点处于另一种状态。

快照与生产环境之间的差距一直在单调地扩大，而流水线中没有任何报警机制。离线评估不断产生相同的数字，因为它是在针对自己进行测试。在线行为则不断漂移，因为基座在漂移。只有当有人手动重新对快照进行嵌入并发现数字与离线测试预测的不符时，两者才会达成一致。

那些避免了这一陷阱的团队会将重新嵌入的节奏与厂商的发布节奏挂钩，而不是为了工程上的方便。每当生产环境的嵌入端点被改动时，语料库就会被重新嵌入，快照也会同时重新生成。两者保持步调一致，否则你将失去通过离线数据预测在线检索行为的能力，这意味着你失去了在发布前进行评估的能力。

已经成为“弗兰肯斯坦”的混合索引

如果你的向量索引已经运行了超过一年，它几乎肯定是一个混合体。3 月份摄入的文档使用的是供应商模型的某一个版本。10 月份摄入的文档使用的是供应商当时提供的任何版本。在语料库刷新后重新摄入的文档，则使用的是那一周最新的版本。而今天的查询则是针对当下的模型进行的。

加载中…