聊一个医疗健康场景下的CV落地项目：疼痛检测数据集。说白了就是拿2200张带标注的图片，用YOLO类模型训练一个能识别疼痛相关面部表情或肢体姿态的检测器。这类项目的难点从来不在模型本身，而在数据标注的一致性、场景覆盖的充分性、以及类别定义的清晰度。我前前后后做过几个类似的医疗影像检测项目，今天把这套东西完整拆开聊一遍，从数据整理到训练调参再到部署导出，把能踩的坑提前说出来，省得后面的人再走一遍弯路。

1. 疼痛检测数据集的项目背景与数据拆解

1.1 这个数据集解决的是什么问题

疼痛检测听起来有点抽象，但在临床和护理场景里是非常实际的刚需。术后病人疼不疼、ICU里无法言语的患者状态如何、康复训练时动作是否超出耐受范围，这些情况目前主要靠护士巡房观察或患者自评量表，主观性强、连续性差。如果有一个系统能自动从监控画面里判断患者的疼痛状态，既能减轻护理压力，也能为医生提供客观参考。

这里有个关键点：疼痛检测本质上不是“分类任务”，而是“定位+分类任务”。模型不仅要判断画面里的人在不在疼痛状态，还得告诉你在画面的哪个位置、是面部表情还是肢体动作体现的疼痛。这正好是YOLO这类目标检测器的强项。2200张图像配好标注之后，训练一个端到端的检测模型，输入的是原始画面，输出的就是带有置信度的检测框和类别。

所以这套数据集的定位很明确：它不是学术研究用的几万张大规模数据集，而是面向实际落地验证的中等规模数据集。适合做原型验证、算法选型、以及给刚接触YOLO的团队练手。

1.2 2200张图为什么是“够用但不宽裕”的规模

很多人一看到2200张就觉得少，尤其现在动辄几万张的数据集满天飞。但医疗场景的数据采集成本摆在那里：要获得合规的、涉及人体姿态的影像数据，需要伦理审批、患者知情同意、数据脱敏，采集周期按周甚至按月算。2200张已经是经过筛选和清洗之后的规模，不是原始拍摄量。

这个规模在实际训练中是什么水平？以YOLOv8n为例，COCO预训练权重做迁移学习，单卡训练不考虑复杂增强的情况下，2200张图大概几分钟一个epoch。训练集约1700张左右，验证集和测试集各取200多张，跑50到100个epoch，半小时以内就能完成一轮完整实验。这个迭代速度非常关键，它能让你快速验证标注质量、类别平衡度和模型选型是否合理。

但如果想达到更理想的泛化效果，2200张确实偏紧，必须配合数据增强、预训练迁移和外部辅助数据来补。尤其是疼痛状态在真实场景中往往只出现在少数几帧，容易出现类别严重不均衡，这个我在后文第4节会专门讲处理思路。

1.3 标注格式与标签设计：YOLO数据集的“地基”

YOLO系列用的标注格式是每个图像对应一个同名txt文件，每行代表一个目标框，格式为：类别编号 + 归一化中心点x + 归一化中心点y + 归一化宽度w + 归一化高度h。所有坐标都是相对图像宽高的比例值，取值范围0到1。

这套格式最大的优点是简单，缺点是直观性差。我第一次接触的时候总忍不住想换算回像素坐标，后来直接用标注工具导出YOLO格式就舒服多了。LabelImg、X-AnyLabeling、Roboflow都支持直接导出YOLO格式。我自己习惯用X-AnyLabeling，它支持半自动标注，对视频抽帧数据能省不少人工框选的功夫。

标签类别怎么设计，是这类项目里最容易被低估的问题。以疼痛检测为例，最朴素的做法是单类别“pain”，但实际训练你会发现问题很多：模型根本分不清是“疼痛表情”还是“正常皱眉”，会把所有面部框都高概率判定为疼痛。我建议至少分三个类别：

• pain_face：疼痛相关的面部表情（皱眉、咧嘴、闭眼扭曲等）
• pain_posture：疼痛相关的肢体姿态（蜷缩、抱腹、异常僵直等）
• normal：日常正常表情或姿态

