简介一套基于深度学习的油井生产动态预测源码面向石油行业数据工程师与算法研究人员解决采油生产数据时序建模与多模型效果对比问题。项目基于PyTorch与Optuna融合CNN、RNN、LSTM、Self-Attention和Seq2Seq五种模型覆盖特征提取、长短期依赖建模、注意力机制及序列映射并提供超参数自动调优与可视化评估可复用于油气生产预测、工业时序分析等场景。资源包共232个文件、9.1MB含58个Python脚本、7个Notebook、14个模型权重、41个文本说明、6个CSV数据集及86张结果图从数据处理、模型训练到误差对比均有完整落盘辅助的YAML环境配置与Markdown说明也便于快速复现。已有134人学习下载适合希望系统掌握深度时序建模并快速搭建油井预测实验的开发者可直接基于原始生产数据展开训练与调优。1. 为什么油井生产动态预测值得用深度学习重做一遍油井生产动态预测不是新概念采油厂一直用递减曲线、Arps公式和物质平衡方程在做。但现场数据越积越多井况越来越复杂稠油热采、注水驱、间抽制度这些场景下递减曲线经常算不准。深度学习的价值在于能直接吃多维时序特征——油压、套压、动液面、含水率、产液量历史——把“这口井接下来30天能产多少”这个问题变成一个有监督的序列预测任务。今天聊的这套“基于深度学习的油井生产动态预测源码”核心就是围绕这个任务组织的数据管线、模型骨架和训练调参经验。这套方案适合谁一类是采油厂或油服公司的数据工程师手上有一堆历史生产报表想用深度学习做产量预测或措施效果对比另一类是课题组的算法同学拿公开的油气田数据集做毕设或横向课题。无论哪一类能跑通源码只是第一步真正有价值的是知道数据怎么清洗、网络怎么选、预测结果怎么被现场采油工程师认可。下面从数据准备开始逐步把整条链路拆开。2. 井史数据先“治”再“喂”两个关键处理与特征构造深度学习吃数据但油井生产数据是国内现场最“脏”的数据之一。报表录入靠人传感器更换和校准也靠人所以数据里既有缺失、超界值还有“关井—开井”产生的间歇性零值。这些不处理干净后面模型再先进也是白搭。2.1 原始数据里最常见的三类“假信号”第一类是产液量突然归零原因可能是关井测压、设备检修也可能是仪表离线但报表上写的都是0。第二类是脉冲尖峰比如抽油机启动瞬间的热线电流波动或者输油泵切换导致的瞬时高值这类值在曲线图上看着吓人但对预测下一阶段的产量没有参考价值。第三类是时间不对齐井口的温度、压力是小时级采集产液量是日报动液面可能一个月才测一次多源数据直接拼起来会让深度学习模型学会“乱对时间戳”。我一般处理顺序是先按井号和时间戳排序把明显超出物理边界的值比如日产液量超过泵额定排量三倍标为缺失再用前后两天的中位数做填充而不是均值——均值对尖峰敏感会把一根刺磨成一个鼓包。对于关井状态直接看生产状态字段如果状态是“关井”或者连续三天产液量为0就把这段标记成非生产期不进入滑窗样本。import pandas as pd import numpy as np df pd.read_csv(well_history.csv, parse_dates[date]) df df.sort_values([well_id, date]) # 物理边界过滤产液量不能为负也不能超过泵额定排量的3倍 pump_max 120 # m3/d来自该井的泵挂参数 df.loc[df[liquid_rate] pump_max * 3, liquid_rate] np.nan df.loc[df[liquid_rate] 0, liquid_rate] np.nan # 连续3天为0视为关井段整段置为NaN避免把关井后的“恢复峰”当训练样本 zero_mask df[liquid_rate] 0 zero_run zero_mask.groupby((~zero_mask).cumsum()).transform(sum) df.loc[(zero_run 3) zero_mask, liquid_rate] np.nan # 中位数填充缺失 df[liquid_rate] df.groupby(well_id)[liquid_rate].transform( lambda s: s.fillna(s.median()) )这段代码里最关键的是“连续3天为0”的判断逻辑。分组用的技巧是(~zero_mask).cumsum()它会把连续的 True 切成不同的组然后transform(sum)统计每组连续零值天数只有真正达到3天才被当作关井段处理。如果只把单日0值置为NaN会把正常生产中的偶发日停误伤导致模型学到一个错误的“今天零产量明天就恢复”的规律。2.2 构造滑窗样本预测目标怎么定才符合现场需求油井生产动态预测的落地场景一般是三条一是月度配产计划的制定需要预测未来30天累积产液量二是措施井效果评价比如压裂或酸化后30天产量对比三是间抽制度寻优需要看不同开关井周期下的产量趋势。因此源码里推荐默认预测窗口是30天输入窗口是60天或90天。输入太长模型学到的是长期递减趋势输入太短则很难捕捉到压力恢复周期等中短期波动。构造样本时要注意步长。如果每口井用滑窗步长1天切样本一口1000天的井能切出900多条样本相邻样本重叠度太高训练集和验证集之间会产生严重的相似性泄漏。我一般对日产数据用步长7天切既能保证样本量又能降低重叠带来的伪相关。对月报数据的井窗口和步长都按“月”为单位重新定义。def make_samples(df, input_len60, pred_len30, stride7): samples, targets [], [] for well_id, grp in df.groupby(well_id): grp grp.sort_values(date).reset_index(dropTrue) values grp[[liquid_rate, oil_rate, water_cut, tubing_pressure, casing_pressure]].values for i in range(0, len(values) - input_len - pred_len 1, stride): x values[i : i input_len] y values[i input_len : i input_len pred_len, 1] # 预测 oil_rate samples.append(x) targets.append(y) return np.array(samples), np.array(targets)这里的y取的是oil_rate这一列也就是未来30天的产油量序列。实际业务里产油量比产液量对经济评价更有意义但也更难预测因为它受含水率变化影响。你也可以把liquid_rate也放进预测目标里做成多目标输出但后续损失函数和评估指标都要跟着调整。参数stride7直接影响样本数量1000天数据、60天输入、30天输出按步长7切能得到约130条样本这在小数据集上是合理数量。2.3 归一化的坑MinMax 还是 RobustScaler油井数据经常有长尾尖峰比如压裂井初期产量是正常水平的5到10倍之后迅速回落。如果直接对全序列做 MinMax尖峰会被拉到接近1大部分正常生产值被压到0到0.3之间模型梯度在归一化空间里非常难走。常见做法有两种一是对所有特征用 RobustScaler基于中位数和四分位距缩放抗尖峰能力强二是对油压、套压这类本身变化幅度不大的特征单独用 MinMax但把上界设成物理上限而不是数据最大值。from sklearn.preprocessing import RobustScaler scaler RobustScaler(quantile_range(10.0, 90.0)) x_scaled scaler.fit_transform(grp[[liquid_rate, oil_rate, water_cut, tubing_pressure, casing_pressure]])注意一个顺序问题RobustScaler的fit应该在训练集上完成验证集和测试集只用transform。如果在全量数据上先缩放再切分等于让模型在训练时已经“见过”测试集的分布统计量这是典型的数据泄漏。另一个坑是不同井的液量基数差异很大有的井日产5吨有的井日产80吨。如果所有井一起缩放再训练低产井的特征会被压缩到很小范围模型天然偏向高产井。我通常先按井分组每组单独 fit scaler再拼接样本。3. 模型选型与源码骨架从 LSTM 到 TCN 的实测对比模型选型不该拍脑袋。油井生产动态预测本质是单变量或多变量的时序回归最常见的选择是 LSTM、GRU、TCN 和 Transformer。对这个特定场景样本量是关键约束——一口井的历史数据往往只有几百到两千天并且生产制度一旦调整提液、转抽、措施序列的统计规律会突变。这种数据量下Transformer 容易过拟合LSTM 是平衡性能和可解释性的基线选择。3.1 为什么把 LSTM 当成源码默认基线LSTM 的门控机制适合捕捉油井生产中的两类典型动态一类是长期递减趋势这是由地层能量下降决定的跨度在数月以上另一类是短期波动比如泵工况变化引起的产量抖动。标准的 LSTM 细胞状态可以在长时间跨度上保留递减趋势信息同时遗忘掉无意义的抖动这种双重特性正好匹配产量序列。层数上现场实测下来两层 LSTM 基本就是上限。三层以上在小样本时序数据上几乎必然过拟合而且训练时间翻倍。隐藏单元数建议从32到128之间调输入特征多可以适当加到128特征少用64。每层后面接 Dropout丢弃率0.2到0.3防止对训练井的模式记忆过深。import tensorflow as tf from tensorflow.keras import layers, Model def build_lstm_model(input_shape(60, 5), hidden_dim64, pred_len30): inputs layers.Input(shapeinput_shape) x layers.LSTM(hidden_dim, return_sequencesTrue)(inputs) x layers.Dropout(0.2)(x) x layers.LSTM(hidden_dim // 2)(x) x layers.Dropout(0.2)(x) x layers.Dense(64, activationrelu)(x) outputs layers.Dense(pred_len)(x) model Model(inputs, outputs) model.compile(optimizeradam, losshuber, metrics[mae]) return model这个网络结构输出的是30个时间步的产油量预测也就是一个Dense(pred_len)直接把 LSTM 最后一步的隐状态映射成30个数值。相比用TimeDistributed逐步输出这种直接映射更适合产量预测因为我们要的不是“逐步滚动预测”而是一次性给出未来30天的趋势曲线。损失函数用huber而不是mse是因为产量序列里有尖峰Huber 损失对异常值的梯度约束更平滑不会让模型为了少数几天的高产尖峰扭曲整体预测。3.2 候选模型GRU、TCN 和注意力机制各自的定位GRU 是 LSTM 的简化版参数量大约少四分之一训练更快在小数据集上往往比 LSTM 更稳。我在几口注水井的数据上对比过GRU 的验证集 MAPE 比 LSTM 低1到2个百分点原因是 GRU 少一个遗忘门对噪声更钝感。如果你的数据只有一两年优先试 GRU它能省不少调参时间。TCN 即时间卷积网络优势是训练速度远超 LSTM因果卷积可以并行计算而且感受野可以靠膨胀系数灵活控制。油井产量序列的周期性和趋势性都能被卷积捕获但 TCN 对输入序列的长度要求更高短序列上表现不如 LSTM。另外 TCN 的输出对输入中的近期波动更敏感如果现场数据中的偶发尖峰没有清洗干净TCN 的预测曲线会明显比 LSTM “毛躁”。注意力机制在这类任务里适合加在 LSTM 输出和全连接层之间让模型自己决定历史哪几个时间点的状态对预测最关键。对油井生产动态预测来说注意力加权后的隐状态通常更关注最近7天到14天的趋势这符合现场经验——短期内压力恢复或措施见效的迹象比三个月前的递减规律更能决定未来30天产量。3.3 训练流程里容易被忽略的三个环节第一是验证集切分不能随机。油井时序数据的随机切分会让训练集里混入验证集时间之后的样本造成时间穿越。正确做法是按时间顺序切分比如前70%的日期范围做训练中间15%做验证最后15%做测试。第二是早停的监控指标不能只看验证集损失还要结合业务指标。我见过模型验证损失降得很好但预测曲线整体滞后一天原因是损失函数对“整体抬高但形状吻合”和“形状滞后一天”给出的惩罚差异不够大。第三是多井训练时的样本权重高产井样本波动大、低产井样本波动小如果不做任何处理损失会被高产井主导。简单做法是按井的产量中位数做样本权重归一化实际使用中能显著提升低产井的预测精度。4. 训练、评估与调参这套源码的核心参数表源码能跑通和能上现场是两码事。真正决定模型好坏的是那几个看起来不起眼的参数——滑窗长度、步长、损失函数、批大小、学习率。这章直接给出参数表和一套命令行训练流程便于直接复现。4.1 必调参数清单从数据到训练的一站式建议下表是这套代码里的核心参数取值基于多口井的评测结果给出推荐范围和理由。参数推荐值区间影响说明input_window60 ~ 90天太短捕捉不到递减趋势太长引入过多历史噪声pred_window30天默认值对齐月度配产计划周期stride7天降低相邻样本重叠抑制数据泄漏网络隐藏单元64 / 128特征5个以内用64超过8个用128损失函数huber / log_cosh不容易被生产尖峰带偏学习率0.0005 ~ 0.001太高发散太低训练慢且容易过拟合batch_size32 ~ 64小批量在少量样本上泛化略好early_stopping_patience15 ~ 20轮防止在验证集上反复震荡滑窗长度对结果的影响最直接。60天输入能覆盖两个月左右的趋势这对递减率稳定的井足够90天输入适合含水率上升较快或注水见效滞后的井。我建议先跑60天基线再跑90天做对比如果验证集指标提升超过2%才保留长窗口否则短窗口优先因为短窗口意味着推理时需要的输入更短部署时更灵活。4.2 训练脚本与早停、模型保存的工程细节from tensorflow.keras.callbacks import EarlyStopping, ModelCheckpoint, ReduceLROnPlateau callbacks [ EarlyStopping(monitorval_loss, patience20, restore_best_weightsTrue), ModelCheckpoint(best_oil_model.keras, monitorval_loss, save_best_onlyTrue, verbose1), ReduceLROnPlateau(monitorval_loss, factor0.5, patience5, min_lr1e-5), ] model.fit( x_train, y_train, validation_data(x_val, y_val), epochs200, batch_size32, callbackscallbacks, verbose1, )这里ModelCheckpoint只保存验证集损失最小的模型restore_best_weightsTrue则保证训练结束后模型权重回滚到最优状态而不是最后一步。ReduceLROnPlateau的作用是当验证损失连续5轮不降时把学习率减半这对 LSTM 类模型很有效能避免后期在局部最优附近反复震荡。模型保存格式用.keras而不是.h5前者是 Keras 3 的推荐格式保存了完整的优化器状态和自定义损失后续做推理恢复更省事。4.3 评估指标不能只看 RMSE采油业务里的“合格率”深度学习通用的评估指标是 RMSE 和 MAE但油工程审核人员更认“单月预测合格率”——预测产油量与真实产油量的相对误差在正负15%以内记作合格。这个指标对模型输出的解释更直观一张月度配产计划表上领导关心的是“有百分之几的井预测基本靠谱”而不是抽象的均方根误差。def qualified_rate(y_true, y_pred, tol0.15): # 相对误差百分比排除真实值接近0的样本 mask np.abs(y_true) 1e-6 rel_err np.abs((y_true[mask] - y_pred[mask]) / y_true[mask]) return np.mean(rel_err tol)引入合格率之后你会发现模型调参的方向变了。RMSE 会被少数极端井的预测误差拉高导致你拼命去拟合那些难井但从合格率角度看真正值得优化的是把中等难度井的误差从18%压到14%而不是把最难的井从50%压到40%。这也是为什么现场落地时模型的损失函数可以不改但评估报告里一定要同时给出 RMSE、MAPE 和合格率三个指标。5. 避坑、踩坑与排查油井时序预测里最常见的四个翻车现场深度学习在工业数据上的失败大部分不是模型问题而是数据处理和评估设计的问题。油井生产动态预测的翻车现场我按出现频率排了四个前两个几乎必然遇到后两个在交叉验证和部署阶段容易爆发。5.1 时间穿越随机切分让模型“偷看”了未来现象训练集损失降得很好验证集损失也很低但模型在一口新井上的预测完全不对。原因代码里用了train_test_split(X, y, random_state42)随机切分把同一时间段的一部分样本分到训练集、一部分分到验证集。油井产量序列有强自相关性验证集里的某一天其实和训练集里前两天高度相似模型实际在“背答案”。解决改成按日期排序的连续切分训练集日期范围在验证集之前验证集在测试集之前。5.2 关井段的“零值陷阱”现象验证集损失不大但画出来的预测曲线在真实产油量归零的时段还维持在高位或者提前几天就往下掉。原因关井段的零值没有被清洗模型用大量零值样本训练学到“遇到相似压力特征时产量应该趋近于零”但真实场景中关井是人为决策和油层产能没有直接关系。解决按2.1节的逻辑把连续3天及以上的零值段剔除不送入训练推理时如果当前井实际处于关井状态直接先做人工标记再决定是否启用模型预测。5.3 滑窗重叠造成的样本依赖现象把验证集切出来后模型在验证集上的表现异常好但到了下一口井就崩。原因步长设成了1相邻两个样本只有一天之差训练集和验证集边界附近的样本几乎重合验证损失被严重低估。解决步长至少设到预测长度的四分之一推荐7天更严格的做法是在多井数据上按“井级”切分训练集和验证集各含完全不同批次的井这样评估的是模型跨井泛化能力不是对同一口井的记忆能力。5.4 归一化统计量泄漏现象同一套代码换了数据集训练正常验证集损失却莫名其妙比训练还低。原因数据预处理时先在全量数据上计算 MinMax 或 RobustScaler 的参数再进行切分验证集和测试集的分布统计已经参与了训练数据的缩放。解决严格把预处理拆成两步先在训练集上 fit再对验证集和测试集只做 transform如果按井分组归一化每口井的 scaler 参数要单独序列化保存推理阶段加载同一口井的 scaler 反变换输出。6. 从离线预测到现场可用部署形态与模型迭代的验证技巧模型训练完成只是开始。油井生产动态预测的源码价值最终体现在“预测结果能不能直接进配产会、能不能指导间抽制度调整”。这里讲三个落地习惯模型导出、输出反变换、再训练节奏。训练好的 Keras 模型可以导出为SavedModel格式方便用 TensorFlow Serving 或 ONNX Runtime 部署。导出前记得把 scaler 一起打包。由于训练时每组输入特征都经过了归一化推理接口接收的应该是归一化后的张量而输出需要反变换回真实产量单位否则工程师看到的是一堆0到1之间的小数根本没法判断预测值是否合理。model.save(oil_prod_model_saved, save_formattf) np.save(scaler_params.npy, {medians: scaler.center_, scales: scaler.scale_})再训练节奏上我的习惯是现场每月月底用截至当天的数据增量训练一次而不是模型上线后就不管了。油井的含水率上升、地层压力下降都会让输入分布发生漂移静态模型的有效期往往只有两到三个自然月。增量训练时保留上一版模型作为对照如果新模型在验证集上的合格率低于旧模型直接回滚不发布。最后一个验证技巧拿历史“措施事件”做回溯测试。选3到5口做过压裂、酸化或提液的井用模型在措施前的输入窗口做预测看措施后30天的实际曲线和预测曲线差多少。理想结果是在措施生效前模型预测偏差可控这说明模型学的是趋势性的生产动态规律而非对具体事件的记忆。我把这个测试写进了每次模型迭代的检查清单里每次发布新版模型前必须跑一遍经历过一次在措施井上预测失真而现场照搬的情况后这个步骤再也没省过。希望这套从数据清洗、特征构造到模型部署的完整思路能帮你少走一些弯路。本文还有配套的精品资源点击获取