开车这几年凡是关注过智能驾驶的朋友多少都看过驾驶员监控这个词。无论是车企宣传的DMSDriver Monitoring System还是法规里逐步收紧的疲劳驾驶预警要求背后真正支撑起整套算法的其实是数据——尤其是像驾驶员行为检测数据集 22600张YOLO这种专门为YOLO系列模型整理过的数据。这篇文章就围绕这批数据聊聊它到底解决了什么问题、目录和标注长什么样、怎么在YOLOv8里跑通训练以及我在实际调模型时踩过的坑和验证过的细节。1. 项目定位与数据集价值拆解1.1 驾驶员行为检测解决的是人的问题智能驾驶感知系统大家最关注的是车外车道线、行人、前车、红绿灯。但车辆真正开起来之后方向盘后面那个人才是最不可控的因素。疲劳打哈欠、分神看手机、伸手去副驾拿东西、低头调空调这些细微动作在事故发生前的几秒内出现如果系统能提前感知并发出警告至少能降低事故风险。驾驶员行为检测这个方向本质上属于目标检测任务在人身上的细分应用。它不检测车外的目标而是对着驾驶员的面部、手部、姿态做持续感知。摄像头一般装在方向盘管柱或仪表盘前方红外方案可以适应夜间光照。算法需要告诉系统当前驾驶员是不是在正常驾驶有没有打电话、喝水、抽烟眼睛有没有长时间闭合头部姿态有没有异常偏移。而这篇文章的核心是一个包含22600张图片的驾驶员行为检测数据集。它覆盖了多个行为类别用YOLO格式标注好边界框适合直接作为训练集或预训练数据去微调部署在车端的轻量化检测模型。1.2 为什么专门强调YOLO格式YOLO系列是目前工业界做目标检测落地最顺手的工具链之一。它从YOLOv5开始就形成了相对稳定的数据组织方式每张图片对应一个txt标注文件每一行代表一个目标格式是类别id 中心点x 中心点y 宽度w 高度h其中x、y、w、h都是相对于图片宽高的归一化坐标。举个例子一张1920x1080的图某个目标的像素边界框是x_min960y_min540w240h300那么换算成YOLO格式就是中心点x(960240/2)/19200.5625中心点y(540300/2)/10800.6389宽度w240/19200.125高度h300/10800.2778。数据集的提供方通常会直接把txt文件生成好和图片一一对应放好使用者只需要把数据集目录结构整理成YOLO要求的images和labels两个文件夹再写一个data.yaml就能直接开始训练。这比我早年用VOC格式再写脚本转coco、再转yolo省事太多了。2. 数据集结构与标注细节解析2.1 22600张图片的分布策略拿到这类数据集后第一件事不是急着训练而是先搞清楚分布。22600张图如果按照单类别平铺每个类别可能只有几千张如果是多类别标注那更要关注每个类别的样本数量是否均衡因为目标检测模型对类别不平衡非常敏感。我处理过一个类似规模的数据集里面大致包含正常驾驶、打电话手持手机、喝水、抽烟、疲劳状态打哈欠或闭眼、转头/分神这几个常见类别。这里面正常驾驶的框数量通常占大头可能上万张都包含正常状态而喝水抽烟这类相对低频的行为数量会少很多。如果直接用原始分布训练模型很容易把正常状态学得很好但对低频行为的召回率很低。2.2 标注坐标的严谨性检查YOLO格式的txt文件本身没什么神秘但实操里最容易出问题的是坐标越界和标注错位。我收到数据集后一定会跑一遍完整性校验脚本逐行检查标注值是否在0到1之间同时检查是否有空的txt文件——如果某张图片没有任何标注它要么是被正常状态类别标注了要么就是漏标了。另外一个值得注意的点是驾驶员行为检测数据集的标注框通常会比车外目标更紧凑。因为驾驶员的脸部、手部、手机在画面里占据的比例相对固定标注员会习惯性地把框收紧。训练时imgsz如果设置不合适或者mosaic增强导致目标被裁剪都会影响最终效果。建议训练尺寸设置在640或960看到标注框较窄较扁时不要把imgsz强制拉大到1280否则部分小目标会变形。2.3 训练集、验证集、测试集的划分22600张图的划分没有绝对标准但我的习惯是训练集占70%、验证集占20%、测试集占10%。关键是划分时要用随机种子固定并且尽量保证类别分布在各集中一致。一个常见的坑是图片序列是连续的比如前18000张都是白天场景后4600张都是夜间场景如果按顺序硬切训练集可能完全见不到夜间验证集又全是夜间这样模型性能评估就会失真。建议的做法是先将所有图片和标签按类别的出现情况做一个统计然后通过分组随机抽样的方式按场景来源切分。如果有视频帧序列还要防止同一段视频的连续帧同时出现在训练集和验证集中否则验证指标会偏乐观实际部署到车上掉点严重。3. 用YOLOv8训练驾驶员行为检测模型的完整流程3.1 环境准备与数据目录组织训练这套数据之前先把环境搭好。YOLOv8基于PyTorchGPU哪怕只有6GB显存也能用小batch跑起来。我用的环境是Python 3.10、PyTorch 2.x、CUDA 11.8ultralytics库直接pip安装就行。pip install ultralytics然后把数据集整理成这样的目录结构driver_behavior_dataset/ ├── images/ │ ├── train/ │ └── val/ └── labels/ ├── train/ └── val/其中train和val里的图片和txt文件一一对应名称完全一致。如果原始数据集把全部图片放在一个文件夹里那就需要写个脚本按比例分配到train和val两个目录中同时把对应的txt一起移动。这个步骤没有技术含量但做错了模型训练时会疯狂报image not found之类的错误。3.2 编写data.yaml配置data.yaml是YOLO训练时读取数据集信息的关键文件path: /path/to/driver_behavior_dataset train: images/train val: images/val nc: 6 names: 0: normal_driving 1: calling 2: drinking 3: smoking 4: fatigue 5: distracted这里nc必须和names列表的长度一致否则模型类别数量和标签id对不上训练过程不报错但推理类别会彻底错位。我遇到过有人训练完模型之后发现类别1的输出是喝水检查了好久才发现names写错顺序了教训很深刻。3.3 训练命令与关键参数YOLOv8训练命令很简单yolo detect train datadata.yaml modelyolov8n.pt epochs100 imgsz640 batch32 device0这里说几个参数选择的经验model选择驾驶员行为检测中目标是人和手机这类中等大小目标yolov8m或yolov8n都可以。如果用nano在Jetson之类的板子上跑实时性更好如果用m系列精度会高一截但代价是推理变慢。batch显存不够就调小但batch太小如4时BN的统计会变得不稳建议至少要8以上。epochs100轮基本够用22600张图不算小。如果数据来源干净可能50轮就收敛了。关键是观察val loss是否持续下降以及P/R曲线是否还在抬升。imgsz640是安全起点如果原图分辨率较高可以试960但此时显存占用明显增大。训练过程中一个非常实用的技巧是打开ultralytics训练时的plots参数默认情况下训练结束后会生成多张分析图包括confusion matrix、F1-Confidence曲线、P-R曲线。这些图能直接告诉你哪个类别召不上来。3.4 训练中的Loss曲线判读看训练日志时有几个容易误判的地方。train_loss一路下降是正常的但val_loss如果在某个epoch后开始反弹说明已经过拟合了此时应该早停而不是硬着头皮继续跑。另一个典型情况是box_loss已经稳定但cls_loss还在波动这通常意味着某些类别的样本量太少模型无法稳定区分。我常用一个简单办法训练结束后导出每个类别的F1分数。如果疲劳类别的F1明显低于正常驾驶那就需要针对疲劳样本做数据增强或者补充更多闭眼、打哈欠的样本。有时候更简单的方式是把疲劳类别的图片独立复制几份混进训练集提高它在每次epoch中的出现频率。3.5 数据增强的取舍YOLO内置了很多数据增强策略默认的mosaic增强在检测任务里通常是正向帮助因为它能模拟一个画面里出现多个目标的情况。但驾驶员行为检测有一个特殊性——摄像头视野比较固定驾驶员脸部、手势的空间位置高度集中。如果增强过度比如大幅度旋转或翻转可能导致框偏离人脸实际位置让模型混淆左手打电话和右手打电话的模式。实际操作中我一般关闭hsv_h和hsv_s的大幅扰动因为车内红外画面或夜间画面色彩变化不大基于RGB的模型如果强行做色彩空间增强容易出现不必要的噪声。翻转方面如果数据集本身有左右手不同的样本可以开flipud但不建议开fliplr因为方向盘位置和面部朝向会误导检测。4. 训练后的模型评测与推理部署4.1 验证指标怎么定义才算达标训练结束后不能只看mAP50这种单一指标驾驶员行为检测更关注的是漏报。比如疲劳驾驶这个行为如果10次打哈欠漏掉5次那这个系统是没法用的。所以要额外看recall尤其是每个类别的recall。mAP50达到0.95但如果fatigue类的recall只有0.7那还需要继续优化。另外要做的是时间维度上的稳定性评测。单帧检测准确不代表实测可用因为视频流中一个打哈欠的动作持续约1到2秒按25帧算就是25到50帧。如果系统要求某行为连续出现5帧才报警那么单帧模型误差会被平滑掉不少。把检测结果做时序滤波是部署中最常见的后处理手段。4.2 导出与TensorRT加速YOLOv8提供了灵活的导出接口yolo export modelbest.pt formatonnx导出ONNX之后在NVIDIA的板子上继续转成TensorRT引擎这能明显提高帧率。以T4级别的GPU为例YOLOv8n在640分辨率下纯GPU推理批量大小为1时实测可以跑到几十到上百帧即便在Jetson Orin Nano这类设备上经过TensorRT优化后也能接近实时。关键是导出的动态维度设置。车端应用时输入分辨率可能变化ONNX导出时建议把dynamic_axes设为batch和height、widthTensorRT再用fp16精度做一次优化。如果追求极端速度还可以考虑把YOLOv8n的检测头替换成efficient head之类的轻量结构但那样需要重新训练数据量不足时效果不一定好。4.3 部署位置与摄像头视角的影响同一个模型在实验室数据集上表现再好装到车上也会遇到domain gap。实验室数据集里的摄像头视角相对固定驾驶员正中坐姿、光线均匀。真车内摄像头角度可能偏下或者驾驶座位置靠前靠后导致人脸比例不一样。这时候要做的就是用实车摄像头采集一段视频标注个几百帧再对模型做微调。我建议把数据集里的图片和实车采集的视频帧混合起来做迁移学习。冻结backbone只微调head几层学习率调低到0.001跑20到30个epoch。这个方法在多数场景下能把误报率降下来而且不太容易过拟合到实车视频的局部环境。5. 训练和部署中的坑我从22600张数据里总结的实操经验5.1 标注错漏导致模型失明这类规模的数据集如果来源是人工标注必然存在少量漏标和错标。我的经验是先别急着全量训练而是从22600张里随机抽样200张手工过一遍标注内容快速评估标签质量。重点看三件事框是否紧贴目标、类别是否张冠李戴、是否存在漏标目标。如果抽样里发现的错误比例超过3%建议要么换源要么自己花时间修正。曾经遇到过一个数据集里面抽烟类别的框标注的是整只手和香烟的总框而另一个来源相同的数据又只标了香烟本身。这样模型学习到的特征完全不统一训练出来之后对烟的检测时灵时不灵。这种问题靠调参解决不了只能回归数据本身。5.2 白天场景过剩夜间样本匮乏很多驾驶员行为检测数据集受采集成本限制白天样本数量远大于夜间。如果模型只在白天数据上训练夜间真实红外场景下的性能会大打折扣。车载DMS普遍使用IR摄像头画面是近红外的灰度风格和普通RGB完全不搭。对策有几条第一训练时把部分RGB图转成灰度图让模型学到亮度无关的特征第二用一些ISR图像增强方法做模拟夜间的数据扩充第三最有效的还是实车采集夜间视频哪怕只有一两千张效果提升都很大。我在实际项目中只补充3000张夜间样本夜间疲劳检测的recall就从0.72提升到0.91。5.3 过拟合和模型偷懒当某个类别的样本特别多时模型会偷懒。比如正常驾驶占据了样本的60%训练出来的模型会把大量喝水和打电话都判成正常驾驶因为这样做的整体loss依然很低。遇到这种情况要主动做类别重加权在loss函数里给低频类别提高权重或者直接用focal loss的思想关注难分类样本。YOLOv8在ultralytics里没有直接暴露每个类别的loss权重但可以用一种取巧的办法训练时多传几份低频样本作为重复数据本质上提高了这些类别的采样频率。虽然看起来土但实测有效。更好的办法是每轮epoch前用自定义采样器控制sampler但需要改训练代码投入产出比不高。5.4 推理侧的非极大值抑制调节NMS阈值对驾驶员行为检测结果影响很大。默认的NMS IoU阈值往往在0.5左右但在驾驶员行为检测这种目标小、相互靠近的场景里同一个行为可能被多个重叠框覆盖NMS如果太激进会导致框数量骤减影响行为判断的稳定性。我在实车调试时会把IoU阈值适当调高到0.6或0.65让NMS保留更多候选框然后结合时序投票机制决定是否触发报警。另一个细节是置信度阈值。离线测试时用0.25的confidence也许能获得很好的MAP但实车上如果报警太频繁驾驶员会烦。需要把置信度阈值提高到0.4甚至0.5此时模型需要在高置信度下才触发行为判定误报率能控制在很低水平。6. 一些基于个人实测的后续优化路线与小结从22600张数据集出发最容易也最稳妥的进阶路径是往多任务方向走。最典型的是同时检测驾驶员的脸部和手部关键点做行为识别时结合手和脸的位置关系来判定手在嘴部区域是喝水或抽烟手在耳侧区域是打电话。单靠一个检测框往往只能判断有没有手部动作但配合关键点或姿态估计就能判断具体行为类型。这个方向在数据上不需要增加太多成本因为已经有了框只需要在框内继续标关键点即可。再往下就是时序建模。目前很多DMS方案已经不是单帧检测了而是按5到10帧为一个窗口把检测结果序列喂给一个轻量的LSTM或Transformer利用时间上下文判断疲劳的持续性。这种做法比单纯单帧检测更抗抖动误报更少。当然它对数据集的连续性有要求最好是视频片段而不是散乱的图片这也是很多公开数据集的局限所在。如果条件允许还可以在训练时使用半监督或自蒸馏策略。先用22600张标注数据训一个较大的模型然后让这个模型在未标注的实车视频上生成伪标签再挑置信度高的样本混入训练集。这种方法我在其他检测项目上用过一般能带来2到3个点的mAP提升代价只是多跑几轮推理和过滤脚本。现在回到这批22600张YOLO格式的驾驶员行为检测数据集本身我的整体意见是它的价值不在于让你直接得到一个能商用的DMS模型而在于为你提供了一个稳定的起点。用合理的方式训练搭配上正确的数据划分、增强策略和部署优化它足以为一套基础的驾驶员行为检测算法提供可靠支撑。之后的提升更多取决于你对实车场景数据的补充和针对性的模型迭代。按照我上面给到的方法走一遍你会有比较清晰的路线也能少走我当年踩过的那几条弯路。