蒙眼说做负荷预测的人，大概都遇到过调度员或者售电交易员打电话来问：“明天尖峰负荷到底是多少？给个准话。”早几年我习惯直接报一个数字，然后对面总会补一句“误差多少”。报误差其实就是在问不确定性的范围，而传统的点预测很难回答好这个问题。后来新能源接入比例上来，负荷曲线越来越“皮”，我才发现真正该做的不是把单点误差猜得更准，而是把预测结果整体变成一个概率分布，让下游自己按风险偏好去取数。这就是概率负荷预测。而让这套概率体系能持续跟上真实系统变化的关键，是我最终选定的自适应在线学习路线。
这篇文章不打算做教科书式的推导，而是把我从建模思路、模型选型、在线更新机制、概率校准到实际落地过程中踩过的坑和最终验证过的方案完整捋一遍。适合正在做电力负荷预测的算法工程师、准备把离线预测升级成在线预测的数据团队，以及想了解分位数回归和在线学习怎么结合的研究者。涉及的代码逻辑我会给关键实现，数据和场景脱敏，但方法链路和工程细节是能直接复用的。
1. 概率负荷预测先回答的问题：点预测的不确定性缺口
1.1 点预测给不了调度员的东西
先聊一个很简单的场景：预测明天中午12点的系统负荷，模型给出15000MW。调度员如果只拿到这一个数字，他必须自己去脑补“这个数到底靠不靠谱”。如果实际波动是正负300MW，按15000MW安排机组组合问题不大；如果实际波动是正负1500MW，那这个数字基本没有决策价值，甚至会有误导性。
光伏和风电渗透率上去之后，这个问题被放大了。中午光伏大发时段，净负荷曲线会出现明显的“鸭型”下探，而这个下探深度高度依赖光伏出力预测。光伏预测本身有云层的不确定性，传导到负荷预测上就是系统性偏差。点预测模型再怎么调参，也只能告诉你一个期望值，无法告诉你“有10%的概率会超过多少”或者“有90%的概率落在哪个区间”。而电力市场报价、需求响应、备用容量安排，恰恰需要的是这种风险量化信息。
所以概率负荷预测的核心问题不是“明天是多少”，而是“明天可能落在什么范围内，每个区间的概率多大”。这个表述上的转变，直接影响下游的决策质量。
1.2 概率预测到底输出什么
实际工程里，概率负荷预测通常有三种输出形态，对应不同的下游场景：
第一种是分位数序列。设定一组分位点，比如 0.05、0.1、0.25、0.5、0.75、0.9、0.95，模型对每个预测时点输出7条曲线。这条曲线集几乎能回答所有下游问题：中位数可以直接当点预测用，0.05/0.95分位可以框出90%置信区间，某个分位点对应的负荷值可以直接用于市场报价的阶梯电量拆分。
第二种是预测区间。不输出完整的分位数，只输出上下界和置信水平。常见做法是取 0.05/0.95 或者 0.1/0.9。这种方式对调度侧最友好，一张图上画两条边界线就行。
第三种是完整概率分布。可以通过参数化分布（比如正态分布、t分布）或非参数化分布（核密度估计、分位数拼接）来近似。完整分布的用处是计算任意概率的事件，比如“负荷超过16000MW的概率是多少”，这在极端天气预警和供需平衡风险评估里很有价值。
我最终采用的是第一种形态：输出七个分位数。原因是它实现简单、下游兼容性好，而且分位数之间可以直接计算区间，不需要做分布族假设。
1.3 负荷预测的“不确定性”到底从哪来
在做概率建模之前，得先把不确定性的来源拆清楚。我总结了四类，每一类对概率预测的设计都有直接影响。
第一类是天气预报误差。负荷对温度、湿度、辐照度高度敏感，天气数值预报本身有误差，而且这个误差是随时间变化的。早上8点看明天中午的预报，和当天中午看中午的预报，置信度完全不同。第二类是负荷自身的随机性。用户用电行为总是有随机波动，这部分基本不可预测，只能靠概率区间去吸收。第三类是事件性分布漂移，比如重大节假日、突发极端天气、疫情管控等。这类事件会让负荷模式和训练数据产生系统性偏离，也是点预测最容易翻车的地方。第四类是结构性变化，比如分布式光伏大量接入、电动车普及、新的大型工业用户投产，这类变化会让历史数据的“有效期”变短。
不同的不确定性来源，需要不同的模型机制去应对。天气误差适合用分位数回归去建模尾部，随机波动靠概率输出自然吸收，分布漂移则需要在线学习去快速适应。这也是为什么我把“概率负荷预测”和“自适应在线学习”放在一起，而不是当作两个独立的技术点。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 在线学习为什么比每周重训更适合负荷场景
2.1 老套路：离线模型加定期重训的三大死穴
很多团队做负荷预测的标准流程是：攒上一年两年历史数据，训练一个规模不小的模型，然后每周或每月重训一次，每次全量数据过一遍。这套方案的第一个死穴是漂移响应太慢。每周重训的话，模型看到“这周负荷模式变了”之后，至少要一周才能把参数改过来。碰上连续高温、寒潮、或者一次突发限电，这一周的滞后意味着连续多天预测系统性偏错。
第二个死穴是历史数据窗口到底取多长，永远在纠结。取一年，去年同期的负荷水平和今年可能已经完全不同，那些老样本对当前预测全是噪声。取一个月，碰上季节性转换又不够看。离线训练天然需要一个相对稳定的“训练集”，但电力负荷恰恰是时刻在漂移的时间序列。
第三个死穴是计算资源浪费和热切换风险。每周全量重训一次，GPU和CPU占用都很大，而且模型重训完上线，效果不升反降的情况经常发生。你没法保证上一周的数据分布和这一周一致，也没法保证重训出来的模型一定比现网版本好。
2.2 在线学习的本质：数据到了就学
在线学习的核心思想其实特别朴素：不等数据攒够，来一条就学一条。数学上就是一个增量梯度更新：
code复制θ_new = θ_old - η · ∇L(θ_old, sample)
其中 θ 是模型参数，η 是学习率，∇L 是当前样本的损失梯度。
这个公式看着简单，落地的时候有一堆工程细节。第一个细节是“一条”还是“一个小批量”。电力负荷数据噪声不小，拿单条样本做更新，梯度方差会很大，模型会抖得厉害。我实际用的是最近几个时点的滚动小批量，比如每15分钟来一个断面，用最近两小时的数据（8个样本）拼一个batch，计算平均梯度再更新参数。
第二个细节是学习率怎么调。线上环境和训练环境不一样，没法提前定个最优学习率然后就不管了。我在后面的防震荡设计里会专门讲。第三个细节是模型结构必须支持“一步一更新”。树模型这类不支持梯度回传的模型，做在线更新就不好使，所以基模型的选择得留一手。
2.3 在线学习 vs 滑动窗口重训的实测对比
我在项目里前期专门做过一组对照实验，对比在线学习和滑动窗口重训的行为差异。
滑动窗口重训的做法是：保留最近14天数据，每24小时用这14天数据重训一次模型。在线学习的做法是：保留同样的基础模型结构，但每15分钟用最近两小时小批量做一次参数更新。
从行为上直观对比：滑窗重训对“两天前开始的模式变化”要等到下一次重训时刻（最迟24小时后）才能让参数开始修正。在线学习则不同，只要新数据进来了，模型在下一个15分钟周期就已经开始向新分布靠拢。一个典型例子是气温突然升到35度以上，空调负荷激增。滑窗模型第一天的预测会明显偏低，到第二、三天才追平；在线模型基本在几个更新周期内就修正到位了。
但这不意味着在线学习在所有维度上都优于重训。在线学习的问题是它更容易被极端值带偏，短期噪声可能被当成结构性变化学习进去。所以我得反复强调：在线学习不是拿掉离线训练，而是把两者组合成一个有监督、有回退的体系。这部分在第三章的防震荡设计里会展开说。
3. 模型怎么搭：在线更新机制与防震荡设计
3.1 基模型选型：分位数神经网络配合LightGBM
基模型我最终选了分位数神经网络（QNN），同时保留一版LightGBM作为离线参考和兜底。选择QNN的理由很直接：神经网络天然支持反向传播，每来一个batch都能做参数更新，这和在线学习的诉求完全匹配。LightGBM虽然精度优秀，但增量更新很麻烦，做在线落地需要额外引入类似GBM在线训练的开源框架，工程复杂度高，而且稳定性不好保证。
QNN的结构不复杂。输入层接历史负荷、温度、湿度、辐照度、日历特征、滞后差分等特征，中间两到三个全连接隐层，激活函数用ReLU，输出层神经元数量等于分位数个数。每个输出神经元对应一个分位点，同一个模型同时学习七个分位数。
我在结构上做了一个关键改动：不直接让七个输出头各自独立预测，而是让中间层共享特征提取，每个分位数只在最后几层分开。这样做的原因是共享层可以让模型用一份特征表达拟合所有分位数，既减小参数总量，也降低分位数之间的交叉风险。
3.2 在线更新全流程
在线更新的完整链路是这样的：
- 数据采集。15分钟一个断面，获取最新负荷值和外部特征数据。
- 数据预处理。在线做归一化，窗口统计量实时更新，缺失值用上一周期填充。
- 构建增量batch。取最近两小时（8个时间点）的数据作为更新样本。
- 计算梯度并更新参数。损失函数用分位数对数损失（即pinball loss），优化器用Adam。
- 记录模型版本快照。每个更新周期生成带时间戳的模型状态，供回滚用。
核心更新代码的逻辑大致是这样：
python复制# 简化示意：在线更新一个step
def online_update(model, batch_x, batch_y, lr=1e-3):
model.train()
optimizer = torch.optim.Adam(model.parameters(), lr=lr)
pred = model(batch_x) # 同时输出多个分位数
loss = pinball_loss(pred, batch_y, taus) # 分位数损失
optimizer.zero_grad()
loss.backward()
optimizer.step()
return loss.item()
我特别强调batch的选择。用单条数据更新，一旦这个断面出现异常，模型会被狠狠拽一下；用最近两小时的小批量，既保留了响应速度，又让梯度的方差小很多。实际调试下来，两小时是一个比较稳的窗口。窗口太短（比如就一个点）模型太敏感，太长（比如半天以上）则在线学习的及时性优势就打折扣了。
3.3 防震荡：EWMA平滑、学习率衰减、异常过滤
在线模型最容易被人诟病的就是“抖”。为了让它在真实负荷曲线上能稳定输出，我加了三层防护。
第一层防护是目标值平滑。负荷真实值本身有随机噪声，直接拿这个值当监督信号，模型很容易学习到噪声。我在监督目标上加了EWMA（指数加权移动平均）：
code复制y_smooth(t) = α · y(t) + (1 - α) · y_smooth(t-1)
α取0.1到0.3之间。这个式子让模型不要对每一个瞬时值都做出剧烈的参数反应，而是跟着一个平滑后的趋势走。代价是响应速度损失一点，但换来的是稳定性的显著提升，这个取舍非常值得。
第二层防护是学习率自适应调度。在线场景里，固定的学习率并不理想。分布平稳的时候希望学习率小，避免过度调整；分布发生漂移的时候希望学习率大一点，能快速跟上。我用的策略是：每5个更新周期评估一次损失的变化趋势，如果最近一段时间的损失持续偏高，说明可能存在分布漂移，把学习率临时调大；如果损失稳定，就慢慢衰减。这个逻辑和AdaGrad、Adam的自动调整部分相似，只不过我加了一个基于漂移信号的外部控制，让模型对突发情况反应更积极。
第三层防护是异常样本过滤。在线更新的生命周期里，污染数据是不可避免的——计量终端跳变、通信错误、人为置数等。如果模型把脏数据当真，一次更新就可能让预测值偏出十万八千里。我的方案是在更新前做一个残差判断：计算当前样本点的预测残差，如果残差超过近期残差分布的4倍标准差，就认为这是异常样本，跳过本次更新。这个判断不需要额外标签，纯在线就能算出来。
3.4 漂移检测与模型回退
在线学习的“自适应”不能是无条件跟随，必须有一套监控和回退机制兜底。我在模型层面和预测输出层面各设了一道监控。
模型层面监测特征的分布漂移。我每隔一段时间计算当前输入特征分布和历史训练集特征分布的PSI（群体稳定性指标），PSI超过0.25就认为特征分布发生显著漂移。这个信号会触发两个动作：一是临时调大学习率让模型加速适应，二是做一次强制回退评估——如果在线模型最近24小时的预测误差明显差于离线稳定版本，就自动把线上产出切回离线模型，同时保留在线模型持续更新，等在线模型的质量重新反超后再切回来。
输出层面监测预测区间的覆盖率。我按日统计90%预测区间实际覆盖真实值的比例，如果连续3天覆盖率低于85%，触发告警。这个指标的优点是不需要真实标签之外的任何信息，直接看区间准不准就行。
这套“监控-告警-回退”体系是在线学习能长期稳定运行的定心丸。它本质上是承认一个事实：在线模型不是永远正确，但系统要有能力尽早发现它错了，并优雅地回退到安全状态。
4. 概率输出的核心：Pinball Loss、CRPS与覆盖率校准
4.1 分位数回归的基本逻辑
概率负荷预测的输出要“可信”，关键在训练时用对的损失函数。分位数回归的核心是pinball loss（也叫分位数损失），它的数学定义是：
code复制ρ_τ(u) = u · (τ - 1{u < 0})
翻译成人话就是：当预测值低于真实值（欠预测）时，损失是 τ 乘以误差；当预测值高于真实值（过预测）时，损失是 (1 - τ) 乘以误差。这样不对称的加权，逼着模型在不同的分位点上做出不同的预测。
以 0.9 分位数为例，如果真实值经常超过预测值（欠预测），损失会很大，模型会被持续往上推；如果真实值经常低于预测值（过预测），惩罚相对小一些。最终模型学出来的 0.9 分位点，会保证真实值不超过它的概率接近90%。
实际代码里pinball loss可以这样写：
python复制def pinball_loss(pred, true, tau):
# pred: (batch, n_quantiles), true: (batch, 1), tau: (n_quantiles,)
diff = true - pred
loss = torch.maximum(tau * diff, (tau - 1) * diff)
return loss.mean()
这个写法是一个简洁而准确的形式。值得注意的是，如果只是单独训练一个 0.5 分位数，它等价于MAE回归，模型学到的是条件中位数；若要得到期望值，还是需要用MSE或者pinball loss中 τ=0.5 的分位数，实践中常用中位数当点预测的鲁棒版本。
4.2 多分位数建模与分位数交叉处理
同时输出多个分位数时，最经典的问题就是“分位数交叉”。比如模型某一天预测的 0.05 分位数是14800MW，而 0.5 分位数反而只有14600MW，这在逻辑上是荒谬的——概率更大的点不可能比概率极小的点还低。
交叉问题出现的原因在于各分位数输出头虽然是同一模型，但训练时各自独立优化，没有保证单调性的约束。我试过几种处理方案：
第一种是预测完做后处理排序。把七个分位数按大小重新排一遍，保证单调递增。这个方案最简单，但会破坏各分位数的统计一致性，不推荐作为主方案。
第二种是改变输出结构。我实际采用的是：模型先预测 0.5 分位数（基准），再预测 0.5 分位数到其他各分位数的偏移量，并且对偏移量做 softplus 激活，保证非负。这样天然不会交叉，而且训练也更稳定。具体做法是输出层最后一个维度拆成两部分：第一部分一个神经元输出基准中位数，第二部分 K-1 个神经元输出正偏移量。
第三种是加交叉惩罚项。在pinball loss基础上，如果某对相邻分位数出现逆转，就额外加一个惩罚。这个方法也能压制交叉，但超参数比较敏感，我用了之后发现还不如改输出结构来得干净。
4.3 CRPS：同时衡量校准度和锐度
训练时用pinball loss没问题，但评估概率预测时，pinball loss逐分位来看有个盲点：它不关心各分位数之间的整体一致性。比如一个模型的0.1和0.9分位都校准得很好，但0.5分位偏离严重，逐分位的pinball损失可能显示差不多，可是整个概率预测的质量并不好。
所以在线评估和离线对比时，我主要看CRPS（连续排名概率评分）。CRPS衡量的是预测的累积分布函数和真实值经验分布之间的距离，同时考虑了校准度（calibration）和锐度（sharpness）。一个理想的概率预测，应该是区间窄且真实值落在区间内的频率符合标称概率，CRPS能同时这两点。
CRPS的近似计算可以用分位数输出：
python复制def crps_from_quantiles(q_true, quantiles, taus):
# 用梯形法近似 CRPS，量纲和 MAE 一致
grid = np.sort(np.concatenate([quantiles, [q_true]]))
widths = np.diff(grid)
heights = np.abs(np.interp(grid[:-1], quantiles, taus) - (grid[:-1] < q_true))
return np.sum(widths * heights)
这个计算方式的好处是只依赖模型输出的分位数集合，不需要额外的密度估计。在横向对比不同模型的时候，CRPS相比单独看MAPE和覆盖率更全面。
4.4 覆盖率校准：区间“达标”不代表有效
概率预测界有个经典玩笑：如果模型输出一个0到正无穷的区间，那覆盖率的指标一定完美，但一点用都没有。这个玩笑点出了只关注覆盖率（PICP）的陷阱。
覆盖率指标衡量的是“真实值落在预测区间内的比例”，区间只要够宽，覆盖率必然高。但太宽的区间对调度员没有意义，因为做决策时“什么都有可能”等于没给信息。因此必须同时看区间宽度（PINAW），或者直接看CRPS这样的综合指标。
我在系统里同时监控两个数：90%预测区间的覆盖率和平均区间宽度。理想状态是覆盖率接近90%，同时区间宽度尽量窄。如果覆盖率达标但区间宽度在持续变大，说明模型正在用“变宽”而不是“变准”来满足指标，要立刻排查原因。如果覆盖率持续偏低，就要检查是不是出现了未建模的新负荷模式，或者在线模型近期被异常样本带偏了。
5. 评估方案与实测：在线模型的收益到底在哪
5.1 实验数据与切分
为了让结论能服人，我把评估方案设计得尽可能严谨。实验用的是某区域电网14个月的历史负荷数据，15分钟粒度，每日96个断面。特征包括：历史负荷序列、温度、湿度、辐照度、日历特征（星期几、是否节假日、是否为工作日）、以及滞后一小时、滞后一天、滞后一周的差分特征。
切分方式采用时间序列滚动验证，这一点非常关键。很多团队在评估预测模型时习惯随机抽样切分训练集测试集，这个做法对时序预测是完全错误的——负荷数据高度自相关，随机切分等于在测试集里混入了训练集的信息，线上效果会被高估。正确的做法是前8个月作为初始训练，后6个月作为在线评估期，并且评估期间模拟真实的在线流程：模型每15分钟更新一次，每天滚动预测未来24小时。
5.2 评估指标组合
评估指标我用了四个，每个都有明确含义：
| 指标 | 含义 | 期望方向 |
|---|---|---|
| MAPE | 点预测（取0.5分位）的平均绝对百分比误差 | 越低越好 |
| PICP@90% | 真实值落在90%预测区间内的比例 | 越接近90%越好 |
| PINAW | 90%预测区间平均宽度占实际峰值的比例 | 越低越好（同时PICP要达标） |
| CRPS | 综合校准度和锐度的概率预测评分 | 越低越好 |
单独看任何一个指标都有误导性。MAPE只反映点预测质量；PICP只反映区间覆盖频率；PINAW只看区间宽窄；CRPS是一个综合性的裁判。我建议团队至少同时使用CRPS+PICP+PINAW三件套。
5.3 在线与离线的实测对比
为了公平对比，我跑了两组模型：一组是纯离线模型（LightGBM，每天重训一次，保持最优参数）；一组是本文描述的在线模型（QNN + 在线更新）。两组模型使用相同的特征工程和分位数设置。
节选6个月评估期的平均结果如下：
| 模型 | MAPE | PICP@90% | PINAW | CRPS |
|---|---|---|---|---|
| 离线LightGBM（每日重训） | 3.2% | 86.1% | 0.42 | 0.18 |
| 在线QNN（15分钟更新） | 2.7% | 92.8% | 0.38 | 0.15 |
这组数字说明几件事。第一，在线模型的点预测MAPE有所改善，但幅度不算夸张，大概0.5个百分点的提升；真正拉开差距的是概率输出的质量：PICP从86.1%提升到92.8%，离90%的标称覆盖率更近了，说明预测区间更“诚实”。PINAW从0.42降到0.38，意味着达到更高覆盖率的同时区间反而更窄了，这说明模型学到的是更精准的不确定性分布，而不是简单地把区间拉宽来“作弊”。CRPS的下降印证了整体概率质量的提升。
如果你是冲着“在线学习能大幅提高点预测精度”去的，可能会失望；但如果你关心的是风险量化质量，在线学习的收益是非常显著的。
5.4 极端场景实测
在6个月的评估期里，我专门挑了三个极端场景来分析在线模型的行为。
连续高温场景：评估期出现了一周持续38度以上的极端高温，空调负荷陡增。离线模型由于训练数据里类似事件很少，尖峰预测系统性偏低，最大偏低幅度达到6%。在线模型在高温开始后的头两天同样偏低，但到了第三天就修正到位，最大偏低幅度控制在3%以内。这是因为在线模型每天48次更新，能在高温信号持续积累后快速调整温度敏感性权重。
突发寒潮场景：一次强冷空气让负荷两天内拉升15%。这个场景里两条路线都出现滞后，因为寒潮带的风速和云量变化是突发性的，特征变化本身就超出了模型经验范围。在线模型在有EWMA平滑的情况下，收敛速度快于离线模型，但不如高温场景那么显著。这说明在线学习对“渐进式变化”的适应能力很强，对“突发式变化”虽然有帮助但做不到预知。
节假日场景：春节前后负荷基线大幅下移。离线模型如果带好了节假日特征，效果尚可；在线模型在这个场景里的表现主要取决于有没有把节假日特征送到输入里。如果只看连续负荷数据而没有日历信号，在线模型会把春节的负荷下降误认为一种持续性趋势，节后恢复时又需要一段时间才能回正。所以特征工程在在线模型里同样重要，不能因为模型能持续更新就忽视外生变量。
6. 落地六个月踩过的坑与补救策略
6.1 数据延迟导致特征错位
系统上线第一个月，我就被一个隐蔽的问题坑了。现场采集的负荷数据并不是准点到达的，部分计量终端有数分钟到数十分钟的延迟。在线更新的流程里，如果直接把收到的数据当作“最新时刻”的数据，训练样本的标签时间、特征时间和真实时间就会错位。在15分钟粒度的系统里，半小时的错位意味着模型学到的一组时序关系是乱的，预测精度会明显下降。
解决办法是给每个样本打上“水位线”时间戳。每条训练数据只有在“该时刻之后的特征全部到达”时才允许进入训练流。我简单解释一下：如果当前系统时间是14:30，那么14:15的样本大概率已经齐了，可以直接用；但14:25的样本可能还缺14:25的遥测值，就暂时不进训练队列。这个机制避免用“未来信息”去训练，也不需要依赖复杂的乱序数据管理。
6.2 在线模型被坏数据带崩
有一次模型预测值突然跳出一个离谱的尖峰，排查了半天，发现是一个站点的计量终端连续三天跳数，往上报了一个比真实负荷高出一大截的值。离线模型对这种单点噪声不敏感，因为训练时是批量数据，平均一下就稀释了；在线模型则不行，它每次学习都会实时更新参数，一个坏值足以让模型在后续好几个周期里都带着错误的记忆。
我在前面提到的“异常样本过滤”机制就是这次事故的产物。残差阈值不能设太死，否则会漏掉真正的分布漂移信号；我最终的方案是用一个滚动窗口动态计算残差的均值和标准差，超过4σ才判为异常，这样既能在大多数情况下保住有效更新，又能在极端情况下防止模型被带崩。同时，我在数据接入端加了数据质量标签，对遥信跳变、越限值和重复值做了实时标记，训练流会直接跳过带质量标签的样本。
6.3 分位数交叉问题
分位数交叉这个问题，我最初以为改了输出结构就不会再遇到，后来发现还是会在个别极端时刻冒出来。原因是即使输出结构保证了正向偏移，模型在训练不充分时仍可能让某个分位数的输出在数值上比较接近另一个分位数，虽然不违反单调性，但会出现两个分位几乎重合，区间宽度趋近于零的情况。这在概率上虽然没有“交叉”那么荒谬，但同样说明模型在该时点的不确定性被严重低估。
我的处理方案是双保险：训练层面用带有相对偏移约束的输出结构，预测层面在上报前做一个后处理，检测相邻分位数之差是否小于某个最小阈值（比如峰值负荷的0.5%），如果小于则强制拉开。这样既保证了上报区间的合理性，也不影响训练过程的收敛。
6.4 监控体系是最后一道防线
在线系统的监控，某种意义上比模型本身更重要。我上线后的第二个月就把周报改成了日报，每日自动生成一份模型健康报告，核心指标包括：当日MAPE、PICP@90%、平均区间宽度、CRPS、模型更新梯度的L2范数、特征漂移PSI。梯度范数这个指标是我后来加的——如果某天梯度范数异常大，说明模型参数发生了剧烈变动，大概率是有数据问题或分布突变，需要人工介入。
告警阈值我设置了三级：黄色告警对应PICP连续两天低于85%，橙色告警对应CRPS连续三天比离线基线差10%以上，红色告警对应在线模型预测值出现明显不合理跳变或PICP跌破70%，此时自动触发回退机制，把线上预测源切换回离线稳定版本。这套监控体系上线后，团队对在线模型的信心大幅提升，因为系统自己知道什么时候该“认怂”。
6.5 几条给后来者的建议
结合这半年的落地经历，我总结了四条最值得分享的经验。
第一，在线学习不是银弹。它最有价值的地方是适应分布漂移，但前提是漂移是有迹可循的渐进过程。纯突发式的极端事件，在线学习能做的只是更快恢复，而不是提前预知。系统设计时要把“恢复速度”当成一个明确的优化目标。
第二，概率预测的评估指标要先于模型建立。没有CRPS和覆盖率监控，就没法区分“模型好”和“模型运气好”。先把评估口径定了，再开始调模型，否则很容易在错误的指标上把模型调得越来越偏。
第三，所有热切换都要有回退能力。模型是从A切到B，还是从在线切回离线，必须有自动化回退机制。在线学习天然是“永远在更新”的模式，这既是优势也是风险，没有回退就没有安全边际。
第四，在线模型的成本低估是普遍现象。在线更新、监控、告警、数据质量保障、版本管理，这些工程链路的投入远超模型本身的算法开发。如果你的团队只准备加一个更新代码，没有配套的监控和回退机制，那不如继续用离线方案，至少不会在半夜被一个异常值折腾醒。
最后再分享一个我反复踩过之后才明白的道理：在线模型更新得再快，也快不过数据质量的破坏速度。把数据水位线、质量标签、异常过滤这些“脏活”做扎实，在线概率负荷预测才能真正从实验环境走进生产环境。