1. 流水线的整体设计与模块拆解先说结论这条深度学习的“总流程”代码本质上解决的是工程化边界问题。很多开发者第一次接触深度学习时写代码的顺序是“先import keras再想网络”结果训到一半发现数据切分忘做评价指标没写可视化曲线也没有最后只能补丁叠补丁。而一套结构清晰的流水线代码把“数据处理、模型构建、训练驱动、评估导出”四件事彻底分开每个环节都有明确的输入输出约定这才是能拿来做实验、复现结果、甚至交给别人接手的东西。我用过的这条“liner代码”总流程采用的是一种“控制流与数据流分离”的设计。控制流就是训练的总循环数据流就是数据从磁盘到GPU的搬运和预处理管线。两条线并行推进但互不纠缠。这样做的好处非常明显当你想换一个网络结构时只需要改模型模块当你想换一份数据集时只需要改数据模块。训练引擎对这两样东西的改动完全无感知。我个人在实际操作中的体验是这种模块化隔离对于新手尤其重要。因为新手最容易犯的错误就是把数据预处理的代码和模型定义的代码写在一起最后改任何一处都会牵动全局。把流程拆开之后每一个环节都能独立测试、独立调试心理负担小很多出错定位也快得多。这套流水线的目录结构一般是这样组织的project_root/ ├── configs/ # 配置文件目录存放yaml/json ├── data/ # 数据集存放目录 ├── model/ # 模型定义目录 ├── utils/ # 工具函数包括日志、指标计算 ├── train.py # 训练总入口 ├── eval.py # 评估入口 └── requirements.txt # 依赖清单配置驱动的思想贯穿全程。训练的超参数、数据路径、模型类型、学习率策略全部放在一个yaml配置文件里而不是硬编码在训练脚本中。这样做的好处是你拿同一份代码随便改几个配置项就能在多个实验之间平滑切换不需要动任何核心代码。2. 数据链路从原始文件到模型输入数据处理是整个流水线中最容易翻车的一环。很多人在Kaggle或者其他公开数据集上跑demo没事一换自己的业务数据就各种报错——有的是标签格式不对有的是图像尺寸问题有的是数据增强比例没控制好。这套流水线在数据处理环节做得比较扎实核心思想是“让数据代码只知道数据不知道模型”。2.1 数据集类的抽象与组织在PyTorch框架下数据集类主要实现三个关键方法__init__、__len__、__getitem__。这条流程代码中的数据集类设计有一个值得学习的地方它把“文件读取”和“样本变换”分成了两个阶段。__init__阶段只做路径的收集和索引的建立不做实际的图像读取。也就是说初始化的时候只是得到一个“哪些文件属于训练集、哪些属于验证集”的清单。真正的读文件、解码、变换操作放到__getitem__阶段执行。这个设计看起来很朴素实际上对性能影响很大。假设你的数据集有一万张图片如果初始化时就全部读进内存内存占用会非常可怕如果在初始化时只存路径每次取样本时再读那么内存压力就完全消失了。配合DataLoader的多进程加载读取时间是完全可以被隐藏到训练耗时中的。class BalancedDataset(Dataset): def __init__(self, file_list, label_list, transformNone, phasetrain): self.file_list file_list self.label_list label_list self.transform transform self.phase phase def __len__(self): return len(self.file_list) def __getitem__(self, index): img_path self.file_list[index] image cv2.imread(img_path) image cv2.cvtColor(image, cv2.COLOR_BGR2RGB) label self.label_list[index] if self.transform: image self.transform(image) return image, label注意这里没有写死任何具体的图像尺寸。尺寸缩放的处理通常统一放在transform中这样数据集类就变得非常通用——今天跑一个224x224的分类任务可以用它明天跑一个512x512的分割任务也可以用它只要修改配置文件里的输入尺寸参数即可。2.2 数据划分与验证集隔离的艺术验证集的构建是这个流程中最容易被忽视但实际影响最大的环节。简单粗暴地随机抽样百分之二十作为验证集在某些任务上是够用的但对于类别不均衡的数据集来说随机抽样很可能导致验证集中缺少某些样本种类或者在某一折上验证集分布和训练集分布差别过大造成验证指标失真。这套流程推荐的方案是“分层抽样”。核心逻辑是先按照标签把样本分组然后从每个组内按比例抽取验证集样本。这样不管你的数据有多不均衡验证集的类别分布都能保持和全量数据集大体一致。还有一个细节经常被新手忽略就是“数据泄露”问题。如果训练集和验证集中出现了来自同一来源的重复或者高度相似的样本最终的验证指标会虚高看起来成绩很好一上线就崩。解决办法是在划分阶段就保证同一来源的样本只能出现在一个集合中而不是简单随机打乱。比如某类样本中有一组是从同一个视频或者同一个设备采集的多帧图像应该把这整个组都归入训练集或者整个归入验证集不能打散。2.3 数据增强策略不要一上来就上强度我看过很多流水线代码在数据增强上做得非常激进随机裁剪、旋转、颜色抖动、mixup、cutmix全上一遍。看起来实验很丰富实际上往往会给调试带来巨大的干扰。我的经验是数据增强的强度应该是逐步叠加的先在无增强或者弱增强的条件下跑通整个流程确认模型能够正常收敛之后再逐步增加增强策略的强度。为什么会这样因为数据增强本质上是人为扩大了数据分布的范围如果一开始就上强增强模型可能根本学不动你很难判断是网络结构的问题、学习率的设置问题还是数据增强的问题。而先用弱增强跑通流程确认模型没问题再加增强这样每一步的变量都是可控的。这套流程代码中数据增强采用的是albumentations库它和PyTorch的衔接非常顺畅。最关键的一点是用Compose把多个变换组合起来并且保证训练阶段和验证阶段使用不同的变换管线——训练阶段可以有翻转、裁剪验证阶段只做resize和归一化。train_transform A.Compose([ A.Resize(256, 256), A.RandomCrop(224, 224), A.HorizontalFlip(p0.5), A.ColorJitter(brightness0.2, contrast0.2, saturation0.2), A.Normalize(mean[0.485, 0.456, 0.406], std[0.229, 0.224, 0.225]), ToTensorV2(), ]) val_transform A.Compose([ A.Resize(224, 224), A.Normalize(mean[0.485, 0.456, 0.406], std[0.229, 0.224, 0.225]), ToTensorV2(), ])3. 模型组织从示例网络到可扩展架构模型模块的设计决定了这个流水线的上限。如果模型定义写得乱七八糟各种分支堆叠在一个函数里那么后续想换网络结构、加载预训练权重、修改输出层都会变成一场噩梦。这条流水线在模型组织上的设计思路值得拿来说一说它采用了一种“基类约定子类实现”的策略。3.1 模型基类约定模型基类做的事情非常纯粹定义好前向传播的接口、参数初始化的标准流程、以及权重加载的统一入口。具体的网络结构全部放到子类中去实现。这样做的好处体现在几个方面。第一评估代码和被评估的模型类别完全解耦。一份评估脚本可以评估任何继承自基类的模型因为基类已经保证了所有子类都有相同的加载权重和接收输入的接口方式。第二便于做实验对比。你可以用同一套训练代码只修改配置文件中的模型名称字段就能在两个完全不同的网络结构之间来回切换。模型的结构是由配置项决定的而不是改代码。class BaseModel(nn.Module): def __init__(self): super().__init__() def forward(self, x): raise NotImplementedError def load_pretrained(self, weights_path): state_dict torch.load(weights_path, map_locationcpu) self.load_state_dict(state_dict, strictFalse) print(f[LOAD] Pretrained weights loaded from {weights_path})strictFalse这个参数用得巧。它的含义是加载权重时允许有部分层的权重不匹配。这样设计是为了解决一种常见场景你自己改了一个分类头类别数量和预训练模型不一致因此分类头那几层的权重形状发生了变化。如果用strictTrue加载会直接报错而strictFalse会跳过那些形状不匹配的层只加载能对齐的部分。3.2 分类头的灵活配置这个流水线代码里还做了一个很贴心的小设计把总分类数和dropout比例通过配置文件传入模型。这样当你从二分类改成十分类、或者给全连接层加一点dropout来防止过拟合时不需要修改任何模型代码只要改配置就完成了。class CustomClassifier(BaseModel): def __init__(self, num_classes, dropout_rate0.1): super().__init__() self.backbone models.resnet18(pretrainedFalse) self.global_pool nn.AdaptiveAvgPool2d((1, 1)) self.dropout nn.Dropout(dropout_rate) self.fc nn.Linear(512, num_classes) self._init_weights() def forward(self, x): x self.backbone(x) x self.global_pool(x) x torch.flatten(x, 1) x self.dropout(x) x self.fc(x) return x为什么不直接在__init__里用models.resnet18(pretrainedTrue)因为预训练权重的下载很依赖网络环境很多开发环境的网络策略不允许随意下载外部文件。把pretrained参数置为False然后通过load_pretrained方法手动加载本地权重这样既保留了使用预训练模型的选项又保证了在离线环境下代码依然可以运行。这个设计我觉得很实用。3.3 权重初始化的“为什么”_init_weights方法做的是对最后一层分类头的权重做均匀分布初始化。很多人会问“既然PyTorch的默认初始化已经可以跑为什么还要手动初始化”原因在于默认初始化是针对一般情况的对于分类头来说采用更集中的参数初始化范围可以让模型在早期训练阶段更加稳定减少数值不稳定带来的损失剧烈抖动。实际动手做一个简单的分类任务时这个细节可能看不出太大差别。但当任务复杂化、类别数变多、网络层数变深时最后一层初始化的方差控制就显得重要了。这是一个典型的“训练早期稳定性”问题花费的代码只有三行但是收益是真实的。4. 训练驱动配置、日志、可视化与断点续训训练引擎是整个流水线的心脏区域。这个环节最考验代码的工程化水平因为训练循环本身并不复杂——一个for循环嵌套另一个for循环难的是在这个循环外面做好工程化的包装。4.1 配置文件的加载逻辑整个流程用yaml文件作为唯一的配置源。注意这里的措辞——“唯一”。这是有意为之的。有些团队用argparse传参参数要么写很多有的团队直接在代码里写默认参数又想切换配置。这两个方案都有问题argparse的命令行参数没法做实验记录的历史归档代码里的默认参数隐身于代码逻辑中追踪率低。yaml配置方案的逻辑是这样的所有实验的光学参数都存在于一个独立的yaml文件中代码中通过读取这个文件来获取配置并且在做实验时复制一份yaml文件作为实验记录的附件。data: train_path: ./data/train val_path: ./data/val batch_size: 32 num_workers: 4 input_size: 224 model: name: CustomClassifier num_classes: 10 dropout_rate: 0.1 train: epochs: 100 lr: 0.001 momentum: 0.9 weight_decay: 0.0001 scheduler: cosine log_interval: 20在代码中加载yaml相当简单PyTorch官方风格的训练代码中通常都是这么做的import yaml def load_config(config_path): with open(config_path, r, encodingutf-8) as f: config yaml.safe_load(f) return config持久化是一个非常重要的工程意识。训练到一半代码报错了、机器重启了、或者你想调整参数再来一发如果没有持久化之前的训练全部作废。这套流水线代码通过一种方式解决了这个问题实验记录机制。在做每一轮实验时代码会自动创建一个带时间戳的文件夹用来存放模型权重、日志文件、配置文件副本。这个文件夹的命名方式一般长这样./runs/20250110_1532_lr0001_batch32/ ├── checkpoints/ ├── logs/ └── config_backup.yaml文件夹的名字里带上了关键的超参数组合这样就省去了翻日志的功夫一眼就能知道这个实验跑的是什么配置。这个设计我认为很值得点赞因为深度学习实验的复现性在很大程度上依赖于实验记录的制度。4.2 优化器与学习率策略的选型逻辑优化器的选择直接关系到模型最终的性能。对于绝大多数任务来说Adam或者SGD加动量这两种选择就能覆盖大部分场景。它们之间的差别我总结成一句话Adam收敛快但最终精度可能略低于调好的SGDSGD收敛慢但调好后往往能达到更好的泛化性能。一个中庸而稳妥的做法是在训练初期或者快速验证阶段使用Adam快速看到模型能不能收敛等到最终实验时切换成SGD加余弦退火调度策略争取达到更高的精度。在代码实现上学习率调度器需要注意的一个细节是PyTorch的cosine调度器的生命周期是按epoch来计算的。如果你中途改了训练的epoch总数那么余弦曲线的形状就会变化最后几步学习率的下沉速度也会不同。所以调优过程中一旦设置好epoch总数最好不要轻易变动。4.3 训练循环的结构与日志系统训练循环本身是高度程序化的前向传播、计算损失、反向传播、更新权重。但一个合格的总流程在循环内部还得做好这样几件事梯度裁剪、损失值平滑、模型在验证集上的周期性评估、以及日志的输出。梯度裁剪这个操作容易被忽略但它对训练稳定性的贡献非常大。特别是当你使用类似Transformer这样的结构或者学习率设置得偏高时梯度范数可能在某个batch上突然变得极大导致参数更新一步跨出十万八千里之后模型就再也回不来了。做了梯度裁剪相当于给参数更新加了一个“安全阀”让单步更新的大小被限制在可控范围内。来看这段典型的训练代码结构for epoch in range(start_epoch, config[train][epochs]): model.train() running_loss 0.0 for batch_idx, (inputs, labels) in enumerate(train_loader): inputs, labels inputs.to(device), labels.to(device) optimizer.zero_grad() outputs model(inputs) loss criterion(outputs, labels) loss.backward() torch.nn.utils.clip_grad_norm_(model.parameters(), max_norm5.0) optimizer.step() running_loss loss.item() if batch_idx % config[train][log_interval] 0: current_lr optimizer.param_groups[0][lr] print(fEpoch [{epoch}/{config[train][epochs]}] fBatch [{batch_idx}/{len(train_loader)}] fLoss: {loss.item():.4f} LR: {current_lr:.6f}) val_loss, val_acc evaluate(model, val_loader, criterion, device) scheduler.step() save_checkpoint(...)我在实际使用中发现损失值的平滑处理对判断训练状态非常有帮助。单步的损失值会上下剧烈跳动就像股市的日线图一样难以分辨大趋势。在日志里输出的最好是一个平滑后的损失值——比如维护一个滑动平均这样能更直观地看到损失的整体走向是持续下降、震荡不动还是一路飙升。4.4 断点续训实验的“后悔药”断点续训是深度学习中必不可少的功能但它经常被新手写到代码里的位置不对导致中途挂掉后无法恢复。在这个流水线中断点信息当前epoch号、模型状态、优化器状态、学习率调度器状态被完整地打包保存为一个权重文件。def save_checkpoint(state, filename): torch.save(state, filename) # 在训练循环中 checkpoint { epoch: epoch, model_state_dict: model.state_dict(), optimizer_state_dict: optimizer.state_dict(), scheduler_state_dict: scheduler.state_dict(), best_val_acc: best_val_acc, } save_checkpoint(checkpoint, f./runs/current_exp/checkpoints/epoch_{epoch}.pth)恢复训练时只需要通过torch.load加载这个文件然后把对应的状态分别传回模型、优化器和调度器再设置起始epoch为保存的epoch值即可。注意这里的优化器和调度器状态也必须保存否则恢复时只能恢复模型参数学习率的进度会丢失接下来几轮的学习率策略会错乱。按照我的经验只存模型参数不存优化器状态是断点续训中最常见的坑。4.5 训练可视化让曲线变成眼睛事件可视化工具的好处是很多人低估了的。很多人觉得看终端里打印的loss值就行但当你同时跑三四个对比实验时终端的滚动字符很难做出直观对比。把loss曲线和验证精度曲线画在同一张画布上几个实验之间的对比一目了然模型的过拟合趋势也能非常直观地暴露出来。在代码中接入可视化工具是非常简单的关键是在训练循环里恰当的位置加上记录语句from torch.utils.tensorboard import SummaryWriter writer SummaryWriter(log_dir./runs/current_exp/logs) # 在验证结束后执行 writer.add_scalars(loss, { train: train_running_loss_avg, val: val_loss, }, epoch) writer.add_scalars(accuracy, { val: val_acc, }, epoch) writer.add_scalar(lr, current_lr, epoch)5. 评估、导出与部署训练结束只是开始很多开发者的习惯是把评估逻辑写在训练脚本里训完直接测试一下完事。但这种方法不够规范化因为在同一份脚本里训练逻辑和评估逻辑会互相干扰。这套流程把评估单独作为一段独立的代码存在它做的事情是从训练好的权重机器中加载模型、跑完整验证集、计算出各种指标、并且把模型的输出导出为文件供后续分析或者部署服务使用。5.1 指标定义与选择指标的选择取决于任务类型。分类任务看准确率、召回率、F1值回归任务看MSE和MAE分割任务看mIoU和Dice系数。这套代码中默认包含了对多分类任务通用的指标计算逻辑从混淆矩阵出发计算每一类的精确率、召回率、F1分数然后得到宏平均和微平均。要注意的一个细节是二分类问题和多分类问题在指标计算上是有区别的。二分类需要特别关注正例的定义多分类则需要决定是采用宏平均还是微平均。宏平均对每个类平等对待哪怕这个类的样本很少微平均则更偏向样本多的类别。在实际业务中如果数据不均衡这两者的数值差异会非常大。所以评估代码必须允许用户手动指定要计算哪种平均方式。5.2 混淆矩阵与错误案例分析除了数值指标可视化分析手段也不可或缺。混淆矩阵可以直观地告诉你“模型把哪个类和哪个类搞混了”。当训练出的模型出现偏差时混淆矩阵往往能比准确率更快地指认问题根源。比如你训练一个区分猫、狗、鸟三类网络混淆矩阵显示“鸟”这一类被大量预测成“猫”。如果训练集里猫的样本数量远大于鸟的样本数量那么这个问题的根源很可能是数据不均衡。如果训练集本身是均衡的那么就要考虑是不是特征提取阶段对毛细腻纹理的特征表示不够好。另外我还习惯在评估模块里加入一个“错误样本保存”的小功能把预测错误的图片连同正确的标签和预测的标签一起保存到本地文件夹中。这看起来不起眼但在实际业务调试中作用巨大。你可以直接翻错误样本的照片用常识去判断模型是因为什么原因犯错的——光照变化、遮挡关系、类别相似性这些信息是纯数字指标给不了的。5.3 模型导出与部署思路训练好的模型最终是要用的不管是为了做推理加速、还是部署成在线服务都需要把PyTorch的模型导出成一种可以被轻量级推理框架读取的格式。最简单和安全的导出方式是使用标准推理格式。这一步的基本操作是model.eval() dummy_input torch.randn(1, 3, 224, 224).to(device) with torch.no_grad(): torch.onnx.export( model, dummy_input, model.onnx, opset_version11, input_names[input], output_names[output], )导出时有几个坑需要避开。第一dummy_input的尺寸必须和模型预期的输入尺寸完全一致包括batch维度。第二如果你在模型的前向传播中有任何非标准的操作比如自定义python控制流导出时可能会报错。第三导出一定要在model.eval()模式下进行否则模型中的BatchNorm和Dropout层行为会不一致导致导出的模型推理结果和训练时不一致。部署时通常还会考虑量化、蒸馏等手段来压缩模型体积。这部分工作不是训练流水线的直接职责但训练时把模型设计的模块化对后续部署的改造工作帮助巨大——比如你的分类头和骨干网是分开定义的那么部署时删掉分类头、提取特征向量就非常容易。6. 常见问题与调试实录这一段我想集中整理一下我在复现这套流程或类似流水线代码时实际踩过和反复处理过的一些典型问题。这些问题的分布是很有规律的——主要集中在数据、设备、数值稳定性三类。6.1 数据处理相关的高频错误问题现象根本原因解决方案训练到某一步报错“文件找不到”数据划分时文件名拼接错误或者路径中混入了中文/特殊字符检查文件路径统一使用绝对路径或者规范的相对路径确保标签文件与图像文件的名称一一对应图像通道数报错部分图片是灰度图只有单通道而代码假设全部是RGB三通道加载时统一转换为RGB或者用稳健写法判断通道数并做相应转换验证集准确率极高但线上效果很差数据泄露检查数据集划分逻辑确认同一来源的数据不会同时出现在训练和验证集多进程加载数据时报错num_workers设置过大导致内存溢出逐步调低num_workers观察内存占用找到合适的数值一个非常隐蔽的坑是当数据量很大时某些深度学习框架的数据读取机制依赖于内存中的共享内存映射。如果代码在多个子进程中同时大量读取文件会导致内存暴涨系统出现假死。解决方法是把num_workers调低或者检查是否有文件句柄没有被关闭。6.2 训练过程中的数值问题训练loss出现NaN是最让人头疼的问题之一。原因有很多常见的就包括学习率过大导致损失函数值震荡上溢播种了NaN。损失函数中有log运算而输入了一个0值。某些数据中存在异常值比如标签不在有效范围内。混合精度训练时缩放因子更新不当。排查NaN问题有一个标准流程先在CPU上用小规模数据跑一个前向传播观察loss是否正常。如果正常再用单张图片过一遍训练循环观察有没有问题。如果单张图片还是正常可能是数据整体分布的问题这时候就要去看是否存在异常样本。我的习惯是在一次训练的全过程中开启“异常检测”模式一旦loss值出现了非有限数值立即通过assert torch.isfinite(loss)中断训练并且打印出当前batch的数据信息把那个有问题的样本单独保存下来。这样就能快速定位到是哪张图片引起的数值异常而不是等到训练跑完。6.3 显存管理问题显存不足OOM是每一轮深度学习实操中必然遇见的问题。OOM诊断起来不复杂但解决方案的选择却体现经验。通常的切入点有三个第一个是看batch size能不能减小第二个是看是不是梯度累积造成的显存占用过大第三个是检查常用框架在训练模式下是否有不必要的中间变量被保存。但很有意思的一点是很多OOM问题不是真正的显存不够而是前一个实验的进程没有完全退出显存还被人占用着。我经常遇到跑新实验时发现显存已经被占满查看GPU进程列表时发现是早前调试时留下的僵尸进程。所以遇到OOM第一步永远是nvidia-smi查看进程列表而不是着急缩减batch size。带来较大提升的做法是用梯度累积来模拟更大的batch size。显存不足时把batch size调小然后通过梯度累积步数来平衡优化效果的稳定性和显存的占用accumulation_steps 4 optimizer.zero_grad() for batch_idx, (inputs, labels) in enumerate(train_loader): outputs model(inputs) loss criterion(outputs, labels) loss loss / accumulation_steps loss.backward() if (batch_idx 1) % accumulation_steps 0: optimizer.step() optimizer.zero_grad()6.4 模型不收敛的排查路径如果训练了几个epoch损失几乎不下降或者验证集准确率一直停留在某个低水平我建议按以下顺序逐一排查先检查数据是否正确。用可视化脚本把数据集的样本打印出来看一遍标签是否对齐、图片内容是否符合预期。再检查模型输出是否正确。单独跑一个前向看模型的输出层维度是否和损失函数期望的一致样本数量是否大于类别数。然后看损失值的大小是否符合常规。分类问题的初始交叉熵损失应当约等于ln(num_classes)如果差很远说明模型的参数初始化可能有严重问题。最后确认优化器的参数。学习率太低会学不动太高又会震荡甚至炸掉。这套排查路径的核心思想是把“谁坏了”的嫌疑从数据、模型、损失函数、优化器这四个模块中一步步排除。大多数情况下问题都会在“数据”或者“学习率”这两步被定位到。7. 一些我个人的经验总结这套总流程我跑下来最大的感受是——深度学习项目的工程化程度决定了你实验的下限。调参调的再好如果实验记录一团糟、代码结构混乱、无法复现那么实验结果的可信度就大打折扣。在长时间实操里我发现几条帮助显著的规律第一实验记录比调参更重要。跑一个实验之前先建立好内容的归档结构。我一开始只记录模型权重和准确率后来发现完全不够因为中间修改过的数据处理逻辑、临时加的图像增强、为了兼容某个样本而写的特殊分支这些代码改动如果不记录一个月后回看实验连自己都看不懂。所以现在每次跑实验都同步记录配置文件、数据划分方式、代码版本号、以及运行环境详情。第二不要迷信复杂的技巧。很多刚入门的朋友特别喜欢叠加各种高级技术混合精度训练、分布式数据并行、自动数据增强、EMA优化、知识蒸馏……每一样都是好东西但每一件都会增加系统的调试复杂度。我见过太多项目因为同时上了几个高级技术而无法定位问题到底出在哪一环。正确的做法是先用基础配置把训练流程完整跑通得到一个baseline然后再一项一项地添加复杂度。这样每一项新技术带来的收益和潜在问题都能得到验证和掌握。第三踩坑记录要随手写下来不要把代码跑通当做结束。每次解决一个调试问题我都会记下问题表象和根因时间久了这就是一份很个人的排查手册。遇到新问题先翻自己的笔记往往能直接跳过两次三遍的简单的排查路径。“好记性不如烂笔头”这句话在做深度学习时体现得尤为明显。如果你现在正打算开始搭建自己的深度学习代码流程我建议你直接基于一套结构清晰的总流程来修改而不是从零开始用一个脚本打天下。好的工程基础能让你把更多的精力放到模型设计、数据质量和业务分析上而不是反复纠缠于“数据为什么加载不进去”这类基础问题。跑通了整套流程之后你会发现后面的很多实验说白了就是换配置文件和换模型文件的事。