多类别设计有两个好处：第一，模型被迫学习区分“疼痛”和“非疼痛”的边界特征；第二，推理阶段可以分别统计面部和肢体两个通道的置信度，后续做决策逻辑时更灵活。

2. YOLO模型选型与训练前置准备

2.1 为什么选YOLO而不是分类网络或关键点检测

先掰扯一下方案选型。很多人遇到“疼痛检测”第一反应是做人脸表情分类，或者用关键点检测模型分析面部肌肉运动。这两种方案都能做，但各自有软肋。

纯分类网络的问题在于没有空间定位能力。病房里可能同时有多个人，摄像头拍到的是一整个场景，分类网络默认输入是“已经裁好的单人图像”，这就导致你要先做一个人体检测的前置步骤，相当于自己拼一个两段式pipeline，工程复杂度上去了，实时性还打折。

关键点检测方案更精细，能输出面部关键点坐标，配合规则判断表情状态，听起来很美。但实际做起来你会发现，关键点模型对图像质量要求高，监控摄像头角度一偏、距离一远，关键点就飘了。而且疼痛姿态很多时候不是靠面部关键点能表达的——手臂抱紧、身体蜷缩这类动作，关键点方案也得再叠加人体姿态估计模型，两个模型协同部署的复杂度直接起飞。

YOLO这种目标检测方案的好处是端到端：输入原始画面，输出检测框和类别。多人场景天然支持，面部框和肢体框分开检测，置信度还能直接用于后续判断逻辑。实时性能也够，YOLOv8n在普通GPU上跑几百帧每秒，边缘设备上也能跑到30帧以上。对一个7x24小时监控场景来说，这个选型是最务实的选择。

2.2 模型规格怎么选：n、s、m、l、x五档怎么取舍

YOLO系列每个版本基本都按模型深度和宽度分成n/s/m/l/x等规格。不要一上来就选最大的，我在这个项目里用YOLOv8n和YOLOv8s都做过实验，两者在验证集上的mAP差距不到2个点，但推理速度差了将近一倍。

原因很简单：数据量只有2200张，小模型参数少，反而更不容易过拟合。大模型在这个规模下不会带来质的提升，只会让你在训练时候更焦虑——一跑就是几十分钟，调参都不方便。

我给的选型建议是：先跑n模型做baseline，确认标注和训练流程没问题后再试s模型。如果精度确实有缺口，优先排查数据和标注问题，不要急着上l或x。数据不到位的情况下，大模型只是把一个错误拟合得更彻底。

2.3 预训练权重与迁移学习

YOLO预训练权重下载是很多新手卡住的第一关。YOLOv8用ultralytics库训练的时候，如果不指定weights参数，它会自动下载COCO预训练权重。国内网络环境下下载可能时断时续，我一般提前用脚本手动下载好对应版本的预训练权重，放到项目目录里再指定路径。

迁移学习的正确打开方式是分两阶段：

• 第一阶段：冻结backbone，只训练检测头。这时候模型是在快速适应新的类别定义和标注分布，学习率控制在较小范围。
• 第二阶段：解冻全部层，用更小的学习率对整个网络微调。这个阶段让backbone的底层特征也适应医疗场景的图像风格。

实测下来这个策略比从头训到底的效果稳定得多。从头训你很容易遇到梯度振荡、损失不下降的问题，不是因为你代码写错了，而是2200张图根本不足以让backbone从头学到足够好的底层特征。

3. 从数据整理到模型训练全流程实操

3.1 数据目录结构的标准组织方式

ultralytics框架对数据集目录结构有约定，虽然不是强制，但按它的约定来最省事。我的标准目录长这样：

pain_dataset/ ├── images/ │ ├── train/ │ │ ├── 000001.jpg │ │ ├── 000002.jpg │ │ └── ... │ ├── val/ │ └── test/ ├── labels/ │ ├── train/ │ │ ├── 000001.txt │ │ ├── 000002.txt │ │ └── ... │ ├── val/ │ └── test/ └── data.yaml

这里有一个容易踩的坑：图像文件和标签文件的文件名前缀必须一一对应，如果一张图没有对应目标，标签文件也应该存在，只是内容是空的。漏掉空标签文件会导致ultralytics在加载数据时报索引错误，别问我是怎么知道的。

