企业官网建设流程全解析

我一直觉得，能源管理系统里最容易被低估、但一旦做对就非常出彩的模块，就是负荷预测。很多人把 MyEMS 这类平台当成一个“数据大屏 + 告警中心”：电流电压、功率因数、用能统计看得清清楚楚，但问起“明天这个车间大概用多少电”，回答不出来。这个问题的答案，就是负荷预测的价值所在。我最近把一个基于 LSTM 神经网络的预测模块完整地接进了 MyEMS，实现了对未来 24 小时用电负荷的滚动预测，常规日子的拟合优度做到了 0.95 以上，验证集 MAPE（平均绝对百分比误差）压到 5% 以内，确实够得上“95% 准确率”这个说法。这篇文章把整个过程中的模型选型、数据处理、训练调试、系统集成和踩坑记录都整理出来，给正在做 AI + 能源管理方向的朋友一个可以直接参考的落地路径。

先说明一个容易被误解的点：“95% 准确率”在不同的沟通语境里差别很大。如果你问的是负荷预测的 MAPE，5% 以内，也就是准确率 95%，这在短期负荷预测领域已经是很不错的水准；如果你问的是 R²，0.95 同样代表模型解释了 95% 以上的负荷波动。后面我会把这两套指标都展开讲，你拿到自己的数据后对应着算就行。这篇文章适合三类人：一类是做工业/建筑能源管理的实施工程师，想给现有系统加一个智能预测功能；一类是刚接触时间序列预测的算法同学，想找一个真实业务场景练手；还有一类是纯粹对 AI 落地好奇、想知道 LSTM 在现实世界里到底怎么创造价值的人。

1. 负荷预测在能源管理里的真实位置：它到底解决什么问题

1.1 从“事后统计”到“事前预判”的转变

MyEMS 这类开源的能源管理系统，核心能力是数据采集、监控、告警、统计分析和基础报表。数据采集层支持 Modbus、BACnet、DL/T 645 这些工业协议，把电表、水表、气表、冷热量表的读数汇聚到中心数据库，再通过 Web 界面展示出每小时、每天、每月的用能趋势。这一套体系解决的是“发生了什么”的问题——这个月比上个月多用多少电，哪条产线的单位产品能耗超标了，变压器负载率是不是长期偏低。

但能源管理做到后面，需求一定会从“解释过去”延伸到“预判未来”。这跟开车一样，只看后视镜也能往前开，但只有盯着挡风玻璃才能提前减速、变道、规划路线。负荷预测就是能源管理的挡风玻璃。

我在实际项目里梳理过，负荷预测在 MyEMS 这样的系统里至少有四个明确的业务出口：

1.2 “95% 准确率”到底是怎么算的

谈负荷预测的准确率，不能用分类问题那种“猜对/猜错”的视角。时间序列预测的误差是连续的，所以业界一般看三个指标：

• MAPE（平均绝对百分比误差）：把每个时间点的预测误差取绝对值后除以真实值，再求平均。MAPE 5%，口语化表达就是“平均准确率 95%”。
• R²（决定系数）：衡量模型对负荷波动的解释能力。R² = 0.95 意味着真实负荷曲线 95% 的方差变化都被模型捕捉到了。
• RMSE（均方根误差）：带量纲的误差指标，比如“平均偏差 80kW”。这个指标在做需量预警时特别有用，因为需量费是按最大峰值算的，你需要知道预测值可能偏大还是偏小。

我在 MyEMS 项目里最终使用的是 MAPE 和 R² 这两个指标来对外汇报。原因也很简单：MAPE 直观，业务方一听就懂；R² 严谨，能体现模型对复杂波动的解释能力。你在自己的项目里跑完模型后，建议把这三个指标一起算出来放在模型评估报告里，不要只盯着一个数字看。

1.3 预测尺度决定技术选型方向

还有个必须先说清楚的事情：负荷预测的“时间尺度”决定了后面所有的技术选型。

