为什么你的 LLM 告警总是迟到两周

大多数团队发现其 LLM 性能下降通常是在两周后，当时有人在 Slack 上发消息问：“嘿，有人注意到最近 AI 的输出似乎不太对劲吗？”到那时，损害已经造成：用户已经形成了负面印象，支持工单不断累积，而最初推动该功能的业务负责人也正在悄悄失去信心。

令人沮丧的是，你的基础设施在这段时间内一直非常健康。HTTP 200 状态码、180 毫秒的 p50 延迟、每次请求 0.04 美元的成本——仪表盘上的一切都显示为绿色。模型只是变得更安静、更模糊、更简短且更犹豫，而这些表现是基础设施监控无法察觉的。

这不是通过增加 Datadog 仪表盘就能弥补的监控漏洞。它需要一套完全不同类别的指标。

LLM 静默性能下降的剖析

静默性能下降（Silent degradation）是常态，而非例外。追踪生产部署的研究一致发现，大多数 LLM 在部署后的 90 天内都会出现可衡量的行为偏移（Behavioral drift）。检测延迟——即从性能下降开始到第一个用户投诉的时间——平均为 14 到 18 天。在实践中，这意味着团队始终是在基于过时的模型质量信息进行操作。

性能下降本身有四种截然不同的形式，每种形式都有不同的原因和检测策略。

**行为侵蚀（Behavioral erosion）**是逐渐发生的。回答变得更短。推理链缩减。在模型以前会给出直接回答的语境中，开始出现对冲语言（例如“这可能是”、“你可能想要考虑”）。这是最常见的形式，也是最难检测的，因为任何单一回答看起来都是合理的。

**语义偏移（Semantic drift）**发生在生产查询的分布偏离模型训练分布时。例如，一个针对实物产品配送问题训练的客服模型开始被问及数字交付的问题。模型仍然在生成流畅、自信的文本——但内容是错误的。

**安全层重新校准（Safety layer recalibration）**是团队很少预见到的供应商侧变化。一个以前直接回答某些类型问题的模型，开始添加过多的免责声明，或拒绝处理以前可以处理的边缘案例。拒绝率（Refusal rate）是在几天内缓慢上升，而非几小时。

**上下文腐化（Context rot）**更像是一个能力悬崖，而非平缓的下滑。对 18 个前沿模型的研究测试发现，每一个模型都会随着输入长度的增加而出现性能下降——有些模型在短上下文时准确率为 95%，而在中等长度时降至 60%，这远在达到宣称的上下文窗口限制之前。

这四种形式的共同点在于，标准基础设施监控（延迟、错误率、吞吐量、Token 成本）对它们完全视而不见。一个保持 200 毫秒响应时间的模型可能在 30 天内损失 23 个百分点的任务准确率，却从未触发任何告警。

真正奏效的指标

弥补这一差距需要对语义层（Semantic layer）进行检测，而不是基础设施层。以下指标构成了一个实用的监控栈，已在生产环境中得到验证。

**Token 长度分布偏移（Token length distribution drift）**是成本最低且具有惊人预测能力的信号。建立一个输出 Token 数量的 7 天滚动基准直方图，以 25 个 Token 为一组进行分桶。每天计算当前输出分布与基准之间的 KL 散度（KL divergence）。KL 散度超过 0.15 通常意味着用户感知质量下降的可能性高达 87%。计算成本每天约 0.02 美元，它是投资回报率最高的监控原语。它能在用户投诉出现前约 11 天检测到性能下降。

**基于嵌入的语义偏移评分（Embedding-based semantic drift score）**能捕捉到 Token 计数无法发现的含义变化。使用 Sentence Transformer 或供应商的嵌入 API 为每天的输出样本生成嵌入。应用 PCA 将其降至 64 维，然后计算与已知稳定运行期的参考基准之间的余弦相似度。当余弦相似度降至 0.82 以下时，模型的回答分布偏移已大到值得调查。这能捕捉到长度监控无法发现的“词同义异”故障模式。

