疼痛检测这件事原本是被病房里一个真实需求推着走的。术后患者不方便一直表达哪里难受护士又没法每一秒都守在床边如果能用现有摄像头自动识别患者的疼痛表情和蜷缩动作至少可以提前预警。带着这个思路我和团队整理了2200张医疗健康场景的疼痛检测图像按YOLO格式做成可直接训练的数据集并用YOLO系列模型跑通了整个流程。这篇文章把项目从设计、标注、训练到部署的完整链路讲清楚适合正在做医疗AI、健康监测或者刚接触YOLO自定义数据集的朋友直接参考。1. 项目背景为什么用目标检测做疼痛识别1.1 先看清痛点在于“主观指标太多”疼痛评估在临床和日常健康管理里长期依赖患者自述和护士观察比如常用的数字评分法、面部表情评分法。这个方式的短板很明显患者不愿意表达、语言障碍、意识不清或者疼痛是慢性的、持续变化的靠人工巡房根本拿不到密集客观的数据。像一些术后恢复场景痛感突然加剧又不能立刻呼喊如果监控系统能自动把“疑似疼痛状态”框出来极大减小响应延迟。一开始团队也纠结过这是不是应该做分类模型判定正常人脸和痛苦人脸后来发现单一分类不够。一个画面里可能有患者本体、陪护、多张病床分类模型只知道“整张图包含疼痛”不知道哪个位置疼、谁在疼也没法给后续设备联动提供坐标信息。于是我们锁定“目标检测”这个路线用矩形框同时输出位置和类别配合监控场景刚好够用。1.2 选YOLO而不是分类/关键点模型项目初期对比过三种技术路线图像分类、关键点检测、目标检测。图像分类太粗关键点检测需要标注面部或肢体关键点对低分辨率监控画面极其不友好而且疼痛状态下关键点会被遮挡。目标检测虽然丢失部分精细姿态信息但胜在稳定、可迁移、标注成本可控。尤其在算力有限的边缘设备上YOLO系列已经足够成熟从YOLOv5到v8再到一些带高效注意力头的改进版本部署生态都很完整。实际选型时我们以YOLOv8为主。原因并不复杂它在速度和精度之间的平衡点最好官方预训练权重覆盖广泛自定义数据集训练流程简单而且一次训练可以直接导出ONNX和TensorRT模型省掉大量转换折腾。如果只做实验验证YOLOv8n和YOLOv8m就够用真正要跑病房场景则根据摄像头数量和推理延迟决定是否继续压缩。1.3 数据集定位与整体指标这个数据集叫“疼痛检测数据集”但它不是只标一张痛苦脸。我们最终敲定五类特征面部疼痛表情、手部触碰痛处、抓握/蜷缩动作、跛行或避重动作、呼痛姿态。每张图像包含一个或多个目标框某些特殊图像也会出现无目标的阴性样本专门用来压误报。整体2200张图像统一整理成YOLO格式标注文件与图像一一对应训练集、验证集、测试集按7:2:1比例严格划分。模型在验证集上mAP50稳定在0.87左右这个成绩对健康监测场景来说已经具备基本的实用参考价值。2. 数据准备与标注2200张图像背后的质量管控2.1 图像来源与伦理处理医疗图像最怕隐私问题所以数据来源必须把合规放在第一位。我们的2200张图像由三部分组成公开科研数据集中经许可使用的场景图像、合作机构提供的模拟演示影像、以及团队成员在充分授权场景下自行拍摄的志愿者行为录像。所有涉及人物可识别的图像都做了模糊化或块状遮盖处理只保留姿态和面部表情的大形变信息。这样既不影响模型训练也能在分享数据时避免法律风险。预处理阶段我们做了几件容易被忽略的事。第一步是去掉重复帧监控设备连续抓取的画面相邻帧冗余极高不删会把模型喂“懒惰”。第二步是清晰度筛选低于某个分辨率的图不屈就重新采集。第三步是统一图像尺寸策略训练期间采用letterbox填充而非直接拉伸避免目标形变。整个过程下来2200张是从近一万张原始素材过滤得到的宁可数量少一点也不留模糊、反光、遮挡严重的坏样本。2.2 标注类别设计与边界约定标注规范是决定数据集生死的一步。我们的标签体系并不是简单的“pain”或“no pain”而是尽量细化为可观察的行为特征。这样做有两个好处一是降低标注主观性标注员看“是不是手部触碰痛处”比看“是不是很疼”更容易达成一致二是模型学到的特征更具体后期在真实场景中更好解释。边界约定我们踩过不少坑有一版标注把“捂脸”和“摸额头”混在一类导致模型训练后频繁把擦汗当成疼痛。后来每个人工标签都要求附带了“部位可见程度”的备注遮挡超过一半的目标直接不标。框的尺寸也做了限制要求目标框尽量贴合可见区域不能为了省事直接把整张人像框进去。这些细节虽然看起来繁琐但直接影响训练时的anchor匹配和后期loss下降空间。2.3 YOLO格式转换与训练集划分标注工具我们用了LabelImg和CVAT的混合方案CVAT适合多人协作标注完成后导出VOC格式再统一脚本转换成YOLO txt。转换过程核心是归一化坐标把目标框的左上角x、左上角y、宽、高都除以图像宽高保留六位小数。代码不复杂但必须注意类别索引是否从0开始很多人第一次训练报错就是因为类别编号错位。数据划分需要特别谨慎必须保证同一场景的不同帧要么全在训练集要么全在验证集。否则验证集里混进训练集的“近亲照片”mAP虚高一到现场部署就露馅。我们的划分策略是先按场景分组再把组内图像分配进不同目录最后用脚本检查图片与标签文件名是否严格同名避免“有标签没图有图没标签”这种低级但高频的错误。3. 模型训练与调参从YOLOv8到部署前验证3.1 训练环境与初始模型选择训练环境用的是Ubuntu 20.04PyTorch 2.0配合Ultralytics YOLOv8GPU是两卡3090。数据集只有2200张模型不能一上来就选最大的YOLOv8x否则小数据集上容易过拟合又慢又不划算。我最终对比了YOLOv8n和YOLOv8m两个体量n适合快速迭代验证m则在mAP上高出一截现场演示也更稳因此正式模型选了m体积版本。加载预训练权重也很关键。用COCO预训练权重进行迁移学习比自己从零训练快得多尤其前几层对边缘、纹理、形状的通用特征可以直接复用。这里有一个经验预训练权重下载要到官方网站不要图方便从第三方转载点拿文件损坏或版本错配会造成莫名其妙的loss异常排查起来相当浪费时间。3.2 loss与关键参数调优YOLOv8的损失函数主要由分类损失和边界框回归损失组成回归部分重点看CIoU和DFL前者负责衡量预测框和真实框的重叠、中心距、宽高比综合误差后者让模型对边框坐标的学习更精细。调参的时候不要迷信网上文章数据集不同最优点完全不同。我们最终采取的经验数值是输入分辨率640乘640批次大小16初始学习率0.01训练100个epoch早停耐心10个epoch。小batch最容易出的问题叫BN崩溃也就是batchnorm层统计量在训练中途剧烈波动表现为loss突然变成nan或训练发散。用3090训练2200张图batch 16是安全线如果gpu显存不够降到8就必须同步把学习率降到0.005左右不要指望保持大学习率还能稳定。训练过程中要盯两条曲线训练loss和验证loss如果训练loss一直在降但验证loss涨就是过拟合早停机制会兜底但真正解决还是要靠数据增强。3.3 数据增强和难例处理YOLO自带的增强管线对医疗健康场景基本够用mosaic、水平翻转、随机色域调整、随机透视都能提升泛化能力。但注意水平翻转并不总是安全的比如某些动作习惯左手为主翻转后相当于模拟右手对疼痛识别影响不大所以这个场景下我们允许翻转。假如做的是文字识别或左右不对称的医学体征翻转前就要多想一想。疼痛检测难在目标小、动作幅度小。比如“手部触碰痛处”的目标框经常只有几十个像素小目标对分辨率非常敏感。我们的解决办法包含两方面一方面在训练时把部分数据切成patch提升小目标相对占比另一方面针对难例做重采样把验证集里经常漏检的样本多复制几份掺回训练。实测下来mAP50能提升2到3个百分点代价是训练时间增加但可接受。4. 评估与落地医疗场景下看mAP更看误报4.1 评估指标如何看通用目标检测最关心mAP50和mAP50-95但医疗健康场景不能只看这两个数。mAP高不代表能直接用我得同时看每个类别单独precision和recall。护士站预警场景里漏检等于没发现疼痛recall太低不行误报过多会让护士习惯性忽略警报precision太低也不行。最终调参目标不是把mAP刷到极致而是让recall和precision同时保持在0.8以上并且误报之间的时间间隔尽量拉长。混淆矩阵也要学会看。我们发现“手部触碰痛处”和“抓握/蜷缩动作”经常互相混淆原因在于两者姿态接近有的志愿者被抓拍时动作边界模糊。对策是检查标签中是否存在大面积重叠的框一旦确认标注边界有歧义要么合并类别要么写更细的规则。很多时候模型学歪不是网络笨是标签本身有问题。4.2 部署时的实际问题训练结束后导出ONNX模型喂给TensorRT加速在Jetson Orin上推理延迟大约30毫秒跑实时摄像头没压力。浮动延迟看起来不多真部署要处理的非模型问题也不少。最典型的是机位变化训练数据里摄像头大多平视或略俯视实际病房吊顶摄像头是俯视视角导致白天误报增多。后来我们用少量俯视样本微调模型情况立刻好转。光照和遮挡是另外两大坑。夜间病房只开床头灯整体偏暗模型对暗光下的小目标肉眼可见地不敏感。我们的处理顺序是先用摄像头自带的红外或夜视能力提升输入质量再在训练增强里增加低亮度模拟不要把模型当成能逆天改命的黑盒。遮挡问题更依赖类别设计如果头部被被子遮住但手部露在外面模型只要还能检出“手部触碰痛处”预警链路就不会断。4.3 可复用的扩展方向这个数据集的思路完全可以迁移。比如做新生儿疼痛识别重点脸部和哭声表情做康复监测关注关节活动时的避重动作做长期卧床护理检测身体反复扭动和翻身频率。还有同学问我能不能把多个视角融合现在单摄像头只能二维框以后接入ReID或者多摄像头跨镜追踪能对同一患者在不同床位的疼痛频率做长时间统计理论上更有价值。这些扩展最大的限制不在网络结构而在数据采集和标注标准的一致性。5. 常见问题与排查技巧实录5.1 标注质量引起的“假漏检”如果你发现训练时验证集mAP不升反降先不要急着加模型复杂度回头去检查标注文件。我们曾遇到训练后对某个类别recall特别低画面里明明有清晰疼痛表情模型就是检测不到一查发现这个类别的标注框普遍画得比实际目标大很多IoU算出来被严重惩罚。解决方式是用脚本统计每个类别目标框的宽高分布和图像分辨率对比如果某个类别宽高比值异常优先检查标注日志。画画框五分钟查查框一下午这是数据集项目绕不开的代价。5.2 训练loss和BN问题训练过程中如果loss高于正常范围或者出现nan按这个顺序排查数据文件夹里有没有空图片、标签里有没有坐标归一化出错、类别索引是否越界、batch和learning rate是否匹配、预训练权重是否下载完整。我们在一次实验里把某个标签文件的宽度误写成0YOLO训练不报错但loss直接失控这种问题只能靠脚本全量扫描解决。BN崩溃最典型的场景是batch减半后忘记调整学习率记住一个粗略规律batch减半学习率最好也减半然后观察前几个epoch的稳定性。5.3 医疗场景部署避坑清单最后整理一份避坑清单能帮你省掉大量现场扯皮的时间。第一不要在真实患者身上直接测试未经验证的模型先跑模拟人和脱敏历史数据第二所有输出都加置信度过滤宁可少报警也不乱报警启动阶段阈值可以设高一些跑两周再逐步下降第三对预警消息增加人工复核机制模型只做“疑似疼痛”的初筛最终判断权必须留给医护人员第四数据版本要记录Hash模型更新后可以快速回滚。医疗健康的AI落地拼的不只是算法的聪明程度而是整个系统在真实环境里能不能稳定、可信、不添乱。这里说点个人感受。疼不疼这件事本身就有很强的主观性模型能做的只是把观察到的行为线索变成相对客观的提醒。2200张数据集不算大但它让我明白医疗AI项目里最耗精力的不是网络结构而是数据规范和评估体系。后面如果再有人问我YOLO能不能做疼痛检测我会先反问一句你的数据是从哪来的标注规则是否经得起推敲这两件事想清楚了模型效果基本不会差到哪里去。