3.2 标注格式转换与校验脚本

如果你的原始标注是其他格式（比如VOC的xml、COCO的json），需要先转成YOLO格式。转换脚本网上很多，但我在实际使用中发现很多开源脚本对边界情况处理得不够干净。比如坐标超出图像边界、类别id越界、宽度或高度为负数这些情况，需要全员核查。

我习惯在训练前写一个校验脚本，遍历所有标签文件，检查：

• 坐标值是否都在0到1范围内
• 框的宽高是否大于0
• 类别id是否在数据集类别列表内
• 是否有标签文件对应不上的图

这一步看起来繁琐，但能帮你省下好几次无效训练。4000张以内的数据量，校验脚本跑完也就几秒钟。

3.3 data.yaml配置与训练命令

data.yaml是整个训练的配置文件，核心内容如下：

train: pain_dataset/images/train val: pain_dataset/images/val test: pain_dataset/images/test nc: 3 names: ['pain_face', 'pain_posture', 'normal']

nc是类别数量，names是类别名列表，顺序必须和标注文件里的类别id严格一致。顺序一旦错了，模型会把pain_face训练到pain_posture的标签上，出来的结果整个乱套。

训练命令我常用的是：

yolo train model=yolov8n.pt data=pain_dataset/data.yaml epochs=100 imgsz=640 batch=16 device=0

这里几个参数值得解释一下。imgsz设为640是YOLO系列的默认训练尺寸，也是速度和精度的平衡点。batch大小取决于显卡显存，16在大多数GB级别显存下都能跑。epochs先设100，后面根据验证集损失变化再调整。

3.4 损失函数与训练参数怎么理解

关于YOLO损失函数，很多人看到loss曲线里三个分量的波动就懵了。YOLOv8的损失由三部分组成：

• box_loss：边界框回归损失，衡量预测框和真实框的位置差异
• cls_loss：分类损失，衡量类别预测是否正确
• dfl_loss：分布焦点损失，用于优化边界框的定位精度

这三项在训练日志里会分开记录，最终总损失是它们的加权和。我判断训练是否正常，主要看box_loss和dfl_loss是否持续下降，cls_loss是否下降后保持稳定。如果cls_loss一直不降，急着加训练轮数没用，要回头检查类别标注是否混乱——大概率是某一类标注框里混入了明显不一致的样本。

训练参数里我最关注的是学习率。ultralytics默认的lr0=0.01对大多数场景够用，但你用预训练权重微调的时候，初始学习率可以调低一些，比如0.003，否则前几个epoch可能会看到损失不降反升的“回弹现象”。开了余弦退火后，学习率会在训练后期自动降到一个极低值，利好收敛稳定性。

4. 训练过程踩坑与调优实录

4.1 类别不均衡：疼痛帧永远是少数

真实采集的原始视频里，正常姿态占绝大多数，疼痛状态可能只在某个时间窗口出现。如果不处理，训练出来的模型会严重偏向正常类别——这其实是最常见的故障模式：验证集上mAP还挺好看，但拿到真实场景里一测，疼痛检出率低得吓人。

我的处理思路分三步走。第一，训练时给疼痛类别设置更高的类别权重，让模型在计算损失的时候对疼痛类别的错误分类更敏感。第二，对包含疼痛目标的图像做离线增强，比如小角度旋转、亮度扰动、随机裁剪，把疼痛样本的有效训练数量提上去。第三，如果条件允许，从原始视频里找一些真实的疼痛片段重新抽帧补标注，这是根治手段。

补数据这个事听着麻烦，但对医疗场景特别重要。合成增强做得再多，也不如几十张真实新场景的数据带来的泛化提升大。

4.2 小目标与遮挡：监控场景的老三样

疼痛检测的推理画面往往来自病房角落的摄像头，人物在画面里占比不大，面部区域尤其小。当目标框尺寸明显小于图像尺寸的十分之一时，YOLO在这些小目标上的表现就会开始衰减。

改善手段有几种。最直接的是调高输入分辨率，把imgsz从640升到960甚至1280，小目标的特征保留能力会明显增强，代价是训练和推理变慢。另一种手段是利用多尺度训练，ultralytics默认在训练时会动态调整输入尺寸，让模型在不同缩放尺度下都能学到特征。第三种手段是检查标注框是否贴近了目标的真实边界，如果标注框被画得过大，把背景都包进去了，模型学到的特征会被稀释。

