简介一份面向计算机类专业毕业设计的高分项目资料围绕基于卷积神经网络的人脸识别驾驶员疲劳检测与预警系统展开适合正在准备毕设、课程设计或期末大作业的学生以及希望练习深度学习实战的学习者。资源提供完整的Python源码与配套数据集可直接运行调试。压缩包共19个文件涵盖11个Python源码、模型权重文件hdf5、OpenCV人脸检测所需的XML配置、依赖说明txt、可执行程序exe及README文档等整体78.33MB目录结构清晰便于快速定位核心代码、模型与数据预处理脚本。已有244人学习下载。项目内置mini_XCEPTION模型权重、人脸提取与数据加载脚本、tkinter界面程序等有助于理解从人脸检测、疲劳状态判别到预警展示的完整流程兼具工程落地与教学参考价值。1. 疲劳驾驶预警系统卷积神经网络在这道毕设题里的真实分量凌晨三点的高速上驾驶员眼皮闭合超过两秒车辆还在以百公里时速前进——疲劳检测系统的价值就在这一瞬间。基于卷积神经网络的人脸识别驾驶员疲劳检测与预警系统是 Python 毕业设计里长期热门的题目它把 CNN 图像分类、OpenCV 人脸检测、实时视频流处理和预警机制串成一条完整链路既有学术上的模型训练内容又有工程上的部署调试内容。这篇笔记面向两类人正在选毕业设计题目、想确认这个方向能不能撑起一篇论文的在校生以及想把疲劳检测接进车载或者工位监控场景的开发者。我会把数据怎么准备、模型怎么选、参数怎么调、现场怎么踩坑讲清楚。2. 从传感器选型到系统架构疲劳检测方案为什么走到 CNN 这条路上2.1 三种主流技术路线对比生理信号、驾驶行为、视觉特征疲劳检测不是只有看脸这一条路。做方案选型之前先把手头的选项盘一遍避免开题答辩时被问到“为什么不做脑电”而答不上来。目前工程上形成过三条路线。基于生理信号的方案采集脑电EEG、心电ECG或肌电信号通过电极贴片接触人体。优点是生理指标和疲劳的相关性有大量医学研究支撑准确率上限最高缺点是电极佩戴麻烦长时间驾驶不现实一套多导联设备的价格也远超毕设预算。这类方案在实验室做机理研究可以落地到驾驶舱基本没有可能。基于驾驶行为的方案通过方向盘转角、车道偏移量、油门刹车节奏来反推驾驶员状态。传感器成本低装在车上不打扰人但问题在于行为变化是疲劳的结果而非原因存在明显的滞后性——等方向盘开始蛇形摆动危险往往已经发生。而且不同驾驶员的行为基线差异很大阈值很难标定。基于视觉特征的方案用摄像头采集驾驶员面部图像通过眼睛开合程度、嘴巴张合状态、头部姿态来判断疲劳。非接触、硬件成本低一个普通 USB 摄像头就行响应及时是目前商用驾驶监控系统的主流选择。它的问题集中在光照鲁棒性和个体差异上而这恰恰是后面卷积神经网络要解决的核心矛盾。技术路线传感器优点主要缺点部署成本生理信号EEG / ECG 电极精度上限高、机理清晰佩戴不适、设备贵高驾驶行为方向盘角度、车道相机无侵入、成本低滞后明显、个体差异大中视觉特征驾驶舱摄像头无接触、响应快受光照和遮挡影响低三种路线对比下来视觉方案是毕业设计性价比最高的选择数据好采集、模型可视化效果好、答辩时能现场演示。后面的内容都围绕第三条路线展开。2.2 传统图像处理能检测疲劳吗EAR 阈值方案的边界很多人第一反应是用 OpenCV 的人脸关键点检测算眼睛纵横比EAR来判断闭眼不训练任何模型。这个方案确实能跑而且代码量极小但它在真实场景里扛不住。EAR 的原理是取眼睛周围六个关键点计算纵向距离与横向距离的比值。睁眼时 EAR 稳定在 0.25 到 0.3 之间闭眼时迅速降到 0.15 以下。配合 PERCLOS 指标单位时间内闭眼帧占比阈值通常取 0.4能实现一个朴素的疲劳判定。问题出在三个地方。第一EAR 的绝对值因人而异。单眼皮和双眼皮、眼睛大和眼睛小睁开程度对应的 EAR 基准值差很多一个全局阈值没法覆盖所有驾驶员。第二关键点检测在戴墨镜、逆光、侧脸角度大时定位会漂关键点一飘 EAR 就剧烈抖动误报率居高不下。第三打哈欠和说话在嘴部特征上高度相似单靠几何距离很难把两者分开。卷积神经网络解决的是特征表达问题。CNN 不需要人手工定义“闭眼是什么样”而是让卷积核在大量标注数据上自行学习眼睛、嘴巴在不同状态下的纹理模式。训练好的模型对个体差异和光照变化有更好的容错性——这也是这个方向值得作为毕业设计深挖的关键点。方案演进路径很清晰先跑通传统方法建立基线再对比 CNN 方法的优势论文的对比实验就有了。2.3 系统整体架构与数据流从摄像头到预警输出的完整闭环整个系统按数据流划分可以拆成五个模块每一块都有独立的调试空间。摄像头采集模块负责读取视频帧处理分辨率、帧率和曝光人脸检测模块在每一帧里定位人脸位置并裁剪出 ROI预处理模块对裁剪出的人脸做缩放、归一化CNN 推理模块输出疲劳概率预警模块对连续多帧的判定结果做平滑处理决定是否触发声光报警。架构上要注意的细节是推理频率。实时视频流每秒 30 帧如果把每一帧都送进 CNN 推理对 CPU 来说压力偏大对 GPU 来说又是浪费。常见的做法是设置跳帧策略每秒只对其中 5 到 10 帧做人脸检测和疲劳分类中间未推理的帧沿用最近一次的判定结果。这个策略在保证实时性的同时把计算负载降一个量级后面第 6 章会给出具体实现。数据流的方向是单向的摄像头产生帧帧经过人脸检测变成人脸 ROIROI 进 CNN 变成概率值概率值经过时序平滑变成预警信号。不要在任何一个环节做复杂的双向反馈毕设阶段保持流水线清晰比什么都重要。整个系统在 Python 里用 OpenCV 加 PyTorch 就能搭完不需要额外的中间件。3. 训练数据从哪来疲劳数据集构建与预处理3.1 公开数据集与自采数据的取舍以及类别怎么设计数据集是疲劳检测项目里最容易被低估的一环。模型能不能收敛、答辩时演示会不会翻车七成取决于数据质量而不是网络结构。公开数据集方面NTHU-DDD台湾清华大学驾驶数据集、YawDD 和 DROZY 是这个方向比较常用到的选项。它们包含不同受试者在清醒、困倦状态下的面部视频有的还提供了头部姿态和打哈欠的标注。用公开数据集的优势是省时间、结果可对比缺点是样本和真实驾驶舱环境存在 gap而且类别分布不一定符合你的需求。数据集内容适合用途注意点NTHU-DDD多受试者驾驶视频含困倦标注疲劳分类训练需申请、视频体积大YawDD驾驶中打哈欠视频哈欠检测类别较单一DROZY多模态生理视频数据扩展对比实验含生理信号处理复杂自采数据是这个项目比较推荐的补充方式。方法不复杂找一台带摄像头的电脑让 3 到 5 位同学分别录制正常状态和模拟疲劳状态的视频各 10 分钟。模拟疲劳的关键在于表演要真实——频繁眨眼、长时间闭眼、打哈欠、点头。录完之后按每 3 帧抽 1 帧的方式切图大概能拿到几千到上万张图片。类别设计有两种路线。第一种是二分类清醒和疲劳最简单模型容易收敛。第二种是多分类清醒、闭眼、打哈欠信息量更大论文可以做的分析更多。我一般建议采用多分类因为闭眼和打哈欠这两个中间状态单独成类之后可以分别统计频率为预警策略提供更细的输入。无论选哪种都要保证每个类别样本量均衡后面会用数据增强处理这个问题。3.2 人脸检测与对齐裁剪出稳定的人脸 ROI拿到原始图片后第一步是把人脸从背景里裁出来。人脸检测器有很多选择OpenCV 的 Haar Cascade、OpenCV DNN 模块的 SSD 检测器、dlib 的 HOG 检测器、MediaPipe 的 Face Detection。从速度和精度的平衡来看OpenCV DNN 的 SSD 检测器对毕设来说是比较稳的选择它比 Haar 鲁棒又不像 MediaPipe 那样引入太多额外依赖。import cv2 def load_face_detector(prototxt_path, model_path): net cv2.dnn.readNetFromCaffe(prototxt_path, model_path) return net def detect_and_crop_face(frame, net, target_size(64, 64), conf_threshold0.7): h, w frame.shape[:2] # 构建 blob缩放、减均值、交换通道顺序适配 Caffe 模型的输入格式 blob cv2.dnn.blobFromImage(frame, 1.0, (300, 300), (104.0, 177.0, 123.0)) net.setInput(blob) detections net.forward() best_confidence conf_threshold best_box None # 遍历所有检测框保留置信度最高的一个人脸 for i in range(detections.shape[2]): confidence detections[0, 0, i, 2] if confidence best_confidence: best_confidence confidence best_box detections[0, 0, i, 3:7] if best_box is None: return None # 坐标还原到原图尺寸 x1 int(best_box[0] * w) y1 int(best_box[1] * h) x2 int(best_box[2] * w) y2 int(best_box[3] * h) # 边界保护检测框越界时截断避免切片溢出 x1, y1 max(0, x1), max(0, y1) x2, y2 min(w, x2), min(h, y2) face_roi frame[y1:y2, x1:x2] if face_roi.size 0: return None return cv2.resize(face_roi, target_size)这个函数有两个参数需要根据实际场景调整。conf_threshold 默认 0.7如果发现该检测到的脸没检测到就降到 0.5如果背景里的非人脸物体频繁被框出来就往 0.8 以上调。target_size 决定了后面 CNN 的输入分辨率64×64 是个起步值数据充足时可以提到 112×112 提升精度。要注意的是这里的均值 (104.0, 177.0, 123.0) 是 Caffe 模型自带的标准化参数换成别的检测模型要跟着换否则检测效果会明显退化。3.3 数据增强与样本均衡别让模型只学会“清醒”疲劳样本的采集难度天然高于清醒样本——没人能随时随地表演出自然的困倦状态。这会导致数据集中醒着的图片远多于疲劳图片训练出来的模型会对一切输入都倾向于输出“清醒”这个现象在项目里太常见了。解决思路有两个方向。第一个是数据增强在训练时对图片做随机的翻转、旋转、亮度扰动和对比度扰动相当于从有限的原始样本里变出更多变体。第二个是采样策略用 PyTorch 的 WeightedRandomSampler 或者直接在 Loss 里给少数类更高的权重。from torchvision import transforms train_transform transforms.Compose([ transforms.RandomHorizontalFlip(p0.5), # 水平翻转模拟不同朝向 transforms.RandomRotation(degrees10), # 小角度旋转容忍侧脸 transforms.ColorJitter(brightness0.3, contrast0.3), # 亮度对比度扰动模拟光照变化 transforms.ToTensor(), transforms.Normalize(mean[0.5, 0.5, 0.5], std[0.5, 0.5, 0.5]), ])参数需要注意几点。RandomRotation 的 degrees 不要超过 15转多了人脸关键特征会失真。ColorJitter 的幅度在 0.3 左右比较合适太大图片会发灰发白让模型学到不真实的颜色分布。Normalize 的均值和标准差这里用的是 0.5 系列如果你的数据整体偏暗可以改成按实际统计值计算。数据增强不是越多越好。翻转和旋转在疲劳检测里是安全的但像 RandomErasing随机遮挡这类增强要谨慎使用因为真实驾驶场景中人脸被大面积遮挡往往意味着姿态异常不一定是疲劳。增强策略定下来之后把它同时用在验证集上是不对的验证集只用 ToTensor 和 Normalize保证评估结果真实反映模型在未增强数据上的表现。4. 用 PyTorch 搭 CNN 疲劳分类模型从模型定义到训练调参4.1 模型选型LeNet-5、ResNet18 还是 MobileNetV2CNN 模型选型是这个项目的核心决策。常见的选择集中在三个方向各有各的适用场景。LeNet-5 是经典的卷积网络结构简单参数量小CPU 上跑得飞快。但它的特征提取能力有限面对真实拍摄、光照不均的人脸图片准确率往往不够理想做毕设演示时容易在复杂场景露怯。它更适合作为课程实验而不是毕业设计的最终方案。ResNet18 是目前平衡性最好的选择。残差结构解决了深层网络的梯度消失问题18 层的深度对人脸分类来说足够权重文件也只有四十多兆训练速度快推理速度在 CPU 上也能达到实时。论文里有 ResNet 的消融实验可写答辩时也讲得出设计思路。MobileNetV2 的优势在参数量和推理速度适合后续要移植到树莓派或 Jetson Nano 的边缘设备场景。如果题目里明确写了“嵌入式”选它更合理。代价是精度比 ResNet18 略低调试时需要更仔细地调学习率。一般建议以 ResNet18 为基线模型先跑通流程再根据设备情况决定是否换成 MobileNetV2。直接上 ResNet50 或 VGG16 对毕设来说都是过度设计训练时间长、过拟合风险高收益却很小。4.2 模型定义与训练循环最小可跑通的完整代码用 PyTorch 实现整个训练流程代码量在 150 行左右。这里给出一个可以直接改路径就跑的最小版本包含模型定义、数据加载、训练循环三部分。import torch import torch.nn as nn from torchvision import datasets, transforms from torch.utils.data import DataLoader # 定义一个轻量 CNN适合作为 ResNet 之外的基线对比 class FatigueCNN(nn.Module): def __init__(self, num_classes3): super(FatigueCNN, self).__init__() self.features nn.Sequential( nn.Conv2d(3, 32, kernel_size3, padding1), nn.BatchNorm2d(32), nn.ReLU(inplaceTrue), nn.MaxPool2d(2), nn.Conv2d(32, 64, kernel_size3, padding1), nn.BatchNorm2d(64), nn.ReLU(inplaceTrue), nn.MaxPool2d(2), nn.Conv2d(64, 128, kernel_size3, padding1), nn.BatchNorm2d(128), nn.ReLU(inplaceTrue), nn.MaxPool2d(2), ) self.classifier nn.Sequential( nn.AdaptiveAvgPool2d(1), nn.Flatten(), nn.Dropout(0.5), nn.Linear(128, 64), nn.ReLU(inplaceTrue), nn.Linear(64, num_classes), ) def forward(self, x): return self.classifier(self.features(x)) # 数据集路径按 ImageFolder 目录结构组织 # dataset/train/awake, dataset/train/closed_eye, dataset/train/yawning train_dataset datasets.ImageFolder( rootdataset/train, transformtransforms.Compose([ transforms.Resize((64, 64)), transforms.RandomHorizontalFlip(), transforms.ToTensor(), transforms.Normalize([0.5], [0.5]), ]) ) val_dataset datasets.ImageFolder( rootdataset/val, transformtransforms.Compose([ transforms.Resize((64, 64)), transforms.ToTensor(), transforms.Normalize([0.5], [0.5]), ]) ) train_loader DataLoader(train_dataset, batch_size32, shuffleTrue, num_workers2) val_loader DataLoader(val_dataset, batch_size32, shuffleFalse, num_workers2) # 使用 ResNet18 作为主模型自定义 CNN 作为对比 from torchvision.models import resnet18 model resnet18(num_classeslen(train_dataset.classes)) criterion nn.CrossEntropyLoss() optimizer torch.optim.Adam(model.parameters(), lr1e-3) scheduler torch.optim.lr_scheduler.StepLR(optimizer, step_size15, gamma0.1) for epoch in range(30): model.train() running_loss 0.0 for images, labels in train_loader: optimizer.zero_grad() outputs model(images) loss criterion(outputs, labels) loss.backward() optimizer.step() running_loss loss.item() model.eval() correct 0 total 0 with torch.no_grad(): for images, labels in val_loader: outputs model(images) _, predicted torch.max(outputs, 1) total labels.size(0) correct (predicted labels).sum().item() scheduler.step() print(fEpoch {epoch1}: loss{running_loss/len(train_loader):.4f}, fval_acc{100.0 * correct / total:.2f}%)这里把两种网络都写进来了FatigueCNN 是一个三层卷积的基线模型适合做对比实验resnet18 是主模型直接迁移预训练权重也可以。batch_size32 是 8GB 显存下比较稳妥的值如果训练时内存不足就降到 16。StepLR 的参数 step_size 设为 15 表示每 15 轮学习率降为原来的 0.1让模型在训练后期用小学习率精细调整。num_workers2 在 Windows 上如果报错就改为 0这是 PyTorch 在 Windows 下的一个已知坑。训练结束后将模型保存为 state_dict方便推理阶段加载。保存模型的格式用 .pt 或 .pth内容包含模型权重后续在预警程序里加载后转换为 eval 模式即可。torch.save(model.state_dict(), fatigue_model.pth) print(模型已保存)4.3 训练参数设置学习率、batch、损失函数与过拟合控制训练参数的设置直接决定模型能不能收敛、会不会过拟合下面几个是我在实际调试中总结出的可复现经验。学习率方面Adam 优化器配 1e-3 是通用起点但人脸图像分类任务如果直接加载 ImageNet 预训练的 ResNet18建议把学习率降到 3e-4因为预训练权重已经处于一个较优的解空间过大的学习率会破坏这些特征。学习率衰减策略用 StepLR 即可每 15 个 epoch 降 0.1 倍总训练轮数 30 到 40 轮就能收敛。batch size 的选择和显存绑定。8GB 显存跑 ResNet18 输入 64×64batch 32 不会爆显存如果用的是自定义小 CNN可以放心调到 64。batch size 越大模型收敛越稳定但也越容易收敛到尖锐极小值泛化性能不一定更好这个需要在实验中权衡。损失函数选 CrossEntropyLoss 就可以它内部已经包含了 Softmax不要在模型输出层再手动加 Softmax。如果类别不平衡严重给 CrossEntropyLoss 传 class_weight 参数用 sklearn 的 compute_class_weight 算出各类权重。这一步对模型效果的影响比换网络结构更明显。过拟合的控制有三个手段组合使用。第一个是前面提到的数据增强第二个是 Dropout第三个是早停记录验证集准确率连续 5 个 epoch 不提升就终止训练。训练过程中要同时观察训练集和验证集的 loss如果训练 loss 持续下降而验证 loss 不降反升就是过拟合的信号优先加重数据增强而不是增加模型复杂度。5. 避坑指南与常见问题排查5.1 现象人脸检测框抖动导致预警乱跳人脸检测器在视频流上单帧独立检测时检测框会随轻微头部晃动而上下左右抖动裁剪出的人脸 ROI 内容跟着变化传给 CNN 的分类结果在清醒和疲劳之间来回横跳预警信号触发又取消体验非常差。原因在于没有对检测结果做时序平滑。每一帧都是独立决策而检测器对同一张脸的定位本身存在几个像素的随机噪声。解决方法是引入指数移动平均EMA对检测框坐标做平滑。具体实现是维护一个平滑框每帧用smooth_box alpha * current_box (1 - alpha) * smooth_box更新alpha 取 0.3 到 0.5。人脸丢失时保留最后一个平滑框连续 10 帧检测不到人脸才清空避免短暂低头就导致 ROI 消失。5.2 现象夜间与逆光场景下模型性能骤降白天演示效果很好一到晚上或者逆光环境检测准确率明显下滑失效概率很高。这是因为训练数据以正常光照为主模型没有见过低照度的人脸卷积核学到的纹理特征在暗光下提取不出来。解决思路分两层。数据层面在数据增强里加入亮度扰动并录制部分夜间数据让模型见过这种场景。图像处理层面在送入检测器之前对帧做直方图均衡化用 OpenCV 的cv2.equalizeHist先将 BGR 转成 YUV 对 Y 通道做均衡再转回。如果条件允许直接换红外摄像头是最省事的方案红外光下眼睛和面部特征对比度更稳定不受可见光影响。5.3 现象数据集类别不均衡模型对一切都说“清醒”训练结束时验证集准确率很高但实际测试时无论怎么输入模型都输出“清醒”。这是典型的类别不均衡症状清醒样本占总样本八成以上模型只要全预测为清醒就有八成准确率反向传播计算出的梯度也被多数类主导少数类的模式根本学不到。解决方法有两个优先同时使用。第一个是在 Dataset 构建时统计每类样本数给少数类做重采样用torch.utils.data.WeightedRandomSampler让每个 batch 里的疲劳样本比例保持在一个合理水平。第二个是给 CrossEntropyLoss 设置 class_weight计算方式推荐class_weight total_samples / (num_classes * class_counts)。两个手段都执行后观察模型在疲劳类别上的召回率是否明显上升。5.4 现象摄像头帧率与推理速度不匹配程序卡顿摄像头是 30 帧每秒模型在 CPU 上单帧推理需要 200 毫秒还要多视频画面明显掉帧预警响应跟着变慢。这个问题的本质是串行处理导致瓶颈累积。人脸检测加 CNN 分类在 CPU 上跑全帧率本身就不现实需要在工程上做降载处理。我采用的做法是跳帧推理设置一个推理间隔参数每 3 帧挑 1 帧做完整推理其余帧沿用上次结果。再配合跳过人脸检测的平滑框跟踪CPU 占用能降一半以上。如果项目允许使用 GPU把模型和数据都放到 CUDA 上推理速度提升一个量级。5.5 现象打哈欠和说话在图像上太相似误报频发用户反馈最多的场景是驾驶员说话时嘴巴持续张合模型反复判定为打哈欠。二者在单帧图像上的确有相似性——嘴巴都是张开状态单纯对单帧做分类从理论上就无法彻底区分。解决这个问题的思路有两个方向。一个是在模型输入层不只看嘴巴同时输入眼部和嘴部的联合特征打哈欠时眼睛往往也是半闭的说话时眼睛通常是睁开的模型可以学习到这种联合模式。另一个是引入时序信息统计连续 N 帧内的嘴部打开帧数和眼睛闭合帧数打哈欠是一个持续 3 到 5 秒、具有明确开始和结束的事件而说话是间歇性张合两者的时序特征差异明显。后一种方案不增加模型复杂度是我在实际项目中更常用的做法。6. 预警系统的实时落地与验证方法6.1 跳帧推理与连续帧触发的预警逻辑训练好模型之后部署端的核心逻辑是控制推理频率和消除误报。推理频率问题前面提过用跳帧解决。误报问题则需要连续帧触发机制不因为单帧的疲劳判定就报警而是连续 N 帧都被判定为疲劳才触发预警N 通常在 10 到 15 之间对应约 0.5 秒的持续疲劳状态。import cv2 import torch from torchvision import transforms model resnet18(num_classes3) model.load_state_dict(torch.load(fatigue_model.pth, map_locationcpu)) model.eval() cap cv2.VideoCapture(0) transform transforms.Compose([ transforms.ToPILImage(), transforms.Resize((64, 64)), transforms.ToTensor(), transforms.Normalize([0.5], [0.5]), ]) frame_count 0 fatigue_streak 0 FATIGUE_THRESHOLD 15 # 连续帧阈值 while True: ret, frame cap.read() if not ret: break frame_count 1 if frame_count % 3 ! 0: # 每 3 帧推一次 continue face detect_and_crop_face(frame, detector) # 复用第 3 章的函数 if face is None: fatigue_streak 0 continue tensor transform(face).unsqueeze(0) with torch.no_grad(): probs torch.softmax(model(tensor), dim1) fatigue_prob probs[0][1].item() # 假设第二类是疲劳 if fatigue_prob 0.7: fatigue_streak 1 else: fatigue_streak max(0, fatigue_streak - 1) if fatigue_streak FATIGUE_THRESHOLD: cv2.putText(frame, FATIGUE WARNING - Take a Rest!, (30, 60), cv2.FONT_HERSHEY_SIMPLEX, 1.0, (0, 0, 255), 3) # 在此处接入声光报警或语音提示 cv2.imshow(Driver Fatigue Monitor, frame) if cv2.waitKey(1) 0xFF ord(q): break cap.release() cv2.destroyAllWindows()注意代码中连续帧累加和衰减的细节判定为疲劳时连续帧数加 1判定为清醒时不是直接清零而是减 1。这个设计避免了一次模型误判就把计时清零同时又能让短暂清醒状态逐渐拉低疲劳计数。fatigue_prob 的阈值 0.7 是经验值实际使用时要根据测试视频的误报率调整阈设高了系统迟钝设低了自己吓自己。6.2 用带标注的测试视频量化评估演示不能只靠现场感觉需要一个可量化的评估流程。操作方法如下录制一段 10 分钟的真实驾驶模拟视频可以用行车记录仪画面替代在时间轴上标注出疲劳发生的起止时间段误差控制在 1 秒内。然后让系统跑一遍完整视频把每次报警时间输出成日志文件与标注结果对比。评估指标用三个准确率所有报警中真疲劳的比例、召回率所有疲劳时间段中被成功报出的比例、误报间隔平均多久出现一次虚假报警。这三个指标往往不能同时最优调阈值就是在它们之间找平衡点。如果误报率太高先提高疲劳概率阈值如果召回率太低先检查连续帧阈值是否设得太大再看是不是模型本身对疲劳样本不敏感。毕设答辩的核心演示逻辑是跑通实时检测并展示这段量化评估结果。训练准确率是一回事系统在真实视频流上的鲁棒性是另一回事能拿出后者整个项目的工程完成度就立住了。这个项目里我吃过最大的亏是在数据增强上偷懒导致模型在实验室灯光下表现优异换到现场偏暗环境就直接失灵。后来养成一个习惯从第一天起就在训练数据里混合多场景光照样本并且每次调整参数后先跑一段测试视频而不是只看训练 loss。做这类实时检测系统的落地项目数据覆盖度永远比模型结构更值得投资希望帮到你。本文还有配套的精品资源点击获取
