“跌倒检测”这四个字，翻译成两种完全不同的语言。在普通人眼里，它是关怀与风险，是家里老人摔倒时的惊慌；在机器视觉工程师眼里，它是框、是类别、是置信度、是每秒多少帧的推理结果。YOLOv8 顺手把这两套语言缝合到一起，主干网络负责提特征，检测头把特征转成“人跌倒”这个结论。这篇实战记录，覆盖了从我拿到需求到模型上线部署的全过程：数据标注、模型训练、导出部署、真实场景接入。前前后后满打满算调了两个多月，项目本身并不复杂，但坑全埋在细节里，其中部署和误报处理保守估计吃掉了八成的时间。适合正在做监控场景检测、或者想给老人的居住空间加一道“自动预警”的开发者，当作一份可以直接抄作业的流程参考。

1. 整体设计复盘：从场景需求到技术选型

1.1 机器眼里的“跌倒”到底长什么样

先把“跌倒”这件事在计算机视觉里的样子说清楚。二维图像里的跌倒，本质是“人的姿态出现异常”，最常见的画面特征是人体沿着地面的横向分布：人体框的宽明显大于高，或者人体区域整体呈现斜躺、蜷缩的形态，同时相对静止或只存在轻微移动。简单说，模型学的不是一个物理动作，而是一组由“目标框宽高比变化”“目标轮廓分布”和“帧间位置变化”共同决定的图像模式。

这个定义在立项时非常重要，因为它直接决定了我们用检测模型而不是姿态模型。跌倒瞬间动作很快，但从帧画面看，跌倒后的静止姿态才是最容易稳定捕捉的信号。检测模型天然就是“找目标、给边界框”，只要框能将跌倒后的躺倒姿态框得足够稳，后台上位机再配合连续几帧的框位置变化，就能很好地完成“跌倒判定 + 告警触发”这件业务任务。

另一方面，真实场景的物联网监控是常亮的，摄像头视角多为斜俯视或平视，画面里人的尺度会变化、光照会变、遮挡会出现。这些都对模型的泛化能力提出了比实验室测试高得多的要求，所以整个项目我刻意把“场景复杂”当成第一设计约束，宁可牺牲一点实验室精度，也要保证现场环境的稳定性。

1.2 模型选型：为什么用 YOLOv8，而不是姿态估计或传统视觉

先说结论：YOLOv8在“跌倒检测”这件事上，是一种权衡之后更偏向工程落地的选择。项目初期我也认真评估过另两条技术路线。

第一条是人体姿态估计，例如基于关键点的方案。姿态估计能给出更精细的“人是否倒地”判断，通过计算肩膀和髋关节连线与地面的夹角来判断倒地状态。这条路线识别姿态确实更优雅，但问题是：实时性开销大，一张图上要同时跑目标检测和关键点回归，对边缘设备的算力压力陡增；数据标注成本也高，需要给每个人逐帧标注十几个关键点；最关键的是在相机斜俯视场景里，部分关键点被遮挡的概率非常高，一旦脚部或肩部关键点丢失，角度计算立刻不可靠，误报反而会增多。

第二条是传统视觉方案，比如背景建模配合轮廓分析。这类方案在光线固定、背景纯净的小范围实验里表现尚可，但在养老机构或家庭环境下几乎不可用。窗帘飘动、光线渐变、宠物移动都会触发前景分割错误，误报率高到完全没有实用价值。

下面这张表是我当初做选型时整理的，按工程落地角度来评分：

其实单看处理单帧图像，姿态估计也没慢到不能用，真正的问题出在工程链路上：姿态估计后续还要串一套角度判断逻辑，而这套逻辑在真实环境里对摄像头安装高度、角度太敏感。YOLOv8则简单得多，一个检测头直接框出人所在区域，要不要接分类逻辑、要不要接跟踪，都可以在部署阶段灵活加。所以我最终选定YOLOv8，核心思路就是“把复杂判断推迟到后处理，让模型干自己最擅长的事”。

