AI 性能异常检测系统：用 Transformer 替代阈值告警的生产验证报告

AI 性能异常检测系统：用 Transformer 替代阈值告警的生产验证报告

一、告警泛滥的困境：每天 300 条告警，只有 2 条是真的

团队运维群里的告警消息日均 300 条，但经过排查后确认需要处理的有效告警日均只有 2~3 条。虚警率超过 99%。这不仅是资源浪费，更严重的问题是产生了"狼来了"效应——工程师开始习惯性地忽略告警，导致真正的问题被淹没。

传统的阈值告警（CPU > 80% 告警、延迟 > 500ms 告警）在面对业务的自然波动时必然产生大量误报。比如每天凌晨的定时任务会让 CPU 短暂飙升到 95%，这并不构成问题。又比如大促前一周的延迟从 50ms 爬升到 120ms，虽然每个时刻都在阈值以下，但趋势本身已经预示了即将到来的瓶颈。

这个问题的本质是：阈值告警是"点状"判断，而性能问题往往表现为"趋势性"和"上下文相关"的特征。需要一种能理解时间序列趋势的检测方法。

二、时序 Transformer 的模型选型与设计

时序异常检测领域的主流方案有三种：统计方法（3-sigma、MAD）、传统机器学习（Isolation Forest、LSTM AutoEncoder）和 Transformer。经过对比实验：

Informer 是专门为长序列时序预测优化的 Transformer 变体，通过 ProbSparse Self-Attention 机制将 O(L²) 复杂度降至 O(L log L)，适合处理 15 秒粒度、30 天跨度的监控数据（约 17 万个数据点）。

# Informer 时序异常检测 —— 预测值 vs 真实值的偏差作为异常分数
import torch
import torch.nn as nn

class AnomalyInformer(nn.Module):
"""基于 Informer 的时序异常检测模型"""
def __init__(self, enc_in=12, dec_in=12, c_out=12, seq_len=96, label_len=48):
"""
enc_in=12: 输入特征维度（CPU、内存、延迟、QPS、错误率、网络I/O…）
seq_len=96: 输入序列长度（96 * 15s = 24min 的历史窗口）
label_len=48: 用于预测的已知长度
"""
super().__init__()
self.encoder = InformerEncoder(
enc_in=enc_in,
# ProbSparse Attention 的核心：只计算 Top-u 个 query 的注意力
# u = c * ln(L_Q)，大幅降低计算复杂度
factor=5, # probsparse 因子
d_model=512, # 隐层维度
n_heads=8, # 注意力头数
e_layers=3, # encoder 层数
dropout=0.05, # 低 dropout，避免时序模式被过度平滑
)
self.projection = nn.Linear(512, c_out)

def forward(self, x):
# x: (batch, seq_len=96, enc_in=12)
enc_out = self.encoder(x)
# 输出下一时刻的预测值
pred = self.projection(enc_out[:, -1, :]) # (batch, c_out=12)
return pred

def anomaly_score(self, x: torch.Tensor, y_true: torch.Tensor) -> float:
"""
计算异常分数：多维度预测误差的加权平方和
各维度的权重根据业务重要性动态调整
"""
y_pred = self.forward(x)
# 维度权重：错误率 > 延迟 P99 > CPU > QPS > …
dim_weights = torch.tensor([2.0, 1.5, 1.2, 1.0, 0.8, 0.8, 0.8, 0.5, 0.5, 0.5, 0.3, 0.3])
weighted_error = dim_weights * (y_true – y_pred) ** 2
raw_score = weighted_error.sum().item()
# 归一化到 [0, 1]：用历史 7 天数据的 99.9 分位数作为上界参考
return min(raw_score / self._score_upper_bound, 1.0)

三、LLM 二次研判：从异常分数到可操作的告警

Transformer 模型输出的异常分数只是一条曲线上的峰值。峰值可能由多种原因引起——真正的服务异常、计划内变更、业务引流切换——仅凭分数无法判断严重性。引入 LLM 做二次研判，将异常分数与最近的部署记录、变更日志、业务事件结合，输出带原因分析的告警：

# LLM 二次研判 —— 将异常分数转化为带根因的告警
ANOMALY_TRIAGE_PROMPT = """你是一个在线服务运维专家。根据以下信息，判断这个告警是否需要人工介入。

## 异常信息
– 异常分数: {anomaly_score}（0~1，越高越异常）
– 异常维度: {affected_metrics}
– 时间: {timestamp}

## 近期上下文
– 最近部署: {recent_deployments}
– 业务事件: {business_events}
– 同类服务状态: {peer_service_status}

请用 JSON 格式回复：
{{
"need_action": true/false,
"severity": "critical|warning|info",
"likely_cause": "最可能的根因（一句话，如'可能是 10 分钟前代码发布引起'）",
"suggested_action": "建议的处理动作",
"confidence": 0.0-1.0
}}
"""

def triage_anomaly(anomaly_score: float, context: dict) -> dict:
prompt = ANOMALY_TRIAGE_PROMPT.format(
anomaly_score=f"{anomaly_score:.3f}",
affected_metrics=json.dumps(context.get("affected_metrics", [])),
timestamp=context.get("timestamp"),
recent_deployments=json.dumps(context.get("deployments", []), indent=2),
business_events=json.dumps(context.get("events", []), indent=2),
peer_service_status=json.dumps(context.get("peers", []), indent=2),
)
response = llm_client.chat.completions.create(
model="gpt-4o-mini", # 轻量模型即可，不需要重度推理
messages=[{"role": "system", "content": prompt}],
temperature=0.0, # 确定性输出
response_format={"type": "json_object"},
)
return json.loads(response.choices[0].message.content)

四、实际效果与误报分析

系统上线 30 天后的数据对比：

唯一一个未被发现的故障是数据库连接池耗尽——指标的变化过于缓慢（3 小时内连接数从 20 渐变到 250），模型将其识别为正常的业务增长而非突变异常。这暴露了 Transformer 方案对"缓慢渐变型"异常的检测盲区，下一迭代需要引入 Trend Detector 作为补充。

五、总结

AI 性能异常检测系统的核心经验：

后续优化方向：引入多模型集成——Informer（突变检测）+ StatsForecast（趋势检测）+ LLM（综合研判），覆盖更多异常类型。