简介：面向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 \ data=dataset/data.yaml \ model=yolov8s.pt \ imgsz=640 \ epochs=100 \ batch=16 \ device=0 \ project=wasp_detect \ name=run1 \ patience=15这条命令的意思是用yolov8s作为预训练权重，在dataset/data.yaml指定数据上训练100轮，图像缩放到640×640输入网络，批次大小16，使用第0号GPU。项目输出到wasp_detect目录，本次实验子目录叫run1。patience=15表示连续15轮验证指标没有提升就提前停止，这个参数对1404张的小数据集特别有用，能节省大量训练时间。
模型选择方面，yolov8s是精度和速度比较平衡的选择。n版本速度最快但精度偏低，蜂类本身是中小尺寸目标，m或l版本对小目标更友好但显存占用高。如果你的显卡只有6GB显存，s版本配batch=8比较稳妥，直接上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 ... imgsz=640 yolo detect train ... imgsz=960上面两条命令可以用做对比。640是速度和精度比较均衡的默认值，在多数消费级显卡上都能跑；960是给显存余量比较大的用户准备的，蜂类小目标检测效果会明显好一些，但训练时间和显存占用大约会增加一倍以上。我实际操作下来，用960训练蜜蜂类的AP值比640能提升3到5个百分点，尤其是在大黄蜂这类纹理细节丰富的类别上，但代价是batch要减半。
显存不够时有一条取舍路径：保持imgsz=640，但关闭mixup和部分马赛克增强。yolov8默认启用了马赛克增强，生成训练图时会把多张图拼在一起，小目标本来就只有十几像素，被马赛克一拼再一缩放，就可能彻底消失了。这个改动对小目标数据集的效果非常显著。
4.2 batch大小与学习率联动：显存不够时不要硬撑
batch大小直接影响BatchNorm的统计量和学习率的有效范围。yolov8默认的学习率是按照batch=16左右设定的，如果你把batch降到4，同一个学习率下梯度更新会变得非常震荡。反过来，batch提到64以上，默认学习率又可能太大。
# 一些常见的batch-学习率配对参考，ultralytics内部有自动缩放逻辑 # batch=4 lr0约0.001 # batch=8 lr0约0.002 # batch=16 lr0约0.01 (框架默认) # batch=32 lr0约0.02实际使用中，ultralytics会根据batch大小自动做学习率缩放，大多数情况下不需要手动改。我要提醒的是另一个现象：小数据集配合小batch时，由于BatchNorm统计量更新不足，模型更容易过早过拟合。如果你发现训练曲线震荡幅度很大，val精度一直上不去，考虑把batch调大，或者把输入图像尺寸适当缩小一点来换取更大的batch。
有一个更隐蔽的细节：验证时batch大小跟训练时不一致，会导致验证指标波动。ultralytics默认用batch=16做验证，如果你训练时用的是batch=4，验证结果跟你预期可能会有出入。为了统一标准，我一般会在验证和训练时保持相同的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( source="test_images/", conf=0.35, # 置信度阈值，低于这个值的框全部丢弃 iou=0.5, # NMS的IoU阈值，两个框重叠超过这个值就合并 imgsz=640 )置信度0.35是通用起点，但蜂类场景经常要降到0.2或0.25。原因在于蜂类飞行姿态多变、局部遮挡严重，模型给出的置信度天然偏低。这个阈值不是一个全局最优值，不同场景、不同摄像头角度差异很大，建议用一批真实场景截图做小批量验证，找到误报和漏报的平衡点。
NMS的IoU阈值默认取0.5到0.7之间。蜂类目标互相挨得近，一个花朵上可能同时停两只蜜蜂，框重叠程度高。如果IoU阈值设得太低，比如0.3，两只紧挨的蜜蜂会被合并成一个框，导致数量统计失真。设到0.6左右通常能得到比较合理的分离效果。这个参数可以在部署阶段反复试，不用回炉重训。
5. 蜂类训练避坑：五类高发问题与排查记录
小数据集训练YOLO，问题翻车率远高于大数据集。1404张图属于中小规模，很多坑我在实际项目中反复踩过。这一章直接从现象入手，每条都给原因和解决方法，方便你对号入座。
5.1 标注错位：图像与标签文件错配导致loss不降
现象：训练了好几个epoch，loss值纹丝不动或者下降极慢，验证集的mAP几乎为零。
原因：images目录和labels目录里的文件名没有一一对应。最常见的是某个标签文件名是bee_001.txt但对应图像是bee_002.jpg，模型拿蜜蜂的框去学大黄蜂的图像特征，训练过程完全混乱。另一种情况是类别编号混用，某些标签文件里用了0、1、2以外编号，比如3，YOLO框架在读标签时虽然不会报错，但模型永远学不会这个不存在的类别。
解决：训练前跑一遍文件名配对检查脚本，确认每个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(format="onnx", imgsz=640, half=True, simplify=True)导出时imgsz必须和训练时保持一致，否则导出的模型输入尺寸跟训练分布不一致，推理精度会下降。half=True启用半精度，边缘设备推理速度几乎翻倍，但对部分老显卡不支持，需要先确认一下硬件环境。
实际部署时，只输出检测框还不够，蜂箱自动计数需要把每一帧的检测结果做时间维度上的处理。最简单的做法是每帧的检测数量求平均，稍微复杂一点的做法是记录每个目标框中心点的运动轨迹，在前后几帧之间匹配，避免同一只蜂在连续帧里被重复计数。
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, conf=0.35, iou=0.6, verbose=False) # 只统计蜜蜂类别的目标数量，假设bee是类别0 bee_count += sum(1 for r in results[0].boxes.cls if int(r) == 0) print(f"视频中蜜蜂总帧级出现次数: {bee_count}")真实蜂箱场景还有一个特别容易被忽略的细节：正午强光下蜜蜂腹部反光会形成高光区域，模型容易把亮斑识别成蜂类。我的处理习惯是在推理前加一个简单的光电增强预处理，用直方图均衡化压低高光区域的对比度。这个改动虽然朴素，但在实际部署中经常能让误报率降一半以上。
我这套流程走下来，最大的一个教训是：小数据集训练时不要过度迷信默认参数，但也不要一上来就大幅度调参。先把数据格式搞对、把YOLO标签的格式和类别顺序验证清楚，然后跑一个默认参数的结果做基准，再逐个调整imgsz、batch、置信度阈值。每改一个参数都做对比实验，记录清楚哪次改了什么，这样踩坑时才好回溯。
这类蜂类检测数据集本身不大，但用来跑通农业视觉的完整流程绰绰有余。数据预处理、训练、部署这三步每一步都有它自己的坑，希望这篇笔记能帮你少走几趟弯路。
本文还有配套的精品资源，点击获取
