基于LSTM预测控制的地源热泵系统能耗优化实践

做建筑能源管理的朋友应该都有同感——真正难的不是把设备装好，而是怎么让它常年保持高效运行。地源热泵（GSHP）系统就是个典型例子，光看设计工况，COP随便四五，但实际项目跑起来，很多系统一年的平均综合能效连2.5都不到。问题出在哪？绝大部分出在控制策略上。大多数项目的机组启停、出水温度设定都是靠人工经验或者固定时间表，负荷变化跟不上的时候，要么房间过冷，要么白白耗电，地埋管侧的换热也不均衡，时间一长系统性能只会越来越差。

这个项目做的就是一件很直接的事：用长短期记忆网络（LSTM）对建筑未来几小时的冷热负荷做预测，再把预测结果接到地源热泵机组的启停和出水温度控制逻辑里，形成一套数据驱动的预测控制系统。整套代码用MATLAB实现，包括数据预处理、LSTM模型训练、负荷预测、控制决策四个核心模块，在一栋以地源热泵为主要冷热源的办公楼场景中做了仿真对比，效果挺明显：在满足室内舒适度的前提下，整体能耗比原来的时间表控制降低了约20%。

如果你也在做建筑能耗优化、暖通自动控制，或者只是想知道深度学习模型到底怎么落地到实际工控场景，这篇文章值得往下看。我会把从数据采集、模型训练到控制策略实现的完整链路都拆开讲一遍，包括踩过的坑。

1. 项目整体：为什么要做一个数据驱动的GSHP预测控制

1.1 传统控制方式到底差在哪

先说结论：传统控制不是不能用，而是“反应太慢、动作太粗”。最常见的做法有两种，一种是定时间表控制，比如每天早上8点开主机，下午6点关主机，冷冻水供水温度全年固定设7℃；另一种是回水温度上下限控制，温度高了就加机，低了就减机。

第一种的问题在于完全不看负荷。夏天太阳暴晒最厉害的时候负荷最大，但人还没上班，机组却在凌晨以最低负荷空转；傍晚负荷其实还很高，但时间表已经让机组降载，导致室内温度慢慢攀升，等运维人员第二天来看数据才发现昨天傍晚室内温度飙到了28℃。

第二种比第一种稍微聪明一点，但本质上还是纯反馈控制，而且滞后很严重。建筑本身是一个巨大的热容体，混凝土楼板、墙体、家具都在吸收和释放热量，从机组改变出力到室内温度变化，往往要滞后半小时到一小时。等回水温度超限了再响应，环境早就变了。打个比方，这就像开车只看前车尾灯刹车，等看到尾灯再踩刹车，反应总是慢半拍。

1.2 数据驱动方案的价值在哪里

数据驱动方案的核心变化是：把“事后响应”变成“事前预判”。既然我们有建筑的历史运行数据、气象预报数据、电价数据、室内外温度数据，那完全可以用深度学习模型把这些数据中的规律提取出来，预测未来6到24小时的负荷曲线。有了这条预测曲线，控制系统就可以提前做决策：未来两小时后负荷要上来，现在就提前开一台机组，让地源侧的温度场先稳定下来；未来三个小时负荷会下去，主机可以提前降频，而不是等回水温度超标了再折腾。

我做这个项目时，最开始也考虑过用传统物理建模方式——建立建筑的传热微分方程、机组模型、地埋管模型，然后做模型预测控制（MPC）。但最后放弃了，原因很简单：建筑实测下来的热工参数和设计图纸差得太多，一个12000平米的办公楼，简化成几个集中参数的RC模型，校准就要花掉大量时间，而且建筑实际使用模式一变（比如某个区域改成了24小时机房），模型就得重新标定。

LSTM这条路的吸引力在于：它不需要我们手动建立传热模型，只要历史数据足够丰富，网络会自己学到“室外温度升高+太阳辐射增强+工作时间开始→冷负荷上升”这类隐含规律。数据驱动不是万能的，但在这个场景下，它的性价比确实比传统物理建模高很多。

