YOLOv11蜜蜂目标检测实战：数据标注、模型训练与Web部署全流程

做蜜蜂识别这个项目，起因很朴实：有朋友做蜂场智能化监测，每天要盯视频统计蜂箱进出的蜜蜂数量。蜂箱门口蜜蜂一多，目标小、移动快、相互遮挡，人眼数起来非常痛苦。我就想着干脆用YOLOv11直接搭一套能自动识别的系统，把采集、标注、训练、推理到Web界面全部打通，最后不光模型训练出来了，还顺手做了一套带登录注册的检测界面，整套Python项目和模型权重都能直接复用。

这篇文章不聊虚的，就是整个项目的实战复盘：为什么选YOLOv11而不是其他检测框架，数据集怎么采怎么标，训练参数怎么调，UI和登录注册怎么落地，以及我在实际调试中踩过哪些坑。适合正在做目标检测方向毕设、农业和养蜂场景智能化项目，或者刚接触YOLO系列想快速跑通全流程的朋友参考。整体思路按环境、数据、训练、界面、排错五条线展开，照着复现基本不会绕弯路，后面我把每部分的细节全部摊开来讲。

1. 项目整体设计与技术选型思路

1.1 蜜蜂检测的真实难点

很多人觉得蜜蜂识别不就是“框一个目标”嘛，模型丢进去训练就完事，等自己动手才发现坑不少。我先把蜜蜂目标检测的难点列出来，这些直接决定了后续的选型策略。

第一是目标尺寸小。常规监控画面里，一只蜜蜂可能只占十几个到几十个像素，和整幅图640乘640的分辨率比起来，属于典型的小目标。小目标的问题在于下采样后特征非常容易丢失，网络很难学到底层纹理和轮廓信息，这也是很多通用目标检测模型在蜜蜂场景下精度骤降的原因。

第二是密集遮挡。蜂箱口、花丛里蜜蜂经常重叠在一起，密集场景下边框回归的竞争很严重。检测头需要同时输出准确的框位置和类别置信度，一旦两个相邻目标靠得太近，NMS（非极大值抑制）很容易把其中一个框误杀。

第三是背景干扰。蜜蜂活动场景里花瓣、叶片、同类昆虫、甚至蜂箱上的纹理都会产生大量误检。特别是在浅色背景下，蜜蜂的黄色和黑色条纹对比足够强还好，逆光或阴影下边缘轮廓模糊，模型很容易“看走眼”。

第四是实时性要求。如果只是离线分析几张图片，用重型检测网络也没问题，但要做视频流或者实拍统计，单帧处理时间就必须压到几十毫秒级别。综合这四点，选型的核心诉求就很清晰：精度不能低，推理要快，还得对小目标和密集场景友好。

1.2 为什么选YOLOv11而不选其他检测框架

因为要同时满足精度和速度，我的对比范围主要锁定在一阶段检测器。两阶段的Faster R-CNN精度虽然不错，但推理速度在蜜蜂这种需要高频监测的场景下不太够用；SSD这类早期一阶段模型对小目标的支持又相对一般；YOLO系列经过多版本迭代，对目标尺度和推理效率的平衡做得最好。

具体到YOLOv11，它在结构上延续了YOLO系列高效的特征提取思路，主干部分采用分层模块设计，跨阶段连接和注意力机制的搭配让小目标的细节信息保留得更好，检测头的解耦设计也比旧版本好调。对比YOLOv5和YOLOv8，YOLOv11在相同推理速度下精度普遍有提升，参数量却更精简，模型文件也小一圈，Web端加载权重更轻，对部署很友好。

我放了张对比表，方便直观理解当时选型的理由：

从实际项目角度讲，YOLOv11还有一个优势是官方工具链比较友好，训练配置、导出模型、推理调用都集成在统一框架里，省去了从头造轮子的时间。加上社区资料多，训练过程遇到问题能很快找到思路，对做项目的人来说效率就是一切。

1.3 系统功能模块划分