• 超短期预测（未来 5 分钟到 1 小时）：主要用于实时需量控制、微电网功率平衡，对延迟要求极高，传统的时间序列方法甚至线性外推都可能够用。
• 短期预测（未来 24 小时到 72 小时）：用于需量管理、储能策略、需求响应，这是 MyEMS 场景里最常用、价值最直接的一个层级。我这次做的就是这个。
• 中期预测（未来一周到一个月）：用于检修计划、能耗目标制定、电力交易报价，需要引入更复杂的周期性特征。

LSTM 神经网络在短期预测这个层级上表现出色，原因后面章节细讲。但我要先给一个忠告：如果你的业务只需要预判未来半小时，不要杀鸡用牛刀，ARIMA 甚至简单的移动平均都能做得不错；如果目标是未来一周以上，纯 LSTM 也不够，需要融合更多外部因素。明确预测尺度，是开始建模之前的第一件事。

2. 模型选型复盘：为什么最终是 LSTM，而不是 ARIMA 或 XGBoost

2.1 先看负荷数据长什么样

做算法选型之前，我花了不少时间做数据探查。MyEMS 里存的历史负荷数据，如果拉出来画成图，你会发现几个非常稳定的规律：

• 日周期性：工厂通常白天高负荷、夜间低负荷，两班倒或三班倒的企业会有对应的双峰/三峰结构；办公建筑则是明显的早九晚六“驼峰”。
• 周周期性：工作日和周末的负荷水平差异巨大，某些企业周日几乎只剩安保和维保负荷。
• 天气敏感性：夏季高温天的空调负荷、冬季寒潮天的采暖负荷，都会让曲线整体抬升。
• 特殊事件扰动：节假日、设备检修、突发停产，会造成局部的尖峰或断崖。

这些规律说明负荷数据是一个典型的、受多因素影响的“准周期”时间序列。模型要做的事情，本质上是从历史数据里把这些规律“记住”，然后用它外推未来。

2.2 ARIMA 这类统计模型的局限

很多入门资料会把 ARIMA 当作时间序列预测的第一选择，我也确实先跑了一版。ARIMA 的前提假设是序列平稳，或者经过差分后平稳。负荷数据有明显的周期性、趋势性和天气敏感性，想做平稳化处理会非常痛苦，通常要先用 STL 分解把趋势项和周期项拆出来，再用 SARIMA 去拟合残差项。这一套流程下来，模型已经变得很复杂，而且它对节假日、天气突变这类“外生变量”的支持非常有限，预测精度很难突破 85%-90%。

我并不是说 ARIMA 不能用，它训练快、可解释性强、在数据量小的情况下不容易过拟合。如果你手上只有几十天的数据，ARIMA 是合理的起点。但你如果想做到 95% 级别且能应对节假日场景，纯统计模型不够用。

2.3 XGBoost 这类树模型的优势与短板

这两年做预测、画像、排序，很多人第一反应就是 XGBoost。我也专门做过对比实验：把滞后负荷特征、时间特征、天气特征全部做成表格，用 XGBoost 做多步回归预测。它确实很能打，尤其在特征工程到位的情况下，精度可以接近 LSTM 的 90%-93%。

但树模型有一个结构性的短板：它本质上是一个“有监督的特征匹配器”，没有显式的时间记忆机制。如果你想让它记住“三天前这个时候发生了什么”，必须手工构造大量的滞后特征（lag 96、lag 168、lag 336……），特征工程的复杂度会指数上升。而且一旦预测步长拉长，误差会通过递归预测快速累积——因为每一步预测都依赖上一步的输出，错一步，后面步步错。

LSTM 则在结构上天然适合这件事。它通过循环连接维护一个“记忆状态”，网络自己学习从历史序列里提取哪些信息该记住、哪些信息该遗忘，不需要人为设计几百个滞后特征。

2.4 标准 RNN 的核心公式与梯度困境

要理解 LSTM 为什么比标准循环神经网络（Vanilla RNN）强，得先看标准 RNN 是怎么工作的。在时间步 t，循环神经网络的隐藏状态更新公式是：

[ h_t = \tanh(W_{hh} \cdot h_{t-1} + W_{xh} \cdot x_t + b_h) ]

