最近在做能源管理项目的时候一个老朋友问我MyEMS 这种开源能源管理系统到底能不能把电负荷预测做到生产可用的级别他手上有一批历史负荷数据和天气数据想上预测功能但不确定用什么样的模型能达到实际效果。我直接给他看了我们跑过的 LSTM 方案预测准确率稳定在 95% 上下MAPE 控制在 5% 以内。他很惊讶因为在他印象里神经网络这东西玄学成分大落地难度高。实际上只要把数据整理、特征工程、模型调参这几步走扎实LSTM 做负荷预测不仅可行而且能稳定复现。这篇文章我就把整个方案从头到尾拆开讲。从 MyEMS 的数据底座怎么和预测模型衔接到为什么选 LSTM 而不是 ARIMA 或 XGBoost再到数据清洗、特征构建、模型训练、误差修正和在线部署的完整链路全部梳理清楚。无论你是刚接触能耗预测的工程师还是已经在做电力数据分析的从业者这篇都能给你一套可以直接参考复现的实操方案。1. 项目整体设计与思路拆解1.1 MyEMS 在能源管理系统中的定位MyEMS 是一套开源能源管理平台常见的生产能力包括设备数据采集电表、水表、气表、能耗统计、费用分摊、数据大屏展示、设备控制等。但它的侧重点在“管理”和“分析”并不自带高精度的负荷预测算法模块。换句话说MyEMS 把数据基础、权限体系、可视化能力都给你搭好了预测模型这层需要自己接入。我们这套项目的切入点很简单在 MyEMS 已有的历史电耗数据基础上新增一个“未来 24 小时负荷预测”模块。数据来源是现场智能电表采集粒度 15 分钟一条通过 Modbus/TCP 或 DL/T 645 协议汇聚到 MyEMS 的 MySQL 数据库。预测模块独立部署成服务定时从 MyEMS 读取历史负荷、温度、湿度、节假日日历用 LSTM 模型预测未来 24 小时逐 15 分钟的负荷曲线再把预测结果回写到 MyEMS 的扩展表里供大屏和报表模块调用。之所以采用“MyEMS 负责数据底座、独立服务负责预测模型”的架构核心原因有三个。第一MyEMS 的稳定版本迭代有自身的节奏如果为了加一个模型去改它的核心调度逻辑后续升级很容易冲突。第二LSTM 训练和推理对 Python 生态依赖很强TensorFlow 或 PyTorch 的环境独立部署可以避免污染 MyEMS 的 Python 运行环境。第三预测结果有独立的评估需求。我们需要随时对模型精度做回溯校验独立服务更方便做日志、监控和版本回滚。1.2 为什么选 LSTM 而不是 ARIMA 或 XGBoost电力负荷预测的常用方案无非三类传统统计模型ARIMA、指数平滑、机器学习模型XGBoost、LightGBM、随机森林、深度学习模型LSTM、GRU、Transformer。我在项目里特意对比过这几类的实际表现。ARIMA 是经典的时间序列方法能捕捉线性趋势和季节性对平稳序列效果不错。但工厂和园区的负荷曲线受生产排班、天气变化、节假日等因素影响往往存在明显的非平稳特征和多变量耦合关系ARIMA 很难同时建模这些因素实际预测误差通常在 10% 到 15%。XGBoost 这类树模型的特点是特征工程灵活你可以把温度、湿度、星期几、是否节假日、历史同刻负荷全部作为特征输进去模型能学到非线性关系提升效果明显。但树模型是“回归器”它本身没有时间序列的记忆结构预测多步时需要反复滚动推理误差会一步一步累积。虽然可以通过合理设计特征窗口来缓解但在连续 96 个预测点15 分钟粒度预测 24 小时的场景下尾段精度衰减比较明显。LSTM 的优势在于它本身就是为序列建模设计的。通过门控机制LSTM 可以记住几天前甚至几周前的负荷模式。以园区为例某个工作日因为设备检修负荷异常偏低树模型可能只把它当噪声忽略但 LSTM 能结合前几天的序列形态和当日特征更合理地推断当前趋势。从实际测试结果看LSTM 在多种预测步长下都能把 MAPE 稳定压在 5% 以内滚动预测 96 个点也无明显误差爆炸。所以最终选 LSTM。1.3 95% 准确率的指标口径先说明一下“95% 准确率”这个口径。负荷预测领域常用指标不是简单算“预测值/实际值”而是 MAPE平均绝对百分比误差。MAPE 降到 5% 以下就相当于预测准确率 95% 以上。我们这套方案在园区场景下15 分钟粒度的 24 小时滚动预测MAPE 可以稳定在 4.2% 到 4.8%。也就是说100kW 的实测负荷预测偏差平均在 4.2kW 到 4.8kW 之间。需要强调一点这个指标并不是所有场景都能复现。如果现场负荷波动剧烈、数据质量差、或者没有对应的天气特征MAPE 可能到 8% 甚至更高。所以文章后面会花大篇幅讲数据清洗、特征对齐和误差修正这三步是决定精度的关键。2. 数据准备与特征工程的完整细节2.1 数据采集的坑粒度、时区和缺失值从 MyEMS 的数据库读数据第一件事不是建模型而是先搞清楚数据长什么样。我强烈建议先做一次全量数据体检至少覆盖以下检查项。第一是粒度是否真的对齐。现场电表可能中途改过采集周期或者因为通讯故障出现上报延迟导致入库数据不是严格的 15 分钟等间隔。比如 MyEMS 表里某天晚上 8 点到 10 点之间有两条记录的时间戳相差 30 分钟其余都是 15 分钟。这种情况必须做重采样修正统一到 15 分钟整点。第二是时区问题。服务器默认时区如果不是东八区时间戳和当地电价时段、生产班次的对应关系就会错位。我们用 MySQL 的 CONVERT_TZ 函数统一转换到本地时区再存到分析专用表里。第三是缺失值和异常值。电表通讯中断会导致整段数据缺失现场电压暂降或互感器故障会导致某几个点负荷跳零或突然翻倍。处理策略分优先级连续缺失少于 2 个点用前后线性插值连续缺失超过 2 个点用前一天同时刻值加权填充如果缺失超过总样本的 5%要回头排查采集通道不要指望算法能弥补数据链路的问题。处理完成后可以把清洗后的负荷序列做一次可视化和描述性统计确认最大值、最小值、均值是否在合理区间比如一个 2500kVA 变压器的园区15 分钟平均负荷一般不会超过 1800kW如果出现 3000kW 以上的记录基本可以判定是异常值。2.2 特征工程序列窗口、日历特征与天气特征LSTM 不是凭空学习输入的特征直接决定预测上限。我们最终用了三类特征组合。第一类是历史负荷序列。这是最核心的输入。我们取过去 7 天、96 点/天共 672 个负荷点组成序列窗口。为什么取 7 天因为大多数工业园区有以周为周期的生产节律周一的负荷形态和上周二有差异但和上周一相似度高。取 7 天窗口可以让模型学到周周期的规律。第二类是日历特征。包括 hour0-23 的整数、day_of_week周一至周日、is_holiday是否节假日、is_workday是否工作日、season春夏秋冬。把这些特征编码后和负荷序列拼接一起喂进模型。节假日特征尤其重要因为节假日负荷通常比工作日低 30% 到 50%如果模型不知道当天是节假日预测值会明显偏高。第三类是天气特征。包括温度、湿度、体感温度、降雨量。其中温度对负荷的影响最显著尤其是夏季高温和冬季严寒时段空调和取暖负荷占比大。我们直接在项目里接了免费的天气 API按小时拉取温度、湿度、天气现象重采样到 15 分钟粒度后对齐到每个时间点。特征构造完成之后还要做一步归一化。LSTM 对输入尺度敏感负荷和温度数值范围差距大负荷几千 kW温度只有三十几度不做归一化会拖慢收敛速度甚至导致梯度爆炸。我们用 Min-Max 归一化把所有特征压缩到 [0,1] 区间。归一化公式很简单x_scaled (x - x_min) / (x_max - x_min)这里 x_min 和 x_max 必须用训练集的统计值不能用全量数据或者预测时刻的数据否则存在信息泄露训练时指标很漂亮上线后直接崩。2.3 训练集、验证集和测试集的划分策略时间序列数据划分数据集不能随机打乱否则模型会“偷看”未来的信息。我们按时间顺序切分前 80% 的历史数据用于训练中间 10% 用于验证集调参最后 10% 作为测试集评估真实精度。切分点要避开节假日等特殊时段最好覆盖完整的周循环保证每个集合里都有工作日和周末样本。数据量方面我们用了大约 12 个月的 15 分钟粒度历史数据总共约 35000 条记录。这个量级对 LSTM 来说不算多需要一定技巧防止过拟合后面会详细讲。3. LSTM 模型设计与训练调参全记录3.1 模型结构输入层、LSTM 层、全连接层我们的模型结构并不复杂包含一层输入层、两层 LSTM 层、一层 Dropout、一层全连接输出层。输入层接收的是三维张量样本数时间步长特征数量。时间步长为 96也就是过去 24 小时的负荷数据特征数量为 5分别是历史负荷、温度、湿度、是否工作日、是否节假日。为什么时间步长取 96 而不是 672之前提到过去 7 天完整序列可以做长序列输入但实际测试发现96 步长已经能覆盖一天内的完整负荷变化周期加上日历特征和天气特征补充外部信息效果和 672 步长差不多但训练速度快很多。如果想进一步做长周期趋势建模可以在数据管线中额外配置一个按小时粒度的特征分支这里不再展开。两层 LSTM 的隐藏单元数分别设置为 64 和 32。第一层 LSTM 返回完整序列第二层 LSTM 只返回最后一个时间步的输出再接一个全连接层输出未来 24 小时 96 个点的负荷预测值。Dropout 比率设为 0.2放在两层 LSTM 之间和 LSTM 与全连接之间用于缓解过拟合。这里有个细节想多说一句为什么用两层 LSTM 而不是一层。一层 LSTM 能学习到负荷序列的基本时序特征但面对多变量输入时提取更高层级的抽象特征能力弱一些。第二层 LSTM 能组合第一层输出的局部模式整体预测精度大约能提升 0.3 到 0.5 个百分点。再加第三层收益很小训练时间却会明显变长性价比不高。3.2 损失函数与评估指标的选择训练 LSTM 回归模型损失函数一般用均方误差MSE或平均绝对误差MAE。MSE 对大误差更敏感会让模型优先减小极端误差MAE 对所有误差一视同仁。做过几组对比测试后我们发现用 Huber Loss平滑平均绝对误差的效果最好它在误差较小时表现为 MSE误差较大时表现为 MAE兼顾了收敛速度和对异常值的鲁棒性。评估指标方面除了前面提到的 MAPE还增加了 RMSE 和 R²。MAPE 用来和业务方沟通“准确率”RMSE 用来衡量实际偏差的离散程度R² 用来判断模型对负荷变化的解释能力。三个指标一起看才能全面评估模型质量。顺便补充一下 Python 实现的评估指标计算import numpy as np def mape(y_true, y_pred): return np.mean(np.abs((y_true - y_pred) / (y_true 1e-8))) * 100 def rmse(y_true, y_pred): return np.sqrt(np.mean((y_true - y_pred) ** 2)) def r2(y_true, y_pred): ss_res np.sum((y_true - y_pred) ** 2) ss_tot np.sum((y_true - np.mean(y_true)) ** 2) return 1 - ss_res / (ss_tot 1e-8)3.3 训练过程与超参数调优我们用 TensorFlow 2.x 的 Keras API 搭建模型批次大小设为 64训练轮数设为 200。优化器用 Adam初始学习率 0.001并且在训练过程中动态降低学习率。当验证集损失连续 10 个 epoch 不再下降时学习率乘以 0.5当验证集损失连续 20 个 epoch 不再下降时触发 EarlyStopping 提前终止训练防止过拟合。实际训练过程中EarlyStopping 大概在第 80 到 100 轮触发训练时间在单张 NVIDIA T4 显卡上约为 20 分钟。如果是纯 CPU 环境训练时间会拉到 2 小时以上但推理速度不受影响单次预测在 CPU 上也能在 1 秒内完成。所以线上部署用 CPU 完全够用不需要 GPU。这里贴一下我们训练时用的核心代码骨架import tensorflow as tf model tf.keras.Sequential([ tf.keras.layers.LSTM(64, return_sequencesTrue, input_shape(96, 5)), tf.keras.layers.Dropout(0.2), tf.keras.layers.LSTM(32, return_sequencesFalse), tf.keras.layers.Dropout(0.2), tf.keras.layers.Dense(96) ]) model.compile( optimizertf.keras.optimizers.Adam(learning_rate0.001), losstf.keras.losses.Huber(), metrics[mae] ) early_stop tf.keras.callbacks.EarlyStopping( monitorval_loss, patience20, restore_best_weightsTrue ) reduce_lr tf.keras.callbacks.ReduceLROnPlateau( monitorval_loss, factor0.5, patience10 ) history model.fit( X_train, y_train, validation_data(X_valid, y_valid), epochs200, batch_size64, callbacks[early_stop, reduce_lr], verbose1 )超参数里影响最大的是 LSTM 隐藏单元数和学习率。隐藏单元数从 32 调到 64验证集 MAPE 下降了大约 0.8 个百分点但从 64 调到 128MAPE 反而上升了 0.2 个百分点过拟合迹象明显。学习率如果直接设成 0.01训练初期 loss 会抖动得很厉害需要调低才行。所以如果你想快速复现可以直接抄我们这个配置大多数场景下都能跑出不错的结果。3.4 数据分割与序列构造的细节套路很多人第一次做时间序列预测会栽在序列构造这一步。输入样本是“过去 96 个时间点的特征”输出标签是“未来 96 个时间点的负荷值”两个窗口之间必须严格连续中间不能跳点。构造过程用滑窗法步长为 1。假设总共有 N 条按时间排序的记录每条记录包含 5 个特征和 1 个负荷值那么从第 96 条开始每往后滑动 1 条就产生一个训练样本。这样 35000 条数据能产生约 34900 个样本数据量充足。还要注意时间错位用 t-96 到 t-1 时刻的特征预测 t 到 t95 时刻的负荷值不能把 t 时刻本身的特征也塞进输入否则相当于让模型开了天眼上线后必然翻车。4. 从 8% 到 4.5%精度优化的关键手段4.1 误差修正残差学习与滚动预测模型初版上线时24 小时预测的 MAPE 在 7.5% 到 8% 之间经过三轮优化降到 4.5% 左右。这里面最有效的一步是残差修正。LSTM 直接输出未来 96 个点的预测值初期最大的问题不是整体偏差大而是峰值负荷预测偏低。工厂某条产线在上午 10 点集中开机负荷从 800kW 瞬间拉到 1500kW模型很难精准预测这种尖峰。针对这类问题我们做了两步修正。第一步是峰值补偿。统计历史数据中每个时段负荷的峰值分布算出模型在峰值时段的平均误差率。预测时对峰值时段通常是上午 9 点到 11 点、下午 2 点到 4 点额外乘上一个 1.02 到 1.05 的修正系数。第二步是滚动预测加残差学习。每预测完一个时段等真实数据出来之后把“真实值 - 预测值”的残差作为特征和最新真实负荷拼接重新构造输入窗口预测下一个时段。这种策略让模型每一步都能吸收最新信息修正系统性的预测偏差。从实际效果看滚动修正能让全天的 MAPE 再下降 0.6 到 0.8 个百分点。4.2 天气特征的滞后性问题天气数据有个天然问题天气预报本身有误差尤其是降雨量越往后预测偏差越大。我们使用的天气 API 提供逐小时预报未来 24 小时内的温度预报相对准确但降雨量前几个小时还准到晚上就可能偏得离谱。针对这个问题我们的方案是把天气预报数据分成两段处理。预测未来 0 到 6 小时直接使用天气预报值预测未来 6 到 24 小时使用“历史同期均值 最新观测偏差”的修正值。比如当前时刻温度 30 度过去 7 天同一时刻的平均温度是 29 度偏差为 1 度那么预测未来 12 小时的温度就取预报值再加 1 度修正。这种方式能抵消一部分系统性偏差。4.3 模型集成与置信区间输出单一 LSTM 模型的预测误差虽然可以控制但偶尔会出现极端误差。比如某个工作日突发设备停机负荷比预测低了 40%这种极端事件模型无法预知。为了提升整体的鲁棒性我们尝试了模型集成方案。同时训练 5 个 LSTM 模型每个模型用不同的随机种子初始化权重训练时用不同的验证集切片最终预测结果取 5 个模型输出的平均值。集成之后 MAPE 进一步下降 0.3 到 0.5 个百分点而且极端误差的发生频率明显降低。代价是训练时间增加了 5 倍但推理时仍然是并行计算 5 个模型后取平均单次推理耗时从 0.8 秒增加到 2.1 秒左右完全可以接受。另外我们还计算了 5 个模型输出的标准差作为每个预测点的置信区间参考值。输出预测结果时附带置信区间业务侧可以做辅助决策当置信区间过宽时提醒调度人员谨慎调整能源策略。5. MyEMS 集成与线上部署实践5.1 定时调度与任务编排模型训练好之后下一步就是接到 MyEMS 的体系里。我们部署在一台独立的 Linux 服务器上使用 Docker 容器运行预测服务通过 cron 定时任务触发每日的模型重训和预测流程。具体的时间规划是每天凌晨 2 点先读取 MyEMS 里前一天的全量负荷数据和天气数据增量训练模型并跑完测试集指标评估。如果 MAPE 超过 6%触发告警并自动回滚到上一版模型文件如果 MAPE 在 5% 以内用新模型替换旧模型。然后每天早晨 6 点用最新版本模型生成当天 6 点到次日 6 点的逐 15 分钟负荷预测结果写回 MyEMS 数据库。回写的表结构是 MyEMS 自定义扩展表包含预测时间、预测值、置信区间下限、置信区间上限、模型版本号等字段。MyEMS 大屏模块直接读这张表就能渲染出预测曲线和实际曲线的对比图。5.2 用 SQL 从 MyEMS 提取训练数据从 MyEMS 里提取训练数据不需要改它的表结构直接用 SQL 查询对应电表的累计电量或瞬时功率。大多数电能表上报的是电度值kWh通过差分可以得到平均功率。我们用的查询逻辑如下SELECT meter_id, record_time, power_value FROM energy_records WHERE meter_id METER_001 AND record_time 2024-01-01 00:00:00 AND record_time 2025-01-01 00:00:00 ORDER BY record_time ASC;如果 MyEMS 存的是电度值假设相邻两个时间点的电度差为 ΔkWh时间间隔为 Δt 小时那么平均功率为P(kW) ΔkWh / Δt以 15 分钟0.25 小时为例相邻两点功率就是电度差除以 0.25再乘以 4 换算成 kW。5.3 推理服务的 REST API 封装预测服务对外提供 REST API供 MyEMS 或其他系统调用。接口设计简洁输入参数是待预测的 meter_id 和预测起始时间输出是未来 24 小时 96 个点的负荷预测值和置信区间。from flask import Flask, request, jsonify import numpy as np import joblib app Flask(__name__) model joblib.load(/models/lstm_latest.pkl) preprocessor joblib.load(/models/preprocessor.pkl) app.route(/api/v1/load_forecast, methods[POST]) def load_forecast(): req request.get_json() meter_id req[meter_id] start_time req[start_time] forecast predict(meter_id, start_time, model, preprocessor) return jsonify({ code: 0, data: { meter_id: meter_id, start_time: start_time, points: forecast[points], confidence: forecast[confidence], model_version: forecast[model_version] } }) if __name__ __main__: app.run(host0.0.0.0, port8000)实际用 Flask 还是 FastAPI 都行我们选 Flask 是因为团队熟悉部署方便。生产环境用 Gunicorn 起多进程配合 Nginx 反代压测下来单机 QPS 200 以上足够应对园区几十块表同时请求预测的场景。5.4 云端部署与边端部署的选择这套系统根据项目规模和预算有两种部署方式。一种是纯云端部署模型和预测服务全部跑在云服务器上MyEMS 也部署在同一台机器或内网环境。这种方式的好处是运维简单模型更新、监控告警都在同一套体系里完成适合中小型园区预测服务需要的算力不高一台 8 核 16G 的云主机就能满足需求。另一种是云端训练、边端推理的混合架构。云端负责每天凌晨的模型重训和评估训练完成后把模型文件下发到园区本地的边缘网关。边缘网关负责实时推理从本地数采终端获取最新负荷数据生成短时预测结果。这种方式适合对时延敏感或者网络不稳定的场景比如分布式光伏电站、微电网等。虽然我们的项目目前还没走到边端这一步但架构上预留了这个方向。6. 常见问题与排查技巧实录6.1 模型预测值整体偏低症状预测曲线和真实曲线形态接近但整体低 10% 左右。排查思路这种情况往往不是模型结构问题而是数据归一化环节出了差错。检查一下是否用全量数据计算了 Min 和 Max。如果训练时用的是历史数据的最小值和最大值但推理时用的是包含未来数据的全量统计值预测值就会被压低。修正方法很简单写死一个归一化参数文件训练和推理都用同一套参数。还有一个常见原因是负荷本身有增长趋势。工厂产线扩容负荷水平一年内从均值 800kW 涨到 1000kW模型训练数据里的旧数据占大头自然会把预测值拉低。这种情况建议用加权训练策略给近期数据更高的权重。6.2 节假日预测偏差特别大症状预测节假日负荷时比实际高 30% 以上。排查思路如果只有 is_holiday 这个二值特征模型对节假日的学习能力很弱。节假日样本少占比不足全年的 5%模型很难学到节假日的典型负荷模式。我们后来把 is_holiday 换成 holiday_type 枚举特征区分“春节长假”“周末”“法定节日”“调休工作日”等类型。同时把节假日前一天和后一天也作为特殊特征输入因为很多工厂在放假前一天会提前停产放假后一天会逐步恢复。加了这几个特征之后节假日预测 MAPE 从 12% 降到了 6% 左右。6.3 训练 loss 下降缓慢或者震荡症状训练集 loss 下降很慢或者到了某个值就上下震荡。排查思路首先检查输入数据是否已经归一化。如果负荷特征没做归一化LSTM 的梯度计算会非常不稳定。其次检查学习率。初始学习率设成 0.001 一般是安全的如果 loss 震荡把学习率降到 0.0005同时把批次大小从 32 调到 64让梯度方向更稳定。如果训练集 loss 一直在降但验证集 loss 反而上升说明过拟合了。降低 LSTM 隐藏单元数增加 Dropout 比率或者增大训练数据量都能缓解。6.4 MyEMS 数据时间戳不同步导致预测失效症状预测结果的曲线整体右移或左移了若干个 15 分钟点但形状看起来正常。排查思路这个问题隐蔽性很高我们把预测值和实际值对比时发现尖峰出现的时刻总是差一两个点。查到最后是 MyEMS 里记录的时间戳比电表本地时间慢了 15 分钟导致模型学习到的“10 点尖峰”对应实际是“10 点 15 分”。直接修改采集程序里的时区偏移配置重新拉取数据后模型恢复正常。这提醒我们数据链路的时间对齐是整个预测项目的生命线上线前务必用真实数据做一次端到端的时间戳校验。6.5 常见问题速查表问题现象可能原因解决办法预测曲线整体偏低归一化参数不一致统一训练和推理的 Min/Max 参数文件预测值波动大、不平稳输入特征包含过多噪声增加平滑窗口去掉分钟级毛刺节假日预测明显偏高节假日特征表达不足拆分节日类型特征增加节前节后标记验证集 loss 上升模型过拟合增大 Dropout、减小 LSTM 单元数预测结果时间偏移数据时区或采集时序错位检查时区配置校准采集程序时间戳在线推理延迟高模型过大或者并发请求多模型蒸馏、减小特征维度、增加推理实例7. 实操心得与后续扩展方向从最初模型 8% 的 MAPE 优化到稳定 4.5%整个过程我最大的体会是负荷预测项目里算法只占三成数据质量和特征工程占七成。LSTM 本身并不神秘它解决的是“从序列中学习规律”这个问题但规律能不能学出来取决于喂进模型的数据是否干净、特征是否对齐、评估指标是否合理。如果你手头还没有足够的负荷历史数据我给一个保守建议至少积累 6 个月以上、粒度在 15 分钟以内的数据再开始训练。如果只有一两个月的数据大概率会遇到严重的过拟合模型上线后精度波动很大。还有一个很实用的技巧想分享模型重训不一定要每天全量跑更推荐每周跑一次全量训练加每日增量微调。全量训练保证模型对季节性变化的适应能力增量微调让模型能快速响应最近一周的负荷变化。我们在实际项目中把这个策略固化下来后模型长期运行精度几乎没有衰减。语言理解到这里其实已经可以落地一套完整的、可用的负荷预测系统了。从数据清洗、特征工程、模型调参到 MyEMS 集成部署所有的坑和应对策略都在上面了。如果接下来要做扩展可以考虑加入 Transformer 或时序卷积网络做效果对比也可以在预测结果之上叠加优化调度算法这些话题我们以后找机会再单独展开。