简介面向yolo系列算法目标检测入门与实战的蜜蜂、大黄蜂及黄蜂识别数据集适合使用yolov5/7/8/9/10/11的开发者快速上手模型训练与验证。压缩包共2000个文件约73.77MB包含1230个xml标注文件和770个txt标注文件分别对应VOC格式与yolo格式标签并已按训练、验证、测试划分好配有data.yaml配置文件下载后可直接调用训练。数据集覆盖蜜蜂、大黄蜂、黄蜂等目标类别标注内容含类别索引、归一化中心坐标与宽高能满足目标检测项目从数据准备、模型训练到效果评估的完整流程。目前已有69人学习下载适合需要现成标注数据、希望省去手动标注时间的算法学习者和工程实践者。1. 1404张带标签的蜂类图像这套YOLO数据集到底能解决什么问题蜂箱门口蜜蜂和入侵的大黄蜂混在一起时人眼还能勉强分辨摄像头就完全不够用了。这套数据把这件事拆成了一个能直接上手的目标检测任务1404张图像标注对象分蜜蜂、大黄蜂、黄蜂三类标签文件已经按YOLO格式排好解压就能喂给yolov8训练自己的数据集。它最大的价值不在数据量而在场景集中——大部分图像来自蜂箱入口、花丛、树干这些真实拍摄位置模型训练完可以直接用在蜂箱入侵预警、果园授粉统计这些实际任务上。适合正在做农业视觉、边缘端检测或者想用现成数据集打通YOLO训练全流程的人。下面我按从解压到出权重的顺序把数据格式、训练参数和踩过的坑一次讲完。2. 拆解数据集目录结构、YOLO标签格式与类别分布拿到压缩包先别急着训练。先花十分钟把数据结构和标注内容看清楚能避免后面百分之八十的翻车。这一章我按自己处理数据集的老流程来先看目录再读标签最后做类别分布统计。三步走完这套数据能不能用、要怎么调參心里基本就有数了。2.1 标签文件里到底存了什么从一行标注看YOLO格式解压之后常见YOLO数据集目录一般长这样dataset/ ├── images/ │ ├── train/ │ │ ├── bee_001.jpg │ │ ├── bee_002.jpg │ │ └── ... │ └── val/ │ ├── bee_101.jpg │ └── ... ├── labels/ │ ├── train/ │ │ ├── bee_001.txt │ │ ├── bee_002.txt │ │ └── ... │ └── val/ │ └── ... └── data.yaml这套目录结构是YOLO系列的标准布局images下按训练集和验证集分目录labels里是跟图像一一对应的txt文件名字相同、后缀不同。data.yaml里写类别信息训练时直接引用。挑一个标签文件用文本编辑器打开每一行对应一个目标框格式是五个数字0 0.4852 0.3613 0.1234 0.0876 1 0.7231 0.5168 0.0654 0.0912这五个数字的含义按顺序是类别编号、目标中心点的x坐标、中心点的y坐标、目标宽度、目标高度。注意后四个值全部做了归一化除以了图像自身的宽和高所以取值范围在0到1之间。类别编号从0开始计数对应data.yaml里names列表的下标。读取标注的时候有一个最容易忽略的细节YOLO格式里框的坐标是中心点加宽高不是左上角加右下角。很多人做数据可视化验证时直接按坐标画框结果框全部偏到右上角就是这个原因。我一般会写个十几行的脚本把标注框叠加回原图确认一遍再进训练这笔时间花得非常值。import cv2 # 把YOLO格式的txt标注画回原图用于人工核对 image_path dataset/images/train/bee_001.jpg label_path dataset/labels/train/bee_001.txt img cv2.imread(image_path) h, w img.shape[:2] with open(label_path, r) as f: for line in f.readlines(): cls, x_c, y_c, bw, bh map(float, line.strip().split()) # YOLO存的是归一化中心点坐标换算回像素 x1 int((x_c - bw / 2) * w) y1 int((y_c - bh / 2) * h) x2 int((x_c bw / 2) * w) y2 int((y_c bh / 2) * h) cv2.rectangle(img, (x1, y1), (x2, y2), (0, 255, 0), 2) cv2.putText(img, str(int(cls)), (x1, y1 - 5), cv2.FONT_HERSHEY_SIMPLEX, 0.6, (0, 0, 255), 2) cv2.imwrite(check_bee_001.jpg, img)这段脚本做了三件事读取标签文件、把归一化坐标乘回图像宽高还原成像素坐标、画框并保存。画框时用的是中心点坐标换算如果哪张图的框明显错位多半是某个标注文件被复制错了。2.2 1404张图像怎么切分train/valid比例与类别不平衡检查数据切分比例看起来是个小问题但对小数据集影响很大。1404张图如果按默认的九比一分开验证集只有140张左右波动会非常明显。我一般会手动固定成训练集1200张左右、验证集200张左右的比例并且保证验证集里每一类都有一定数量。类别不平衡是蜜蜂类数据集的通病。真实拍摄场景里蜜蜂数量天然比大黄蜂、黄蜂多如果标注的时候没有刻意均衡训练出来的模型会对大头类别偏置。训练前用一段代码统计一下各类别的目标框数量比训练完看结果再猜原因要高效得多。from collections import Counter # 统计所有标注文件里各类别的目标框数量 class_counter Counter() total_boxes 0 import glob for txt_path in glob.glob(dataset/labels/train/*.txt): with open(txt_path, r) as f: for line in f.readlines(): cls int(line.strip().split()[0]) class_counter[cls] 1 total_boxes 1 # 类别名按data.yaml里的names顺序填 class_names [bee, hornet, wasp] for idx, name in enumerate(class_names): print(f类别 {idx} ({name}): {class_counter.get(idx, 0)} 个目标框) print(f总目标框数: {total_boxes})假设统计结果里bee有8000个框hornet只有600个这就说明图片里蜂类的类别分布大概是十三比一完全不成比例。遇到这种情况常见的做法有两种一是对少数类做图像增强比如把黄蜂、大黄蜂的样本做水平翻转、旋转、亮度变化扩到三到四倍二是在训练时给少数类更高的loss权重。yolov8训练自己的数据集时类别权重在配置文件里调整但最简单粗暴有效的方法还是先做离线增强把少数类的图像数量补上来。还有一个值得核对的点验证集里不能出现跟训练集完全重复的图像。有些数据集制作时偷懒直接随机切分偶尔会出现一张图的两个拷贝分别进了训练集和验证集。这种数据泄露会让验证指标虚高部署到真实环境立刻现原形。核对方法也很简单用文件名哈希比对一下两个目录的重复情况就行这里就不展开代码了。3. 用YOLOv8训练蜂类检测器从数据准备到第一个可用权重数据集结构确认无误后进入正式的YOLOv8训练流程。我默认读者用的是ultralytics包这是目前训练自备数据集最省事的框架一条命令就能跑起来。但省事不等于可以盲跑数据YAML文件写错、训练参数不合适照样会浪费大量时间。3.1 数据YAML怎么写类别名与路径映射YOLOv8不像老版本YOLOv5那样依赖数据集根目录的自动查找它要求你在YAML文件里显式指定训练集和验证集的路径。路径建议写绝对路径避免相对路径在各种IDE和命令行环境下产生歧义。# data.yaml path: /home/user/dataset # 数据集根目录后续相对路径都基于这个 train: images/train # 训练图像目录 val: images/val # 验证图像目录 nc: 3 # 类别总数 names: 0: bee 1: hornet 2: wasp字段含义很直白path是数据集根目录train和val填相对于根目录的子路径nc是类别个数names是类别名称列表。有一个常见错误是train字段直接写成images/train/xxx.jpg这样的文件路径yolov8虽然也支持传图像列表但如果目录里还有其他图片就很容易漏训练样本。保持目录级别配置让框架自己扫描最稳妥。我见过有人把names的顺序跟训练时对不上模型输出的类别全部错位。原因就是数据集的标签文件里类别编号是0、1、2但names列表写成了wasp、bee、hornet跑出来的结果自然张冠李戴。检查names顺序最可靠的方式就是回到第二章的可视化脚本把类别编号画在框上人工对比一下。3.2 训练命令与核心参数imgsz、epochs、batch、device确认YAML没问题后用下面的命令启动训练yolo detect train \ datadataset/data.yaml \ modelyolov8s.pt \ imgsz640 \ epochs100 \ batch16 \ device0 \ projectwasp_detect \ namerun1 \ patience15这条命令的意思是用yolov8s作为预训练权重在dataset/data.yaml指定数据上训练100轮图像缩放到640×640输入网络批次大小16使用第0号GPU。项目输出到wasp_detect目录本次实验子目录叫run1。patience15表示连续15轮验证指标没有提升就提前停止这个参数对1404张的小数据集特别有用能节省大量训练时间。模型选择方面yolov8s是精度和速度比较平衡的选择。n版本速度最快但精度偏低蜂类本身是中小尺寸目标m或l版本对小目标更友好但显存占用高。如果你的显卡只有6GB显存s版本配batch8比较稳妥直接上l版本大概率显存溢出报错。小数据集上从s版本起步跑通后再升级到m版本是我比较推荐的做法。训练过程中的实时输出会给出每一轮的loss、精度和召回率。重点看val精度和val召回率两个指标不要被训练集loss吸引太多注意力。小数据集上训练集loss降到很低的水平不代表模型好用真正要看的是验证集上的泛化表现。训练结束之后output目录下的weights文件夹里会出现best.pt和last.pt两个权重文件。best.pt是验证集表现最好的那一轮权重last.pt是最后一轮的权重。我的习惯是优先用best.pt在验证集上做推理测试如果发现验证集上best.pt和last.pt差距过大就得回查是不是有过拟合或者数据集划分问题。4. 调准训练参数batch、imgsz与置信度阈值在蜂类检测里的取舍很多人在这套数据集上跑出来的模型效果差不是框架问题而是对三个关键参数理解不够图像尺寸、批次大小、置信度阈值。这三个参数环环相扣直接决定模型能不能看到小目标、能不能稳定收敛、部署时会不会疯狂误报。4.1 图像尺寸640还是960小目标蜂类对分辨率的敏感度蜂类检测对图像尺寸特别敏感。蜜蜂在画面里通常只占几十到一百像素左右如果图像缩到512甚至更小目标区域可能只剩十几个像素特征几乎丢失。YOLO系列本身有从小特征层检测小目标的机制但这个机制依赖输入图像保留足够的目标细节。yolo detect train ... imgsz640 yolo detect train ... imgsz960上面两条命令可以用做对比。640是速度和精度比较均衡的默认值在多数消费级显卡上都能跑960是给显存余量比较大的用户准备的蜂类小目标检测效果会明显好一些但训练时间和显存占用大约会增加一倍以上。我实际操作下来用960训练蜜蜂类的AP值比640能提升3到5个百分点尤其是在大黄蜂这类纹理细节丰富的类别上但代价是batch要减半。显存不够时有一条取舍路径保持imgsz640但关闭mixup和部分马赛克增强。yolov8默认启用了马赛克增强生成训练图时会把多张图拼在一起小目标本来就只有十几像素被马赛克一拼再一缩放就可能彻底消失了。这个改动对小目标数据集的效果非常显著。4.2 batch大小与学习率联动显存不够时不要硬撑batch大小直接影响BatchNorm的统计量和学习率的有效范围。yolov8默认的学习率是按照batch16左右设定的如果你把batch降到4同一个学习率下梯度更新会变得非常震荡。反过来batch提到64以上默认学习率又可能太大。# 一些常见的batch-学习率配对参考ultralytics内部有自动缩放逻辑 # batch4 lr0约0.001 # batch8 lr0约0.002 # batch16 lr0约0.01 (框架默认) # batch32 lr0约0.02实际使用中ultralytics会根据batch大小自动做学习率缩放大多数情况下不需要手动改。我要提醒的是另一个现象小数据集配合小batch时由于BatchNorm统计量更新不足模型更容易过早过拟合。如果你发现训练曲线震荡幅度很大val精度一直上不去考虑把batch调大或者把输入图像尺寸适当缩小一点来换取更大的batch。有一个更隐蔽的细节验证时batch大小跟训练时不一致会导致验证指标波动。ultralytics默认用batch16做验证如果你训练时用的是batch4验证结果跟你预期可能会有出入。为了统一标准我一般会在验证和训练时保持相同的batch。4.3 置信度阈值与NMS IoU误报和漏报的天平训练结束后推理时的置信度阈值是决定模型实用性的最后一道关口。阈值设高了蜂类漏报多设低了花丛背景里的绿色叶片会被误报成蜂类。NMS的IoU阈值同样关键它决定两个重叠框什么时候合并成一个。from ultralytics import YOLO # 用best.pt做推理显式设置置信度和NMS参数 model YOLO(runs/detect/wasp_detect/weights/best.pt) results model.predict( sourcetest_images/, conf0.35, # 置信度阈值低于这个值的框全部丢弃 iou0.5, # NMS的IoU阈值两个框重叠超过这个值就合并 imgsz640 )置信度0.35是通用起点但蜂类场景经常要降到0.2或0.25。原因在于蜂类飞行姿态多变、局部遮挡严重模型给出的置信度天然偏低。这个阈值不是一个全局最优值不同场景、不同摄像头角度差异很大建议用一批真实场景截图做小批量验证找到误报和漏报的平衡点。NMS的IoU阈值默认取0.5到0.7之间。蜂类目标互相挨得近一个花朵上可能同时停两只蜜蜂框重叠程度高。如果IoU阈值设得太低比如0.3两只紧挨的蜜蜂会被合并成一个框导致数量统计失真。设到0.6左右通常能得到比较合理的分离效果。这个参数可以在部署阶段反复试不用回炉重训。5. 蜂类训练避坑五类高发问题与排查记录小数据集训练YOLO问题翻车率远高于大数据集。1404张图属于中小规模很多坑我在实际项目中反复踩过。这一章直接从现象入手每条都给原因和解决方法方便你对号入座。5.1 标注错位图像与标签文件错配导致loss不降现象训练了好几个epochloss值纹丝不动或者下降极慢验证集的mAP几乎为零。原因images目录和labels目录里的文件名没有一一对应。最常见的是某个标签文件名是bee_001.txt但对应图像是bee_002.jpg模型拿蜜蜂的框去学大黄蜂的图像特征训练过程完全混乱。另一种情况是类别编号混用某些标签文件里用了0、1、2以外编号比如3YOLO框架在读标签时虽然不会报错但模型永远学不会这个不存在的类别。解决训练前跑一遍文件名配对检查脚本确认每个txt文件都有对应的jpg且编号不超过nc-1。我自己的习惯是直接检查labels目录里所有txt文件把所有类别编号提取出来去个重一旦发现超出类表范围的编号立刻筛查这个标注文件是哪张图的重新核对再进训练。# 快速检查标签编号是否合法 import glob all_cls set() for txt in glob.glob(dataset/labels/train/*.txt): with open(txt, r) as f: for line in f: all_cls.add(int(line.split()[0])) print(标签中出现的类别编号:, sorted(all_cls)) # 如果出现大于等于3的编号说明标注文件有错5.2 类别不平衡蜜蜂图像占大半黄蜂样本不足现象验证集上bee类别的精度和召回率很高wasp类别几乎不检出或者看到黄蜂时也报成bee。原因训练数据里bee类别目标框数量远大于wasp。模型在训练过程中学到的最优策略就是把所有类似蜂的目标都预测成bee因为这样loss最小。类别不平衡在小数据集里影响比在大数据集里更明显因为少数类的有效样本太少模型很难学到类别的判别特征。解决先按2.2的方法统计类别数量在训练层面做两个调整。第一给wasp和hornet类的loss加权ultralytics支持在训练配置里指定class_weights参数。第二针对少数类做离线增强把现有wasp图像的亮度、对比度、翻转变化生成副本扩到和目标类数量接近。有人还会专门去补拍更多黄蜂图像这是治本的方法实际操作中不一定凑得上能补几张算几张。5.3 小目标漏检远处蜂类在图像里不到15像素现象近景图像检测效果好画面里距离稍远的蜂类全漏掉。查看验证集错误结果漏检框集中在尺寸很小的目标上。原因YOLO检测小目标的能力受限于特征图分辨率。以640输入为例最浅检测层的步长是8一个15像素的目标在该层只占约2×2的特征网格特征信息非常有限。如果训练时图像又被马赛克增强缩放这些目标就更难学了。解决优先尝试提升输入尺寸到960代价是显存和训练时间。另一个有效做法是把数据集里小目标比例偏低的图像单列出来多做几次裁剪放大再作为额外训练样本。此外可以用yolov8的SAHI切片推理技术推理时把大图切成小块分别检测再合并结果但要留意边缘目标可能被切开。5.4 过拟合1404张图训练到后期val loss反弹现象训练loss持续下降但验证集loss在某个epoch后开始上升mAP同步下滑。典型的过拟合曲线。小数据集上跑50轮以上很常见。原因数据量有限模型学完训练集的细节特征后开始记忆噪声包括光照变化、背景纹理这类与蜂类无关的信息。尤其在一部分图像背景高度相似的情况下模型可能直接记住了背景。解决最直接的方案是提前停止也就是训练命令里的patience参数让框架在val指标不再上升时自动停。另一个手段是增强正则化把weight decay从默认值适当调大一点。还有一个实用的做法是数据增强降级把马赛克增强关掉因为马赛克在末期可能加剧模型对训练集分布的依赖。我一般会用best.pt而不是last.pt做最终推理因为best.pt通常是在验证集上表现最好的那轮权重泛化能力更有保障。5.5 相似类别混标蜜蜂和黄蜂在低分辨率下难区分现象模型把蜜蜂识别成黄蜂或者把黄蜂识别成蜜蜂类别错乱但框的位置很准。这种错误同网络图里“框对了标签错了”的情况最恼火。原因蜜蜂和黄蜂外形本身接近加上图像分辨率不高、拍摄角度多变类间差异被严重压缩。有些数据集制作方在标注时也容易把两者搞混导致标签本身就存在噪声。框的位置准说明模型已经找到目标类别错说明它没学到足够强的判别特征。解决训练阶段可以试试把容易混淆的两个类别合并成一个类比如只区分“蜜蜂”和“非蜜蜂”。这个方案在很多农用场景里反而更实用因为用户只关心有没有入侵。如果必须细分三种建议给容易混淆的类别单独准备一批特写图尽量把腹部条纹、翅膀形态这些判别特征在图像中放大。推理阶段也要注意置信度阈值对这些相似类别的灵敏度通常混标类别的置信度会比较低适当拉高阈值可以减少这类错误的输出。6. 把模型部署到蜂箱场景推理脚本、ONNX导出与置信度调参技巧训练完的模型最终要落到真实场景里用最后的实用步骤是把best.pt导成ONNX格式让推理不依赖PyTorch环境同时做一个能自动统计蜂类数量的推理脚本。这两个做法一套下来模型才算真正能用。# 导出ONNX方便后续用onnxruntime或TensorRT部署 from ultralytics import YOLO model YOLO(runs/detect/wasp_detect/weights/best.pt) model.export(formatonnx, imgsz640, halfTrue, simplifyTrue)导出时imgsz必须和训练时保持一致否则导出的模型输入尺寸跟训练分布不一致推理精度会下降。halfTrue启用半精度边缘设备推理速度几乎翻倍但对部分老显卡不支持需要先确认一下硬件环境。实际部署时只输出检测框还不够蜂箱自动计数需要把每一帧的检测结果做时间维度上的处理。最简单的做法是每帧的检测数量求平均稍微复杂一点的做法是记录每个目标框中心点的运动轨迹在前后几帧之间匹配避免同一只蜂在连续帧里被重复计数。import cv2 from ultralytics import YOLO model YOLO(best.onnx) # 直接用导出的ONNX推理 cap cv2.VideoCapture(beehive.mp4) bee_count 0 while True: ret, frame cap.read() if not ret: break results model.predict(frame, conf0.35, iou0.6, verboseFalse) # 只统计蜜蜂类别的目标数量假设bee是类别0 bee_count sum(1 for r in results[0].boxes.cls if int(r) 0) print(f视频中蜜蜂总帧级出现次数: {bee_count})真实蜂箱场景还有一个特别容易被忽略的细节正午强光下蜜蜂腹部反光会形成高光区域模型容易把亮斑识别成蜂类。我的处理习惯是在推理前加一个简单的光电增强预处理用直方图均衡化压低高光区域的对比度。这个改动虽然朴素但在实际部署中经常能让误报率降一半以上。我这套流程走下来最大的一个教训是小数据集训练时不要过度迷信默认参数但也不要一上来就大幅度调参。先把数据格式搞对、把YOLO标签的格式和类别顺序验证清楚然后跑一个默认参数的结果做基准再逐个调整imgsz、batch、置信度阈值。每改一个参数都做对比实验记录清楚哪次改了什么这样踩坑时才好回溯。这类蜂类检测数据集本身不大但用来跑通农业视觉的完整流程绰绰有余。数据预处理、训练、部署这三步每一步都有它自己的坑希望这篇笔记能帮你少走几趟弯路。本文还有配套的精品资源点击获取