提示：LSTM能做的是预测，不是直接控制。最终的控制决策还是要有一套规则或优化算法来承接，这一点后面第5节会细说。

2. GSHP系统与预测控制的底层逻辑

2.1 地源热泵系统的工作特点

地源热泵的原理这里简单带过：通过埋在地下的地埋管换热器，夏季把建筑里的热量“搬到”地下，冬季把地下的热量“搬到”建筑里。因为地下10米以下的温度常年恒定在15到18℃左右，所以地源热泵的换热效率天然比空气源热泵高，理论上COP能做到4以上。

但有个工程上很头疼的特点：地埋管侧的热响应时间很长。地埋管周围土壤的温度场一旦发生变化，恢复很慢。如果控制策略不合理，夏季连续几天把热量灌进地下某个区域，那个区域的土壤温度会慢慢升高，导致机组冷凝温度上升，COP直线下降。这个问题，靠“看回水温度再动作”的反馈控制根本解决不了，必须提前规划地埋管侧的负荷分配。

LSTM预测在这个场景下还有一个额外用处：不光预测建筑负荷，还可以根据预测结果，提前在多个地埋管分区之间做切换，让不同分区的土壤温度有恢复时间。这个操作在项目里属于偏进阶的玩法，但前提都是负荷预测得准。

2.2 预测控制为什么适配建筑温控

模型预测控制（MPC）的框架可以用三步概括：预测未来、滚动优化、反馈校正。标准MPC比较依赖精确的数学模型，但在建筑这个场景里，“模型”是通过LSTM学出来的黑箱，这其实就给传统MPC换了一个新的引擎。

具体到控制周期，我的做法是这样的：每隔15分钟滚动一次，LSTM基于过去48小时的数据，预测未来12小时的冷负荷。控制决策层把未来12小时分成若干个时间段，结合电价、机组台数、出水温度设定范围，算出一个未来12小时的总能耗最小化方案，但只执行第一个时间段（比如半小时）的动作。到下一个15分钟周期，用最新的实测数据重新预测、重新优化。这就是典型的滚动优化。

为什么这套逻辑特别适配建筑温控？因为建筑负荷的“惯性”和“可预测性”同时存在。一方面，建筑热容大，负荷曲线平滑，不像工厂设备那样瞬间跳变，所以预测的置信度比较高；另一方面，早晚高峰、工作日/休息日、太阳辐射变化这些因素都有明显的周期性规律，LSTM这种序列模型能把周期模式学得很好。两者叠加，预测控制的收益就非常可观。

3. 数据准备：哪些数据最关键，怎么处理才能喂给LSTM

3.1 特征选择比模型结构更容易决定成败

很多人一上来就调LSTM的隐藏单元数，但其实在这个项目里，我花时间最多的不是调网络结构，而是数据清洗和特征选择。LSTM不是魔法，垃圾进去垃圾出来。

我当时用到的核心特征分成四类：气象类、建筑运行类、系统运行类、时间特征类。整张表大概是这样：

有个比较容易忽略的是节假日。中国建筑的使用习惯里，法定节假日和普通休息日的负荷差别非常大，尤其是春节前后那一个月，整个楼可能只有20%的人在使用。我第一版模型在春节那段时间预测误差特别大，后来在特征里加入了一个“节假日距离因子”——当前日期离最近法定节假日的天数，这个问题才缓解。

3.2 数据清洗与归一化的几个细节

建筑运行数据脏得惊人。我遇到过凌晨某个数据采集器断线，早上发现从0点到7点室外温度全是NaN；也遇到过传感器漂移，冷冻水供水温度读数一整天都在波动，但实际机组根本没启动。事前不处理，训练出来的模型就是废的。

我整理了一套自己惯用的清洗流程，供你参考：

