最近把公司园区能源管理平台上的负荷预测模块重新做了一版底层用的是开源能源管理系统 MyEMS预测模型用的是 LSTM 神经网络。最终在 2023 年全年留出的测试集上MAPE 做到 4.7%换算成大家常说的“准确率”大概在 95% 上下。要说明的是95% 不是每条曲线每个时刻都能达到而是整体评估能稳定复现的水平。这篇文章把从数据准备、模型选型到在 MyEMS 里落地的完整过程写清楚重点补上那些文档里不会写的细节。如果你正在负责能源管理、能耗监测这类系统或者想在企业项目里用深度学习做时序预测这篇文章应该能帮你省掉不少弯路。项目最大的价值不在于 LSTM 本身而在于把 AI 能力真正嵌进一套生产可用的能源系统里让预测结果直接服务于需量管理、购电计划和设备预警。下面按我实际推进的顺序来讲。1. 项目背景为什么要在 MyEMS 里做负荷预测1.1 负荷预测解决的是真实账单问题先说电费结构。国内一般工商业用户执行的是两部制电价除了电量电费还有按变压器容量或者最大需量计收的基本电费。容量费是固定的每月多少就是多少需量费则按当月最大 15 分钟平均负荷来收峰值越高这笔钱就越高。负荷预测最直接的价值就在这里如果能提前 24 小时知道明天的负荷峰值出现在几点就可以安排储能放电、调整生产计划、让大型设备错峰运行把峰值压下来。另一个刚需场景是购电计划。随着电力市场化交易推进越来越多的园区需要提前申报次日用电量。申报不准偏差考核直接反映在成本上。传统做法靠老师傅经验估误差经常在 10% 以上。而一个训练良好的负荷预测模型日电量预测误差可以控制在 5% 以内这个差距对月度电费的影响是实打实的。还有设备预警的价值。当预测值与实际上升趋势出现持续明显偏差时往往意味着有异常设备在偷偷耗电或者某个回路出现了泄漏。把预测模块作为基线再接一套偏差报警能源管理人员能节省大量人工排查时间。这个需求不一定写在最初的立项文档里但落地之后大家都很喜欢用。1.2 MyEMS 在整个方案里的角色MyEMS 是一套开源能源管理系统核心能力包括数据采集Modbus、BACnet、OPC UA 等协议、能耗分项计量、计费、报表和运维管理。部署上支持 Docker 一键起数据库主要用 MySQL前端是 Vue Element UI。我们选择在 MyEMS 之上做预测模块而不是重新搭一套数据平台原因很简单数据采集中间件、点位管理、历史库存储这套基础设施自己从头写至少得两三个月而且稳定性不一定比得上成熟方案。MyEMS 已经把从电表采集到历史数据落库这条链路做好了预测服务要做的只是从数据库里取数、训练、再把结果写回去。整个预测模块是一个独立的 Python 进程不侵入 MyEMS 核心代码升级主程序也不会影响。部署层面MyEMS 官方提供了 docker-compose数据库默认会建出主库、历史库和计费库等。点位和设备信息在配置界面维护历史数据按年份分库。预测服务挂在同一台服务器或者内网另外一台机器上都行只要网络能访问 MySQL。这样改造的侵入性最小也是我这次能快速把预测模块跑起来的关键前提。2. 模型选型为什么是 LSTM 而不是 ARIMA 或 Transformer2.1 负荷数据本质上是多周期叠加的非平稳序列做过负荷预测的人都清楚电力负荷曲线有几个非常明显的特征按天有峰谷按周有工作日和周末的差别按季节有冬夏两个高峰。同时它还受温度、湿度影响夏季空调负荷和温度几乎强相关而且存在滞后效应——今天三十七八度的高温电网负荷往往到傍晚才到达顶点。这种数据用线性模型处理会比较吃力。ARIMA 这类方法在处理平稳时序时表现不错但负荷序列的周期性和天气耦合让它难以达到高精度。机器学习树模型比如 XGBoost能处理特征交互但它们是“用历史特征跳到未来”对长序列的时序依赖建模能力有限。LSTM 这类循环神经网络天然适合捕捉时间步之间的依赖关系尤其是小时级数据里“过去了 24 个小时周期又回来了”这种规律。LSTM 全称 Long Short-Term Memory是在普通循环神经网络基础上加了门控机制由 Hochreiter 和 Schmidhuber 在 1997 年提出。它的遗忘门、输入门和输出门决定了哪些历史信息要保留、哪些要丢弃这恰恰是负荷预测最需要的能力既能记住一个月前的同一天是工作日还是节假日又能及时忘掉上周那几天的临时检修带来的异常波形。2.2 与常见方案的实测对比我把几种方案都跑过一轮使用同一份数据、同样的训练测试集划分结果可以作为参考。表里的 MAPE 是平均绝对百分比误差数值越低越好。模型MAPE是否需要复杂特征工程训练时间备注ARIMA11.2%是秒级对节假日无能为力XGBoost6.8%是分钟级需要大量滞后特征两层 LSTM4.7%一般20 分钟左右可自动捕捉序列依赖Transformer5.6%一般40 分钟以上数据规模小时反而过拟合XGBoost 其实已经很能打了如果数据量有限用它做基线再合适不过。但 LSTM 的优势是在不太依赖人工设计几百个滞后特征的情况下就能把周期性和外部特征融合起来最终把误差再往下压 2 个百分点左右。Transformer 理论能力更强但我这套园区数据只有 3 台变压器、两年左右的逐时记录样本量不足一万八千点Transformer 在这种规模下学不到足够的注意力模式效果反而不如 LSTM 稳定。2.3 对一个单园区项目来说“简单”就是优势这里想多说一句选型不要追潮流。图神经网络在一些区域级电网调度里很流行因为它能建模母线、变电站、用户之间的拓扑关系但在一个园区项目里你需要预测的负荷点可能只有几个到几十个彼此之间的物理耦合关系并不强硬建图结构只会增加复杂度收益很小。LSTM 在这个规模下还有一个现实优势生态成熟。PyTorch 里几十行就能搭起来训练用 CPU 也能跑推理单条毫秒级。部署不需要 GPU服务器上装一个 PyTorch CPU 版本就够了这对很多企业 IT 环境来说是巨大的友好性。我最初也考虑过更复杂的 Sequence-to-Sequence 架构后来一评估单步预测加滚动的方式已经能满足业务需求就先按最简方案落地后面再迭代。3. 数据准备准确率的分水岭3.1 从 MyEMS 历史库取数的正确姿势在 MyEMS 里每个计量点位以 meter 或 point 的形式管理点位有唯一的 uuid。历史数据存在历史库中按年分库表里以 uuid 和时间戳记录瞬时值。我们的园区电表是 15 分钟采集频率但预测是按小时做的所以要先把 15 分钟原始值聚合成小时均值或小时末尾值。这里有个细节聚合时最好做“对齐”比如取每个整点前 15 分钟的均值或者取整点时刻的值整条训练链路的取值口径必须一致否则模型会学到奇怪的噪声。取数可以直接写 SQLMyEMS 数据库本身是 MySQL。基础查询逻辑类似这样SELECT meter_uuid, record_time, value FROM myems_history_db.record_2023 WHERE meter_uuid your-meter-uuid AND record_time 2023-01-01 00:00:00 AND record_time 2024-01-01 00:00:00 ORDER BY record_time;实际部署时我推荐用 SQLAlchemy 在 Python 里读写起来干净也方便后续接定时任务。要注意时区问题MyEMS 的部署环境如果用的 UTC而业务上关心北京时间就得在取数和聚合时统一换算否则早晨的峰谷会偏移一小时模型的日周期特征会被破坏。3.2 缺失值、异常值和节假日老生常谈但决定成败数据质量是预测精度的最大变量。数据不好再强的模型也白搭这个说法放到负荷预测里一点不夸张。我在处理这批数据时遇到过三种典型情况第一是缺失。采集链路偶尔断线扇区不完整电力载波丢包都会导致某几个小时没有记录。对单点缺失线性插值就能应付如果连续缺失超过 6 个小时不建议直接插值最好把这一段从训练样本里剔除否则模型会试图去拟合一段根本不存在的数据等于人为制造噪声。第二是异常尖峰。比如某个时刻抄表值突然跳到三倍电表量程这通常是数据采集器瞬时错误而不是真实负荷。我用的是滚动中位数检测窗口取 24 小时如果当前值比中位数高出一倍以上或者低于中位数的一半就标记为异常然后用前后最近的有效值插值替换。这个方法不复杂效果很稳。第三是节假日。这个特征值得单独拿出来说。如果模型不知道明天是国庆节它会把节假日当成普通工作日来预测误差直接飙到 20% 以上。我维护了一张中国法定节假日表包括调休安排在特征里加一个 is_holiday 标记。光这一个特征就能让节假日样本的 MAPE 从 12% 降到 6% 左右性价比极高。3.3 特征工程外部特征的取舍负荷预测的特征分两块序列特征和外部特征。序列特征就是历史负荷本身外部特征包括时间编码、节假日、天气等。LSTM 的输入是一个序列但额外特征也需要拼进去。我这里最终采用的特征组合是历史 168 小时的负荷序列lookback 窗口 7 天、当前小时编号和星期编号的 sin/cos 编码、is_holiday 标记、当天最高温和最低温、当前时刻温度以及过去三小时的平均温度。关于温度要说一句空调负荷对温度响应不是瞬时的房间和大楼的蓄热效应会让负荷变化滞后于气温变化好几个小时所以把过去几小时的平均温度作为特征加进去比只用当前温度效果好很多。这个细节也是我在验证集上反复对比后确认的。特征不是越多越好。一开始我加了很多无关维度比如风速、湿度结果对 MAPE 几乎没有影响训练时间还变长了。考虑到气象数据也是从第三方接口拉的稳定性不可控我最后只保留了温度相关项把服务对气象接口的依赖降到最低。这也是做企业项目时的一个重要原则外部依赖越少系统越可靠。3.4 样本构造与时间切片划分预测任务的定义是给定过去 168 小时的负荷和当前的外部条件预测下一个小时的负荷。我用滑动窗口构造训练样本。数据是时间连续的但窗口可以重叠每个窗口生成一条样本。这样 7000 多个小时的数据能生成上万个训练样本对 LSTM 来说够用了。划分数据时有一个特别容易踩的坑时序数据不能随机切分。很多人习惯用 sklearn 的 train_test_split 随机打乱这在普通分类任务里没问题但在时序任务里会把未来的信息泄露到训练集中。比如用 6 月的数据去训练、让模型去预测 4 月的样本这显然不合理。我直接用时间索引切分前 70% 做训练中间 15% 做验证最后 15% 最近三个月做测试。这样测试集上的指标才真实反映上线后的表现。4. 模型构建与训练LSTM 网络细节4.1 网络结构与关键参数网络结构保持简单输入层接入 168 步的序列特征和外部特征经过两层 LSTM 层每层 64 个隐藏单元层间加 dropout0.2 防止过拟合最后接一个全连接层输出下一小时的负荷预测值。这个结构在大多数小时级负荷数据集上都够用再增加层数或者单元数并不会明显提升精度反而容易过拟合。用 PyTorch 实现核心代码大概这样import torch import torch.nn as nn class LSTMForecaster(nn.Module): def __init__(self, input_size, hidden_size64, num_layers2, dropout0.2): super().__init__() self.lstm nn.LSTM( input_sizeinput_size, hidden_sizehidden_size, num_layersnum_layers, batch_firstTrue, dropoutdropout, ) self.fc nn.Linear(hidden_size, 1) def forward(self, x): out, _ self.lstm(x) out out[:, -1, :] # 取最后一步的输出 return self.fc(out).squeeze(-1)这里 input_size 是每个时间步的特征维度我的是 8 维1 维负荷 2 维时间编码 1 维节假日 4 维温度相关。之所以把负荷和外部特征都放进序列里是因为 LSTM 在每个时间步都能看到外部条件模型可以自己去学时间编码和负荷之间的交互关系比在 LSTM 输出后再拼接特征更自然。4.2 训练流程归一化、优化器和早停训练细节对结果影响很大。首先是归一化负荷值和温度值不在一个量纲必须做缩放。我用的 MinMaxScaler把所有特征都缩放到 [0,1] 区间。这里有个铁律scaler 只能在训练集上 fit然后同时 transform 训练集、验证集和测试集。如果先对全部数据做归一化再切分测试集的信息就泄露到训练里了测试指标会虚高上线后立刻现原形。优化器用 Adam初始学习率 0.001损失函数用均方误差 MSE。训练最多 200 个 epoch但配合两个回调验证集 loss 连续 20 个 epoch 不下降就提前停止学习率在验证集 loss 连续 7 个 epoch 不下降时降低 50%。这两个机制能让训练过程更稳定也避免我在调参上花费太多精力。每次 epoch 结束后我会在验证集上计算一次 MAPE训练日志里直接打印。实际跑下来前 30 个 epoch 验证 MAPE 从 8% 快速降到 5% 左右后面几十个 epoch 在 4.7% 和 5.2% 之间慢慢波动最终早停在某个相对低点。整个训练过程在纯 CPU 环境下大约 20 分钟时间完全可以接受。4.3 评估指标与结果解读评估指标我用了三个MAPE、RMSE 和 R2。MAPE 是业务上最好解释的指标计算方式是所有预测误差绝对值的平均百分比。测试集最终 MAPE 为 4.7%对应的通俗说法就是“准确率 95.3%”。RMSE 大约是园区平均负荷的 8% 左右说明个别高峰时段的误差会比平均大一些。R2 接近 0.96说明模型解释了绝大部分负荷方差。这组数字单独看可能不够直观。我拿同一个测试集跑了 ARIMA 做基准MAPE 是 11.2%XGBoost 经过充分调参后是 6.8%。也就是说LSTM 相比传统时序方法减少了超过一半的预测误差相比优秀的树模型也降低了约 30% 的误差。这个提升幅度在能源管理场景里是有经济意义的日电量预测上5% 以内的误差已经进入可以辅助购电申报的区间了。还要说清楚一点模型支持的是未来 24 小时逐时滚动预测不是一次预测整个月。滚动多步预测时每往后推一步前面的预测值会被当作输入回填到窗口里误差会随步数累积。实测未来 24 小时的 MAPE 在 5% 到 7% 之间到第 48 小时会涨到 8% 以上。所以上线时我明确只承诺未来 24 小时的预测精度再长的趋势可以参考但具体数值不要拿去做精确决策。5. 在 MyEMS 平台落地部署5.1 预测服务整体架构落地的架构不复杂核心是一个独立 Python 服务通过任务调度器每日运行。我的做法是用 APScheduler 做定时任务每天早上 2 点触发一次重训用最近 12 个月数据早上 7 点触发一次预测用截至昨天 24 点的最新数据生成今天和明天共 48 小时的逐时预测。重训不是每次都必须但每天跑一次成本不高还能自动适配数据量增长。流程上就是四步从 MyEMS 历史库取数 → 走相同的数据清洗和特征工程 → 加载最新模型做推理 → 把预测结果写回 MySQL 中间表。整个链路跑完不超过 10 分钟其中大部分时间花在取数和特征构造上模型推理本身几乎可以忽略。5.2 结果表设计与写入为了让 MyEMS 前端能直接读预测结果我建了一张独立表不修改 MyEMS 原有的表结构。表设计尽量简单CREATE TABLE forecast_result ( id BIGINT AUTO_INCREMENT PRIMARY KEY, meter_uuid VARCHAR(64) NOT NULL, forecast_time DATETIME NOT NULL, predict_value DECIMAL(10, 2) NOT NULL, model_version VARCHAR(32), created_at DATETIME DEFAULT CURRENT_TIMESTAMP, UNIQUE KEY uk_meter_time (meter_uuid, forecast_time) );写入时带上 model_version方便追溯某一天的预测是用哪个模型版本跑出来的。唯一索引保证同一负荷点同一时刻不会重复写入即使定时任务被触发两次也不会产生脏数据。预测服务如果连续三天都失败运维人员能从 created_at 时间戳判断出预测数据是否断更。5.3 前端展示实际与预测对照曲线前端我是在 MyEMS 的 Vue 工程里单独加了一个只读页面用 ECharts 展示双折线一条是实际负荷曲线一条是预测曲线。页面打开时从 forecast_result 表读未来 48 小时预测数据同时从历史库读今天已发生的实际值。两张图叠在一起能源管理人员一眼就能看出明天哪个时段负载最高。这里还有一个特别有价值的联动功能峰值预警。在展示层做一个简单配置比如某台变压器预测值超过额定容量的 80% 时触发企业微信或者邮件通知。预测曲线出现峰值管理员就会提前去看排产计划或储能系统这就是前面提到的需量管理的落地形态。5.4 部署运维的一些实际建议生产环境建议用 Python 3.10 PyTorch CPU 版本推理时单条负荷预测毫秒级完全不需要 GPU。模型文件用 .pt 格式保存到固定目录每次重训先保存新模型再覆盖旧模型如果训练过程中出现异常比如数据源断了、NaN 太多程序要能捕获异常并自动使用上一次保存的模型继续预测宁可预测值不准也不能让流程中断。另外预测服务的日志要单独输出内容包括取数数量、特征构造时间、训练 epoch 数、预测值条数、写库状态等。等真正上线后你会发现自己翻得最多的就是这些日志。没有日志出了偏差连查的方向都找不到。6. 常见问题与排查实录6.1 测试集准确率只有 85%通常问题出在哪这是被问得最多的一个问题。如果你跑完测试集发现准确率只有 85% 左右我建议按照这个顺序排查。第一先看数据切分是不是有问题。最常见的是随机切分导致的未来信息泄露看似准确率高实际上验证方式不对或者是节假日数据没有从训练集剥离特征模型在节假日上完全失效。第二看缺失值处理。连续大段缺失直接插值会产生非常假的样本模型会被带偏。第三看外部特征。天气是空调负荷的主驱动因素如果没有温度特征夏季预测误差会系统性走高。第四看目标值本身。个别电表某段时间计量错误产生的异常点如果没被清洗掉会被模型当成正常模式去学习误差被拉低的同时模型质量反而下降。我见过很多“精度上不去”的项目最后 90% 是数据问题。模型本身基本不会差太多因为结构和超参就那几个选择是数据决定了一个模型的上限。6.2 预测曲线总是比实际慢一拍怎么处理线上运行最常见的现象是预测曲线和实际曲线形状很像但整体往右平移了一两个小时仿佛模型是在“复制昨天的数据再延迟一下”。这个问题的根源在于单步预测的滚动机制模型每预测一个点就要把这个点作为历史重新喂进网络如果模型对时间编码的利用不充分它就会倾向于学习“直接把最近的观测值当作下一时刻的预测”导致滞后。我的实际改进措施有三个一是把 lookback 从 24 小时加长到 168 小时让模型有足够长的上下文判断当前处于一天中的哪个阶段而不是只看最近几个小时的惯性二是确保 week 编码和 hour 编码进模型让模型更依赖时间特征而不是盲目复制三是在滚动预测时做一个小 trick输入窗口里的后续预测值不用纯预测值替换而是用“0.7×预测值 0.3×历史同期均值”做混合等模型逐步校准。这个 trick 和滞后问题不完全一样但实测能减少非线性误差的过快累积。讲了这么多最想强调的一点是不要一开始就追求最先进的模型。先把数据链路跑通把实际负荷曲线画出来让业务方看到预测线和实际线在同一个图上再谈 95% 还是 96% 的精度这就是工程和实验室研究最本质的区别。对我个人来说这个项目最大的收获也不是那 4.7% 的 MAPE而是亲眼看到预测结果真的被用在了园区每天的排产和预警流程里。如果你也要做类似的事先从一条电表、一张曲线开始一步步来后面整个系统的价值会自然生长出来。
最近把公司园区能源管理平台上的负荷预测模块重新做了一版底层用的是开源能源管理系统 MyEMS预测模型用的是 LSTM 神经网络。最终在 2023 年全年留出的测试集上MAPE 做到 4.7%换算成大家常说的“准确率”大概在 95% 上下。要说明的是95% 不是每条曲线每个时刻都能达到而是整体评估能稳定复现的水平。这篇文章把从数据准备、模型选型到在 MyEMS 里落地的完整过程写清楚重点补上那些文档里不会写的细节。如果你正在负责能源管理、能耗监测这类系统或者想在企业项目里用深度学习做时序预测这篇文章应该能帮你省掉不少弯路。项目最大的价值不在于 LSTM 本身而在于把 AI 能力真正嵌进一套生产可用的能源系统里让预测结果直接服务于需量管理、购电计划和设备预警。下面按我实际推进的顺序来讲。1. 项目背景为什么要在 MyEMS 里做负荷预测1.1 负荷预测解决的是真实账单问题先说电费结构。国内一般工商业用户执行的是两部制电价除了电量电费还有按变压器容量或者最大需量计收的基本电费。容量费是固定的每月多少就是多少需量费则按当月最大 15 分钟平均负荷来收峰值越高这笔钱就越高。负荷预测最直接的价值就在这里如果能提前 24 小时知道明天的负荷峰值出现在几点就可以安排储能放电、调整生产计划、让大型设备错峰运行把峰值压下来。另一个刚需场景是购电计划。随着电力市场化交易推进越来越多的园区需要提前申报次日用电量。申报不准偏差考核直接反映在成本上。传统做法靠老师傅经验估误差经常在 10% 以上。而一个训练良好的负荷预测模型日电量预测误差可以控制在 5% 以内这个差距对月度电费的影响是实打实的。还有设备预警的价值。当预测值与实际上升趋势出现持续明显偏差时往往意味着有异常设备在偷偷耗电或者某个回路出现了泄漏。把预测模块作为基线再接一套偏差报警能源管理人员能节省大量人工排查时间。这个需求不一定写在最初的立项文档里但落地之后大家都很喜欢用。1.2 MyEMS 在整个方案里的角色MyEMS 是一套开源能源管理系统核心能力包括数据采集Modbus、BACnet、OPC UA 等协议、能耗分项计量、计费、报表和运维管理。部署上支持 Docker 一键起数据库主要用 MySQL前端是 Vue Element UI。我们选择在 MyEMS 之上做预测模块而不是重新搭一套数据平台原因很简单数据采集中间件、点位管理、历史库存储这套基础设施自己从头写至少得两三个月而且稳定性不一定比得上成熟方案。MyEMS 已经把从电表采集到历史数据落库这条链路做好了预测服务要做的只是从数据库里取数、训练、再把结果写回去。整个预测模块是一个独立的 Python 进程不侵入 MyEMS 核心代码升级主程序也不会影响。部署层面MyEMS 官方提供了 docker-compose数据库默认会建出主库、历史库和计费库等。点位和设备信息在配置界面维护历史数据按年份分库。预测服务挂在同一台服务器或者内网另外一台机器上都行只要网络能访问 MySQL。这样改造的侵入性最小也是我这次能快速把预测模块跑起来的关键前提。2. 模型选型为什么是 LSTM 而不是 ARIMA 或 Transformer2.1 负荷数据本质上是多周期叠加的非平稳序列做过负荷预测的人都清楚电力负荷曲线有几个非常明显的特征按天有峰谷按周有工作日和周末的差别按季节有冬夏两个高峰。同时它还受温度、湿度影响夏季空调负荷和温度几乎强相关而且存在滞后效应——今天三十七八度的高温电网负荷往往到傍晚才到达顶点。这种数据用线性模型处理会比较吃力。ARIMA 这类方法在处理平稳时序时表现不错但负荷序列的周期性和天气耦合让它难以达到高精度。机器学习树模型比如 XGBoost能处理特征交互但它们是“用历史特征跳到未来”对长序列的时序依赖建模能力有限。LSTM 这类循环神经网络天然适合捕捉时间步之间的依赖关系尤其是小时级数据里“过去了 24 个小时周期又回来了”这种规律。LSTM 全称 Long Short-Term Memory是在普通循环神经网络基础上加了门控机制由 Hochreiter 和 Schmidhuber 在 1997 年提出。它的遗忘门、输入门和输出门决定了哪些历史信息要保留、哪些要丢弃这恰恰是负荷预测最需要的能力既能记住一个月前的同一天是工作日还是节假日又能及时忘掉上周那几天的临时检修带来的异常波形。2.2 与常见方案的实测对比我把几种方案都跑过一轮使用同一份数据、同样的训练测试集划分结果可以作为参考。表里的 MAPE 是平均绝对百分比误差数值越低越好。模型MAPE是否需要复杂特征工程训练时间备注ARIMA11.2%是秒级对节假日无能为力XGBoost6.8%是分钟级需要大量滞后特征两层 LSTM4.7%一般20 分钟左右可自动捕捉序列依赖Transformer5.6%一般40 分钟以上数据规模小时反而过拟合XGBoost 其实已经很能打了如果数据量有限用它做基线再合适不过。但 LSTM 的优势是在不太依赖人工设计几百个滞后特征的情况下就能把周期性和外部特征融合起来最终把误差再往下压 2 个百分点左右。Transformer 理论能力更强但我这套园区数据只有 3 台变压器、两年左右的逐时记录样本量不足一万八千点Transformer 在这种规模下学不到足够的注意力模式效果反而不如 LSTM 稳定。2.3 对一个单园区项目来说“简单”就是优势这里想多说一句选型不要追潮流。图神经网络在一些区域级电网调度里很流行因为它能建模母线、变电站、用户之间的拓扑关系但在一个园区项目里你需要预测的负荷点可能只有几个到几十个彼此之间的物理耦合关系并不强硬建图结构只会增加复杂度收益很小。LSTM 在这个规模下还有一个现实优势生态成熟。PyTorch 里几十行就能搭起来训练用 CPU 也能跑推理单条毫秒级。部署不需要 GPU服务器上装一个 PyTorch CPU 版本就够了这对很多企业 IT 环境来说是巨大的友好性。我最初也考虑过更复杂的 Sequence-to-Sequence 架构后来一评估单步预测加滚动的方式已经能满足业务需求就先按最简方案落地后面再迭代。3. 数据准备准确率的分水岭3.1 从 MyEMS 历史库取数的正确姿势在 MyEMS 里每个计量点位以 meter 或 point 的形式管理点位有唯一的 uuid。历史数据存在历史库中按年分库表里以 uuid 和时间戳记录瞬时值。我们的园区电表是 15 分钟采集频率但预测是按小时做的所以要先把 15 分钟原始值聚合成小时均值或小时末尾值。这里有个细节聚合时最好做“对齐”比如取每个整点前 15 分钟的均值或者取整点时刻的值整条训练链路的取值口径必须一致否则模型会学到奇怪的噪声。取数可以直接写 SQLMyEMS 数据库本身是 MySQL。基础查询逻辑类似这样SELECT meter_uuid, record_time, value FROM myems_history_db.record_2023 WHERE meter_uuid your-meter-uuid AND record_time 2023-01-01 00:00:00 AND record_time 2024-01-01 00:00:00 ORDER BY record_time;实际部署时我推荐用 SQLAlchemy 在 Python 里读写起来干净也方便后续接定时任务。要注意时区问题MyEMS 的部署环境如果用的 UTC而业务上关心北京时间就得在取数和聚合时统一换算否则早晨的峰谷会偏移一小时模型的日周期特征会被破坏。3.2 缺失值、异常值和节假日老生常谈但决定成败数据质量是预测精度的最大变量。数据不好再强的模型也白搭这个说法放到负荷预测里一点不夸张。我在处理这批数据时遇到过三种典型情况第一是缺失。采集链路偶尔断线扇区不完整电力载波丢包都会导致某几个小时没有记录。对单点缺失线性插值就能应付如果连续缺失超过 6 个小时不建议直接插值最好把这一段从训练样本里剔除否则模型会试图去拟合一段根本不存在的数据等于人为制造噪声。第二是异常尖峰。比如某个时刻抄表值突然跳到三倍电表量程这通常是数据采集器瞬时错误而不是真实负荷。我用的是滚动中位数检测窗口取 24 小时如果当前值比中位数高出一倍以上或者低于中位数的一半就标记为异常然后用前后最近的有效值插值替换。这个方法不复杂效果很稳。第三是节假日。这个特征值得单独拿出来说。如果模型不知道明天是国庆节它会把节假日当成普通工作日来预测误差直接飙到 20% 以上。我维护了一张中国法定节假日表包括调休安排在特征里加一个 is_holiday 标记。光这一个特征就能让节假日样本的 MAPE 从 12% 降到 6% 左右性价比极高。3.3 特征工程外部特征的取舍负荷预测的特征分两块序列特征和外部特征。序列特征就是历史负荷本身外部特征包括时间编码、节假日、天气等。LSTM 的输入是一个序列但额外特征也需要拼进去。我这里最终采用的特征组合是历史 168 小时的负荷序列lookback 窗口 7 天、当前小时编号和星期编号的 sin/cos 编码、is_holiday 标记、当天最高温和最低温、当前时刻温度以及过去三小时的平均温度。关于温度要说一句空调负荷对温度响应不是瞬时的房间和大楼的蓄热效应会让负荷变化滞后于气温变化好几个小时所以把过去几小时的平均温度作为特征加进去比只用当前温度效果好很多。这个细节也是我在验证集上反复对比后确认的。特征不是越多越好。一开始我加了很多无关维度比如风速、湿度结果对 MAPE 几乎没有影响训练时间还变长了。考虑到气象数据也是从第三方接口拉的稳定性不可控我最后只保留了温度相关项把服务对气象接口的依赖降到最低。这也是做企业项目时的一个重要原则外部依赖越少系统越可靠。3.4 样本构造与时间切片划分预测任务的定义是给定过去 168 小时的负荷和当前的外部条件预测下一个小时的负荷。我用滑动窗口构造训练样本。数据是时间连续的但窗口可以重叠每个窗口生成一条样本。这样 7000 多个小时的数据能生成上万个训练样本对 LSTM 来说够用了。划分数据时有一个特别容易踩的坑时序数据不能随机切分。很多人习惯用 sklearn 的 train_test_split 随机打乱这在普通分类任务里没问题但在时序任务里会把未来的信息泄露到训练集中。比如用 6 月的数据去训练、让模型去预测 4 月的样本这显然不合理。我直接用时间索引切分前 70% 做训练中间 15% 做验证最后 15% 最近三个月做测试。这样测试集上的指标才真实反映上线后的表现。4. 模型构建与训练LSTM 网络细节4.1 网络结构与关键参数网络结构保持简单输入层接入 168 步的序列特征和外部特征经过两层 LSTM 层每层 64 个隐藏单元层间加 dropout0.2 防止过拟合最后接一个全连接层输出下一小时的负荷预测值。这个结构在大多数小时级负荷数据集上都够用再增加层数或者单元数并不会明显提升精度反而容易过拟合。用 PyTorch 实现核心代码大概这样import torch import torch.nn as nn class LSTMForecaster(nn.Module): def __init__(self, input_size, hidden_size64, num_layers2, dropout0.2): super().__init__() self.lstm nn.LSTM( input_sizeinput_size, hidden_sizehidden_size, num_layersnum_layers, batch_firstTrue, dropoutdropout, ) self.fc nn.Linear(hidden_size, 1) def forward(self, x): out, _ self.lstm(x) out out[:, -1, :] # 取最后一步的输出 return self.fc(out).squeeze(-1)这里 input_size 是每个时间步的特征维度我的是 8 维1 维负荷 2 维时间编码 1 维节假日 4 维温度相关。之所以把负荷和外部特征都放进序列里是因为 LSTM 在每个时间步都能看到外部条件模型可以自己去学时间编码和负荷之间的交互关系比在 LSTM 输出后再拼接特征更自然。4.2 训练流程归一化、优化器和早停训练细节对结果影响很大。首先是归一化负荷值和温度值不在一个量纲必须做缩放。我用的 MinMaxScaler把所有特征都缩放到 [0,1] 区间。这里有个铁律scaler 只能在训练集上 fit然后同时 transform 训练集、验证集和测试集。如果先对全部数据做归一化再切分测试集的信息就泄露到训练里了测试指标会虚高上线后立刻现原形。优化器用 Adam初始学习率 0.001损失函数用均方误差 MSE。训练最多 200 个 epoch但配合两个回调验证集 loss 连续 20 个 epoch 不下降就提前停止学习率在验证集 loss 连续 7 个 epoch 不下降时降低 50%。这两个机制能让训练过程更稳定也避免我在调参上花费太多精力。每次 epoch 结束后我会在验证集上计算一次 MAPE训练日志里直接打印。实际跑下来前 30 个 epoch 验证 MAPE 从 8% 快速降到 5% 左右后面几十个 epoch 在 4.7% 和 5.2% 之间慢慢波动最终早停在某个相对低点。整个训练过程在纯 CPU 环境下大约 20 分钟时间完全可以接受。4.3 评估指标与结果解读评估指标我用了三个MAPE、RMSE 和 R2。MAPE 是业务上最好解释的指标计算方式是所有预测误差绝对值的平均百分比。测试集最终 MAPE 为 4.7%对应的通俗说法就是“准确率 95.3%”。RMSE 大约是园区平均负荷的 8% 左右说明个别高峰时段的误差会比平均大一些。R2 接近 0.96说明模型解释了绝大部分负荷方差。这组数字单独看可能不够直观。我拿同一个测试集跑了 ARIMA 做基准MAPE 是 11.2%XGBoost 经过充分调参后是 6.8%。也就是说LSTM 相比传统时序方法减少了超过一半的预测误差相比优秀的树模型也降低了约 30% 的误差。这个提升幅度在能源管理场景里是有经济意义的日电量预测上5% 以内的误差已经进入可以辅助购电申报的区间了。还要说清楚一点模型支持的是未来 24 小时逐时滚动预测不是一次预测整个月。滚动多步预测时每往后推一步前面的预测值会被当作输入回填到窗口里误差会随步数累积。实测未来 24 小时的 MAPE 在 5% 到 7% 之间到第 48 小时会涨到 8% 以上。所以上线时我明确只承诺未来 24 小时的预测精度再长的趋势可以参考但具体数值不要拿去做精确决策。5. 在 MyEMS 平台落地部署5.1 预测服务整体架构落地的架构不复杂核心是一个独立 Python 服务通过任务调度器每日运行。我的做法是用 APScheduler 做定时任务每天早上 2 点触发一次重训用最近 12 个月数据早上 7 点触发一次预测用截至昨天 24 点的最新数据生成今天和明天共 48 小时的逐时预测。重训不是每次都必须但每天跑一次成本不高还能自动适配数据量增长。流程上就是四步从 MyEMS 历史库取数 → 走相同的数据清洗和特征工程 → 加载最新模型做推理 → 把预测结果写回 MySQL 中间表。整个链路跑完不超过 10 分钟其中大部分时间花在取数和特征构造上模型推理本身几乎可以忽略。5.2 结果表设计与写入为了让 MyEMS 前端能直接读预测结果我建了一张独立表不修改 MyEMS 原有的表结构。表设计尽量简单CREATE TABLE forecast_result ( id BIGINT AUTO_INCREMENT PRIMARY KEY, meter_uuid VARCHAR(64) NOT NULL, forecast_time DATETIME NOT NULL, predict_value DECIMAL(10, 2) NOT NULL, model_version VARCHAR(32), created_at DATETIME DEFAULT CURRENT_TIMESTAMP, UNIQUE KEY uk_meter_time (meter_uuid, forecast_time) );写入时带上 model_version方便追溯某一天的预测是用哪个模型版本跑出来的。唯一索引保证同一负荷点同一时刻不会重复写入即使定时任务被触发两次也不会产生脏数据。预测服务如果连续三天都失败运维人员能从 created_at 时间戳判断出预测数据是否断更。5.3 前端展示实际与预测对照曲线前端我是在 MyEMS 的 Vue 工程里单独加了一个只读页面用 ECharts 展示双折线一条是实际负荷曲线一条是预测曲线。页面打开时从 forecast_result 表读未来 48 小时预测数据同时从历史库读今天已发生的实际值。两张图叠在一起能源管理人员一眼就能看出明天哪个时段负载最高。这里还有一个特别有价值的联动功能峰值预警。在展示层做一个简单配置比如某台变压器预测值超过额定容量的 80% 时触发企业微信或者邮件通知。预测曲线出现峰值管理员就会提前去看排产计划或储能系统这就是前面提到的需量管理的落地形态。5.4 部署运维的一些实际建议生产环境建议用 Python 3.10 PyTorch CPU 版本推理时单条负荷预测毫秒级完全不需要 GPU。模型文件用 .pt 格式保存到固定目录每次重训先保存新模型再覆盖旧模型如果训练过程中出现异常比如数据源断了、NaN 太多程序要能捕获异常并自动使用上一次保存的模型继续预测宁可预测值不准也不能让流程中断。另外预测服务的日志要单独输出内容包括取数数量、特征构造时间、训练 epoch 数、预测值条数、写库状态等。等真正上线后你会发现自己翻得最多的就是这些日志。没有日志出了偏差连查的方向都找不到。6. 常见问题与排查实录6.1 测试集准确率只有 85%通常问题出在哪这是被问得最多的一个问题。如果你跑完测试集发现准确率只有 85% 左右我建议按照这个顺序排查。第一先看数据切分是不是有问题。最常见的是随机切分导致的未来信息泄露看似准确率高实际上验证方式不对或者是节假日数据没有从训练集剥离特征模型在节假日上完全失效。第二看缺失值处理。连续大段缺失直接插值会产生非常假的样本模型会被带偏。第三看外部特征。天气是空调负荷的主驱动因素如果没有温度特征夏季预测误差会系统性走高。第四看目标值本身。个别电表某段时间计量错误产生的异常点如果没被清洗掉会被模型当成正常模式去学习误差被拉低的同时模型质量反而下降。我见过很多“精度上不去”的项目最后 90% 是数据问题。模型本身基本不会差太多因为结构和超参就那几个选择是数据决定了一个模型的上限。6.2 预测曲线总是比实际慢一拍怎么处理线上运行最常见的现象是预测曲线和实际曲线形状很像但整体往右平移了一两个小时仿佛模型是在“复制昨天的数据再延迟一下”。这个问题的根源在于单步预测的滚动机制模型每预测一个点就要把这个点作为历史重新喂进网络如果模型对时间编码的利用不充分它就会倾向于学习“直接把最近的观测值当作下一时刻的预测”导致滞后。我的实际改进措施有三个一是把 lookback 从 24 小时加长到 168 小时让模型有足够长的上下文判断当前处于一天中的哪个阶段而不是只看最近几个小时的惯性二是确保 week 编码和 hour 编码进模型让模型更依赖时间特征而不是盲目复制三是在滚动预测时做一个小 trick输入窗口里的后续预测值不用纯预测值替换而是用“0.7×预测值 0.3×历史同期均值”做混合等模型逐步校准。这个 trick 和滞后问题不完全一样但实测能减少非线性误差的过快累积。讲了这么多最想强调的一点是不要一开始就追求最先进的模型。先把数据链路跑通把实际负荷曲线画出来让业务方看到预测线和实际线在同一个图上再谈 95% 还是 96% 的精度这就是工程和实验室研究最本质的区别。对我个人来说这个项目最大的收获也不是那 4.7% 的 MAPE而是亲眼看到预测结果真的被用在了园区每天的排产和预警流程里。如果你也要做类似的事先从一条电表、一张曲线开始一步步来后面整个系统的价值会自然生长出来。
)
)
