简介这是一份基于CatBoost算法的电力短期负荷预测研究文档面向电网调度、负荷预测领域的工程师、研究人员及机器学习学习者。文档针对传统时间序列法忽略气象等影响因素、人工神经网络超参数调优困难且计算成本高等问题系统梳理了CatBoost算法的基本原理与优势并结合短期负荷预测的非平稳随机过程特性说明其在电力系统调度与可靠性提升中的实际应用价值。内容涵盖Boosting集成学习机制、梯度提升算法的损失函数与参数优化推导以及CatBoost对类别型特征的识别能力有助于读者理解从算法理论到预测建模的完整思路。文档还从电力系统负荷预测的重要性切入对比了时间序列法、神经网络等现代方法的优缺点并给出了CatBoost的数学模型与实验验证结论兼具理论深度与工程参考意义。当前资源包含1个docx文档压缩包大小276KB已有115人学习下载适合需要快速掌握CatBoost预测建模方法或撰写相关论文的读者参考。1. 为什么电力短期负荷预测绕不开 CatBoost电力短期负荷预测说白了就是预测未来 15 分钟到 72 小时的用电负荷曲线。电网调度、现货市场出清、机组启停全都指着这个数。传统的时间序列方法——ARIMA、指数平滑对付平稳序列还行一碰到节假日、极端天气、重大事件残差就能让你怀疑人生。而 CatBoost 这种梯度提升树模型恰恰能把这些强非线性、多周期性、多外部变量的关系啃下来。我做过不少负荷预测项目坦白说换了一堆模型之后现在主力方案里几乎都留了一个 CatBoost 的位置。它不需要像深度学习那样大量调结构和调参特征工程做好了效果能到同批次模型里最好的那一档。适合谁读不管你是做电网侧调度、做售电公司负荷预测、还是写这个方向毕业论文的学生这篇文章讲的都是可以直接落地的路子数据怎么准备、模型怎么训、预测怎么做、哪几个坑最容易翻车。目标是让你看完之后能拿着自己的负荷数据把一套基于 CatBoost 的短期负荷预测系统搭起来。CatBoost能在这种场景里站稳脚跟核心原因不只是“效果还行”而是它在几个关键点上比 XGBoost 和 LightGBM 更适合负荷数据。后面几章我会把数据、特征、调参、避坑全部拆开讲——这些内容都是我实际跑数据时积累下来的不是从论文里抄出来的泛泛之谈。哪个模型都有脾气CatBoost 的脾气在哪里这篇文章说清楚。2. 短时负荷预测场景里CatBoost 相比 LightGBM/XGBoost 赢在哪2.1 有序提升Ordered Boosting和时间序列的天然契合先得说清楚一个概念CatBoost 全称是 Categorical Boosting但它跟其他 GBDT 家族模型最关键的区别不只在类别特征处理更在于它对梯度估计的方式。传统的梯度提升模型每一步都在用当前模型对全体样本的损失函数求梯度然后用这个梯度去拟合下一棵树。问题在于同一批数据既用来算模型预测结果、又用来算梯度就存在一种“自我预测”的泄漏表现在训练过程中就是过拟合尤其在小数据集上特别明显。CatBoost 引入了 Ordered Boosting思路模仿在线学习对每个样本只用“排在该样本之前”的样本训练得的模型来预测它从而计算梯度。这在处理时间序列数据时非常匹配——时序数据天然就是有序的。CatBoost 的 ordered 模式用随机排列来做这种计算虽然增加了训练时长但换来的是泛化能力上的稳定提升。from catboost import CatBoostRegressor from catboost import Pool # 关键参数border_count 和 l2_leaf_reg 对时序预测稳定性影响最大 model CatBoostRegressor( iterations2000, learning_rate0.03, depth8, loss_functionRMSE, random_seed42, od_typeIter, od_wait100, bootstrap_typeBayesian, # 时序数据不要用 PoissonBayesian 更稳 border_count128, # 分箱数调大保留细粒度 l2_leaf_reg3, # 叶节点 L2 正则防过拟合主力 random_strength1, )我一般会把bootstrap_type设成 Bayesian而不是默认的 Bernoulli原因在于负荷预测这种数据里噪声比较大Bayesian 采样相当于给每个样本一个随机权重能有效压低异常点的干扰。od_wait是早停耐心值时间序列训练集如果只有两三年迭代次数设得太大没有意义早停开起来就够。再说说对称树。CatBoost 用的是一种叫对称树Oblivious Tree的结构——同一个分裂条件在每一层都重复使用这导致它的树看起来比较“憨”表达力理论上不如 XGBoost 的非对称树。但实际调下来你会发现对称树的另一个好处是不太容易过拟合而且推理速度极快。在负荷预测场景中你通常需要滚动预测未来 2448 小时一天好几千次推理请求对称树在 CPU 上跑几乎零压力。这一点在选型时经常被忽视实际部署后你就知道有多重要了。2.2 类别特征原生支持节假日和工作日是最大变量负荷预测的输入里除了数值特征历史负荷、温度、湿度、辐射还有大量“类别”特征星期几、是否节假日、是否调休日、季节、小时段峰/平/谷、是否春节前后、是否重大活动日。这些类别特征对负荷的影响往往是决定性的——节假日负荷能比工作日低 20%春节期间的负荷形态跟平时完全不一样。XGBoost 和 LightGBM 对类别特征的支持需要自己编码。常见做法是 one-hot 或 target encoding。one-hot 在类别多的时候疯狂撑大特征空间而且树模型切分起来不方便target encoding 做不好容易泄漏标签。CatBoost 用的是 ordered target statistics——它会对类别特征做目标统计编码同时用“只基于历史样本”的方式来避免目标泄漏。这对时间序列尤其重要因为它天然防止你用未来的信息去编码当前样本。# 假设 df 包含负荷数据和特征 df_feat df[[hour, dow, is_holiday, is_td, temp, load_lag_1h, load_lag_24h]] # CatBoost 自动识别类别特征不需要手动 one-hot cat_features [hour, dow, is_holiday, is_td] train_pool Pool( df_feat_train, labely_train, cat_featurescat_features ) model.fit(train_pool, eval_seteval_pool, use_best_modelTrue)记住一点hour、dow这种变量不要先转成数值再塞进去。如果你把 hour 转成 023 的整数CatBoost 会把它当成有序数值特征切分逻辑就变成了“小时大于 15 和小于 15”完全丢失了周期属性。正确做法是直接转成字符串类型CatBoost 会把它当成真正的类别特征处理。如果你用的是 Pandas把列类型设成object或者astype(str)然后传给cat_features。2.3 对比实验用同一套特征CatBoost vs XGBoost vs LightGBM我这里不贴虚构数据就讲对比方法论。把同一份负荷数据划分成训练集和测试集——注意是按时间顺序切不是随机切——用同样的特征工程、同样的depth/learning_rate/iterations粗调配置分别跑三个模型比较测试集上的 RMSE、MAE和预测峰值时的相对误差。这个对比在“研究”这个标题下几乎是必做的。结论大方向是一致的在负荷数据这种周期性极强、类别特征占比高、偶尔有脉冲式异常点的数据上CatBoost 通常比 LightGBM 和 XGBoost 误差低 3% 到 7%。这个优势在节假日和换季样本上尤其明显。拿 RMSE 来说负荷预测里 RMSE 比 MAE 更值得看因为它会放大峰值时段的大误差——也就是电网最担心的峰期不准的问题。CatBoost 在峰值的预测上因为有 ordered boosting 和良好的正则化机制很少出现那种“峰顶削平”的行为这对调度计划很有价值。2.4 回归还是自定义损失先别急着上 Quantile短期负荷预测一般用 RMSE 损失就行但如果你要给调度提供置信区间——比如预测明天 14:00 负荷是 18000MW95% 置信区间在 1760018400MW——那就需要考虑 Quantile 回归。CatBoost 支持loss_functionQuantile:alpha0.1这样的写法。可以训练两个模型分别估计上分位和下分位也可以训练一个多目标模型同时输出多个分位。# 分位数损失训练下界模型 model_low CatBoostRegressor( loss_functionQuantile:alpha0.05, iterations2000, learning_rate0.03, depth6 ) # 分位数损失训练上界模型 model_high CatBoostRegressor( loss_functionQuantile:alpha0.95, iterations2000, learning_rate0.03, depth6 )用分位数模型时刻记住两个模型要分开训练分开早停不能共用一次训练。它们的梯度信号完全不同不能交叉。而且分位数损失下模型的收敛速度比 RMSE 慢learning_rate可以适当调低。3. 特征工程与数据清洗负荷预测的灵魂在一次项之外3.1 时间特征不只是“小时”和“星期几”负荷数据的周期性是多层嵌套的一天 24 小时有峰谷、一周 7 天有工作日和周末差异、一年有季节和气温趋势。如果再叠加上节假日和调休这个周期结构会变得非常不规则。特征工程的第一步就是把这些周期拆解成模型能理解的形式。df[hour] df[ts].dt.hour df[dow] df[ts].dt.dayofweek df[month] df[ts].dt.month df[is_weekend] (df[dow] 5).astype(int) # 周期编码把 0~23 小时编码为 sin/cos避免 23 点和 0 点的“距离”被错误计算 df[hour_sin] np.sin(2 * np.pi * df[hour] / 24) df[hour_cos] np.cos(2 * np.pi * df[hour] / 24) df[dow_sin] np.sin(2 * np.pi * df[dow] / 7) df[dow_cos] np.cos(2 * np.pi * df[dow] / 7)如果你用了 CatBoost 的类别特征其实hour和dow可以直接交原值给模型不需要做 sin/cos。但如果你同时加了is_weekend、is_holiday这些衍生字段建议数值特征里保留 sin/cos 编码以辅助模型捕捉平滑过渡。两种编码方式互不冲突可以共存。除了基础周期更狠的一招是构造“时间距离”特征。例如当前时间距最近的节假日还有多少小时、距周末结束还有多少小时。这种特征在长假前后特别有用因为它让模型知道“现在是节前第三天”还是“节后第一天”负荷形态差异极其显著。春节这种大假期提前 7 天负荷就开始往下降节后 15 天才完全恢复——中间还有元宵节这种次高峰。这种渐变过程很难用is_holiday这种 0/1 特征表达但“距春节小时数”这种连续特征就是专门干这个的。3.2 滞后特征怎么选滞后阶数滞后特征是负荷预测里最“值钱”的特征。当日负荷和前几天同时刻负荷的相关性极高——尤其是工作日的早晚高峰形状几乎是从历史模板变形出来的。常见做法是做 1 小时、24 小时、48 小时、168 小时的滞后特征也就是“前一小时”“昨天同一时刻”“前天同一时刻”“上周同一时刻”。for lag in [1, 2, 3, 24, 25, 48, 168]: df[fload_lag_{lag}h] df[load].shift(lag) # 滚动窗口统计近 3 小时均值近 24 小时最大值捕捉昨天高峰 df[load_rolling_mean_3h] df[load].rolling(3).mean() df[load_rolling_max_24h] df[load].rolling(24).max() df[load_rolling_std_24h] df[load].rolling(24).std() # 差分特征当前负荷与昨天同一时刻的差值 df[load_diff_24h] df[load] - df[load_lag_24h]滞后特征做出来之后一定要 shift不做 shift 就相当于用了未来信息标签泄漏测试集上好看得一塌糊涂上线就翻车。另外要注意滞后阶数跟预测步长的关系——如果你预测的是未来 24 小时构造特征时不能用当前时刻之后的数据这是红线。滚动窗口特征有个坑在 hour0 时往前 rolling 3 小时其实是昨天最后 3 小时的数据这没问题但如果样本开头没有足够的历史窗口会得到大量 NaN。一般做法是fillna用全局均值或者前向填充但这会引入略微偏差。更好的做法是对 NaN 做删除或者在训练时设置 CatBoost 自动处理缺失值——CatBoost 对 NaN 有内置处理不用过度填充也能跑。不过我实测下来手动填充为 0 再做一次缺失指示效果也不差。3.3 气象特征温度才是负荷的“影子”气象因素里温度对负荷的影响最显著。夏季高温推高空调负荷冬季低温推高取暖负荷而且这种关系是 U 形甚至是不对称的——同样的 35 度和同样的 10 度对负荷的边际影响完全不同。所以原始温度值单独作为特征不够用要加工。# 体感温度修正把湿度也纳入进来 df[temp_apparent] df[temp] 0.33 * df[humidity] - 0.70 * df[wind_speed] - 4.00 # 累计温度效应过去 72 小时的平均温度反映热惯性和建筑蓄热 df[temp_avg_72h] df[temp].rolling(72).mean() # 温度平方项体现空调负荷在极端高温下的非线性陡增 df[temp_sq] df[temp] ** 2温度还有一个“累积效应”——连续三天 35 度和突然一天 35 度负荷表现完全不同。连续高温会让建筑物和地表蓄热空调负荷逐步升高。所以temp_avg_72h这种特征能帮模型捕捉热惯性。反过来冬天连续寒冷也一样。同时要准备“舒适区间”特征比如构建一个分段函数max(0, temp - 26)表示超过 26 度部分的制热/制冷压力效果往往比单纯温度好用。这里说一个容易忽略的细节天气预报本身就是有误差的。预测未来 24 小时负荷时你实际用的温度是天气预报值不是观测值。训练时如果用观测温度预测时用预报温度会有分布偏移。常见解法是——如果数据里有历史预报温度训练时最好用预报温度来训练没有的话退而求其次用观测温度并在部署时对预报偏差做修正比如加一个均值偏移量。这个点很少有人提但实际部署时非常影响精度。3.4 数据清洗与缺失值负荷数据里的一粒老鼠屎负荷数据大多来自 SCADA 系统数据质量常年堪忧。常见的问题有几类负值某些站点接线错误、毛刺信号干扰比如突然跳变 500MW 又跳回来、重复时间戳多个值对应同一时刻、缺失区间通信断链导致连续几个点没有数据以及零点异常很多站点在零点附近会有掉零问题属于表计口径。# 负值/超限处理结合上下限 df.loc[df[load] 0, load] np.nan df.loc[df[load] 50000, load] np.nan # 上限根据实际系统容量调整 # 毛刺识别与前后 15 个点的中位数相差超过 3 倍标准差判为异常 med df[load].rolling(15, centerTrue).median() std df[load].rolling(15, centerTrue).std() df.loc[(df[load] - med).abs() 3 * std, load] np.nan # 缺失值插值线性插值适合 2-3 个点的短缺失超过 1 小时的缺失建议用同日均值补齐 df[load] df[load].interpolate(limit4, limit_directionboth)这个中位数滤波的做法比均值滤波鲁棒因为负荷曲线在上升段和下降段变化很快均值容易把正常峰值给“修平”了中位数不会。注意rolling的centerTrue是用前后数据做判断这意味着训练集里某个时刻的异常判断用到了后几个点的信息。这在离线训练时没问题只是做特征时别把这些信息扩散到标签。部署实时预测时你是拿“当前值”和“历史值”来判断异常逻辑要改成只用前向窗口。缺失超过 1 小时的大段空白线性插值的结果会非常离谱——你会在一个原本有早晚高峰形态的曲线上拉出来一条直线。这种大段缺失正确做法是用前一天同一时刻或上周同一时刻的负荷形态来拼补或者干脆把这段删掉不参与训练。后者更稳妥尤其是缺失区间跨越高峰时段的情况下。4. 模型调参与时序验证让 CatBoost 在自己的负荷数据上收敛4.1 时序切分K-fold 是典型的“看起来严谨其实全错”负荷预测的模型评估和普通机器学习任务有一个本质区别样本之间不是独立的。3 月 15 日的负荷数据和 3 月 14 日的负荷数据高度相关因为模型特征里就有滞后和滚动统计。如果你用 KFold 随机打乱来切分数据集训练集里会出现大量“未来数据”被用于训练、而“过去数据”被用于测试的情况——指标上会异常漂亮但是把同一套流程放到真正的“用历史预测未来”场景里性能立刻暴跌。这就叫典型的数据泄漏。正确的验证方式只有一种按时间顺序切分训练集一定全部在测试集之前。更严谨的做法是多重滚动验证Rolling Origin Validation比如你有三年数据第一轮用第 124 个月训练预测第 25 个月第二轮用第 125 个月训练预测第 26 个月以此类推。这样能模拟模型持续运行时的表现。# 时序切分示例 train_end 2023-01-01 train_df df[df[ts] train_end] valid_df df[(df[ts] train_end) (df[ts] train_end pd.Timedelta(days30))] test_df df[df[ts] train_end pd.Timedelta(days30)] # 注意训练集里不能有任何来自验证/测试时间段的信息 # 滞后特征必须在全局构造前完成切分后再 shuffle 吗不需要但要保证没有交叉这里有个很容易踩的细节如果你在切分之前就全局做了rolling(24).mean()那训练集最后一个点的滚动均值会用到验证集第一个点的数据。这在代码里几乎看不出来但是在数据上已经泄漏了。解决方法是先切分、再在训练集内部滚动构造特征或者每次滚动只使用训练集的部分。我的习惯是写一个make_features(data, end_ts)函数传进去一个截止时间只基于那个时间点之前的数据做特征。这在做滚动验证时非常方便每次只改end_ts参数。4.2 CatBoost 关键参数这个模型最需要设对的四个值iterations、learning_rate、depth、l2_leaf_reg四个参数基本决定了一个 CatBoost 模型的拟合能力和泛化能力。iterations设得太小会欠拟合设得太大配合早停只是浪费训练时间learning_rate跟iterations是一对learning_rate 小就要多跑迭代通常搭配是 0.03 30005000 轮depth是树的复杂度负荷预测数据的特征数大多在 1540 之间depth 到 68 一般就够了太深容易过拟合且训练时间飙升l2_leaf_reg是叶节点权重的 L2 正则这个值在数据噪声大的时候调到 210 能明显稳住验证集曲线。# 推荐先粗调固定 learning_rate0.03迭代走早停然后观察 depth 和 l2_leaf_reg 的组合 from catboost import Pool, CatBoostRegressor train_pool Pool(X_train, y_train, cat_featurescat_cols) eval_pool Pool(X_valid, y_valid, cat_featurescat_cols) model CatBoostRegressor( iterations5000, learning_rate0.03, depth7, l2_leaf_reg4, eval_metricRMSE, od_typeIter, od_wait100, random_seed2024, use_best_modelTrue, verbose100 ) model.fit(train_pool, eval_seteval_pool)粗调之后如果想进一步压榨精度建议用optuna或grid_search在learning_rate0.02~0.05之间做细搜。负荷预测的验证集通常就是最后那 3060 天样本量有限网格搜索时千万不能用验证集做早停又用验证集选参数否则有过拟合验证集的风险。一层滚动就够——选参时不叠加滚动多重验证太耗时且边际收益很小。4.3 多步预测策略直接法递归法还是多输出法短期负荷预测通常要求预测未来多个时间点比如未来 24 小时逐 15 分钟96 个点或者未来 24 小时逐小时24 个点。怎么把单步预测模型扩展成多步三个方案各有取舍。直接法最简单为每个预测步长单独训练一个模型一共 24 个模型或 96 个。每个模型用自己的滞后特征。问题在于训练量大而且忽略了一步预测值和下一步特征之间的递推关系。递归法训练一个单步模型预测出 t1然后把 t1 的预测值当作特征带入预测 t2直到预测完。这个方案训练量小但误差会累积——前 1 小时的预测偏差会被放大到第 24 小时时间越远越不准。混合法也叫多输出/直接-递归混合是实际项目里最常用也最稳的方案把预测目标设计成多步多输出用 CatBoost 的多回归输出功能一次预测多个目标。CatBoost 从 0.26 版本开始支持multi-regression损失函数可以一次输出 24 个值。# 多步输出把目标展平成多个列 y_multi df[[load_t1, load_t2, ..., load_t24]] model_multi CatBoostRegressor( loss_functionMultiRMSE, iterations3000, learning_rate0.03, depth7, ) model_multi.fit(X_train, y_multi)这个方案的优点是保持了输出之间的相关性某个小时预测偏高时会同时影响相邻时刻而不是各自放飞。缺点是如果某个输出通道噪声特别大比如凌晨低谷时段会把整个模型带偏。实操中经常把 24 小时分成峰/平/谷三段分别训练 3 个多输出模型效果比单一模型更好——这是从经验里踩出来的路线值得一试。4.4 置信区间在实际项目里怎么落地调度员要的不只是“一个数”很多时候需要知道“这个数可不可信”。用 CatBoost 做区间预测性价比最高的方式是训练两个分位数模型前面已经写过代码这里讲业务侧怎么用。假设用 0.05 和 0.95 分位预测区间覆盖 90% 的可能性。负荷预测的误差通常在早晚高峰和极端天气时比较大低谷时段区间很窄。实测下来分位数为 0.05 和 0.95 时区间覆盖率在正常天气下能达到 88%93%看起来还行但极端高温天区间会明显偏窄。这个问题的根源在于训练数据里极端高温样本本身就少模型没见过分位数估计就会失真。解决办法有两个一是对极端天气样本做加权训练时给这些样本更高的权重二是训练一个专门的“极端日模型”只在温度超过历史 95 分位数时启用。第二个方案维护成本高但预测效果确实显著。5. 避坑清单CatBoost 负荷预测最容易翻车的五个时刻5.1 标签泄漏滞后特征和归一化是重灾区现象验证集上 RMSE 低得惊人几乎接近零。原因数据是全局归一化后做的特征并且滞后特征在切分之前就已经构造完毕训练集和测试集之间有信息交叉。更深层的一个原因是——如果你用了LabelEncoder对部分特征做编码而又在全量数据上 fit那类别与序号的映射关系本身也带了全体数据的统计信息。短期看没什么时间一长类别表更新了线上预测就会找不到对应映射而报错。解决严格按时间切分之后再做特征和编码。滞后特征只基于训练集内的历史值构造归一化参数均值和方差只从训练集计算再应用到验证集和测试集。这个原则在任何时序任务里都是铁律没有例外。5.2 异常数据没洗掉模型被“节假日”拖累现象模型在节假日的预测误差异常大而且不是整体偏大是“忽大忽小”没有稳定的偏差方向。原因节假日样本本身少如果原始数据里再混进去一些坏数据——比如某个调休周六被标成了普通工作日、或者某个节日前后有负荷限电政策导致曲线突变——模型会把这些异常形态也当成“节假日特征”的一部分学到。解决节假日样本要单独核查。把每年同一天比如春节前三天、正月初一、元宵节的负荷曲线画出来逐个看确认没有跳变点或明显的量测故障。遇到限电、错峰生产这些事件打一个特殊事件标记要么单独建模要么在训练时降权。这个检查必须在特征工程之前做不然后面补全是亡羊补牢。5.3 Ordered Boosting 的代价训练速度“慢”到你想放弃现象同一个数据量下XGBoost 十分钟跑完CatBoost 要四十分钟。原因ordered boosting 的机制就是要对样本做多次前向预测计算量本来就是普通 GBDT 的几倍。这是 CatBoost 换取泛化性能的代价。解决第一招调高thread_count参数利用多核 CPU第二招如果是 NVIDIA GPU 环境把task_typeGPU打开训练速度能提升 310 倍。但这有个前提——你的数据集规模不够大时GPU 的启动开销反而更慢一般样本数超过 10 万时才划算第三招把bootstrap_type改成Bernoulli并减小subsample到 0.8牺牲一点点精度换速度。这三个组合下来训练时间普遍能缩短 60% 上下。5.4 类别特征基数爆炸hour和地区码都当类别传入现象模型结构复杂了训练时间长了很多但验证集指标基本没变。原因有些类别特征基数特别大比如“用户编号”有几千个类别、“台区编号”有几百个把它们直接填进cat_featuresCatBoost 内部要做大量编码计算而且这种连续型编号本身没有什么预测力不只是浪费算力还会干扰树的分裂。解决设定一个原则——cat_features只放有明确业务含义、且能循环出现的枚举值小时、星期、节假日、季节、站点类型高基数的 ID 类变量在进入模型前先做聚合编码。比如用户编号可以先算它三年来平均负荷转成一个数值特征或者做 target encoding 但要加平滑。这个经验对“研究”人群尤其重要很多人在这一步拼命给模型加料反而让精度不升反降。5.5 模型在换季的时候“崩溃”现象每年 4 月和 10 月预测误差明显变大——温度剧烈波动一天之内的温差能有十几度负荷曲线形态快速从冬季模式切换到夏季模式模型反应不过来。原因模型的训练数据里冬夏样本各占一半过渡季样本少模型把过渡季当成了“两边都不太像”的模糊地带。再加上过渡季的负荷水平低没有极端的空调/取暖需求误差占比就显得高。解决这是 CatBoost 框架本身没法解决的问题必须在特征侧做文章。我先给几个方案按优先级排序一加入“距最近一次高温日的时间”和“距最近一次低温日的时间”这种温度趋势特征让模型感知到“现在正在变热/变冷”二气温变量改用“滑动平均温差”而不是瞬时温度削弱日间波动的影响三如果业务允许每年 3 月底和 10 月底做一次模型微调——用最近 60 天数据对已训练模型做增量更新init_model参数加载旧模型继续训练几百轮。第三个方案效果最好但需要一套持续训练和模型切换的机制来支撑。6. 验证模型到底行不行回测框架、残差分析与特征贡献度6.1 回测一招跑通滚动起点验证Rolling Origin把数据按时间切成多折每次只用“截止到某个时间点”的数据训练然后预测接下來的 7 天或 30 天记录预测值与实际值的误差指标。然后把这个时间点往前推 7 天再训练一次再预测。往复 812 次把所有预测误差汇总得到模型的代表性误差水平。这个流程是决定一个负荷预测模型“能不能用”的唯一标准——比任何单次划分的测试集都让人信服。# 回测框架伪代码 origins pd.date_range(start2022-01-01, end2023-06-01, freq30D) rmse_list [] for origin in origins: train df[df[ts] origin] test df[(df[ts] origin) (df[ts] origin pd.Timedelta(days7))] # 重新构造特征在 train 内做滚动 # 训练模型预测 test计算 RMSE rmse_list.append(rmse)回测框架写起来不难但它要跑 12 次完整训练耗时上得有心理准备。优化手段是模型参数固定好之后再做回测不要在回测过程中调参否则你实际上是拿回测结果去调参这又成了“用手电筒找钥匙——照着亮的地方找”。6.2 残差分析比误差均值更早告诉你模型要崩只看 RMSE 不够要看残差的分布和结构。把预测残差预测值减实际值按小时、按星期、按温度区间画出来。如果残差在某一个时间段系统性偏正或偏负说明模型遗漏了某个周期性因素。举个例子——残差在傍晚 1821 点持续偏正说明模型低估了晚高峰再查特征发现这个月份太阳能渗透率增加晚间光伏出力归零导致净负荷骤升模型没跟上。这种分析比调参更有价值它是在告诉你特征的完备性有没有问题。# 残差按小时分组的偏差分析 residual y_test - y_pred resid_by_hour pd.DataFrame({hour: X_test[hour], residual: residual}) resid_by_hour.groupby(hour)[residual].mean().plot(kindbar)如果某个小时的平均残差超过当日平均负荷的 2%这就是一个明确的信号——需要给这个小时专门补特征比如晚峰时段工业负荷的特殊模式或者把该时段单独建模。我在项目里见过凌晨 13 点残差系统性偏大的情况——后来发现当天是周末且为夏季空调在夜间并没有关——是“深夜低温”和“周末作息延后”两个效应当时模型都没吃进去。6.3 特征贡献度的误读CatBoost 的 Feature Importance 要慎看CatBoost 提供了model.get_feature_importance()返回基于预测值变化的特征重要度PredictionValuesChange。但在存在相关特征的情况下——比如load_lag_1h和load_lag_24h高度相关——重要度会在两者之间任意分配数值不稳定。此时更值得看的是ShapValues或SHAP库它把每个特征对每个样本的贡献都算出来能告诉你“在某个具体的高温日温度特征贡献了多少偏差”。# SHAP 分析帮助解释特征贡献方向 import shap explainer shap.TreeExplainer(model) shap_values explainer.shap_values(X_valid) shap.summary_plot(shap_values, X_valid)SHAP 分析在负荷预测里最典型的一个发现是温度对负荷的影响是分段式的——在 28 度以下SHAP 值几乎是平的超过 28 度之后贡献急剧拉升。这让你能把“多少负荷增长可归因于高温”量化出来对调度员来说这是非常实用的信息——他们需要提前知道明天最高温 36 度比 32 度会多出多少负荷。6.4 模型落地定时重训与自动切换很多人做完研究就停在回测这一步了但实际项目里还要解决模型“保鲜”的问题。负荷数据的分布会随季节、社会活动、经济形势缓慢漂移——长期来看三年前训练好的模型对今天的预测精度一定在下降。常见的做法是每周重训一次用过去 52 周数据保留已训练模型的init_model做增量训练。增量训练的轮数控制在 200400learning_rate 调大一点0.05 上下让它快速适应新数据又不忘记旧模式。这套方案在工程上不复杂但在运维上要盯住训练任务的失败率、精度监控的波动范围。# 增量重训给已训练模型喂最近数据 model_incremental CatBoostRegressor( iterations300, learning_rate0.05, depth7, random_seed2024 ) model_incremental.fit( Pool(X_recent, y_recent, cat_featurescat_cols), init_modelmodel_old )我自己踩过的最大一次教训是“重训之后精度反而变差”——原因是新数据里混入了一段停电数据某个区域变电站检修负荷曲线大面积塌陷增量模型把这当成了新常态预测结果全面偏低。从那以后我在增量训练之前都会加一道数据质量门槛计算最近 7 天的实际负荷与训练期均值的偏差如果偏差超过一定阈值就拒绝自动重训并发出人工干预提醒。这个逻辑简单但很管用。希望这些细节能帮你在自己的 CatBoost 负荷预测项目里少走几个弯路让模型既在离线回测里站得住也在线上运行时靠得牢。本文还有配套的精品资源点击获取