1. 缺失值处理：连续缺失不超过2小时，用前后线性插值；超过2小时，直接丢弃该段连续数据，不要硬补。
2. 异常值剔除：对每个特征做3σ检测，但要注意室内温度在开关门时会有瞬时跳动，这种不应该当异常值剔除，需要配合机组状态判断。
3. 准确性校验：把冷冻水流量和供回水温差算出的冷量，和机组电表的耗电量做交叉比对。两者相关性异常偏低，说明流量计或温度传感器有问题，优先修数据而不是喂给模型。
4. 归一化：所有连续特征做z-score标准化，即减去均值除以标准差。这里有个特别容易踩的坑——标准化参数必须在训练集上计算，再应用到验证集和测试集，不能拿全序列的均值和标准差去标准化，否则就是数据泄漏。

关于数据泄漏多说一句：我最早写代码时图省事，把整条序列一次性计算均值和标准差，然后统一标准化，结果模型验证指标好得吓人，RMSE只有正常情况的1/5，后来发现是标准化参数用了未来数据的信息。训练时看着完美，上到真实环境彻底露馅。这个一定要引以为戒。

3.3 时间序列的样本切分方式

普通机器学习做训练集/测试集划分，往往是随机打乱，但在时间序列上绝对不行。建筑负荷有强自相关性，8月的数据和12月的数据的分布完全不同，如果随机划分，模型实际上是在“作弊”——它的训练集里包含了未来数据的信息，验证集分数虚高。

我的做法是把整个数据集按时间顺序切成三段：前70%训练，中间15%验证，最后15%测试。测试集必须是模型从未见过的最新时段数据。具体到这个项目，我用的是某办公楼前一年10月到次年9月的完整运行数据，训练集是10月到6月中旬，验证集是6月中旬到7月底，测试集是8月到9月——正好包含了一整个夏天的完整工况。

4. LSTM建模与MATLAB实现步骤

4.1 网络结构的取舍

LSTM结构在MATLAB里实现起来很简洁。我的基本结构是：序列输入层 → LSTM层 → 全连接层 → 回归输出层。有人会加两层LSTM，或者加Dropout，但在这个项目里，单层LSTM加128个隐藏单元就已经够了，再深收益非常有限，训练时间却成倍增加。

关于时间窗口的长度，我做过一组对比实验。用过去24小时预测未来1小时，RMSE大概是2.6%；过去48小时预测未来1小时，RMSE降到2.1%；但拉到72小时，RMSE反而升到2.3%。原因是窗口过长引入了太多早期、与当前工况相关性不大的历史信息，网络学到了噪声。所以最终我选的是48小时窗口。

输出长度的选择也很关键。单步预测（预测未来1小时）最简单，但控制决策需要的是未来12小时的负荷趋势。两种做法：一种是直接多输出，让网络输出未来12个值；另一种是递归预测，把预测值当成输入滚动往后推。我测试下来，直接多输出在12小时尺度上明显更稳，递归预测的误差会随时间步长累积，到第8个小时以后基本不可用。

4.2 可直接套用的MATLAB训练框架

先解释一下整个项目的代码组织，我习惯拆成四个脚本：load_data.m负责读数据、清洗、切分；prepare_sequences.m负责构造LSTM的输入输出序列；train_lstm.m负责定义网络、训练、保存模型；predict_control.m负责加载模型、滚动预测、执行控制决策。

下面这段是prepare_sequences.m的核心逻辑，用滑窗法把原始时间序列转成训练样本：

% 输入: data 是标准化后的特征矩阵, 每行一个时刻, 每列一个特征 % 输出: XTrain (cell数组), YTrain, XVAL, YVAL, ... numTimeSteps = 48; % 用过去48个时刻(12小时)预测 numFeatures = size(data, 2); numSamples = size(data, 1) - numTimeSteps - horizon; for i = 1:numSamples XTrain{i} = data(i:i+numTimeSteps-1, :)'; % 每个样本是 numFeatures x numTimeSteps YTrain(i) = data(i+numTimeSteps+horizon-1, 1); % 假设第1列是负荷 end