1.3 项目技术栈与整体流程

这个项目的技术栈很主流，常规开发环境下几乎可以一键复现：

• 模型框架：YOLOv8，采用官方预训练权重做微调，而不是从头训练。从头训练在数据量上不现实，微调则对数据需求友善得多。
• 训练环境：单张消费级显卡即可，显存16G上下完全够用。
• 部署环境：边缘计算盒子，同时兼容CPU推理作为降级方案。
• 业务外围：视频流接入用RTSP，数据处理用Python脚本实现“检测结果 + 连续帧状态机”的跌倒判定逻辑。
• 可视化：简单做了一个Web告警后台，用于展示报警截图和现场视频回放。

整体流程可以拆成五段：数据准备与标注，模型训练与评估，模型导出，边缘部署与环境适配，告警业务逻辑联调。每一段都有独立的坑，但最花时间的第二段和第五段。接下来我一条一条拆开讲。

2. 数据准备与标注：决定模型上限的关键环节

2.1 数据从哪来：公开数据与自采数据相结合

模型效果的天花板不是网络结构，而是数据。YOLOv8的骨干网络足够强，但喂进去的数据如果没有覆盖真实场景的各种姿势、光照、遮挡情况，训练完照样在监控画面里疯狂误报。

我的数据源分成三块：

第一块是公开数据集。网上能搜到的跌倒检测开源数据集，我收集了三四套，把里面的图片全部抽取出来看了一遍。这一步很枯燥，但必须做，因为很多数据集的标注质量参差不齐，有的把“蹲下捡东西”也标成了跌倒，有的标注框极其粗糙，导致目标特征学习混乱。我最终只筛选出图像质量清晰、跌倒姿态完整的图片，摔跤、坐倒、滑倒、晕厥倒地这几类姿态尽量都要覆盖。

第二块是自采模拟数据。我找了几个同事在样板间里模拟跌倒动作，用不同角度的相机录制视频，然后抽帧保存。不要小看自采数据，它是最能贴近真实部署场景的一环，因为公开数据集里的机位，跟你的现场机位永远存在差异。

第三块是真实监控数据。这部分在涉及隐私的前提下，只截取了场景中无人的背景帧作为负样本，或者经充分脱敏后才使用。同时我会在无人的背景帧里混入一部分作为负样本，让模型知道“当前画面没有目标”，这对降低误报有奇效。

综合下来，训练集大概有12000多张图，其中正样本（包含跌倒）和负样本（正常站立/行走/无人的背景）的比例控制在大概1比3。一开始我是1比1，发现模型虽然对跌倒敏感，但也特别容易把扫地机器人误报成人，后来扩大负样本比例，误报明显下降。

2.2 类别定义与“半跌倒”边界处理

标注之前先定类别，这一步比多数人想象的更容易影响最终效果。

我一开始只标了两类：人类（person）和跌倒（fall）。逻辑是：模型先检出人，再判断人是否跌倒。但很快发现问题，监控画面里人倒下的过程可能只有零点几秒，中间帧的姿态既不是站也不是躺，模型在这一两帧里会犹豫。更麻烦的是，蹲下系鞋带、弯腰捡东西、坐在地上休息，这些姿态跟跌倒后的姿态实在太像了。

最终我调整为三个类别：

• 站立/行走：常规的直立或运动状态。
• 蹲坐/弯腰：过渡状态、低姿态。
• 跌倒/躺倒：人体大面积贴近地面且姿态异常。

这三类并不是业务上的最终分类，而是为了把“模糊地带”从模型层面里分出来。模型只负责给出形态判断，至于“蹲坐”算不算危险，完全交给后处理逻辑结合持续时间来决定。这比让模型强行二分类要稳得多。举个实际例子：老人只是在床边坐下来缓一缓，画面里的姿态跟跌倒非常接近，如果没有这个过渡类别，系统大概率会误报；加了之后，模型会把这种情况归到蹲坐，后处理逻辑再判断是否连续若干秒没有恢复直立，才决定要不要告警。

