简介面向目标检测与行为识别开发者一套专为“打电话/玩手机”场景设计的数据集支持YOLOV11格式标注可覆盖手持打电话、非接触式打电话、玩手机自拍等细分行为适合用于安防监控、驾驶舱监管或课堂状态分析等场景。资源包共2000个文件其中包含724张jpg原始图像、1275个txt标注文件及1个yaml配置文件总大小51.36MB标注格式与YOLO系列模型直接兼容便于快速投入训练与验证。从内容预览来看图片多来自视频抽帧与实拍画面涵盖多样角度与光照条件标注信息完整可有效提升模型对不同姿态和远近目标的泛化能力用户只需按YOLOV11要求调整路径即可使用。当前已有851人学习下载数据集经过预处理与格式整理省去自行采集标注的繁琐环节适合需要快速建立行为识别模型的初学者与实战项目开发者。1. 打电话玩手机识别别被“手持检测”骗了真正的难点是这三类目标很多刚接触这个领域的人接到“打电话玩手机识别”的需求后第一反应都是直接训练一个手机目标检测器。但实际落地时你会发现光有手机框根本判不了行为非接触式打电话时手机可能在支架上、在肩膀上甚至拿在手里但没贴耳朵而玩手机自拍和手持打电话的视觉表现又高度重叠。这份支持 YOLOv11 格式标注的数据资源把目标拆成了手持打电话、非接触式打电话、玩手机自拍三类省掉了我最头疼的标注整理环节。拿到手之后我花了不少精力做格式校验、调训练参数、跑推理验证中间踩了不少坑。这篇文章就把从数据检查到最终可部署推理的完整过程写下来给正要在这类行为检测场景里用 YOLOv11 的工程同学做个参考。2. YOLOv11 格式的数据集先检查标签再谈训练2.1 目录结构和标签格式txt、类别ID到底怎么对应YOLOv11 的标签格式和 YOLOv5/v8 完全一致一个图片对应一个同名.txt文件文件里每一行代表一个目标框。标准的写法是class_id center_x center_y width height这里center_x、center_y、width、height都是归一化到 0~1 的值而不是像素坐标。如果你想直接用这份数据集训练第一步就要确认目录结构是不是符合 Ultralytics 引擎的默认约定。一般来说下载下来的数据包会是这样phone_play_dataset/ ├── images/ │ ├── train/ │ │ ├── img_0001.jpg │ │ └── ... │ └── val/ │ ├── img_1001.jpg │ └── ... ├── labels/ │ ├── train/ │ │ ├── img_0001.txt │ │ └── ... │ └── val/ │ ├── img_1001.txt │ └── ... └── data.yamldata.yaml里最重要的就是nc和names。对于这个项目通常会用三个类别我建议在训练前先明确类别 ID名称行为定义0hold_phone_call手持打电话手机贴在耳边或保持在耳旁1handsfree_phone_call非接触式打电话手机支撑在固定位置人体未手持2phone_play_selfie玩手机/自拍手机拿在手里操作或举高自拍这套定义相对清晰但真正用的时候会发现一个麻烦类别 0 和类别 2 在物理形态上都是“手里有手机”如果你把标注框打在手机上模型根本分不出“打电话”和“玩手机”。所以这类行为识别数据集最常见、也最容易训练成功的做法是把标注框打在“人”身上用人的动作和手机姿态联合语义来区分类别。也就是说标签里center_x这类坐标对应的往往是人的包围框而不是手机的包围框。我一般拿到数据集之后不会急着建data.yaml而是先做一个简单的标签可视化把标注框和类别名直接画回图片上。肉眼判断匹配工作区背景中的真实场景避免后续训练的时间被浪费。2.2 用一段脚本检查标注是否可用避免白练一场标签文件本身是纯文本格式错了不会报错只会在训练时莫名丢失目标。我见过不少现象训练完 val 的 mAP 有数字但推理结果却和原始图片对不上。这种大多是标签坐标写错、类别 ID 越界或者存在空文件。每次拿到数据我都会先跑一个校验脚本。下面的代码可以检查出大部分常见问题import os from pathlib import Path def yolo_label_validate(labels_dir, images_dir): 遍历 YOLO 格式标签文件, 检查格式、类别 ID 和坐标范围。 labels_dir: 标签目录 images_dir: 对应图片目录 label_files sorted(Path(labels_dir).glob(*.txt)) class_names [ hold_phone_call, handsfree_phone_call, phone_play_selfie, ] empty_files [] bad_lines [] for txt_path in label_files: # 标签文件命名为 tmp.jpg - tmp.txt img_path Path(images_dir) / (txt_path.stem .jpg) if not img_path.exists(): bad_lines.append(f{txt_path}: 对应图片不存在 {img_path.name}) lines txt_path.read_text(encodingutf-8).strip().splitlines() if not lines: empty_files.append(str(txt_path)) continue for line_no, line in enumerate(lines, 1): parts line.split() if len(parts) ! 5: bad_lines.append(f{txt_path}:{line_no} 列数不是 5) continue cls_id int(parts[0]) if cls_id 0 or cls_id len(class_names): bad_lines.append(f{txt_path}:{line_no} 类别越界: {cls_id}) continue cx, cy, bw, bh map(float, parts[1:]) if bw 0 or bh 0: bad_lines.append(f{txt_path}:{line_no} 宽高非法: {bw} {bh}) # 归一化后的中心点越界说明坐标没有换算干净 if not (0.0 cx 1.0 and 0.0 cy 1.0): bad_lines.append(f{txt_path}:{line_no} 中心点越界: {cx} {cy}) print(f标签文件总数: {len(label_files)}) print(f空标签文件: {len(empty_files)}) print(f可疑行数: {len(bad_lines)}) if empty_files: print(空标签文件示例:) for f in empty_files[:10]: print( , f) if bad_lines: print(可疑行示例:) for b in bad_lines[:20]: print( , b) if __name__ __main__: validate_yolo_labels(phone_play_dataset/labels/val, phone_play_dataset/images/val)这段脚本的逻辑很简单却有效。第一校验每个 txt 是否都对应一张图片避免训练时因为图片没读进来导致某个类别的样本量失真。第二检查列数YOLO 格式如果写成class_id x1 y1 x2 y2坐标是像素值在官方训练器里会被当成归一化坐标直接算很多时候不会报错但模型就废了。第三检查归一化坐标是否落在 0~1 区间像中心点出现负数或大于 1基本都是转换脚本没写好。脚本执行后如果空文件比你预想的多别急着删除。空标签意味着这张图片没有目标通常来自背景帧或难样本。在训练集里保留一部分空文件能让模型学会“没有目标时不乱框”减少误检。2.3 数据分布和类别策略手持、非接触、玩手机怎么划分这个数据包叫“超高识别率”但识别率的前提是数据分布接近你的真实场景。三类目标里非接触式打电话是最容易翻车的类别。因为“非接触”意味着手机不在人手里那么人形姿态可能完全正常只有桌面上某个小物品是手机。如果标注框打在人身上模型相当于要去记忆“这个人正在打电话”的上下文这类样本必须足够多。玩手机和自拍看上去容易但实际很难和手持打电话区分。以我见过的标注标准两者互斥的原则通常是手机在耳边附近且人处于通话姿势归为手持打电话手机在视线下方、胸前或举过头顶进行滑动、浏览、拍摄归为玩手机自拍。如果你的现场需求里还有“吸烟”“揉眼睛”等动作混淆的概率会更高。当你发现数据分布偏得厉害时我的做法是先画一张类别样本数量图用条形图统计每个类别在不同角度、不同光照下的数量。如果一个类别的样本只有另一个类别的五分之一哪怕整体识别率虚高部署时这个类别的召回也会很差。实在没有更多数据就先合并类别把手持打电话和玩手机自拍合为“使用手机”等数据充足后再拆分边界线会清晰很多。3. 跑通 YOLOv11 训练从 data.yaml 到一条命令出权重3.1 Ultralytics 环境配置版本和依赖的边界YOLOv11 在 Ultralytics 框架里跑起来非常省事但环境上一个常见的坑就是版本冲突。官方仓库更新很快如果你的环境里装了旧版torch或opencv-python训练时可能直接编译失败也可能在推理时莫名其妙地报CUDA内存错误。一般我会按下面的流程配置一个干净环境python -m venv yolo11_env source yolo11_env/bin/activate pip install --upgrade pip pip install ultralytics yolo version这里yolo version是为了确认安装成功也方便后面定位问题。如果你的机器是 Windows把source yolo11_env/bin/activate换成yolo11_env\Scripts\activate即可。GPU 环境里的 PyTorch 建议单独装尤其是 CUDA 版本不一致的时候直接用pip install ultralytics拉到的 PyTorch 可能不是本地驱动对应的版本。我的经验是先把torch、torchvision按官网命令装好再装ultralytics能省掉很多“训练前 10 分钟才发现显卡不可用”的无用操作。3.2 训练参数怎么定imgsz、epochs、batch 的选择逻辑拿到一份外来的数据包我的第一个习惯不是直接开训而是先在data.yaml里把路径写对。路径里的相对路径是相对于data.yaml所在目录还是相对于工作目录很多人会搞混。为了避免这种问题建议直接用绝对路径或者把整个数据包放到工程目录下用相对路径./phone_play_dataset# phone_play_dataset/data.yaml path: ./phone_play_dataset train: images/train val: images/val test: images/test nc: 3 names: 0: hold_phone_call 1: handsfree_phone_call 2: phone_play_selfie然后就可以开训了。我的起步命令长这样yolo detect train \ dataphone_play_dataset/data.yaml \ modelyolo11s.pt \ imgsz640 \ epochs200 \ batch16 \ patience50 \ device0参数并不需要全部调整但有几个关键点需要理解特别是对新手参数说明我的建议model预训练模型文件先yolo11n.pt试跑通稳定后换成yolo11s.pt或yolo11m.ptimgsz输入图片尺寸场景里人的像素高度小于 50 时建议 1280否则 640 就够epochs训练轮数数据集几千张时200 轮左右能收敛数据量小则配合早停batch每批图片数显存不够就减半能接受训练时间变长patience早停耐心轮数验证集指标连续多少轮不涨就停我一般设 50device训练设备0代表第一张 GPU纯 CPU 环境填cpuimgsz的选择对行为识别影响很大。你的现场摄像头如果是 300 万像素的高空视角一个人可能只有 30 像素高这时候你用 640 训练下采样后人的细节基本全没了。我更倾向于把imgsz调到 1280第一次训练可以先跑 50 轮看速度确认单卡能接受再跑完整训练。另一个被忽略的点是batchbatch 太小BN 层的统计量不稳定模型在小数据集上会来回震荡batch 太大显存不够时会自动降级为梯度累积速度反而变慢。所以不要盲目往上加。3.3 训练后第一时间看什么指标训练结束不是看最后的loss有多低就行。YOLOv11 在训练过程中会在runs/detect/train/下生成results.csv和一堆图我最关注的是混淆矩阵和每个类别的 PR 曲线。对于这个数据包手持打电话类别的 AP 通常最高玩手机自拍次之非接触式打电话最低。如果你发现非接触式的 AP 低于 0.5别急着调模型先去看这个类别的标注框是否把手机支架上的手机也框进去了。如果标签框位置主要落在身体上而测试数据中的“非接触式打电话”人形和训练集中差异很大AP 自然上不去。验证阶段还需要单独跑一波不要只看训练时内嵌的 val 结果yolo detect val \ modelruns/detect/train/weights/best.pt \ dataphone_play_dataset/data.yaml \ imgsz640跑完后查看confusion_matrix.png。如果“非接触式打电话”大量被预测成“玩手机自拍”说明两个类别的姿态样本区分度不够。这时候不是改网络而是要回到数据本身增加两个类别在同一机位下的独立样本并且要保证标注标准严格互斥。很多情况下同一个动作被两个标注员标成了不同类别这种“标注语义漂移”在行为检测里比模型结构问题更隐蔽。4. 推理脚本把模型变成“打电话/玩手机”事件输出4.1 基础检测推理训练完成之后最好的验证方式是直接跑一段视频流而不是只对几张图片看效果。YOLOv11 的 Python API 接口很简洁下面的代码是把训练好的权重跑在一段测试视频上from ultralytics import YOLO model YOLO(runs/detect/train/weights/best.pt) results model.predict( sourcetest_video.mp4, imgsz640, conf0.35, iou0.5, device0, saveTrue, save_txtTrue, )代码里conf0.35是核心参数。它对三类目标的影响不同手持打电话的检测置信度往往在 0.5 以上非接触式打电话因为姿态不明显很多真实框只能跑到 0.25~0.4 的置信度。如果你为了保召回把conf调到 0.2那么误检的杯子、显示器、反光贴纸也会跟着出来。我的建议是先分别在conf0.2、0.3、0.4下跑同一段视频观看预测结果再选择一个对现场需求最友好的阈值。4.2 后处理按类别统计违规事件在大多数管理场景里用户不只是要“看到框”而是想要“谁在违规”。所以推理脚本需要把连续帧里的检测结果转换成一次事件。最简单的方法是在帧计数上做统计目标连续出现 N 帧才算一个有效事件。import cv2 from ultralytics import YOLO from collections import defaultdict model YOLO(runs/detect/train/weights/best.pt) cap cv2.VideoCapture(camera_02.mp4) fps max(int(cap.get(cv2.CAP_PROP_FPS)), 1) # 只统计目标出现过的帧数 counters defaultdict(int) # 已经触发的事件避免同一人重复计数 event_flags defaultdict(bool) while True: ret, frame cap.read() if not ret: break results model(frame, conf0.35, iou0.5, verboseFalse)[0] current_frame_events set() for box in results.boxes: cls_id int(box.cls) class_name model.names[cls_id] current_frame_events.add(class_name) for cls_name in current_frame_events: counters[cls_name] 1 # 连续出现超过 0.5 秒认为一次真实事件 for cls_name, count in list(counters.items()): if count int(fps * 0.5) and not event_flags[cls_name]: print(f{cls_name} 事件触发持续帧数 {count}) event_flags[cls_name] True elif count 0: event_flags[cls_name] False cap.release()这段逻辑的价值在于过滤单帧误检。拿一个水杯的误检来说它可能在某两帧里置信度很高但不会连续出现半秒钟。通过时间维度的过滤能把大量单帧噪声消掉。需要留意的是counters这个字典没有区分画面里的多个人。如果现场会有多个人同时出现在视野里你需要先做目标跟踪或按框的中心点位置分配 ID否则统计会混在一起。基础版先用classes名称做事件判断对单人场景完全够用。4.3 延时与性能非接触式打电话的难点行为检测的实时性很多人会踩到同一个坑用 1080p 视频流喂给 YOLOv11 做全图推理GPU 负载很高延迟也比较大。事实上监控场景里人的尺寸通常只占画面的很小一部分更推荐的做法是通过一个轻量级的行人检测器先圈出人的区域再把每个区域裁剪后送给 YOLOv11 做行为分类。这样做有两个好处第一输入图片变小推理速度显著提升第二行为识别模型看到的是“放大的完整人像”而不是远处的一个小目标。非接触式打电话在这种流程里仍然是最难的。因为如果手机没在手上裁剪出来的人像里手机占比很小模型可能要依赖“手机放在桌面上 人头部微侧”这种弱特征这类特征很容易被姿势变化干扰。实际部署时最好给非接触式打电话保留一个独立的摄像头角度比如正对办公桌或驾驶室仪表盘方向的机位会比一个斜上方全局视角可靠得多。5. 避坑和排查模型为什么总把水杯当手机5.1 现象训练完误检多水杯、耳机、键盘都被框成玩手机现象跑测试视频时桌面的保温杯、耳机盒、甚至键盘反光区域都被标成了phone_play_selfie置信度还在 0.4 左右。原因训练集中缺乏负样本也就是“画面里没有打电话/玩手机行为”的帧。模型被动学习了大量“手在桌面上拿着东西”的背景特征把类似的小型物体都激活了。解决从现场监控视频里抽几段空白场景截取几百张没有人或人没有使用手机的帧放到训练集的images/train里并保留为空的.txt标签文件。这样让模型接触更多真实负样本误检会明显下降。同时可以把推理conf从 0.2 提到 0.35过滤掉低置信度噪声。5.2 现象夜间红外场景下手机和手部轮廓全部糊在一起现象白天测试 mAP 能到 0.8晚上切到红外摄像头后召回率下降到 0.3手持打电话根本框不出来。原因训练数据大概率是白天自然光图片红外图像丢失了颜色信息且手部和手机的温度差异在画面上表现成灰色纹理接近的区域。YOLO 系列模型默认的 HSV 增强只针对颜色空间的小变换对红外这种全图灰度化场景效果有限。解决在训练时增加灰度化增强把hsv_v提到 0.5或者直接对训练集做灰度预处理生成一部分单通道复制件。更有效的是采集现场红外样本做半天的增量训练。可以用少量红外图片加上原来数据联合训练注意红外图要先用标注脚本转成同样的 YOLO 格式不要漏掉标注框。5.3 现象类别不平衡模型总把玩手机识别成手持打电话现象验证集显示hold_phone_call的 AP 很高但实际画面里一个人在低头刷手机模型却给了“hold_phone_call”的框。原因手持打电话和玩手机自拍在姿态上本来就是连续过渡的如果数据集中手持打电话样本多模型会把所有“手举着手机”的相似特征都归到这个多数类里。另外很多标注在“手机接触脸颊”和“手机举在胸前”之间的边界不一致。解决先做一次标签统一明确拿手机到耳边才算手持打电话否则一律归玩手机。如果已经统一过仍然失衡就在训练时给玩手机类别的图片在upsample层面简单复制两倍而不是改变损失函数权重。因为改动 YOLOv11 的 loss 权重需要动框架源码对工程上线不划算不如直接调整数据比例。5.4 现象换一个摄像头角度精度立刻崩掉现象A 摄像头俯视角训练出来的模型换到 B 摄像头平视视角检测结果几乎全漏。原因这是过拟合到了训练集特定的拍摄角度和人物尺度。特别是行为识别任务同一个“非接触式打电话”在俯视视角和水平视角下的视觉特征完全不同模型没有学到通用的“打电话”概念。解决随机增强参数里打开翻转、旋转和透视变化。Ultralytics 默认的degrees0.0也就是不做旋转。建议设置degrees10translate0.2scale0.5fliplr0.5。另外在验证集里必须隔离开不同摄像头的数据不能把同一个摄像头的帧同时放进训练集和验证集否则看到的指标全是假的。5.5 现象训练时 loss 还在下降但 mAP 到了某个点就不再涨现象训练到 120 轮时 loss 还在持续下降但验证集 mAP 一直停在 0.73 左右无论加多少轮都上不去。原因模型对小样本类别的特征表达已经饱和。YOLOv11n 的容量有限在非接触式打电话这类弱特征类别上尤其明显。也可能是imgsz640且检测框很小网络下采样后目标特征丢失。解决先换更大的预训练模型比如yolo11m.pt同时把输入尺寸提升到imgsz1280。如果显存不够则改用迁移学习只冻结骨干层前几个 stage释放后面的学习率。另一个隐藏原因是验证集里标注框本身存在错误低质量的标签会把 mAP 压在一个虚高水平。建议抽 200 个验证样本重新核对一遍把明显错标的数据剔除。6. 更近一步用强增强和置信度融合提高现场泛化能力6.1 增强参数调整不要用默认值直接跑默认训练参数在公开数据集上表现不错但换到行为识别现场场景还是偏保守。我比较常用的做法是在命令里显式增加增强项yolo detect train \ dataphone_play_dataset/data.yaml \ modelyolo11s.pt \ imgsz1280 \ epochs150 \ batch8 \ degrees10 \ translate0.2 \ scale0.5 \ fliplr0.5 \ hsv_v0.5其中hsv_v0.5是为了模拟不同亮度和红外灰度场景处理后的图在灰度层面变化更大对夜间监控更友好。degrees10虽然会增加训练难度但能明显提升不同安装角度下的稳定性。6.2 对检测结果按时间段做事件判定单独一帧的置信度不如连续帧的“多数投票”可靠。我在最终交付时习惯用一个长度为 15 帧的滑动窗口窗口内超过 10 帧出现同一个类别才输出一次事件。这样既不会漏掉短暂抬头看手机的瞬间也能过滤掉喝水、玩笔等误检。实现方式简单用collections.deque(maxlen15)可以轻松完成。6.3 ONNX 导出与现场验证训练结束后把权重导出为 ONNX 格式方便接入现有的 C/Java 推理服务yolo export modelruns/detect/train/weights/best.pt formatonnx dynamicTrue imgsz640导出后需要重新验证一次因为 ONNX 的预处理和后处理和 PyTorch 原生推理存在细微差异。从那以后我每次换场景都会固定走一遍“数据校验 → 短训练 → 全量训练 → 多阈值推理 → ONNX 复验”的流程不再依赖训练日志里那个 mAP 数字。希望你拿到这份资源后也能在你的现场场景里少走这些弯路希望帮到你。本文还有配套的精品资源点击获取