做回归预测还想着用Transformer的人不少一开始是被杀鸡用牛刀这类说法劝退的。常规的多输入单输出回归大家习惯了直接上多层感知机顶多加个LSTM或者GRU似乎线性层堆叠就能解决一切。但当我遇到一组高维、强非线性、且时间依赖性明显的过程数据时MLP的表现非常挣扎调参调到我怀疑人生。换到Transformer Encoder之后一切开始变得不同。这篇文章我打算把整个项目从头到尾摊开来讲——从数据怎么构造、Encoder的每一层代码怎么写到损失函数和评估指标怎么配再到怎么给模型套一个GUI界面让不懂代码的人也能跑预测全部走一遍。我会尽量把思路讲透而不是只丢一段能跑的代码。适合那些已经会Python基础、用过PyTorch但还没系统接触过Transformer做非序列回归任务的朋友。如果你是纯新手只要会用conda建虚拟环境跟着步骤走也能复现。1. 为什么多输入单输出回归值得换用Transformer Encoder先说一下项目背景。我手头的数据是某设备运行过程中采集的多维传感器信号包含温度、振动幅度、转速、负载电流等8个特征每隔一分钟记录一次。目标是预测未来某个时点的设备能耗值这是一个典型的多输入单输出回归任务输入是多个历史时刻的多维特征输出是一个连续数值。用朴素MLP做这个任务意味着我把最近N个时间步的特征全部拉平成一长串向量塞进全连接层。这种方式有一个致命问题时间上下文被破坏了。第1分钟和第30分钟的特征在MLP看来是一视同仁的邻居没有任何先后顺序的概念模型根本学不到能耗的变化趋势这种动态信息。用LSTM能不能解决能但LSTM的致命弱点是训练慢且很难并行。序列长度一上来一个样本要逐步走完整个序列300个时间步就是300次串行计算迭代到收敛非常煎熬。而且LSTM对长距离依赖的捕捉能力并不算好在碰到某些周期性滑动的模式时容易丢信息。Transformer Encoder的好处在于全局注意力机制输入序列中的任意两个位置之间可以直接建立联系1号位置的温度和30号位置的温度可以一步直接相互感知到而不像RNN那样必须一步一步传递信息并行计算注意力权重是一次性算出来的整条序列可以同时处理训练速度在同样的batch下比LSTM快不少位置编码强行把顺序信息灌进输入让模型知道现在看的是第几步残差结构与LayerNorm深层编码器训练更稳定梯度消失的概率大大降低当然Transformer不是万能的。如果你的数据量特别小少于几千条或者特征之间完全是静态独立的MLP反而更省事。我选择Transformer是因为数据具备明显的时间依赖且总样本量在两万条以上足够喂饱一个有4层Encoder的模型。2. 数据构造与预处理把多输入整成模型能吃的样子2.1 理解输入输出的张量形状先讲清楚模型到底吃什么形状的数据。这个决定了一切后续代码的书写逻辑。假设我们设定[look_back 48]意思是使用过去48个时刻的数据来预测下一个时刻的能耗值。每个时刻有8个特征那么一个样本的形状是(48, 8)即48行、8列一个batch送给模型时形状是(batch_size, 48, 8)Transformer Encoder在PyTorch中的输入要求是(seq_len, batch_size, d_model)或者(batch_size, seq_len, d_model)后者更常见配合batch_firstTrue使用。这里的d_model就是我们映射给每个时间步的隐藏维度。8个原始特征可以先用一个全连接层映射到64维等于d_model64。输出层呢编码器输出的形状是(batch_size, 48, 64)我们要预测一个单值通常做法是取最后一个时间步的输出或者对整条序列的输出做全局平均池化然后接一个(64 - 1)的全连接层我实际测试下来对于这种预测任务最后一个时间步的输出效果通常优于全局平均池化因为最后一个时间步承载了整条序列压缩后的最终信息。2.2 滑窗切分与训练集划分核心思路就是滑动窗口。假设原始数据一共有N行N个时间戳每行8个特征加上1个要预测的能耗标签。我们可以构造X[i] 第i行到第i47行的8个特征形状(48, 8)y[i] 第i48行的能耗值单个数这样原始N条数据能构造出N-look_back个样本。这里有个非常关键的细节切分训练集和测试集不能随机打乱。因为是时间序列你如果用train_test_split默认的随机分割会让模型看到未来的数据造成严重的数据泄漏测试集上的R2会好看到离谱但真实落地预测完全不是那么回事。正确做法是严格按照时间顺序划分比如前75%训练、后25%测试。我当时是把总共22000条数据切成训练集16000条、验证集3000条、测试集3000条。这里没有悬念时间序列就是要按顺序裁。def create_sequences(data, feature_cols, target_col, look_back48): X, y [], [] for i in range(len(data) - look_back): X.append(data.iloc[i:ilook_back][feature_cols].values) y.append(data.iloc[ilook_back][target_col]) return np.array(X), np.array(y)注意特征列需要是DataFrame里能直接取到的8列名称的列表。数据里如果混入非数值列提前做编码或丢弃。2.3 标准化必须在训练集上拟合并后向测试集套用这是另一个绕不开的坑。你要先对训练集做fit拿到均值和标准差然后再用同一个scaler去transform验证集和测试集。很多新手把整个数据集扔进StandardScaler再分割结果是训练和测试共同参与了均值和方差的估计测试集信息提前泄露进了训练阶段。我在项目里实际写了三个scaler特征用同一个标签单独用一个feature_scaler对8列特征标准化target_scaler对能耗值标准化预测出来的结果如果没有反标准化你会得到一个均值为0方差为1的数这个数根本无法和实际能耗对得上。反标准化很简单y_hat_real y_hat * target_scaler.scale_ target_scaler.mean_。在这个项目里我直接调了inverse_transform更方便。feature_scaler StandardScaler() target_scaler StandardScaler() train_features feature_scaler.fit_transform(train[feature_cols]) test_features feature_scaler.transform(test[feature_cols]) train_target target_scaler.fit_transform(train[[target_col]]) test_target target_scaler.transform(test[[target_col]])再强调一遍绝对不要在fit_transform之前把train和test拼在一起。我见过太多人这样写训练效果好落地就废。3. Transformer Encoder代码拆解从位置编码到输出头下面进入重头戏。整个模型我分成了几个模块输入映射、位置编码、Encoder堆叠、输出头。先看整体的代码结构。3.1 位置编码的实现Transformer本身不感知顺序所以我们要在输入里注入位置信息。常见的做法是用三角函数位置编码对每个位置pos给它的每个维度分别填充不同频率的正弦和余弦值。import torch import torch.nn as nn import math class PositionalEncoding(nn.Module): def __init__(self, d_model, max_len5000): super().__init__() pe torch.zeros(max_len, d_model) position torch.arange(0, max_len, dtypetorch.float).unsqueeze(1) div_term torch.exp(torch.arange(0, d_model, 2).float() * (-math.log(10000.0) / d_model)) pe[:, 0::2] torch.sin(position * div_term) pe[:, 1::2] torch.cos(position * div_term) pe pe.unsqueeze(0) # (1, max_len, d_model) self.register_buffer(pe, pe) def forward(self, x): # x: (batch, seq_len, d_model) return x self.pe[:, :x.size(1), :]这里用register_buffer而不是普通张量是为了让位置编码随模型一起转入GPU并且在model.parameters()里不出现、不参与训练。为什么用三角函数而不是可学习的嵌入因为三角函数编码可以外推到比max_len更长的序列而且不需要额外的参数量。对于时间序列预测样本序列长度通常是固定的所以两种方案差别不大。但我个人偏好三角编码因为它在理论上能更好地泛化到不同数据分布。3.2 Transformer Encoder的完整定义核心做法是先通过一个线性层把原始特征维度从input_dim映射到d_model然后加位置编码接着过若干层TransformerEncoderLayer在PyTorch里这两个都有现成的我们需要做的是把它们组装起来。class TransformerEncoderRegressor(nn.Module): def __init__(self, input_dim, d_model64, nhead4, num_layers3, dropout0.1, max_len5000): super().__init__() self.input_fc nn.Linear(input_dim, d_model) self.pos_encoder PositionalEncoding(d_model, max_len) encoder_layer nn.TransformerEncoderLayer( d_modeld_model, nheadnhead, dim_feedforward256, dropoutdropout, activationgelu, batch_firstTrue, norm_firstTrue ) self.encoder nn.TransformerEncoder(encoder_layer, num_layersnum_layers) self.output_fc nn.Sequential( nn.Linear(d_model, 32), nn.GELU(), nn.Dropout(dropout), nn.Linear(32, 1) ) def forward(self, x): # x: (batch, seq_len, input_dim) x self.input_fc(x) # (batch, seq_len, d_model) x self.pos_encoder(x) # (batch, seq_len, d_model) x self.encoder(x) # (batch, seq_len, d_model) x x[:, -1, :] # 取最后一个时间步 out self.output_fc(x) # (batch, 1) return out.squeeze(-1)这段代码里我认为最关键的一个参数是norm_firstTrue。它表示先做LayerNorm再做多头注意力和前馈网络。这个设置来自GPT-2之后大量实验验证的经验比旧版的Post-LN在深层网络中更稳定训练不容易发散。如果你用老版本PyTorch可能没有这个参数建议至少升级到PyTorch 2.0以上。dim_feedforward256也是一个调出来的经验值。Transformer里前馈层的隐藏维度一般设为d_model的4倍但64维的4倍是256这恰好能让模型有足够容量表达非线性关系又不会太大导致过拟合。关于nhead4的选择d_model644头注意力意味着每头负责16维子空间这个配置在小规模回归任务里是合理的。如果你的数据模式更复杂可以加大d_model到128同时把nhead提到8但要记住参数量会显著上涨。3.3 参数量估算与训练开销以这个配置来算input_fc8×64 64 576每层TransformerEncoderLayer内部的参数多头注意力QKV三个矩阵各64×64加上输出投影大约 4×(64×64) 16384再加上两个LayerNorm的4×64 ≈ 256小头不计前馈网络64×256 256 256×64 64 ≈ 32768单层大约5万参数3层Encoder约15万输出头64×32 32 32×1 1 ≈ 2081合计大约18万参数。这是一个非常轻量的模型在GPU上训练一个epoch大概几秒钟CPU上也能跑只是慢一些。我很长一段时间在只有CPU的笔记本上调试这个项目虽然慢但没有到不能忍受的地步。如果你用GPU训练记得开启torch.cuda.amp.autocast混合精度可以再快一倍。4. 训练流程里最容易被忽视的细节损失、指标与过拟合控制模型定义好了接下来是训练。这一部分看着常规但坑比模型本身还多。我建议把所有配置集中在开头方便复现和调整参数。4.1 数据集类与DataLoader直接构造一个TensorDataset最简单from torch.utils.data import TensorDataset, DataLoader train_dataset TensorDataset(torch.FloatTensor(X_train), torch.FloatTensor(y_train)) test_dataset TensorDataset(torch.FloatTensor(X_test), torch.FloatTensor(y_test)) train_loader DataLoader(train_dataset, batch_size64, shuffleFalse, drop_lastTrue) test_loader DataLoader(test_dataset, batch_size64, shuffleFalse, drop_lastFalse)注意训练时也不要shuffleTrue。因为是时间序列数据打乱顺序会彻底抹掉时间连续性模型对时间依赖的学习就无从谈起。虽然Transformer的注意力本身不依赖顺序位置编码保留了顺序感但把一个序列的第1个时间步和第48个时间步拆到不同的batch里对学习效率是打击。保持数据顺序让每个batch内部的时间上下文尽量连贯这是我实测下来收敛更稳定的重要原因。drop_lastTrue在训练时建议启用。如果你的样本数不能被batch_size整除最后剩下的小batch会影响BatchNorm和训练的稳定性。Transformer中没有BatchNorm影响没这么大但统一处理更省心。4.2 损失函数的选择损失函数效果对比回归任务的损失函数第一反应是MSE。上一张图可以看出MSE其实是看起来好但不够稳的选择。让我用数据说话损失函数公式特点本次实验MAEMSE((y-\hat y)^2)大误差惩罚重收敛快1.97MAE|(y-\hat y)|对异常点不敏感2.03SmoothL1见代码注释分段式误差小时接近L2大时接近L11.72LogCosh(\log(\cosh(y-\hat y)))平滑且近似Huber1.68我最终选择了LogCosh损失。这个损失函数的曲线在接近0时近似二次函数在远离0时近似线性既保留了MSE的收敛速度优势又避免了异常样本主导梯度的困境。设备能耗数据中偶尔会有设备启停引起的能耗尖峰这类异常如果是真实事件就不该像MSE那样被过度放大LogCosh刚好平衡了这一点。class LogCoshLoss(nn.Module): def __init__(self): super().__init__() def forward(self, y_pred, y_true): diff y_pred - y_true return torch.mean(torch.log(torch.cosh(diff 1e-12)))用1e-12做偏移防止cosh在输入为0时输出去NaN。实际测试LogCosh的收敛速度不如MSE那么快但最终loss更平滑没有MSE那种一波一波的震荡感。4.3 优化器与学习率调度我用的优化器是Adam初始学习率设定的核心原则是大学习率优先但必须配warmup调度器。Transformer对学习率非常敏感固定学习率1e-3开始时loss可能不降反升加了warmup之后问题基本消失。optimizer torch.optim.Adam(model.parameters(), lr1e-3, weight_decay1e-5) scheduler torch.optim.lr_scheduler.OneCycleLR( optimizer, max_lr2e-3, total_stepsnum_epochs * len(train_loader), pct_start0.2, div_factor50, final_div_factor10 )OneCycleLR是我个人非常推崇的训练策略。它将整个训练过程分成两段前20%的step从极小学习率线性上升到max_lr这相当于预热的warmup后80%逐步走余弦退火降到最小学习率。好处是前期模型权重还没稳定时用小学习率避免震荡后期接近收敛时又用小学习率仔细搜最优解中间用大学习率加速突破。相比手动StepLR这个方案几乎不需要调参收敛一致性好。4.4 评估指标与可视化回归预测不能只看loss还需要看R2、MAE、RMSE以及真实值和预测值的拟合曲线。from sklearn.metrics import r2_score, mean_absolute_error, mean_squared_error def evaluate(model, loader, device): model.eval() preds, trues [], [] with torch.no_grad(): for X_batch, y_batch in loader: X_batch X_batch.to(device) pred model(X_batch).cpu().numpy() preds.extend(pred) trues.extend(y_batch.numpy()) preds target_scaler.inverse_transform(np.array(preds).reshape(-1, 1)) trues target_scaler.inverse_transform(np.array(trues).reshape(-1, 1)) r2 r2_score(trues, preds) mae mean_absolute_error(trues, preds) rmse mean_squared_error(trues, preds, squaredFalse) return r2, mae, rmse, np.array(preds).ravel(), np.array(trues).ravel()inverse_transform这一步容易疏忽。模型学习的是标准化的目标值你如果用标准化之前的真实值去算metrics误差会被严重放大。我在测试时碰到过一次结果R2虽然还正常但MAE显示5.6而实际上标准化前的能耗总量单位是千瓦时量级很大这个MAE是错的。我的本次项目最终的测试集结果R2 0.912MAE 1.68RMSE 2.34。这个结果在工业设备能耗预测里算不错了不算惊艳但对数据质量参差不齐的现场传感器值来说已经具备实用价值。训练过程中我还会绘制loss曲线和预测对比图。这里不展开画图的代码但强烈建议你保留。模型训完之后再看一眼预测曲线如果有波峰波谷对不齐说明模型没有真正学到时间模式多半是数据构造或者超参有问题。5. 给模型套上GUI外套tkinter预测界面的完整实现模型训练好之后拿去交付给不懂代码的运行人员总不可能让人家去跑Python脚本调API。我在项目里用tkinter做了一个非常轻量的图形界面不用装额外的依赖双击就能跑功能也挺完整。5.1 界面布局与交互逻辑界面逻辑设计如下用户可以选择CSV数据文件导入最近若干时刻的特征数据界面上直接显示8个输入特征的数值点击开始预测按钮加载训练好的模型和scaler输出预测值如果用户没有新数据也提供使用测试集示例给你演示用import tkinter as tk from tkinter import filedialog, messagebox import torch import pandas as pd import joblib class PredictionGUI: def __init__(self, model_path, scaler_path): self.window tk.Tk() self.window.title(设备能耗预测系统 - Transformer Encoder) self.device torch.device(cuda if torch.cuda.is_available() else cpu) self.model TransformerEncoderRegressor(input_dim8, d_model64, nhead4, num_layers3) self.model.load_state_dict(torch.load(model_path, map_locationself.device)) self.model.to(self.device) self.model.eval() self.feature_scaler joblib.load(scaler_path) self.entries {} self._build_ui() self.window.mainloop()框架搭好之后界面上就是8个标签输入框对应8个特征字段。为了演示效果我把特征命名成环境温度、设备温度、振动幅度、转速、电流、电压、气阀开度、运行时长。这样运行人员一眼能看懂每格填什么。5.2 核心预测逻辑实现预测逻辑的核心在于界面拿到用户输入的8个值后这只是一个时刻的特征。但模型需要的是48个时刻、8个特征的矩阵。这个数据从哪里来我提供两种途径如果导入的是CSV文件且包含最近的历史数据就自动取出最近48条如果用户只想快速测试就在代码里写一个简单逻辑用当前输入的8个值复制出48个时间步作为一个静态序列去预测。这样预测结果反映的是假设设备保持当前状态往后运行的能耗水平下面是第二种方式的代码def predict_from_current_state(self): try: features [] for name in self.feature_names: features.append(float(self.entries[name].get())) features np.array([features]) features_std self.feature_scaler.transform(features) # 复制48个时间步 sequence np.repeat(features_std, 48, axis0).reshape(1, 48, 8) with torch.no_grad(): X torch.FloatTensor(sequence).to(self.device) pred self.model(X).cpu().numpy().reshape(-1, 1) # 反标准化 pred_real self.target_scaler.inverse_transform(pred)[0, 0] self.result_label.config(textf预测能耗值: {pred_real:.2f} kW·h) except Exception as e: messagebox.showerror(输入错误, f请检查输入格式: {str(e)})如果读取CSV真实历史逻辑稍微复杂一点def predict_from_csv(self): path filedialog.askopenfilename(filetypes[(CSV files, *.csv)]) if not path: return df pd.read_csv(path) if len(df) 48: messagebox.showwarning(数据不足, 至少需要48条连续记录) return recent df.iloc[-48:][self.feature_names].values recent_std self.feature_scaler.transform(recent) sequence recent_std.reshape(1, 48, 8) # 后续与上面一致注意feature_scaler在GUI里也要做和训练时一样的操作——用同一个scaler去transform。所以训练完成后一定要把两个scaler保存下来常见做法是joblib.dump。这个细节做完就不容易遗忘但很多人训练完只存模型权重不存scaler导致推理时特征数值不对预测结果完全跑偏。/5.3 用PyInstaller打包成exe让运行人员双击运行不能总是让他们开个Python解释器。用PyInstaller打包pip install pyinstaller pyinstaller -F -w --add-data model.pth;. --add-data feature_scaler.pkl;. transformer_gui.py-F生成单文件exe-w表示不显示命令行窗口。如果你的资源文件路径写的是相对路径打包后可能找不到模型文件。我在代码里用了resource_path函数去适配打包环境import sys import os def resource_path(relative_path): base_path getattr(sys, _MEIPASS, os.path.abspath(.)) return os.path.join(base_path, relative_path)然后在加载模型和scaler的地方都通过resource_path取路径。这是PyInstaller打包最常见的一个坑不加这个函数你在开发环境跑得好好的打包完一开机直接报找不到文件。6. 训练中的稳定性和性能优化一些实战经验这部分内容是我跑这个项目几十轮实验攒下来的体会常规博客不太会讲得这么细但对结果影响却很大。6.1 随机种子固定跨平台可复现的关键训练深度学习模型如果不固定随机种子同一份代码两次训练结果可能差出好几个百分点。尤其Transformer这类模型初始化的微小差异在多层叠加后被放大得厉害。def set_seed(seed42): import random random.seed(seed) np.random.seed(seed) torch.manual_seed(seed) torch.cuda.manual_seed_all(seed) torch.backends.cudnn.deterministic True torch.backends.cudnn.benchmark False把这段放训练脚本最开头每次跑出来的结果基本一致。尤其在与别人论文对比或内部评审时可复现性非常重要。6.2 梯度裁剪的必要性Transformer的训练中偶尔会出现loss突然暴涨的情况这多半是某个样本触发了过大的梯度。我在每次反向传播之后加了一句梯度裁剪torch.nn.utils.clip_grad_norm_(model.parameters(), max_norm1.0)这个操作等价于给所有参数梯度模长设了一个上限如果超过1.0就按比例缩回去。它的作用是防止单次更新的步长过大从而稳定训练、防止loss发散到NaN。我的经验是加上这一句之后用LogCosh加Transformer的组合几乎没有再遇到过训练崩掉的情况。6.3 早停机制没有理由让模型跑满全部epoch训练曲线在某个epoch之后就不再下降甚至验证集loss开始回升说明模型开始过拟合了。与其靠肉眼盯着训练输出卡点不如写一个早停逻辑自动停best_val_loss float(inf) patience 15 counter 0 for epoch in range(num_epochs): train_loss train_one_epoch(...) val_loss validate(...) if val_loss best_val_loss: best_val_loss val_loss torch.save(model.state_dict(), best_model.pth) counter 0 else: counter 1 if counter patience: print(fEarly stopping at epoch {epoch}) break这里我把patience设定为15。如果连续15个epoch验证损失都没刷新纪录我就认为继续训练意义不大。保存下来的是验证损失最小的那一次权重而不是最后一轮的权重这个细节非常重要。最后一轮权重往往不是表现最好的权重因为验证集上波动会导致最后几轮不一定落在最优点上。6.4 隐藏维度与头数的组合实验我在项目中做过一组对比实验直接放数据给大家参考d_modelnheadnum_layersR2MAE32220.8722.3164430.9121.6864830.9051.74128430.9071.70128840.9081.69结论很有意思大模型不一定更好。从64维4头3层再往上加容量性能几乎不涨甚至略有下降。这个项目的核心瓶颈不在模型容量而在数据本身的噪声水平。更大更多的参数只会让模型去拟合噪声而不会提升对真实模式的表征能力。所以如果你在做类似任务不要盲目上大模型、长序列。先用64维4头3层如果欠拟合再一层层往上加。加参量的优先级建议是num_layersd_modelnhead。层数直接决定模型能捕捉的抽象层次隐藏维度决定了单层表达的宽度头数则影响注意力对不同子空间的切分程度。一般来说头数选择和d_model之间需要满足整除关系不需要很大。6.5 训练过程中的数据标准化细节标准化之前要特别注意设备传感器数据里可能存在缺失值和异常值。我一开始没做处理就标准化结果均值和方差被几个异常值拉偏模型的预测在正常范围之外波动得很厉害。建议在构造序列之前的预处理阶段就做好两步用插值法或前向填充补齐缺失值用3倍标准差法或者百分位法剔除异常点替换成上下边界值对于时间序列数据缺失值我推荐用ffill前向填充因为设备运行中相邻时刻数值变化幅度有限前向填充比线性插值更贴近真实物理过程。异常值方面能耗数据里偶尔会有设备启停瞬间的尖峰这类数据如果是正常操作造成的不应该当作噪声粗暴剔除。你需要结合业务场景判断。我在项目里使用了一个保守的处理把超过99.9分位数的点替换为99.9分位数防止极端数据把scaler参数拉偏但不改变数据总量。lower_perc data[target_col].quantile(0.001) upper_perc data[target_col].quantile(0.999) data[target_col] data[target_col].clip(lower_perc, upper_perc)如果你的现场数据里确实存在需要剔除的传感器坏值建议使用median填充而不是mean因为中位数对异常值更鲁棒。做完这一步再进StandardScaler后面的效果会明显不一样。7. 完整训练脚本结构梳理如果你想直接把这个项目当模板用这里给出一个完整的文件结构和训练流程。我习惯把所有东西拆得清清楚楚调试和维护都省心proj/ ├── data/ # 原始数据存放与处理脚本输出 │ └── sensor_data.csv ├── models/ # 保存训练好的模型和scaler │ ├── best_model.pth │ ├── feature_scaler.pkl │ └── target_scaler.pkl ├── utils/ │ ├── data_preprocess.py # 数据读取、标准化、序列构造 │ ├── model.py # TransformerEncoderRegressor及位置编码 │ ├── loss.py # LogCoshLoss │ └── train.py # 训练与评估全流程 ├── gui/ │ └── predictor_gui.py # tkinter界面 └── main.py # 一键训练入口细节决定成败。数据预处理脚本、模型定义、训练逻辑拆开写每个模块还能单独被GUI复用避免在GUI脚本里再次复制大量数据处理的代码。我这里GUI里直接调用model.py和data_preprocess.py封装的函数维护起来非常顺。迭代训练的时候我的main.py入口大概是这样的from utils.data_preprocess import load_and_split, build_dataloaders from utils.model import TransformerEncoderRegressor from utils.loss import LogCoshLoss from utils.train import train_model, evaluate_model # 1. 加载数据生成训练/测试集 X_train, X_test, y_train, y_test load_and_split(data/sensor_data.csv) # 2. 构造数据加载器 train_loader, test_loader build_dataloaders(...) # 3. 初始化模型 model TransformerEncoderRegressor(input_dim8, d_model64, nhead4, num_layers3) # 4. 训练 train_model(model, train_loader, test_loader, epochs100) # 5. 评估 r2, mae, rmse, preds, trues evaluate_model(model, test_loader)训练过程带着验证集做早停训练完成自动把最优模型和两个scaler存下来CPU大概需要半小时到一小时GPU可以几分钟搞定。之后GUI加载这些产物完事。8. 收尾关于这类项目的一点心得体会做这个项目最大的感受是Transformer在回归预测任务上的价值经常被严重低估。不只是在NLP和大语言模型这些热门场景只要数据带有时间依赖特征Encoder的全局注意力机制对比RNN就有天然优势。但它的好是有条件的——数据要有足够的时间连续性样本量不能太小特征维度要有信息量。如果这三条不满足你不如回头用MLP或者线性回归。还有一个小建议训练时不要只盯着最后的R2多看看预测值的时间序列曲线。R2是一个整体统计量它对局部动态模式的拟合效果不敏感。预测曲线如果整体趋势正确但每个波峰波谷都滞后一拍R2可能也有0.85以上但实际使用中那种滞后是无法接受的。我因为在项目里多看了几眼预测曲线才发现数据构造中有一个序列对齐偏移的bug如果只看R2根本发现不了。如果后续你想把这个项目再往前推一步不妨试试多步预测比如一次预测未来3个时刻的能耗值或者把注意力权重可视化出来看看模型每步预测的时候重点在看哪些历史时刻。这两件事对理解模型行为和理解业务数据都有很大帮助。先说到这里接下来你可以拿自己的数据试试遇到问题欢迎一起讨论。