2.3 标注工具与标注易错点

标注工具我用了开源的标注软件，支持自动保存和快捷键操作，在批量标注效率上有肉眼可见的提升。下面几个易错点都是真实踩过的坑：

1. 标注框不要刻意贴着人体外侧。检测框稍微包含一点背景，反而有利于模型学到相对完整的轮廓特征。太紧的框遇到人体部分被遮挡时，容易导致特征丢失。
2. 遮挡处理要统一规则。人体被桌椅遮挡了大约三分之一时，也要正常标注完整框。不要因为看不见就只标可见部分，那样会让模型学习到残缺特征。
3. 人体很小但清晰的图片不要跳过。监控画面里经常出现远景小目标，这种图数量少但价值高。YOLOv8本身就存在小目标检测的弱点，标注时保留小目标样本，有利于后续模型针对性训练。
4. 连续帧不要机械地全部抽取。跌倒动作的视频抽帧时，尽量隔几帧抽一张，保证画面多样性，否则连续相似帧会让模型过拟合于某一特定动作片段，验证集上表现却依然虚高。

另外，每批数据标完以后，我都会用第二个人去抽检大概10%的标注结果，重点看边界框和类别是否有明显错误。AI训练最怕的就是“脏数据进、脏模型出”，发现问题时返工成本远高于训练时间成本。

2.4 数据增强：不换模型也能提点

YOLOv8自带丰富的数据增强策略，训练时开启默认增强就够用，但有几个参数值得单独调。

• 色调、饱和度、亮度：监控画面里色温差异很大，白天偏冷、夜间偏暖，所以我把HSV增强的幅度比默认值调大了大概50%，模拟不同时间段的画面风格。
• 随机透视与平移：这些模拟摄像机安装角度小范围变化，能提升模型对不同机位的适应能力。幅度不宜过大，否则会让目标形变失真。
• Mosaic增强：这幅图是YOLO系列的老朋友，多图拼接能让模型学会在复杂背景下辨别目标。不过最后一二十个epoch我会把它关掉，在这一阶段使用Mosaic会导致训练特征分布与实际场景偏差，具体做法在后面训练部分展开说。

有一点必须提醒：数据增强不是无脑拉满，增强过猛会让模型学到虚假纹理。我的经验是先在默认参数下跑一个短期训练看验证集指标，再小幅调整增强参数，对比几次后取稳定上升的方向，小步尝试比一次性大改更容易定位问题。

3. 训练实战：配置、过程与评估

3.1 训练环境与显存占用

训练环境非常平民化。操作系统是Ubuntu，深度学习框架PyTorch，显卡用的是单张普通游戏显卡。别被一些教程吓住，以为非得四卡起步，YOLOv8n和YOLOv8s这类模型在消费级显卡上完全可以训。

显存占用主要取决于图像分辨率、batch size和模型宽度。我把输入分辨率设为640×640，模型选的是YOLOv8n和YOLOv8s各训了一版。YOLOv8s在精度上比n版低一点，二者差异其实没有想象中大，但YOLOv8s的推理负载和显存占用明显更高。考虑到最终要上边缘设备，我选择了YOLOv8s作为主干方案，n版作为备选，算是一个精度和延迟之间的折中。

一个实用技巧：训练时显存不够，优先调小batch size，不要一上来就改图像分辨率。分辨率降低会让小目标漏检率直线上升，这个代价比降低batch size严重得多。

安装环境只需要执行几条命令，建议用虚拟环境隔离。项目里我用的是Python 3.10版本，装好Ultralytics后再装一张基础依赖清单，避免后续额外扩展时版本打架。

3.2 训练参数逐项解读

YOLOv8的官方命令行工具已经封装得很顺手，但参数含义必须吃透，不然训练跑起来出了问题都不知道去哪找。我用的是下面这份基础配置来训练YOLOv8s：

yolo train \ model=yolov8s.pt \ data=dataset.yaml \ epochs=120 \ imgsz=640 \ batch=16 \ optimizer=SGD \ lr0=0.01 \ lrf=0.01 \ cos_lr=True \ patience=20 \ device=0

