假设你经营着一家名叫「智香楼」的餐厅，后厨有一位 AI 大厨，每天根据食材、时令和客流预测做什么菜、备多少料。过去你只能等月底看营业额报表，才知道这个月哪道菜受欢迎；可如果某道菜这周突然卖不动了，等你发现时，食材早就烂在仓库里。在线性能指标，就是餐厅门口那块「透明后厨大屏」：实时显示每道菜的出品速度、出餐耗时、食客反馈得分，哪个环节亮起红灯，你当场就能发现并调整。但真正的难题在于——食客的满意评价要等他吃完甚至回家后才到达，这份「延迟的反馈」正是你最需要处理的信息。这篇文章，我们就从智香楼出发，学会如何设计一套实时监控 AI 模型健康的在线指标系统。

岗位关联

在线性能指标是 AI 模型上线后的「心电图」，学会它，你能在模型出问题的第一时间发现并止损，是从「会训练模型」走向「能守护模型」的核心技能。

目录
  1. 可视化演示
  2. 指标概念定位
  3. 指标采集体系
  4. 延迟标签设计
  5. 近似评估方法
  6. 异常检测机制
  7. 工程落地实践
  8. AI 应用场景
  9. Python 演示
  10. 常见误区
  11. 面试题

可视化演示

展示模型在线指标的采集架构、异常检测与漂移监控，实时把握线上表现

本节配有交互动效（进入视口后自动加载，约 3KB）。

在线指标采集架构 请求流经模型推理后异步采集预测与标签 延迟标签通过队列缓冲后回写指标系统 指标 = f（预测，真实标签） 在线采集实现模型表现的实时可观测

指标概念定位

智香楼开业第三个月，你发现「月底复盘」有个致命的迟钝：一道菜出了问题，要等三十天才被看见，那时口碑已经崩了。于是你决定在后厨装一块透明大屏，实时显示每道菜从下单到上桌的每个环节。在线性能指标就是这块大屏——它连着模型线上服务的每一次预测，持续输出「此刻模型健不健康」的答案。

传统的离线评估像「期末考试」：训练完成后用一套固定测试集打分，一次定胜负。在线指标则是「随堂测验」：每来一条真实请求就记录一次预测行为，用滚动方式不断刷新健康评分。两者最大的区别在于，在线指标面对的是真实分布、真实用户和真实延迟，计算出的数值才代表模型「此刻」的真实表现。

搭建这套体系要直面三大挑战：第一，真实标签往往延迟到达，像食客吃完才评价；第二，线上请求分布会随时间漂移，测试集的比例早已失效；第三，海量请求下只能抽样与聚合，指标本身有噪声。因此需要覆盖「采集—回填—评估—告警」的完整生命周期。其中，用滑动窗口计算在线准确率是最基础的公式：

有了这块大屏，智香楼不再等月底，而是随时知道菜单该不该调整。接下来要解决的，是大屏上的数据从哪来——也就是指标怎么采集。

Acconline(t)=1W∑i=t−W+1tI(y^i=yi)\displaystyle Acc_{online}(t) = \frac{1}{W} \sum_{i=t-W+1}^{t} \mathbb{I}(\hat{y}_i = y_i)
这个公式用最近 W 条已获标签的预测样本实时估算准确率，就像大屏滚动显示「最近 100 桌客人的好评率」。
  1. 在线准确率 $Acc_{online}(t)$表示时刻 $t$ 模型最新的准确率估值，随每个新样本到达不断刷新，像实时跳动的评分大屏。
    Acconline(t)Acc_{online}(t)
  2. 滑动窗口 $W$只取最近 $W$ 条样本求平均，让旧数据自然滑出窗外，兼顾「敏感」与「稳定」。
    1W∑i=t−W+1t\frac{1}{W}\sum_{i=t-W+1}^{t}
  3. 指示函数 $\mathbb{I}(\cdot)$括号内条件成立记 1、否则记 0，本质是在统计窗口内「猜对了多少单」。
    I(y^i=yi)\mathbb{I}(\hat{y}_i = y_i)