注意MATLAB的trainNetwork对LSTM输入格式有要求：每个样本是一个二维矩阵，维度是“特征数×时间步数”，所有样本放在一个cell数组里。我第一次用的时候把维度搞反了，卡了半天才反应过来。

网络定义和训练的部分：

% train_lstm.m numFeatures = 8; % 选了8个核心特征 numHiddenUnits = 128; numResponses = 1; layers = [ sequenceInputLayer(numFeatures) lstmLayer(numHiddenUnits, 'OutputMode', 'last') fullyConnectedLayer(32) reluLayer fullyConnectedLayer(numResponses) regressionLayer]; options = trainingOptions('adam', ... 'MaxEpochs', 120, ... 'MiniBatchSize', 32, ... 'InitialLearnRate', 0.005, ... 'LearnRateSchedule', 'piecewise', ... 'LearnRateDropPeriod', 40, ... 'LearnRateDropFactor', 0.3, ... 'ValidationData', {XVal, YVal}, ... 'ValidationFrequency', 20, ... 'Shuffle', 'never', ... 'Plots', 'training-progress', ... 'Verbose', true);

Shuffle那里需要特别说明一下。时间序列训练时，每个样本仍然是从原始序列上连续截取的，如果每个epoch都随机打乱样本顺序，虽然大多数情况下能收敛，但我在实验中发现，对于强自相关的负荷序列，关闭打乱、保持序列内顺序，验证集的RMSE反而更稳定。这个见仁见智，你可以根据自己的数据特点试。

4.3 训练选项与调参心得

这里有几个参数是我反复调过的，直接说结论：

• 学习率：0.005起步是合理的。我用过0.01，训练到40个epoch左右损失函数开始震荡，降下来以后模型不收敛，最后只能回退。0.005配合每40个epoch衰减0.3，120个epoch练完，验证集RMSE平缓下降。
• MiniBatchSize：32和64我都试过，32收敛更快但噪声大，64稳定但每个epoch时间更长。数据量不大（几千个样本）的时候，32是更稳妥的选择。
• MaxEpochs：120个epoch足够。更多epoch会导致过拟合，验证集损失开始回升。判断标准很简单——“验证集平稳，训练集继续下降”就是过拟合的前兆。
• 隐藏单元数：64、128、256三个档位试过，128在误差和训练时间之间平衡最好。256虽然能把训练集拟合得更好，但验证集上的提升不到10%，训练时间却翻了将近3倍。

数据量是这个项目的一个现实约束。我用的是约一年历史数据，按48小时窗口切出来大概有7000多个样本，这个量级下LSTM的表现已经不错。如果你的项目数据只有几个月，我建议降低隐藏单元到64，同时把窗口缩到24小时，否则很容易过拟合。

还有一个经验：把机组启停状态这个特征加进输入后，模型的短期预测精度有很明显的提升，但长期预测反而变差。原因很好理解——启停状态是控制决策的结果，属于内生变量，预测未来12小时时我们并不知道未来的停机状态，模型只能沿用当前的0或1，一旦实际控制策略变化，预测就会偏。最后我的妥协是：训练时保留这个特征，但预测时把它平滑成概率值（比如以这个时刻启动的概率来输入），效果比纯0/1输入好不少。

5. 预测控制策略落地：从预测到决策

5.1 控制决策规则设计

预测模型训练好以后，怎么把它变成实际控制指令，是另一个值得花心思的地方。我没有一开始就上复杂的优化算法，而是先用了一套“预测 + 规则”的渐进式方案，后面再对比效果。

首先是机组启停逻辑。原来纯时间表控制是8点开机、18点关机。用上规划后，逻辑改成了这样：

if predictedLoad(t+1) > threshold_start 开机 elseif predictedLoad(t+1) < threshold_stop AND 当前温度已满足 停机 end

