基于YOLOv11的蜜蜂识别检测系统：从数据集训练到Web部署

聊一个我最近在折腾的视觉项目基于YOLOv11的蜜蜂识别检测系统。标题看着长拆开其实就是四件事——用YOLOv11训练一个蜜蜂目标检测模型配套一份YOLO格式数据集再套一个带登录注册界面的UI系统最后把Python源码和训练好的模型一起交付。它解决的问题很具体在养蜂场或生态观测站人工盯着屏幕数蜜蜂、统计进出巢频率耗时而且容易漏这套系统能在视频流里实时标出每一只蜜蜂顺带输出数量统计。适合谁参考呢刚学完深度学习、手里缺一个能跑通全链路练手项目的人或者正在做农业信息化、昆虫监测的开发者都可以把它当模板。这篇文章会把从数据集准备到模型训练、再到界面联调的全过程捋一遍能直接“抄作业”的地方尽量写得细。1. 项目整体设计与思路拆解1.1 系统要解决的三个核心问题做这类视觉系统本质上不是在解决“用什么模型”的问题而是在解决数据、精度和易用性三件麻烦事。先说数据。蜜蜂检测属于典型的小目标密集检测场景公开数据集数量不算多而且不同地区、不同光线条件下的蜜蜂外观差异很大。如果只拿现成数据集训练模型很容易在自采图片上表现拉胯。所以这个项目在数据层面要先做一次“组合拳”公开蜜蜂图像库加上自己补拍的照片混合标注训练。再说精度和速度的权衡。蜜蜂体型小、运动快一张蜂箱入口的图里可能出现几十只蜜蜂挤在一起。模型要能在低分辨率下把密集小目标分开同时推理速度还得跟得上视频流。这也是我最终选YOLOv11而不是其他模型的关键原因后面细说。最后是易用性。模型训练好只是半成品给用户用的时候不能让他们敲命令行。系统需要一个网页或者桌面界面让人上传图片、选摄像头、看检测结果还得有最基本的账号登录和注册功能区分使用权限。把这些串起来才算一个能展示的完整项目。1.2 整体技术栈与模块划分这套系统的技术栈并不复杂核心组件如下检测引擎Ultralytics YOLOv11PyTorch作为后端框架数据集YOLO格式标注图片加同名txt文件后端服务Python Flask提供登录注册、检测API、视频流转发前端UIHTML、CSS、JavaScript展示摄像头画面和检测结果数据库SQLite存储用户账号信息辅助库OpenCV、NumPy负责图像读取、画面推流和框坐标处理为什么用Flask做Web界面而不是PyQt桌面端我的判断是Web方案跨平台能力好演示的时候只要浏览器打开就行不用在一台机器上装Python环境。而且Flask做视频流推送非常顺配合OpenCV的生成器函数就能实现MJPEG流手机和电脑都能访问。桌面端虽然交互响应更直接但打包体积大、分发麻烦适合后续做成客户端再说。数据流大致走一条直线前端页面发起请求后端Flask路由接收读取图片或摄像头帧后送入YOLOv11模型推理模型返回目标框和置信度后端把标注后的画面转成图像流推给前端同时附带一份检测数量统计。用户登录态用Session保存每次访问检测页面之前校验一下。1.3 为什么最终选YOLOv11而不是v8或v5选择模型是项目开始后第一个需要拍板的决定我把YOLOv5、v8、v11放在一起做过对比。YOLOv5的好处是生态成熟网上教程一抓一大把部署资料多。缺点是模型结构相对老在密集小目标场景下同等参数量的表现已经被后面几代版本拉开距离而且超参数调节更多依赖手动经验。YOLOv8是功能最全的一代分类、检测、分割都支持训练流程稳定很多教程直接拿它做默认版本。但我实际跑下来YOLOv11在相同算力下的小目标精度更有优势主要原因有两点第一YOLOv11的backbone换成了C3k2模块相比v8的C2f结构在减少参数量的同时让特征提取更高效对尺寸小的蜜蜂目标更友好。第二网络颈部加入了C2PSA注意力模块注意力机制能帮模型在密集场景里区分重叠的目标边界蜂箱口那种一群蜜蜂挤在一起的情况下减少漏检。参数规模上这个项目用的yolov11n版本参数量只有两百多万单张图片推理非常快如果追求更高精度可以换yolov11s参数量九百多万训练时间和显存会上去一点但在可接受范围内。对蜜蜂这种单类别检测任务n版本已经足够跑出不错的结果后续再按需上s或者m。2. 蜜蜂数据集的构建与标注要点2.1 数据从哪里来公开数据集与自采补拍做检测项目数据质量决定模型上限。刚开始我没太当回事直接拿一个公开蜜蜂图像数据集来训练那个数据集有几千张蜂箱附近的图像标注的是完整蜜蜂个体整体基础不错。但问题在于只靠它训练出的模型面对我自己补拍的不同光照照片时误检率很高。原因不复杂蜜蜂在不同颜色背景、不同逆光角度下外观特征差异太大。所以后来我加了一步自采数据补拍。用手机和相机在蜂箱入口、花丛边缘各拍了几百张照片覆盖晴天强光、阴天散射光、傍晚弱光三个光线条件同时兼顾近距离特写和远距离小目标两种场景。补拍的照片再人工筛选模糊的、蜜蜂占比过小的直接删掉留下一千张左右有效图片。整体数据量控制在三千多张。对单类别检测任务来说一千到三千张能跑通流程五千张以上能把精度做得比较好。如果你的目标是竞赛级效果建议在这个基础上翻倍但工程演示和实际落地三千张左右性价比最高。2.2 标注工具与标注规则标注工具我用的LabelImg开源免费支持直接导出YOLO格式。YOLO格式很好理解每张图片对应一个同名txt文件每一行都是“class x_center y_center width height”class是类别编号从0开始x、y、w、h都是归一化到0到1之间的比例值。蜜蜂检测就一个类别所以每行开头的数字永远是0。标注蜜蜂比标注普通物体麻烦几个坑得提前避开。边界框要紧贴蜜蜂身体不要把展开的翅膀面积全包进去。翅膀几乎是透明的在图像里会混入背景纹理如果框大了模型提取特征的时候就会把大量背景信息当正样本学进去小目标误检率直线上升。轻微遮挡的蜜蜂要正常标注但遮挡超过一半的建议直接跳过。模型学到的是完整物体的表现方式如果标注了大量半截蜜蜂反而会让模型疑惑“什么才算一只完整的蜜蜂”。远距离的小目标不要因为看着模糊就放弃标注。这些恰恰是评估模型真实能力的样本漏标一个模型就会把那个位置当成负样本反复训练后它对小目标的响应会变得更差。还有一条最重要同一张图里的每只蜜蜂都要标全绝不能漏标。漏标相当于告诉模型“这个位置的蜜蜂是背景”模型会在后续推理中本能地忽略那些被漏掉的目标形态。2.3 数据划分与增强策略数据划分上我按8:1:1拆成train、val、test。要注意一个细节如果自采的连续帧图片来自同一个视频序列不能直接随机打乱划分否则验证集里的图片和训练集高度相似训练出来的指标虚高一换到真实场景就露馅。正确做法是按拍摄批次或场景分组整个批次被完整划分到同一个集合。增强策略直接用Ultralytics训练时自带的方案。模型默认会开启Mosaic增强、HSV颜色扰动、随机翻转、随机缩放等。Mosaic把四张图拼在一起训练对密集小目标提升明显蜜蜂这个场景很适合。额外加了一个思路如果某个批次里蜜蜂分布过于稀疏检测效果会变差可以用小目标复制粘贴增强把图里已有蜜蜂框复制一份放在空白区域增加目标密度。但这类增强在训练轮次多了之后会带来轻微过拟合问题我自己只在数据量不足的阶段使用。3. YOLOv11模型训练的实操细节与调参经验3.1 环境准备与依赖安装训练环境建议用conda创建独立环境别把依赖装进系统全局Python不然以后维护排查会很难受。conda create -n bee python3.10 conda activate bee pip install ultralytics torch torchvision opencv-python如果你有NVIDIA显卡先确认本机CUDA版本再装对应版本的PyTorch。最简单的方法是去PyTorch官网按条件复制安装命令而不是手动乱装。如果机器没有显卡CPU也能训练但速度会慢很多蜜蜂数据集三千张、一百轮大概要跑好几个小时这时候可以把imgsz调小到416试试。3.2 数据集配置与训练启动Ultralytics的训练入口需要一个数据集配置文件里面写明图片和标注的路径、类别数量、类别名称。文件名就写成data.yaml放在项目目录下。train: dataset/images/train val: dataset/images/val test: dataset/images/test nc: 1 names: [bee]然后启动训练。我第一次跑的时候用yolov11n.pt作为预训练权重这个权重在通用图片上已经学好了基础特征再迁移到蜜蜂数据上收敛速度比从头训练快很多最终效果也更好。yolo detect train datadata.yaml modelyolov11n.pt epochs100 imgsz640 batch16 device0参数含义逐条说清楚epochs是训练轮数100轮对三千张数据够了再多到150到200轮容易过拟合imgsz是输入分辨率640是通用选择如果觉得小目标检测效果不够可以尝试1280但显存占用和训练时间都会成倍上涨batch是批大小按显存容量来定16G显存跑yolov11n、imgsz640没有问题显存不够就调低到8甚至4效果不会有太大变化训练时间长一点而已。3.3 训练过程中的监控与判断标准训练跑起来之后不要干等。在runs/detect/train目录下会生成results.csv和一系列曲线图重点关注train/box_loss、cls_loss、dfl_loss三条损失曲线以及val侧mAP50、mAP50-95两个关键指标。正常的训练状态是前二十轮loss快速下降mAP快速上升之后速度放缓逐渐收敛到了最后几十轮mAP曲线趋于平坦不再有明显波动。常见异常有两个。一是train loss持续下降但验证mAP停滞不前甚至开始掉点这是过拟合的经典信号处理方式是加强数据增强、减少训练轮次或者换一个更小的模型。二是loss和mAP都一直横在高位怎么训都上不去这不是训练参数问题而是数据本身出了问题比如标注文件和图片不匹配、类别索引写错、训练集里混了大量无法识别的模糊照片这时候先检查数据不要急着调学习率。单类别蜜蜂数据集上mAP50做到90%以上是合理的期望mAP50-95能到70%左右已经不错。但要记住这两个数值和数据集难度强相关不用太执着绝对数字。更重要的是去看验证集图片上的可视化效果框有没有贴紧、有没有把蜜蜂肚子分离开这些视觉判断比一个数字更可靠。3.4 模型评估与导出部署训练结束之后项目目录下会出现best.pt和last.pt两个权重文件best.pt是验证集上表现最好的版本后续推理都用它。先用测试集评估一下泛化能力yolo predict modelruns/detect/train/weights/best.pt sourcetest.jpg conf0.35确认效果没问题就可以导出成ONNX格式方便部署到服务器环境yolo export modelbest.pt formatonnx dynamicTrue导出ONNX的意义在于服务器端不一定有完整的PyTorch环境ONNX是一种跨框架的模型格式后续可以转成TensorRT进一步提升推理速度也可以直接用另一套推理框架。不过这个项目里为了方便演示还是直接用PyTorch加载权重做推理代码更简洁少一层中间格式的转换风险。3.5 把模型推理写进系统系统侧开通的检测接口本质是把模型加载一次反复对图像帧做推理。核心代码并不长from ultralytics import YOLO model YOLO(models/best.pt) def detect_bee(frame): results model(frame, conf0.35, iou0.45, imgsz640, devicecpu) boxes results[0].boxes detections [] for box in boxes: x1, y1, x2, y2 box.xyxy[0].tolist() score float(box.conf[0]) detections.append((x1, y1, x2, y2, score)) return detections这里conf阈值值得多说两句。设得太低比如0.25画面上会出现大量低置信度误检框尤其在背景有叶子、石块、木纹的地方模型会把颜色相近的物体当成蜜蜂。设得太高比如0.6那些模糊的、远距离的小蜜蜂会被直接过滤掉数量统计会偏少。蜜蜂场景下我推荐0.3到0.4之间的值既保留真实目标又过滤掉大部分噪声。这里设成0.35是一个相对稳妥的折中。4. 登录注册界面与检测UI的实现方案4.1 技术选型Web端还是桌面端刚开始拿到这个项目需求时我也考虑过用PyQt做桌面版。但认真比了一下最终还是选了Web端方案。理由有三条第一Web界面开发效率高HTML加CSS几分钟就能出一版能看的页面PyQt的布局和控件要慢慢调第二检测系统的核心展示内容是实时视频流浏览器里用img标签就能显示MJPEG流PyQt做类似事情需要额外写解码和绘制逻辑第三以后如果要把系统部署到服务器场Web端口直接就能变成服务桌面客户端反而需要重新封装。这套系统的后端用Flask数据库用SQLite因为用户量不大根本不需要上MySQL。前端就用原生HTML加JavaScript不引重型框架保持项目结构透明。4.2 登录注册模块的核心实现登录注册在Web系统里属于基础功能但基础不代表可以不做安全措施。用户密码绝不能明文存储我用Werkzeug自带的密码哈希函数生成带盐值的哈希字符串再入库。这块和Flask配合得很好不需要额外引入别的加密库。先看注册接口。接收前端传来的用户名和密码做两道校验用户名不能为空、不能与已有用户重复。校验通过后密码经过generate_password_hash处理存进users表。from flask import Flask, request, session, jsonify from werkzeug.security import generate_password_hash, check_password_hash import sqlite3 app Flask(__name__) app.secret_key change-me def get_db(): conn sqlite3.connect(bee_system.db) return conn app.route(/api/register, methods[POST]) def register(): data request.get_json() username data.get(username, ).strip() password data.get(password, ) if not username or not password: return jsonify({msg: 用户名和密码不能为空}), 400 conn get_db() exists conn.execute( SELECT id FROM users WHERE username?, (username,) ).fetchone() if exists: conn.close() return jsonify({msg: 用户名已存在}), 409 password_hash generate_password_hash(password) conn.execute( INSERT INTO users(username, password_hash) VALUES(?, ?), (username, password_hash), ) conn.commit() conn.close() return jsonify({msg: 注册成功})登录接口类似区别在于用check_password_hash比对密码比对成功就写入Flask Sessionapp.route(/api/login, methods[POST]) def login(): data request.get_json() username data.get(username, ).strip() password data.get(password, ) conn get_db() user conn.execute( SELECT id, password_hash FROM users WHERE username?, (username,) ).fetchone() conn.close() if user and check_password_hash(user[1], password): session[user_id] user[0] return jsonify({msg: 登录成功}) return jsonify({msg: 用户名或密码错误}), 401两个关键点一是SQL查询全部用参数化方式直接用字符串拼接SQL会留下注入风险二是app.secret_key不能写死成公开值发布环境里改成随机生成的环境变量否则Session伪造风险很大。前端页面在检测界面加载前先请求一个校验接口如果Session里没有user_id直接跳转回登录页。这样可以保证系统不是“裸奔”状态至少有一个最基本的访问权限控制。4.3 摄像头视频流与实时检测实时检测是整个系统最有展示效果的部分。实现原理不算复杂OpenCV打开摄像头读取视频帧每一帧送入YOLOv11模型推理推理结果画在帧上再把帧编码成JPEG字节流Flask以multipart/x-mixed-replace格式把字节流推送到浏览器。import cv2 from ultralytics import YOLO model YOLO(models/best.pt) cap cv2.VideoCapture(0) def generate_frames(): while True: ok, frame cap.read() if not ok: break results model(frame, conf0.35, imgsz640) annotated results[0].plot() ret, buffer cv2.imencode(.jpg, annotated) frame_bytes buffer.tobytes() yield ( b--frame\r\nContent-Type: image/jpeg\r\n\r\n frame_bytes b\r\n )前端只需要一个img标签指向视频流路由img src/video_feed width960 height540 /浏览器就会像播放视频一样持续刷新画面。这种方案的优点是不用WebSocket、不用JavaScript画Canvas最简单的方式实现实时画面稳定性也足够。不过有两个性能提醒第一在CPU环境下跑640分辨率的YOLOv11推理单帧需要几百毫秒画面FPS可能只有3到5帧这是正常的。如果要做流畅视频建议在显卡环境中运行把device参数改成GPU或者换TensorRT推理引擎。第二模型初始化要放到全局作用域不要在生成器函数内部每次循环都加载一遍模型否则画面会卡成幻灯片。4.4 检测结果统计与前端展示计数统计和检测展示需要分开。视频流只能展示画面没办法在img标签旁边同步显示结构化数据所以我在后端额外写了一个统计接口。在generate_frames里实时维护一个变量记录当前帧检测到的蜜蜂数量同时用另一个路由返回JSON数据前端用定时器每两秒拉取一次刷新数量显示。前端页面分三块区域顶部是标题和当前登录用户中间是视频流画面画面下方是统计面板包含当前帧蜜蜂数量、系统运行时间、模型名称。整体风格走简洁路线深色背景边框圆角尽量让用户注意力集中在画面上。5. 常见问题与排查技巧实录5.1 训练阶段的高频问题训练环节单独整理一份问题速查表基本覆盖新手会踩的坑问题现象可能原因处理方案CUDA out of memorybatch过大或输入分辨率过高把batch调到4或8imgsz降到480loss一直不下降学习率过大或数据目录路径错误检查data.yaml路径恢复默认学习率验证mAP异常低标注漏标严重或类别索引错误抽查真值标注文件看类别数值是否正确训练指标很好但现场误检多训练集和测试场景差异过大加入现场场景图片重新训练推理结果出现大量重复框NMS的iou参数过小把iou设为0.45到0.5之间这里最有迷惑性的是第一个CUDA内存报错。很多人第一反应是换更大的显卡但调整策略往往是先把batch调低因为batch对单类别检测任务精度影响并不明显真正决定精度的还是数据质量和输入分辨率。16G显存跑yolov11n、batch16、imgsz640通常没问题如果你的显卡只有8G显存batch降到4也能正常训练就是每个epoch时间会变长。5.2 部署与界面联调问题训练好模型之后联调阶段的问题和训练阶段完全不同更像“软件工程问题”。常见的有摄像头打不开。最常见原因是摄像头索引号不对。OpenCV的VideoCapture(0)表示默认摄像头如果机器上外接了多个摄像头可能需要用VideoCapture(1)或者重新枚举设备号。另外笔记本的摄像头被其他程序占用时OpenCV会读不到画面需要检查资源冲突。前端画面卡顿甚至白屏。多数情况不是摄像头本身问题而是视频流生成器抛了异常。在所有yield之前加try/except至少保证帧出错时不断流浏览器就不容易白屏。登录后一刷新页面又回到登录页。这是Flask Session有效期和Cookie配置问题app.secret_key一定不能每次启动都随机变化否则重启服务后旧Session全部失效。同时在浏览器检查Cookie是否被拦截。中文路径读取失败。OpenCV在读取带中文的路径时经常报错图片上传后不要用原始中文文件名直接喂给cv2.imread统一改名为时间戳或随机字符串后再处理。5.3 我踩过的几个坑和心得数据集标注的时候我犯过一个看起来不起眼但影响很大的错误把蜜蜂翅膀透明区域全包进边界框。那时候觉得框大一点更容易框住结果训练出来的模型误检率明显偏高尤其在有落叶、有花瓣纹理的地方经常把颜色接近的碎片当成蜜蜂。后来重新标注框贴紧身体精度立刻上了一个台阶。第二个经验是关于训练分辨率的。第一次直接上imgsz1280想用小目标利器把远处蜜蜂看清晰结果显存直接爆掉。后来先用640把整个流程跑通验证了数据集没问题再用1280做针对性微调同时在config里降低batch大小。这个“先小后大”的策略适合所有小目标检测项目。还有视频流优化的一个细节不要每次yield帧之前都调用一次model.predict模型初始化只做一次后续全部复用。推理时的device参数保持一致混用CPU和GPU会导致不可预测的延迟。把模型加载放在全局生成器只负责读取帧和调用detect函数画面FPS会稳定不少。最后再提一个和统计准确率相关的经验。系统界面显示的检测数量和真实蜜蜂数量总有一些偏差主要原因是conf阈值过滤掉了低置信度目标。如果你的场景里蜜蜂和背景颜色接近那些模糊的远距离目标很难被高置信度识别这是检测模型本身的局限。想进一步缩小差距可以在跟踪模块上做文章对同一只蜜蜂进行多帧关联而不是简单地按单帧数框。结束语最后说点实在的。这套系统做完最大的收获不是“跑通了一个检测模型”而是把数据、训练、前后端一整套链路串了起来。我在实际测试中用一段真实蜂箱入口的视频片段跑模型在训练集之外的图片上mAP50达到了92%CPU环境下视频帧的FPS只有3到5帧但接到有显卡的服务器上运行就流畅了。如果你是刚开始接触这类项目建议先把训练流程跑通再用yolov11n这样的小模型把服务端接口调明白最后再去美化前端。后续还可以往下扩展加蜜蜂轨迹跟踪和计数分析、识别不同蜂种、接蜂箱传感器数据做综合告警这套架子都已经给你留好了位置。