整套系统在功能上拆成五个模块。最底层的模型服务负责加载权重、执行推理和返回检测框；紧接着是Web服务端，用Python的后端框架处理请求、上传文件、调推理接口；用户模块里包含登录、注册和会话状态管理，保护系统不被随便调用；前端界面负责交互，上传图片、展示标注框、显示识别结果；最后是数据管理模块，维护标注数据集、训练配置和识别历史记录。

这种分层的好处是每个环节都可以独立测试和替换。模型效果不好可以单独重训权重，界面丑陋可以只改前端模板，用户数据表有变化也只动服务端代码。后面不管做实时视频接入，还是扩展别的目标类别，都不需要推倒重来。

2. 环境搭建与核心依赖配置

2.1 硬件环境与性能预期

训练和推理对硬件的要求完全是两个量级。训练阶段，YOLOv11至少需要一张支持CUDA的显卡才算舒服，显存大小直接决定单批能塞多少图片。我在项目里用的是8GB显存级别的卡，单批数量控制在16到32张，纯CPU训练不是不行，但一个几百张蜜蜂图片的数据集会拖到地老天荒。

推理阶段对硬件就宽容很多。Web服务跑在普通的四核CPU上也能达到单张图片几百毫秒的处理速度，如果换到带GPU的环境，可以轻松做到实时视频流。实测下来，CPU环境下加载yolo11n权重进行单张图片推理大约在200到400毫秒之间，GPU环境下能压到十几毫秒，这个差距在做实时检测时需要提前考虑。

2.2 Python环境与依赖安装清单

为了避免环境污染，我强烈建议用虚拟环境来隔离项目依赖。Python版本建议选择3.9到3.11之间，太旧的版本对新版库支持不好，太新的版本部分CUDA组件可能还没跟上。核心依赖我直接做成了一份requirements.txt，内容大致包含如下几个库。

• ultralytics：YOLOv11训练与推理的核心工具库
• torch与torchvision：深度学习框架及其视觉组件
• opencv-python：图像处理与格式转换
• Flask：Web服务端框架
• Pillow：图片处理兜底
• numpy：数值运算
• PyMySQL或sqlite3：用户数据持久化，我项目里用的SQLite

安装顺序建议先装PyTorch，再装ultralytics，因为ultralytics会检测PyTorch的版本和CUDA是否可用。如果先装ultralytics再补torch，有可能出现版本匹配问题，训练时报出一堆莫名其妙的依赖错误。GPU版的PyTorch安装时要注意CUDA版本要和驱动匹配，直接在官方地址按平台复制安装命令是最稳妥的方式。

2.3 项目目录结构设计

一个清晰的项目目录能省掉大量找文件的痛苦，尤其是这种同时包含训练代码、模型权重和Web应用的项目。我实际使用的目录结构如下，你完全可以按这个骨架去搭。

text复制bee_detect/
├── app.py                 # Flask 入口，路由与视图逻辑
├── models/
│   ├── yolo11n.pt         # 预训练权重
│   └── best.pt            # 自己训练完成的蜜蜂检测权重
├── datasets/
│   └── beedata/
│       ├── images/
│       │   ├── train/
│       │   └── val/
│       ├── labels/
│       │   ├── train/
│       │   └── val/
│       └── bee.yaml       # 数据集配置文件
├── templates/
│   ├── login.html
│   ├── register.html
│   └── detect.html
├── static/
│   ├── css/
│   ├── js/
│   └── uploads/
├── utils/
│   └── auth.py            # 登录注册与会话管理
└── requirements.txt

datasets目录严格按照YOLO格式组织，图片和标签一一对应，训练脚本直接读取bee.yaml里的路径配置。best.pt是训练阶段生成的最终权重，统一放到models目录下方便推理模块调用。前后端资源分离，UI页面只放在templates和static里，逻辑代码绝不和页面代码混在一起，后面做页面改版或换框架都会容易很多。

3. 数据集的采集、标注与增强

3.1 蜜蜂数据来源与类别定义

数据集是整个项目的地基。我最初把蜜蜂图片分成了两条来源：一是在蜂箱附近实地拍摄的视频中逐帧抽取画面，二是从公开的农业病虫害数据集里筛选出包含蜜蜂的样本。两条腿走路的好处是既能保证场景贴合实际情况，又能快速把样本数量拉到可训练的水平。

