凌晨两点，你的检索系统突然"变笨"了。用户投诉找不到答案，可监控面板一片翠绿——没有报错，没有超时，延迟曲线平得像湖面。问题藏在你看不见的地方：向量之间的距离，正在失去意义。
这是嵌入模型（文本向量化技术）最阴险的故障模式。它不崩溃，只是悄悄停止区分任何事物。本文拆解这种"静默失效"的识别与防御。
当0.987和0.984失去区别
故障现场是这样的：你挑一个查询和已知正确答案，余弦相似度0.987——看起来不错。再挑一个明显无关的文本块，0.984。两个随机段落，0.98。所有样本挤在1.0附近的狭窄区间，像被压扁的弹簧。
模型仍在响应，仍返回1536维向量，仍通过所有健康检查。但它已停止编码语义差异。相似度分布坍缩了，而你的告警系统一无所知。
嵌入接口有两种故障：显性的（500错误、超时）和隐性的（向量照返，意义全失）。后者摧毁检索质量，却从不触发任何警报。
分布漂移的三大信号
分布变化不需要事故也能发生。先别急着定位根因，你得先知道它发生了。
从语料库中固定抽取1000对随机样本，绘制余弦相似度分布。多数生产级嵌入模型在多样化语料上呈钟形：
这些数值因领域而异——法律合同语料整体偏高，新闻文章偏低。关键不是绝对值，而是今天的形状明天必须一致。
分布坍缩时，三个指标同步异动：
任一指标偏离滚动基线超过三个标准差，就是警报。
探针集：你的早期预警系统
在系统上线时固定一组探针。探针分三部分：
每小时嵌入探针集，计算三个数值：随机对相似度的均值、标准差，以及已知相似对与随机对的平均差距。与滚动基线对比。
代码实现的核心逻辑：固定输入、固定对比、固定阈值。不依赖业务指标（如Top-1命中率）的滞后反馈，直接在向量空间层面捕捉漂移。
为什么现有监控会失效
传统监控盯着可用性：API通不通、快不快。嵌入模型的隐性故障绕过这一切——它"可用"但"无用"。
更棘手的是，这种漂移可能源于上游变化：模型版本微调、提示模板调整、甚至训练数据分布的渐进偏移。你的系统没动，但世界动了。
探针集的价值在于隔离变量。用完全固定的输入，排除业务流量的噪声，纯粹测量模型行为的稳定性。
落地建议与权衡
探针集需要维护成本。随机对可从历史日志采样，相似对需人工标注，对抗对最难设计——得找模型曾经能区分、现在可能混淆的边界案例。
频率也有讲究。每小时嵌入对大多数场景足够，高频调用会增加成本。建议对关键业务路径独立部署探针，与主流量隔离。
阈值设定需要历史数据。至少积累两周正常波动，再定义"三个标准差"。别在上线第一天就设死阈值。
这种监控不解决漂移根因，只解决"发现"问题。根因可能是模型提供商的静默更新、你的预处理管道变化、或语料库本身的语义漂移——但那是另一个战场。
向量检索的可靠性，正在从"能调用"进化到"能区分"。当你的嵌入模型停止区分任何事物时，你希望是第一个知道的人，还是最后一个？
热门跟贴