简介面向深度学习与计算机视觉方向的毕业设计、课程设计开发者提供一套完整的驾驶员分心驾驶行为识别方案。资源整合了基于Keras框架的VGG16、VGG19、ResNet50、InceptionV3、Xception等经典卷积神经网络的微调与可视化代码覆盖数据预处理、瓶颈特征提取、模型训练、结果评估及可视化环节所有关键步骤均配有注释清晰的Python脚本与Jupyter Notebook新手也能快速上手。包内还包含项目说明文档、毕业论文成稿docx与pdf以及演示动图可直接参考撰写论文和制作答辩PPT。压缩包共31个文件以ipynb、py、html为主辅以pdf、docx、gif、md等格式整体大小约65.36MB目录结构清晰部署方便。目前已有739人下载学习适合需要从零搭建系统、完成高完成度项目的学生与研究者。1. 驾驶员分心行为识别一个看着简单、坑却不少的深度学习落地方案我复现过不少视觉分类项目驾驶员分心驾驶行为识别是其中“看起来简单、实际坑最多”的一个。它本质上是一个图像分类任务判断司机正在安全驾驶、打电话、发短信、喝水、化妆还是操作中控面板。但类间相似度高、光照变化大、姿态多样模型很容易在训练集上刷出高分一到真实场景就露馅。这套基于深度学习的驾驶员分心驾驶行为识别项目包含完整源码、标注数据集、训练好的模型权重以及配套毕业设计论文正好覆盖从数据准备到部署推理的全部环节适合正在选毕设题的同学也适合想系统性掌握图像分类工程的开发者。下面我按复现流程逐层拆解把每步能抄作业的参数和值得警惕的坑一并说清。2. 数据集与预处理分心样本怎么选、怎么切分才不踩坑2.1 数据集选型公开样本与自采数据的取舍驾驶员分心行为识别的主流做法是把它建成一个细粒度图像分类任务。公开数据集方面最常被引用的是 State Farm 分心驾驶员检测数据集它在模拟驾驶舱环境中拍摄覆盖 10 类行为。下面的表是我在复现时整理的标签含义也直接对应源码里的类别目录类别标签行为识别的关键部位c0安全驾驶双手在方向盘上视线朝前c1右手发短信右手不在方向盘手机在下半区c2左手发短信左手不在方向盘手机在下半区c3右手打电话手机靠近右耳右臂抬起c4左手打电话手机靠近左耳左臂抬起c5操作收音机手伸向中控台区域c6喝饮料手持杯体或瓶体嘴部靠近c7化妆手持镜子或化妆工具面部朝向镜头c8与乘客交谈头部转向副驾驶方向c9从后座拿东西身体向后方扭转这类公开数据的优点很直接类别体系是现成的标注也比较规整跑基线非常快。但它有个明显边界——拍摄背景固定在模拟驾驶舱里真实行车环境的光照、抖动、视角变化一旦叠加上来模型的泛化能力会明显下降。自采数据能缓解泛化问题但成本不低标注 10 类行为、每类至少 500 张有效样本一个人需要一周左右的时间。我一般建议的折中方案是用公开数据集做预训练和基准测试再补充 100 到 200 张自己拍摄的行车视频抽帧做最后的微调。这样既保留了可复现性又让模型带上真实场景的特征。2.2 预处理流水线RGB 顺序、裁剪比例与按人划分预处理环节看起来不复杂但每一处都藏着影响精度的细节。我的处理顺序是先用 OpenCV 读图并把 BGR 转成 RGB这个顺序很容易被忽略却是最常见的翻车点然后按中心裁剪裁掉左右两侧的副驾座椅和车窗背景裁剪比例设在 0.8 到 0.9再统一缩放到 224×224匹配 ImageNet 预训练模型的输入尺寸最后做归一化像素值除以 255再按 ImageNet 的 mean[0.485, 0.456, 0.406] 和 std[0.229, 0.224, 0.225] 做标准化。比预处理更关键的是数据划分方式。State Farm 数据集中同一个驾驶员会出现在连续多张图片里姿势和背景极其相似。如果直接随机划分训练集和验证集同一个人的图片被拆到两侧验证集分数会明显虚高训练过程看起来一切正常实际泛化能力却被高估。我采用的常见做法是“按人划分”而不是“按图划分”import os import random import shutil def split_by_subject(data_root, output_root, train_ratio0.8): 按驾驶员 ID 划分数据集保证同一个人不会同时出现在训练集和验证集。 data_root 结构要求data_root/subject_id/class_id/*.jpg subjects [d for d in os.listdir(data_root) if os.path.isdir(os.path.join(data_root, d))] random.shuffle(subjects) cut int(len(subjects) * train_ratio) train_subjects set(subjects[:cut]) for split_name, condition in [(train, lambda s: s in train_subjects), (val, lambda s: s not in train_subjects)]: out_dir os.path.join(output_root, split_name) os.makedirs(out_dir, exist_okTrue) for subject in subjects: if condition(subject): src os.path.join(data_root, subject) dst os.path.join(out_dir, subject) if not os.path.exists(dst): shutil.copytree(src, dst) split_by_subject(raw_data, split_data, train_ratio0.8)这个脚本的逻辑是先扫描出全部驾驶员 ID做一次随机打乱然后按比例切成训练组和验证组再按 ID 复制整个目录。注意这里必须用copytree复制整个驾驶员目录而不是复制单张图片否则类别目录结构就乱了。train_ratio0.8在样本量充足时是合理取值如果总人数少于 20建议提到 0.9因为验证集过小会导致评估波动明显。如果手里的原始数据不是按人分目录的就需要从文件路径或元数据中解析出驾驶员 ID再按 ID 分组。解析时特别要留意文件名分隔符的差异不同数据集的命名规范不一样正则写错了同一个人就被切散到两侧数据泄漏问题会再次出现。2.3 类别不平衡与数据增强公开数据集里 10 类样本基本均衡但一旦掺入自采数据类别数量就会明显拉开。我的经验是先把各目录的样本数统计出来打印一遍from collections import Counter counter Counter() for root, dirs, files in os.walk(split_data/train): class_id os.path.basename(root) counter[class_id] len(files) print(counter)如果类别之间数量差距超过 1 倍就需要处理。常见做法是随机过采样小类别再把小类别的样本重复读入训练循环也有人用加权采样器效果相近。数据增强层面翻转和旋转对分心驾驶这个任务特别有效因为驾驶员的左右手动作本来就有对称性但翻转有一个标签陷阱下面这份数据增强配置和对应的说明会讲清楚from torchvision import transforms train_transform transforms.Compose([ transforms.RandomResizedCrop(224, scale(0.8, 1.0)), transforms.RandomHorizontalFlip(p0.3), transforms.RandomRotation(degrees15), transforms.ColorJitter(brightness0.25, contrast0.25), transforms.ToTensor(), transforms.Normalize(mean[0.485, 0.456, 0.406], std[0.229, 0.224, 0.225]), ])RandomHorizontalFlip对左右手类别的影响需要特别说明水平翻转后“右手打电话”图像上的手部位置会镜像到左侧视觉特征接近“左手打电话”。如果训练时不做标签联动修改模型会在这两类上产生混乱。所以更稳妥的做法是对左右手成对类别单独处理或者把翻转概率降到 0.3 以下并用类别映射修正标签。我在复现时用的是成对映射方案训练循环里读取图片时如果发生了翻转就把 c1 与 c2 互换、c3 与 c4 互换。单纯压缩翻转概率也能缓解但不如映射方案彻底。3. 模型选型与训练ResNet50 与轻量化网络的取舍3.1 骨干网络选型从 ResNet50 到 MobileNet 的边界分心驾驶识别最稳定的基线是基于 ImageNet 预训练权重的迁移学习。骨干网络的选择本质上是在精度、参数量、推理延迟三者之间做权衡。下面是我在复现时整理的三个常见选择骨干网络参数量推理相对耗时适用场景ResNet5025.6M1x基准实验室验证、精度优先MobileNetV3-Large5.4M约0.3x边缘设备、实时推理EfficientNet-B29.2M约0.5x精度与速度的折中ResNet50 是最稳妥的起点。它的残差结构让十几层卷积之后梯度依然稳定训练曲线容易收敛调参空间也相对宽松。MobileNetV3 的优势在部署侧深度可分离卷积把参数量压得很低在 CPU 上也能跑到可用帧率但它的训练对学习率更敏感收敛后精度通常比 ResNet50 低 2 到 4 个百分点。EfficientNet-B2 是折中选择复现时需要额外安装 timm 库对刚接触深度学习代码的同学来说多一个依赖就多一个变量我建议先把 ResNet50 跑通再换。替换分类头是迁移学习的关键步骤。预训练模型在 ImageNet 上输出 1000 类分心识别只需要 10 类所以要重建最后的全连接层import torchvision.models as models import torch.nn as nn def build_model(num_classes10, backboneresnet50, pretrainedTrue): if backbone resnet50: model models.resnet50( weightsmodels.ResNet50_Weights.IMAGENET1K_V2 if pretrained else None ) in_features model.fc.in_features model.fc nn.Sequential( nn.Dropout(0.3), nn.Linear(in_features, num_classes) ) elif backbone mobilenet_v3: model models.mobilenet_v3_large( weightsmodels.MobileNet_V3_Large_Weights.IMAGENET1K_V1 if pretrained else None ) in_features model.classifier[-1].in_features model.classifier[-1] nn.Linear(in_features, num_classes) return model这段代码的逻辑是保留预训练模型的特征提取部分只重建最后的任务头。ResNet50 的model.fc.in_features是 2048MobileNetV3 最后一个线性层的输入是 1280这些值不需要手写直接从原模型里取。分类头里加一个 Dropout 是为了抑制小样本类别的过拟合概率设 0.3 已经足够再大反而会拖慢收敛。3.2 训练配置冻结层、学习率与收敛节奏迁移学习里一个常被忽略的点是“冻结”策略。我的做法是前 5 个 epoch 冻结骨干网络的所有参数只训练新加的分类头让随机初始化的分类头先学会适配预训练特征第 6 个 epoch 开始解冻骨干网络的后半段用更小的学习率对整个网络做微调。def set_freeze_by_epoch(model, epoch, backbone_nameresnet50): for name, param in model.named_parameters(): param.requires_grad True if epoch 5: for name, param in model.named_parameters(): if fc not in name and classifier not in name: param.requires_grad False这段代码的行为是epoch 5时除分类头之外的所有参数都不可训练。解冻时要注意不能所有层同时放开否则分类头学习率偏大骨干网络的预训练权重会被快速破坏训练曲线容易出现先跌后涨的过山车现象。我见过不少训练日志里验证集 loss 在第 6 个 epoch 突然抬升就是解冻策略没控制好。学习率方面分类头用 1e-3骨干网络解冻后用 3e-5整体采用余弦退火。对应的优化器与调度器配置如下from torch.optim.lr_scheduler import CosineAnnealingLR import torch.optim as optim optimizer optim.SGD(model.parameters(), lr1e-3, momentum0.9, weight_decay5e-4) scheduler CosineAnnealingLR(optimizer, T_max30, eta_min1e-5)SGD配合momentum0.9在图像分类任务上是稳定的默认选择weight_decay5e-4对全连接层有效对卷积层影响不大。T_max30表示 30 个 epoch 完成一个完整的余弦周期学习率从初始值缓慢降到eta_min1e-5。有人用 Adam 也能跑但我在这类任务上遇到 Adam 的验证精度波动偏大换成 SGD 后反而稳定很多。AdamW 也可以试但初始学习率要降到 1e-4 附近否则前几个 epoch 就会发散。3.3 评估指标不要只看整体准确率分心驾驶任务最容易出现的情况是整体准确率很高但某个类别完全崩掉。比如“与乘客交谈”和“安全驾驶”之间头部姿态稍微偏移一点就被误判再比如“右手发短信”和“左手发短信”模型对左右手的区分本身就敏感。所以评估时要打印混淆矩阵和每个类别的召回率from sklearn.metrics import confusion_matrix, classification_report y_true, y_pred [], [] model.eval() with torch.no_grad(): for imgs, labels in val_loader: imgs imgs.cuda() logits model(imgs) preds logits.argmax(dim1).cpu().numpy() y_true.extend(labels.numpy()) y_pred.extend(preds) print(classification_report(y_true, y_pred, digits3)) print(confusion_matrix(y_true, y_pred))classification_report输出的 precision、recall、f1-score 是按类别分开统计的如果某个类别的 recall 低于 0.85就需要检查是样本太少还是类间特征太接近。混淆矩阵里的高频错误对会告诉你具体是哪两类在打架比如 c3 和 c4 互相误判通常意味着左右手的特征没有学好。还有一个容易被忽略的点安全驾驶类的误报统计要单独看漏报一次危险行为比多报一次误警的后果严重得多模型选择的标准也应该向这个方向倾斜。4. 从单帧分类到行为判定推理脚本与连续帧决策4.1 模型加载与单帧推理训练完成之后核心工作转向加载模型并对视频流做实时推理。加载模型有两个常见做法一是用torch.save(model.state_dict())保存权重推理时先重建模型结构再 load二是保存完整的 TorchScript 脚本模型。前一种兼容性好后一种适合部署不依赖 Python 环境。下面是我常用的推理脚本框架import torch import torchvision.models as models import torch.nn as nn from PIL import Image from torchvision import transforms def load_model(weight_path, num_classes10, devicecuda): model models.resnet50(weightsNone) model.fc nn.Sequential( nn.Dropout(0.3), nn.Linear(model.fc.in_features, num_classes) ) state torch.load(weight_path, map_locationdevice) model.load_state_dict(state[model_state_dict] if model_state_dict in state else state) model.to(device).eval() return model val_transform transforms.Compose([ transforms.CenterCrop(224), transforms.Resize((224, 224)), transforms.ToTensor(), transforms.Normalize(mean[0.485, 0.456, 0.406], std[0.229, 0.224, 0.225]), ]) def predict_image(model, pil_image, devicecuda): img val_transform(pil_image).unsqueeze(0).to(device) with torch.no_grad(): logits model(img) prob torch.softmax(logits, dim1) conf, idx torch.max(prob, dim1) return idx.item(), conf.item()推理端的代码没有训练那么复杂关键点是model.eval()一定要调用它能关闭 Dropout 和 BatchNorm 的训练状态。CenterCrop(224)和Resize((224, 224))同时出现容易被误认为重复实际上 Crop 是先把图像中心裁成方形Resize 再统一尺寸两个操作合起来能减少图像拉伸导致的形变失真。torch.no_grad()会关闭梯度计算推理显存占用和单帧耗时都会下降。4.2 从单帧到连续判定滑动窗口投票与报警逻辑单帧分类结果不稳定。同一段 1 秒视频里某几帧把“安全驾驶”判成了“操作收音机”下一帧又跳回“安全驾驶”这种抖动在实际系统中不能直接使用。处理抖动的常见做法是滑动窗口投票from collections import deque import numpy as np class FrameVoter: def __init__(self, window_size15, alarm_class_idsNone): self.window deque(maxlenwindow_size) self.alarm_class_ids alarm_class_ids or {1, 2, 3, 4, 5, 6, 7, 9} def update(self, class_id, prob): self.window.append((class_id, prob)) if len(self.window) self.window.maxlen: return None, 0.0 ids [c for c, _ in self.window] counter np.bincount(ids, minlength10) vote_class int(counter.argmax()) vote_rate counter[vote_class] / len(ids) return vote_class, vote_rate这个FrameVoter的做法是维护一个长度固定的双端队列每来一帧就往队尾放入一个分类结果队首自动弹出。只有窗口满 15 帧时才输出判定结果输出的是窗口内出现次数最多的类别。vote_rate表示该类别在窗口内所占比例比例越高判定越可信。alarm_class_ids用来标记哪些类别属于需要报警的危险行为默认集合里排除的 c0 和 c8 是安全驾驶与交谈实际部署时可以根据业务需求调整。真实系统里很少直接播放单帧预测结果。我一般会在投票结果仍是危险类别、且vote_rate超过 0.7 的情况下才触发一次报警并给报警加一个 3 秒的冷却时间防止同一次行为触发多次提示。这样做的本质是把模型输出的单帧概率转换成一个短时间尺度上的决策比直接拿 softmax 结果做阈值要稳得多。窗口长度 15 帧对应 1 秒决策粒度在 15fps 的抽帧策略下刚好匹配人的反应节奏。5. 避坑指南数据、训练与推理三个阶段的常见问题5.1 数据阶段的坑验证集虚高与左右手翻转混乱复现这套项目最容易翻车的位置大多不在模型结构而在数据切分和增强这两个环节。我按现象、原因、解决三个层次记录了三条最典型的踩坑记录读者可以直接对照检查自己的流程。问题一验证集准确率接近 98%真实场景掉到 80% 以下现象训练日志里验证集精度很高把模型接到行车视频上测试准确率明显下降甚至稳定把安全驾驶判成操作收音机。原因训练集和验证集按图片随机划分同一个驾驶员的连续帧同时出现在两侧。分心驾驶数据集中同一人的图像背景、光照、姿势高度相似模型记住的是“这个人”的特征而不是“这个行为”的特征。解决按驾驶员 ID 分组切分数据用split_by_subject这种脚本保证同一人的图片只落在训练集或验证集一侧。切分完成后要抽查验证集目录确认每个驾驶员 ID 没有重复出现。问题二c1/c2、c3/c4 左右手类别的召回率始终偏低现象混淆矩阵里 c1 和 c2 互相误判比较频繁c3 和 c4 也有类似情况整体准确率被拉低。原因数据增强里加了RandomHorizontalFlip水平翻转后图像里的手部位置镜像变换但标签没有同步修改模型在左右手类别上收到了矛盾信号。解决去掉水平翻转或者用成对标签映射。更稳定的做法是只保留旋转 10 度以内的增强因为分心驾驶数据里左右手的物理方向对识别有明确意义不需要靠翻转来扩充样本。问题三自采数据加入后训练 loss 下降缓慢现象在公开数据集上训练正常加入自采数据后 loss 明显偏高收敛速度变慢。原因自采数据的图像分辨率、光照、相机位置与公开集不一致预处理参数没有统一归一化以后的数据分布出现偏移。解决把所有来源的图像统一走同一条预处理流水线先缩放再裁剪裁剪比例保持一致。自采数据如果分辨率分布跨度大可以在预处理里加一个Resize的中间步骤让输入尺寸先对齐到统一大小再裁剪。5.2 训练阶段的坑验证曲线震荡与 Loss 发散问题四验证准确率在第 6 个 epoch 突然下跌之后恢复缓慢现象前 5 个 epoch 验证集稳定上升进入第 6 个 epoch 后验证准确率突然跌了几个点之后需要很长时间才爬回来。原因骨干网络从冻结切换为解冻时所有参数同时开始更新预训练权重被较大的梯度扰动特征提取层出现短期退化。解决解冻时按层分组先解冻最后一个残差块再逐步解冻更早的层。更简单的做法是把解冻后的学习率压到 1e-5 以下让梯度扰动变小。问题五训练过程中 loss 变成 NaN现象训练日志打印的 loss 在某一步突然变成nan之后所有指标全部失效只能中断训练。原因数据管道里混入损坏图片或空标注文件读入的图像张量出现异常值也可能是初始学习率偏大梯度爆炸把权重数值推到溢出范围。解决检查数据加载日志确认每个 batch 的 tensor 统计量里没有inf或nan把分类头初始学习率降到 1e-4 再试在优化器之后加一层梯度裁剪torch.nn.utils.clip_grad_norm_(model.parameters(), max_norm5.0)能兜住绝大多数发散场景。5.3 推理阶段的坑颜色通道错位与模型状态错误问题六训练准确率高推理脚本预测结果一塌糊涂现象同一个验证集图片在训练脚本里评估准确率 95%换到推理脚本里预测结果几乎随机。原因推理脚本用 OpenCV 读图OpenCV 默认返回 BGR 顺序而 PyTorch 预训练模型期望的是 RGB颜色通道错位后模型看到的图像色调完全不对。解决读图后立即做cv2.cvtColor(img, cv2.COLOR_BGR2RGB)或者在预处理函数里用 PIL 的Image.open替代 OpenCV。问题七单张推理正常连续跑视频时显存缓慢增长现象固定输入分辨率推理单张图片显存占用稳定连续处理视频帧时显存不断攀升最后 OOM。原因每一帧都调用.cuda()或者torch.from_numpy创建新张量旧的张量没有被及时释放PyTorch 的缓存分配器没有把显存还回来。解决推理循环外面统一创建输入张量每帧用copy_把数据填进去或者每处理 100 帧调用一次torch.cuda.empty_cache()。更彻底的做法是把推理函数改成接收预处理后的张量而不是接收 PIL 图像这样张量的生命周期由调用方控制。6. 最后一步滑窗投票的细节调参与行为链判定前面第 4 章给出的FrameVoter是基础版本实际部署时还有两个参数值得深调窗口长度和报警阈值。窗口长度 N 是第一个关键参数。N30 表示 30 帧按 15fps 的抽帧速度相当于 2 秒决策窗口N15 是 1 秒。对报警任务来说窗口太长会延迟危险行为的响应窗口太短又无法滤掉单帧误判。我建议从 N15 开始优先保证报警及时性。如果现场误报率太高再把窗口加到 25 或 30但要注意误报率的下降与报警延迟是线性相关的。第二个参数是危险行为的触发条件。基础版取窗口内出现次数最多的类别作为结果但更实用的做法是记录窗口内的危险帧占比只有连续出现且占比超过阈值才触发。我在复现时用的是双重条件危险类别连续出现 3 帧以上且窗口内危险帧比例超过 0.7。连续 3 帧能过滤掉单帧噪声比例阈值能防止窗口内类别频繁跳动时误触发。class BehaviorTrigger: def __init__(self, danger_threshold0.7, consecutive_frames3, cooldown90): self.danger_threshold danger_threshold self.consecutive_frames consecutive_frames self.cooldown cooldown self._danger_streak 0 self._cooldown_left 0 def step(self, class_id, window_danger_ratio): if self._cooldown_left 0: self._cooldown_left - 1 return False if window_danger_ratio self.danger_threshold: self._danger_streak 1 else: self._danger_streak 0 if self._danger_streak self.consecutive_frames: self._cooldown_left self.cooldown self._danger_streak 0 return True return FalseBehaviorTrigger把报警决策拆成两个阶段先看窗口内的危险占比再做连续帧累计。cooldown90表示触发一次报警后 90 帧内不再重复触发在 15fps 下恰好是 6 秒足够司机完成一次抬头看路的动作。这个逻辑看起来简单但很有效它把单帧分类结果变成了一个有时间维度的行为链判断。从那以后我每次部署分心驾驶识别模型都会强制走一遍这套流程先按人切分数据验证是否有泄漏再打印混淆矩阵检查左右手类别最后用滑动窗口加报警冷却时间跑一段模拟视频。三个环节都过了模型才有底气接到真实场景里。希望帮到你。本文还有配套的精品资源点击获取