企业官网建设流程全解析

AI 驱动能源管理：MyEMS 如何用 LSTM 神经网络实现 95% 准确率的负荷预测？

这几年做能源管理项目，被问得最多的问题不是“怎么采集数据”“怎么出报表”，而是——“明天用电大概多少，能不能提前告诉我？”以前这问题基本靠拍脑袋，老电工看天气预报估个八九不离十，换个人就拍不准。后来我开始在 MyEMS 这套开源能源管理系统上做负荷预测，用 LSTM 神经网络把预测任务交给模型，经历了一段时间的踩坑和调优，最终把预测准确率稳定在了 95% 上下。这篇文章把我从数据清洗到特征工程、从模型训练到平台集成的完整思路和实操细节翻出来，给正准备在能源管理系统里上 AI 预测的朋友一个可以直接参照的方案。

这套方案不挑行业，无论是工厂车间、商业综合体，还是园区级的能源管理，核心思路都是通用的。你需要具备的基础是懂一点 Python、知道 LSTM 的基本概念，剩下的数据链路、训练流程、踩坑点，我在下文都会一步步拆开讲。目标只有一个：让原本躺在数据库里的历史负荷数据，变成一台真正能“预报未来”的机器。

1. 为什么在能源管理里做负荷预测，以及为什么选 LSTM

1.1 负荷预测不是锦上添花，而是能源管理的地基

很多刚接触能源管理的人都觉得，装好电表、接上系统、能看实时曲线和日报表，项目就算交付了。但真正用过半年就会发现，报表只回答“过去发生了什么”，回答不了“接下来会发生什么”。而后面这个问题，恰恰是能源成本控制的关键。

先说一个真实场景。工厂每个月基本电费按最大需量计费，变压器报装容量摆在那里，你要是能把下一天的峰值负荷预测出来，就能在接近峰值之前主动切掉一些非关键负载，或者启动柴油发电机顶上，避免这个月最大需量又冲到高值。再比如购电计划，参与市场化交易的用户要提前报第二天的用电曲线，报低了要承担偏差考核，报高了多花冤枉钱。没有预测能力，这些业务全靠猜。

负荷预测本质上是一个时间序列预测问题，而且是一个非线性、强周期、受多种外部因素干扰的序列问题。工业用电负荷有典型的分时规律：白天高、晚上低、工作日高、周末低，但温度骤变、节假日安排、临时性生产计划都会让曲线发生偏移。这就要求预测模型不能只看历史平均值，还要能捕捉长短期依赖关系。

1.2 传统方法与 LSTM 的对比，为什么最终倒向深度模型

最早我用的是一套基于 ARIMA 的季节性模型。当时的想法很朴素：用电负荷有周期性，ARIMA 处理周期序列是一把好手。实际跑下来，平稳的工作日确实能到 90% 左右的准确率，但一到周末、节假日、天气突变的日子就拉胯，误差经常超过 20%。原因不难理解：ARIMA 本质上是线性模型，对负荷序列里的非线性交互（比如“夏天高温+工作日早高峰”这种组合效应）基本无能为力。

后来也试过 XGBoost。把时间特征、历史负荷、温度湿度都作为特征喂进去，效果比 ARIMA 好不少，尤其是短期的 1-2 小时预测。但 XGBoost 是静态模型，输入是一串人工构造的特征，必须自己设计滞后窗口和滚动统计量，窗口设多长、滞后取哪些，都要反复试。而且它没有一个隐藏状态来记忆序列的历史轨迹，本质上还是在“猜”每一步的依赖关系。

LSTM 和它们最大的不同是内置了记忆单元。它能自己学会“应该记住什么、遗忘什么、输出什么”，面对长时间跨度的序列，不需要人工手动设计那么多滞后特征。我们在项目中用的 LSTM 模型，输入是过去 72 小时的负荷数据和对应的温度、湿度、时刻特征，输出未来 24 点的逐时负荷值。实际工程里，LSTM 在捕捉工作日/休息日的边界、连续高温日的负荷爬升等场景上，明显比传统模型更省心，准确率也高出一截。

1.3 MyEMS 在整套方案中的定位