类别定义上我采用了最简单的方案，只定义了一个类别：bee。项目目标是单类检测，类别越少，训练难度越低，边界混淆也越少。如果后续想区分工蜂和雄蜂，或者检测蜂箱里的蜂王，那就在标注阶段就按多个类别划分，重新走一遍数据流程。类别定义会直接影响输出层设计，所以一开始就要想清楚，不要训练到一半才改。

标注数量上我的经验是：单类目标检测至少准备800到1500张有效图片，其中正样本要涵盖不同光照、不同背景、不同密度的蜜蜂。样本太少模型容易过拟合，只记住训练集里的特定场景；样本太杂但质量不高，又会让模型学到一堆噪声特征。这个项目里我最终保留了1000张左右，按8比2的比例划分训练集和验证集。

3.2 标注工具与过程规范

标注工具我用的是LabelImg，它是目标检测领域最常用的标签工具之一，输出YOLO格式的txt文件非常方便。YOLO标签格式的核心是每个目标一行，内容为类别序号加上归一化的中心点坐标和宽高，如下面这个例子：

text复制0 0.534180 0.387500 0.089844 0.432812

上面这行数字表示第一个类别，目标中心点在图像的53.4%宽度、38.75%高度位置，目标宽约图像宽度的9%，高约图像高度的43.3%，所有数值都是在0到1之间归一化的。手动标注时工具会自动计算这些值，不需要去心算。

标注规范里我最想强调的一点是边界框的紧致程度。画蜜蜂时，框要尽量贴合蜜蜂的身体轮廓，不要把花蕊、叶片也圈进去。对于重叠的蜜蜂，如果视觉上能分辨出明显的轮廓边界，就分开标注；如果两个目标完全重叠到分不清，只标一个反而比硬标两个对模型更友好。标注时还要注意每个目标的最小像素尺寸，太小的目标标注上去标签本身误差就大，模型学不到有效信息。

我做数据清洗时筛掉了很多模糊、严重过曝和反光严重的图片，这类图片对识别效果没有帮助，反而会让模型试图去学习噪声特征。一个常用经验是目标在图片中至少要有30乘30像素，否则标注误差占比太高，训练时很容易干扰边框回归损失。

3.3 数据增强策略与小目标专项处理

数据增强是提升模型泛化能力的利器，尤其是对小目标检测。YOLOv11在训练时默认会做Mosaic增强，也就是把四张图随机裁剪拼接成一张新图，这样能让模型看到更多小尺度的目标特征，同时提高对遮挡的鲁棒性。

我在YOLOv11默认增强之外，又针对性调整了几个参数。平移和缩放的比例控制在10%到20%，避免变换太夸张导致目标形状失真；HSV色域增强里色调和饱和度的扰动范围稍微调大了一些，因为蜜蜂在不同角度和光线下，黄色条纹的色相变化明显，模型必须适应这种变化才能避免误检。

对于小目标问题，最直接的手段是把训练输入分辨率imgsz调大。默认的640像素用在蜜蜂检测上会出现大量漏检，因为蜜蜂本身占比太小，缩放后细节被压缩得很严重。我把输入尺寸调到832，精度提升非常明显，代价是训练和推理速度变慢，但项目的实时性要求还在可接受范围内。如果目标是密集花朵场景，甚至可以继续往1024走，但显存占用也会成倍增加。

4. YOLOv11模型训练与性能调优

4.1 预训练权重与数据集配置文件

训练之前要先准备两份关键文件：预训练权重和数据集配置文件。YOLOv11官方提供了不同尺寸的预训练权重，从轻量到重型依次可以选yolo11n、yolo11s、yolo11m、yolo11l等规格。蜜蜂检测这种单类小目标场景，我建议从yolo11s这个尺寸起步，它比nano版本特征提取能力更强，比medium版本训练更快、显存占用更低。

数据集配置文件是一个yaml格式的文件，告诉训练脚本图片路径和类别信息。我项目的bee.yaml长这样：

