基于YOLO的疼痛检测数据集构建与训练实战指南

1. 疼痛检测数据集项目整体设计与思路拆解

1.1 为什么疼痛检测值得单独做一个数据集

疼痛检测这个方向，在医疗健康与计算机视觉的交叉地带里，属于那种“听起来小众、做起来真香”的题目。它的核心任务，是让模型从图像或视频中识别出人或动物是否处于疼痛状态，以及疼痛的程度。这件事在临床护理、术后监护、动物福利、婴幼儿照护等场景里都有非常实际的价值——因为疼痛这件事，患者自己说不清楚的时候太多了，尤其是婴幼儿、认知障碍老人、不会说话的动物，全靠护理人员肉眼观察，主观性强、容易漏判。

我最初接触这个方向，是因为一个做养老监护的朋友提到，夜班护工要同时盯十几个房间的监控画面，根本看不过来，老人术后疼痛蜷缩的姿势经常被忽略。这就让我意识到，疼痛检测本质上是一个目标检测问题：从画面里定位到人体（或面部、肢体），再判断其姿态和表情是否呈现疼痛特征。而YOLO系列作为目标检测里落地最成熟的方案，天然适合承接这类任务。

这个数据集规模定在2200张，是一个很务实的量级。太小（几百张）训不出泛化能力，太大（几万张）对个人开发者和中小团队来说标注成本吃不消。2200张配合YOLO的迁移学习，在单卡消费级显卡上就能跑出可用的效果，这是它最吸引人的地方。

1.2 数据集的核心构成与标注逻辑

疼痛检测数据集和普通的目标检测数据集最大的区别，在于它的类别定义。普通检测数据集标的是“人、车、狗”，而疼痛检测标的是“疼痛状态”。这里就有个关键设计选择：是按二分类（疼痛/不疼痛）标，还是按多级疼痛强度标？

从2200张这个规模来看，我倾向于采用分层标注策略：主类别用二分类保证样本量充足，同时用附加属性记录疼痛等级（如轻度、中度、重度）。这样既保证了YOLO训练时每个类别的样本不至于太稀疏，又保留了后续做细粒度分析的空间。实际标注时，边界框通常落在面部区域或整体躯干区域——面部适合做表情层面的疼痛识别，躯干适合做姿态层面的识别，两者可以分开建子集。

标注工具方面，主流的就是LabelImg、Labelme、CVAT这几款。LabelImg适合纯矩形框，操作简单，生成的YOLO格式txt直接可用；CVAT适合团队协作，支持视频逐帧标注，做疼痛视频素材时更顺手。我个人的习惯是：静态图用LabelImg快速过一遍，视频抽帧的用CVAT，因为它的插值功能能省掉大量重复劳动。

1.3 为什么选YOLO而不是其他检测框架

这个问题我被问过很多次。疼痛检测场景对实时性的要求其实很高——监护场景需要秒级甚至更快的响应，两阶段检测器（如Faster R-CNN）虽然精度不错，但推理速度在边缘设备上很难达标。YOLO的单阶段设计天然占优，一次前向传播就出结果，部署到RK3588这类边缘芯片上也能跑到可用帧率。

另一个原因是YOLO的生态成熟度。从YOLOv5到YOLOv8、YOLOv11，再到社区里讨论的更新版本，预训练模型下载、训练脚本、部署工具链都非常完整。你不需要从零搭轮子，改改配置文件就能开跑。对于医疗健康这种“快速验证想法”比“追求极致精度”更重要的领域，YOLO的性价比是最高的。

还有一点容易被忽略：YOLO的损失函数设计对类别不平衡比较友好。疼痛样本在真实数据里往往是少数（大部分时间人是正常的），YOLO的分类损失和定位损失分开计算，配合数据增强，能缓解正负样本失衡的问题。这一点在2200张这种中小规模数据集上尤其关键。

2. 核心细节解析与实操要点

2.1 数据采集与预处理的关键细节

2200张图从哪来，直接决定了数据集的质量上限。疼痛检测的数据来源大致分三类：公开医疗影像库、合作机构授权数据、自采数据。公开库能拿到的主要是面部表情类（比如一些疼痛表情数据库），但姿态类的公开数据很少，需要自己补。

采集时有个坑我必须提前说：疼痛表现具有强烈的个体差异和场景依赖。同一个人，躺着和坐着、白天和晚上，疼痛时的姿态可能完全不同。所以采集时要刻意覆盖不同光照、不同拍摄角度、不同身体姿态。我建议按“场景×姿态×光照”做一个粗略的矩阵，每个格子至少保证几十张，避免模型学到“只要躺着就是疼痛”这种伪相关。

预处理环节，YOLO对输入尺寸有要求（常见的是640×640）。直接resize会改变长宽比，导致人体变形。我的做法是letterbox填充：保持原图比例缩放，空白处用灰边补齐。这样既不丢信息，也不引入形变。另外，医疗场景的图像往往偏暗或偏亮，做一次自适应直方图均衡化（CLAHE）能明显提升对比度，对后续检测有帮助。