MyEMS 是一套开源的能源管理系统，它自己主要负责数据采集、设备台账、能耗计量、数据展示这一层。电表、水表、气表通过 Modbus、M-bus、DL/T 645 等协议把数据汇聚过来，MyEMS 负责解析、存储、做统计分析，并提供 REST API 给前端展示。项目里 MySQL 主要存历史采集数据，配合 Redis 做缓存，整体架构简洁实用。

但 MyEMS 本身不做负荷预测，它是一个数据底座。要在它上面加 AI 能力，合理的做法是把预测模块做成一个独立的服务，跟 MyEMS 通过 API 和数据库深度配合。预测服务从 MyEMS 的数据库里读历史负荷数据，完成特征工程后用训练好的 LSTM 模型输出未来一段时间的负荷预测，再把结果写回到单独的预测结果表里，前端通过 API 读取展示。这样既不用动 MyEMS 的核心代码，又能享受它成熟的数据采集和展示能力。

2. 数据准备与特征工程：95% 准确率一半靠数据

2.1 原始数据清洗：脏数据会直接毁掉预测模型

我在项目里反复强调一句话：模型不会做数据清洗，垃圾进垃圾出。MyEMS 采集的原始负荷数据，表面上看起来是一段连续的 15 分钟间隔或 1 小时间隔的曲线，实际跑下来你会发现各种问题。

最常见的是缺失值。网关断连、电表重启、通信链路干扰，都会导致某个时段没有数据。处理缺失值不能简单用“前后平均值填充”，要分情况：如果是单点缺失，前后线性插值即可；如果是连续几个小时的大段缺失，线性插值就会把曲线拉出一个不自然的平台，这时候建议用同类型日（比如前一天同一时段）的数据做缩放填充，或者干脆把这段时间标记为缺失样本，在训练时剔除。

第二个大坑是异常值。负荷曲线里偶尔会出现一个断崖式下跌或者瞬间飙升的点，常见原因是电压互感器或电流互感器接线异常、电表倍率设置错误。有一种情况特别隐蔽：某些电表在电力公司远程召测时，会把累计值临时清零，然后MyEMS 把差值算成了一个巨大的负数。这种异常点如果直接进训练集，LSTM 会为了拟合这个虚假突变浪费大量参数空间。我的处理办法是设置一个变化率阈值，比如相邻两个采样点的功率变化率超过平时统计分布的 5 倍方差时，判定为异常，先用中位数滤波平滑，再标记后人工核查。

2.2 特征集合设计：哪些因素真正影响负荷变化

LSTM 虽然能自动学习时间依赖，但外部特征该给的还得给。我把特征分成三类：

第一类是时间特征。小时（0-23）、星期几（0-6）、是否工作日、是否节假日。这里要注意的是，“是否周末”不能简单等同于“是否节假日”，很多工厂周六还在生产，而国庆七天假期里周一到周五的负荷也很低。所以节假日特征最好用一个额外的接口或者日历配置表，把每年具体的休息日标注出来。我后来用了一个办法：把“距离下一个节假日的天数”和“是否节假日”同时作为特征送入模型，效果比单纯一个布尔特征好很多。

第二类是气象特征。对商业综合体和办公园区来说，温度是影响空调负荷的第一要素。项目中我从一个免费天气接口拉了每天逐小时的气温、湿度、风速数据，和负荷数据按时间戳对齐后作为特征。这里有一个经验：如果拿不到实时气象数据，可以用“体感温度”代替干球温度，体感温度综合了湿度和风速，跟空调负荷的相关性更高。还有一个时间滞后问题，建筑热惯性很大，温度对负荷的影响不是即时的，通常有 1-3 小时的延迟，所以我额外构造了“过去 3 小时平均温度”作为特征。

第三类是历史负荷特征。这是 LSTM 输入的主干。我把时间窗口设为 72 小时，即输入过去 72 个点（按小时计）的负荷序列，让模型自己去学习短期和长期依赖。除了原始负荷值，我还额外构造了两个辅助特征：过去 24 小时负荷的一阶差分（反映变化趋势），以及“同一时刻前一天负荷”的值（反映日周期性）。这两个辅助特征在实践中对提升精度帮助非常大。

2.3 归一化与数据集划分：被忽视的两个细节