指标采集体系

大屏要显示「出餐速度」，你得先在每个出餐口装传感器。同理，在线指标采集的第一步，是在模型服务的每个环节埋点：请求什么时候进来、什么时候出去、预测结果是什么、耗时多少。没有埋点，一切指标都是空中楼阁。

指标要体系化地采集，通常归为四类：量（QPS 吞吐）、质（准确率等质量指标）、速（响应延迟）、钱（推理成本），这就是常说的「M4」维度。埋点不只是打日志，还要给每个样本配唯一请求 ID，串联起「请求→预测→标签」的完整链路，否则后续做延迟标签回填时，样本对不上账。

采集之后要过数据管道：实时流负责秒级汇总，离线仓库负责小时级或天级回填。存储上，指标通常按时间序列保存，配合滑动窗口做聚合查询。延迟类指标不能只看平均值——高并发下长尾比均值更致命，所以用分位数刻画：

传感器装好了，数据源源不断涌向大屏。但此时你发现：屏幕上只能看到「出餐快不快」，还看不到「顾客满不满意」——因为满意度要等顾客吃完才反馈，这就引出了延迟标签。

QPS=NserveΔt,P95=min⁡{l∣P(L≤l)≥0.95}\displaystyle QPS = \frac{N_{serve}}{\Delta t}, \qquad P_{95} = \min\{l \mid P(L \le l) \ge 0.95\}
QPS 是每秒服务吞吐，P95 是「95% 的请求都能在 l 毫秒内返回」，像后厨承诺「95% 的菜在 15 分钟内上齐」。
  1. 服务吞吐 $QPS$$\Delta t$ 时间内服务的请求数 $N_{serve}$ 除以时长，衡量系统扛不扛得住客流峰值。
    NserveΔt\frac{N_{serve}}{\Delta t}
  2. P95 延迟定义$P(L \le l) \ge 0.95$ 表示「延迟不超过 $l$ 的概率至少有 95%」，$l$ 就是长尾阈值。
    P(L≤l)≥0.95P(L \le l) \ge 0.95
  3. 取最小值 $\min\{\cdot\}$在所有满足条件的 $l$ 中取最小者，保证 P95 是一个具体、可告警的数字。
    min⁡{l∣P(L≤l)≥0.95}\min\{l \mid P(L \le l) \ge 0.95\}

延迟标签设计

智香楼最头疼的事：菜端上桌 ≠ 顾客满意。真实评价往往要等顾客吃完、甚至隔天在外卖平台补评。模型也一样——推荐系统今天推送的商品，用户明天才决定买不买；风控模型判断的这笔交易，要等几周后才知道是否真的欺诈。

延迟标签的设计分三块：分析延迟来源、设计回填机制、评估滞后影响。延迟来源包括业务周期（转化要几小时）、人工流程（审核要几天）、数据链路（同步要几分钟）。回填机制上，可以用流式管道实时补充标签，也可以用批处理在夜间回填，关键是「预测时刻」和「标签时刻」要对齐记录，否则指标会算错账。

滞后评估的影响在于：部分样本的标签永远不来（比如用户再也没回来），导致「已获标签集合」有偏——只统计快速反馈的样本，会高估或低估真实表现。为此需要监控标签到达率，并用指数滑动平均刻画平均延迟：

等标签实在太慢怎么办？智香楼的聪明做法是：不等食客评价，先观察「剩菜量」和「翻台率」。对应到模型，就是用代理指标做近似评估。