2.2 标注规范与质量控制

标注是数据集项目里最耗人力、最容易出问题的环节。疼痛检测的标注难点在于边界模糊：一个人皱眉、蜷缩，到底算不算疼痛？不同标注员的理解可能差很多。

我的解决方案是制定一份标注手册，把疼痛的判定标准写清楚。比如：面部标注以眉毛下压、眼睑紧闭、鼻唇沟加深为参考特征；躯干标注以护住某部位、身体蜷曲、肌肉紧绷为参考。手册里配上正例和反例图，标注员先做一轮试标，统一口径后再正式开工。

质量控制上，我采用双人交叉复核：每张图至少两个人标，不一致的挑出来由第三人仲裁。2200张听起来不多，但认真标下来，一个人一天也就标三四百张，双人复核意味着至少两周的工期。这个时间成本要提前算进去。

提示：标注时务必保留原始图像和标注文件的对应关系，建议用“图像名=标注文件名”的命名规则，避免后期训练时找不到标签。

2.3 YOLO训练配置的核心参数

拿到标注好的数据，下一步就是配置训练。以YOLOv8为例，数据集目录结构要按它的要求组织：images和labels分开，train/val/test三个子集。2200张的划分比例，我一般用7:2:1，即训练1540张、验证440张、测试220张。如果疼痛样本本身很少，验证集可以适当缩小到15%，把更多数据留给训练。

关键参数里，学习率和batch size最影响结果。单卡训练时，batch size设16或32比较稳，学习率用余弦退火从0.01降到0.0001。如果发现训练中BN层崩溃（这是YOLO训练里常见的问题），八成是batch size太小或者学习率太高，把batch调大、学习率调小通常能解决。

数据增强方面，疼痛检测要慎用垂直翻转——人倒过来在现实里几乎不出现，翻转后反而引入噪声。水平翻转、随机裁剪、色彩抖动是安全的。Mosaic增强能提升小目标检测能力，但如果疼痛区域本身就是大目标，Mosaic可能把目标切得太碎，这时候可以降低它的使用概率。

3. 实操过程与核心环节实现

3.1 从零搭建训练环境的完整流程

环境配置是新手最容易卡住的地方。我按最省事的路径走一遍：先装Anaconda管理Python环境，建一个Python 3.9的虚拟环境（3.9对YOLO各版本的兼容性最好）。然后装PyTorch，注意要跟CUDA版本对应——如果你用的是V100这类卡，CUDA 11.x配PyTorch 1.13或2.0都行。

conda create -n pain_yolo python=3.9 conda activate pain_yolo pip install torch torchvision --index-url https://download.pytorch.org/whl/cu118 pip install ultralytics

装完ultralytics后，用yolo checks命令验证环境，它会打印出PyTorch版本、CUDA是否可用、GPU型号等信息。这一步过了，后面就顺了。

数据集配置文件（data.yaml）要写清楚路径和类别：

path: ./pain_dataset train: images/train val: images/val test: images/test nc: 2 names: ['no_pain', 'pain']

3.2 训练过程与关键节点记录

启动训练的命令很简洁：

yolo detect train data=data.yaml model=yolov8n.pt epochs=100 imgsz=640 batch=16

这里选yolov8n（nano版）是有考虑的：2200张的数据量，用大模型容易过拟合，nano版参数量小、训练快，先跑通流程看效果，不够再换s或m版。实测下来，nano版在V100上跑100轮大概两三个小时，速度可以接受。

训练过程中要盯几个指标：box_loss（定位损失）和cls_loss（分类损失）是否稳定下降，mAP50和mAP50-95是否在涨。如果box_loss降但cls_loss不降，说明定位学得不错但分类分不开，可能是类别定义太模糊，要回去检查标注。如果两个都不降，先查学习率是不是太大。

我踩过的一个坑是：训练到三四十轮时mAP突然掉下去，查了半天发现是验证集里有几张标注错误的图，模型被带偏了。所以训练前一定要抽查验证集标注，别偷这个懒。

3.3 模型评估与混淆矩阵解读

训练完，YOLO会自动生成混淆矩阵和PR曲线。混淆矩阵是判断模型到底“错在哪”的关键工具。疼痛检测里，最常见的错误是把“不疼痛”误判成“疼痛”（假阳性），这在监护场景里会导致护理人员频繁误报，用久了就不信任系统了。

如果假阳性高，说明模型对疼痛特征过于敏感，可以适当提高置信度阈值，或者在训练时增加“不疼痛”样本的权重。反过来，如果假阴性高（漏报疼痛），那问题更严重，需要补充更多疼痛样本，尤其是轻度疼痛的样本——轻度疼痛最难标也最难学。