阈值怎么定？我是用历史负荷的百分位数来标定的。比如取过去一个月同时刻负荷的P70作为启动阈值，P40作为停止阈值。用滞回线避免机组频繁启停——启动阈值比停止阈值高，这样既能保证负荷上升时机组已经准备好，又不会在负荷波动时反复折腾压缩机。

其次是出水温度设定值的优化。地源热泵机组的COP和冷冻水出水温度密切相关，出水温度越高，压缩比越小，COP越高。传统控制为了保证极端工况下能降温，往往把出水温度全年固定在7℃。而当我有了未来负荷的预测值以后，就可以做这样一个调整：预测负荷低时，把出水温度抬高到10℃甚至12℃，机组COP能提升15%左右；预测负荷高时，再把出水温度降回7℃，预留足够换热余量。

这段决策逻辑在MATLAB里可以写成很直观的代码：

% predict_control.m 核心决策片段 predictedLoad = predict(net, currentSequence); nextHourLoad = predictedLoad(1); % 出水温度设定值 = f(预测负荷) if nextHourLoad < lowLoadThreshold supplyTempSetpoint = 12; elseif nextHourLoad < highLoadThreshold supplyTempSetpoint = 10; else supplyTempSetpoint = 7; end % 机组启停滞回控制 if nextHourLoad > startThreshold && ~currentStatus equipmentCmd = 'startup'; elseif nextHourLoad < stopThreshold && currentStatus equipmentCmd = 'shutdown'; else equipmentCmd = 'keep'; end

实际上，更精细的做法是做一个带电价信息的优化：电价高峰时段尽量不启动主机，靠建筑热容蓄冷；低谷时段提前把机组开起来，一边蓄冷一边利用更低的电价。我最初用的是电价分时表做离线优化，后来发现电价信号本身也充满不确定性，规则化处理反而更落地方便，所以项目最终落地时把电价因素也作为规则输入的权重项，而不是做动态规划。

5.2 与常规控制的对比评测

评价这套方案到底值不值，光看节能率是不够的。室内舒适度必须作为硬指标来卡，否则单纯压能耗，把房间里的人冻得发抖或热得冒汗，没有任何意义。

我这一版项目的对比评价分成两个部分：仿真回放和现场实测。仿真回放是把历史数据离线跑一遍新控制逻辑，看看它会给出什么指令，再和当时实际的控制指令比。现场实测则是在机组控制允许的条件下，把系统切到预测控制模式运行两周，和之前两周的基线数据做对比。

最终的对比结果是这样的（数据做了模糊化处理，趋势是准的）：

系统能稳定节能，核心是两件事同时作用：出水温度的季节性浮动，以及机组启停次数的大幅下降。固定启停很伤能效——每次重启都要经历电流爬升和部分负荷运行，这部分损耗在机组频繁启停的站点里，粗略估算能占到制冷季总能耗的8%到12%。

6. 实操中踩过的坑与排查技巧

6.1 预测漂移问题

LSTM模型在训练集上的表现和上线后实际运行的表现往往会有一个落差，最典型的就是预测漂移。模型是拿去年数据训练的，但建筑的使用模式在今年发生了变化——比如新增了一个数据机房，全年冷负荷增加了15%，模型还在按去年的水平预测，结果就是持续偏低。

我在这个项目里踩过一串跟漂移相关的坑。最开始运行时，预测值跟实际值在凌晨时段比较准，但到了午后太阳辐射强的时候，预测值总是偏低0.5到1℃的负荷水平。后来排查发现是训练数据里夏季样本不足，模型对极端高温天气的泛化能力不够。解决办法是给训练数据按气象条件加权，把高温时段的样本在损失函数里赋予更高权重，等于变相做数据增强。

再就是滚动更新的问题。模型上线后不能一直用初始模型，我后来做了一个简单粗暴的“每周自动重训”机制：每周日凌晨用过去12个月最近的数据重新训练一次模型，然后自动验证并替换。这样模型永远徘徊在新数据附近，漂移不会积累。