你可以把这个公式理解成：当前时刻的“记忆” (h_t)，是由上一时刻的“记忆” (h_{t-1}) 和当前输入 (x_t) 共同决定的。就像一个人逐字阅读一本书，每读到一个新字，脑子里会结合刚才读过的文字更新理解。

问题出在反向传播上。训练时误差要从最后一步逐层传回最初几步，每次都要乘以 (W_{hh}) 的导数。时间步一长，这个连乘要么指数级坍缩（梯度消失），要么指数级爆炸（梯度爆炸）。结果就是：标准 RNN 能记住最近几步的信息，但让它在 100 个时间步之前的信息和当前预测建立关联，非常困难。负荷预测恰恰需要长依赖——今天的负荷峰值和昨天、上周同一天的历史模式高度相关，这种跨度为 24 小时、168 小时的依赖，标准 RNN 的“短期记忆”不够用。

2.5 LSTM 的门控机制：给神经网络装上一个记账本

LSTM（长短期记忆网络）的关键改进，是加入了细胞状态(C_t) 和三个门控结构。

可以这样类比：标准 RNN 的隐藏状态像一个随手写在便利贴上的字条，容易丢；LSTM 的细胞状态则是一个账本，每一行都记得清清楚楚。三个门控控制信息如何进出账本：

• 遗忘门：决定从账本里划掉哪些旧信息。比如到了周末，“昨天是工作日”这个信息就没什么用了，可以丢掉。
• 输入门：决定新的信息里哪些值得写进账本。比如温度突然升高，这个信号很重要，要记录在案。
• 输出门：决定当前要用账本里的哪些信息来输出预测。比如要预测下午两点负荷，就要把“每天下午两点负荷偏高”这条记忆调出来。

这套机制让 LSTM 能够选择性地保留跨越几十个甚至上百个时间步的有效信息，同时规避梯度消失问题。在我的 MyEMS 负荷预测项目里，输入窗口是过去 168 个小时（一周），预测目标是未来 24 小时。LSTM 能有效建立“今天是星期三下午三点”和“上周三下午三点负荷曲线”之间的关联，这是它能够冲上 95% 准确率的重要原因。

2.6 为什么不用 Transformer 或更复杂的架构

你可能会问，现在大模型这么火，Transformer 的注意力机制不是更强吗？我的回答是：Transformer 确实在长序列建模上有优势，但它对数据量的要求更高，训练更慢，推理延迟更大。在一个中小规模的能源管理系统里，一年 15 分钟粒度的数据大约 3.5 万条，给一个资源有限的边缘服务器做推理，LSTM 的性价比远远高于 Transformer。我实测过，在同样的数据和硬件条件下，LSTM 的训练时间大约是 Transformer 的 1/3 到 1/2，推理延迟低一个数量级，精度差距在 1-2 个百分点以内。业务上完全够用。

模型选型这件事，我的原则很简单：够用、稳定、低成本。在一个真实的能源管理项目里，工程价值大于模型炫技。下表是我做的横向对比，你可以直接参考：

3. 工程关键：特征怎么选、数据怎么清洗，准确率一半在这里

3.1 我的特征全集：不只是“历史负荷”

很多人跑 LSTM 预测，第一版模型只把历史负荷序列扔进去，结果发现效果不错但始终差一口气。原因很简单：负荷变化不只由历史负荷决定，还受外部因素影响。我最终使用的特征全集如下表：

其中“历史负荷”的滞后项选择是有讲究的。我选了 1 小时、24 小时、48 小时、168 小时这四档——1 小时捕捉最近趋势，24 小时和 48 小时覆盖日周期性，168 小时覆盖周周期性。如果你直接用整个滑动窗口（比如 168 小时全部输入），LSTM 也能自己学习这些周期关系，但加上这四档滞后特征等于给模型喂了“参考答案”，收敛速度更快，精度也略有提升。

3.2 归一化：LSTM 的底线操作

LSTM 内部大量使用 tanh 和 sigmoid 激活函数，这两个函数对输入范围非常敏感。如果你把几百安培的电流值直接喂进去，经过激活函数后梯度会瞬间饱和，模型基本学不动。所以归一化不是可选步骤，而是前提条件。