遮挡问题更麻烦。病人侧躺时面部被手臂挡住一半、盖被子时身体轮廓模糊，这些情况很难靠模型本身解决。我的经验是标注时对有遮挡的样本单独处理：如果目标可见区域小于30%，直接不标；如果可见区域在30%到70%，标注真实可见部分的框，不要试图框出完整躯体。这么做能减少大量低质量拟合。

4.3 过拟合与数据增强的平衡

2200张图的小数据集天然有过拟合风险。判断是否过拟合有个简单粗暴的方法：训练loss还在下降，验证集loss已经拐头上升，mAP停滞甚至下滑，这就是过拟合的典型信号。

数据增强是正面战场。ultralytics默认开了马赛克增强、平移、缩放、翻转等操作。其中马赛克增强对这个小数据集特别有用——它能把四张图拼成一张，让模型在一个样本里看到更多样的上下文。马赛克增强在训练后期可以关掉或降低权重，因为它的样本分布和真实场景偏差较大，训练后期持续使用反而会影响收敛。

如果增强已经拉满还是过拟合，我就直接把epochs从100减到60，再加大衰减系数。tips：小数据集上weights_decay这个参数的作用比大数据集上显著，别忽略。

4.4 推理部署与模型导出注意事项

训练完的模型最终要部署到实际环境里。ultralytics的Python接口导出ONNX很成熟，命令行一行就能完成。但我提醒几个部署相关的细节：

第一，输入尺寸在导出时就要定好，不要训练一个640输入的模型部署时用1280输入，预处理的letterbox操作会把图像比例搞乱。第二，ONNX导出后建议用onnxruntime跑一遍推理，对比导出前后的类别预测结果是否一致，这一步能抓出很多模型结构上的细节错误。第三，如果你的部署环境是TensorRT，注意GPU架构的兼容性，TensorRT版本和显卡驱动版本有一系列的匹配约束。

推理阶段的置信度阈值设置也有讲究。默认0.25往往偏保守，疼痛检测场景我更推荐在验证集上绘制PR曲线，根据你实际能接受的假阳性率反推阈值。比如护理场景可以容忍一定的假阳性，那就把阈值调低到0.2左右；如果是自动触发镇痛泵的场景，就得把阈值调到0.5以上，宁错过勿误报。

5. 常见问题排查速查

训练YOLO数据集时遇到的很多问题，其实都有固定的排查套路。我把这个项目里实际遇到过以及同行交流中最常见的问题整理成了速查表，方便你训练的时候对照排查。

排查速度和科学素养同等重要。很多时候，问题出在数据而不是模型。先可视化一批训练样本的标注结果，把每个类别的标注框可视化出来看一遍，比盲目调参高效得多。我在每个项目开始前都会跑一个“标注可视化”步骤——把训练图随机抽200张，画上标注框保存成网格大图，整体扫一眼，基本就能确定是否有系统性标注错误。

一点个人心得

做疼痛检测数据集这个项目，我最大的体会是：一个好的数据集比一个好的模型值钱得多。2200张图看着不多，但如果你把标注质量做到极致——每个类别边界清晰、每个框贴合目标、每种场景都有覆盖——训练出来的模型效果会超过很多拿几万张粗糙数据硬训出来的结果。

如果你打算复现这个项目，建议按这个路线走：先拿YOLOv8n把baseline跑通，确认数据和流程没问题；再看一轮可视化标注，修正掉肉眼可见的脏数据；最后才考虑换更大的模型或调更复杂的增强策略。这套思路不止适用于疼痛检测，任何中小规模的YOLO数据集项目都能照搬。

最后分享一个偷懒但实用的技巧：训练完模型后，别急着看那些精确率召回率数字，直接找几段你压根没参与采集的真实视频跑一遍推理，把检测结果带置信度打印出来看看。模型在验证集上的表现再好，也不如实际场景里的“肉眼感觉”来得可靠，尤其是疼痛检测这种对误判容忍度极低的场景，真实感观验证永远是最重要的验收标准。