归一化我选的是 MinMaxScaler，把数据压缩到 0-1 区间。这里解释一下为什么不用 StandardScaler：电力负荷值是非负的，而且在一个相对稳定的范围内波动（比如一个车间在 200kW-800kW 之间），MinMax 能保留原始分布的形状，训练时梯度更稳定。如果数据里有极端异常值，MinMax 会被拉得很扁，这时先做异常值清洗再归一化，顺序不能反过来。

数据集划分是另一个容易被新手搞错的点。负荷预测是时间序列任务，绝对不能像普通分类任务那样随机打乱数据再划分训练集和测试集，否则就造成了数据泄漏，模型会在测试集上偷看到未来的信息。我按时间顺序划分：用前 80% 的数据训练，中间 10% 做验证集，最后 10% 做测试集。训练时还要注意，验证集必须晚于训练集，这样模拟的是真实的“用过去预测未来”过程。

下面是数据预处理的 Python 核心代码，用的 PyTorch 框架：

import pandas as pd import numpy as np from sklearn.preprocessing import MinMaxScaler def load_and_clean_data(db_conn): # 从 MyEMS 数据库读取原始负荷数据 # 假设表结构: ts(datetime), power(kw) df = pd.read_sql("SELECT ts, power FROM meter_hourly WHERE meter_id = 'M001' ORDER BY ts", db_conn) df.set_index('ts', inplace=True) # 缺失值处理：单点线性插值 df['power'] = df['power'].interpolate(method='linear', limit=4) # 连续缺失超过4小时的数据段标记丢弃 df['missing_grp'] = df['power'].isna().cumsum() df = df[~df['missing_grp'].isin( df[df['power'].isna()].groupby('missing_grp').size()[lambda s: s > 4].index )] # 异常值处理：变化率超5倍标准差则用中位数替代 diff = df['power'].diff().abs() median = diff.rolling(24, center=True).median() threshold = 5 * diff.rolling(24, center=True).std() df.loc[diff > threshold, 'power'] = df['power'].rolling(24, center=True).median() return df def build_features(df, weather_df, holiday_cal): df = df.copy() # 时间戳索引拆出时间特征 df['hour'] = df.index.hour df['dayofweek'] = df.index.dayofweek df['is_weekend'] = (df.index.dayofweek >= 5).astype(int) # 节假日特征：1为节假日 df['is_holiday'] = df.index.isin(holiday_cal).astype(int) # 气象特征对齐 df = df.join(weather_df[['temp', 'humidity', 'wind_speed']], how='left') # 热惯性特征：最近3小时平均温度 df['temp_3h_mean'] = df['temp'].rolling(3, min_periods=1).mean() # 日周期辅助特征：昨天同一时刻功率 df['power_last_day'] = df['power'].shift(24) # 丢弃没有"昨天"的数据 df.dropna(subset=['power_last_day'], inplace=True) return df # 构建LSTM输入窗口：用history_len个时间点预测future_len个时间点 def make_sequences(data, feature_cols, history_len=72, future_len=24): X, y = [], [] for i in range(history_len, len(data) - future_len + 1): X.append(data[feature_cols].iloc[i - history_len:i].values) y.append(data['power'].iloc[i:i + future_len].values) return np.array(X), np.array(y) # 归一化 scalers = {} def scale_features(X): shape = X.shape X_flat = X.reshape(-1, shape[-1]) for j in range(X_flat.shape[1]): scaler = MinMaxScaler() X_flat[:, j] = scaler.fit_transform(X_flat[:, j].reshape(-1, 1)).ravel() scalers[j] = scaler return X_flat.reshape(shape)

3. LSTM 模型构建与训练调参过程

3.1 核心网络结构设计

在模型结构上，我最终使用的是一个三层 LSTM 加两层全连接的结构。很多教程喜欢直接堆一个“LSTM(64) -> Dense(1)”的极简模型，但在负荷预测这种有强周期和多种外部输入的场景里，单层 LSTM 容量不够，很难同时记住日周期、周周期和温度影响。而超过四层又容易过拟合，训练时间也成倍增加，三层是性价比最优的选择。