**输出 Schema 符合率（Output schema conformance rate）**对于任何生成结构化输出的任务都至关重要。如果你的流水线生成 JSON、提取实体到 Schema 中或调用带有类型签名的函数，请跟踪通过确定性 Schema 验证的回答百分比。Schema 违规率不会随机下降——它们呈现出趋势，而这种趋势可以在下游系统崩溃发生前进行预测。

**用户修复率（User-repair rate）**是最真实的信号，因为用户用行为而非言语投票。跟踪用户重新提交查询、在收到回复后几秒内重新表述请求，或在正式使用前对 AI 生成的输出进行大量编辑的频率。高于基准的重试率表明模型未能第一次就解决请求。高于基准的编辑率表明输出结果无法直接使用。这些隐式的行为信号比显式的点赞/点踩反馈能产生更真实的训练和质量数据，因为后者对不满意的用户存在严重的筛选偏差。

**按查询簇划分的拒绝率（Refusal rate by query cluster）**比任何其他信号都能更快地捕捉到安全层偏移。按查询类型或意图簇对拒绝事件进行细分，并滚动跟踪每个簇的拒绝率。特定簇内拒绝率的突然飙升——例如，编程助手开始拒绝编写它以前处理过的某些库调用——通常是能检测到的供应商侧更新的最早迹象。该信号通常比用户投诉提前 3 到 5 天到达，对于预防性调查非常有价值。

**按文档类型划分的实体提取准确率（Entity extraction accuracy per document type）**对于信息提取和 RAG 流水线至关重要。按文档类别而非全局汇总提取准确率。全局准确率可能保持稳定，而某一类文档却在悄悄失败——当上游文档格式发生变化或特定内容领域的检索质量下降时，这是一种常见的故障模式。

构建异常检测层

拥有指标是必要的，但还不够。你需要一套检测逻辑，能区分信号与噪声，并能辨别出是性能退化的开始还是孤立的异常情况。

最简单有效的方法是采用带有 KL 散度（KL divergence）阈值的滚动基准。存储 7 天窗口内的每日指标分布，并将每个新的一天与滚动基准进行对比。当多个指标同时发生偏离时——例如 Token 长度分布发生偏移、嵌入相似度下降且拒绝率上升——你就有了确凿的证据表明这是真正的性能退化，而非统计噪声。

变点检测（Changepoint detection） 值得在拥有关键指标的时间序列数据后加入。在操作层面，区分异常（单日的糟糕表现）和变点（指标统计特性的持续转变）至关重要。异常情况值得调查；变点则需要立即修复。标准的变点检测算法（如 PELT、BOCPD）在 LLM 质量指标上表现良好，并且在大多数语言中都有开源实现。

对采样后的生产流量进行 LLM 作为评委（LLM-as-judge）打分 能提供最高保真度的信号，但成本更高——在中等采样率下，每天大约花费 15 到 40 美元。评委模型会根据针对你的任务校准的评分标准，从相关性、完整性、准确性和格式维度对样本进行评估。当任何维度的滚动平均值比基准下降 0.3 或更多时，触发警报。在 5%–10% 的请求上运行，而不是全部流量，以控制成本。LLM 作为评委通常能在用户投诉前 5 到 8 天捕捉到退化——比任何其他指标都要快。

多指标关联 能显著减少误报。对信号进行加权组合：Token KL 散度（权重 0.3）、嵌入余弦偏移（权重 0.4）、LLM 作为评委得分（权重 0.2）、拒绝率变化（权重 0.1）。使用这种加权组合方法的团队报告称，漂移检测的 AUC 大约为 0.93，虚假警报显著少于单指标监控。

将指标与根因关联

只有当检测能引导你做出正确的诊断时，它才是有用的。LLM 质量退化有四个截然不同的根因，每个原因都会产生不同的指标特征。