Davg(t)=α⋅dt+(1−α)⋅Davg(t−1)\displaystyle D_{avg}^{(t)} = \alpha \cdot d_t + (1-\alpha) \cdot D_{avg}^{(t-1)}
这条公式给「最新的标签延迟」更高权重，让大屏上的平均延迟既平滑又能快速反映变化，像温度计既防抖又灵敏。
  1. 新观测 $d_t$第 $t$ 个已获标签样本的延迟时长，是本次更新输入的新读数。
    dtd_t
  2. 平滑系数 $\alpha$取值 0 到 1 之间，控制新读数的影响权重，通常取 0.1~0.3 兼顾平滑与响应。
    α\alpha
  3. 递推更新 $D_{avg}^{(t)}$新均值等于新读数与旧均值按权重混合，只需记住上一个值，内存开销极小。
    α⋅dt+(1−α)⋅Davg(t−1)\alpha \cdot d_t + (1-\alpha) \cdot D_{avg}^{(t-1)}

近似评估方法

在没有评价的几小时里，怎么知道菜品受不受欢迎？服务员会偷偷观察：这桌菜剩了多少、客人有没有拍照、叫没叫加菜。这些「间接信号」就是代理指标。模型侧也一样：点击率、预览时长、用户反馈按钮，都能在真实标签到达前充当健康度探针。

近似评估的核心方法论是：给每个预测样本关联一个代理指标 $p$，同时保存未来的真实标签 $q$，然后定期计算两者相关性。相关性高，说明代理靠谱，可以在标签缺失期放心使用；相关性低，说明代理是「伪信号」，要赶紧更换。常用的度量是皮尔逊相关系数：

代理指标让大屏在标签缺位时仍有读数。但智香楼发现，光看「剩菜率」还不够——如果某天全城下暴雨，所有桌都剩菜，这究竟是菜的问题还是天气的问题？这就需要对指标做异常检测，分辨真变化与正常噪声。

ρ=∑i=1k(pi−pˉ)(qi−qˉ)∑i=1k(pi−pˉ)2∑i=1k(qi−qˉ)2\displaystyle \rho = \frac{\sum_{i=1}^{k} (p_i - \bar{p})(q_i - \bar{q})}{\sqrt{\sum_{i=1}^{k}(p_i - \bar{p})^2}\sqrt{\sum_{i=1}^{k}(q_i - \bar{q})^2}}
$\rho$ 越接近 1，代理指标与真实质量越同步，像「剩菜率」越能反映「满意度」。
  1. 代理序列 $p_i$ 与真实序列 $q_i$同一批样本的两套分数，一个即时可得、一个延迟到达，构成成对数据。
    pi, qip_i, \ q_i
  2. 中心化 $p_i - \bar{p}$各自减去均值，只保留「波动方向」，剔除整体高低水平的影响。
    pi−pˉ, qi−qˉp_i - \bar{p}, \ q_i - \bar{q}
  3. 标准化分母 $\sqrt{\sum(\cdot)^2}$除以各自的能量，把系数压缩到 $[-1,1]$ 区间，只看形状相关性。
    ∑i=1k(pi−pˉ)2\sqrt{\sum_{i=1}^{k}(p_i - \bar{p})^2}

异常检测机制

大屏数据每天都会波动：周末客流大、雨天差评多，这些「正常噪声」如果每次都报警，值班师傅会直接关掉铃声。异常检测要解决的核心问题，就是把「真实异常」从「正常波动」中分离出来。

常用的方法是标准化 z-score：记录指标的历史均值和标准差，当前值偏离均值 N 个标准差就触发告警。它比固定阈值更聪明，能自动跟随季节性和周期性。此外还要结合漂移信号：准确率下滑、置信度分布偏移、代理指标与真实指标相关性骤降，都是模型生病的症状。

告警阈值设计要权衡灵敏与误报：阈值太紧（小 z）天天误报，太松（大 z）则漏报事故。实践中先用历史数据模拟阈值，观察「正常期」的误报率，再确定 $\xi$ 的取值：

报警只是开始。智香楼把铃声接到值班手机，收到告警后看大屏、查原因、调菜单，形成闭环。这个「从指标到动作」的链路，就是工程落地。