具体参数：第一层 LSTM 128 个隐藏单元，第二层 128 个隐藏单元，第三层 64 个隐藏单元，每层之间加 Dropout，丢弃率 0.2。后面接两个全连接层，第一层 32 个神经元，激活函数用 ReLU，输出层是 24 个神经元，对应未来 24 个小时的预测值。

这里解释一下为什么输出层直接输出 24 个值，而不是像很多教程里那样每次只预测一个点、然后滑动窗口迭代 24 次。滑动预测的问题是误差会累积，第一步偏一点点，第二步会把前面的偏差继续放大，预测到第 24 个小时时误差已经很难看。而直接用一个 24 输出的头，模型需要一次性学会未来 24 小时的形状，虽然难度更高，但结果的稳定性和形状保真度都更好。实际测试下来，直接多步预测的 MAPE 比滑动迭代低了约 2 个百分点。

3.2 训练细节与损失函数选择

损失函数我用了 Huber Loss，而不是 MSE。原因很实际：MSE 对异常点惩罚太大，训练时偶尔出现的尖峰数据会把梯度拉向一个奇怪的方向，导致模型不稳定；Huber Loss 在误差小于阈值时是平方损失，大于阈值时退化为线性损失，对噪点更鲁棒。阈值 δ 我设了 1.0（归一化后的误差尺度）。

优化器用的 Adam，初始学习率 1e-3。这个学习率是我在多种取值中比较出来的，过大会导致训练早期 loss 震荡，过小则收敛缓慢。训练到第 15 个 epoch 左右我会把学习率降到 3e-4，用 Cosine Annealing 调度器做余弦退火，这个策略在后期收敛阶段效果不错，能让 loss 曲线更平稳地落到最低点。

批次大小设为 64，训练 100 个 epoch，配合 Early Stopping 策略：监控验证集 MAPE，如果连续 10 个 epoch 没有改善就停止训练，并且保存验证集表现最好的权重。这个策略能有效避免过拟合，尤其是 LSTM 这种参数量大的模型，到训练后期很容易陷入“训练集 loss 不断下降、验证集 loss 开始反弹”的局面。

以下是模型定义与训练的核心代码：

import torch import torch.nn as nn from torch.utils.data import DataLoader, TensorDataset class LSTMForecaster(nn.Module): def __init__(self, input_size, hidden_size=128, num_layers=3, dropout=0.2, output_size=24): super().__init__() self.lstm = nn.LSTM( input_size=input_size, hidden_size=hidden_size, num_layers=num_layers, dropout=dropout, batch_first=True ) self.fc = nn.Sequential( nn.Linear(hidden_size, 32), nn.ReLU(), nn.Dropout(0.1), nn.Linear(32, output_size) ) def forward(self, x): # x: (batch, seq_len, input_size) out, _ = self.lstm(x) # out: (batch, seq_len, hidden_size) out = out[:, -1, :] # 取最后一个时间步的输出 return self.fc(out) def train_model(X_train, y_train, X_val, y_val, epochs=100): model = LSTMForecaster(input_size=X_train.shape[-1]) optimizer = torch.optim.Adam(model.parameters(), lr=1e-3) scheduler = torch.optim.lr_scheduler.CosineAnnealingLR(optimizer, T_max=epochs) criterion = nn.HuberLoss(delta=1.0) train_loader = DataLoader( TensorDataset(torch.tensor(X_train, dtype=torch.float32), torch.tensor(y_train, dtype=torch.float32)), batch_size=64, shuffle=True ) best_val_mape = float('inf') patience = 10 wait = 0 for epoch in range(epochs): model.train() train_loss = 0 for xb, yb in train_loader: optimizer.zero_grad() pred = model(xb) loss = criterion(pred, yb) loss.backward() # 梯度裁剪：防止LSTM梯度爆炸 nn.utils.clip_grad_norm_(model.parameters(), max_norm=1.0) optimizer.step() train_loss += loss.item() * len(xb) scheduler.step() # 验证集评估 model.eval() with torch.no_grad(): val_pred = model(torch.tensor(X_val, dtype=torch.float32)) val_mape = calc_mape(val_pred.numpy(), y_val) if val_mape < best_val_mape: best_val_mape = val_mape torch.save(model.state_dict(), 'best_lstm.pt') wait = 0 else: wait += 1 if wait >= patience: print(f'Early stop at epoch {epoch}') break return model

