1. 项目概述1.1 做鸟类识别最难的不是模型而是数据鸟类图像识别在计算机视觉领域里算是一个经典细分方向但真正上手做过的朋友应该深有体会算法本身不是最卡脖子的环节怎么把数据准备好、怎么处理类间相似度极高的小目标问题才是最磨人的。常见的应用场景有生态保护区鸟类监测、观鸟爱好者拍照辅助识别、机场鸟击防范预警甚至农业领域的益鸟招引统计。这些场景普遍存在一个共性痛点——相机拍到的鸟往往占比很小背景又杂乱传统分类网络一遇到多目标场景就抓瞎而目标检测网络又容易漏检小鸟。我这次选择yolov5来做鸟类图像识别主要是看中了它在工业界的成熟度训练部署链路完整、中文资料多、硬件要求相对友好。虽然现在yolov8、yolov9甚至yolov10都已经出来了但在实际项目中yolov5依然是一个非常稳的选择尤其是配合官方预训练权重做迁移学习的时候收敛速度和小目标表现都很有保障。加上官方仓库长期维护社区排障经验丰富遇到问题基本都能搜到解决方案。这篇文章我会从数据准备、环境搭建、模型训练、优化技巧到推理部署全程复盘一遍我实际做鸟类识别项目的思路和踩坑记录给正在做类似工作的朋友一个可以直接参考的路线图。1.2 用yolov5做鸟类识别整体技术路线是什么整个项目的技术链路可以拆成四个阶段数据工程、模型训练、性能调优、部署推理。数据工程是工作量最大的部分包括采集图像、清洗筛选、标注格式转换、数据增强模型训练阶段核心是选好预训练权重和超参数性能调优阶段要围绕鸟类识别最常见的两个痛点——小目标漏检和相似物种混淆——做针对性优化部署推理阶段则是把训练好的模型导出成不同格式适配不同硬件场景。我最终训练出的模型mAP0.5能到0.93左右mAP0.5:0.95在0.72上下对于20类常见鸟类数据集来说这个结果已经能支撑实际使用了。单张1080P图像在GTX 1660 Super上的推理耗时约32ms基本可以满足准实时检测的需求。这套技术方案同样适用于其他细分类目标检测项目比如昆虫识别、鱼类识别、小型野生动物监测核心思路是完全通用的。2. 数据集构建决定模型上限的关键环节2.1 数据采集渠道与类别设计思路鸟类识别的数据集构建有一个比较头疼的问题不同鸟种之间的外观差异有时候比跨物种还小。比如黄腹山雀和绿背山雀在野外光线条件下连资深鸟友都容易看走眼。这就决定了我们在设计类别的时候不能一味求“多而全”而是要结合应用场景决定识别粒度和类别清单。我的做法是先确定目标场景是“城市公园常见鸟类识别”所以最终圈定了20类麻雀、喜鹊、灰喜鹊、乌鸦、八哥、白头鹎、绿绣眼、珠颈斑鸠、山斑鸠、乌鸫、家燕、白鹡鸰、树鹨、黄腹山雀、大山雀、红头长尾山雀、棕头鸦雀、白颊噪鹛、黑脸噪鹛、画眉。这个清单兼顾了常见度和特征区分度20类对于起步阶段也比较好管理。数据采集渠道我用了三个一是公开数据集比如从Kaggle、iNaturalist、Caltech-UCSD Birds等平台筛选合规可商用的图片这个来源能提供大量不同姿态、不同光照条件的样本是数据基础盘。需要提醒的是务必记录每张图的来源和授权协议避免后续商用踩坑。二是自己拍摄补充这样做最大的价值不是“多几张图”而是可以针对性地补足项目场景的特殊角度——比如仰拍视角、逆光条件、远处小目标。我大概补拍了1500多张占比不高但对测试集鲁棒性的提升非常明显。三是网络图片爬取通过爬虫按物种名批量抓取然后人工筛选。这部分质量参差不齐需要花大量时间清理但胜在量大、姿态多样。有一点值得专门说鸟类图像识别的数据容易“看起来很多实际有效的不多”。我最初下载了接近四万张图按“目标是否清晰、是否有遮挡、是否被裁切过度、是否是真实拍摄而非插画”这四个标准筛选之后只剩下约12500张可用图。筛选标准宁可严格一些因为一张模糊或遮挡严重的坏图会让模型在训练时学会错误的特征关联。2.2 标注格式转换与细节规范yolov5使用的标注格式是每个图像对应一个同名txt文件内容格式为“类别ID 中心点x 中心点y 宽度 高度”其中坐标值都是相对于图像宽高的归一化值。如果之前用的是LabelImg的VOC XML格式或者labelme的JSON格式需要先做一次格式转换。这里我踩过一个大坑LabelImg导出的XMLxmin、ymin、xmax、ymax是像素坐标要转成归一化格式时必须先用像素坐标减半再除以图像宽高。公式是xc ((xmin xmax) / 2) / image_width yc ((ymin ymax) / 2) / image_height w (xmax - xmin) / image_width h (ymax - ymin) / image_height写脚本的时候容易把分子分母搞反导致训练时loss直接不收敛。我的建议是转换完成后做一次可视化校验把标注框画回原图随机抽200张逐一检查这个步骤虽然烦琐但能拦下大量低级错误。标注工具我用的是X-anylabeling相比LabelImg它支持自动标注辅助可以在yolov5s模型预测结果基础上做人工修正。对于鸟类这种目标数量多、轮廓复杂的数据自动标注能节省至少60%的时间但自动标注的结果一定要人工复查尤其是边缘模糊的小鸟目标。2.3 数据划分与增强策略数据划分我采用了严格的分层抽样按类别比例将数据集分成train/val/test 8/1/1。之所以强调分层是因为如果随机划分可能出现某个类别全部落在训练集或测试集里的极端情况导致验证指标虚高或失真。数据增强方面yolov5自带了一系列在线增强策略在hyp.scratch-low.yaml中可以看到配置项。我根据鸟类识别的特点做了针对性调整hsv_h、hsv_s、hsv_v这几个颜色扰动参数适当调大因为鸟类羽毛颜色在不同光照下变化很大增强颜色扰动可以提高模型对光线变化的鲁棒性。fliplr0.5水平翻转保持默认这对鸟类来说是安全增强因为左右翻转不会改变物种特征。mosaic1.0开启这是yolov5最核心的增强手段把四张图拼成一张训练能大幅提升模型对小目标的识别能力。但mosaic数据分布和真实场景差异较大所以建议在最后30个epoch关闭mosaicyolov5代码中通过--evolve或者手动调参支持让模型在真实分布上精调。我还额外做了离线增强来补充小目标样本把包含小鸟目标的图像随机裁剪放大1.5到2倍后再加入训练集专门强化模型对“画面中占比很小”的鸟的识别效果。这个操作对mAP0.5:0.95的提升实测有3到4个点非常划算。3. 环境配置与训练准备3.1 服务器环境与依赖版本选择用yolov5训练模型硬件的选择逻辑很简单显存决定batch size上限显存越大训练越省心。我这次用的是单卡RTX 3090 24GB训练20类12500张图、300个epoch耗时大约11个小时。如果你的显卡显存较小比如8GB那就把batch size降到8或4同时把图像尺寸从640降到512一样能跑只是精度会有一定损失。软件环境方面我给出一份实测可用的版本组合Python 3.8.10 CUDA 11.3 cuDNN 8.2.0 PyTorch 1.10.0 torchvision 0.11.0 numpy 1.21.0 opencv-python 4.5.4.58之所以建议用Python 3.8而不是3.10是因为yolov5的老版本对Python 3.10有些兼容性问题尤其是一些依赖库没有及时更新跑起来容易出莫名其妙的报错。如果你拿到的是最新版yolov5代码可以适当放宽版本限制但最好还是按官方README里的要求来。安装依赖非常简单git clone https://github.com/ultralytics/yolov5 cd yolov5 pip install -r requirements.txt注意yolov5官方仓库更新频繁建议固定版本号而不是直接clone最新的main分支比如git checkout v6.0或v7.0这样能保证训练参数和代码行为的一致性也方便后续复现。3.2 数据集目录结构与配置文件编写yolov5对数据集目录结构有约定俗成的规范虽然不是强制但按规范来能让后续操作顺畅很多。我的目录结构是bird_dataset/ ├── images/ │ ├── train/ │ ├── val/ │ └── test/ ├── labels/ │ ├── train/ │ ├── val/ │ └── test/ └── bird.yamlimages和labels目录底下的train、val、test子目录名称必须一一对应。yolov5在训练时通过读取图片路径自动替换images为labels来寻找对应的标签文件所以如果目录结构不一致会直接报错找不到标签。bird.yaml的内容如下# 鸟类识别数据集配置 train: /data/bird_dataset/images/train val: /data/bird_dataset/images/val test: /data/bird_dataset/images/test nc: 20 # 类别数量 names: [sparrow, magpie, azure-winged-magpie, crow, crested-myna, light-vented-bulbul, green-white-eye, spotted-dove, oriental-turtle-dove, chinese-blackbird, barn-swallow, white-wagtail, olive-backed-pipit, yellow-bellied-tit, great-tit, red-headed-tit, vinous-throated-parrotbill, white-browed-laughingthrush, masked-laughingthrush, hwamei]这里有一个容易出错的地方names列表的顺序必须和标注时分配的类别ID一一对应。比如标注时麻雀是0那么names列表第0个元素就必须是sparrow。如果顺序错乱训练出来的模型会“张冠李戴”识别结果完全混乱。3.3 预训练权重选择别小看这一步yolov5官方提供了s、m、l、x四种规模的预训练权重它们的参数量和mAP大致呈正比。选择的原则是在显存允许的前提下模型越大精度越好但推理速度越慢。我最终的方案是选择了yolov5s作为基础模型而不是更大的yolov5l或者yolov5x。原因有三点一是鸟类识别场景中目标通常较小而大模型并不一定能显著提升小目标识别能力反而会因为参数量大、训练数据量不够而出现过拟合。二是推理速度是实际项目的重要指标。保护区部署场景中往往用的是边缘设备比如Jetson Nano或者树莓派这些设备跑大模型非常吃力。yolov5s的参数量和计算量都很适合边缘部署。三是迁移学习的效果yolov5s在COCO上的预训练权重已经学到了丰富的通用特征鸟类数据集虽然是新领域但底层特征边缘、纹理、颜色分布是通用的用小模型做迁移学习足够。如果你做的是高精度要求的离线识别任务可以尝试yolov5m或yolov5l。我的经验是当数据量在1万到2万张这个量级时yolov5s和yolov5l的最终精度差距通常在2到4个mAP点以内但推理速度差距可能在3倍以上。4. 模型训练从参数设定到收敛判断4.1 超参数配置与解释yolov5的超参数配置涉及两个文件一个是模型结构文件yolov5s.yaml一个是训练超参数文件hyp.scratch-low.yaml。很多新手在训练时完全不碰这两个文件直接用默认参数跑这样做确实能出结果但离“好用”还有距离。我实际使用的训练命令是python train.py \ --data bird.yaml \ --cfg yolov5s.yaml \ --weights yolov5s.pt \ --batch-size 16 \ --epochs 300 \ --img 640 \ --hyp hyp.scratch-low.yaml \ --workers 8 \ --device 0下面逐个解释关键参数的含义和我的选择理由batch-size3090显存跑yolov5sbatch-size 16比较合适。batch-size过大会导致显存溢出过小则训练不稳定。一个经验公式是batch_size ≈ 显存(GB) / 模型大小(GB)以yolov5s为例模型大约占1.5GB显存24GB显存可以跑到12到16。epochs300个epoch听起来多但yolov5的mosaic增强、学习率衰减策略等都是配置为长时间训练服务的300个epoch在这个数据量级属于正常范围。我实测到大约第180个epoch时mAP开始趋于平稳后面100多个epoch带来的提升非常有限大概只有0.5到1个点。如果时间有限200个epoch是一个更经济的选择。img训练图像尺寸640x640是yolov5的默认值对大多数场景够用。如果目标鸟很小可以尝试896甚至1280但显存和训练时间会成倍增加。我做了一组对比实验同样条件下640训练的模型mAP0.5:0.95是0.72提升到896后是0.75但训练时间从11小时变成27小时。这个提升幅度是否值得取决于你的实际场景。workers数据加载线程数建议设置为CPU核心数的一半或者等于核心数但过高反而会导致数据加载成为瓶颈。8是3090配合16核CPU时的合理值。4.2 训练过程中的关键监控指标训练启动后不是干等结果就行需要实时关注几个关键指标判断训练状态是否健康。第一个是Box Loss它反映的是边界框回归的误差正常情况下应该在训练过程中持续下降并最终收敛在一个较小的值附近。如果box loss在某个阶段突然升高可能是学习率设置过大也可能是数据里有标注错误的坏样本。第二个是mAP0.5在训练前100个epoch内它可能会比较低甚至一直为0这是正常的不用慌张。mAP0.5从0开始上涨意味着模型开始学到有效特征。如果在4到50个epoch内mAP始终为0反而需要警惕可能是标注文件路径配置错误也可能是names顺序和标注ID对不上。第三个是验证集的Precision和Recall。理想情况下两者应该同时上升。如果precision高但recall低说明模型检出结果多数是对的但漏检严重如果recall高但precision低说明模型检出了很多错的东西。这两个指标需要结合来看。训练过程中yolov5会在runs/train/exp目录下实时保存训练曲线图、验证集检测结果示例、模型权重文件。我习惯每隔50个epoch去翻一下验证集的可视化结果看看模型预测的鸟框是否有整体偏移、有没有把背景物体误检成鸟。4.3 收敛判断与早停策略yolov5自带EarlyStopping机制当模型在连续patience个epoch内mAP没有提升时会自动停止训练。默认patience100这个值偏保守了。实际操作中我建议通过观察训练曲线手动干预如果mAP0.5:0.95连续30个epoch没有变化基本可以判断已经收敛再继续训练只是浪费时间。判断收敛时还有一个容易忽略的细节要看验证集指标而不是训练集指标。训练集上的loss会持续下降直到一个非常小的值但这不代表模型泛化能力好。验证集指标才是模型真实能力的反映。我在第二轮训练时改变了策略设置--patience 50最终在第243个epoch触发早停比第一轮少了近60个epoch节省了约2小时训练时间最终精度反而比第一轮略高一点。这是因为过度训练会让模型在训练集上开始“死记硬背”而早停在这之前截住了这个趋势。5. 精度优化解决小目标漏检和类别混淆5.1 小目标增强策略鸟类识别的最大痛点就是小目标漏检。一只站在远处树枝上的麻雀可能只有32x32像素大小在640x640的输入图像中占比不到1%。yolov5的默认anchor对这样的小目标支持有限如果不做优化漏检率会很高。我试过三种方案按效果排序如下第一种是增加输入图像分辨率。从640提升到896小目标尺寸在输入图像中占比变大更容易被模型捕捉。但缺点是训练时间和显存占用显著增加。实测mAP0.5:0.95提升约3个点如果硬件允许是性价比最高的方案。第二种是利用SAHI切片推理。SAHISlicing Aided Hyper Inference的核心思路是把大图切分成多个小图块分别推理最后合并结果。比如把1080P图像切分成4个640x640的图块重叠比例20%检测效果相当于用更高分辨率做了检测。我用SAHI配合640训练的模型实测小目标recall从0.71提升到0.84提升非常明显。缺点是推理时间变为原来的4到5倍适合离线批处理场景。第三种是调整anchor尺寸。yolov5的anchor是在COCO数据集上聚类得到的COCO里目标普遍偏大和鸟类场景不完全匹配。可以关闭自动anchor计算在代码里增加Anchor聚类操作让anchor自动适配你的数据集目标尺寸分布。具体做法是在yolov5/utils/autoanchor.py中运行k-means。不过我实测感知提升有限可能只带来1到2个mAP点的改善而且操作不当会引入新的不稳定性新手可以先跳过这步。5.2 解决相似物种混淆问题鸟类识别中相似物种混淆是非常头疼的问题。比如大山雀和黄腹山雀主要区别是腹部颜色和头部花纹细节人在远距离都容易分辨错模型自然更容易混淆。我的解决思路是“特征增强数据平衡”双管齐下。特征增强方面我在数据增强中增加了对小目标区域的局部放大策略从训练图像中裁剪出包含鸟类目标的小块放大后单独作为一张训练图像。这样做强制模型学习鸟类的细节特征而不是只依赖整体轮廓。数据平衡方面我先统计了每个类别的样本数量发现画眉只有342张而麻雀有1560张。样本量差距过大会导致模型对少样本类别学习不充分。我在训练过程中采用了类别加权采样让每个类别在每轮训练中出现的频率尽量均衡。在yolov5中可以通过修改dataset代码或者简单地在数据集中过采样少样本类别来实现。这两个手段叠加让mAP0.5:0.95从最初的0.63提升到了0.72。中间还尝试过用Focal Loss来缓解类别不平衡但yolov5默认的损失函数已经是CIoUBCEWithLogits的组合效果已经不错换上Focal Loss后提升不明显。5.3 模型集成与测试时增强如果你追求极致精度而不太在意推理速度可以用模型集成和测试时增强TTA来再挤出几个点。模型集成很简单训练三个模型比如yolov5s、yolov5m、yolov5l推理时把三个模型的预测结果做加权融合。集成的本质是让不同模型的“偏见”互相中和。实测三个模型集成能将mAP0.5:0.95从0.72提升到0.76但推理时间变为原来的三倍。TTA是指推理时把图像做多种变换翻转、缩放、旋转分别预测后合并结果。yolov5官方代码支持--augment参数开启TTA实测能提升1到2个mAP点但推理时间会增加4倍以上。我的建议是如果项目是离线分析场景可以用模型集成TTA的组合能榨出不少精度如果是实时检测场景老老实实只用一个模型把延误控制在可接受范围内更重要。6. 模型部署与推理实践6.1 模型导出与格式选择训练完成后yolov5支持导出多种推理格式PyTorch的.pt、ONNX、TensorRT的.engine、OpenVINO、CoreML等。导出脚本非常方便python export.py --weights runs/train/exp/weights/best.pt --img 640 --batch 1 --include onnx engine这里有几个需要特别留意的地方一是导出TensorRT格式时必须指定与训练时相同的图像尺寸否则后续推理时输入尺寸不匹配会报错。同时TensorRT引擎第一次运行时会做层融合优化耗时较长但之后推理速度会非常快。二是ONNX导出后建议用onnx-simplifier做一次简化删除冗余算子能减少约10%到20%的推理耗时。三是如果目标平台是Jetson系列直接用TensorRT格式是最优解。我在Jetson Nano上用TensorRT FP16推理yolov5s单帧耗时约85ms勉强达到实时/准实时水平如果换成FP32直接翻倍到170ms左右。6.2 Python推理脚本与后处理下面是我实际使用的推理脚本去掉了无关内容保留了最核心的检测流程import cv2 import torch import numpy as np # 加载模型 model torch.hub.load(ultralytics/yolov5, custom, pathbest.pt, force_reloadTrue) model.conf 0.35 # 置信度阈值鸟类场景不宜设太高 model.iou 0.45 # NMS的IoU阈值 model.classes None # 不过滤类别 # 推理单张图片 img cv2.imread(test_bird.jpg) results model(img, size640) # 解析结果 boxes results.xyxy[0].cpu().numpy() for box in boxes: x1, y1, x2, y2, conf, cls_id box label f{model.names[int(cls_id)]} {conf:.2f} cv2.rectangle(img, (int(x1), int(y1)), (int(x2), int(y2)), (0, 255, 0), 2) cv2.putText(img, label, (int(x1), int(y1) - 5), cv2.FONT_HERSHEY_SIMPLEX, 0.5, (0, 255, 0), 1) cv2.imwrite(result.jpg, img)置信度阈值我这里设置的是0.35比常用默认值0.25要高一些。这是因为鸟类识别的误报会直接导致后续统计结果失真宁可少检一点也不能乱检。如果发现漏检严重再逐步下调到0.25左右。后处理部分最容易忽略的是类别映射模型输出的是类别ID必须通过names列表转换为可读名称。很多人会在这里忘记写names映射推理结果全是“0 0 0”这样的编号。6.3 边缘设备部署经验在实际项目中把yolov5部署到Jetson Nano这类边缘设备才是真正考验人的环节。我踩过的坑主要集中在三个地方一是PyTorch版本与JetPack版本的兼容问题。Jetson Nano自带的JetPack版本决定了你能安装哪个版本的PyTorch。比如JetPack 4.6对应的是Python 3.6和PyTorch 1.10。我用的是JetPack 4.6 PyTorch 1.10.0的组合实测稳定建议直接按这个配置来。二是推理速度达不到预期的问题。Jetson Nano的CPU性能很弱如果直接用ONNX Runtime CPU推理速度极慢。必须用TensorRT加速并且开启FP16。我导出.engine格式后在Jetson Nano上推理yolov5s1680x960的图像耗时约180ms这个速度做定时抓拍分析完全足够做实时视频流检测就比较紧张了。三是多线程推理时的显存管理问题。GPU显存不太够用当视频流分辨率过高时容易导致显存溢出。我的解决思路是在推理前先压缩图像到1280或960宽度同时开启torch.cuda.empty_cache()定期清理缓存。实测压缩到1280宽度损失约1个mAP点但推理速度提升了一倍多这笔交易在边缘场景是很划算的。7. 常见问题与排查技巧实录7.1 训练阶段常见报错与解决按我接触到的项目经验训练阶段的报错虽然五花八门但绝大多数都集中在几个固定模式上。最先遇到的基本都是环境问题比如CUDA out of memory这个多半是batch size设太大了。我习惯先把batch size调到2跑一个短迭代确认能跑通后再逐步往上加比直接开大会省心得多。然后是数据路径问题。yolov5在本地测试时用的都是相对路径但如果把数据集放到服务器上路径配置不对就会报FileNotFoundError。这类错误的定位思路是先确认bird.yaml里的路径在服务器上真实存在再确认yaml文件里没有使用Windows风格的反斜杠路径最后确认训练命令是在yolov5项目根目录下执行的。还有一个高发问题模型权重加载错误。如果用yolov5x的权重文件去配yolov5s.yaml的模型结构直接报错因为两者的网络结构层数不一样。尽量保证--cfg和--weights的模型规模一致。7.2 推理阶段预测结果不理想怎么办推理结果不理想通常有两种截然不同的表现一种是该检出的没检出漏检另一种是不该检出的检出了一堆误检。这两种情况的优化方向完全不同。漏检多发时优先检查置信度阈值是否设置过高。在鸟类识别场景中模型对小鸟的置信度天然较低如果阈值设成0.5很多小鸟都会被过滤掉。我的经验是候选目标区域特别小时适当放低阈值然后用后续的跟踪或统计逻辑来过滤无效结果。误检多发时看训练数据里是否包含了与背景环境相似度很高的负样本。我有一次做园区鸟类监测模型总是在悬挂的树叶间误检出“鸟”后来排查发现训练集中大量鸟图都带绿色背景模型把“绿色圆形轮廓”当成了鸟的特征。解决方法是多收集一些纯风景、树叶、天空等无鸟背景图标注为空让模型学会区分。第三种情况是框的定位不准。比如框住了鸟的半个身体或者框明显偏移。这通常是标注质量的问题尤其是边界框过紧或过松。yolov5对边界框回归比较敏感建议在数据集里随机抽检标注框发现偏移严重的就重新标注。7.3 数据与标注相关的隐性坑最后集中说几个不太容易被发现、但影响很大的数据问题。一个是类别样本数量失衡。某些类别样本量特别少比如画眉只有300多张模型学到的特征不充分。我的对策是过采样少样本类别同时稍微调低这些类别的置信度阈值让它们在推理时更容易被检出来。第二个是图像中目标极小且密集。有些场景里一棵树上几十只鸟每只鸟只有十几个像素人工标注都很难标准。这种情况下yolov5的模型能力已经到极限了单纯的算法优化意义不大。更实际的方案是用更高像素的输入或者靠图像切片推理去解决。第三个坑是可信度标注错误。我在筛选公开数据集时发现有部分图片的物种标签本身就是错的可能是上传者误标。这类错误样本混入训练集危害极大——模型会学到完全错误的类间差异。我最后做了一次全量标签复核按类别逐张检查所有训练图片虽然花了两天时间但避免了模型“学歪”的风险。提示这类数据质量问题的排查优先级很高。数据问题导致的精度瓶颈再怎么调模型结构都解决不了。怀疑数据有错误时最快的方法不是看指标而是随机抽一批训练图可视化亲眼看看标注框和标签是否合理。8. 项目总结与个人体会整个基于yolov5的鸟类识别项目做下来我最大的体会是这个项目真正的难点不在“跑通yolov5”而在于构建一个高质量的数据集并针对鸟类场景特有的问题做优化。类别混淆、小目标漏检、边缘设备部署每一个环节都需要从数据和推理策略两个维度去解决而不是单纯指望模型结构本身。如果你也要做类似的项目我建议优先保证数据质量而不是一味追求模型规模和训练时长。一个干净的数据集配合yolov5s往往能打败一个充满噪声数据集配yolov5x。最后再分享一个小技巧训练完成后不要只看mAP指标就结束。把模型部署到目标硬件上用真实场景的视频流跑一遍观察实际漏检误检情况。模型评估指标和实际项目体验之间往往存在差异只有经过真实场景检验的模型才算是真正“能用”的模型。