我使用的是 MinMaxScaler，把所有特征统一缩放到 [-1, 1] 区间。选择 MinMax 而不是 StandardScaler，是因为负荷数据通常没有特别极端的重尾分布，MinMax 能保留原始分布的相对关系，且反归一化方便——预测完成后，用同一个 scaler 把输出还原成功率值即可。

这里有个容易踩坑的细节：scaler 只能用在训练集上拟合，然后分别应用到验证集和测试集。如果用全量数据拟合 scaler，验证集和测试集的信息就已经“泄漏”到了训练阶段，评估结果会虚高。后面我还会专门讲这个问题。

3.3 数据清洗：识别“真变化”和“假突变”

能源数据比很多人想象中脏。我用 MyEMS 拿到的原始数据里，常见问题有：采集器断线导致一段时间数据为空；电表更换导致同一测点的量程突然变化；互感器故障导致数据跳变；还有人为的抄表错误。如果对这些数据不做处理，LSTM 会把异常当成正常模式学习，预测结果就会被带偏。

我的清洗策略分三层：

1. 缺失值处理：单点缺失用前后均值填充，连续缺失超过 2 小时则标记该时段为“不可用”，在训练时直接剔除对应样本，而不是强行插值。
2. 阈值过滤：根据表计的额定容量设定物理阈值，超过阈值的数据点直接置为缺失。比如一块 250A 的表计，瞬间读到 1000A，这种数据大概率是故障。
3. 突变点鉴别：相邻两个采样点的负荷变化率超过正常范围（我用的是 50%），则进一步判断属于“真实生产事件”还是“数据异常”。判断方法是同时段多表计的交叉验证：如果同一母线上所有表计同时跳变，大概率是真实的生产启停；如果只有单块表计跳变而周围表计平稳，则判定为数据异常。

在清洗过程中，我的原则是“保守标记，谨慎剔除”。尽量不要人为修改数据值，因为任何插值都会引入噪声；宁可把异常段排除在训练集外，也不让一个错误数据点污染模型的记忆。

3.4 滑动窗口与训练/验证/测试集的切分

LSTM 的输入是“序列片段”，所以需要把连续的时间序列切成固定长度的窗口。每个样本的输入是过去 168 个小时的特征序列，标签是未来 24 个小时的负荷值。窗口滑动步长取 1 小时，这样数据利用率高，样本数也充足。

切分数据也要遵循时间顺序，这一点特别重要。我见过不少人直接调用train_test_split随机打乱数据，这在时间序列预测里是严重错误——它会训练集里混入未来信息，测试集里出现“模型已经见过”的相邻时间点，评估结果虚高。我采用的做法是：

• 前 70% 作为训练集
• 中间 15% 作为验证集（用于早停和学习率调整）
• 最后 15% 作为测试集（只用于最终评估）

这样的划分保证了“训练线”在时间上严格早于“测试线”，模拟的是真实部署时“用过去预测未来”的场景。

4. 网络搭建与训练：95% 准确率是怎么一点点抠出来的

4.1 网络结构：从简单到复杂的迭代过程

我最初的模型是一个单层 LSTM + 一个全连接输出层，只有 32 个隐藏单元。这个基线模型的测试集 R² 约 0.89，离目标还有差距。通过逐步调试，最终确定的结构是：

• 输入层：时间步 168，每个时间步的特征维度 14
• LSTM 层 1：64 个隐藏单元，return_sequences=True
• Dropout 层：比率 0.2
• LSTM 层 2：32 个隐藏单元
• Dropout 层：比率 0.2
• 全连接层：输出维度 24（即未来 24 小时的负荷预测）

选择两层 LSTM 而不是一层，是因为单层 LSTM 虽然能捕捉基本的日周期，但在同时建模“日周期”和“周周期”两个时间尺度时力不从心。第二层 LSTM 相当于在第一层提取的局部时序特征之上，再抽象出更高层的时间模式。Dropout 则是为了抑制过拟合——在能源数据这种信噪比不算高的场景里，Dropout 带来的泛化能力提升肉眼可见。

4.2 损失函数与优化器选择