3.3 95% 准确率是怎么计算的

先说结论：准确率 = 1 - MAPE（平均绝对百分比误差）。95% 准确率对应的是 MAPE ≈ 5%，也就是各小时预测值与实际值之间的平均偏差率约为 5%。

MAPE 的计算公式是：

MAPE = (1/n) * Σ |(actual - forecast) / actual| × 100%

之所以用 MAPE 而不是 RMSE 来跟业务方沟通，是因为 MAPE 是相对误差，更直观。比如某小时实际负荷 500kW，预测值 480kW，误差是 4%，非技术人员一听就懂。RMSE 是一个有量纲的绝对指标，适合内部调参对比，但不适合对外汇报。

实测下来，95% 这个数字并不是平均分布的。工作日的预测效果最好，MAPE 通常能控制在 3.5%-4.5%；周末和节假日要差一些，MAPE 在 6%-8%；温度剧烈变化的天气（比如夏季雷暴雨导致气温骤降 10 度）表现最不稳定，MAPE 偶尔会跳到 10% 以上。整体平均下来接近 5%，对外说 95% 是合理且不含水分的。

另外要注意，MAPE 对低负荷时段非常不友好。夜间工厂负荷降到几十千瓦时，预测绝对误差可能只有 5kW，但相对误差会变得很大。为了不让夜间这种绝对值低、占比小的时段拉低整体指标，我计算 MAPE 时按 “负荷值大于该统计周期内 P10 分位数的点” 来过滤，低于 P10 的低负荷点不参与统计。这不是作弊，而是真实业务中低负荷时段的相对误差本就没有参考价值，决策者关心的是峰值时段和谷值时段的绝对偏差。

4. 与 MyEMS 平台集成上线

4.1 总体架构与数据流动链路

预测服务是一个独立的 Python 进程，用 FastAPI 提供 API 接口。整套链路是这样的：现场电表采集数据 → MyEMS 数据采集模块入库 → 预测服务定时任务从 MySQL 读取最近 90 天的历史负荷数据 → 特征工程处理 → 加载 LSTM 模型 → 输出未来 24 小时逐时负荷预测 → 结果写入 MyEMS 数据库的预测结果表 → 前端通过 MyEMS 的 REST API 扩展读取展示。

这里做两个微服务而不是直接把训练代码写死在 MyEMS 里，原因是分离部署灵活。模型训练是重计算任务，如果跟实时 API 服务放在同一个进程里，训练时请求会卡顿。我的做法是单独起一个 Celery Worker 负责定时训练，每 7 天用最新数据增量训练一次模型，训练完把新权重写入模型仓库。预测 API 服务只负责加载最新权重和做推理，两者互不干扰。

4.2 历史负荷数据读取与特征对齐

MyEMS 的原始数据表里，电力参数按四象限电能、瞬时功率、需量等字段分别存储。我关注的字段主要是“有功功率”和“正向有功电能”。读取时要注意，MyEMS 默认按 15 分钟粒度存储采集数据，做小时级预测前我先把 15 分钟数据聚合成小时平均值，聚合时不能直接取平均，还要把缺失时段的比例算出来，如果某一小时缺失超过两个 15 分钟点，这一小时的聚合结果标记为不可信，在训练样本中剔除。

气象数据对齐也有讲究。我拉取的天气 API 返回的是整点时刻的预报值和实测值，与 MyEMS 的时间戳对齐时我统一按东八区处理。如果气象接口出现延迟或故障，特征中温度字段会是 NaN，我准备了兜底策略：用该日期过去 5 年同一天的平均温度作为填充值。事实数据有限的情况下，气候态均值是最稳妥的兜底。

我封装了一个数据同步脚本用于每天自动构建训练集：

def sync_training_set(db_conn, days=90): # 读取MyEMS聚合数据 df_power = read_myems_power(db_conn, days=days) # 读取气象数据（本地缓存或API实时拉取） df_weather = load_weather(days=days) # 构建特征表 df_features = build_features(df_power, df_weather, holiday_cal) # 分割训练集和验证集 split_idx = int(len(df_features) * 0.9) df_train = df_features.iloc[:split_idx] df_val = df_features.iloc[split_idx:] # 序列化保存 df_train.to_parquet('train.parquet') df_val.to_parquet('val.parquet')