yaml复制path: ./datasets/beedata
train: images/train
val: images/val
names:
  0: bee

这里最需要注意的是路径写法。path既可以用相对路径也可以用绝对路径，但训练脚本的工作目录不同会导致相对路径失效，建议直接写成项目根目录下的相对路径，并在统一的入口脚本里执行训练，避免找到不文件这种低级错误。

4.2 训练参数配置与调整思路

训练参数的设置直接影响收敛速度和最终精度。我用一行训练命令就能跑起来，但每个参数背后都有讲究：

python复制from ultralytics import YOLO

model = YOLO("yolo11s.pt")
model.train(
    data="datasets/beedata/bee.yaml",
    epochs=150,
    imgsz=832,
    batch=16,
    lr0=0.01,
    optimizer="SGD",
    workers=4,
    seed=42
)

epochs设置150轮是考虑到蜜蜂数据集数量不大，模型需要较长时间充分收敛。但实际训练中很少真的跑满150轮才停，可以开启早停机制，当验证集指标连续几十轮不再提升就自动停止，能省掉不少时间。

batch要结合显存来定，理论上是越大越好，因为梯度更稳定、收敛更平滑，但8GB显存下imgsz=832时batch最多开到16。如果显存不够，优先降低batch而不是降低分辨率，因为分辨率对蜜蜂小目标的影响比batch大得多。

初始学习率lr0=0.01是YOLO系列默认值，配合SGD优化器在中小数据集上表现很稳定。如果想用AdamW，学习率通常要降到0.001甚至更低，否则前期容易震荡不收敛。训练时我一般会监控训练损失和验证损失两条曲线，两只曲线都平稳下降说明状态正常；如果训练损失继续降而验证损失回升，就是过拟合的前兆，需要加强增强或提前停止。

4.3 训练效果评估与模型导出

训练结束后，YOLO会在项目根目录下的runs/detect/目录里生成训练结果，包含权重文件、损失曲线图和各类指标。检测任务最核心的指标有两个：mAP50和mAP50-95。前者衡量框和真实目标交并比超过50%时的平均精度，后者更严格，从50%到95%按步长计算平均，对框位置精度要求更高。

我做这个蜜蜂模型时，最终验证集上的mAP50达到了90%出头，mAP50-95在65%左右。这个水平对蜜蜂检测够用，说明模型能稳定找到蜜蜂且框的位置基本贴合。如果你发现mAP50高但mAP50-95偏低，说明框定位不够精细，需要在输入分辨率或边框回归权重上继续调。

导出模型时，我用ONNX格式作为中间转换格式，一方面可以加速CPU推理，另一方面以后想部署到服务端或边缘设备都方便。导出代码很简单：

python复制from ultralytics import YOLO

model = YOLO("runs/detect/train/weights/best.pt")
model.export(format="onnx", imgsz=832, simplify=True)

导出的best.onnx可以直接用ONNX Runtime加载推理，也可以用ultralytics自带的推理接口继续调用。需要注意的是导出分辨率要和训练一致，否则输入尺寸变了，检测效果可能明显下降。

5. 登录注册与检测UI的实现

5.1 登录注册模块与用户数据库

既然标题里明确了要有登录注册界面，那用户体系就要认真做。项目里我用Flask作为Web框架，配合SQLite存用户信息，再用一个auth.py工具模块封装认证逻辑。密码不能明文存数据库，我用哈希算法处理，登录时对比哈希值。这样即使数据库文件泄露，也不会直接暴露用户密码。

先看一下用户表的表结构和核心注册逻辑：

python复制import sqlite3
import hashlib
import os

def hash_password(password: str) -> str:
    salt = os.urandom(16).hex()
    hashed = hashlib.sha256((salt + password).encode()).hexdigest()
    return f"{salt}${hashed}"

def verify_password(password: str, stored: str) -> bool:
    salt, hashed = stored.split("$")
    return hashlib.sha256((salt + password).encode()).hexdigest() == hashed