损失函数我用的是 Huber Loss，而不是最常见的 MSE。原因是负荷数据偶尔会出现极端尖峰（比如设备集中启动），MSE 会对这些离群点施加平方级惩罚，导致模型把大量学习能力花在“拟合尖峰”上，反而牺牲了常规时段的精度。Huber Loss 在误差较小时表现为平方损失，误差较大时转为线性损失，兼顾了收敛速度和对离群点的鲁棒性。

优化器用 Adam，初始学习率 0.001，这两个是经过大量实践验证的默认组合。训练轮数（epochs）设为 100，但配合了早停策略（EarlyStopping），当验证集损失连续 10 个 epoch 不下降时停止训练。实际训练中，模型大约在第 28 个 epoch 就触发了早停，避免了过拟合。

4.3 核心模型代码（PyTorch 版本）

下面是模型定义和训练逻辑的精简版，完整工程里还会包含特征构建、归一化、数据加载等模块，但核心结构如下：

import torch import torch.nn as nn class LSTMForecaster(nn.Module): def __init__(self, input_dim, hidden_dim, num_layers, output_dim, dropout=0.2): super().__init__() self.lstm = nn.LSTM( input_size=input_dim, hidden_size=hidden_dim, num_layers=num_layers, batch_first=True, dropout=dropout ) self.fc = nn.Linear(hidden_dim, output_dim) def forward(self, x): # x shape: (batch_size, seq_len, input_dim) out, _ = self.lstm(x) # 取最后一个时间步的隐藏状态作为序列总结 last_hidden = out[:, -1, :] return self.fc(last_hidden) model = LSTMForecaster( input_dim=14, hidden_dim=64, num_layers=2, output_dim=24, dropout=0.2 )

训练时的核心循环，要注意把预测值和真实值都反归一化后再计算评估指标，否则 MAPE 没有任何意义：

criterion = nn.HuberLoss() optimizer = torch.optim.Adam(model.parameters(), lr=0.001) for epoch in range(max_epochs): model.train() for batch_x, batch_y in train_loader: optimizer.zero_grad() pred = model(batch_x) loss = criterion(pred, batch_y) loss.backward() optimizer.step() # 每个 epoch 结束后在验证集上评估，判断是否早停

4.4 训练过程中的观察：什么信号说明模型在变好

训练的时候不要只看 loss 数字，我建议每个 epoch 结束后把验证集的预测曲线和真实曲线画在一起，肉眼观察拟合情况。这一步很关键，因为数值指标可能被少量极端点带偏，而曲线图能直观展示模型在峰值、谷值、节假日切换等关键位置的拟合质量。

我的实际训练过程里，loss 曲线在最初几个 epoch 快速下降，然后进入缓慢下降阶段。验证集上的 MAPE 在第 15 个 epoch 左右降到 6% 以内，第 22 个 epoch 左右降到 5% 以内。继续训练后验证集 loss 不再下降，触发了早停。最终测试集指标为：

4.5 峰值时段的误差为什么总是更大

测试集分析时我发现一个规律：模型在负荷平稳期（如夜间）的 MAPE 可以做到 2% 以下，但在早高峰、午高峰这些负荷快速爬升的时段，误差会扩大到 6%-7%。这背后的原因是，负荷从谷值到峰值的爬升过程受人为操作影响很大——工人几点开机、哪条产线先启动，具有一定的随机性。LSTM 能学会“这个时段负荷通常会上涨”，但无法预知具体是 8:30 还是 8:45 启动。

对业务来说，这个误差水平是可以接受的。需量管理关心的本来就是“未来有没有可能突破设定阈值”，哪怕预测峰值出现 30 分钟的时间偏差，预警系统依然能提前给到足够长的响应时间。

5. 接入 MyEMS 的落地路径：从离线脚本到定时推理服务

5.1 MyEMS 的架构与数据流

MyEMS 的典型部署架构是：现场仪表通过 Modbus/BACnet 等协议接入采集器，采集器把数据写入 MySQL/PostgreSQL，后端服务提供 REST API，前端基于 Web 展示。我的负荷预测模块要做的，就是从这个数据流中“借”一条旁路：从数据库读取历史负荷数据，经过特征工程和模型推理，把预测结果写回专门的预测表，再让前端图表读取展示。