逐项解释我调整过的关键参数：

• model参数用的是yolov8s.pt预训练权重，这是在COCO数据集上训好的通用模型。风吹日晒的，YOLOv8已经在通用目标上学会了很好的特征表达，我们只学“跌倒”这个新任务即可。
• epochs没有设很大，120轮是因为数据量本身够用，过度训练反而开始过拟合。我观察过训练日志，大约在80轮之后验证集曲线就基本进入平台期，120轮已经足够收敛，多出来的轮数主要为了保险。
• optimizer用SGD而不用Adam，YOLOv8官方默认也推荐SGD。Adam前期收敛快，但后期容易在验证集上收不干净；SGD配合余弦退火学习率，整体收敛过程更稳，最终精度通常略高。
• lr0、lrf和cos_lr组合成一套余弦退火策略，学习率从0.01慢慢降到0.0001。这种曲线比固定学习率更平滑，特别是后期微调阶段不容易震荡。
• patience=20表示如果验证集指标连续20个epoch没有改善，训练会自动停止，防止空转浪费时间。

数据集配置文件是YAML格式，里面定义训练验证路径和类别名。这里有一个细节，路径最好用绝对路径，或者至少确保相对路径是相对于配置文件所在目录的，我就在这上面栽过跟头，数据集移动目录后一直报找不到文件，后来仔细看路径拼接规则才发现问题。

3.3 训练过程与中断恢复

训练过程不是一键执行就完事，我基本每隔一小时会看一眼曲线。主要看两个地方：候选值的变化趋势和训练集损失。

正常情况下，推理损失和分类损失都应该是连续下降的，验证集mAP曲线呈现波浪式上升。如果发现候选值已经掉头持续下降几个epoch，而训练损失还在降，这就是典型的过拟合信号，需要对模型进行正则化加强，或者提前停止训练。另外如果训练开始阶段mAP还是零，不用慌，前几个epoch只是让模型适应新数据，一般到10到15个epoch后曲线会突然开始抬头。

训练过程中途意外断电也不想重新来，YOLOv8支持断点续训。我建议每5到10个epoch保留一个权重文件，这里给出的是模型自动保存的策略。万一中断，只要找到最近的一个权重文件直接续训——一般从验证集指标较高的那个checkpoint继续，能得到一个相对更稳的收敛结果。

另一个心得是训练阶段要学会“看日志找线索”。日志里除了正常显示mAP和loss之外，还会显示每个类别的精确率、召回率。如果使用“跌倒/躺倒”类别的召回率明显偏低，大概率是正样本不够，模型把跌倒漏成了背景；若精确率偏低，大概率是负样本不够或者容易混淆的站姿过多，模型过于激进地把普通姿态判定为跌倒。定位到方向后再去补数据，比盲目调参高效得多。

3.4 评估指标与权重版本选择

评估模型时不能只看一张图上“看起来准不准”，那只是主观感受。我用下面这套指标组合来客观评价：

• mAP50：初始验证时的主要参考。它在IoU为0.5的宽松标准下，计算所有类别的平均精度。这个指标比较高说明模型基本能框住目标，但边界框与真实框有较大浮动也能接受。
• mAP50-95：更严格的目标检测综合指标。它对边界框位置精度的要求更高。如果这个指标明显偏低，说明模型的坐标回归能力还不足，检测框经常偏移。
• 精确率与召回率：我分别统计了“跌倒/躺倒”这一类别的精度和召回率。精确率要的是减误报，召回率要的是减漏报。业务场景里漏报更严重，所以我的方向是“保召回率，精确率通过后处理兜底”。

训练完成后，官方会输出best.pt和last.pt两个权重文件。不要直接把last.pt拿去部署，它极大概率不是验证集指标最高的版本。best.pt才是训练结束时验证集表现最好的那个checkpoint。后续如果要调整训练数据或参数，建议在best.pt基础上继续，而不是从头再来。