# 创建用户表
conn = sqlite3.connect("user.db")
conn.execute("""
    CREATE TABLE IF NOT EXISTS users (
        id INTEGER PRIMARY KEY AUTOINCREMENT,
        username TEXT UNIQUE NOT NULL,
        password_hash TEXT NOT NULL,
        created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP
    )
""")

注册时先检查用户名是否已经存在，不存在再写入新用户记录。登录时根据用户名查出密码哈希值，调用verify_password验证。用户名重复和密码错误两种情况都要给出明确的提示，前端再通过弹窗或文本把结果反馈给用户，体验才好。

登录成功后我用Flask的session机制保持会话状态。session会把用户状态写入浏览器的加密cookie，服务端靠它识别当前用户是否已登录。受保护的检测页面在调用前先判断session，如果没登录就跳转回登录页面，这是一种最基本的访问控制手段。

5.2 检测页面与模型推理的衔接

检测页面是这个项目的核心交互页面，用户进入后可以上传一张图片，系统调用训练好的YOLOv11模型完成推理，把检测结果直接渲染到网页上。最关键的后端代码如下：

python复制from flask import Flask, request, render_template, session, redirect, url_for
from ultralytics import YOLO
import os
import uuid

app = Flask(__name__)
app.secret_key = "your-secret-key"
model = YOLO("models/best.pt")

@app.route("/detect", methods=["GET", "POST"])
def detect():
    if "user" not in session:
        return redirect(url_for("login"))

    if request.method == "POST":
        file = request.files["image"]
        if not file:
            return "请选择图片"

        filename = f"{uuid.uuid4().hex}.jpg"
        filepath = os.path.join("static/uploads", filename)
        file.save(filepath)

        results = model.predict(source=filepath, conf=0.35, iou=0.45)
        boxes = results[0].boxes
        data = []
        for box in boxes:
            x1, y1, x2, y2 = box.xyxy[0].tolist()
            conf = float(box.conf[0])
            cls = int(box.cls[0])
            data.append({
                "class": results[0].names[cls],
                "confidence": round(conf, 4),
                "box": [round(x1), round(y1), round(x2), round(y2)]
            })
        results[0].save(filename="static/results/result.jpg")
        return render_template("result.html", data=data, image="result.jpg")

    return render_template("detect.html")

推理时两个参数要注意：conf是置信度阈值，低于这个值的检测框会被过滤掉；iou是NMS的交并比阈值，值越高滤掉的框越少。我项目里conf=0.35是结合验证集表现调出来的平衡点，太小会混进大量误检，太大则漏检增多；iou=0.45在蜜蜂密集场景下能保留更多相邻检测框。

model.predict处理完以后，我调用results[0].save()把带标注框的原图保存到静态目录，前端页面直接引用保存的图片，再把每个框的坐标和置信度用表格展示出来。这样用户看到的既有直观的标注图，又有量化的数据可以导出，实用感很强。

5.3 界面细节与实时视频扩展思路

界面设计不需要多花哨，但要让用户看得懂。检测页面上传区要有拖拽或点击上传的交互，上传后显示预览缩略图；等待推理时显示“识别中”状态，避免重复点击；结果区把标注图和目标数量、每个目标的置信度一起呈现，让用户一眼能看出系统干了什么活。

如果想从单张图片检测扩展到视频流，其实不需要改模型，只需要把推理入口从图片路径改成视频流帧，再把结果叠加到帧上编码成新的视频或直接推送到前端显示。对于实时摄像头场景，还可以把推理搬到带GPU的服务器上，保证每一帧的处理速度跟得上采集帧率。这是这套系统最自然的扩展方向，代码层面改动并不会伤筋动骨。

6. 常见问题排查与实战经验

6.1 训练阶段的典型问题

显存不足是第一个高频问题。训练时报CUDA out of memory，通常是因为batch设得太大或者输入分辨率太高。我的解决思路是优先降batch，再不行就把workers调低释放部分内存。如果还想在低显存下保持较高分辨率，可以考虑开启cache参数，把数据提前缓存到内存里，减少GPU上的数据解压负担。

