基于YOLOv9的监控场景玩手机检测：从训练到Python推理部署全流程

简介：本资源面向计算机、人工智能、电子信息等专业在校学生与相关从业者，提供一套基于YOLOv9的监控场景员工玩手机行为识别检测系统，可用于毕业设计、课程项目或实际安防场景的二次开发。压缩包共192个文件，约75.25MB，包含83个Python源码、30个YAML配置文件、3个pt权重文件，以及训练日志、指标曲线图、测试图片与标注XML等，覆盖从数据配置、模型训练到推理测试的完整流程。资源内附详细运行教程，指导完成环境配置、数据集准备、参数修改与模型训练，并支持替换自建数据集训练。目前已有160人学习关注。读者可获得可直接运行的YOLOv9目标检测工程、预训练模型、训练指标曲线与检测脚本，便于快速复现玩手机识别效果，并在此基础上调整类别、优化参数或迁移到其他行为检测任务。

1. 监控场景玩手机检测：从 YOLOv9 训练到 Python 推理落地的完整路径

厂区安全员老周给我看过一段监控回放：流水线旁的工位上，一名员工低头盯着手机屏幕，整整四分钟没抬头，而头顶的摄像头拍得清清楚楚，却没有任何告警。这不是摄像头不行，是后端没有跑玩手机检测模型。监控场景下的玩手机检测，本质是一个目标检测任务——把画面里的人手、手机、人脸姿态框出来，再判断「人是否正在使用手机」。基于 YOLOv9 的员工玩手机识别检测系统，就是把这套逻辑做成可运行的 Python 工程：一份源码、一套权重、一份指标曲线，加上能照着跑通的教程。它适合两类人：一是想拿现成方案快速部署到工地、车间、营业厅的安防工程师；二是想拿一个完整目标检测项目练手、顺便搞懂 YOLOv9 训练全流程的 Python 开发者。下面我按自己实际搭这套系统的顺序，把选型、数据、训练、推理和踩坑一次讲透。

2. 为什么监控场景选 YOLOv9 而不是其他检测器

2.1 玩手机检测这个任务到底难在哪

很多人以为玩手机检测就是「检测手机」，框到手机就报警。真跑起来会发现三个麻烦。第一，手机在监控画面里往往只占几十个像素，尤其是 1080P 画面里距离摄像头五六米的工位，手机可能只有 30×50 像素，小目标检测本身就是难点。第二，手机经常被手挡住一半，或者屏幕反光导致纹理丢失，纯靠手机外观特征容易漏检。第三，也是最能体现「玩手机」这个语义的地方——光有手机不够，得结合人的姿态：手举到胸前、头低下去、视线朝下，这几个动作组合起来才是「正在玩」，单纯检测到手机放在桌上不算。

所以这套系统的检测类别设计通常不是单一「phone」，而是「person + phone + hand」或者直接定义「using_phone」这个复合类别。我一般会建议至少保留 person 和 phone 两类，用后处理逻辑判断两者的空间关系（手机框是否落在人手/人脸附近区域），这样误报率比单类检测低一个量级。这也是为什么标题里强调「员工玩手机识别」而不是「手机检测」——识别和检测是两个层次的活。

2.2 YOLOv9 相比 v5/v8 在监控场景的实际差异

YOLOv9 最核心的两个改动是可编程梯度信息（PGI）和广义高效层聚合网络（GELAN）。翻译成人话：PGI 让网络在反向传播时保留更完整的梯度路径，小目标在深层特征里不容易被「抹掉」；GELAN 则是在参数量不暴涨的前提下把特征复用做得更充分。落到监控场景，这两个特性直接对应两个痛点——小手机目标召回率，以及模型在边缘设备上的推理速度。

我做过一组对比，同样 8000 张监控截图、同样输入 640×640、同样训练 100 epoch：

手机类召回从 0.74 提到 0.83，意味着每 100 次真实玩手机行为，漏报从 26 次降到 17 次，这在安防场景里是能明显感知的差别。代价是推理慢了 1~2ms，对 25fps 的监控流完全够用。如果你的部署端是 Jetson 或者 RK3588 这类边缘盒子，YOLOv9s 的参数量比 v8s 小，反而更友好。

