基于MyEMS与LSTM的园区负荷预测实战：准确率95%

最近把公司园区能源管理平台上的负荷预测模块重新做了一版，底层用的是开源能源管理系统 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 或 Transformer

2.1 负荷数据本质上是多周期叠加的非平稳序列

做过负荷预测的人都清楚，电力负荷曲线有几个非常明显的特征：按天有峰谷，按周有工作日和周末的差别，按季节有冬夏两个高峰。同时它还受温度、湿度影响，夏季空调负荷和温度几乎强相关，而且存在滞后效应——今天三十七八度的高温，电网负荷往往到傍晚才到达顶点。

这种数据用线性模型处理会比较吃力。ARIMA 这类方法在处理平稳时序时表现不错，但负荷序列的周期性和天气耦合让它难以达到高精度。机器学习树模型，比如 XGBoost，能处理特征交互，但它们是“用历史特征跳到未来”，对长序列的时序依赖建模能力有限。LSTM 这类循环神经网络天然适合捕捉时间步之间的依赖关系，尤其是小时级数据里“过去了 24 个小时周期又回来了”这种规律。

LSTM 全称 Long Short-Term Memory，是在普通循环神经网络基础上加了门控机制，由 Hochreiter 和 Schmidhuber 在 1997 年提出。它的遗忘门、输入门和输出门决定了哪些历史信息要保留、哪些要丢弃，这恰恰是负荷预测最需要的能力：既能记住一个月前的同一天是工作日还是节假日，又能及时忘掉上周那几天的临时检修带来的异常波形。

2.2 与常见方案的实测对比

我把几种方案都跑过一轮，使用同一份数据、同样的训练测试集划分，结果可以作为参考。表里的 MAPE 是平均绝对百分比误差，数值越低越好。

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 分钟的均值，或者取整点时刻的值，整条训练链路的取值口径必须一致，否则模型会学到奇怪的噪声。

取数可以直接写 SQL，MyEMS 数据库本身是 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 个隐藏单元，层间加 dropout=0.2 防止过拟合，最后接一个全连接层输出下一小时的负荷预测值。这个结构在大多数小时级负荷数据集上都够用，再增加层数或者单元数并不会明显提升精度，反而容易过拟合。

用 PyTorch 实现，核心代码大概这样：

import torch import torch.nn as nn class LSTMForecaster(nn.Module): def __init__(self, input_size, hidden_size=64, num_layers=2, dropout=0.2): super().__init__() self.lstm = nn.LSTM( input_size=input_size, hidden_size=hidden_size, num_layers=num_layers, batch_first=True, dropout=dropout, ) 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，而是亲眼看到预测结果真的被用在了园区每天的排产和预警流程里。如果你也要做类似的事，先从一条电表、一张曲线开始，一步步来，后面整个系统的价值会自然生长出来。