zt=xt−μt−1σt−1,∣zt∣≥ξ⇒ALERT\displaystyle z_t = \frac{x_t - \mu_{t-1}}{\sigma_{t-1}}, \qquad |z_t| \ge \xi \Rightarrow \text{ALERT}
这个公式把「当前读数」和「历史常态」对比，偏离超过 ξ 个标准差就报警，像餐厅规定「好评率跌破历史均值两个点就找主厨」。
  1. 当前读数 $x_t$$t$ 时刻最新算出的在线指标值，比如窗口内的在线准确率。
    xtx_t
  2. 历史基准 $\mu_{t-1}, \sigma_{t-1}$截至上一时刻的历史均值与标准差，代表「平常是什么水平、波动有多大」。
    μt−1,σt−1\mu_{t-1}, \quad \sigma_{t-1}
  3. 标准化 $z_t$把偏离量折算成「多少个标准差」，让不同量纲的指标可以统一设置阈值。
    zt=xt−μt−1σt−1z_t = \frac{x_t - \mu_{t-1}}{\sigma_{t-1}}
  4. 告警触发 $|z_t| \ge \xi$偏离绝对值超过阈值即报警，$\xi$ 通常取 2 到 3。
    ∣zt∣≥ξ|z_t| \ge \xi

工程落地实践

智香楼的最终形态是一间「数字食客体验中心」：大屏看板、值班台、告警手机一应俱全。对应到 AI 工程，就是监控平台、看板与告警响应的组合。平台统一采集各类指标并长期存储；看板按角色分层展示——老板看总览、主厨看菜系、服务员看单桌。

告警要能落地，得区分级别和责任人：准确率跌破红线是 P0，立即核因；某类请求延迟升高是 P1，观察处置；代理指标相关性下滑是 P2，排期优化。同时每次告警都要记录处理结果，供复盘时调优阈值，避免同样的误报反复消耗团队精力。

告警系统本身也要被监控——如果误报率太高，工程团队会逐渐麻木。所以需要回放评估告警质量，用告警精准率衡量：

至此，智香楼的透明后厨大屏终于完整：传感器采集、延迟评价回填、代理指标兜底、异常铃声把关、值班团队闭环。一套在线性能指标体系，让模型像餐厅一样被实时照顾着。

Precisionalert=TPTP+FP\displaystyle Precision_{alert} = \frac{TP}{TP + FP}
告警精准率等于「真正出事」的告警占比，像考核「餐厅的报警铃，响起来时到底有几次是真的出事」。
  1. 真告警 $TP$确诊为真实问题的告警次数，比如当天确实发生了模型效果骤降。
    TPTP
  2. 误报 $FP$查无实据的告警次数，比如只是节假日引起的正常波动。
    FPFP
  3. 告警精准率 $Precision_{alert}$精准率越高，值班团队越信任铃声；长期低于 0.5 就该调整阈值或检测方法。
    TPTP+FP\frac{TP}{TP+FP}

AI 应用场景

电商大促推荐系统实时监控

阶段：模型部署与在线运维

解决的问题：大促流量暴涨时，推荐模型效果可能因人群分布骤变而滑坡。传统做法是等第二天报表，损失大量 GMV。AI 方案：对 CTR、转化率、响应延迟做在线指标采集，用滑动窗口准确率与 z-score 告警，分钟级发现效果衰减。

具体案例：某电商平台双十一当天，监控系统发现「猜你喜欢」模块窗口 CTR 下降 15%，z 值超过阈值，值班同学立即回滚到上一版本模型，两小时内恢复，避免了上亿流量的无效曝光。

交易风控模型的事后标签核对

阶段：延迟标签管理与近似评估

解决的问题：风控模型判断交易是否欺诈，真实结果要等数周后银行结算才知道，实时准确率无法直接计算。AI 方案：先采集模型置信度、拒绝率、首笔逾期率等代理指标，设计「T+7 标签回填」管道，定期计算代理与真实指标的相关性，验证代理是否仍然可靠。

具体案例：某支付公司对风控模型建立月度相关性报告，发现某策略的代理相关性从 0.85 跌到 0.6，提前定位到新上线渠道的样本偏差，及时调整策略参数，避免了坏账率上升。