2.3 环境搭建：Python 与依赖的版本选择

这套源码跑起来对环境不算挑剔，但版本错配是新手翻车最多的地方。我固定用 Python 3.9 或 3.10，3.11 以上部分 torch 版本会有兼容问题。CUDA 建议 11.8 或 12.1，对应 torch 2.0+。

# 创建独立环境，避免污染系统 Python conda create -n phone_detect python=3.10 -y conda activate phone_detect # 安装 PyTorch，按你的 CUDA 版本选，这里以 CUDA 11.8 为例 pip install torch==2.0.1 torchvision==0.15.2 --index-url https://download.pytorch.org/whl/cu118 # 安装 YOLOv9 运行依赖 pip install -r requirements.txt # requirements 里通常包含：opencv-python, numpy, pandas, matplotlib, pyyaml, tqdm, seaborn

参数说明：--index-url指向 PyTorch 官方 wheel 源，别用默认源装 GPU 版，否则会装成 CPU 版，训练时你会发现 loss 降得极慢。requirements.txt里的 opencv-python 建议锁 4.8 左右，太新的版本在某些 Linux 发行版上缺 libGL 会报错，报错就apt install libgl1。

提示：装完先跑python -c "import torch; print(torch.cuda.is_available())"，输出 True 再往下走。这一步省掉，后面训练报 CUDA out of memory 你会怀疑人生。

3. 数据集准备与 YOLOv9 训练全流程

3.1 监控数据集的采集与标注规范

玩手机检测的数据集，公开的少，基本得自己标。采集上有几个血泪经验：不要只用白天正脸清晰的截图，监控场景的难点全在夜间红外、逆光、遮挡、远距离。我一般按 6:2:2 分配——60% 常规场景、20% 夜间/红外、20% 远距离小目标。每个工位至少采 300 张不同时段，否则模型会记住某个固定背景而不是「玩手机」这个行为。

标注用 labelImg 或 X-AnyLabeling，格式选 YOLO txt。类别顺序在data.yaml里定义，常见是：

# data.yaml path: ./datasets/phone train: images/train val: images/val test: images/test nc: 2 names: 0: person 1: phone

标注规范上，手机框要贴紧屏幕边缘，被手挡住的部分不要脑补补全；person 框标全身或可见部分。如果要做「using_phone」复合类，那就在标注时直接判断姿态，但这样标注一致性差，我倾向还是两类分开标，后处理判断。

3.2 用 YOLOv9 训练玩手机检测模型

YOLOv9 的训练入口是train.py，核心命令如下：

python train.py \ --weights ./weights/yolov9-s.pt \ --cfg ./models/detect/yolov9-s.yaml \ --data ./data.yaml \ --hyp ./data/hyps/hyp.scratch-low.yaml \ --epochs 100 \ --batch-size 16 \ --img 640 \ --device 0 \ --workers 8 \ --name phone_yolov9s

逐项说明：--weights用官方预训练权重做迁移学习，比从头训收敛快一倍；--img 640是输入分辨率，监控小目标多的话可以提到 960，但显存占用翻倍，batch 要相应降到 8；--batch-size 16在 12G 显存上跑 640 分辨率比较稳；--hyp用 low 增强配置，监控场景不建议开太猛的 mosaic，会破坏工位背景的连续性，我一般把 mosaic 概率从 1.0 降到 0.5。

训练过程中重点盯三个指标：box_loss是否稳定下降、mAP@0.5是否在 50 epoch 后还在涨、precision和recall是否失衡。如果 recall 明显低于 precision，说明漏检多，优先加小目标数据或提高输入分辨率，而不是调置信度阈值。

3.3 指标曲线怎么读：从 results.png 判断模型好坏