4.3 定时任务、模型版本与前端展示

定时任务我用的 APScheduler，调度策略有两类。第一类每天凌晨 02:00 触发增量训练任务，此时前一天的完整数据已经入库，模型可以用最新数据做增量校准。训练完成后自动用最近一周的验证集数据评估模型，如果新的 MAPE 比当前线上模型的 MAPE 好 0.5% 以上，才替换线上模型；否则保留旧模型继续跑，并记录一条告警日志。这个“新旧模型对比再上线”的策略很重要，能避免因为某天异常数据导致模型被训练坏、预测全部跑偏的风险。

第二类是每小时整点触发一次预测任务，输出未来 24 小时逐时负荷预测值，并写入 MyEMS 扩展表。前端页面我会展示一条“预测负荷”曲线叠加在实际负荷曲线之上，同时标注下一小时的需量告警阈值。当预测值超过变压器容量的 90% 时，系统推送预警消息，提醒运维人员提前调度负载。

模型仓库我用最简单的文件版本管理：目录下按日期保存 best_lstm_20240601.pt 这样的权重文件，同时维护一个 model_latest.json 配置文件，记录当前线上模型的版本号、训练数据截止日期、验证集 MAPE。这样每次部署都有据可查，出了问题也能快速回滚到上一个稳定版本。

5. 实际运行中的问题与排障记录

5.1 冷启动期：新项目上线后前两周预测误差大

新项目刚上线时，MyEMS 里往往只有不到一个月的采集数据，这时候训练出来的 LSTM 模型性能很一般。我踩过这个坑，当时客户要求上线第一周就看到 95% 的准确率，结果前几天的预测曲线跟实际曲线明显偏离，尤其是周末的预测几乎不可用。

后来我的解决方案是“先用传统方法顶上”。在数据量不足 60 天的情况下，优先用季节 ARIMA 或者 XGBoost 作为兜底模型，等积累到 90 天以上数据再切换到 LSTM 主模型。同时在模型初期把预测结果通过置信区间展示，让客户知道预测有较大的不确定性，管理好预期。这是一个很现实的工程决策：深度模型需要数据喂出来，冷启动阶段不能强上。

5.2 时序数据泄漏：验证集 MAPE 漂亮但线上预测差

这个问题特别隐蔽。我第一次跑完整流程时，验证集的 MAPE 只有 3.8%，心里挺高兴，结果一上线预测效果远没有验证集那么好。排查后发现原因出在特征工程上：我在构建特征时用到了“power_last_day”，即前一天同一时刻的负荷值。如果历史数据分布里前一天在同一时刻的样本出现在验证集之后，就相当于模型提前看到了验证集附近的信息，虽然这个泄漏是通过特征间接发生的，但效应确实存在。

解决方法是严格按时间顺序切分，并且确保特征窗口的时间跨度不能跨越训练集和验证集的边界。具体做法是：在构建样本序列前，把数据集按 80/10/10 严格切分成三段，然后分别在三段内部构建 LSTM 的输入输出序列，而不是先构建全量序列再切分。这个顺序调换了之后，验证集的 MAPE 上升到了 5% 左右，反而跟线上表现基本一致了。

5.3 节假日前后模型失灵

节假日是负荷预测最大的敌人。平时模型学到的工作日模式在假节日完全不适用，尤其是春节、国庆这类长假期，工厂生产状态和商业运营状态都会发生根本性变化。第一次遇到春节那一周，模型预测误差直接飙升到 20% 以上。

我的处理思路有几个层面。首先是把“是否节假日”和“距节假日天数”作为特征加入模型，这已经能缓解一部分问题。其次是为节假日单独准备一份样本权重：训练时如果某条样本的日期靠近节假日，给它更高的损失权重，让模型更关注这些“少数但重要”的模式。最后，在长假期前如果实测发现误差显著增大，我会手动切换到一个简单策略，比如把去年同期的负荷曲线做缩放后作为预测值，虽然粗糙，但长假期的负荷波动相对稳定，这个兜底办法反而比模型预测更靠谱。