训练不收敛通常表现为损失不下降或上下剧烈震荡。这时第一件事是检查学习率，太大就调小一个数量级；第二件事是检查数据标注有没有错，尤其是标签里的类别序号和bee.yaml里的names是否对应；第三件才是看网络结构设置。很多时候不是模型问题，是数据和配置问题。

过拟合在小数据集上非常常见。训练损失一路走低、验证损失在几十轮后开始回升，就是典型的过拟合信号。这种情况下我会加大数据增强强度，比如把Mosaic开启概率调高；同时配合早停，保存验证集上指标最好的那一轮权重，而不是最后一轮权重。

6.2 检测效果相关的调优

模型跑起来以后，漏检和误检是最影响体验的问题。漏检的处理方向是降低conf阈值，或者提高输入分辨率；误检则相反，需要提高conf阈值，并检查验证集里是否有很多背景相似的负样本。蜜蜂检测的误检经常来自叶片纹理和蜂箱边框，遇到这种情况可以再收集一批含这些背景的负样本，单独做一轮难样本挖掘。

NMS参数iou对密集场景影响很大。蜜蜂重叠多时，如果iou阈值太高，相邻目标会被合并成一个；太低则同一个目标可能出现多个重复框。实测中我通常把iou放在0.4到0.5之间，再结合具体的密集程度微调。

还有一个容易忽略的坑：训练和推理时的imgsz不一致会让精度大幅下降。如果训练用的是832，推理就必须保持832，否则模型看到的特征尺度完全变了，漏检率会急剧上升。

6.3 Web服务与部署阶段的常见问题

Flask服务启动时最常遇到的问题是端口占用。默认跑在5000端口，如果出现Address already in use，可以用python app.py --port 8080换端口，或者在代码里直接指定app.run(port=8080)。

模型加载慢也是部署时的痛点。加载权重文件涉及模型结构和参数的初始化，首次请求会特别慢。我的解决办法是在服务启动的时候就把模型加载到内存里，而不是每个请求都重新加载一次，这样后续请求基本都是毫秒级响应。代价是服务启动时间变长，但用户体验提升非常明显。

上传文件的路径处理也值得注意。保存图片时要使用绝对路径拼接和随机的文件名，避免覆盖和路径穿越问题。我在项目里用uuid生成文件名，同时限制只接受jpg、png等常见图片扩展名，防止用户上传非图片文件导致后端处理出错。

6.4 数据与标注质量的经验复盘

如果让我重新做一遍这个项目，我会在数据积累上多花一倍时间。训练阶段跑出90%的mAP50看起来不错，但换到野外新场景测试的时候，泛化能力还是会打折扣。原因是场景多样性不够，单靠数据增强只能模拟变化，不能替代真实场景的多样性。多去几个不同拍摄角度和光线条件的地方采集数据，比纠结一个点的调参收益大得多。

标注的一致性也值得反复检查。我自己中途有段时间标注了一个叶子后面的半只蜜蜂，后面对比标签时发现问题，重新修正后才让模型收敛更稳定。标注主观偏差会直接影响边框回归的收敛上限，哪怕只差几个像素，积累到上千张图上就是系统性误差。

6.5 后续扩展与使用建议

遇到有毕设或工程需求的朋友问这套系统能不能直接用，我通常建议三个扩展方向：增加工蜂、雄蜂等多类别检测，把单类模型升级成多类模型；接入蜂箱出入口的摄像头做进出流量统计，结合时间轴数据可视化，这是养蜂管理最痛的需求；把模型导出成TensorRT或OpenVINO格式，部署到边缘设备上做实时推理。

我自己实际用下来最满意的一点是，这套方案从数据准备到Web界面全部开源可控，不依赖任何闭源平台，将来换场景只需要换数据集重训模型就行。踩过几次坑之后也总结出来，目标检测项目最怕上来就调参，老老实实把数据规范和标注一致性做到位，模型最后基本不会太差。

这篇文章写到这，所有关键环节都摊开讲完了。想复现的话，建议严格按照环境、数据、训练、界面四步顺序走，遇到问题时对照第六节排查。项目后续要继续扩展，优先级最高的永远是数据采集和标注质量的提升，这方面投入的时间和算力一样值钱。