简介：本资源是一套基于YOLOv5与Dlib的人物专注性检测系统完整实现，面向计算机视觉初学者、智能监考/驾驶辅助项目开发者及行为分析研究者，解决课堂、考场、车载等场景下人员疲劳与分心行为的实时识别问题。压缩包共63个文件，含20个核心Python源码（如main.py、myfatigue.py、mydetect.py）、18个YOLOv5模型配置yaml文件（覆盖s/m/l/x多尺度）、17个编译缓存pyc文件、1个UI界面文件（mainwindow.ui）及1个关键人脸特征点dat模型，辅以演示视频MP4、GIF动图和README说明文档，整体体积109.54MB。已有1356人学习下载。用户可直接运行main.py启动图形化界面，系统集成双模块：Dlib驱动的疲劳检测（基于PERCLOS、EAR、MAR指标）与YOLOv5训练的分心行为检测（玩手机、抽烟、喝水三类），配套weights/best.pt模型与PySide2可视化框架，具备即装即用特性，适合快速部署验证与二次开发。 前阵子接了个挺有意思的需求，要做一套基于YOLOV5的人物专注性检测系统，核心是两块：疲劳检测和分心行为检测。说白了就是让电脑自己盯着画面里的人，判断这个人是在认真干活还是已经困了、走神了、正在摸鱼。这套东西早期的典型落地场景是驾驶场景的DMS（驾驶员监控系统），后来扩展到在线教育、远程办公、宿舍自习室管理这些方向。我基于YOLOV5把整套源码跑通并做了二次开发，今天把这套系统的设计思路、实现细节和踩坑记录整理出来，给正在做类似方向的朋友一个参考。
先说结论：YOLOV5在这类任务上依然是性价比很高的选择。不需要上多复杂的模型，配合人脸关键点、眼部纵横比、嘴部纵横比和头部姿态估计，就能搭出一套实时性不错的专注度分析系统。整套系统的核心不是模型本身，而是如何把检测结果转换成“专注/疲劳/分心”这些可量化的业务指标。代码我都在本地调试过，训练和推理流程可以完整复现，下面直接进入正题。
1. 项目整体设计与方案选型
1.1 专注性检测到底在检测什么
很多刚接触这个方向的人会把专注性检测理解成“检测人是否在看摄像头”，其实这是个常见的误区。真正的专注性检测是一个多维度融合判断的问题，至少包含以下三个层面的信息：
第一层是存在性检测，也就是画面中有没有人、人在哪里、有多少人。这层用目标检测就能解决，YOLOV5的person类可以直接完成。
第二层是细粒度状态检测，包括人脸关键点、眼睛开合程度、嘴巴开合程度、头部姿态角度。这层是专注度判断的核心依据，需要用到人脸关键点模型或姿态估计模型。
第三层是行为语义判断，也就是把上面检测到的原始数据组合成有意义的行为标签。比如“眼睛闭合时间过长”组合成“疲劳”，“频繁转头+视线偏离”组合成“分心”，“低头看手机”组合成“使用手机”。
所以整套系统的本质是：用目标检测定位人，用关键点检测提取状态，用行为逻辑规则输出结论。三部分缺一不可。
1.2 为什么选YOLOV5而不是其他方案
选型的时候我比较过几套方案，包括OpenCV传统方法、MediaPipe、YOLOv5和YOLOv8，最终定在YOLOv5上。原因有三个：
一是生态成熟。YOLOv5的权重文件、标注工具、部署教程都是最全的，遇到问题基本能搜到解决方案。相比YOLOv8，v5的社区积累更久，很多边缘设备的适配案例都是基于v5做的。
二是速度和精度的平衡点很舒服。YOLOv5s的模型大小只有14MB左右，在GTX 1660上跑实时推理完全没有压力，配合TensorRT或者OpenVINO还能进一步加速。对于专注性检测这种需要长时间运行在教室、机房、驾驶室等场景的系统，实时性比极限精度更重要。
三是方便做二次开发。v5的代码结构清晰，检测头和关键点分支可以灵活改造。我后面把人脸检测和关键点检测都整合进了同一个推理管线，v5的架构让我改动起来很顺手。
如果单纯做人脸关键点，MediaPipe确实开箱即用，但它的检测框不稳定，在多人和遮挡场景下容易丢目标。YOLOV5配合自有数据训练后，对特定场景的鲁棒性明显更强。
2. 核心模块设计与实现原理
2.1 疲劳检测的判定逻辑
疲劳检测在这套系统里主要通过两个生理指标实现：眼睛闭合程度和嘴部打哈欠程度。这里要引入一个核心概念——眼部纵横比（EAR，Eye Aspect Ratio）。
EAR的计算公式是：EAR = (||P2-P6|| + ||P3-P5||) / (2 * ||P1-P4||)，其中P1到P6是人脸68关键点中眼部区域的6个点。简单来说，这个比值衡量的是眼睛的“竖向开口程度”相对于“横向距离”的比例。正常睁眼时EAR大约在0.25到0.35之间，闭眼时EAR会骤降到0.1以下。
嘴部纵横比（MAR）同理，通过嘴部关键点计算嘴巴张开程度，MAR超过一定阈值且持续超过1.5秒，就判定为打哈欠。哈欠是疲劳的强信号，比单纯闭眼更容易捕捉。
疲劳判定不能只看单帧，必须引入时间窗口概念。这里的经验公式是：统计连续30帧内EAR低于阈值的帧数占比，如果占比超过40%就触发疲劳预警。这种基于PERCLOW思想的判定方式比单帧阈值判断可靠得多，能有效过滤眨眼带来的误报。PERCLOS的完整形式是计算眼睛闭合时间占特定时间窗口的百分比，业界公认的疲劳阈值是P80，即闭眼时间超过窗口的80%判定为疲劳。
眼部关键点坐标的提取我用了两种方案并存：一种是接入dlib的68点模型，稳定性高但速度一般；另一种是训练了一个轻量级的人脸关键点模型，推理速度更快。实际项目里建议用第二种，因为dlib的模型在侧脸和大角度遮挡时经常丢失关键点。
2.2 分心行为检测的判定逻辑
分心行为比疲劳更难定义，因为“分心”本身是一个模糊概念。我在系统里把分心分解成了几个可量化的子行为：
头部姿态偏转是第一个指标。通过人脸关键点计算头部的偏航角（Yaw）、俯仰角（Pitch）和滚动角（Roll），偏航角绝对值超过35度或俯仰角绝对值超过20度且持续2秒以上，判定为分心。计算方式是用solvePnP求解2D-3D对应关系，3D人脸模型用的是通用的标准模型坐标。
视线方向偏离是第二个指标。严格来说这需要瞳孔中心定位和眼球建模，比较复杂。我的简化做法是利用两只眼睛的关键点计算眼球中心位置，结合头部姿态估算大致视线方向。这个方法精度有限，但判断“低头看手机”和“左右张望”这类大幅度视线偏移是够用的。
交互行为检测是第三个指标。比如检测手部区域和手机目标，如果手部区域与手机目标在画面中重叠且持续一段时间，判定为“使用手机”。这需要额外训练一个手机类别和一个手部类别，我在YOLOV5原有的coco类别基础上手动标注并微调了这两个类别。
还有一个加分项是身体姿态检测。如果画面中的人趴在桌上，躯干关键点的置信度会显著降低，这个信息可以辅助判断“趴睡”状态，对教室和自习室场景特别有用。
2.3 专注度评分是怎么算出来的
上面这些检测结果最终要汇总成一个直观的分数，否则直接输出一堆EAR、Yaw角度数值，业务方根本没法用。我设计了一套简单的加权评分机制：
专注度分数初始为100分，检测到闭眼/哈欠事件每分钟最多扣15分，检测到头部偏转事件每分钟最多扣20分，检测到使用手机事件每分钟扣30分。扣分不是瞬时的，而是采用衰减窗口：事件消失后每10秒恢复1分。
这个评分机制非常实用主义，它不追求医学级的准确率，而是通过连续扣分和缓慢恢复来反映一段时间的整体专注状态。实践中，这种机制比逐帧判定“专注/不专注”更符合用户对系统的预期。
3. 实操部署：环境配置与模型训练
3.1 YOLOV5环境搭建的完整步骤
这套系统的环境搭建我踩过不少坑，尤其是一些版本兼容性问题，这里直接给出我验证过可行的组合。
操作系统建议Ubuntu 20.04或Windows 10/11，Python版本必须用3.8到3.10，不建议用3.11以上版本，部分依赖还没有完全适配。PyTorch版本建议1.12.1或2.0.1，CUDA版本对应10.2或11.7。
克隆YOLOV5代码库后，安装依赖的顺序很重要。如果直接用yolo官方提供的requirements.txt安装，很容易装出版本冲突。正确做法是先安装PyTorch，再安装requirements.txt里的其他依赖。
git clone https://github.com/ultralytics/yolov5 cd yolov5 pip install torch==1.12.1+cu113 torchvision==0.13.1+cu113 --extra-index-url https://download.pytorch.org/whl/cu113 pip install -r requirements.txt装完之后建议先跑一次官方推理验证环境：
python detect.py --weights yolov5s.pt --source data/images/bus.jpg如果能正常输出检测结果，说明环境没有问题。我遇到过一种情况是检测结果全空白，排查下来发现是OpenCV版本和PyTorch的图像读取格式冲突，重新安装opencv-python-headless后解决。
3.2 数据集准备与标注技巧
疲劳检测和分心检测都属于特定场景任务，用公开数据集预训练的YOLOV5权重不能直接满足要求，必须用标注数据微调。
我使用的公开数据集包括YawDD驾驶员疲劳数据集，包含约30000帧的闭眼和打哈欠标注；CEW闭眼数据集，包含约4000张闭眼人脸图片；以及自己采集补充的教室场景数据约5000张，标注类别包括：eye_open（睁眼）、eye_closed（闭眼）、mouth_open（张嘴）、mouth_closed（闭嘴）、phone（手机）、hand_raise（举手）等。
很多人标注数据时会忽略一个要点：不同场景下的同一行为，外观差异可能非常大。比如闭眼，在光线充足的驾驶舱和光线昏暗的教室，眼睛区域的特征是完全不同的。所以训练数据一定要覆盖目标场景的光照、角度和距离分布。我第一版模型在实验室测试效果不错，到实际教室环境就出现了大量漏检，就是因为训练集和实际场景差异太大。
标注工具推荐LabelImg或者X-AnyLabeling，后者支持半自动标注，用YOLOV5-pytorch模型做预标注，人工只做修正，效率能提升3到4倍。
标注完成后把数据组织成YOLOV5要求的格式：images文件夹存放图片，labels文件夹存放对应的txt标注文件，每行格式为“类别ID x_center y_center width height”，坐标是归一化后的值。
3.3 超参数调整与训练命令
训练命令我放到一个脚本里，方便重复执行：
python train.py --data dataset.yaml --weights yolov5s.pt --epochs 150 --batch-size 16 --img 640 --device 0 --patience 20dataset.yaml的格式大概是这样的：
train: ./dataset/images/train val: ./dataset/images/val nc: 6 names: ['eye_open', 'eye_closed', 'mouth_open', 'mouth_closed', 'phone', 'hand_raise']训练过程要重点关注两个指标：一是验证集上的mAP@0.5，二是训练集和验证集的loss曲线是否同步下降。如果训练集loss降低但验证集loss回升，说明模型过拟合了，典型的解决方法是增加数据增强、增大数据集或加上early stopping。
这里有个实操要点：YOLOV5默认的数据增强已经比较强力，但对于眼睛这种小目标，过强的mosaic增强反而会引入大量无效信息。我训练时把mosaic参数从1.0调到了0.5，同时将hsv_h、hsv_s、hsv_v等颜色增强参数略微降低，让模型更专注于目标本身的纹理特征，最终mAP提高了约两个百分点。
超参数调整方面，我用的YOLOV5官方自带的hyp.scratch-low.yaml作为基线，只调整了三个最影响收敛的参数：lr0从0.01降到0.005，避免小数据集上发散；warmup_epochs从3.0调到5.0，让模型在前期更稳定；weight_decay保持0.0005不变，这是一个通用且稳定的值。
训练完成后，验证集mAP@0.5如果能达到0.92以上，基本可以用于实际场景。如果低于0.85，建议先检查数据集，而不是急着调参。
4. 代码实现与关键节点源码解析
4.1 实时检测推理的构建思路
整套系统的推理管线用多线程实现，避免检测、分析和UI渲染互相阻塞。
主线程负责视频流读取和帧预处理，检测线程负责YOLOV5的推理，分析线程负责关键点提取和疲劳/分心逻辑判断。三个线程之间用Python的queue.Queue传递数据。这里要注意队列长度的限制，不限制的话帧累积会导致延迟持续变大，我设置队列最大长度为2，满则丢弃旧帧，保证实时性优先。
YOLOV5推理部分可以直接使用官方提供的detect.py，但为了嵌入到自己的系统里，我建议调用YOLOV5的API模式，也就是用torch.hub或直接导入模型：
import torch model = torch.hub.load('./yolov5', 'custom', path='best.pt', source='local', force_reload=True) model.conf = 0.45 model.iou = 0.5 model.max_det = 10 results = model(frame) boxes = results.xyxy[0].cpu().numpy()这里的conf阈值要根据场景调整。教室场景里因为摄像头离人远，目标较小，置信度普遍偏低，阈值设成0.35更合适；驾驶场景离人近，可以设高一些到0.5，减少误检。
4.2 疲劳检测核心算法代码
EAR计算的代码实现很直接，但有不少细节需要注意：
def eye_aspect_ratio(eye_points): # eye_points是6个关键点的坐标列表 p2_p6 = np.linalg.norm(eye_points[1] - eye_points[5]) p3_p5 = np.linalg.norm(eye_points[2] - eye_points[4]) p1_p4 = np.linalg.norm(eye_points[0] - eye_points[3]) ear = (p2_p6 + p3_p5) / (2.0 * p1_p4 + 1e-6) return ear代码最后加一个1e-6的极小值，是为了防止p1_p4为0时产生除零错误。这在极端检测失败场景下会发生，不加的话整个进程会直接崩掉。
疲劳判断的逻辑我用了一个滑动窗口：
class FatigueDetector: def __init__(self, ear_thresh=0.2, frames_thresh=12, mar_thresh=0.5): self.ear_thresh = ear_thresh self.frames_thresh = frames_thresh self.mar_thresh = mar_thresh self.closed_frames = 0 self.yawn_frames = 0 self.fatigue_flag = False def update(self, ear, mar): if ear < self.ear_thresh: self.closed_frames += 1 else: self.closed_frames = 0 if mar > self.mar_thresh: self.yawn_frames += 1 else: self.yawn_frames = 0 if self.closed_frames >= self.frames_thresh or self.yawn_frames >= 45: self.fatigue_flag = True else: self.fatigue_flag = False return self.fatigue_flag这里有几个参数值得细说：ear_thresh取0.2是经验值，不同人种、不同脸型会有差异，严格来说应该对每个目标做自适应校准。frames_thresh取12意味着在30FPS的帧率下，眼睛需要连续闭合0.4秒才触发一次闭眼事件，这个时长刚好能过滤正常眨眼（眨眼通常0.1到0.2秒），又不至于漏掉真正的闭眼。mar_thresh取0.5且连续45帧（1.5秒）才判定哈欠，同样是为了过滤说话导致的嘴部开合。
4.3 分心行为检测的代码实现
头部姿态估计我用的是OpenCV的solvePnP：
def head_pose_estimation(face_landmarks, img_size): # 3D人脸标准模型坐标 model_points = np.array([ (0.0, 0.0, 0.0), # 鼻尖 (0.0, -330.0, -65.0), # 下巴 (-225.0, 170.0, -135.0), # 左眼角 (225.0, 170.0, -135.0), # 右眼角 (-150.0, -150.0, -125.0), # 左嘴角 (150.0, -150.0, -125.0) # 右嘴角 ], dtype=np.float64) # 对应的2D关键点 img_points = np.array([ face_landmarks[30], face_landmarks[8], face_landmarks[36], face_landmarks[45], face_landmarks[48], face_landmarks[54] ], dtype=np.float64) camera_matrix = np.array([ [img_size[1], 0, img_size[1]/2], [0, img_size[1], img_size[0]/2], [0, 0, 1] ], dtype=np.float64) dist_coeffs = np.zeros((4, 1)) success, rotation_vector, translation_vector = cv2.solvePnP( model_points, img_points, camera_matrix, dist_coeffs) rmat, _ = cv2.Rodrigues(rotation_vector) angles = cv2.RQDecomp3x3(rmat)[0] return angles # 返回pitch, yaw, roll这段代码的关键在于camera_matrix的估计。由于没有实际的相机标定参数，我用了简化假设：焦距约等于图像宽度，主点位于图像中心。这个假设在摄像头没有明显畸变时误差不大，但如果你用的是广角摄像头，建议先用棋盘格标定获取真实的相机参数，否则角度计算会有好几度的误差。
分心行为的判定逻辑和疲劳检测类似，也是基于连续帧计数。头部偏航角超过35度且持续30帧，判定为一次分心事件。这里有一个容易忽略的问题：检测目标从画面中消失时，上一帧的姿态数据需要立即清零并暂停分心计数。我一开始没有处理这种情况，结果一个人转头出画面，系统反而把分心状态保持了很久，造成大量误报。
5. 常见问题排查与性能优化
5.1 训练不收敛或收敛效果差
这个现象在小数据集上最常见。排除数据标注错误以外，最值得检查的三个方向是：学习率是否过大、数据分布是否均衡、预训练权重是否使用正确。
我遇到过一次训练loss降不下去的情况，排查到最后发现是预训练权重文件损坏了，模型加载了随机初始化的权重从头训练。6000张图片对一个检测模型来说显然不够，自然不收敛。重新下载权重文件后，训练曲线就正常了。
另一个典型问题是类别不平衡。我第一版数据里eye_open的标注量是eye_closed的三倍，结果模型对闭眼的召回率极低。解决方法是配合类别权重给少数类别增加复制增强，或者直接调整损失函数中的类别权重参数，让模型对少数类别更敏感。
5.2 实时性不够，FPS过低
YOLOV5s在CPU上推理一般只能跑到5到8FPS，达不到实时要求。要提升实时性，优先考虑这三条路：
第一条是简化输入尺寸，把推理分辨率从640降低到480或者416。这会降低一点精度，但推理速度能提升50%左右。专注性检测对目标位置精度要求不高（我们只关心区域而不需要精确到像素），所以这个取舍是划算的。
第二条是开启半精度推理。在较新的GPU上把模型转为FP16格式，速度几乎翻倍，对精度的影响在可接受范围内。
第三条也是性能提升最大的，导出TensorRT引擎。在NVIDIA设备上，TensorRT能把YOLOV5s的推理时间从20ms压到7ms左右。导出过程虽然有点繁琐，但一劳永逸。
python export.py --weights best.pt --include engine --device 0 --half5.3 检测框抖动导致指标不稳定
这是最影响体验的问题。检测框的轻微抖动会导致关键点坐标跟着抖动，进而让EAR和头部姿态角度出现高频噪声。我最后的解决方案是引入卡尔曼滤波对关键点坐标做平滑处理，同时把检测框做了IOU追踪关联，保证同一个人的ID在连续帧中保持一致。
另一个更简单的方案是对EAR和角度数据做指数移动平均（EMA），平滑系数设为0.6到0.7。这个方案实现成本低，效果也不错，适合对精度要求不高的场景。
5.4 单人画面效果良好，多人画面逻辑混乱
我一开始的实现是针对单人场景，后来扩展到多人场景时发现逻辑异常复杂。核心难点是人脸的ID关联，如果两个人交叉走过，ID交换会导致疲劳状态被错误转移到另一个人身上。
多人跟踪我采用的是YOLOV5检测框加DeepSORT追踪，用人体ReID特征做关联，可以在一定程度上缓解ID Switch问题。但如果追求极致效果，建议还是限制画面中的人数为4到6人，超过这个数量时，优先检测距离摄像头最近的目标。
5.5 实测中容易被忽略的细节
摄像头角度对检测效果的影响远超模型选择。尽量把摄像头放在正对位置，俯视角度不要超过30度。俯角过大时，眼睛和嘴部的关键点会被压缩，EAR和MAR的计算会失真。
光照也是个大变量。逆光和低照度环境下，关键点检测的误差会显著增加。实际部署时建议优先选择带宽动态功能的摄像头，或者在软件里做一次自适应直方图均衡化做预处理。
还有一个细节是眼镜问题。戴眼镜的人眼睛经常被反光干扰，关键点偶尔会跳到镜框上。我的处理是用历史帧的EAR做中值滤波，把这种偶发波动滤掉。
6. 总结与经验分享
这套基于YOLOV5的专注性检测系统，从模型训练到逻辑实现，整个链路走下来最深的体会是：检测模型决定的是系统的上限，而行为判定逻辑决定的是系统的可用性。YOLOV5能帮你把人、眼、嘴、手机都框出来，但怎么把这些检测结果变成业务方能看懂、能决策的专注度指标，需要在逻辑层花大量精力打磨。
另外想给同样在做这个方向的朋友一个忠告：不要迷信预训练模型的泛化能力。不管是YOLOV5还是其他检测模型，到了真实场景都必须用自己的数据做微调。哪怕只采集两个小时的真实场景视频，标注个几百帧，效果也会有质的飞跃。
这套代码后续我还在继续完善，目前正在往两个方向扩展：一个是引入轻量级关键点模型替换掉dlib，让整套系统能在树莓派和RK3588这类边缘设备上跑起来；另一个是加连续动作识别模块，把“频繁摸脸”“无意识点头”这类微小行为也纳入专注度分析。如果有朋友也做过类似的工作，欢迎交流。
本文还有配套的精品资源，点击获取