智能客服满意度延迟评估

阶段：指标趋势异常检测与告警

解决的问题：客服机器人答得好不好，用户评价常滞后甚至缺失。用「转人工率、重复提问率、会话停留时长」作为代理指标，结合采样回访获取真实满意度标签，构建实时体验监控。

具体案例：某电信运营商智能客服上线新话术后，转人工率代理指标在 3 小时内上升 8%，触发黄牌告警，运营团队分析发现是话术模板与新业务政策冲突，当天完成修正。

Python 演示

python75 行
import mathimport random  class OnlineMonitor:    """在线性能指标监控器: 滑动窗口准确率 + 延迟标签 + 代理指标 + 异常告警"""     def __init__(self, window=100, threshold=0.8, delay=5, z_thr=3.0):        self.window = window        self.threshold = threshold        self.delay = delay        self.z_thr = z_thr        self.predictions = []   # (时间戳, 置信度, 预测标签)        self.true_labels = {}   # 时间戳 -> 真实标签 (延迟到达)        self.acc_history = []   # 在线准确率历史        self.alert_count = 0     def predict(self, ts, confidence):        """模拟线上预测: 按置信度决定对错, 真实标签延迟 delay 步到达"""        pred = 1 if random.random() < confidence else 0        self.predictions.append((ts, confidence, pred))        if random.random() < 0.95:            self.true_labels[ts + self.delay] = (                pred if random.random() < confidence else 1 - pred            )        return pred     def online_accuracy(self, now):        """滑动窗口内已获标签样本的命中率"""        recent = [            p for p in self.predictions            if now - p[0] <= self.window and p[0] in self.true_labels        ]        if not recent:            return None        hits = sum(1 for ts, _, pred in recent if self.true_labels[ts] == pred)        return hits / len(recent)     def proxy_confidence(self, now):        """近似评估: 无标签时用窗口内平均置信度当作健康度代理"""        recent = [p for p in self.predictions if now - p[0] <= self.window]        return sum(p[1] for p in recent) / len(recent) if recent else None     def z_score(self, x):        """用近 30 个点的均值与标准差做标准化, 返回偏离几个标准差"""        hist = self.acc_history[-30:]        if len(hist) < 20:            return 0.0        mu = sum(hist) / len(hist)        var = sum((v - mu) ** 2 for v in hist) / len(hist)        return (x - mu) / math.sqrt(var + 1e-9)     def run(self, steps=300):        """第 200 步后模型能力下滑, 模拟线上漂移"""        for ts in range(steps):            confidence = 0.9 - max(0, ts - 200) * 0.004            self.predict(ts, confidence)            acc = self.online_accuracy(ts)            if acc is None:                continue            self.acc_history.append(acc)            proxy = self.proxy_confidence(ts)            z = self.z_score(acc)            if acc < self.threshold and z > self.z_thr:                self.alert_count += 1                print(                    f"[告警] 时刻={ts} 准确率={acc:.2f} "                    f"代理置信度={proxy:.2f} z={z:.2f}"                )        print(f"监控结束: 产生 {self.alert_count} 次告警, "              f"末段准确率 {self.acc_history[-1]:.2f}")  if __name__ == "__main__":    OnlineMonitor().run()
目的：模拟一个线上模型从健康到漂移的全过程，演示滑动窗口在线准确率、延迟标签回填、代理置信度与 z-score 告警如何协同工作。
  1. self.true_labels[ts + self.delay] = (标签延迟 5 步后回填，key 是「预测时刻 + 延迟」，保证样本对得上账。
  2. recent = [p for p in self.predictions if now - p[0] <= self.window and p[0] in self.true_labels]只挑「最近窗口内且已获标签」的样本，过滤掉无标签噪声。
  3. hits = sum(1 for ts, _, pred in recent if self.true_labels[ts] == pred)统计窗口内预测命中的样本数。
  4. return hits / len(recent)在线准确率 = 窗口内命中数 / 窗口内已回填样本数。
  5. sum(p[1] for p in recent) / len(recent) if recent else None用窗口内平均置信度当代理指标，标签没到时也能估计健康度。
  6. hist = self.acc_history[-30:]取历史最近 30 个准确率构成参考基线，跟随近期水平。
  7. return (x - mu) / math.sqrt(var + 1e-9)z 分数表示偏离历史均值几个标准差，加小常数防止除零。
  8. confidence = 0.9 - max(0, ts - 200) * 0.004第 200 步后模型能力逐步下滑，模拟真实漂移。
  9. if acc < self.threshold and z > self.z_thr:双重条件：既跌破红线又显著偏离历史，才触发告警以降低误报。

常见误区

误区我认为在线性能指标就是「模型每预测一条，立刻就能算出准确率」，就像考试交卷当场出分。如果线上准确率没显示，一定是系统没做好。

正解预测结果和真实标签往往是异步的。菜端上桌时，你并不知道顾客是否满意。真实标签要等业务周期走完才回填，所以在标签到达前只能计算代理指标与工程指标，准确率必须等窗口内样本完成回填后才有意义。

为何常见：离线评估时「答案」和「预测」同时存在，让人误以为生产环境也天然如此，忽略了反馈链路的时间差。

误区我习惯每周把离线测试集跑一遍，准确率不掉就认为线上模型没问题，省事又直观。

正解离线测试集是静态分布，线上是动态分布。测试集准确率再高，也代表不了真实用户在真实场景下的表现。在线指标必须基于线上真实请求计算，并配合分布漂移检测（如置信度分布偏移、代理相关性下降），才能反映模型「此刻」的健康状态。

为何常见：测试集指标好算、可复现，容易让人忽视它与线上分布的差异，产生「考试好 = 工作好」的错觉。

误区我认为设阈值越简单越好，直接写死「准确率 < 80% 告警」，省得每次调参。

正解固定阈值无法适应季节性和周期性波动。节假日、大促、不同时段本身就有正常起伏，固定阈值会导致平时狂报警、真正出事时反而淹没在噪声里。正确做法是用 z-score、EWMA 等基于历史统计的方法，并周期性回放校准阈值。

为何常见：固定阈值实现成本最低、最符合直觉，但健康指标天然有波动，固定的线必然误伤。

误区我上线监控时恨不得每个中间变量都埋点，觉得多存点总没错，以后分析啥都有。

正解采集要有体系，先明确「量质速钱」四类维度以及每个指标的服务对象与计算口径。无规划地全量埋点会让数据管道爆炸、存储成本飙升，还会因口径混乱导致同一指标在不同看板上数值打架。

为何常见：技术人倾向于「数据先留着」，却忽略了采集、存储、维护的成本，以及口径统一的管理难度。

面试题

Q1. 在线性能指标与离线评估最本质的区别是什么？

单选题 · easy

  • A.在线指标必须用 GPU 训练模型
  • B.离线评估需要标注全部样本
  • C.在线指标基于线上真实数据流← 正确答案
  • D.离线评估使用流式计算引擎

答案：C。在线指标基于线上真实请求的连续数据流实时计算，反映模型当前状态；离线评估则是用固定测试集一次性打分。GPU 训练、标注全部样本都不是本质区别。

Q2. 关于「延迟标签」，下列说法正确的是？

单选题 · easy

  • A.延迟标签指网络传输过程卡顿
  • B.延迟标签指标注人员的上班时间
  • C.延迟标签指模型训练时的欠拟合
  • D.延迟标签指真实结果晚于预测到达← 正确答案

答案：D。延迟标签是生产环境的常态：模型先给出预测，真实结果要等业务周期走完才回填，比如推荐转化要等几小时、风控欺诈要等几周。它是在线指标设计必须考虑的核心问题。

Q3. 滑动窗口在线准确率公式中，指示函数 \(\mathbb{I}(\hat{y}_i = y_i)\) 的作用是？

单选题 · mid

  • A.统计窗口内预测正确的样本数← 正确答案
  • B.计算预测结果的概率分布
  • C.对预测标签做归一化处理
  • D.过滤掉未获得标签的样本

答案：A。\(\hat{y}_i = y_i\) 成立时指示函数取 1，否则取 0，求和后就是窗口内命中数，再除以窗口大小得到在线准确率。它不负责归一化，也不负责过滤样本。

Q4. QPS 与 P95 延迟分别描述模型的哪类属性？

单选题 · mid

  • A.模型准确率与召回率
  • B.服务吞吐能力与响应速度← 正确答案
  • C.带宽大小与推理功耗
  • D.训练时长与收敛速度

答案：B。QPS 衡量每秒能服务的请求数，对应「量」；P95 延迟衡量 95% 请求的响应耗时上限，对应「速」。两者都是在线指标中「量质速钱」四维体系的组成部分。

Q5. 下列哪些方法可用于获取或弥补延迟标签？

多选题 · mid

  • A.流式管道实时回填真实标签← 正确答案
  • B.批处理任务在夜间批量回填← 正确答案
  • C.用代理指标暂时近似评估← 正确答案
  • D.删除所有尚未回填的样本

答案：ABC。流式回填和批处理回填是两种主流机制，代理指标可以在标签缺位期兜底评估。删除未回填样本会引入严重偏差，属于错误做法。

Q6. 皮尔逊相关系数接近 1 说明代理指标与真实指标的关系是？

单选题 · mid

  • A.两者完全互不相关
  • B.两者呈高度线性正相关← 正确答案
  • C.两者呈高度负相关
  • D.无法判断任何关系

答案：B。相关系数 \(\rho\) 接近 1 表示代理指标与真实指标同升同降、高度线性正相关，代理越可靠；接近 -1 是负相关，接近 0 则代理失效。

Q7. z-score 告警中，\(z = \frac{x - \mu}{\sigma}\) 的语义是什么？

单选题 · hard

  • A.当前值偏离历史均值多少个标准差← 正确答案
  • B.当前值与最大值之间的比例
  • C.当前值在窗口内的排名名次
  • D.历史均值的衰减变化斜率

答案：A。z-score 用历史均值和标准差把当前读数标准化，把偏离量换算成「几个标准差」。它衡量的是与历史常态的相对偏离，而非绝对比例或排名。

Q8. 以下哪些属于模型漂移的典型在线信号？

多选题 · hard

  • A.在线准确率跌破统计阈值← 正确答案
  • B.预测置信度分布明显偏移← 正确答案
  • C.代理指标与真实指标相关性骤降← 正确答案
  • D.服务器 CPU 使用率偶发升高

答案：ABC。准确率下降、置信度分布偏移、代理相关性骤降都是模型层面的漂移信号；CPU 升高属于工程资源指标，与模型效果漂移无直接关系。

Q9. 为什么在线指标推荐用滑动窗口而不是全量累计均值？

单选题 · easy

  • A.全量累计更消耗数据库空间
  • B.滑动窗口能跟上最新性能变化← 正确答案
  • C.滑动窗口能减少代码的书写量
  • D.全量累计无法计算平均值

答案：B。滑动窗口只统计最近 W 条数据，让旧样本自然滑出，指标能灵敏反映最新性能。全量累计会用远古历史掩盖近期的变化，好比用三年的平均好评掩盖今天的差评潮。

Q10. 设计在线监控告警系统时，为降低误报率应该怎么做？

多选题 · hard

  • A.基于历史数据回放校准阈值← 正确答案
  • B.使用自适应统计方法替代固定阈值← 正确答案
  • C.对不同类型的指标设置差异化阈值← 正确答案
  • D.提高告警灵敏度并发送全员通知

答案：ABC。回放校准、自适应统计、差异化阈值都能减少误报。盲目提高灵敏感并全员通知只会制造告警疲劳，让真正的异常被淹没。