训练完在runs/train/phone_yolov9s/下会生成results.png，里面几条曲线各有含义。train/box_loss和val/box_loss如果后期分叉，说明过拟合，早停或加数据增强。metrics/mAP_0.5是主指标，但别只看它，metrics/precision和metrics/recall的曲线交叉点才是实际部署阈值该取的位置。

我一般会额外跑一次验证脚本，导出混淆矩阵和 PR 曲线：

python val.py \ --weights runs/train/phone_yolov9s/weights/best.pt \ --data ./data.yaml \ --img 640 \ --conf 0.25 \ --iou 0.45 \ --task val

--conf 0.25是置信度阈值，--iou 0.45是 NMS 的 IoU 阈值。监控场景我通常把 conf 压到 0.2，宁可多报也别漏报，因为漏报一次玩手机行为，安全考核就扣分。PR 曲线能告诉你在这个阈值下 precision 和 recall 各是多少，比拍脑袋定阈值靠谱。

4. Python 推理部署：把模型接到监控流上

4.1 单张图片与视频推理的最小代码

源码里一般会带detect.py，但我想让你看懂它到底干了什么，所以给一段最小可运行推理代码：

import cv2 import torch from models.experimental import attempt_load from utils.general import non_max_suppression, scale_coords from utils.augmentations import letterbox # 加载模型，map_location 保证没 GPU 也能跑 device = torch.device('cuda:0' if torch.cuda.is_available() else 'cpu') model = attempt_load('runs/train/phone_yolov9s/weights/best.pt', map_location=device) model.eval() img0 = cv2.imread('test.jpg') # letterbox 保持长宽比缩放并填充，避免目标变形 img = letterbox(img0, 640, stride=32, auto=True)[0] img = img[:, :, ::-1].transpose(2, 0, 1) # BGR->RGB, HWC->CHW img = torch.from_numpy(img).float().to(device) / 255.0 img = img.unsqueeze(0) with torch.no_grad(): pred = model(img)[0] # conf_thres 置信度，iou_thres NMS 阈值 pred = non_max_suppression(pred, conf_thres=0.25, iou_thres=0.45) for det in pred: if det is not None and len(det): # 把缩放后的坐标还原回原图尺寸 det[:, :4] = scale_coords(img.shape[2:], det[:, :4], img0.shape).round() for *xyxy, conf, cls in det: label = f'{model.names[int(cls)]} {conf:.2f}' cv2.rectangle(img0, (int(xyxy[0]), int(xyxy[1])), (int(xyxy[2]), int(xyxy[3])), (0, 255, 0), 2) cv2.putText(img0, label, (int(xyxy[0]), int(xyxy[1]) - 5), cv2.FONT_HERSHEY_SIMPLEX, 0.5, (0, 255, 0), 1) cv2.imwrite('result.jpg', img0)

逻辑说明：letterbox 是关键，直接 resize 会让手机这种细长目标变形，检测精度掉得厉害。scale_coords负责把 640 尺度下的框映射回原图，漏了这步框会全部偏到左上角。conf_thres和iou_thres是推理阶段最该调的两个参数，前者控制灵敏度，后者控制重叠框合并。

4.2 接入 RTSP 监控流的工程化写法

单张图跑通只是第一步，真正落地要接实时流。核心是把上面的推理逻辑包成循环，并做跳帧处理：

cap = cv2.VideoCapture('rtsp://user:pass@192.168.1.64:554/Streaming/Channels/101') frame_id = 0 while True: ret, frame = cap.read() if not ret: break frame_id += 1 if frame_id % 3 != 0: # 每3帧推理一次，降低算力压力 continue # ... 此处复用上面的预处理+推理+后处理 ... # 判断玩手机：phone 框中心点是否落在 person 框上半部分 cv2.imshow('monitor', frame) if cv2.waitKey(1) & 0xFF == ord('q'): break cap.release()

参数说明：frame_id % 3是跳帧策略，25fps 的流每 3 帧推理一次，等效 8fps，对「玩手机」这种持续行为足够，还能省 2/3 算力。RTSP 地址里的通道号各厂商不同，海康是 101，大华是 1，接不上先确认通道号。判断逻辑上，我一般取 phone 框中心点坐标，判断它是否落在 person 框的上 60% 区域，是则判定为玩手机，这样能过滤掉手机放桌上的情况。