4. 部署与性能优化：从权重到边缘设备

4.1 先做精度确认，再导出推理格式

模型训练完先别急着打包上设备，先在本地测试集上做一轮推理效果巡检，把那些典型误报图、漏报图打印出来看一下。我通常会把置信度阈值调到0.25，把测试集里所有预测结果叠加到原图上，检查模型在真实场景里的表现。这一步的产出是“可信度结论”，确定阈值高一点还是低一点，是决定后续告警敏感度的基础。

确认精度在可接受范围后，再把PyTorch模型导出为推理引擎格式。我部署的边缘盒子支持TensorRT，所以导出命令是得用half=True，也就是FP16精度。这一步能把推理速度提升一个量级，后面详细说。

yolo export model=runs/train/exp/weights/best.pt format=engine imgsz=640 half=True device=0

一些模型在导出为TensorRT引擎时会有精度损失，所以导出后我还会跑一遍同等测试集，把mAP对比一遍。如果出现明显下降，就回头检查训练盒子上预处理器和模型输入尺寸的配置是否符合导出时的要求。

4.2 边缘设备部署方案

我部署的目标设备是一台低功耗边缘计算盒子，算力不高但胜在便宜、稳定、无风扇设计，适合安装在天花板或走廊角落。这类设备的系统环境是精简过的Linux，Python环境和桌面环境都折腾得比较彻底，因此部署策略是这样的：

• 主体推理代码用Python写，调用TensorRT的Python绑定接口加载engine文件。
• 视频流读取用OpenCV的RTSP拉流接口，把摄像头的网络视频流转换为帧数据。
• 推理输出的是张量，需要后处理解析出检测框、类别、置信度，然后传给业务逻辑。

这里有个非常关键的部署细节：摄像头出来的视频分辨率并不一定是640×640，而模型输入要求固定的640×640。所以推理前必须做图像缩放与填充。我维护了一个“等比例缩放+灰边填充”的函数，保证图像内容不变形，同时把实际缩放比例记录下来。检测框坐标从这个640×640的坐标系转换回原始图像分辨率时，必须利用这个缩放比例反向换算，否则后面的框画出来所有位置都偏移。

很多教程这一步是放过去的，但实际部署时，画框位置错位、告警截图区域错误，十个里面七个都是坐标变换没做对。

4.3 推理速度优化：不只是快

YOLOv8s + 640输入 + TensorRT FP16，在边缘盒子上的推理速度大约能到30毫秒一帧，也就是接近30FPS。如果还需要进一步压榨性能，可以依次尝试这几招：

1. 降低输入分辨率。640降到576或512，速度立马上来，但对小目标的影响也最直接。如果你的摄像头视角里人比较大，这个方案很划算。
2. 改用YOLOv8n模型。n版参数量大概是s版的四分之一，推理速度快很多，代价是精度下降。如果部署端算力实在太弱，n版是最后的退路。
3. 减小检测头输出规模。对只有一两个类别的场景，输出层可以裁剪，但这种改动需要重新训练和导出，操作繁琐，一般不到最后不用。

推理耗时之外，整个链路的耗时同样不能忽视。RTSP拉流本身就有延迟，加上多路视频并发时CPU参与编解码的开销，模型推理只占全线耗时的三分之一。如果要做多路视频，优先给每路视频分配一个独立拉流线程，推理再统一回收到一个线程里，避免多线程并发推理挤爆GPU。

4.4 后处理业务逻辑：从“检出跌倒”到“触发告警”

模型输出的只是“这一帧里有人跌倒”，离业务需求的“向后台发出告警”还差三层处理：

第一层是置信度阈值。我最终把置信度阈值定到了0.45。阈值太低了，误报框全漏进来，后台会被淹没；阈值太高了，低质量画面里的真实跌倒又可能漏检。这个值没有标准答案，建议在自己的测试集上画出一个准确率-召回率曲线，再结合业务对误报的容忍度拍板。

