简介面向人脸检测与计算机视觉学习者的疲劳监测实战资源定位在“人脸检测高级”阶段可帮助读者掌握基于人脸关键点的状态判断方法。资源通过摄像头或图像输入实时计算眼睛纵横比等指标评估闭眼频率与幅度适用于驾驶疲劳提醒、网课注意力监测、考勤状态分析等场景尤其适合具备一定OpenCV基础、希望进阶学习人脸应用的开发者。压缩包共5个文件包含两个dat格式的人脸关键点模型shape_predictor_5与shape_predictor_68分别支持轻量级检测与更高精度、一个mp3报警音频、一个Python检测脚本以及一份pdf说明文档整体约74.83MB。检测脚本可直接运行支持加载不同精度的关键点模型连续监测眼部状态并触发声音报警pdf文档则对原理、依赖环境与使用步骤进行说明方便二次开发。无论是学习人脸关键点定位原理还是直接部署为疲劳提醒工具均能提供完整闭环。已有952人学习下载是入门人脸疲劳监测不可多得的完整小项目。1. 人脸检测与疲劳监测为什么这不是一个普通的分类模型很多做安防、车载或者考勤系统的工程师第一次看到“疲劳监测”需求时习惯性把它归类为“人脸检测的进阶版”——以为找几张打哈欠、闭眼的照片训练一个分类模型就完事了。实际做完你会发现完全不是那么回事疲劳监测的核心不在“检测人脸”而在“对人脸关键点的持续追踪和状态推演”。一张闭眼的照片模型认得出但一段视频里眼睛是正常眨眼还是困倦闭合眨眼频率是每分钟15次还是5次这些时间维度上的信息才是判断疲劳的关键。“人脸检测高级”这个前缀也很直白它默认你已经有正脸检测和人脸关键点定位的基础能力疲劳监测是往上再做一层状态机逻辑。适用场景集中在驾驶舱内疲劳预警、在线考试防作弊、长时间值守工位监测几个方向。它的难点不在算法本身多深而在工程上——相机角度、光照突变、眼镜遮挡、姿态偏转每一个干扰因素都会让关键点坐标抖动到无法置信。从业者拿到这类资源包真正该学的不是那个模型权重而是整套链路人脸检测 → 关键点提取 → 眼部/嘴部量化 → 时序判定。本文就按这条链路拆开讲每个环节给出可复现的代码和参数。2. 疲劳监测的指标选型EAR、MAR、PERCLOS 哪个才是硬指标先把原理层的账算清楚。疲劳监测算法经过这么多年沉淀真正被反复验证有效的无非三个量化指标眼睛纵横比EAR、嘴巴纵横比MAR和单位时间内眼睛闭合时间占比PERCLOS。它们全部建立在一个前提上——人脸关键点定位足够稳定。所以这里先明确一点98点、68点还是5点关键点决定了疲劳监测精度的上限。68点方案是目前兼顾精度和计算量的折中dlib自带预训练模型MediaPipe的468点稠密网格在普通CPU上也能跑到实时但落地时很多人为了帧率改用5点结果眼部关键点只有两个点算不出纵横比方案直接报废。2.1 EAR的几何直觉为什么眼睛闭合时纵横比会阶跃下降EAR的计算不涉及任何学习参数纯粹是几何关系。眼睛的6个关键点dlib 68点模型中的第37-42点构成一个近似椭圆EAR定义为垂直方向两个距离的平均值除以水平方向距离。睁眼时这个比值稳定在0.25到0.35之间闭眼时骤降到0.1以下。因为分子是两个垂直距离的平均分母是水平距离眨眼动作只会让分子快速缩小而分母几乎不变所以这个指标天然抗个体差异。import dlib from scipy.spatial import distance as dist def eye_aspect_ratio(eye): # 输入dlib 68点模型中的左右眼各6个关键点坐标 # 垂直距离1点1到点5的欧氏距离 A dist.euclidean(eye[1], eye[5]) # 垂直距离2点2到点4的欧氏距离 B dist.euclidean(eye[2], eye[4]) # 水平距离点0到点3的欧氏距离 C dist.euclidean(eye[0], eye[3]) # 纵横比两个垂直距离的平均值除以水平距离 return (A B) / (2.0 * C)参数说明eye是6个坐标点构成的数组顺序必须严格对应dlib输出的左眼或右眼关键点索引。很多人翻车在这里——索引顺序对不上计算出来的EAR在睁眼时反而比闭眼时更低。dlib官方68点模型中左眼是42-47程序中索引从0开始为37-42右眼是36-41索引30-35别搞反。EAR是标量随帧变化所以疲劳判定不是在某单帧看绝对值而是看低值持续了多少帧。2.2 MAR与PERCLOS嘴巴张合度和闭眼时长的互补逻辑MAR计算逻辑与EAR完全一致只是关键点换成嘴部的6个点dlib索引49-54程序0起始为48-53。打哈欠时MAR显著上升正常说话时也会有波动所以单独用MAR做判定会误报。PERCLOS的定义是单位时间内眼睛闭合帧数占总帧数的比例。学术界公认阈值是P80——即眼睛闭合程度超过80%的时间占比。工程实现上简化成连续N帧EAR低于阈值就计为一次闭眼事件统计闭眼事件时长与总时长的比值。EYE_AR_THRESH 0.22 # EAR低于该值认为眼睛闭合 EYE_AR_CONSEC_FRAMES 3 # 连续3帧低于阈值才记为一次闭眼 frame_counter 0 # 连续闭眼帧计数器 total_blinks 0 # 眨眼总次数 # 每帧人脸关键点提取后执行判定逻辑 if ear EYE_AR_THRESH: frame_counter 1 else: if frame_counter EYE_AR_CONSEC_FRAMES: total_blinks 1 frame_counter 0 # PERCLOS计算假设统计窗口为60秒帧率25fps窗口总帧数1500 # perclos (frame_counter_in_window / 1500) * 100参数说明EYE_AR_THRESH取0.22是针对dlib关键点的经验值不同相机距离、不同人种眼型会有偏移后面第4章详细说怎么标定。EYE_AR_CONSEC_FRAMES取3是为了过滤眨眼过程中的瞬间抖动。正常眨眼持续时间100-400毫秒按25fps算就是2-10帧连续3帧只是最低门槛实际部署建议5帧以上。PERCLOS统计窗口建议60秒滚动计算而非累计到疲劳才看——你可以实时画一条曲线让误报在图表上一眼暴露。2.3 指标选型结论疲劳判定从来不是单一阈值把三个指标叠加才构成可靠方案EAR低值持续时长判断闭眼MAR高值判断哈欠PERCLOS判断整体疲劳趋势。单一指标做判断必翻车——有人天生眼睛小EAR本来就低有人说话时嘴巴张合频繁MAR容易触发。我常见做法是三层判定短期10秒内闭眼总时长超过3秒直接报警中期60秒内PERCLOS超40%报警长期5分钟哈欠频率每分钟超2次且伴随头部低头动作增多判定为深度疲劳。这里先不展开代码第3章会给出完整实现骨架。3. 搭建疲劳监测主流程从摄像头到报警输出的完整代码骨架这一章给出可以直接跑通的完整链路。技术栈选用dlib的人脸检测器 68点关键点模型 OpenCV做图像处理然后在上层实现EAR/MAR计算和疲劳状态机。这套方案的好处是每个环节都可替换——检测器可以换成MediaPipe或YOLOv8-face关键点模型可以换成PFLD状态机逻辑基本不动。环境依赖只有三样dlib、opencv-python、imutils装dlib前需要确保系统有CMake和C编译器。3.1 初始化模型与视频流dlib检测器的三种输入方式import cv2 import dlib from imutils import face_utils # 初始化dlib人脸检测器与关键点预测器 detector dlib.get_frontal_face_detector() predictor dlib.shape_predictor(shape_predictor_68_face_landmarks.dat) # 视频来源摄像头0或视频文件路径 cap cv2.VideoCapture(0) # 设置分辨率与帧率汽油建议640x48025fps过高会拖累关键点推理 cap.set(cv2.CAP_PROP_FRAME_WIDTH, 640) cap.set(cv2.CAP_PROP_FRAME_HEIGHT, 480) cap.set(cv2.CAP_PROP_FPS, 25) while True: ret, frame cap.read() if not ret: break gray cv2.cvtColor(frame, cv2.COLOR_BGR2GRAY) # 检测人脸第二个参数是金字塔上采样次数1表示对图像放大一倍找小人脸 faces detector(gray, 1) for face in faces: landmarks predictor(gray, face) # 转为numpy数组方便索引shape为(68, 2) points face_utils.shape_to_np(landmarks) # 此处提取左右眼与嘴部关键点逻辑见下文 # 显示结果 cv2.imshow(Fatigue Monitor, frame) if cv2.waitKey(1) 0xFF ord(q): break cap.release() cv2.destroyAllWindows()参数说明detector(gray, 1)中的上采样参数1意味着把输入图像放大一倍再检测能提升远距离小脸的召回率代价是每帧耗时翻倍。建议先设为0跑原型确认漏检严重再调为1。dlib的人脸检测器在正脸和轻度侧脸±30度内可靠超过这个角度会整个丢脸——这在驾驶场景是致命的因为司机看后视镜、转头观察路况时脸必然偏转此时的策略后面第4章讲。3.2 关键点索引与EAR/MAR计算68点模型的解剖学映射dlib 68点模型的索引顺序是固定的其中左眼6点索引36-41、右眼6点索引42-47、嘴部外轮廓6点索引48-53、嘴部内轮廓6点索引60-65。注意OpenCV图像坐标系原点在左上角x轴向右y轴向下所以EAR计算公式中的垂直距离用的是y坐标差方向正负无关紧要只要取欧氏距离就行。这里直接给出封装函数# 左右眼与嘴部关键点索引范围 LEFT_EYE_START, LEFT_EYE_END 36, 41 RIGHT_EYE_START, RIGHT_EYE_END 42, 47 MOUTH_START, MOUTH_END 48, 53 INNER_MOUTH_START, INNER_MOUTH_END 60, 65 # 在循环中提取各部分并计算指标 leftEye points[LEFT_EYE_START:LEFT_EYE_END] rightEye points[RIGHT_EYE_START:RIGHT_EYE_END] mouth points[MOUTH_START:MOUTH_END] leftEAR eye_aspect_ratio(leftEye) rightEAR eye_aspect_ratio(rightEye) # 左右眼EAR取平均值避免单眼遮挡或眯眼造成的瞬时误判 ear (leftEAR rightEAR) / 2.0 mar mouth_aspect_ratio(mouth)参数说明左右眼EAR取平均值是常见做法但如果监测对象经常侧头导致单眼被遮挡严重平均反而掩盖问题。我在车载场景会让左右眼分别计算单眼EAR低于阈值且持续超过1秒就直接判定闭眼因为正常眨眼时闭上单眼的概率极低。MAR用水嘴外轮廓计算内轮廓不需要——打哈欠时外轮廓明显张开说话时外轮廓张合幅度小得多阈值区分更干净。3.3 疲劳状态机把连续帧指标翻译成报警等级# 状态机参数配置 EAR_THRESH 0.22 # 闭眼判定阈值 EAR_CONSEC_FRAMES 5 # 连续低值帧数 MAR_THRESH 0.55 # 哈欠判定阈值嘴巴张开且持续 MAR_CONSEC_FRAMES 8 # 连续高值帧数 CLOSE_BLINK_COUNT 30 # 一个疲劳周期内闭眼次数上限 SEGMENT_FRAMES 300 # 统计周期5分钟25fps * 300秒7500帧此处为便于演示取300 # 状态变量 eye_close_frames 0 mouth_open_frames 0 close_events_in_window 0 frame_count 0 for each_frame: # 继脸检测与指标计算后 if ear EAR_THRESH: eye_close_frames 1 if eye_close_frames EAR_CONSEC_FRAMES and eye_close_frames % EAR_CONSEC_FRAMES 0: close_events_in_window 1 else: # 连续闭眼帧中断清零重置 eye_close_frames 0 if mar MAR_THRESH: mouth_open_frames 1 yawn_count 1 if mouth_open_frames MAR_CONSEC_FRAMES else 0 else: mouth_open_frames 0 frame_count 1 # 每统计周期结束评估一次疲劳等级 if frame_count % SEGMENT_FRAMES 0: # 疲劳等级level0正常 / level1轻度 / level2深度 if close_events_in_window CLOSE_BLINK_COUNT: level 2 if yawn_frequency 2 else 1 # 复位周期计数 close_events_in_window 0参数说明这个状态机的关键在“阈值”和“持续帧数”不是静止的——我见过不少初级实现把EAR阈值写死成0.22换个戴眼镜的人就频繁误报。正确做法是先让系统跑一段“清醒基线期”比如前60秒记录EAR均值和标准差然后以“均值减2倍标准差”作为动态闭眼阈值。同理哈欠阈值也建议用动态值。还有一点close_events_in_window的计数逻辑不能简单每次闭眼都1否则连续打盹时闭眼一次持续2秒被重复计数疲劳等级虚高。3.4 报警输出与日志保存给验收方一个可回溯的证据链import datetime import json # 报警状态与日志记录 alert_level 0 alert_log [] def trigger_alert(level, frame, points, metrics): # 保存当前帧为JPEG标注关键点和EAR/MAR数值 timestamp datetime.datetime.now().strftime(%Y%m%d_%H%M%S) cv2.putText(frame, fEAR:{metrics[ear]:.2f} MAR:{metrics[mar]:.2f}, (10, 30), cv2.FONT_HERSHEY_SIMPLEX, 0.7, (0, 0, 255), 2) cv2.imwrite(falerts/fatigue_{timestamp}.jpg, frame) # 记录结构化日志用于后期分析 alert_log.append({ time: timestamp, level: level, ear: metrics[ear], mar: metrics[mar], blink_rate: metrics[blink_rate] }) # 按需发送外部通知可接串口、MQTT或Webhook此处略过参数说明报警帧保存为JPEG是给验收方最直观的证据。日志不要只记时间戳和等级EAR、MAR、眨眼频率必须一起存否则事后复盘无法定位误报。我在实际项目里还会把视频按报警时刻前后各保留30秒存储格式用MP4不然事后看单张静态图根本分辨不了是疲劳还是眯眼——这是和客户扯皮时最重要的后悔药。4. 参数标定与部署优化让 EAR 阈值和检测器适配你的真实场景很多人在原型阶段跑得顺畅一到实际部署就开始玄学抽风——同一个算法白天的会议室里好好的晚上车库里疯狂误报。问题不在算法而在三个地方相机安装角度、光照策略、以及检测器的失效边界。这一章讲清楚参数标定和部署选型的实操套路。4.1 相机安装角度俯视角会毁掉关键点的几何语义疲劳监测对相机角度的敏感程度远超一般的人脸识别。EAR的计算依赖眼睛关键点的垂直距离如果相机装在头顶正上方俯拍眼睛在画面里被压缩成一条扁平的线EAR的基线整体下移睁眼和闭眼的分界线变得模糊。反过来相机水平正对眼睛时EAR的区分度最好。我的一般做法是让相机光轴与眼睛平面的夹角保持在15度到45度之间。超过45度俯拍EAR基线会掉到0.15以下原本0.22的闭眼阈值完全失效。车载场景里相机通常装在内后视镜附近正对驾驶员面部这个角度天然合适但如果是装在A柱或仪表台要实测画面里眼睛的EAR基线是否达到0.25以上达不到就调整支架。# 用命令行快速评估当前安装角度的EAR基线 # 以25fps采集30秒视频计算并输出EAR均值 python evaluate_ear.py --video calibration.mp4 --output ear_stats.json参数说明这个evaluate脚本本质上就是跑一遍检测和关键点提取然后输出EAR序列的均值、标准差、最小最大值。标定动作很简单——让被测人正对镜头保持睁眼状态30秒得到的EAR均值应该大于0.25标准差小于0.03。如果均值偏低先调角度再调算法如果标准差过大检查是不是关键点抖动考虑对坐标做卡尔曼滤波或移动平均平滑。4.2 光照与图像质量红外补光是最优解但有个大坑光线是疲劳监测最大的敌人。逆光时脸部过暗dlib检测器直接丢脸强侧光在脸上打出阴影关键点会被吸引到阴影边缘。最稳定的方案是使用带红外滤光片的摄像头配合红外补光灯。红外光线下人脸纹理被抹平但眼睛的虹膜和巩膜对比度反而更高EAR的计算反而更稳。不过红外方案有个坑红外LED补光灯的功率不够或者照射角度偏了画面里会出现一只眼睛亮一只眼睛暗的情况右眼的关键点质量下降EAR平均值被拉低。解决方式有两种一是把左右眼EAR分开处理不取平均单独一只眼持续闭眼超过阈值就报警二是在代码里加一个图像质量前置判断——如果人脸区域的灰度方差低于某个值说明画面过暗拒绝采样该帧。import numpy as np def check_face_quality(face_region_gray): # 计算人脸区域灰度方差低于阈值说明过暗或过度平滑 variance np.var(face_region_gray) return variance 400 # 经验值需根据实际传感器调整参数说明灰度方差的阈值400是我在普通USB摄像头上的经验值红外摄像头因为图像对比度低这个值可能只有80左右。所以这个参数必须在标定阶段调好方法很简单——录制一段正常光照和被测对象昏暗场景的视频分别计算灰度方差取两者中间值作为阈值。低于阈值的帧跳过关键点提取别硬算因为关键点在暗部区域的输出是随机噪声直接污染EAR曲线。4.3 检测器失效时的降级策略不能简单“丢帧”当人脸检测器连续若干帧检测不到人脸时疲劳监测系统面临一个决策是对外报告“无人脸”还是“保持上一状态”这个选择直接决定误报率。以驾驶场景为例司机低头看手机时检测器可能丢脸此时如果直接报警“疲劳”会被骂死但如果静默处理又可能错过真正的瞌睡点头。我的策略是分情况——小于0.5秒的短暂丢脸低头、转头不做任何处理超过1秒的持续丢脸则启动降级逻辑检测当前帧是否有侧脸或半脸有则标记“注意力分散”没有则标记“人脸丢失”但都不进入疲劳判定链路。# 人脸丢失计数 missing_frames 0 MAX_MISSING_FRAMES 25 # 25帧约1秒超过则降级 if len(faces) 0: missing_frames 1 if missing_frames MAX_MISSING_FRAMES: # 降级输出注意力分散或人脸丢失不参与疲劳计算 status face_lost else: missing_frames 0 status tracking参数说明MAX_MISSING_FRAMES的值取决于你的帧率和报警延迟要求。25fps下设为25是一秒看起来合理但实际驾驶场景里司机转头看后视镜通常要1.5-2秒所以这个参数我一般设在50左右2秒否则转头操作就会触发无关报警。还需要注意的是检测器丢脸但耳朵或下巴边缘还在画面里时可以靠边缘检测判断人的存在但不要试图用这种残缺关键点算EAR算出来的都是垃圾数据。4.4 边缘部署的算力调优检测分辨率与关键点推理的分时复用疲劳监测的完整链路包含人脸检测和关键点定位两步它们的计算开销不在一个量级。dlib人脸检测器在640x480分辨率下大约需要80-120毫秒取决于CPU和上采样参数关键点预测器只需要5-10毫秒。所以瓶颈在检测器不在关键点。我的优化套路是每3帧做一次完整检测中间2帧用上一帧的检测结果继续做关键点预测。因为正常视频流里人脸位置不会在33毫秒内发生巨大位移这样可以把整体处理帧率提升到接近单步关键点推理的速度。frame_skip 2 # 每3帧做一次dlib检测 frame_idx 0 tracking_face None if frame_idx % (frame_skip 1) 0: faces detector(gray, 0) if len(faces) 0: tracking_face max(faces, keylambda r: r.width() * r.height()) else: # 中间帧沿用上一帧人脸框可加margin扩大搜索范围 if tracking_face is not None: # 这里可以做人脸框位置预测简单做法是原框直接传入 pass参数说明这种分时复用方式能提升一倍的帧率但代价是快速转头时人脸框会滞后关键点错位甚至飞出人脸。缓解办法是引入一个简单的运动预测——用卡尔曼滤波器预测下一帧人脸框中心位置预测误差超过20像素时强制触发一次完整检测。我用OpenCV自带的KalmanFilter实现了这个逻辑效果明显代码量20行左右。注意这是优化手段不是必选项如果你部署的机器是工业电脑级别的i5处理器直接全帧检测也跑得起没必要为此引入复杂度。5. 疲劳监测项目的避坑指南五条真实踩坑记录这一章专门写我在疲劳监测部署过程中遇到过的五个典型问题。每一条都是真金白银换来的经验——从“能跑”到“稳定跑”之间隔着的全是这些细节。5.1 闭眼宽容度太好睡着了检测不到现象算法在测试视频上表现完美但实际应用中被测对象困到睁不开眼、眼皮半耷拉时EAR只是略低于阈值没有触发连续帧计数导致深度疲劳没有被报警。原因阈值设得过于保守EAR_CONSEC_FRAMES设得太大——我原来设的连续5帧而半闭眼状态EAR下降幅度不够深只达到0.25但闭眼阈值是0.22根本无法触发。解决用动态阈值替换固定阈值。做法是标定阶段记录清醒状态的EAR均值和标准差以“均值 - 2.5倍标准差”作为动态闭眼阈值。这样半闭眼时会因为低于动态阈值而被识别。5.2 戴眼镜的反射光和镜框阴影导致关键点跳动现象被测对象戴着镜框较粗的眼镜关键点坐标在镜框边缘来回横跳EAR曲线噪声极大有规律的眨眼动作被淹没。原因dlib关键点模型在训练数据里对戴眼镜的人覆盖不足镜框边缘的梯度会吸引关键点。解决在关键点提取前增加一步图像预处理——对人脸区域做高斯模糊加低通滤波削弱镜框边缘的高频梯度。代价是眼角膜和巩膜边缘的对比度也会下降所以模糊半径不能大我一般用3x3的高斯核。更彻底的方案是换用MediaPipe关键点数更多对遮挡鲁棒然后把EAR阈值重新标定。5.3 点头瞌睡时脸直接超出检测范围现象司机打瞌睡时头越来越低直到整个人脸消失系统报警“人脸丢失”而不是“疲劳”。客户告警要求是“驾驶疲劳”不是“人脸不在”。原因疲劳状态机和丢脸检测逻辑没有联动。解决把“人脸丢失超过2秒且头部是渐进下移”处理成“深度疲劳”的辅助证据。关键在记录人脸框中心的y坐标变化轨迹如果y坐标在2秒内单调下移超过20%画幅高度判定为点头瞌睡触发报警如果是突然消失才判定为驾驶员下车或大幅度动作不做疲劳报警。5.4 处理器温度升高后帧率跳水误报率飙升现象设备在户外暴晒后帧率从25fps掉到12fps原本基于帧数的连续闭眼计数算法完全失效——同样的闭眼时长在低帧率下对应帧数变少触发不了报警。原因算法里所有持续时间都写成了帧数没有换算成真实时间。解决所有持续计数都除以实际帧率用时间单位判断。具体写法是记录系统时间戳闭眼时记录开始时间EAR恢复后计算时间差超过500毫秒视为一次闭眼事件。这个改动看似小但能消除帧率波动带来的全部误报。这是我血泪经验里最重要的一条。5.5 哈欠检测阈值与说话动作冲突现象被测对象正常说话尤其打电话时嘴巴开合频繁MAR频繁超过0.55哈欠计数疯狂上涨报警频率过高。原因说话时的嘴部运动也是高MAR值只是单次持续时间短。解决在MAR判定里增加一个最小持续时间——嘴巴连续张开超过0.8秒才算哈欠正常说话中单次开合通常不超过0.3秒。这个时间门槛过滤了绝大多数误报。还可以进一步判断嘴部运动是否与头部点头同步哈欠时头部通常会后仰说话时头部基本不动。6. 验证与进阶用离线视频回放给疲劳监测系统做“体检”系统上线前不做体检上线后必翻车。疲劳监测最适合的验证方式不是看实时画面而是录制一批带标注的测试视频离线逐帧跑一遍对比报警时间点和真实疲劳时间点。这里分享一个我用过的标定和验证工作流包括一条在光标上抠坐标、绘制预警曲线的技巧。6.1 自建验证数据集五种必须覆盖的场景不要拿网上随便找的疲劳视频验证那里面的人脸角度、光照和你部署环境差了十万八千里。自建数据集只需要一个摄像头和几个自愿者同事每种场景录制3分钟即可清醒正常驾驶、轻度疲劳打哈欠、频繁眨眼、深度疲劳闭眼超过1秒、点头、戴眼镜/墨镜、弱光/逆光。录制时让被测人自报状态“我现在很困我要模拟打盹”标注文件用最简单的CSV——时间戳、事件类型blink / yawn / nod / face_lost。总共大概200-300MB视频就够用关键覆盖边界情况不做海量数据。6.2 离线回放测试脚本统计报警延迟和误报率label_map {blink: 1, yawn: 2, nod: 3, face_lost: 4} true_positives 0 false_positives 0 false_negatives 0 # 遍历标注事件与算法报警时间戳比对 for labeled_event in labeled_events: matched False for alert in alert_log: # 报警时间与标注时间差在±3秒内视为命中 if abs(alert[timestamp] - labeled_event[timestamp]) 3.0: matched True break if matched: true_positives 1 else: false_negatives 1 # 计算未被任何标注命中的报警 matched_alerts set() for alert in alert_log: for labeled_event in labeled_events: if abs(alert[timestamp] - labeled_event[timestamp]) 3.0: matched_alerts.add(alert[id]) false_positives len(alert_log) - len(matched_alerts) precision true_positives / (true_positives false_positives) recall true_positives / (true_positives false_negatives) print(fPrecision: {precision:.2f}, Recall: {recall:.2f})参数说明时间容差±3秒是经验值报警延迟在工程上允许2秒左右加上标注误差1秒共3秒比较合理。如果容差设置超过5秒算法的实时性就没意义了。这个脚本把验证变成可量化过程每次调参后都跑一遍看precision和recall的变化。我发现一个规律大多数疲劳监测系统的precision很高报了基本是真的但recall偏低——困倦表现不明显时漏报。所以调参方向应该是优先提升recall接受一定误报再靠时序平滑过滤误报。6.3 进阶技巧EAR曲线和状态图叠加在原始视频上调试疲劳监测算法最直观的手段是把EAR、MAR数值和当前判定状态实时绘制在视频帧上。这样在回放时一眼就能看出指标波动和报警决策之间的因果。我的做法是右上角画一个半透明面板展示字段当前EAR值、MAR值、眨眼次数/分钟、疲劳等级0/1/2。同时用一条线把过去60秒的EAR曲线画在画面底部曲线低于阈值时用红色填充——这比任何日志都好使。另一个进阶技巧是让状态机的输出不止是报警信号还包括“置信度”字段。这个置信度不是概率而是当前疲劳等级判定的证据强度——比如“闭眼总时长3秒、且无说话、且连续低头”的输出置信度就比“只有闭眼”高。部署到实际场景时可以设置置信度门控超过0.8才触发声音报警0.6到0.8只做仪表台亮灯提示。这种方式大幅降低了警报噪音客户满意度提升明显。说了这么多最后想叮嘱一件我自己的教训疲劳监测永远不要追求100%准确——人体状态本身就模糊与其拼命调算法不如在交互设计上留余地。我现在每次部署完毕都习惯把所有报警截图按时间排好一条一条过一遍确认没有大量误报后再宣布“上线”。这套“离线视频回放体检 置信度分级报警”的组合拳帮我躲过了不知道多少次交付事故。希望帮到你。本文还有配套的精品资源点击获取