注意：混淆矩阵的数值总和有时会对不上，这通常是因为部分预测框的IoU没达到匹配阈值，被算作背景了。这不是bug，是正常的匹配逻辑，不用慌。

4. 常见问题与排查技巧实录

4.1 训练不收敛与BN崩溃的排查

BN崩溃是YOLO训练里出现频率很高的问题，表现是loss突然变成NaN。根因通常是batch size太小导致batch内统计量不稳定。解决办法按优先级排：先把batch size调到16以上；如果显存不够，改用梯度累积模拟大batch；再不行就把BN换成GroupNorm，虽然会损失一点精度，但稳定性大幅提升。

另一个不收敛的常见原因是学习率预热没做好。YOLO默认有warmup，但如果你改了优化器或学习率策略，warmup可能失效。手动加几轮线性预热，让学习率从很小的值慢慢升上去，能明显改善初期震荡。

4.2 小目标与遮挡场景的检测优化

疼痛检测里，面部区域相对整张图往往偏小，属于小目标检测。提升小目标效果有几个实用手段：一是提高输入分辨率，从640提到1280，小目标像素多了自然好检；二是用P2层特征图（YOLOv8支持），它保留了更高分辨率的特征；三是数据增强里多用随机缩放，让模型适应不同尺度的目标。

遮挡问题在监护场景很常见——被子盖住半个身子、输液管挡住脸。应对遮挡，除了增加遮挡样本外，可以引入注意力机制改进，比如在backbone里加CBAM模块，让模型聚焦可见的疼痛特征区域。这类改进在社区里有很多现成实现，改几行配置就能用。

4.3 部署到边缘设备的注意事项

训练好的模型最终要落地。如果部署到RK3588这类边缘芯片，需要先把PyTorch模型转成ONNX，再转成芯片支持的格式。转换时要注意算子兼容性，YOLO里的一些自定义算子可能不被支持，需要替换或重写。

部署后帧率不达标的话，优先做输入分辨率降级和模型量化。INT8量化能把推理速度提升两三倍，精度损失通常在可接受范围内。但量化后一定要重新在测试集上评估，确认疼痛检测的召回率没掉太多——医疗场景里，漏报的代价比误报高得多。

5. 数据集扩展与项目迭代方向

5.1 从静态图到视频流的延伸

2200张静态图能训出一个可用的基线模型，但真实监护场景是视频流。从静态到视频，最直接的做法是抽帧标注：按每秒1到2帧抽，保证相邻帧之间有变化但不冗余。视频标注的难点是时序一致性——同一个人连续几秒的疼痛状态应该标成一致的，不能这帧标疼痛、下帧标不疼痛。

更进阶的做法是引入时序模型，比如在YOLO检测结果后面接一个LSTM或Transformer，综合多帧信息判断疼痛状态。这样能过滤掉单帧的误检，提升整体稳定性。社区里已经有YOLO+Transformer结合的工作，思路可以借鉴。

5.2 多模态融合的可能性

疼痛检测如果只靠视觉，天花板是有限的——有些人疼痛时表情和姿态变化都不明显。引入多模态信息是突破方向：比如结合红外热成像（疼痛区域往往有温度变化）、结合心率呼吸等生理信号。电力红外数据集里那种VOC/YOLO格式的处理经验，在这里可以复用。

多模态融合的工程复杂度不低，建议先把单模态做到位，再考虑加模态。融合方式上，早期融合（特征拼接）和晚期融合（决策投票）各有优劣，中小项目从晚期融合入手更稳妥，因为各模态可以独立训练、独立调试。

5.3 持续学习与数据闭环

医疗场景的数据分布会随时间漂移——新来的患者、新的护理流程、新的拍摄设备，都会让模型效果下降。建立数据闭环很重要：把模型在实际使用中判错的样本收集起来，人工复核后加入训练集，定期重新训练。2200张是起点，不是终点。每轮迭代补充几百张难例，模型就能持续进化。

这个闭环里，难例挖掘是关键。简单说就是让模型对未标注数据做预测，挑出置信度低或预测不一致的样本优先标注。这样标注的人力花在刀刃上，数据效率最高。

6. 我个人的实操体会

做疼痛检测数据集这段时间，最大的感受是：数据质量比模型结构重要得多。我试过用同样的YOLOv8配置，在一份标注粗糙的数据集上mAP只有0.5出头，换到精标数据集上直接到0.75。模型没变，变的是标注的一致性和边界的准确性。

另一个体会是，别一上来就追求大而全。2200张先跑通二分类，把流程走顺，再考虑加疼痛等级、加多模态。很多项目死在“想一步到位”上，配置越堆越复杂，最后连基线都跑不出来。

最后分享一个实用技巧：训练时把验证集的预测结果可视化存下来，每轮看几张。比看loss曲线直观得多，能一眼看出模型是“没学会”还是“学歪了”。这个习惯帮我省了大量排查时间。