这种做法最大的好处是不侵入 MyEMS 的核心代码。你不需要改动采集逻辑、告警逻辑和现有报表逻辑，预测模块完全是一个独立服务，可以在任何一台能访问数据库的机器上运行。

5.2 独立预测服务 vs 嵌入 MyEMS 源码

我评估过两种集成方式：

• 把预测代码写进 MyEMS 的 Python 服务里：好处是部署链路短，坏处是耦合度高——MyEMS 升级时你需要重新合代码，LSTM 训练环境的依赖（PyTorch 全家桶）也会污染主服务的依赖环境。
• 独立 FastAPI 预测服务 + 定时任务：预测服务独立部署在另一台机器或容器里，通过数据库与 MyEMS 交互。主系统完全无感知。

我最终选了第二种方案。原因很实际：训练和推理的依赖差异太大，独立服务可以单独管理 Python 环境、单独升级模型、单独扩缩容。运维上更干净，也更容易回滚。

5.3 预测结果表的设计

预测结果要写回数据库，表结构设计要支持“一次预测 24 小时”的写入方式。我建的表如下：

CREATE TABLE load_forecast ( id BIGINT AUTO_INCREMENT PRIMARY KEY, point_id INT NOT NULL COMMENT 'MyEMS 测点 ID', forecast_time DATETIME NOT NULL COMMENT '预测的时刻', forecast_value DECIMAL(12,3) NOT NULL COMMENT '预测负荷(kW)', confidence_lower DECIMAL(12,3) COMMENT '置信区间下界', confidence_upper DECIMAL(12,3) COMMENT '置信区间上界', model_version VARCHAR(32) COMMENT '模型版本号', created_at DATETIME DEFAULT CURRENT_TIMESTAMP, UNIQUE KEY uk_point_time (point_id, forecast_time) );

这里的unique key非常重要——定时任务每小时跑一次，每次预测 24 小时，同一时间点会被重复预测多次。有了唯一键，写入时用INSERT INTO ... ON DUPLICATE KEY UPDATE就能做到“新预测覆盖旧预测”，保证前端展示的永远是最新的一次预测结果。

5.4 定时推理流水线的设计

整个预测流水线我用cron + Python 脚本 + FastAPI 查询接口三层实现：

1. cron 任务：每个整点触发一次推理脚本。
2. 推理脚本流程：从 MyEMS 数据库读取过去 168 小时的真实负荷，获取对应的天气预报数据，构建特征矩阵，归一化后送入 LSTM 模型，输出未来 24 小时的负荷序列，反归一化后写回load_forecast表。
3. 展示层：前端页面在同一个图表里叠加展示真实负荷曲线和预测负荷曲线，方便值班人员对照查看。

这个流程看起来简单，但有个细节值得注意：天气特征必须使用“预报值”而不是“实测值”。预测未来 24 小时时，你手上只有天气预报，没有实测天气。如果你用实测天气训练模型，再在推理时输入预报天气，两者之间存在误差，模型效果会打折扣。我在训练时特意引入了一定比例的天气噪声，模拟预报误差，让模型对天气输入的不确定性更鲁棒。

5.5 模型漂移监控与定期重训练

模型上线之后不是一劳永逸。工厂的生产结构会变（新增产线、淘汰设备），季节会变（冬夏负荷差异巨大），这些都会让模型漂移。我的做法是：

• 每天计算一次“近 7 天预测值与实际值的 MAPE”，如果连续 3 天 MAPE 超过 8%，触发告警。
• 每个月做一次全量重训练，用截至当前的所有历史数据重新训练模型，训练完成后在测试集上对比新旧模型指标，只有新模型更优才上线。
• 模型版本号写入预测表，方便追溯某次预测结果是哪个版本产出的。

这套监控机制让预测服务在持续运行了几个月后，依然能保持整体 MAPE 在 6% 以内，没有出现过“模型越用越不准”的失控情况。

6. 我踩过的坑和回收的教训

