1. 拿到的数据集和那个没人在意的64%先说结论这个项目不是用多么花哨的网络结构也不是调参调到手抽筋而是把一条完整的数据↔模型↔训练策略链路捋顺之后准确率自然从64%爬到了91%。如果你正准备拿PyTorch做分类任务或者做完了一个模型觉得怎么训都上不去这篇文章的思路应该能给你不少启发。先交代背景。我拿到的是经典的手机价格分类数据集2000条样本20个特征标签是0到3四个价格区间——低端、中端、高端、旗舰。样本量小得可怜特征全是硬件参数电池容量、内存、摄像头像素、屏幕尺寸、芯片主频之类没有图片、没有文本纯粹的表格式数据。第一次用PyTorch搭建了一个三层全连接网络跑基线验证集准确率64%。这个数字在四个类别均分25%的基准上不算差但距离能用还差得远。我一开始以为问题出在网络不够深、不够宽于是加层、加神经元结果准确率不升反降一度掉到60%以下。后来我才意识到这压根不是网络容量的问题——这是一个典型的小样本表格数据分类问题模型优化的重心根本不在把网络做得更大。如果你也遇到过类似情况——模型越改越复杂效果反而变差——大概率和我犯了同一个错误没有先搞清楚数据的质量、分布和特征之间的关系就直接把数据丢给了神经网络。这个项目整体走下来准确率提升的几个关键节点大致是这样的阶段关键动作验证集准确率基线原始特征直接喂入三层MLP64%第一轮特征工程 标准化75%第二轮重构网络结构 正则化85%第三轮训练策略调整 模型融合91%下面我把每一轮的思路、操作和踩过的坑详细拆开讲。2. 为什么基线只有64%数据里埋着三个雷2.1 特征量纲差异被神经网络成倍放大表格数据喂给神经网络之前最基础也最容易被忽略的一步就是标准化。我当时买了一个教训数据里的特征跨度大的吓死人。内存RAM是MB级别的整数几百到几千而像是否有蓝牙、是否支持4G这种特征取值只有0和1。直接把原始数值丢进网络数值大的特征在梯度计算中会占据绝对主导地位数值小的特征几乎学不到东西。举个具体的例子权重初始化通常服从均值为0、方差很小的高斯分布。输入特征动辄上千乘上权重再求和神经元的输入就会落在激活函数的饱和区。拿ReLU来说一旦负半轴输入过大梯度就变成0这个神经元就死掉了。模型训练很多个epoch之后部分神经元始终没有任何梯度更新表达能力等于废掉了一半。我在第一版代码里没有做标准化训练loss曲线看起来也在下降但验证集准确率一直在60%左右徘徊怎么都上不去。后来把全部特征过了一遍StandardScaler均值0方差1第一次跑完就看到了明显变化。2.2 特征之间藏着可以组合的信息这个数据集的20个特征里有一类信息特别有意思很多特征单独看没什么用组合起来却能把手机档次划分得很清楚。举个例子内存大小和存储空间两个特征分开看单独和价格区间的相关性都不算极强。但把两者做成一个比值比如存储/内存就近似于在表达这台手机的存储扩展倍率高端机和低端机的区分度一下子就出来了。类似的构造特征有摄像头总像素 主摄像头像素 前置摄像头像素反映拍照综合水电池容量 / 屏幕尺寸反映续航密度也是厂商分档定价的重要依据有无蓝牙、有无3G这类特征在样本里几乎全为1属于典型的低信息量特征我在特征工程阶段做了一件事对每个特征计算和标签的互信息Mutual Information把互信息趋近于0的特征直接删除同时构造上面几个组合特征。做完这步模型的输入维度从20降到了约16维但有效信息密度反而提升了。第二轮训练验证集准确率从64%升到了75%。2.3 类别分布和评估方式这个数据集本身是均衡的四个价格区间各占25%所以准确率作为评估指标是可靠的。但我在一开始犯过一个错误过早划分训练集和验证集导致验证集上出现过拟合的假象。后来我改用了5折交叉验证每次取一折做验证最后取平均。数据量只有2000条时单次划分的结果方差很大交叉验证能更稳定地反映模型真实水平。如果你自己动手做类似项目建议从一开始就用交叉验证来评估不要贪图省事用单次train_test_split。这个习惯在后续做模型融合时尤其重要——每个模型用不同的折来训练天然增加了模型之间的多样性。3. 特征工程与标准化从64%到75%的关键一步3.1 标准化操作的PyTorch实现PyTorch本身不做数据标准化这一步通常在数据加载之前用NumPy或者Pandas完成。我在项目里的做法是from sklearn.preprocessing import StandardScaler scaler StandardScaler() X_train scaler.fit_transform(X_train) X_val scaler.transform(X_val)注意一个细节fit_transform只在训练集上调用验证集和测试集统一用训练集上的均值和方差做transform。如果你不小心在整个数据集上fit了会引入未来信息导致验证集评估结果偏高但真实场景下表现会崩。这是初学者最容易踩的坑。标准化之后训练loss下降到收敛值的速度明显加快了。之前可能需要80个epoch才能看到loss明显下降标准化之后30个epoch就能达到差不多的水平。这背后的原因是标准化让损失函数的地形变得更加规整梯度下降的路径更直接不再有某个方向上梯度特别大、另一方向上特别小的情况。3.2 自定义Dataset的正确写法表格数据量不大用PyTorch的TensorDataset就能直接搞定但为了后面灵活做数据增强主要是给特征添加微小噪声我写了一个简单的自定义Datasetfrom torch.utils.data import Dataset, DataLoader class MobileDataset(Dataset): def __init__(self, X, y): self.X torch.tensor(X, dtypetorch.float32) self.y torch.tensor(y, dtypetorch.long) def __len__(self): return len(self.y) def __getitem__(self, idx): return self.X[idx], self.y[idx]用DataLoader加载时我把batch_size设置成了32。这个值是在后续对比实验中确定的——数据量小batch太大会让每个epoch的梯度更新次数过少训练不稳定batch太小如8则噪声太大收敛慢。32在这个项目里是一个平衡点。3.3 特征工程的操作清单我在这个阶段具体做了这些事你可以直接参考删除互信息接近0的特征删掉后验证集准确率提升了大约1~2%。构造存储/内存比值特征这个特征单独和标签的Pearson相关性在0.5以上非常强。构造电池容量×分辨率综合指数这个特征对旗舰机档位的识别帮助特别大。对连续特征做分位数变换把部分特征的分布拉成接近正态分布减少长尾对模型的干扰。做完这轮特征总数虽然减少但模型在验证集上的表现稳定提升了10个百分点以上。特征工程对小数据集的影响远大于网络结构变化这个结论在后来的多次对比实验里反复得到验证。4. 网络结构重构从越大越好到适配任务4.1 第一版网络错在哪我的第一版网络长这样输入层-256-128-64-输出层ReLU激活没有BatchNorm没有Dropout直接用Adam以0.001的学习率训练。这个结构在当时的直觉里很标准但对于2000条样本来说这个容量已经严重过剩了。神经网络的参数量一旦超过样本量就会开始背答案而不是学规律。训练集的loss可以降到非常低但验证集准确率就是上不去。我的验证集准确率掉到60%以下就是这个原因。后续我写了一个小实验脚本分别测试了隐含层宽度为256、128、64、32的网络发现这个数据集的最佳宽度在64到128之间再宽反而变差。宽度32虽然也能到80%以上但上限明显不如64和128。4.2 最终网络结构宽度适中、正则到位经过多轮调整最终的网络结构是这样的import torch.nn as nn class PriceClassifier(nn.Module): def __init__(self, input_dim, num_classes4): super().__init__() self.net nn.Sequential( nn.Linear(input_dim, 128), nn.BatchNorm1d(128), nn.ReLU(inplaceTrue), nn.Dropout(0.3), nn.Linear(128, 64), nn.BatchNorm1d(64), nn.ReLU(inplaceTrue), nn.Dropout(0.3), nn.Linear(64, 32), nn.ReLU(inplaceTrue), nn.Linear(32, num_classes) ) def forward(self, x): return self.net(x)有几个设计上的考量值得说BatchNorm放在Linear之后、ReLU之前。这个顺序是有讲究的。BatchNorm的作用是把上一层输出的分布拉回均值为0、方差为1的状态避免数据在经过线性变换后分布过于分散导致ReLU落入饱和区。如果先ReLU再BatchNorm则ReLU已经把负值截断成0了BatchNorm看到的分布已经失真效果大打折扣。Dropout只放在前两层最后一层不用。最后一层Linear直接输出分类logits如果在这里加Dropout等于在分类决策前故意丢弃信息通常会掉1~2个点的准确率。Dropout的rate取0.3而不是0.5因为数据集小、dropout过强反而导致欠拟合。4.3 为什么这个结构适合这个任务手机价格预测本质上是一个中等难度、低维度的表格分类任务。特征数量不多特征之间的非线性关系可以通过两到三层的MLP捕捉。更深的网络比如5层以上在这个数据上没有任何优势反而会因为梯度在反向传播中逐层衰减导致前几层几乎学不到有效的特征表示。这一点我是在对比实验里确认的把网络加深到5层之后训练集准确率达到了100%验证集却从85%掉到了80%左右过拟合非常明显。后来我在多个类似数据集上反复验证了同样的现象——表格数据用小模型图像数据用大模型这条直觉在大多数情况下是成立的。5. 训练策略调整把85%推到88%的最后一公里5.1 学习率调度别让模型一直在原地徘徊模型结构改好之后验证集准确率稳定在85%左右。接下来不管怎么加epoch准确率都上不去loss曲线在某个位置来回震荡。这时候我才意识到不是模型容量不够而是学习率已经不适合训练后期的梯度尺度了。Adam优化器虽然自带自适应学习率但全局学习率设置过高的话后期会在局部最优附近反复弹跳无法收敛到更精确的位置。我改用PyTorch的ReduceLROnPlateau以验证集loss为监控指标import torch.optim as optim optimizer optim.Adam(model.parameters(), lr0.001, weight_decay1e-4) scheduler optim.lr_scheduler.ReduceLROnPlateau( optimizer, modemin, factor0.5, patience10, verboseTrue ) # 每个epoch结束后 scheduler.step(val_loss)设置了patience10意思是如果验证集loss连续10个epoch没有下降就把学习率乘以0.5。从0.001降到0.0005再降到0.00025模型在验证集上的表现稳步提升最终稳定在88%左右。5.2 早停小数据集最实用的护身符2000条样本的训练集过拟合风险极高。即使加了Dropout和weight_decay训练超过一定epoch数之后验证集loss照样会反弹。我写了一个简单的早停逻辑patience 20 best_val_loss float(inf) best_model_state None epochs_no_improve 0 for epoch in range(max_epochs): train_one_epoch(...) val_loss evaluate(...) if val_loss best_val_loss: best_val_loss val_loss best_model_state copy.deepcopy(model.state_dict()) epochs_no_improve 0 else: epochs_no_improve 1 if epochs_no_improve patience: print(fEarly stopping at epoch {epoch}) break早停之后我把max_epochs设置在200但实际训练通常在第80到120个epoch之间就会触发早停。这里有一个细节早停的监控指标用验证集loss而不是验证集准确率。因为loss的变化比准确率更平滑不容易出现在准确率不变但loss已经恶化的盲区。5.3 标签平滑给模型一点点容错空间在最终版本中我还加了label_smoothing0.1的交叉熵损失。这个操作的原理是不要模型对训练集的标签100%确信而是留出10%的概率给其他类别。这样做能减少过拟合让模型的泛化边界更平滑。在PyTorch里实现很简单criterion nn.CrossEntropyLoss(label_smoothing0.1)这一项单独带来的提升大约1个百分点不算多但和其他优化叠加之后验证集准确率跨过了89%。标签平滑在分类任务里值得默认加上代价极小收益稳定。6. 从88%到91%模型融合和那些不起眼的细节6.1 三模型投票效果立竿见影到了88%左右单个模型的提升空间已经很小了。我尝试了更复杂的网络结构、更极端的Dropout、不同的激活函数效果都不明显。最后想到的是模型融合——用三个结构相同、但训练时使用了不同交叉验证折的模型对每个样本的预测结果做投票。三个模型的预测逻辑完全一致但因为训练集略有差异它们学到的决策边界不尽相同投票之后可以互相纠正各自的偏差。每次用5折交叉验证中的不同3折做训练集、不同2折做验证集相当于三个模型看到的数据分布有差异但总体相同。最终在验证集上的表现是三个模型的独立准确率分别为87.8%、88.3%、88.1%投票融合之后达到了90.5%。这个提升不是偶然的。投票融合本质上是降低了模型的方差——单个模型可能在某些样本上犯了偶然错误但多个模型在同一个样本上犯相同错误的概率要低得多。6.2 让训练结果可复现的随机种子设置到这一步我开始注意到一个之前忽略的问题同样是这个模型每次跑出来的验证集准确率会有1%左右的波动。这个波动来自PyTorch的随机初始化、DataLoader的shuffle顺序、以及CUDA上某些操作的随机性。为了让结果可复现我在训练脚本最前面固定了所有随机种子import random import numpy as np import torch def set_seed(seed): 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固定种子后验证集准确率从每次跑都不同变成了确定值这对后续调试非常关键。有一段时间我的模型一会儿89%一会儿87%并不是代码改错了而是随机性在作祟。固定种子之后每个实验之间的差异就只来源于代码本身了。6.3 最终版本的关键配置清单最终达到91%的模型完整配置如下供你直接复刻配置项取值输入特征特征工程后约16维网络结构128-64-32三层MLPBatchNorm Dropout(0.3)激活函数ReLU优化器Adamlr0.001weight_decay1e-4学习率调度ReduceLROnPlateaufactor0.5patience10损失函数CrossEntropyLoss label_smoothing0.1Batch Size32最大Epoch200早停patience20模型融合3个模型投票在这个配置下验证集准确率稳定在91%左右。单个最优模型约89%融合模型达到91%。最终提交测试集时准确率仍有约90%和验证集基本一致说明模型没有过拟合验证集。6.4 一个容易忽略的细节推理阶段要关闭Dropout模型融合之后我在推理阶段踩了一个让人哭笑不得的坑训练完的模型直接进入model.eval()准确率正常但如果在预测时忘了调用eval()模型仍处于训练模式Dropout层会继续随机丢弃神经元导致每次预测的结果都不稳定准确率直接掉了5个百分点以上。这两个模式的区别一定要记住model.train()BatchNorm使用当前batch的均值和方差Dropout激活model.eval()BatchNorm使用训练时累计的全局均值和方差Dropout关闭融合投票的时候我自己就是在这个地方栽了跟头。三个模型各跑一遍预测结果一会儿90%一会儿85%排查了半天才发现是忘了切换eval()。如果你复现这篇文章时发现准确率对不上第一件事请检查模型是否处于eval()模式。7. 提升的每一步都不是孤立存在的回头整理这趟优化之路我会这样概括64%到75%靠的是数据侧的努力75%到85%靠的是模型结构的适配85%到91%靠的是训练策略和模型融合。每一步的提升都建立在前面步骤的基础上如果你想跳过特征工程直接靠融合模型的天花板会低很多。我在项目结束后还做了一件事把同样的流程跑在另外两个公开的表格数据集上一个分类任务、一个回归任务结论高度一致——标准化和特征工程带来的收益最稳定模型结构的适配决定了上限训练策略和融合则是把上限转化为实际90%准确率的关键。如果你正在做类似的项目我给你的最具体建议是先把数据侧做扎实再谈网络设计。在这个项目里我花在特征工程上的时间远多于改网络的时间但每一分钟都值了。最后分享一个小技巧做对比实验的时候每次只改一个变量。我尝过一次性改掉三个超参数然后验证集准确率涨了5个百分点的甜头但那纯粹是一晚上比拼运气的自欺欺人。认真控制变量你才知道每一步提升到底来自哪里——这也是你能在下一个项目里复刻这些经验的前提。 
长河君 · 2026/9/30 17:41:29 · 阅读 1.2k PyTorch分类实战：从64%到91%准确率的优化全流程
1. 拿到的数据集和那个没人在意的64%先说结论这个项目不是用多么花哨的网络结构也不是调参调到手抽筋而是把一条完整的数据↔模型↔训练策略链路捋顺之后准确率自然从64%爬到了91%。如果你正准备拿PyTorch做分类任务或者做完了一个模型觉得怎么训都上不去这篇文章的思路应该能给你不少启发。先交代背景。我拿到的是经典的手机价格分类数据集2000条样本20个特征标签是0到3四个价格区间——低端、中端、高端、旗舰。样本量小得可怜特征全是硬件参数电池容量、内存、摄像头像素、屏幕尺寸、芯片主频之类没有图片、没有文本纯粹的表格式数据。第一次用PyTorch搭建了一个三层全连接网络跑基线验证集准确率64%。这个数字在四个类别均分25%的基准上不算差但距离能用还差得远。我一开始以为问题出在网络不够深、不够宽于是加层、加神经元结果准确率不升反降一度掉到60%以下。后来我才意识到这压根不是网络容量的问题——这是一个典型的小样本表格数据分类问题模型优化的重心根本不在把网络做得更大。如果你也遇到过类似情况——模型越改越复杂效果反而变差——大概率和我犯了同一个错误没有先搞清楚数据的质量、分布和特征之间的关系就直接把数据丢给了神经网络。这个项目整体走下来准确率提升的几个关键节点大致是这样的阶段关键动作验证集准确率基线原始特征直接喂入三层MLP64%第一轮特征工程 标准化75%第二轮重构网络结构 正则化85%第三轮训练策略调整 模型融合91%下面我把每一轮的思路、操作和踩过的坑详细拆开讲。2. 为什么基线只有64%数据里埋着三个雷2.1 特征量纲差异被神经网络成倍放大表格数据喂给神经网络之前最基础也最容易被忽略的一步就是标准化。我当时买了一个教训数据里的特征跨度大的吓死人。内存RAM是MB级别的整数几百到几千而像是否有蓝牙、是否支持4G这种特征取值只有0和1。直接把原始数值丢进网络数值大的特征在梯度计算中会占据绝对主导地位数值小的特征几乎学不到东西。举个具体的例子权重初始化通常服从均值为0、方差很小的高斯分布。输入特征动辄上千乘上权重再求和神经元的输入就会落在激活函数的饱和区。拿ReLU来说一旦负半轴输入过大梯度就变成0这个神经元就死掉了。模型训练很多个epoch之后部分神经元始终没有任何梯度更新表达能力等于废掉了一半。我在第一版代码里没有做标准化训练loss曲线看起来也在下降但验证集准确率一直在60%左右徘徊怎么都上不去。后来把全部特征过了一遍StandardScaler均值0方差1第一次跑完就看到了明显变化。2.2 特征之间藏着可以组合的信息这个数据集的20个特征里有一类信息特别有意思很多特征单独看没什么用组合起来却能把手机档次划分得很清楚。举个例子内存大小和存储空间两个特征分开看单独和价格区间的相关性都不算极强。但把两者做成一个比值比如存储/内存就近似于在表达这台手机的存储扩展倍率高端机和低端机的区分度一下子就出来了。类似的构造特征有摄像头总像素 主摄像头像素 前置摄像头像素反映拍照综合水电池容量 / 屏幕尺寸反映续航密度也是厂商分档定价的重要依据有无蓝牙、有无3G这类特征在样本里几乎全为1属于典型的低信息量特征我在特征工程阶段做了一件事对每个特征计算和标签的互信息Mutual Information把互信息趋近于0的特征直接删除同时构造上面几个组合特征。做完这步模型的输入维度从20降到了约16维但有效信息密度反而提升了。第二轮训练验证集准确率从64%升到了75%。2.3 类别分布和评估方式这个数据集本身是均衡的四个价格区间各占25%所以准确率作为评估指标是可靠的。但我在一开始犯过一个错误过早划分训练集和验证集导致验证集上出现过拟合的假象。后来我改用了5折交叉验证每次取一折做验证最后取平均。数据量只有2000条时单次划分的结果方差很大交叉验证能更稳定地反映模型真实水平。如果你自己动手做类似项目建议从一开始就用交叉验证来评估不要贪图省事用单次train_test_split。这个习惯在后续做模型融合时尤其重要——每个模型用不同的折来训练天然增加了模型之间的多样性。3. 特征工程与标准化从64%到75%的关键一步3.1 标准化操作的PyTorch实现PyTorch本身不做数据标准化这一步通常在数据加载之前用NumPy或者Pandas完成。我在项目里的做法是from sklearn.preprocessing import StandardScaler scaler StandardScaler() X_train scaler.fit_transform(X_train) X_val scaler.transform(X_val)注意一个细节fit_transform只在训练集上调用验证集和测试集统一用训练集上的均值和方差做transform。如果你不小心在整个数据集上fit了会引入未来信息导致验证集评估结果偏高但真实场景下表现会崩。这是初学者最容易踩的坑。标准化之后训练loss下降到收敛值的速度明显加快了。之前可能需要80个epoch才能看到loss明显下降标准化之后30个epoch就能达到差不多的水平。这背后的原因是标准化让损失函数的地形变得更加规整梯度下降的路径更直接不再有某个方向上梯度特别大、另一方向上特别小的情况。3.2 自定义Dataset的正确写法表格数据量不大用PyTorch的TensorDataset就能直接搞定但为了后面灵活做数据增强主要是给特征添加微小噪声我写了一个简单的自定义Datasetfrom torch.utils.data import Dataset, DataLoader class MobileDataset(Dataset): def __init__(self, X, y): self.X torch.tensor(X, dtypetorch.float32) self.y torch.tensor(y, dtypetorch.long) def __len__(self): return len(self.y) def __getitem__(self, idx): return self.X[idx], self.y[idx]用DataLoader加载时我把batch_size设置成了32。这个值是在后续对比实验中确定的——数据量小batch太大会让每个epoch的梯度更新次数过少训练不稳定batch太小如8则噪声太大收敛慢。32在这个项目里是一个平衡点。3.3 特征工程的操作清单我在这个阶段具体做了这些事你可以直接参考删除互信息接近0的特征删掉后验证集准确率提升了大约1~2%。构造存储/内存比值特征这个特征单独和标签的Pearson相关性在0.5以上非常强。构造电池容量×分辨率综合指数这个特征对旗舰机档位的识别帮助特别大。对连续特征做分位数变换把部分特征的分布拉成接近正态分布减少长尾对模型的干扰。做完这轮特征总数虽然减少但模型在验证集上的表现稳定提升了10个百分点以上。特征工程对小数据集的影响远大于网络结构变化这个结论在后来的多次对比实验里反复得到验证。4. 网络结构重构从越大越好到适配任务4.1 第一版网络错在哪我的第一版网络长这样输入层-256-128-64-输出层ReLU激活没有BatchNorm没有Dropout直接用Adam以0.001的学习率训练。这个结构在当时的直觉里很标准但对于2000条样本来说这个容量已经严重过剩了。神经网络的参数量一旦超过样本量就会开始背答案而不是学规律。训练集的loss可以降到非常低但验证集准确率就是上不去。我的验证集准确率掉到60%以下就是这个原因。后续我写了一个小实验脚本分别测试了隐含层宽度为256、128、64、32的网络发现这个数据集的最佳宽度在64到128之间再宽反而变差。宽度32虽然也能到80%以上但上限明显不如64和128。4.2 最终网络结构宽度适中、正则到位经过多轮调整最终的网络结构是这样的import torch.nn as nn class PriceClassifier(nn.Module): def __init__(self, input_dim, num_classes4): super().__init__() self.net nn.Sequential( nn.Linear(input_dim, 128), nn.BatchNorm1d(128), nn.ReLU(inplaceTrue), nn.Dropout(0.3), nn.Linear(128, 64), nn.BatchNorm1d(64), nn.ReLU(inplaceTrue), nn.Dropout(0.3), nn.Linear(64, 32), nn.ReLU(inplaceTrue), nn.Linear(32, num_classes) ) def forward(self, x): return self.net(x)有几个设计上的考量值得说BatchNorm放在Linear之后、ReLU之前。这个顺序是有讲究的。BatchNorm的作用是把上一层输出的分布拉回均值为0、方差为1的状态避免数据在经过线性变换后分布过于分散导致ReLU落入饱和区。如果先ReLU再BatchNorm则ReLU已经把负值截断成0了BatchNorm看到的分布已经失真效果大打折扣。Dropout只放在前两层最后一层不用。最后一层Linear直接输出分类logits如果在这里加Dropout等于在分类决策前故意丢弃信息通常会掉1~2个点的准确率。Dropout的rate取0.3而不是0.5因为数据集小、dropout过强反而导致欠拟合。4.3 为什么这个结构适合这个任务手机价格预测本质上是一个中等难度、低维度的表格分类任务。特征数量不多特征之间的非线性关系可以通过两到三层的MLP捕捉。更深的网络比如5层以上在这个数据上没有任何优势反而会因为梯度在反向传播中逐层衰减导致前几层几乎学不到有效的特征表示。这一点我是在对比实验里确认的把网络加深到5层之后训练集准确率达到了100%验证集却从85%掉到了80%左右过拟合非常明显。后来我在多个类似数据集上反复验证了同样的现象——表格数据用小模型图像数据用大模型这条直觉在大多数情况下是成立的。5. 训练策略调整把85%推到88%的最后一公里5.1 学习率调度别让模型一直在原地徘徊模型结构改好之后验证集准确率稳定在85%左右。接下来不管怎么加epoch准确率都上不去loss曲线在某个位置来回震荡。这时候我才意识到不是模型容量不够而是学习率已经不适合训练后期的梯度尺度了。Adam优化器虽然自带自适应学习率但全局学习率设置过高的话后期会在局部最优附近反复弹跳无法收敛到更精确的位置。我改用PyTorch的ReduceLROnPlateau以验证集loss为监控指标import torch.optim as optim optimizer optim.Adam(model.parameters(), lr0.001, weight_decay1e-4) scheduler optim.lr_scheduler.ReduceLROnPlateau( optimizer, modemin, factor0.5, patience10, verboseTrue ) # 每个epoch结束后 scheduler.step(val_loss)设置了patience10意思是如果验证集loss连续10个epoch没有下降就把学习率乘以0.5。从0.001降到0.0005再降到0.00025模型在验证集上的表现稳步提升最终稳定在88%左右。5.2 早停小数据集最实用的护身符2000条样本的训练集过拟合风险极高。即使加了Dropout和weight_decay训练超过一定epoch数之后验证集loss照样会反弹。我写了一个简单的早停逻辑patience 20 best_val_loss float(inf) best_model_state None epochs_no_improve 0 for epoch in range(max_epochs): train_one_epoch(...) val_loss evaluate(...) if val_loss best_val_loss: best_val_loss val_loss best_model_state copy.deepcopy(model.state_dict()) epochs_no_improve 0 else: epochs_no_improve 1 if epochs_no_improve patience: print(fEarly stopping at epoch {epoch}) break早停之后我把max_epochs设置在200但实际训练通常在第80到120个epoch之间就会触发早停。这里有一个细节早停的监控指标用验证集loss而不是验证集准确率。因为loss的变化比准确率更平滑不容易出现在准确率不变但loss已经恶化的盲区。5.3 标签平滑给模型一点点容错空间在最终版本中我还加了label_smoothing0.1的交叉熵损失。这个操作的原理是不要模型对训练集的标签100%确信而是留出10%的概率给其他类别。这样做能减少过拟合让模型的泛化边界更平滑。在PyTorch里实现很简单criterion nn.CrossEntropyLoss(label_smoothing0.1)这一项单独带来的提升大约1个百分点不算多但和其他优化叠加之后验证集准确率跨过了89%。标签平滑在分类任务里值得默认加上代价极小收益稳定。6. 从88%到91%模型融合和那些不起眼的细节6.1 三模型投票效果立竿见影到了88%左右单个模型的提升空间已经很小了。我尝试了更复杂的网络结构、更极端的Dropout、不同的激活函数效果都不明显。最后想到的是模型融合——用三个结构相同、但训练时使用了不同交叉验证折的模型对每个样本的预测结果做投票。三个模型的预测逻辑完全一致但因为训练集略有差异它们学到的决策边界不尽相同投票之后可以互相纠正各自的偏差。每次用5折交叉验证中的不同3折做训练集、不同2折做验证集相当于三个模型看到的数据分布有差异但总体相同。最终在验证集上的表现是三个模型的独立准确率分别为87.8%、88.3%、88.1%投票融合之后达到了90.5%。这个提升不是偶然的。投票融合本质上是降低了模型的方差——单个模型可能在某些样本上犯了偶然错误但多个模型在同一个样本上犯相同错误的概率要低得多。6.2 让训练结果可复现的随机种子设置到这一步我开始注意到一个之前忽略的问题同样是这个模型每次跑出来的验证集准确率会有1%左右的波动。这个波动来自PyTorch的随机初始化、DataLoader的shuffle顺序、以及CUDA上某些操作的随机性。为了让结果可复现我在训练脚本最前面固定了所有随机种子import random import numpy as np import torch def set_seed(seed): 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固定种子后验证集准确率从每次跑都不同变成了确定值这对后续调试非常关键。有一段时间我的模型一会儿89%一会儿87%并不是代码改错了而是随机性在作祟。固定种子之后每个实验之间的差异就只来源于代码本身了。6.3 最终版本的关键配置清单最终达到91%的模型完整配置如下供你直接复刻配置项取值输入特征特征工程后约16维网络结构128-64-32三层MLPBatchNorm Dropout(0.3)激活函数ReLU优化器Adamlr0.001weight_decay1e-4学习率调度ReduceLROnPlateaufactor0.5patience10损失函数CrossEntropyLoss label_smoothing0.1Batch Size32最大Epoch200早停patience20模型融合3个模型投票在这个配置下验证集准确率稳定在91%左右。单个最优模型约89%融合模型达到91%。最终提交测试集时准确率仍有约90%和验证集基本一致说明模型没有过拟合验证集。6.4 一个容易忽略的细节推理阶段要关闭Dropout模型融合之后我在推理阶段踩了一个让人哭笑不得的坑训练完的模型直接进入model.eval()准确率正常但如果在预测时忘了调用eval()模型仍处于训练模式Dropout层会继续随机丢弃神经元导致每次预测的结果都不稳定准确率直接掉了5个百分点以上。这两个模式的区别一定要记住model.train()BatchNorm使用当前batch的均值和方差Dropout激活model.eval()BatchNorm使用训练时累计的全局均值和方差Dropout关闭融合投票的时候我自己就是在这个地方栽了跟头。三个模型各跑一遍预测结果一会儿90%一会儿85%排查了半天才发现是忘了切换eval()。如果你复现这篇文章时发现准确率对不上第一件事请检查模型是否处于eval()模式。7. 提升的每一步都不是孤立存在的回头整理这趟优化之路我会这样概括64%到75%靠的是数据侧的努力75%到85%靠的是模型结构的适配85%到91%靠的是训练策略和模型融合。每一步的提升都建立在前面步骤的基础上如果你想跳过特征工程直接靠融合模型的天花板会低很多。我在项目结束后还做了一件事把同样的流程跑在另外两个公开的表格数据集上一个分类任务、一个回归任务结论高度一致——标准化和特征工程带来的收益最稳定模型结构的适配决定了上限训练策略和融合则是把上限转化为实际90%准确率的关键。如果你正在做类似的项目我给你的最具体建议是先把数据侧做扎实再谈网络设计。在这个项目里我花在特征工程上的时间远多于改网络的时间但每一分钟都值了。最后分享一个小技巧做对比实验的时候每次只改一个变量。我尝过一次性改掉三个超参数然后验证集准确率涨了5个百分点的甜头但那纯粹是一晚上比拼运气的自欺欺人。认真控制变量你才知道每一步提升到底来自哪里——这也是你能在下一个项目里复刻这些经验的前提。