简介适用于YOLO系列算法的嗜睡检测数据集面向自动驾驶、驾驶员监控及疲劳预警等场景的目标检测开发者。数据覆盖头部下垂、唤醒、昏昏欲睡、分心、吸烟、打哈欠、电话等典型状态共8979张带标签图像已按训练/验证/测试集划分并附带data.yaml配置文件可直接用于YOLOv5、YOLOv7、YOLOv8、YOLOv9、YOLOv10、YOLO11等主流版本的模型训练与验证。压缩包共2000个文件以XML标注文件为主同时分别存放YOLO格式TXT标签与VOC格式XML标签适合不同框架间的格式切换坐标均按归一化比例记录使用便捷。包体约172.36MB结构清晰已有91人学习下载适合需要快速获得高质量疲劳状态样本、开展算法对比实验或完成毕业设计的读者使用。1. 嗜睡检测数据集YOLO训练里最容易被低估的一环做驾驶行为分析或者疲劳预警系统的工程师大概率都经历过这种尴尬模型结构选的是最新最火的训练代码也是从成熟项目改的loss曲线一路走低mAP看着也像回事结果一上实车或者一接摄像头打哈欠检测漏报低头看手机倒是报得挺欢头部稍微偏一点就直接判成“分心”。问题往往不出在算法而出在训练数据本身。嗜睡状态检测和通用目标检测有个本质区别它要识别的不是“有什么物体”而是“人处于什么状态”。同一个驾驶员同样是低头可能是看导航可能是捡东西也可能是真的困到睁不开眼——标签定义稍有不严谨模型学到的就是一团浆糊。所以当你拿到一个像“yolo算法-嗜睡数据集-8979张图像带标签-头部下垂-唤醒-昏昏欲睡-分心-吸烟-打哈欠-电话.zip”这样的资源时第一反应不该是“终于有数据了”而是先搞清楚这套数据到底在表达什么、边界在哪里、能不能直接拿来训。这篇文章就按实际落地顺序把数据集解读、标签处理、训练参数、踩坑点和推理优化一次讲透全程以YOLO系列为主聚焦到能直接照做的程度。2. 嗜睡数据集的真实结构先看标签再看图顺序不能反2.1 七个类别的语义边界比想象中模糊拿到zip解压后别急着开训练。先看labels目录下的txt标注文件和对应的jpg图像。这个数据集包含头部下垂head_drop、唤醒awake、昏昏欲睡drowsy、分心distracted、吸烟smoking、打哈欠yawning、打电话phone七个类别8979张图全部是YOLO格式的归一化坐标标注也就是每行“class_id x_center y_center width height”五位数结构。这里有个关键问题打哈欠和昏昏欲睡之间在图像上经常是同时出现的头部下垂和分心之间的边界也很模糊。如果直接按七分类去训模型会频繁在相邻类别之间震荡。实际落地做法是做个标签合并表语义相近的状态归到同一类一般合并成三类或两类疲劳状态头部下垂、打哈欠、昏昏欲睡、专注状态唤醒、干扰行为分心、吸烟、电话。这样既保留原始标签的粒度用于后续分析又让YOLO在工作时只输出一个 1×1 的关键判断误报率能明显下降。2.2 目录组织和验证集划分的平衡点很多下载来的数据集默认只有train和valid两个目录没有test。实际训练里我一般手动再拆分一部分样本做最终评估比例控制在 0.050.1 之间太少了评估结果波动大。但拆的时候要注意必须按“人员ID”或“视频片段”来拆不能随机抽帧否则同一个人的相似姿态会同时出现在训练集和测试集里mAP虚高上真实场景立刻露馅。另外一个隐藏问题是图片尺寸和宽高比。驾驶场景截图多半是16:9的横图部分样本可能做过缩放或裁剪。YOLO训练时resize到640×640会把横向拉变形解决办法是在训练配置里开启letterbox也就是保持宽高比填充灰边而不是强行拉伸。这个参数在ultralytics里默认开着但用其他框架复现时要手动确认。# 统计数据集宽高比分布判断需不需要强letterbox import os from PIL import Image img_dir 嗜睡数据集/images/train ratios [] for f in os.listdir(img_dir): if f.endswith(.jpg): w, h Image.open(os.path.join(img_dir, f)).size ratios.append(w / h) import numpy as np print(宽高比均值:, round(np.mean(ratios), 2)) print(宽高比p95:, round(np.percentile(ratios, 95), 2)) print(最高/最矮:, round(np.max(ratios), 2), round(np.min(ratios), 2))这段代码的作用是摸清数据的画像。如果95%的图宽高比都在1.5以上说明这套数据以横构图为主训练时输入尺寸可以偏向 640×384 或 640×416速度更快减少填充浪费。如果分布很散横竖都有那说明来源复杂老老实实用640×640加letterbox。2.3 类别不平衡的现实权重七类样本数大概率不是均匀的唤醒和分心这类容易采集的状态数量多头部下垂和打哈欠这类真正关键的疲劳状态反而少。直接训的话模型会把高频类学得更好而实际部署时最怕的就是疲劳状态漏报。处理方式有两个一是用YOLO自带的class weightsultralytics里可以直接传--class_weights参数让loss按类别稀疏程度加权二是做简单数据增强对头部下垂和打哈欠这两个关键类做两倍以上的mosaic增强等效增加样本参与度。优先用第一种改动小、收敛快第二种留到过拟合明显时再上。3. 从zip到可训练格式标注校验与统一路径3.1 检查标注文件有没有“脏数据”下载的数据集标注质量参差不齐最常见的脏数据有三种某些txt文件里坐标超出01范围但不能删可能是标注工具导出时没归一化干净某些框宽高为0说明标注时手滑了还有一类是类别ID越界比如明明只有7类txt里却出现了编号7或8。这些脏标注不清理训练时轻则loss震荡重则直接崩。# 找宽高为0或坐标越界的标注文件 find . -name *.txt -path *labels* | while read f; do awk { if ($30 || $40 || $50 || $60) print FILENAME: $0 } $f done这条命令只排查明显的非法值。跑完后如果输出很多说明这批标注整体比较糙建议写个Python脚本统一过滤并统计而不是手工修。修的时候也注意不要只删行要看这个图里剩余目标够不够只剩一个框且还是小目标的可以直接删图省得训练时浪费算力。3.2 YAML配置文件一次性写好YOLO训练前要把数据集的yaml配置好包括路径、类别名和类别数。这里特别强调路径写法用绝对路径最省心少碰相对路径的软链接问题。# sleep_dataset.yaml path: /data/sleep_dataset # 数据集根目录 train: images/train val: images/valid test: images/test names: 0: head_drop 1: awake 2: drowsy 3: distracted 4: smoking 5: yawning 6: phone类别顺序要和labels目录里txt标注的ID严格对齐。很多数据集附带的names文件可能排序混乱最常见的是类别清单按字母排序而不是按训练顺序。第一次训练前要抽几张图把yolo格式反向绘制成框看一眼人工核对类别号和语义是否匹配。这一步花10分钟能省掉训练三天后发现标签映射错了的崩溃。3.3 图像与标注文件数量一致性核对zip解压后的数据集经常出现jpg和txt数量对不上的情况原因不外乎解压中断、网盘传输文件损坏。YOLO训练遇到标注缺失通常是隐性的——图像可以正常载入只是没目标可学模型对该图的输出就会偏向背景类与周围样本互相矛盾。# 对比图像目录和标注目录的文件名集合 ls images/train | sed s/.jpg$// | sort /tmp/img_list.txt ls labels/train | sed s/.txt$// | sort /tmp/lbl_list.txt comm -23 /tmp/img_list.txt /tmp/lbl_list.txt | head -20多出来的就是缺少标注的图片直接移到unlabeled目录别留在训练集里。反过来标注多而图片少的情况比较少见但真要遇到检查是不是重复文件名覆盖或zip分包解压时的目录合并问题。4. 用YOLO训练嗜睡检测从模型选型到参数调优4.1 选YOLOv8n还是YOLOv11n关键看部署设备嗜睡检测的部署场景多半是车内边缘盒子、工位一体机这类算力有限的设备不是云服务器。这时选模型的标准就不是“精度最高”而是“在设备能跑满实时帧率的前提下精度可接受”。YOLOv8n参数量3.2MYOLOv11n更轻但精度也略低。如果设备是Jetson Nano或RK3588级别选YOLOv8n更稳妥训练快、部署资料多、TensorRT转换踩坑少。如果设备是Jetson Orin或独立显卡可以试YOLOv11s或YOLOv8s。另一个常被忽略的点是“efficient head yolo”也就是对YOLO检测头做轻量化改造的思路嗜睡检测的目标类别少且都是单一人体部位输出层通道数可以适当裁剪只保留两个检测头而不是三个省下的推理时间能换出路的裕量。4.2 训练命令的合理默认值与为什么是它们用ultralytics训练这套数据我一般这样起手yolo train \ datasleep_dataset.yaml \ modelyolov8n.pt \ epochs100 \ imgsz640 \ batch32 \ workers8 \ optimizerAdamW \ lr00.001 \ lrf0.01 \ mosaic1.0 \ close_mosaic10 \ cos_lrTrue \ patience20逐项说明意图imgsz用640是精度和检测小目标能力的平衡点再大对小目标检测有提升但推理变慢batch32在单卡RTX 3090级别能跑满显存optimizerAdamW配合低学习率对中等规模数据集比SGD收敛更稳不容易在后期震荡mosaic增强开着但是最后10个epoch自动关闭这是为了让模型在最后阶段适应未经强变换的原始分布patience20防止loss长时间不降还继续空跑。4.3 训练过程中的实读指标训练中别只看mAP嗜睡检测真正要盯的是“唤醒误判成疲劳”和“疲劳漏判”这两个方向。tensorboard或ultralytics的输出里重点看验证集上head_drop、yawning这两个类的precision和recall曲线。如果precision高但recall低说明模型只挑有把握的疲劳特征容易漏如果recall高但precision低说明模型把很多正常状态也报成了疲劳。理想平衡点设在recall 0.85以上且precision不低于0.7。真到调优这一步时优先动的是置信度阈值而不是重新训练。训练结束后用yolo val跑一遍验证集把conf_thres从0.25往下扫记录每个阈值下这两类的指标变化选择一个误报可接受且recall最高的点做部署配置。4.4 损失函数的理解深度决定你能调的层数YOLO的loss由三部分组成box_loss定位、cls_loss分类、dfl_loss分布焦点损失。嗜睡检测这种单人多状态场景里cls_loss的权重影响最大。很多框架允许通过cls_pw调整正负样本权重实际操作时这个参数可以在类别不平衡明显时从默认1.0调整到1.52.0帮助模型更关注疲劳状态的少数类。但调太高会让模型整体趋向把背景也判成目标这时就得同步提高背景类的负样本权重。这些参数没有万能配方只能在第一批训练完成后根据PR曲线反馈来微调。5. 嗜睡检测模型训练避坑5个真实翻车记录与处理方案5.1 目标太小模型什么都学不到现象训练出的模型对头部区域完全没有响应loss降至0.5左右就再也不动了。原因数据集里很多标注框是半身或全身框头部只占框内很小区域YOLO的anchor机制对这种小目标不敏感。解决先按标注框中心点切出头部区域用裁剪后的图重新训练一个专门检测头部的模型再和全身模型串行推理。这一步对打哈欠检测尤其有效因为打哈欠的特征嘴部张开的形状在全身图上只有几个像素模型根本看不见。5.2 标签类别号不对齐现象训练时ids越界报错或者某几类精度特别差。原因zip里的txt文件可能是从不同标注批次合并的前一批txt里的类别顺序和names文件不一致。解决写一个映射脚本把所有txt里的类别ID替换成统一命名顺序。这里尤其要小心程序里的0和1混用很多标注工具是从1开始的而YOLO要求从0开始检查这一步往往能救回一半的精度。5.3 训练集验证集混入同一人的相似姿态现象mAP高到0.95以上但现场一测惨不忍睹。原因随机的图像级划分让同一个人的连续帧同时落进train和val模型相当于记住了测试答案。解决改成人ID级别划分每个人员的所有画面全部进训练集或验证集。这是嗜睡检测领域最隐蔽的数据泄漏场景不按人物拆分的验证结果没有任何部署参考价值。5.4 打哈欠动作被判定为正常张嘴说话现象conf很高但判定类别错误。原因打哈欠标注在侧脸图上无法区分很多侧脸打哈欠的图在标注阶段其实被标成了“唤醒”或“昏昏欲睡”。解决从训练数据里挑出侧脸图人工复核一遍打哈欠和说话的标注必要时增加正脸打哈欠样本。如果数据集不够就补少量关键帧标注别多一张图50个框以内足够。5.5 手机遮挡原因导致的错误检测现象打电话这个类别会频繁触发不论是否真的在打。原因手靠近脸部的通用动作被抽成了局部特征模型把“手脸”当成了“打电话”喝水和擦汗也触发。解决增加“手里没拿东西但手靠近脸”的负样本或在后处理里加时间序列滤波连续3帧以上检测为同一状态才算触发。后者对视频流检测几乎是刚需单帧判断的可靠性太低。6. 部署验证与推理优化验证集是给电脑看的真车才是给你看的6.1 TensorRT导出前的量化检查嗜睡检测的部署大多逃不开TensorRT加速但FP16量化对疲劳状态这种“小目标弱特征”的任务伤害明显。导出前先在验证集上对比FP32和FP16的mAP差额如果drop超过1%就改用FP16INT8混合量化或者干脆保持FP32只做层融合。这是血泪经验RTX设备上FP16确实快但精度变化不跑一遍量化感知训练基本控制不住。6.2 用时间上下文消抖才是真干活单帧检测在真实场景里没法直接用。一帧里头部下垂可能只是驾驶员在低头看仪表盘。部署时要做滑窗投票3秒窗口内检测结果投票决定当前状态也可以做轻量级状态机只有连续3帧进入疲劳状态才上报。这样同时压掉“打哈欠检成昏昏欲睡”和“低头瞬间检成分心”两类问题误报从每小时几十次降到个位数。6.3 场景适应性这套数据上车前必须要做的增量补标公开数据集永远无法覆盖你实际部署环境的光线、摄像头角度、遮挡物和使用者的样貌分布。所以拿到这套数据训练出一个baseline之后用自己的摄像头录3060分钟真实场景视频抽帧补标200300张图做一轮增量训练epochs30~50学习率调低到1e-4级别。这个步骤不是sop但凡是做过实车部署的人都知道没有这套本地化的增量数据公开数据的模型在真实场景里的表现就是黑匣子好坏全凭运气。6.4 从结果反噬训练验证集的指标陷阱验证集上的平均精度只是启动条件之一不是说过了0.9就能发版。真正能证明模型能上线的是断点录制的连续视频用人工标注的关键片段做精确率、召回率、误触发率三个指标衡量每天不同时段各测一次。我习惯的做法是设计一个最简单的5分钟验收脚本让测试者分别做正常驾驶、频繁查看手机、假装打哈欠、低头捡东西四种动作各一分钟统计出误报次数和漏报次数这个数字比任何mAP都更能反映真实体验。这套“数据→训练→验证→增量→验收”的路径走下来嗜睡检测模型算是脱离了玩具阶段。最后给自己留一句数据集的加载和解析永远是项目中看似最不起眼、实际最决定上限的环节。真正做出稳定的疲劳预警靠的往往不是模型层面的神通而是把这些脏活累活都耐着性子做完。希望这些踩坑记录能帮你少走几轮弯路。本文还有配套的精品资源点击获取