6.2 训练/测试数据划分的陷阱

前面提过数据泄漏，这里扩展一下具体场景。有同事问我为什么他的LSTM验证集RMSE能做到0.5%以内，我一问，他说把数据全都混在一起标准化了，我当时就说这个肯定不对。还有一种更隐蔽的泄漏：如果你用未来时刻的负荷数据做了任何形式的滑动平均（比如用未来24小时的平均值去补某个缺失点），这也会把未来信息渗入到训练样本里。

判断有没有泄漏，有个经验可以分享：训练集误差和验证集误差差得越小越可疑，真实的时间序列预测，验证集误差通常比训练集高30%以上。如果你的验证集误差和训练集几乎一样，先回头检查数据切分和预处理。

6.3 实时部署的延迟问题

MATLAB训练好的网络模型部署到实时控制环境，涉及响应速度的问题。LSTM推理本身在单步预测下是毫秒级的，完全够用。但如果你像我一样需要预测未来12小时，直接多输出的计算量会大不少。

我在现场实用了两种部署方式：一种是MATLAB Compiler打包成独立的可执行程序，通过OPC UA与楼宇自控系统（BA系统）通信，这种方式延迟在几十毫秒，完全满足15分钟控制周期的要求；另一种是用MATLAB Coder把LSTM网络导出成C++代码，嵌入到控制箱的工控机上跑，响应更快，但开发调试周期长。如果只是做仿真验证，第一种方式足够了。

还有一点实际经验：控制系统的判断周期是15分钟，但现场传感器的采样周期是1分钟，中间存在时间对齐问题。一定要在控制决策前做时间戳对齐，否则模型输入的实际是脏数据。我遇到过两次，一次是BA系统重装后时间轴错位，一次是数据采集器时区设置错误导致整体偏移8小时，这两次都让预测值在上午时段的误差暴涨，排查了整整一天。

6.4 哪些地方别硬上深度学习

最后说点泼冷水的话。我现在不会再推荐对每个建筑项目都上LSTM预测控制。如果建筑本身负荷很小（比如几千平米的独栋），或者历史数据连半年都没有，LSTM的价值就非常有限。这种情况下，一个简单的2阶RC模型加上基础的负荷率平滑，效果可能更好、成本更低。

如果你现在的系统已经有比较完整的历史数据和BA系统，那么可以按这套流程走一遍：先做负荷预测的可行性评估（预测误差是否小于10%），再做规则式预测控制（不需要优化器，仅仅基于预测值调整启停和设定值），最后才是带优化目标和约束的完整MPC。每一步都能看到成效，也可以随时停下来。

注意：预测控制方案上线前，一定确认机组控制接口支持改写设定值和远程启停，而且要加上“预测失效回退策略”——比如当LSTM接口连续10分钟没有数据，或预测结果超出合理范围时，系统要自动回退到原有的时间表控制，保证建筑不至于失控。

结尾

最后分享一点个人体会。这个项目做完，我的感受是：LSTM本身不是什么神秘的东西，它在你手上能不能发挥作用，关键在于你有没有把数据管好、把控制场景想清楚。数据质量决定模型上限，这句话在这个项目里得到过特别充分的验证——我第一次跑出来的模型在测试集上RMSE是4.7%，听起来不差，但放到预测控制里就是不实用，因为预测偏差集中在午后负荷峰值时段，而恰恰是那个时段的误差会带来控制误判。后来我把重点放在特征工程和异常数据处理上，RMSE降到了2.1%，控制效果一下子就不一样了。

我还在持续改进这套系统，目前的方向是加入动态电价信号，在分时电价和实时电价场景下做冷量蓄放优化；以及在多个地埋管分区之间做预测性的切换控制，让土壤温度场恢复得更均衡。如果你也在做类似的东西，欢迎从这篇文章里的数据结构开始搭一版，先把预测模块跑通，后面加控制决策就是水到渠成的事。