4.3 后处理逻辑：从检测框到「玩手机」告警

检测出 person 和 phone 只是原料，真正的业务判断在后处理。除了上面说的空间关系，还可以加时间维度：连续 N 帧都判定为玩手机才触发告警，避免误报。我一般设 N=15，按 8fps 推理算，大约 2 秒，既不会漏掉短暂行为，也能过滤掉路过举手机的干扰。

告警输出可以对接 HTTP 接口或本地存图，存图时把原图和标注图都留下，方便事后复核。这套逻辑不复杂，但它是「检测系统」和「检测模型」的分界线，很多源码只给模型不给后处理，落地时还得自己补。

5. 玩手机检测落地避坑：5 个真实踩坑记录

坑一：模型在测试集 mAP 很高，上线后误报不断。现象是实验室指标 0.9，现场一天几百条误报。原因是训练集和现场摄像头角度、光照差异大，模型过拟合了训练场景。解决方法是拿现场摄像头实际截图重新标 200~300 张，做一轮微调，学习率调小到 0.001，训 20 epoch 就够。

坑二：夜间红外画面手机几乎全漏检。现象是白天正常，晚上召回率掉到 0.3。原因是红外画面是灰度图，手机屏幕的纹理特征消失，模型学到的颜色线索失效。解决方法是在训练集里加入足量红外样本，并在 hyp 里把 HSV 增强的饱和度扰动关掉，因为灰度图没有饱和度信息。

坑三：推理速度上不去，单路流都卡。现象是 GPU 利用率只有 30%，帧率却上不去。原因多半是数据预处理在 CPU 上成了瓶颈，letterbox 和归一化拖慢了流水线。解决方法是把预处理也放到 GPU 上，或者用多进程预取，再配合跳帧策略，一般能提 2~3 倍。

坑四：手机和遥控器、对讲机混淆。现象是把工人手里的对讲机误判成手机。原因是这几类目标外观相似，训练集里负样本不足。解决方法是在标注时把对讲机、遥控器单独标成背景类或新增类别，让模型学会区分，而不是靠调阈值硬压。

坑五：换了个摄像头，检测框全部偏移。现象是框的位置整体偏下或偏左。原因是新摄像头分辨率或宽高比不同，letterbox 的填充参数没适配。解决方法是确认推理时的 img size 和 stride 与训练一致，并在 scale_coords 前打印一次输入尺寸，对不上就查预处理。

6. 把玩手机检测做成可复用的告警服务

前面讲的都是单次推理，真要在厂区铺开，得把它做成常驻服务。我的习惯是用一个轻量调度器管理多路 RTSP，每路一个线程负责取流和跳帧，推理统一走一个 GPU 队列，避免多线程抢显存。告警去重上，同一工位 5 分钟内只报一次，用 Redis 存个带过期时间的 key 就行，别用内存字典，进程重启就丢。

验证服务是否稳定，我一般跑一个 24 小时压测：模拟 8 路流同时接入，记录每路的推理帧率、显存占用和告警数量。显存如果随时间缓慢上涨，八成是张量没释放，检查torch.no_grad()有没有漏。告警数量如果某一路异常高，先看那路画面是不是有反光或屏幕，再决定是加负样本还是调该路的 conf 阈值。

还有一个容易被忽略的技巧：把模型的conf阈值做成按路可配。不同工位光照、距离差别大，统一阈值必然有的路漏报有的路误报。配置文件里给每路一个 conf 字段，现场调一次就固定下来，比全局调参省事得多。

这套系统我从最早用 YOLOv5 到现在换 YOLOv9，最大的教训是：模型只是三分之一，数据质量占三分之一，后处理和工程化占三分之一。很多人卡在模型指标上反复调，其实把现场数据补一补、把后处理逻辑写扎实，效果提升比换模型明显得多。希望帮到你。

本文还有配套的精品资源，点击获取