YOLOv5训练源码精讲从 train.py 到 best.pt 的完整优化链路 【写在前面】 你有没有过这种感觉照着网上教程跑了训练但指标一掉就不知道怎么办—— 只能加epoch、改lr、换增强三连结果改了一圈说不清哪个有效。 这篇文章不讲玄学调参。我会用一个具体例子用YOLOv5训练一个安全帽检测模型 贯穿全文让你知道训练出问题该去哪找原因、该优先改什么、怎么证明改动真的有效。 看完之后你应该能够独立诊断训练问题、能系统性做对照实验、能向面试官 解释为什么这样设计。 你将获得三样东西 1一张训练主链路图知道问题该去哪里查 2一份高杠杆改点清单知道优先改什么 3一套单变量实验顺序知道怎么证明改动有效 一、为什么你调参无效——用一个具体例子说清楚 【场景带入你要训一个安全帽检测模型】 假设你现在要训一个安全帽检测器数据集有1000张标注图片。 你按教程跑了训练但发现mAP只有0.4远低于预期。 你的第一反应是什么 A. 加 epochs从300改成600 B. 调高学习率 C. 换数据增强策略 D. 不知道先试试再说 如果你选D恭喜你你和大多数人一样——缺少链路视角。 【链路视角是什么】 想象一下你家门口的快递柜。快递从入库到被你取出经历了 投递员放件 → 系统记录 → 柜子存储 → 你扫码取件 如果快递丢了你知道去哪个环节找投递出了问题找快递员系统出了问题找客服。 但如果你对整个流程没概念你就会在四个环节之间来回折腾还找不到原因。 训练YOLO也一样。Loss不降可能是 - 学习率设错了对应快递员环节 - 数据标注有问题对应柜子存储环节 - 增强策略不合适对应投递方式环节 没有链路视角就会盲目试参。有链路视角就能精准定位。 【训练流程的十个节点】 用安全帽检测的例子YOLOv5训练会经历这10个环节 节点1参数解析你输入了 --batch 16 --img 640 --epochs 300 节点2模型构建YOLOv5根据yaml文件构建了一个检测器 节点3权重加载你加载了COCO预训练权重 节点4冻结策略你设置了 --freeze 0-10 冻结backbone前10层 节点5优化器你用了SGD学习率0.01 节点6数据加载Dataset在读你拍的1000张安全帽照片 节点7训练循环每个epoch在算loss、反向传播、更新参数 节点8验证每隔几个epoch跑一次验证看mAP涨没涨 节点9保存模型mAP新高了保存为best.pt 节点10断点续训训练到一半断了从last.pt恢复 如果安全帽漏检严重问题可能在节点6数据集也可能在节点7损失权重 但如果你没这个地图你就会瞎改batch size和epochs——改完了发现没效果。 二、参数来源三个层次的优先级问题附安全帽案例 【三个层次的参数来源】 你在终端输入的每一行命令参数可能来自三个地方 第一层命令行参数 python train.py --batch 16 --img 640 --epochs 300 第二层hyp.yaml配置文件 里面写了 mosaic0.5、lr00.01、box0.05 等 第三层opt.yaml断点续训时 之前训练保存的快照恢复训练时会覆盖命令行参数 【安全帽项目的坑resume后batch没变】 你用1000张图训安全帽模型跑了200个epoch断电了。 你想继续训练同时把batch从16改成32 python train.py --resume runs/exp5/weights/last.pt --batch 32 结果batch还是16不是32。 为什么因为resume时opt.yaml里保存的batch16会覆盖你命令行的--batch 32。 正确做法 - 做法1完全新开训练 --batch 32断点续训的目的本就是恢复同一实验 - 做法2手动改opt.yaml里的batch值再resume 这个坑会导致你明明改了参数但不生效很多人绕了好久才发现是这个问题。 【实战建议】 训练开始时在日志里找opt打印确认这几个值对不对 batch、imgsz、lr0、weight_decay、epochs 养成这个习惯能避开70%的参数不生效问题。 三、预训练权重加载交集机制的通俗理解 【为什么叫交集加载】 你训练安全帽检测用的是COCO预训练权重。 COCO有80类安全帽不在COCO里。那预训练权重有用吗 有用但有限。 预训练权重加载的本质是取交集 假设COCO权重是一个装有100万个参数的盒子 你的安全帽模型需要50万个参数。 加载时会一个个检查盒子里这个参数你模型里有没有形状一样不一样 - 名字对上了 形状一样 → 加载进来 - 名字对不上 → 跳过你模型没这层 - 名字对上了 形状不一样 → 跳过你改了这层的结构 最终加载进来的就是交集。 【安全帽项目的例子】 你的安全帽检测模型把检测头从COCO的80类改成了1类只有安全帽。 结果 - backbone特征提取部分几乎100%加载因为结构和COCO一样 - 检测头最后的分类层加载率很低因为类别数完全不同 这说明改检测头类别的改动对预训练权重的影响很小。 改backbone结构的改动比如换通道数才会严重影响加载率。 【匹配率低于80%意味着什么】 训练日志会打印Transfering params [xxx/xxx] (xx%) 如果匹配率低于80%说明你的模型结构和预训练权重差得太多 预训练收益不明显基本上等同于从零训练。 四、冻结训练什么时候该冻结用一个故事说清楚 【为什么要冻结一个故事】 假设你是一个经验丰富的厨师被派去教一个新厨师做川菜。 你多年的手艺知道怎么切丝、怎么掌握火候、怎么调味就像预训练权重—— 这些基本功对新任务做安全帽检测仍然有用。 新厨师的灾难性遗忘 如果一上来就让他完全自由发挥他可能会用他原有的炒菜直觉来做川菜 反而把你教给他的刀工和火候控制给忘了——这就是灾难性遗忘。 冻结策略 让他先只学新菜的部分基本功先不动。 【三种冻结策略】 策略1全冻结只训head 适用你只有200张安全帽图数据少得可怜 效果收敛快但head能力受限安全帽检测精度可能到不了最优 策略2部分冻结冻backbone前几层 适用你有800张安全帽图领域有一定差异室内安全帽 vs 室外安全帽 效果大多数场景下的默认选择 策略3分阶段解冻 适用你有1500张图想最大化预训练收益 效果分三阶段——先只训head、再解冻后几层、最后全量微调 【安全帽项目什么时候该解冻】 经验法则观察head loss分类loss是否进入平台期 具体表现 - 连续5个epochcls_loss变化小于1% - 但训练集loss还有下降空间 - 同时满足上面两点 → 可以尝试解冻 解冻时记得学习率降到原来的1/10同时打开warmup避免参数大幅震荡。 【冻结和BatchNorm的关系】 BatchNorm层会维护均值和方差的统计量。 冻结后如果不把BN切换到eval模式 - BN还在用当前batch的数据更新统计量 - 但梯度已经不更新了 - 结果统计量和实际参数对不上推理时精度下降 YOLOv5的冻结操作会自动把对应BN层切成eval模式不用你手动处理。 五、输入尺寸640和416这些数字是怎么来的 【为什么必须是32的倍数】 YOLOv5的backbone做了5次下采样每次尺寸减半 640 → 320 → 160 → 80 → 40 → 20 每次下采样YOLO都能检测不同大小的目标 - 80×80特征图每个格子看8×8像素区域 → 负责小目标安全帽离镜头远时 - 40×40特征图每个格子看16×16像素区域 → 负责中目标 - 20×20特征图每个格子看32×32像素区域 → 负责大目标安全帽离镜头近时 【安全帽项目的实际影响】 如果输入图片是 640×500 - 640/3220没问题 - 500/3215.625不是整数 代码会怎么处理 - 方法1自动padding500→512两边填充灰边但这会改变目标的形状 - 方法2直接报错 如果目标被padding导致形变比如圆形的安全帽变成椭圆检测精度肯定下降。 【实战建议】 训练前把所有图片resize到统一尺寸640×640或416×416都行但必须32倍数。 推理时保持和训练时完全一样的预处理方式。 六、优化器和学习率训练能不能稳住的关键 【为什么默认用SGD而不是Adam】 做个比喻 - SGD 认准一条路就一直走下去 momentum累积方向虽然慢但稳 - Adam 每步都会调整方向更快但可能走偏 安全帽检测这种任务需要强泛化能力——你训完的模型要能检测各种场景下的安全帽 而不是只在某一两个场景下效果好。SGD更适合这个目标。 Adam/AdamW什么时候用 - batch很小8-16的时候 - 训练周期很短几十个epoch的时候 - 数据量很少的时候 【weight decay和安全帽项目的关系】 weight decay可以理解为一个惩罚项让模型不要过于依赖某一个特征。 有个坑effective_wd wd × (effective_batch / nbs) 什么意思 假设你之前用batch16训练现在改成batch64扩大4倍 如果其他参数不变实际上你的正则强度也扩大了4倍。 这可能导致模型欠拟合——不是学习率的问题是weight decay的问题。 【warmup为什么训练初期要用小学习率】 刚开始训练时模型参数是随机的梯度方向很不稳定。 如果一上来就用大学习率参数更新幅度太大可能直接跳到一个很差的位置。 warmup 用一个很小的学习率慢慢试探让模型先找到正确的梯度方向。 【EMA让验证指标更稳定的技巧】 EMA 维护一套影子权重每次更新只吸收当前权重0.01%的变化。 好处训练末期的参数在最优解附近震荡EMA帮你把这些震荡平滑掉。 在YOLOv5中你拿到的best.pt是EMA权重不是最后一个epoch的权重。 七、数据管线70%的问题出在这里 【Dataset在干什么】 用安全帽检测的例子Dataset做四件事 1. 找图片扫描images/目录找到所有.jpg文件 2. 找标签找同名.txt文件解析成[class_id, cx, cy, w, h]格式 3. 读图片用cv2读取图片做resize和归一化 4. 做增强Mosaic、MixUp、翻转、HSV调整 【文件命名最容易踩的坑】 安全帽数据集有4种常见问题 坑1文件名有空格 safety helmet .jpghelmet和.jpg之间有空格 路径解析时会认为文件名是 safety helmet 找不到对应的.txt 坑2文件名有隐藏字符 从Windows复制过来的文件名可能带了不可见字符 坑3大小写不一致 images/下是 SafetyHelmet.jpglabels/下是 safetyhelmet.txt Windows不区分大小写能找到Linux服务器就找不到了 坑4扩展名不统一 图片是 .JPG大写标签是 .txt小写 建议训练前写个脚本统一检查一遍。 【cache机制的双刃剑】 第一次跑训练YOLOv5会解析所有标签并缓存到.cache文件。 第二次启动时直接读cache跳过重新解析能加速Dataset构建。 但如果你手动改了标签cache不会自动更新 程序会继续读旧的cache你改了标注但指标没变化。 解决方法每次改完标签删掉对应的.cache文件。 【collate_fn为什么要加image index】 假设batch4就是4张图片一起前向传播。 输出是一个合并的大tensor但loss计算时必须知道 这条GT标签是第0张图的还是第1张图的 image index就在每条GT前插入一个数字表示属于哪张图。 没有这个GT和预测会错位loss计算完全错误。 八、数据增强不是越多越好 【安全帽项目的增强原则】 增强的目的是让训练数据模拟真实场景的多样性。 真实安全帽数据集的局限 - 样本有限拍了1000张 - 场景单一白天拍的夜晚场景少 - 目标形态单一大部分是正面照 增强就是用低成本的图像变换模拟高成本的真实场景多样性。 【为什么不能叠加太多】 假设你把mosaic设成1.0每张图都是4张合成的同时开了mixup。 结果每张训练图都是四张图混合的超级合成图 问题模型长期在过度人工的数据上训练 学到的东西不够贴近真实单一目标泛化到现场时效果反而下降。 【增强的执行顺序】 以默认配置为例mosaic开启 第一步Mosaic4图拼接 4张安全帽图拼成1张模拟多目标场景 第二步MixUp两图混合 把当前图和另一张图加权混合像素级blend 第三步几何变换 随机旋转-5°到5°、平移、缩放 关键GT框坐标必须同步变换否则标签和图对不上 第四步颜色域增强 HSV调整模拟不同光照白天/阴天/室内/室外 第五步翻转 水平翻转概率0.5 注意不做垂直翻转因为真实拍摄不会上下颠倒 【安全帽项目增强实验顺序】 每次只开一个增强观察3-5个epoch的趋势 第一步关掉mosaic和mixup只用HSV翻转 → 建立基线 第二步开mosaic看指标涨了多少 第三步开了mosaic之后如果类别之间容易混淆开mixup 第四步调整HSV范围如果白天夜晚场景都有 第五步调整翻转概率如果安全帽有方向性不能随意翻转 九、损失函数三个loss各自在干什么 【box_loss框的位置准不准】 box_loss负责衡量预测框和真实框的差距。 YOLOv5用CIoU它同时考虑 - 重叠面积两个框叠了多少 - 中心点距离框和框的中心离得远不远 - 宽高比框的形状像不像 类比安全帽检测中box_loss低意味着 预测框的位置和大小都和真实的安全帽框很接近 【obj_loss这个地方有没有目标】 obj_loss衡量模型有没有发现这里有安全帽。 正样本GT框中心点落在哪个格子哪个格子的anchor就是正样本 负样本背景格子没有安全帽 忽略样本GT框附近但不是正样本的格子 【cls_loss目标是什么类别】 cls_loss衡量如果有安全帽它是哪一类。 安全帽检测如果是二类安全帽/无安全帽 cls_loss就会很低如果模型能正确区分这两类。 【多尺度头损失平衡】 YOLOv5有3个检测头分别负责不同大小的安全帽 P3头80×80负责小的、远处的人 P4头40×40负责中等距离的 P5头20×20负责近处的大安全帽 默认权重是[4.0, 1.0, 0.4]小目标权重最高。 如果你发现远处的小安全帽总漏检 把P3权重从4.0调到6.0或8.0看有没有改善。 【Focal Loss解决的是什么问题】 背景格子没有安全帽的区域数量远远多于有安全帽的格子。 大量背景是简单样本模型很容易判断这里没东西。 Focal Loss的思路 - 简单样本产生的损失小 → 调低它的权重 - 难样本产生的损失大 → 继续重点优化 十、best.pt是怎么确定的 【fitness不是只看mAP】 best.pt的保存依据是fitness适应度不是单一的mAP。 典型公式fitness 0.1 × P 0.9 × mAP0.5:0.95 为什么要加权因为不同场景看重的东西不一样。 【安全帽项目的fitness调整】 场景1安全生产监控 漏检假阴性危险有人没戴安全帽你没检测出来 → 提高Recall的权重宁可多报警也不要漏检 场景2安全帽数量统计 误检假阳性导致计数错误 → 提高Precision的权重宁可少计也不要多数 场景3通用检测 没有明显偏好 → 用默认权重就行 【为什么最高Recall的epoch可能不是best】 假设某epoch - Recall 0.95几乎所有安全帽都找到了 - 但Precision 0.3一大堆误检把非安全帽也标成安全帽了 fitness 0.1 × 0.3 0.9 × 0.5 0.48可能比不过 Recall 0.8、Precision 0.7 的 epochfitness 0.71 所以best.pt不是找得最全的是综合表现最好的。 十一、排错清单安全帽项目常见问题 【问题1改了参数但指标没变化】 排查步骤 1. 看训练日志开头打印的opt确认参数真的生效了 2. 如果用了resume检查opt.yaml是否覆盖了你的修改 3. 如果改了hyp.yaml加个特殊注释比如 # DEBUG_001确认文件被读取了 4. 清理__pycache__避免跑的是旧代码 【问题2改了标签但指标不变】 排查步骤 1. 检查.cache文件有没有删 2. 可视化几张图确认标签框真的画在安全帽上了 3. 检查images/和labels/文件名是否完全对应 【问题3自己写的推理和官方推理结果差很多】 排查步骤 1. 预处理是否一致颜色通道RGB还是BGR、归一化/255、resize方式letterbox 2. 后处理是否一致conf_thres和iou_thres是否一样 3. 模型是否eval模式有没有漏.float() 4. 输出张量reshape顺序是否正确 【问题4loss发散第一个epoch就爆炸】 排查步骤 1. 梯度爆炸 → 加梯度裁剪或降低学习率 2. 学习率过高 → 从0.01降到0.001试试 3. 增强过强 → 关掉mosaic和mixup只用HSV翻转 4. weight decay没配合batch调整 → batch扩大4倍wd也要降低 十二、实验顺序一次只改一个 这是最重要的一节。很多人的问题是同时改了很多东西不知道哪个有效。 【第一阶段数据正确性验证】 在优化之前必须确认数据没问题。 操作 - 可视化10-20张图看GT框有没有画在正确位置 - 检查图片能不能正常读取 - 确认类别标签和图片内容一致 数据有问题优化一切白搭。 【第二阶段建立可信基线】 用最基础的配置跑完一个完整训练周期 - mosaic0, mixup0 - 只有HSV调整和水平翻转 - 记录best.fitness和对应epoch 这个基线的意义是基准不是最优。 增强越少训练指标可能越好看但泛化能力不一定最好。 【第三阶段逐个开启增强】 每隔3-5个epoch开启一个新的增强记录变化 - baseline → mosaic → mixup → 其他增强 知道每个增强单独带来的收益是正还是负。 【第四阶段损失权重调优】 观察哪个尺度小/中/大目标的AP最低。 小目标AP低 → 把P3权重从4.0调到6.0或8.0 【第五阶段IoU变体替换】 如果基础优化都做完了还有提升空间 - CIoU → DIoU → SIoU → EIoU - 每次替换跑20-30个epoch观察长期趋势 【第六阶段fitness权重校准】 根据业务目标调整fitness计算公式。 如果更看重Recall → 提高Recall的权重。 十三、面试回答模板 【问题YOLOv5训练流程是怎样的】 回答 YOLOv5训练分为10个节点参数解析、模型构建、预训练权重加载、冻结层处理、优化器初始化、Dataset构建、epoch循环包含前向传播、损失计算、反向传播、EMA更新、验证、模型保存、断点续训。 任何训练异常都可以先定位到具体节点。比如loss发散可能是lr过高节点5或增强过强节点6改了标签但指标不变几乎一定是Dataset或cache的问题节点6。 【问题预训练权重加载的交集机制是什么】 回答 加载时遍历checkpoint中的每个参数检查两个条件键名在当前模型是否存在shape是否一致。只有两个都满足才加载。 比如我改检测头类别数从80改成1backbone参数几乎100%加载因为结构没变。但检测头加载率很低因为shape完全不同。 这种设计允许在预训练权重基础上做结构改动不需要每次从零训练。 【问题如何诊断训练loss发散】 回答 按顺序排查四个方面 第一梯度爆炸。加梯度范数打印grad_norm超100就说明爆炸处理方法是降lr或开梯度裁剪。 第二lr过高。第一个epoch的loss就非常高比如10通常就是lr过高。 第三增强过强。关掉mosaic和mixup看loss曲线是否恢复正常。 第四batch和weight decay配合。effective_wd wd × (effective_batch/nbs)batch扩大后要同比降低wd。 核心思路一次只改一个因素观察是不是该因素导致的问题。 【问题best.pt是怎么确定的】 回答 best.pt按fitness综合评分决定不是单个指标。比如fitness 0.1×P 0.9×mAP0.5:0.95。 所以最高Recall的epoch可能不是best——Recall高但Precision很低fitness综合起来反而不高。 另外YOLOv5保存时用的是EMA权重不是训练末期的即时权重。EMA通过时间平均抵消高频波动通常更接近最优解。 十四、最终总结三个能力让你区别于其他调参者 第一个能力链路视角 能说出参数从哪来到哪去能定位任何训练异常到具体模块。 第二个能力系统优化 有计划地建立基线、逐项实验、记录对照用数据证明这个改动有效。 第三个能力工程闭环 训练和推理全链路保持一致能设计符合业务目标的fitness规则。 当你同时具备这三个能力你就已经不是会跑YOLO了 而是会优化YOLO。