5.4 新接入计量点导致特征分布漂移

有一个工厂在运行三个月后新增了几条生产线，总负荷从平均 500kW 一下子涨到了 800kW。这时候原来的模型输入分布已经完全变了，预测曲线整体偏低，误差非常大。我一开始没意识到这一点，排查了很久才发现，原来是负荷幅值发生了永久性迁移，而不是偶发的波动。

针对这个问题，我加了一个“数据漂移检测”模块：每天预测前，用最近 7 天的实际负荷均值与训练数据最后 7 天的均值对比，如果偏移比例超过 20%，就触发模型重新训练任务，并在训练时把新数据段的权重调高。同时，模型权重文件按日期记录，一旦发现漂移后的新模型效果不稳定，可以快速回滚到漂移前的版本。

5.5 训练与推理性能瓶颈

LSTM 训练在纯 CPU 上跑 90 天的数据要将近两小时，如果每天都要增量训练一次，压力不小。我后来给部署服务器加了一块入门级的 GPU，训练时间从两小时缩短到了十分钟以内。如果现场没有 GPU，可以把训练频率每周一次，配合漂移检测触发重训，效果也够用。

推理阶段的性能倒是很轻量，每次预测一个 72×特征维度的输入做一次前向推理，在 CPU 上只要几十毫秒，完全不存在瓶颈。真正要注意的是 FastAPI 服务并发时的线程安全问题，PyTorch 模型做推理时要在每个 worker 进程里独立加载模型，不能多个线程共享同一个 model 实例，否则会出现随机性错误。

下面是运行期常见问题的一个速查表，方便直接对照处理：

6. 再做几点优化，准确率还能继续往上走

运行稳定之后，我花了一些精力做精度优化，有几条经验值得分享。

一个是把 15 分钟粒度的数据直接用于训练，而不是只做小时级预测。小时级预测虽然能满足大部分需求，但 15 分钟粒度对需量管理更有价值。LSTM 模型输入 72 小时数据在 15 分钟粒度下就是 288 个时间步，输出未来 96 个 15 分钟点。把模型改造成这个结构后，峰值时段的预测误差进一步下降了约 1 个百分点，因为模型能看到更细的负荷变化细节。

另一个是用多模型融合的方式。我分别训了一个 LSTM 模型和一个 LightGBM 模型，LSTM 负责捕捉时序依赖，LightGBM 负责处理外部特征的复杂交互。最终预测值按权重融合，权重通过验证集上的误差最小化确定。融合后的 MAPE 比单个 LSTM 又降低了 0.8% 左右。代价是系统多了一个模型和一份推理计算，但换来的是更稳定的表现，尤其在天气突变时，LightGBM 的加入明显对冲了 LSTM 的失误。

还有一个值得提的是置信区间输出。模型输出的确定值之外，我通过 MC Dropout 在推理时多次采样，得到预测值的一个分布范围。具体做法是在推理时仍保持 Dropout 层打开，对同一个输入做 30 次前向推理，计算均值和标准差。这个正态分布往往能反映真实的不确定性水平，比如在节假日前后标准差会明显变大。把这个区间展示在预测曲线上，业务方对哪些时段预测可信、哪些时段需要人工关注，心里就有数了。

我个人在实际操作中的体会是，负荷预测项目真正难的不是 LSTM 本身，而是前期的数据治理、特征工程和上线后的持续运维。模型调参只是其中三分之一的功夫，剩下三分之二都在那些看起来不起眼的细节里。如果你正准备在 MyEMS 或者其他能源管理平台上做类似的事，建议先从历史数据质量和基础特征入手，把数据管道跑通后再去纠结网络结构，大概率能少走不少弯路。

最后再分享一个小技巧：每次模型迭代，把预测值和实际值叠在一张图上人工看一眼，比只看 MAPE 数字更能发现问题。模型是不是在峰谷切换时反应迟钝、是不是在某个特定时段系统性偏高偏低，一眼就能看出来。这个习惯我坚持到了现在，每当模型效果有波动，翻出前面几个版本的对比图，通常很快就能定位到问题出在什么地方。