用 Azure AI Search 加 Azure OpenAI 搭 RAG 系统时，我碰到过一个很典型的现象：上线初期检索质量挺好，跑了一阵子却慢慢变差。代码没动，基础设施没改，服务也没出故障，可检索的相关性就是在往下掉。折腾了一番我才搞清楚，背后常见的元凶叫向量漂移（vector drift）。这篇就说说向量漂移到底是什么、它为什么会在生产环境的 RAG 系统里冒出来，以及怎么用 Azure 原生的模式设计一套抗漂移的架构。

什么是向量漂移

向量漂移，指的是存在向量索引里的 embedding 已经没法准确表达进来的查询的语义意图了。

向量相似度检索靠的是语义位置的相对关系。正因如此，哪怕模型、数据分布或者预处理逻辑只发生了很小的变化，时间一长都可能明显拖累检索质量。

它跟 schema 漂移或数据损坏不一样，藏得很深：

  • 系统照常运行
  • 查询也有结果返回
  • 但相关性在持续走低

原因一：Embedding 模型版本不一致

发生了什么

文档用一个 embedding 模型建的索引，查询的 embedding 却用另一个模型生成。这种错配通常来自：

  • 模型升级
  • 多个团队共用同一个 Azure OpenAI 资源
  • 不同环境之间配置对不上

为什么这是个问题

不同模型生成的 embedding：

  • 处在不同的向量空间里
  • 数学上没法直接比较
  • 算出来的相似度分数会误导人

结果就是，原本相关的文档，排序可能不再正确。

推荐做法

一个向量索引，在它整个生命周期里都应该绑定同一个 embedding 模型和同一个维度大小。

一旦 embedding 模型变了，索引就得整个重新 embedding、重新构建。

原因二：只做增量更新，却不重新 embedding

发生了什么

新文档不断加进索引，已有的 embedding 却原封不动。时间一长，新内容会带进来更新过的术语、变化了的政策，还有新的产品或领域概念。

因为语义是相对的，向量空间会随之偏移，可老的向量却纹丝不动。

能观察到的影响

  • 最近入库的文档在检索结果里占了上风
  • 更早但依然有效的内容变得更难被检索到
  • 召回率悄悄下降，却没有明显的系统报错

实操建议

把 embedding 当成会变的活资产，而不是一成不变的静态产物：

  • 对稳定的语料定期安排重新 embedding
  • 对高价值或高频访问的文档优先重新 embedding
  • 当领域词汇发生实质变化时，触发重新 embedding

相似度分数下降、引用覆盖率变低，往往就是漂移的早期信号。

原因三：分块策略前后不一致

发生了什么

chunk 大小、重叠量或者解析逻辑随时间调整过，但之前入库的内容没跟着更新。索引里最后混着用不同策略切出来的 chunk。

为什么会造成漂移

不同的分块策略会产生：

  • 不同的语义密度
  • 不同的上下文边界
  • 不同的检索行为

这种不一致会削弱排序的稳定性，让检索结果变得难以预测。

治理建议

分块策略应该被当成索引契约的一部分：

  • 一个索引只用一种分块策略
  • 存好 chunk 的元数据（比如 chunk_version）
  • 分块逻辑变了就重建索引

设计原则

  • embedding 部署要做版本管理
  • 用定时或事件驱动的重新 embedding 流水线
  • 分块策略标准化
  • 建立检索质量的可观测性
  • 对 prompt 和响应做评估

关键要点

  • 向量漂移是架构层面的问题，不是服务缺陷
  • 它来自模型变更、数据演进和预处理不一致
  • 长期运行的 RAG 系统需要 embedding 的生命周期管理
  • Azure AI Search 提供了缓解漂移所需的控制手段

小结

向量漂移是生产级 RAG 系统里预料之中的一个特征。谁能主动管好 embedding 模型、分块策略和检索可观测性，谁就能在数据和用法不断变化时守住相关性。对我来说，把向量漂移放进日常要盯的清单，是在 Azure 上把 AI 方案做稳的关键一步。

延伸阅读

下面这些 Microsoft 资源，对向量检索、embedding 以及 Azure 上生产级 RAG 架构给出了更多指导。