简介面向溶解氧浓度时序预测的深度学习项目源自个人期末大作业并获97分含完整可运行源码与全部实验数据适合正在做课程设计或期末作业的计算机相关专业学生也适合希望实战时序预测的进阶学习者。项目覆盖从数据读取到结果评估的训练全流程可作为完整范例参考。压缩包共16个文件由11个Python脚本和5个CSV数据文件构成整体约931KB。脚本覆盖数据预处理、异常检测、模型构建等环节内置LSTM、EMD-LSTM、EEMD-LSTM、EEMD-BP等多种对比方案CSV文件则提供溶解氧与水质观测等真实建模数据。资源目前已有227人浏览学习代码结构清晰、调试充分可直接运行复现完整预测流程。通过比对不同分解策略与模型组合的效果可较快理解时序特征提取、分解降噪与深度学习结合的思路也便于在此基础上改进或二次开发。1. 溶解氧时间序列预测难点不在模型在数据的“脾气”溶解氧DO是水质监测里最敏感的指标之一直接关系到增氧机控制和水华预警。用 Python 做溶解氧时间序列预测网上能搜到的 demo 不少但大多数跑完就废——要么数据是合成的要么预处理代码和模型代码对不上根本没法改成自己的数据集。这份源码不一样的地方在于它把完整链路都给你了从 csv 原始水质记录、异常检测脚本到 LSTM、EMD-LSTM、EEMD-LSTM、EEMD-BP 四种模型以及配套的数据预处理模块。它不是课程 PPT 里的伪代码而是能直接运行、能跑出对比结果的项目源码。适合两类人一类是正在做课程设计或期末大作业的计算机专业学生需要一份有完整数据处理、有模型对比、有产出图表的可复现项目另一类是刚接触深度学习时间序列预测的工程师想在真实水质数据上看看序列分解那一套到底能带来多少提升。2. 先把数据喂对csv 文件对照与预处理脚本的使用很多人在溶解氧预测上翻的第一个跟头不是模型而是数据根本没洗干净。这份源码里塞了一堆 csv如果你不搞清楚它们各自是干什么的很容易拿错文件、跑错数据最后得出一个莫名其妙的结论。2.1 数据集里有什么按用途认文件整个项目的数据文件分三类。第一类是原始水质记录Water Quality Record.csv是主数据文件溶解氧浓度、水温这类字段基本都在里面siwan_wuwan.csv和HQQ.csv从命名看是按监测站或断面拆出来的子集属于同一套字段结构用来验证模型在不同站点上的泛化表现。第二类是加工过的数据Water Quality Record modify.csv是对主文件清洗、排序、补齐后的版本first5000.csv则只取了前 5000 条记录方便你先快速跑通流程不用每次都在全量数据上等半天。第三类是异常检测脚本放在OutlierDetection目录下包含DBSCAN.py、OneClassSVM.py、LOF.py、IF.py四个算法。我的建议是第一次运行先拿first5000.csv试水确认模型能收敛、指标能算出来再切成全量Water Quality Record modify.csv跑正式实验。直接拿全量数据调参一次训练几分钟起调参成本太高完全没有必要。2.2 缺失值与滑动窗口PreProcessing.py 在做什么溶解氧在线监测数据几乎不可能干干净净探头断电会断传、校准时会出现突变的负值、时间戳顺序偶尔还会乱掉。神经网络对输入顺序极其敏感所以预处理的第一步一定是时间排序和缺失处理。import pandas as pd import numpy as np df pd.read_csv(Water Quality Record modify.csv) df[timestamp] pd.to_datetime(df[timestamp]) df df.sort_values(timestamp).reset_index(dropTrue) # 物理范围过滤DO 不可能为负也不该超过 20 mg/L df df[(df[DO] 0) (df[DO] 20)] # 线性插值补缺失首尾也补limit_directionboth df[DO] df[DO].interpolate(methodlinear, limit_directionboth) # 滑动均值平滑抹平传感器瞬时抖动 df[DO] df[DO].rolling(window5, min_periods1).mean()这里rolling(window5)是个取巧但常用的做法它等价于把最近 5 个采样点的值做平均。对 DO 这种探头噪声明显的指标平滑能显著提升后续序列分解的稳定性。但你要记住一个副作用平滑会让突变点被拉平、峰值滞后。如果后面要做异常检测最好用平滑前的数据否则跳水式的溶解氧骤降会被抹成一串普通波动异常检测等于白做。数据洗完之后下一步就是生成训练样本。LSTM 不能吃一整条序列它需要窗口化的样本用过去 N 个时刻预测未来 M 个时刻。def make_dataset(data, window_size24, horizon6): X, y [], [] for i in range(len(data) - window_size - horizon 1): X.append(data[i:i window_size]) y.append(data[i window_size:i window_size horizon, 0]) return np.array(X), np.array(y)window_size是回看窗口horizon是预测步长。窗口 24、预测 6 的含义是用过去 24 个采样点预测未来 6 个采样点。如果数据是小时级的这就相当于看过去一天、预测未来六小时对增氧决策是合理的节奏如果你手上的数据是分钟级窗口建议往上加到 72 到 168不然模型根本看不全日周期波动。这里没有玄学多试几组选验证集损失最低的窗口即可。2.3 异常检测脚本什么时候用用哪个OutlierDetection目录下的四个文件对应四种异常检测思路DBSCAN.py是基于密度的聚类不需要预设簇个数适合发现形状不规则的数据团LOF.py是局部离群因子擅长捕捉局部密度差异大的点IF.py是孤立森林用随机切分的方式快速隔离异常点特征维度不高时速度很快OneClassSVM.py是学习一个紧凑边界把边界外的点判为异常。老实说对溶解氧预测而言异常检测不是必须步骤。它的价值在于当你发现模型在某个时间段预测误差特别大回头查原始数据往往是那几天探头出了问题数据本身是脏的。这种情况下用LOF.py或IF.py对差分后的序列做检测找出那些明显偏离相邻时刻的点把它们替换成插值比直接删掉整段数据更稳妥。3. EEMD 分解原理与代码为什么分解后 LSTM 更容易学如果你直接把原始溶解氧序列丢给 LSTM会发现模型老是学到一半就卡住loss 降到一定程度不再动弹。这不是网络结构的问题而是溶解氧序列本身太“拧巴”了。3.1 非平稳序列与模态混叠EMD 不够EEMD 来凑溶解氧受水温、光照、增氧机启停共同作用信号是趋势、周期性波动和局部突变的叠加。LSTM 虽然有记忆能力但要同时拟合这些频率差异极大的成分需要很深的网络和大量的数据。经验做法是先用经验模态分解把原始序列拆开分解出来的每个 IMF 分量只包含一个主要波动尺度模型学起来容易得多。但 EMD 有一个著名的毛病叫模态混叠——某个 IMF 里一会儿是高频抖动一会儿又冒出低频趋势分不干净。EEMD 的解决方式很暴力给原始序列反复加白噪声再分解然后对多次结果取平均。噪声会均匀填充整个频谱把不同尺度的信号“挤”到各自该去的 IMF 里平均之后噪声互相抵消混叠就明显减少了。3.2 分解脚本用法eemd.py 的参数与输出怎么接from PyEMD import EEMD import numpy as np eemd EEMD(trials200, noise_width0.05) imfs eemd.eemd(do.flatten()) n_imfs imfs.shape[0]trials是分解次数200 是常见配置低于 100 时平均效应不足分解结果抖动大。noise_width是白噪声幅度0.05 意味着噪声标准差是原始序列标准差的 5%。这个参数太大会把真实信号冲散太小又压不住模态混叠我一般从 0.05 起步看 IMF 的波形是否光滑、有没有明显跳变再决定往上还是往下调。跑完之后imfs是一个二维数组每一行是一个 IMF最后一行是残差趋势项。所有 IMF 和原始序列长度一致这一点很重要它决定了后面窗口切分时能一一对齐。如果某天你发现某个 IMF 的长度和原始序列不一致大概率是 EEMD 在序列两端做了特殊的边界处理这时统一裁剪到最短长度再进模型别硬撑。3.3 分解-预测-重构数据怎么进结果怎么拼回来流程分成四步先对原始溶解氧序列做 EEMD得到若干 IMF然后对每个 IMF 单独做窗口化、单独训练一个 LSTM接着用训练好的模型预测未来一段各 IMF 的值最后把所有 IMF 的预测结果逐点相加得到最终的溶解氧预测值。每个 IMF 都建一个模型听起来笨但这是这类任务的主流做法。因为各 IMF 的动态范围差别很大第一个 IMF 可能是幅值 0.1 的高频抖动残差项可能是幅值 5 的趋势放同一个模型里反而互相牵制。分开训练之后唯一要操心的就是重构时的拼接逻辑。pred_imfs [] for i in range(n_imfs): imf_data imfs[i].reshape(-1, 1) X_i, y_i make_dataset(imf_data, window, horizon) # 每个 IMF 单独建一个 LSTM训练完分别预测 model build_lstm(window, X_i.shape[-1]) model.fit(X_i, y_i, epochs80, batch_size32, validation_split0.1, verbose0) pred model.predict(X_test_i) pred_imfs.append(pred.reshape(-1)) total_pred np.sum(pred_imfs, axis0)这里total_pred就是最终预测结果。需要注意如果每个 IMF 在训练前都单独做了归一化预测完要先各自反归一化再相加。顺序反了叠出来的结果会差出好几倍这个坑在第五章单独展开。4. 三种模型逐一跑通LSTM、EMD-LSTM 与 EEMD-LSTM 的参数怎么调源码里的三个核心训练脚本LSTM.py、EMD-LSTM.py、EEMD-LSTM.py正好对应三条递进路线先跑基线再叠加分解最后换更稳的分解方式。理解了这三者的差异你就能看明白整份源码的对比逻辑。4.1 LSTM.py基线模型的长相基线模型用两层 LSTM 加一层全连接这是时间序列预测里最稳的搭配。第一层 LSTM 设置return_sequencesTrue是为了把每个时间步的隐藏状态都传给第二层 LSTM让第二层能继续提炼时序特征。Dropout 放在两层 LSTM 之间专门抑制过拟合。model tf.keras.Sequential([ tf.keras.layers.LSTM(64, return_sequencesTrue, input_shape(window, X.shape[-1])), tf.keras.layers.Dropout(0.2), tf.keras.layers.LSTM(32), tf.keras.layers.Dense(horizon) ]) model.compile(optimizeradam, lossmse)input_shape里的window要和预处理时的回看窗口一致X.shape[-1]是特征数。如果只用溶解氧单变量特征数就是 1如果把水温、pH 也拼进来这里会变成对应维数。Dense(horizon)的输出维度等于预测步长这个设计意味着模型一次直接输出未来horizon个时刻的预测值而不是只输出下一个点再滚动预测。关于loss官方偏好用mse因为它对大的预测误差敏感。但实际调试时我经常先切到mae跑几十个 epoch等曲线稳定了再换回mse做最终训练这样不容易被前几个 epoch 的大梯度带偏。4.2 EMD-LSTM.py 与 EEMD-LSTM.py拆开学再拼回去这两个脚本的结构一样差别只在分解方式一个用 EMD一个用 EEMD。它们做的事情是对原始序列分解后对每个 IMF 分别调用和基线一样的 LSTM 结构最后把预测结果相加。核心逻辑就是第三章代码里那个循环。EEMD_BP.py就更直白了它把每个 IMF 的预测模型从 LSTM 换成简单的 BP 网络。这个文件的意义不在精度而在于给你一个额外的对比维度同样的分解不同的回归模型效果差多少。如果你课程设计的实验部分需要多个对照模型EEMD_BP.py就是现成的素材。4.3 超参怎么定窗口、神经元、epoch 从哪开始调源码能直接跑但跑出来的数字好不好看取决于你怎么调参。我的习惯是先用一组保守参数跑通全流程窗口 24、神经元第一层 64 第二层 32、epoch 100、batch_size 32。跑通后看验证集 loss 曲线再针对性调整。如果训练 loss 和验证 loss 都高说明欠拟合加大神经元到 128/64或者把window拉长。如果训练 loss 低、验证 loss 高说明过拟合加大Dropout到 0.3 以上并加EarlyStopping。如果前几个 epoch 的 loss 震荡剧烈把batch_size调大一些梯度会稳很多。另外提醒一句validation_split0.1是从训练集尾部切 10% 当验证集。对时间序列来说这没问题但千万别用train_test_split随机打乱切分——那会把未来信息泄漏给训练过程验证集指标虚高实盘预测一塌糊涂。5. 溶解氧预测常见问题排查五个让人反复翻车的点这章写的都是我实际跑类似项目时踩过的坑每条都按“现象 → 原因 → 解决”来拆你可以直接对照排查。5.1 数据泄漏的归一化验证集指标虚高的元凶现象训练集 loss 和验证集 loss 都低得漂亮但把模型拿去预测新数据曲线完全对不上。原因归一化时用了全样本的均值和方差。比如scaler.fit()在完整序列上执行再切训练集和测试集测试集的分布信息已经偷跑进 scaler 里了。解决必须先切分再对训练集fit然后用训练集的均值和方差去transform测试集。from sklearn.preprocessing import MinMaxScaler scaler MinMaxScaler() train_scaled scaler.fit_transform(train_raw) # 先在训练集上拟合 test_scaled scaler.transform(test_raw) # 测试集只变换不拟合5.2 反归一化错位预测值变成一条平线现象预测曲线前段还行后段直接拉平像一条直线。原因如果用标准化的scaler基于原始序列做归一化那么模型预测出来的值是在 0~1 的缩放空间里的必须用同一个 scaler 反变换回原始量纲。很多人做了 EEMD 分解后对每个 IMF 分别归一化预测完却用原始序列的 scaler 去反归一化量纲全乱了。解决按 IMF 的粒度反归一化——每个 IMF 用什么 scaler 归一化的就用什么 scaler 反变换全部反完再相加。5.3 EEMD 边缘效应序列两端预测值飘掉现象整体预测不错但前几十个点和最后几十个点误差特别大。原因EEMD 分解在序列两端的信息不完整白噪声在边界处没有足够的邻居来平均导致 IMF 端点出现摆动。窗口滑动到边界时模型正好学到这些畸变片段。解决训练前把序列两端各裁掉一定比例比如 5%评估指标只在中间区间计算。这是这类坑少有的“物理级”解决办法改参数改不出来。5.4 过拟合与早停epoch 不是越多越好现象训练 loss 一直降验证 loss 降到一个点后开始回升但你盯着训练 loss 觉得还能再跑。原因模型开始背训练集的噪声细节泛化能力反而下降。时间序列模型尤其容易这样因为相邻样本高度相似模型会抓住一些不该学的“巧合”。解决加上EarlyStopping盯着验证 loss连续patience10个 epoch 不下降就停。early_stop tf.keras.callbacks.EarlyStopping( monitorval_loss, patience10, restore_best_weightsTrue )restore_best_weightsTrue是后悔药一旦早停触发自动把权重回滚到验证集最优的那个 epoch。强烈建议加上这行不然后面还得手动重训一次。5.5 评估指标只看 RMSE 会看走眼现象RMSE 看起来不大但画图发现峰值处全没预测准。原因RMSE 对极端误差的惩罚是平方级的几个大误差点能把整体指标拉上去掩盖大部分时段的良好表现。溶解氧骤降往往是突发事件预测模型在平稳段表现好、突变段表现差只报一个 RMSE 等于把关键信息丢了。解决同时看三个指标。RMSE 看整体误差量级MAE 看平均误差R² 看模型相对均值基线提升了多少再对应画一张预测 vs 真实值的曲线目测峰值跟随情况。R² 如果低于 0.6说明模型还没学会序列的基本趋势先别调参回头查预处理。6. 把这份源码迁移到自己的数据集上三处最小改动源码跑通了真正值钱的是把它换成你自己的水质数据。我试过从零写一套也试过在这类源码上改后者省的时间是前者的好几倍。迁移的核心是只改三处其余逻辑全部保留。第一处是读文件路径把pd.read_csv()指向你的 csv。第二处是目标列名源码里写死了df[DO]如果你的数据里溶解氧叫Dissolved_Oxygen全局搜DO替换即可注意别把hdo这类子串也误换。第三处是时间戳字段如果原始数据的日期列不是标准格式pd.to_datetime()会报错常见做法是加一个format参数比如df[time] pd.to_datetime(df[time], format%Y/%m/%d %H:%M)。验证迁移是否成功的套路也很固定先把LSTM.py跑通确认训练和验证 loss 都在下降然后看测试集上 RMSE 的量级。溶解氧浓度通常在 0 到 15 mg/L 之间波动如果 RMSE 在 0.5 以下说明模型已经抓住了主要趋势。在这个前提下再开EEMD-LSTM.py做对比看分解是否真的带来提升。如果基线 RMSE 都 2 以上别急着上分解先检查数据是否有缺失和异常。从那以后我每次拿到新的水质数据都会强制自己走一遍这个最小验证流程先跑通基线再上分解对比最后才谈调参。这套方法帮我过滤掉了很多“数据看着没问题、一跑就翻车”的情况。希望帮到你。本文还有配套的精品资源点击获取