第二层是连续帧确认。单帧检出不足以采信，因为画面噪声和运动模糊会偶发产生假阳性。我的做法是设一个连续帧状态机：检测到fall后开始计数，连续3帧都检出fall，才进入预备告警状态；如果当中有一帧显示站立或蹲坐，计数清零。这层逻辑把很多偶发误报直接过滤掉。

第三层是停留时间判断。跌倒后如果人马上站起来，不需要告警；只有跌倒状态持续超过比如10秒，才触发紧急告警。这样处理能明显减少“假跌倒”造成的无效告警。判断时长需要跟现场客户确认，有的场景希望更敏捷，有的场景害怕打扰，这段参数最好做成配置项而不是写死。

业务后台方面，我只是做了一个非常轻量的告警服务：接收告警事件，保存当前帧截图为证据图，同时把事件推送至管理人员。告警截图最好存下来，因为它是事后追溯的重要凭证。

5. 落地避坑：误报、漏报与现场问题排查

5.1 真实场景里的典型误报

这个项目里最费精力的不是训练，而是现场反复出现的误报问题。挑三个最有代表性的讲：

第一个是影子误报。傍晚阳光斜射，人的影子被拉得很长，影子在地面上的轮廓在某些帧里会被模型当成人形目标，尤其当影子与本体分离时，会检出一个看起来像躺在地面的“人”。解决思路是尽量避免朝向窗户的机位，同时训练数据里加入大量含有影子的负样本。还有个后处理补救办法，利用影子目标运动特征与真实目标的差异进行过滤，但性价比不如前两者。

第二个是椅子和沙发误报。躺进沙发里玩手机的人，远看姿态就是“人体横向分布”，和跌倒写征非常接近。单靠视觉几乎无解，只能靠后处理状态机加“停留时间”来抑制，短时间的躺卧不会触发告警。真遇到长时间赖在沙发上不动，那就只能承认这是系统的合理告警，严格说也不能算误报。

第三个是相机抖动与夜间噪声。老式摄像头或网络传输不稳定时，视频流会自动丢帧，偶尔会出现画面跳动的瞬间，导致检测框突然抖动甚至闪现。我在后处理里加了一个检测框最大位移限制，如果下一帧框的位置相比上一帧发生超过画面宽度一半的跳变，就判定为跟踪异常并忽略该帧。

5.2 排查与调优速查表

现场出现问题，最有用的是一张能快速对照排查的表。下面是我自己整理的：

先分清楚问题属于“模型层”还是“工程层”。模型层问题一般表现为对真实场景数据不敏感，工程层问题一般表现为坐标错误、帧率不稳、告警逻辑缺陷。判断方向对了再动手，省时间。

5.3 效果复盘与后续扩展方向

这个项目做下来，最终实机表现让我比较满意。线上测试统计了大概一周，跌倒检测的召回率在测试集上达到92%以上，误报率控制在约一天一次的水平，而每次误报集中出现在下班时段的光影剧烈变化期间。老人照护场景的反倒是“漏报”的代价更大，所以我对召回率的容忍度要高于误报率。

后续如果继续迭代，我会优先做三件事：

一是时序信息引入。给模型输入连续几帧的差分信息或直接接一条轻量级时序模块，让跌倒动作本身的速度特征参与判断，甩开静态姿态死磕蹲坐类问题的老路。

二是多目融合。单摄像头遮挡是硬伤，可以用两个摄像头从不同角度覆盖同一区域，两个通道的一致判断能显著降低遮挡导致的漏报。

三是端侧告警分级。把跌倒检测与睡眠监测、久坐提醒、区域入侵检测结合起来，让这套模型从一个独立功能升级成一套综合场景守护系统，这对实际部署的工程价值远大于某一指标的改善。

最后分享一个小技巧：实机调试时，把模型预测的“置信度值”和“检测框坐标”一并打印到视频输出画面的角落，这个细节会帮你在现场快速判断问题出在检测环节还是后处理环节。我在项目收尾阶段一直靠这招定位问题，省下了不少对着监控录像反复回放的笨功夫。