向量模型"静默崩溃"：你的检索系统正在失明

凌晨两点，监控系统一片祥和。状态页全绿，错误率平稳，延迟正常。但你的检索系统（RAG）突然"变软"了——Top-1命中率腰斩，而没人碰过索引。

这不是科幻场景。这是嵌入模型（Embedding模型）的"静默崩溃"：API照常响应，向量维度照旧，健康检查全过，但它已经停止区分任何语义。所有文本对的余弦相似度都挤在0.98附近，像一群鱼挤在同一个狭窄水层。

本文拆解这类故障的检测方法——在检索质量崩盘前，提前捕获信号。

两种崩溃：一种会响，一种无声

嵌入API有两种失效模式。

第一种很吵：5xx错误、超时、连接中断。监控立刻尖叫，你马上知道出事了。

第二种很安静：向量持续返回，1536维一个不少，但语义编码已经失真。相似度分布坍缩成一条细线，检索系统变成瞎子，却没有任何告警触发。这才是真正摧毁生产的故障类型。

问题的核心在于：分布漂移不需要服务中断。模型权重更新、微调版本切换、输入预处理变更、甚至批处理顺序调整，都可能让输出空间发生结构性偏移。

而你现有的监控，很可能对此一无所知。

诊断现场：相似度分布的"坍缩三联征"

当你怀疑静默崩溃时，第一步是采样验证。

从你的语料库中固定抽取1000对随机文本，计算余弦相似度分布。健康的生产模型通常会呈现钟形曲线：

均值约0.7，标准差约0.1，已知相似对与随机对的差距约0.2。这三个数字是语料相关的——法律合同库会比新闻库整体偏高，但关键不在于绝对值，而在于稳定性。

分布坍缩时，三个指标会同步异动：

均值向1.0漂移，标准差趋近于0，相似对与随机对的差距消失。任一指标偏离滚动基线超过三个标准差，就是告警信号。

这比监控错误率或延迟更能捕捉语义退化。因为模型仍在"工作"，只是工作的意义已经流失。

构建探针：三组分监测体系

被动采样不够。你需要一组固定的"探针"（Probe Set），每小时嵌入并计算三个核心指标。

探针包含三部分：随机对（约200对，来自真实语料）、已知相似对（约20对，人工标注的语义相近文本）、以及可选的对抗对（语义相关但应区分的边界案例）。

代码实现很直接：调用嵌入API，归一化向量，批量计算余弦相似度，输出均值、标准差、相似-随机差距。与滚动基线对比，异常即告警。

这套机制的成本极低——每小时几百次嵌入调用，却能捕获传统监控盲区。它监控的不是服务可用性，而是语义可用性。

为什么这是产品创新的关键点？因为RAG已成为AI应用的基础设施，而基础设施的可靠性不能依赖"感觉"。当向量空间发生静默畸变，用户感受到的是"AI变笨了"，但你的仪表盘却显示一切正常。这种认知断层，正是产品信任崩塌的起点。

你的系统今天有探针吗？如果没有，你怎么知道模型没有在凌晨两点悄悄失明？