供应商侧模型更新：拒绝率变化和 Schema 符合度下降最先出现，通常不会伴随 Token 长度或嵌入的变化。这种信号是剧烈且阶梯式的，而非渐进的。检查供应商的变更日志和状态页面；大多数供应商仅在发布说明中公布模型更新，而不会通过 API 通知。

输入分布偏移：嵌入偏移最先出现。Token 长度和 Schema 符合度会滞后几天。退化是渐进的，并且与进入系统的用户查询变化相关。使用与输出端相同的滚动基准方法来审查你的输入分布。

检索质量退化（针对 RAG 系统）：忠实度（Faithfulness）指标和实体提取准确度下降，而延迟、Token 长度和拒绝率保持稳定。LLM 工作正常，只是它获取的上下文变差了。修复方案应当在检索管道的上游。

提示词回归：在提示词部署后，Schema 符合度、拒绝率和输出结构发生剧烈变化。时间戳的关联通常非常明显。提示词变更应被视为代码部署，并具备自动回滚能力。

运营架构

大多数团队将 LLM 质量指标作为事后补救，强行挂载到现有的基础设施监控上。这种方法会产生摩擦，导致团队在第一波误报后就关闭了监控。

更好的架构是将一部分生产请求样本（在中等流量下，5%–10% 足以保证统计学意义）路由到并行的评估管道中。该管道同步计算廉价指标（Token 长度、Schema 符合度），并将昂贵指标（嵌入相似度、LLM 作为评委）推迟到后台进程中处理，从而不增加用户路径的延迟。

将指标存储在时间序列数据库中——InfluxDB、具有适当保留策略的 Prometheus，或你的可观测性平台指标库——并保持足够的粒度，以便对每日或每小时的数据桶运行异常检测。按维度聚合：用户群体、查询类型、模型变体、文档类型。全局平均值会掩盖特定领域的退化，而这通常才是问题实际表现出的形式。

针对多指标趋同而非单一阈值触发警报。目标不是对每一次偏差都触发警报——那会导致警报疲劳，从而使监控被禁用。其目标是揭示两个或多个独立信号都表明发生了偏移的情况，使误报率降到足够低，从而让工程师认为警报是有意义的。

基于 OpenTelemetry 的仪表化（通过 OpenLLMetry 或 OpenLIT）允许你将质量指标与标准基础设施追踪一起导出到团队已在使用的任何可观测性后端——Grafana、Datadog、Jaeger。在现有追踪中添加语义质量指标比部署专门的 LLM 可观测性工具干扰更小，并且它将质量数据放在了工程师调查事件时查看的同一个地方。

两周的滞后是一个设计选择

14 到 18 天的检测滞后并不是不可避免的。这是一个特定架构决策的结果：监控容器而非响应内容。

消除这种滞后的团队构建了上述评估流水线，并将语义指标（semantic metrics）作为一等信号进行追踪。而那些任由滞后存在的团队则将 LLM 质量视为“等产品稳定后”再进行测量的事情——但这种稳定永远不会到来，因为生产环境的查询分布（query distributions）从未停止过变化。

此处描述的指标可以逐步实现。从 Token 长度分布偏移（成本低、信号强、仅需一天即可实现）和 Schema 符合率（如果你正在进行任何结构化提取，这已经是现成的）开始。随着流量增加使采样变得可行，再增加嵌入偏移（embedding drift）和 LLM-as-judge 评分。

目标并不是从第一天起就实现完美的监控覆盖，而是在收到 Slack 报错消息之前就发现性能退化。

---

生产环境的 LLM 监控与基础设施监控有着本质的区别，因为你所衡量的东西——语义质量——无法通过 HTTP 状态码或延迟分位数来体现。有效的指标是行为性的：输出的分布随时间如何变化，以及这种变化是否与用户实际尝试解决的查询相关？一旦你在正确的层面上进行测量，检测滞后就会从数周缩短至数天。