模型性能监控：准确率、召回率等指标的实时追踪、A/B测试与影子模式、性能退化阈值设定

模型上线不是终点，而是监控的起点。我见过太多团队，模型上线后就不管了，直到业务方反馈「最近推荐怎么这么差」才去排查——这时候往往已经损失惨重。

性能监控，说白了就是给模型装个「心电图」。你得实时知道它心跳正不正常，有没有「心肌梗塞」的风险。

核心指标：准确率、召回率、F1 的实时追踪

先说说最基础的几个指标。你可能会想：「这谁不会算？」但实时追踪和离线评估完全是两码事。

指标	离线评估	实时追踪
准确率	全量数据，一次性计算	滑动窗口，按分钟/小时聚合
召回率	有完整标注集	依赖延迟反馈，需做预估
F1 分数	精确计算	近似计算，关注趋势

我个人习惯的做法是：用滑动窗口 + 衰减权重。比如计算最近 1 小时的准确率，但越近的样本权重越高。这样既能捕捉突发变化，又不会因为单次抖动就误报。

举个例子，我曾在某个风控项目里，准确率从 98% 掉到 97.5%。离线看只降了 0.5%，但实时曲线显示——这是连续 30 分钟的下滑趋势。后来发现是某个渠道的流量特征变了。如果只看离线报表，至少晚半天才能发现。

A/B 测试与影子模式：两种验证策略

模型更新后，怎么验证它真的变好了？两个主流方案：A/B 测试和影子模式。

A/B 测试

这个大家应该不陌生。把流量随机分成两组，一组用旧模型（对照组），一组用新模型（实验组），对比效果。

但有几个坑，我踩过：

• 流量不够：如果你的业务每天只有几千次请求，A/B 测试的置信区间会大到没意义。我建议至少每天 10 万+ 样本再考虑。
• 指标选择：别只看一个指标。我记得有一次，新模型点击率提升了 5%，但转化率掉了 8%。如果只看点击率，就踩坑了。
• 时间窗口：有些效果不是立竿见影的。比如推荐系统，用户可能需要几天才能适应新策略。我一般会跑至少 7 天。

影子模式

影子模式是我个人非常喜欢的一种方式。新模型和旧模型同时跑，但新模型的结果只记录、不生效。说白了就是「让新模型在旁边看着，不说话」。

这样做的好处很明显：

• 零风险：新模型再烂，也不会影响线上业务。
• 积累数据：可以收集新模型在真实流量上的表现，包括它「如果上线会怎样」。
• 对比分析：能精确对比新旧模型在每一条样本上的差异。

我曾经在一个搜索排序项目里，用影子模式跑了 2 周。发现新模型在 30% 的查询上排序结果不同，但其中只有 60% 是真正变好的。剩下 40% 其实是退步的。如果没有影子模式，直接上线 A/B 测试，用户可能已经感受到体验下降了。

性能退化阈值设定

监控有了，指标有了，那什么时候该报警？这就涉及到阈值设定。

阈值设得太松，模型烂透了才报警；设得太紧，运维同学天天被误报骚扰。我总结了一套「三级阈值」策略：

级别	触发条件	响应动作
黄色预警	指标连续 3 个时间窗口下滑，但未超过 5%	通知负责人，人工排查
橙色预警	指标单次下跌超过 10%，或连续 6 个窗口下滑	自动回滚到上一个稳定版本
红色预警	指标下跌超过 20%，或业务核心指标（如收入）受影响	全量回滚 + 停服排查

阈值怎么定？我的经验是：基于历史数据的百分位数。比如过去 30 天，准确率的 P5（第 5 百分位）是 97.2%，那低于这个值就报警。这样能自适应业务波动。

嗯，这里要注意：阈值不是一成不变的。业务有周期性，比如电商大促期间，模型表现本身就会波动。我一般会按「时段」设定不同的阈值——白天和晚上不一样，工作日和周末也不一样。

知识体系总览

下面这张图，把整个监控体系串起来了。你可以把它当作一个「检查清单」：

代码示例：实时监控与阈值告警

最后给一段伪代码，展示实时监控的核心逻辑。你可以根据自己用的监控系统（Prometheus、Grafana、自研）做适配。

class ModelMonitor:
    def __init__(self, window_size=60, thresholds=None):
        self.window_size = window_size  # 滑动窗口大小（分钟）
        self.thresholds = thresholds or {
            'accuracy': {'yellow': 0.05, 'orange': 0.10, 'red': 0.20},
            'recall': {'yellow': 0.05, 'orange': 0.10, 'red': 0.20}
        }
        self.metrics_buffer = []  # 存储最近 N 个时间窗口的指标

    def update(self, metric_name, current_value):
        """更新指标并判断是否需要告警"""
        # 1. 更新滑动窗口
        self.metrics_buffer.append({
            'timestamp': time.now(),
            'metric': metric_name,
            'value': current_value
        })
        # 只保留最近 window_size 个数据点
        if len(self.metrics_buffer) > self.window_size:
            self.metrics_buffer.pop(0)

        # 2. 计算基准值（过去 window_size 的均值）
        baseline = self._calc_baseline(metric_name)

        # 3. 计算下降幅度
        drop_ratio = (baseline - current_value) / baseline

        # 4. 判断告警级别
        if drop_ratio >= self.thresholds[metric_name]['red']:
            self._trigger_alarm('red', metric_name, drop_ratio)
        elif drop_ratio >= self.thresholds[metric_name]['orange']:
            self._trigger_alarm('orange', metric_name, drop_ratio)
        elif drop_ratio >= self.thresholds[metric_name]['yellow']:
            self._trigger_alarm('yellow', metric_name, drop_ratio)

    def _calc_baseline(self, metric_name):
        """计算基准值：取过去 window_size 个点的中位数（抗噪）"""
        values = [item['value'] for item in self.metrics_buffer
                  if item['metric'] == metric_name]
        if not values:
            return 1.0
        return sorted(values)[len(values) // 2]

    def _trigger_alarm(self, level, metric_name, drop_ratio):
        """触发告警：发送通知、自动回滚等"""
        print(f"[{level.upper()}] {metric_name} dropped by {drop_ratio:.2%}")
        # 实际项目中：发送钉钉/邮件/短信，或调用回滚接口

监控这件事，做得好是「防患于未然」，做不好就是「狼来了」。关键是找到适合自己业务的节奏——指标选对、阈值设准、响应及时。嗯，做到这三点，你的模型就能「健康长寿」了。