6.1 数据泄漏：看起来精度高超 99%，上线立刻崩

第一次跑完模型，测试集 R² 高达 0.99，MAPE 只有 1.2%，我当时还挺高兴，结果想了想不对劲——真实场景不可能这么乐观。排查之后发现两个数据泄漏问题：

第一，我用全量数据拟合并缓存了 MinMaxScaler，导致验证集和测试集的统计信息混入了训练过程。第二，我的滞后特征里包含了“t 时刻的真实负荷”，而测试集样本的 t 时刻真实负荷恰好与标签时间重合——模型等于直接抄了答案。

修正方法就是前面说的：scaled 只 fit 训练集，滞后特征只取过去值，绝不使用任何“未来信息”。修正之后 R² 回落到 0.96，这才是真实水平。

6.2 节假日预测的“突然失灵”

清明节前后那几天，模型的预测曲线和真实曲线出现了明显的系统性偏差。原因并不复杂：LSTM 从历史模式里学到的“这个时间点负荷应该上涨”是基于普通工作日的规律，但节假日期间工厂停工、办公场所关闭，负荷模式完全不同。

解决思路有两个方向：一是把节假日作为二进制特征加入模型输入，让模型知道“这不是一个普通的日子”；二是如果节假日样本太少（一年只有十几天），单独训练一个“节假日模型”不现实，可以在预测结果上叠加一个人工修正系数。目前我用的是第一种方案，并且在预测引擎里维护了一份“年度节假日表”，每次推理前自动判断目标日是否为节假日。

6.3 天气特征：你用实测值，推理时只有预报值

这个问题前面提过。如果训练时用实测天气，推理时用预报天气，模型在训练阶段学到的“温度-负荷”映射关系，在推理阶段会因为输入分布不一致而失效。我的建议是在训练数据里叠加高斯噪声模拟预报误差，同时在模型评估时用“带噪声的天气输入”做一次压力测试，确保模型不会因为天气预报偏差 2-3 度就剧烈变化。

6.4 不要一上来就追求“全厂级预测”

我接第一个项目时，试图直接对整个园区的总进线做预测，效果反而不理想。后来发现原因：总负荷是多条产线、多个建筑、多种业态的叠加，混合了太多不同的用电模式，单靠一个 LSTM 很难同时建模。比较好的做法是先按测点分别建模：办公区一个模型、A 车间一个模型、B 车间一个模型，最后用叠加方式汇总成园区总负荷。

分开建模还有一个额外的好处：某条产线改造导致负荷模式变化时，只需要重训对应产线的模型，不影响其他模型。

6.5 部署环境里的版本兼容

最后说一个工程上的小事。PyTorch 对 Python 版本和 CUDA 版本都有要求，在开发机上训练好的模型，部署到生产环境的 CPU 机器上，容易因为依赖版本不一致而无法加载。我用的是把模型导出为 TorchScript，或者直接保存为 ONNX 格式再部署。TorchScript 是最简单的方式，一个torch.jit.trace就能把训练好的模型变成可独立部署的文件，推理时不需要再依赖完整的 PyTorch 训练环境。

我个人的习惯是：训练环境保持完整依赖，生产环境只安装 CPU 版 PyTorch 和 ONNX Runtime，这样模型服务的部署体积能控制在很小的范围内。

做这个项目的整体感受是：LSTM 本身并不复杂，难的部分在于把数据处理好、把特征选对、把评估做严谨，以及把它真正接进 MyEMS 里让它每天稳定地跑。如果让我给一个快速起步的建议，我会说：不要纠结论文里的 SOTA 模型，先拿 MyEMS 里一个数据质量最好的测点，用 60 天数据跑通一版 LSTM，把训练、评估、写库、展示的链路走通，再回来优化精度。链路通了之后，每提升一个百分点的准确率，都是你根据真实数据特征做针对性调优的结果。另外一个小技巧：模型最后输出的时候，除了点预测值，顺手输出一个置信区间——业务方看到“明天 14:00 负荷大概率在 800-900kW 之间”，比看到一个孤零零的 850kW 要放心得多。这个细节在很多项目里都帮我赢得了业务方的信任。