最早接触行人跌倒检测，是帮朋友做一套家庭看护系统的原型。当时第一反应很简单：拿现成的目标检测模型，在视频流上框出人，再判断这个人是站着还是躺着，不就完了吗？真正跑起来才发现，这事和"普通目标检测"差着一个量级。跌倒不是一个静态目标，它是一个持续时间极短、姿态剧烈变化的动态过程，而YOLO这类检测器本身是单帧模型，它天然不知道"上一秒这个人还在走路"这件事。于是问题变成了：怎么用YOLO系列的单帧检测能力，去支撑一个需要时序理解的跌倒检测场景？这篇文章就围绕这个问题展开，完整记录我基于YOLO系列搭建行人跌倒检测系统时的思路和踩坑过程：从任务定义、方案选型、数据标注，到训练参数调整、部署优化，再到误报抑制的工程策略。我会把当时查过、试过、推翻过的方案都写出来，适合正在做类似监控、安防、养老看护项目的开发者参考，也适合刚入门目标检测但想直接落地一个完整系统的人看。1. 为什么"跌倒检测"比普通目标检测难得多1.1 跌倒动作的视觉特征与检测难点如果把跌倒这个动作拆解开看，它是一个从站立状态到倒地静止状态的快速过渡，整个过程一般只有300到800毫秒。在这个窗口内，人的外观会经历剧烈变化：身体从竖直变成水平或蜷缩，人体框的宽高比从"瘦高"突然变成"矮胖"，同时伴随大幅度的位置下移。对检测器来说，这等于在几帧之内丢失了目标的大部分稳定特征。更难的地方在于自遮挡。人倒下去的瞬间，手臂、腿、躯干会互相遮挡，检测器看到的往往不是完整的人形轮廓，而是团在一起的不规则形状。再加上监控摄像头视角不固定——俯拍、斜拍、平视都有——同一个跌倒动作在不同机位下看起来完全不一样。平视镜头里一个正常的蹲起动作，在顶部俯视镜头里可能和跌倒高度相似。还有一个容易忽略的点：跌倒检测的难点不在"跌倒"，而在"区分像跌倒的事情"。弯腰捡东西、蹲下系鞋带、躺沙发上睡觉、跪着擦地，这些动作在单帧画面里和跌倒后的姿态非常接近。如果只按"人型宽高比变矮"来判断，误报率会高到根本没法用。这就是我一开始踩进去的坑：花了很多时间调模型，结果发现模型把拖地的大爷当成了跌倒。1.2 方案选型：纯检测、检测+姿态估计、还是检测+跟踪做跌倒检测，行业里大致有三条技术路线：方案核心思路优点缺点纯目标检测YOLO直接检测person和fallen两类，用框形态辅助判断结构简单、推理快、数据标注成本低单帧信息有限，区分蹲下/躺下/跌倒靠逻辑补检测+姿态估计YOLO检测人体框，再跑姿态关键点，用关键点夹角/高度判断跌倒能区分弯腰、蹲下等动作，信息更丰富推理开销大，远距离和小目标的关键点不可靠检测+多目标跟踪YOLO检测配合跟踪算法，在ID轨迹上做时序判断能利用前后文，误报率最低工程复杂度高，跟踪本身会出错我当时在第二种和第三种之间犹豫了很久。姿态估计方案听起来很美，但有个致命问题：跌倒瞬间动作太快，关键点在快速运动下经常检测不到或抖动剧烈，反而比纯检测更不稳定。第三种方案看着稳妥，但需要额外引入跟踪模块，ID切换、轨迹丢失都会成为新的故障点。最后我采用的是"纯检测为主、几何特征+时序状态机为辅"的混合路线：让YOLO负责单帧的"人是否处于跌倒姿态"判断，再用人体框的宽高比变化、质心位移速度、连续帧同一目标的状态确认来压误报。这个方案的好处是把模型和逻辑解耦开——模型做它擅长的视觉判断，逻辑部分做时间维度的推理，两端可以分别调优。另一个关键认知是：这套系统不需要做到"跌倒发生的瞬间就报警"，能在跌倒后3秒内报警，已经足够满足绝大多数看护场景。2. 数据是跌到检测的命门：数据集构建与标注规范2.1 公开数据集够不够用，以及怎么补训练数据首先想到的是找公开数据集，跌倒检测方向比较知名的有UR Fall、Le2i这类。它们能提供的样本确实可以，但用起来有几个问题：一是视角主要集中在实验室环境，摄像头高度、角度相对固定，和真实家庭、走廊场景差异不小；二是跌倒样本总数偏少，正负样本比例严重失衡；三是场景单一，几乎没有窗帘、宠物、灯光变化、反光地板这些现实干扰。我的做法是：公开数据集作为预训练基础，然后自己采集一批真实场景数据补充。具体操作不复杂——把摄像头按实际安装高度和角度架好，找几位朋友按照脚本模拟行动，包括正常走路、坐下、蹲下、弯腰捡东西、躺下休息，以及多种方式的跌倒（向前倒、侧倒、滑倒）。每个动作重复多轮，录制原始视频后按5帧抽一帧的方式切出图片，再经过筛选去掉大量重复帧。这里有个关键经验：真正导致模型在真实场景翻车的，往往不是跌倒样本不够，而是"跌倒相似动作"的负样本太少。拖地、系鞋带、抱小孩、搬重物、趴在沙发上看手机，这些日常动作比跌倒更常见，如果模型在训练时没见过足够多这样的负样本，部署后会整天误报。所以我在补充数据时，花在负样本上的精力远远多于跌倒正样本。2.2 我的标注约定：类别、时机与边界标注规范直接决定模型的认知边界，这里最忌讳的是标注标准含糊。我用的方案是YOLO格式的检测框，类别只设两类：person和fall。person表示站立、行走、坐姿、蹲姿等正常姿态；fall只标注"人已经处于倒地姿态"的框，也就是人体主轴明显偏离垂直、身体贴近地面或支撑面的状态。一个反复纠结的问题是：跌倒过程中间帧怎么标注？人还在半空中、还没完全落地的那几帧，到底算fall还是person？我最终定下的标准是：倾向把从倒地后到静止明确为fall，过渡帧如果把握不准就跳过不标。原因很简单，模型学习需要一致的语义，如果把过渡帧标成fall，等于告诉模型"这个中间状态也是跌倒"，会让它更容易把快速下蹲之类的动作当成跌倒。还有一个容易踩的坑：有些标注者会把整片躺倒区域框进去，把地面、沙发、床都圈在框里。这是错误的。fall的框依然要严格贴着人的轮廓，和普通人体检测标注规则一致。否则模型学到的是"大面积的矮框是跌倒"，一旦摄像头角度变化或画面里出现类似的背景区域，就会胡乱输出跌倒框。2.3 数据增强与不均衡处理YOLO训练自带一系列数据增强，但跌倒检测场景里有几个地方必须手动调整。第一个是禁止上下翻转。检测模型通常默认做随机上下翻转增强，对一般目标没问题，但人在物理世界里是不可能倒立走路的。上下翻转会让模型学到"头朝下的人体也是正常的"，反而干扰跌倒判断。左右翻转则安全得多，我开启了左右随机的翻转增强。第二个是旋转角度和透视变换需要保守。跌倒姿态本身就是扭曲的，旋转太大会让框的形状失真，我控制在正负30度以内。透视变换用于模拟不同摄像头视角，这个很有用，但强度也要适中，否则标注框会被变换得不成比例。第三是关于Mosaic增强。Mosaic把四张图拼在一起，对提高小目标检测效果显著，但在跌倒样本量不大的情况下，我建议在前半程训练开启高概率Mosaic，最后10到20个epoch把Mosaic关闭，让模型回到真实分布上精调。这点在YOLO训练配置里可以直接设置，对最终效果影响很大。样本不均衡方面，fall样本通常远少于person。我一开始直接把跌倒类的损失权重拉到很高，结果误报率飙升——模型为了降低损失，把大量相似动作都判成了跌倒。后来把两者的样本比例控制在大概1:4到1:5，然后在分类损失上对跌倒类别做适度加权，用一个系数1.5到2.0之间，而不是极端加权。这样既能保证跌倒的召回，又不至于让模型变得草木皆兵。3. YOLO系列选型与训练参数配置记录3.1 从v5到v8再到现在的新版本，我最终选了哪个YOLO系列迭代很快，训练时市面上常见的版本有v5、v8，以及更新的v11等。我评测下来，单看跌倒检测这个任务，模型版本之间的差距其实没有想象中大。YOLOv5成熟稳定、资料多，但对新硬件和部署链路的兼容性不如后面的版本；YOLOv8的anchor-free结构在框回归上更省心，训练速度和部署便利性均衡；更新的版本在常规COCO目标检测上有改进，但跌倒场景的数据量小、任务特殊性高，这些改进在实践中的体感提升很有限。我最终在YOLOv8和v9? 之间没有纠结太久，直接选定了YOLOv8的medium尺寸（m版本）。选择逻辑是：s版本速度最快但小目标召回弱，跌倒检测面对的家庭场景里，人离摄像头往往比较远，人体像素面积小，s版本容易出现漏检；l版本精度高但训练和推理成本都上去了，在边缘设备上跑不满帧率。m版本在两端的平衡最稳。如果你手头只有纯CPU环境，建议降到s版本再配合稍低分辨率跑，如果是在GPU边缘盒子（像带TensorRT的Jetson这类设备）上部署，m版本体验会很好。补充一句：模型版本统一用带COCO预训练权重的权重文件做起点，不要从随机初始化开始训。预训练权重里已经包含了大量人体外观、衣着、姿态的基础表征，跌倒检测这种数据量不大的场景，从预训练权重起步能少走很多弯路。3.2 训练配置与loss调参：实际跑的参数清单下面是我在跌倒检测任务上实际跑下来的核心参数，不同场景需要微调，但作为起点很有参考价值：yolo detect train \ model=yolov8m.pt \ data=fall.yaml \ imgsz=768 \ batch=32 \ epochs=150 \ hsv_h=0.015 hsv_s=0.7 hsv_v=0.4 \ degrees=30 hflip=0.5 vflip=0.0 \ mosaic=1.0 close_mosaic=10 \ box=7.5 cls=0.5 dfl=1.5几个参数的解释：imgsz=768，比默认的640更大。跌倒检测经常需要看远处的小目标，放大输入分辨率对远处人体框的回归有明显帮助。缺点是训练和推理都变慢，如果部署设备性能紧张，训练时仍然可以用768，推理时再降到640。close_mosaic=10，最后10个epoch关闭Mosaic增强，让模型适应真实图像分布。hsv类的颜色增强保持默认左右，真实监控场景的色温、亮度变化大，颜色扰动对泛化有帮助。box/cls/dfl是三个损失的权重。我只把cls从默认的0.5调低，没有动box和dfl。因为跌倒场景里误报的根源是分类混淆——蹲下、躺下和跌倒太像，分类损失权重过大会让模型"什么都想检出"，适度压低有利于抑制误报。反之，如果实测发现跌倒漏检严重，可以反方向调高cls。训练轮数我建议按实际收敛情况来。我在大约120个epoch时验证集损失趋于平稳，150轮足够。不要盲目拉到300轮，小数据集训练过久容易在增强关闭后过拟合，验证集指标反而波动。3.3 训练过程中怎么判断模型好坏这个部分我要特别强调：跌倒检测不能只看常规指标。YOLO训练结束会打印一堆指标，mAP50、mAP50-95、precision、recall，这些指标对通用目标检测是合理的，但放在跌倒场景里，fall类别的表现必须单独拆出来看。跌倒这类正样本少、误报代价高，整体mAP高不代表跌倒检测没问题，很可能只是样本量大的person类拉高了整体分数。我当时的做法是两个维度并行。第一，单独统计fall类的recall和precision，重点看recall——漏报一次跌倒，比误报一次要严重得多。第二，准备一段离线标注好的视频片段，里面包含10次以上的模拟跌倒动作和大量正常日常动作，跑完检测后用脚本统计三个数：应报警次数、实际报警次数、误报次数。这个"视频回放测试"比任何指标都能反映系统真实表现，我在训练阶段每20轮就跑一次，直观感受模型行为的变化趋势。还有一个实用小技巧：不要只跑最后一次保存的权重。训练过程中如果启用了最佳权重保存逻辑，通常会根据验证集mAP选最优。但在跌倒场景里，我更建议手动检查最后几个epoch保存的权重，因为mAP最优的权重有时为了整体分数牺牲了跌倒类别的召回，而最后一轮的权重经过完整训练，类别平衡往往更接近实际需求。多跑两次离线回放，选那个"漏报少"的权重，而不是"mAP最高"的权重。4. 部署推理：性能优化和把误报压下去的工程细节4.1 模型导出与推理加速：从PyTorch到ONNX再到TensorRT训练好的模型不能直接用PyTorch跑，至少我接触到的真实项目都不是这么干的。PyTorch的推理性能差，还依赖深度学习训练环境，部署到边缘设备上既不现实也不稳定。我的标准流程是把模型导出成ONNX格式，再做推理优化。导出ONNX几乎没有门槛，PyTorch训练框架本身就支持。导出之后可以选ONNX Runtime或者TensorRT跑推理。如果你用的是普通CPU工控机或者没有专门优化过的云服务器，ONNX Runtime加FP16足够了，在普通办公级CPU上，768输入分辨率的m模型单帧推理大概在150到250毫秒，降到640分辨率可以压缩到100毫秒上下，基本满足"跌倒后3秒内报警"的要求。如果目标是NVIDIA的边缘GPU设备，我的建议是直接上TensorRT的FP16推理，条件允许还可以做INT8量化。TensorRT会让推理速度提升数倍，同时功耗更低。但要走TensorRT需要额外的工程适配，并且INT8量化需要准备校准数据集，否则精度损失很可能让本来就稀少的跌倒样本更难检出。我的实际经验是：FP16已经能显著提速且不掉点，INT8是否使用要等模型成熟稳定后再考虑，不要一上来就追求极端优化。除此之外，实时视频流推理还有一个必须注意的工程点：不要串行处理。摄像头的画面是连续到达的，如果每帧都等模型推理完才处理下一帧，延迟会不断累积。我用的是多线程加队列的方式：取帧线程只管把最新帧塞进队列，推理线程从队列取帧，检测完成丢弃旧帧。这样即便模型某帧耗时超了，系统整体延迟也能保持稳定，不会出现画面越往后延迟越大的问题。4.2 用宽高比、帧间移动和连续帧确认来过滤误报单帧检测结果直接拿来报警，必然会被误报淹没。我在推理后加了三层过滤逻辑，每一层都很直观，但组合起来效果显著。第一层是宽高比判断。人站立时人体框的宽高比（w/h）通常在0.3到0.6之间，而倒地时这个比值会趋近0.8以上，甚至超过1。我在模型检测到fall类别后，再校验这个框的宽高比，如果明显小于阈值（比如0.7），就认为这个检测不够可信，直接丢弃。这个判断能干掉一部分误报，但要小心老人蜷缩侧躺的时候，人体框也可能没那么"扁"，阈值不能拍脑袋定太死。第二层是帧间状态确认。具体做法是维护一个"连续跌倒帧计数器"，只有连续N帧在同一位置附近都检测到fall，才触发一次报警。N我取的是5到6帧，对应大约0.2到0.3秒。这样做的效果很直接：单帧闪烁、光线抖动带来的偶发检测，都会被这层过滤掉。代价是报警会有轻微延迟，但前面说过，跌倒后3秒内报出来完全可接受。第三层同时结合相邻帧的运动特征，主要看两点：一是人体框质心在纵向（y方向）有没有发生突变下移；二是人体框面积有没有在短时间内快速变大。跌倒的物理过程必然伴随这两个特征，而蹲下、躺沙发这些动作虽然姿态相似，但质心移动速度和面积变化都不具备突然性。我把这两项作为辅助判据，做成一个简单的评分逻辑，达标才最终报警。这些都是纯粹的几何与时序逻辑，不需要再引入额外的模型，实现简单、解释性强，也方便在项目里按具体场景调阈值。实际跑下来，这套组合过滤能把误报率降低一个数量级。4.3 实测翻车场景与后续对策模型和过滤逻辑都上了之后，我开始做真实环境的长时间验证，这时候才暴露出一堆之前在离线测试里看不出来的问题。第一个翻车场景是宠物。家里养的狗体型和坐姿的儿童很像，模型会偶发把狗判定成person，狗躺下休息时偶尔触发fall。对策是在后端逻辑里增加目标尺寸下限，太小的目标直接不参与跌倒判断。第二个翻车场景是光线剧变。傍晚拉窗帘、晚上关灯，画面亮度的瞬时剧烈变化会导致检测结果抖动，出现"上一帧全是检测框、下一帧全空"的情况。连续帧计数器的逻辑在这里会出现一个副作用：如果画面整体清空，计数器会清零，导致真正跌倒发生的帧恰好被吞掉。我的处理是加了画面有效判断，如果整帧的平均亮度剧烈变化，就在这个窗口内暂缓判断而不是简单清零。第三个翻车场景是视角盲区。摄像头斜向下安装时，画面角落的人如果是背对镜头滑倒，身体会被家具部分遮挡，检测框残缺，fall置信度偏低。这个靠纯调参解决不了，我的办法是把这类情况作为补充负样本收集回灌训练，同时可以在ROI层面排除容易被遮挡的角落区域，避免系统在资源有限的设备上浪费算力去检测一个永远不清晰的画面。多轮迭代之后我最大的体会是：模型能力、后端逻辑、部署环境三者是互相牵制的。单帧检测性能上去了，误报抑制逻辑跟不上，系统还是不好用；逻辑再完善，模型在特定视角下漏检，也补不回来。只有把这几层当作一个整体工程来调，才可能真正落地。至于我最后留的那个小技巧：部署之前，一定要录一段一周以上的原始监控视频，按天回放，把每次报警截屏出来和朋友一起看。你会发现很多模型训练时根本想不到的问题，比如投影、窗帘影子、晾衣架上的衣服——这些看起来离谱的误报，恰恰是真实系统里最常出现的事故。
最早接触行人跌倒检测，是帮朋友做一套家庭看护系统的原型。当时第一反应很简单：拿现成的目标检测模型，在视频流上框出人，再判断这个人是站着还是躺着，不就完了吗？真正跑起来才发现，这事和"普通目标检测"差着一个量级。跌倒不是一个静态目标，它是一个持续时间极短、姿态剧烈变化的动态过程，而YOLO这类检测器本身是单帧模型，它天然不知道"上一秒这个人还在走路"这件事。于是问题变成了：怎么用YOLO系列的单帧检测能力，去支撑一个需要时序理解的跌倒检测场景？这篇文章就围绕这个问题展开，完整记录我基于YOLO系列搭建行人跌倒检测系统时的思路和踩坑过程：从任务定义、方案选型、数据标注，到训练参数调整、部署优化，再到误报抑制的工程策略。我会把当时查过、试过、推翻过的方案都写出来，适合正在做类似监控、安防、养老看护项目的开发者参考，也适合刚入门目标检测但想直接落地一个完整系统的人看。1. 为什么"跌倒检测"比普通目标检测难得多1.1 跌倒动作的视觉特征与检测难点如果把跌倒这个动作拆解开看，它是一个从站立状态到倒地静止状态的快速过渡，整个过程一般只有300到800毫秒。在这个窗口内，人的外观会经历剧烈变化：身体从竖直变成水平或蜷缩，人体框的宽高比从"瘦高"突然变成"矮胖"，同时伴随大幅度的位置下移。对检测器来说，这等于在几帧之内丢失了目标的大部分稳定特征。更难的地方在于自遮挡。人倒下去的瞬间，手臂、腿、躯干会互相遮挡，检测器看到的往往不是完整的人形轮廓，而是团在一起的不规则形状。再加上监控摄像头视角不固定——俯拍、斜拍、平视都有——同一个跌倒动作在不同机位下看起来完全不一样。平视镜头里一个正常的蹲起动作，在顶部俯视镜头里可能和跌倒高度相似。还有一个容易忽略的点：跌倒检测的难点不在"跌倒"，而在"区分像跌倒的事情"。弯腰捡东西、蹲下系鞋带、躺沙发上睡觉、跪着擦地，这些动作在单帧画面里和跌倒后的姿态非常接近。如果只按"人型宽高比变矮"来判断，误报率会高到根本没法用。这就是我一开始踩进去的坑：花了很多时间调模型，结果发现模型把拖地的大爷当成了跌倒。1.2 方案选型：纯检测、检测+姿态估计、还是检测+跟踪做跌倒检测，行业里大致有三条技术路线：方案核心思路优点缺点纯目标检测YOLO直接检测person和fallen两类，用框形态辅助判断结构简单、推理快、数据标注成本低单帧信息有限，区分蹲下/躺下/跌倒靠逻辑补检测+姿态估计YOLO检测人体框，再跑姿态关键点，用关键点夹角/高度判断跌倒能区分弯腰、蹲下等动作，信息更丰富推理开销大，远距离和小目标的关键点不可靠检测+多目标跟踪YOLO检测配合跟踪算法，在ID轨迹上做时序判断能利用前后文，误报率最低工程复杂度高，跟踪本身会出错我当时在第二种和第三种之间犹豫了很久。姿态估计方案听起来很美，但有个致命问题：跌倒瞬间动作太快，关键点在快速运动下经常检测不到或抖动剧烈，反而比纯检测更不稳定。第三种方案看着稳妥，但需要额外引入跟踪模块，ID切换、轨迹丢失都会成为新的故障点。最后我采用的是"纯检测为主、几何特征+时序状态机为辅"的混合路线：让YOLO负责单帧的"人是否处于跌倒姿态"判断，再用人体框的宽高比变化、质心位移速度、连续帧同一目标的状态确认来压误报。这个方案的好处是把模型和逻辑解耦开——模型做它擅长的视觉判断，逻辑部分做时间维度的推理，两端可以分别调优。另一个关键认知是：这套系统不需要做到"跌倒发生的瞬间就报警"，能在跌倒后3秒内报警，已经足够满足绝大多数看护场景。2. 数据是跌到检测的命门：数据集构建与标注规范2.1 公开数据集够不够用，以及怎么补训练数据首先想到的是找公开数据集，跌倒检测方向比较知名的有UR Fall、Le2i这类。它们能提供的样本确实可以，但用起来有几个问题：一是视角主要集中在实验室环境，摄像头高度、角度相对固定，和真实家庭、走廊场景差异不小；二是跌倒样本总数偏少，正负样本比例严重失衡；三是场景单一，几乎没有窗帘、宠物、灯光变化、反光地板这些现实干扰。我的做法是：公开数据集作为预训练基础，然后自己采集一批真实场景数据补充。具体操作不复杂——把摄像头按实际安装高度和角度架好，找几位朋友按照脚本模拟行动，包括正常走路、坐下、蹲下、弯腰捡东西、躺下休息，以及多种方式的跌倒（向前倒、侧倒、滑倒）。每个动作重复多轮，录制原始视频后按5帧抽一帧的方式切出图片，再经过筛选去掉大量重复帧。这里有个关键经验：真正导致模型在真实场景翻车的，往往不是跌倒样本不够，而是"跌倒相似动作"的负样本太少。拖地、系鞋带、抱小孩、搬重物、趴在沙发上看手机，这些日常动作比跌倒更常见，如果模型在训练时没见过足够多这样的负样本，部署后会整天误报。所以我在补充数据时，花在负样本上的精力远远多于跌倒正样本。2.2 我的标注约定：类别、时机与边界标注规范直接决定模型的认知边界，这里最忌讳的是标注标准含糊。我用的方案是YOLO格式的检测框，类别只设两类：person和fall。person表示站立、行走、坐姿、蹲姿等正常姿态；fall只标注"人已经处于倒地姿态"的框，也就是人体主轴明显偏离垂直、身体贴近地面或支撑面的状态。一个反复纠结的问题是：跌倒过程中间帧怎么标注？人还在半空中、还没完全落地的那几帧，到底算fall还是person？我最终定下的标准是：倾向把从倒地后到静止明确为fall，过渡帧如果把握不准就跳过不标。原因很简单，模型学习需要一致的语义，如果把过渡帧标成fall，等于告诉模型"这个中间状态也是跌倒"，会让它更容易把快速下蹲之类的动作当成跌倒。还有一个容易踩的坑：有些标注者会把整片躺倒区域框进去，把地面、沙发、床都圈在框里。这是错误的。fall的框依然要严格贴着人的轮廓，和普通人体检测标注规则一致。否则模型学到的是"大面积的矮框是跌倒"，一旦摄像头角度变化或画面里出现类似的背景区域，就会胡乱输出跌倒框。2.3 数据增强与不均衡处理YOLO训练自带一系列数据增强，但跌倒检测场景里有几个地方必须手动调整。第一个是禁止上下翻转。检测模型通常默认做随机上下翻转增强，对一般目标没问题，但人在物理世界里是不可能倒立走路的。上下翻转会让模型学到"头朝下的人体也是正常的"，反而干扰跌倒判断。左右翻转则安全得多，我开启了左右随机的翻转增强。第二个是旋转角度和透视变换需要保守。跌倒姿态本身就是扭曲的，旋转太大会让框的形状失真，我控制在正负30度以内。透视变换用于模拟不同摄像头视角，这个很有用，但强度也要适中，否则标注框会被变换得不成比例。第三是关于Mosaic增强。Mosaic把四张图拼在一起，对提高小目标检测效果显著，但在跌倒样本量不大的情况下，我建议在前半程训练开启高概率Mosaic，最后10到20个epoch把Mosaic关闭，让模型回到真实分布上精调。这点在YOLO训练配置里可以直接设置，对最终效果影响很大。样本不均衡方面，fall样本通常远少于person。我一开始直接把跌倒类的损失权重拉到很高，结果误报率飙升——模型为了降低损失，把大量相似动作都判成了跌倒。后来把两者的样本比例控制在大概1:4到1:5，然后在分类损失上对跌倒类别做适度加权，用一个系数1.5到2.0之间，而不是极端加权。这样既能保证跌倒的召回，又不至于让模型变得草木皆兵。3. YOLO系列选型与训练参数配置记录3.1 从v5到v8再到现在的新版本，我最终选了哪个YOLO系列迭代很快，训练时市面上常见的版本有v5、v8，以及更新的v11等。我评测下来，单看跌倒检测这个任务，模型版本之间的差距其实没有想象中大。YOLOv5成熟稳定、资料多，但对新硬件和部署链路的兼容性不如后面的版本；YOLOv8的anchor-free结构在框回归上更省心，训练速度和部署便利性均衡；更新的版本在常规COCO目标检测上有改进，但跌倒场景的数据量小、任务特殊性高，这些改进在实践中的体感提升很有限。我最终在YOLOv8和v9? 之间没有纠结太久，直接选定了YOLOv8的medium尺寸（m版本）。选择逻辑是：s版本速度最快但小目标召回弱，跌倒检测面对的家庭场景里，人离摄像头往往比较远，人体像素面积小，s版本容易出现漏检；l版本精度高但训练和推理成本都上去了，在边缘设备上跑不满帧率。m版本在两端的平衡最稳。如果你手头只有纯CPU环境，建议降到s版本再配合稍低分辨率跑，如果是在GPU边缘盒子（像带TensorRT的Jetson这类设备）上部署，m版本体验会很好。补充一句：模型版本统一用带COCO预训练权重的权重文件做起点，不要从随机初始化开始训。预训练权重里已经包含了大量人体外观、衣着、姿态的基础表征，跌倒检测这种数据量不大的场景，从预训练权重起步能少走很多弯路。3.2 训练配置与loss调参：实际跑的参数清单下面是我在跌倒检测任务上实际跑下来的核心参数，不同场景需要微调，但作为起点很有参考价值：yolo detect train \ model=yolov8m.pt \ data=fall.yaml \ imgsz=768 \ batch=32 \ epochs=150 \ hsv_h=0.015 hsv_s=0.7 hsv_v=0.4 \ degrees=30 hflip=0.5 vflip=0.0 \ mosaic=1.0 close_mosaic=10 \ box=7.5 cls=0.5 dfl=1.5几个参数的解释：imgsz=768，比默认的640更大。跌倒检测经常需要看远处的小目标，放大输入分辨率对远处人体框的回归有明显帮助。缺点是训练和推理都变慢，如果部署设备性能紧张，训练时仍然可以用768，推理时再降到640。close_mosaic=10，最后10个epoch关闭Mosaic增强，让模型适应真实图像分布。hsv类的颜色增强保持默认左右，真实监控场景的色温、亮度变化大，颜色扰动对泛化有帮助。box/cls/dfl是三个损失的权重。我只把cls从默认的0.5调低，没有动box和dfl。因为跌倒场景里误报的根源是分类混淆——蹲下、躺下和跌倒太像，分类损失权重过大会让模型"什么都想检出"，适度压低有利于抑制误报。反之，如果实测发现跌倒漏检严重，可以反方向调高cls。训练轮数我建议按实际收敛情况来。我在大约120个epoch时验证集损失趋于平稳，150轮足够。不要盲目拉到300轮，小数据集训练过久容易在增强关闭后过拟合，验证集指标反而波动。3.3 训练过程中怎么判断模型好坏这个部分我要特别强调：跌倒检测不能只看常规指标。YOLO训练结束会打印一堆指标，mAP50、mAP50-95、precision、recall，这些指标对通用目标检测是合理的，但放在跌倒场景里，fall类别的表现必须单独拆出来看。跌倒这类正样本少、误报代价高，整体mAP高不代表跌倒检测没问题，很可能只是样本量大的person类拉高了整体分数。我当时的做法是两个维度并行。第一，单独统计fall类的recall和precision，重点看recall——漏报一次跌倒，比误报一次要严重得多。第二，准备一段离线标注好的视频片段，里面包含10次以上的模拟跌倒动作和大量正常日常动作，跑完检测后用脚本统计三个数：应报警次数、实际报警次数、误报次数。这个"视频回放测试"比任何指标都能反映系统真实表现，我在训练阶段每20轮就跑一次，直观感受模型行为的变化趋势。还有一个实用小技巧：不要只跑最后一次保存的权重。训练过程中如果启用了最佳权重保存逻辑，通常会根据验证集mAP选最优。但在跌倒场景里，我更建议手动检查最后几个epoch保存的权重，因为mAP最优的权重有时为了整体分数牺牲了跌倒类别的召回，而最后一轮的权重经过完整训练，类别平衡往往更接近实际需求。多跑两次离线回放，选那个"漏报少"的权重，而不是"mAP最高"的权重。4. 部署推理：性能优化和把误报压下去的工程细节4.1 模型导出与推理加速：从PyTorch到ONNX再到TensorRT训练好的模型不能直接用PyTorch跑，至少我接触到的真实项目都不是这么干的。PyTorch的推理性能差，还依赖深度学习训练环境，部署到边缘设备上既不现实也不稳定。我的标准流程是把模型导出成ONNX格式，再做推理优化。导出ONNX几乎没有门槛，PyTorch训练框架本身就支持。导出之后可以选ONNX Runtime或者TensorRT跑推理。如果你用的是普通CPU工控机或者没有专门优化过的云服务器，ONNX Runtime加FP16足够了，在普通办公级CPU上，768输入分辨率的m模型单帧推理大概在150到250毫秒，降到640分辨率可以压缩到100毫秒上下，基本满足"跌倒后3秒内报警"的要求。如果目标是NVIDIA的边缘GPU设备，我的建议是直接上TensorRT的FP16推理，条件允许还可以做INT8量化。TensorRT会让推理速度提升数倍，同时功耗更低。但要走TensorRT需要额外的工程适配，并且INT8量化需要准备校准数据集，否则精度损失很可能让本来就稀少的跌倒样本更难检出。我的实际经验是：FP16已经能显著提速且不掉点，INT8是否使用要等模型成熟稳定后再考虑，不要一上来就追求极端优化。除此之外，实时视频流推理还有一个必须注意的工程点：不要串行处理。摄像头的画面是连续到达的，如果每帧都等模型推理完才处理下一帧，延迟会不断累积。我用的是多线程加队列的方式：取帧线程只管把最新帧塞进队列，推理线程从队列取帧，检测完成丢弃旧帧。这样即便模型某帧耗时超了，系统整体延迟也能保持稳定，不会出现画面越往后延迟越大的问题。4.2 用宽高比、帧间移动和连续帧确认来过滤误报单帧检测结果直接拿来报警，必然会被误报淹没。我在推理后加了三层过滤逻辑，每一层都很直观，但组合起来效果显著。第一层是宽高比判断。人站立时人体框的宽高比（w/h）通常在0.3到0.6之间，而倒地时这个比值会趋近0.8以上，甚至超过1。我在模型检测到fall类别后，再校验这个框的宽高比，如果明显小于阈值（比如0.7），就认为这个检测不够可信，直接丢弃。这个判断能干掉一部分误报，但要小心老人蜷缩侧躺的时候，人体框也可能没那么"扁"，阈值不能拍脑袋定太死。第二层是帧间状态确认。具体做法是维护一个"连续跌倒帧计数器"，只有连续N帧在同一位置附近都检测到fall，才触发一次报警。N我取的是5到6帧，对应大约0.2到0.3秒。这样做的效果很直接：单帧闪烁、光线抖动带来的偶发检测，都会被这层过滤掉。代价是报警会有轻微延迟，但前面说过，跌倒后3秒内报出来完全可接受。第三层同时结合相邻帧的运动特征，主要看两点：一是人体框质心在纵向（y方向）有没有发生突变下移；二是人体框面积有没有在短时间内快速变大。跌倒的物理过程必然伴随这两个特征，而蹲下、躺沙发这些动作虽然姿态相似，但质心移动速度和面积变化都不具备突然性。我把这两项作为辅助判据，做成一个简单的评分逻辑，达标才最终报警。这些都是纯粹的几何与时序逻辑，不需要再引入额外的模型，实现简单、解释性强，也方便在项目里按具体场景调阈值。实际跑下来，这套组合过滤能把误报率降低一个数量级。4.3 实测翻车场景与后续对策模型和过滤逻辑都上了之后，我开始做真实环境的长时间验证，这时候才暴露出一堆之前在离线测试里看不出来的问题。第一个翻车场景是宠物。家里养的狗体型和坐姿的儿童很像，模型会偶发把狗判定成person，狗躺下休息时偶尔触发fall。对策是在后端逻辑里增加目标尺寸下限，太小的目标直接不参与跌倒判断。第二个翻车场景是光线剧变。傍晚拉窗帘、晚上关灯，画面亮度的瞬时剧烈变化会导致检测结果抖动，出现"上一帧全是检测框、下一帧全空"的情况。连续帧计数器的逻辑在这里会出现一个副作用：如果画面整体清空，计数器会清零，导致真正跌倒发生的帧恰好被吞掉。我的处理是加了画面有效判断，如果整帧的平均亮度剧烈变化，就在这个窗口内暂缓判断而不是简单清零。第三个翻车场景是视角盲区。摄像头斜向下安装时，画面角落的人如果是背对镜头滑倒，身体会被家具部分遮挡，检测框残缺，fall置信度偏低。这个靠纯调参解决不了，我的办法是把这类情况作为补充负样本收集回灌训练，同时可以在ROI层面排除容易被遮挡的角落区域，避免系统在资源有限的设备上浪费算力去检测一个永远不清晰的画面。多轮迭代之后我最大的体会是：模型能力、后端逻辑、部署环境三者是互相牵制的。单帧检测性能上去了，误报抑制逻辑跟不上，系统还是不好用；逻辑再完善，模型在特定视角下漏检，也补不回来。只有把这几层当作一个整体工程来调，才可能真正落地。至于我最后留的那个小技巧：部署之前，一定要录一段一周以上的原始监控视频，按天回放，把每次报警截屏出来和朋友一起看。你会发现很多模型训练时根本想不到的问题，比如投影、窗帘影子、晾衣架上的衣服——这些看起来离谱的误报，恰恰是真实系统里最常出现的事故。