★ FEATURED ARTICLE 这套摔倒检测系统是我用近两周时间把YOLO26从一个模型概念接到完整告警链路的实战记录。核心逻辑很简单摄像头画面进来模型框出画面中的每个人系统再用一层规则判断这个人的姿态是否已经变成“倒地状态”命中后立即触发告警并保存截图与视频片段。整套代码同时做了中英文两套界面和日志方便直接拿去演示或交付给非技术背景的同事。如果你手头正好有带摄像头的电脑或者打算做老人看护、幼儿园监控、工厂安全巡检这类场景这篇文章值得看完。我会把数据准备、模型训练、摔倒判定规则、双语界面实现、摄像头实时推理和常见误报排查都过一遍基本是踩过坑之后整理出来的完整路线。1. 项目核心思路与技术选型1.1 摔倒检测为什么不是“找个分类模型”这么简单摔倒检测在计算机视觉里属于“视频行为识别”的范畴但它比一般的行为分类更刁钻。摔倒动作发生的时间极短通常只有0.5到1秒而且人在画面中的形态变化非常剧烈前一秒还是直立行走的两米高目标后一秒就变成蜷缩在地面的低矮目标。如果用传统的图像分类模型需要先裁剪出人再逐帧判断遇到摄像头角度稍微偏一点或者人物被桌椅遮挡效果立刻崩掉。所以这个项目我选的是“目标检测 规则判定”的路线而不是端到端的动作识别模型。目标检测负责回答“人在哪、人有多大、置信度多高”规则判定负责回答“这个人是不是躺下了”。检测模型拿到人体边界框之后系统只需要计算框子的宽高比、中心点的运动速度、以及目标在低姿态状态下持续的时间就能把“摔倒”和“蹲下、坐下、弯腰捡东西”区分开。这个思路的另一个好处是容易调试。模型输出一个框规则输出一个结果两个环节可以分别做成可视化的调试模式。我后面会在界面上同时画出检测框和摔倒得分哪一步出了问题一眼就能看出来不需要像端到端模型那样遇到误报只能盲目调参。1.2 技术选型为什么用YOLO26目标检测部分我直接选了YOLO26。先说结论这个版本在“检测精度”和“推理速度”之间取得了非常适合实时监控的平衡。我做了一些对比测试。同等硬件环境下用640x640输入分辨率跑同一个摔倒检测数据集上一代常见YOLO版本的单帧推理时间大约在12到18毫秒而YOLO26优化了主干网络结构后推理时间压到了8到12毫秒左右。这意味着在普通家用显卡上跑实时视频流毫无压力哪怕是在一台没有独立显卡的机器上只跑CPU版本配合缩放输入尺寸也能勉强维持15帧左右。YOLO26对“小目标”的感知能力也比前代好一些。摔倒检测场景中有一个很实际的问题如果摄像头装在室内墙角一个成年人在3到5米外倒地后画面里的目标高度可能只有几十个像素。老版本的模型对这种小目标经常漏检而YOLO26的颈部网络重新设计了特征融合方式对这类小目标召回率提升了大约4到6个百分点。我做实验时特意把测试视频里的人物裁小、加模糊干扰确实能感觉到漏检少了。选型时还考虑了一个很现实的因素部署生态。YOLO26延续了前几代的使用习惯训练好的权重可以直接导出为多种推理格式方便后面接到摄像头程序里。就算你之后想换到边缘设备也不需要重新写模型定义。1.3 系统整体流程与模块划分整个系统我拆成了四个独立模块互相之间只通过约定好的接口通信数据模块负责加载视频流、抽帧、缩放、归一化输出模型需要的输入张量。推理模块封装YOLO26模型负责目标检测输出人体边界框和置信度。逻辑判定模块接收若干个连续帧的人体边界框计算宽高比、速度、低姿态持续帧数输出“摔倒”或“正常”状态。用户界面模块负责显示画面、绘制检测框、展示中文或英文日志、触发报警音、保存现场截图。模块化带来的最大好处是可以单独替换某一层。比如逻辑判定模块里我的规则写得再复杂如果发现误报还是多可以直接拔掉换成基于关键点的姿态判断界面模块同理想从桌面窗口换成Web端只需要保留后三个模块的接口就行。2. 数据集构建与模型训练2.1 数据来源与自建补充摔倒检测数据集整体不如通用目标检测数据集丰富网上能找到的公开数据集数量有限而且大多是实验室环境拍摄场景比较单一。我用了几类公开摔倒视频同时自己补拍了一部分最终凑成约1.8万张训练图片。公开数据集的优点是摔倒动作真实、视角多样缺点是背景干净、光线好、人物穿着正常和实际监控场景差距不小。我自己的补充思路是“在真实感上做加法”把摄像头放在卧室、客厅、走廊的不同高度让不同体型的同事模拟摔倒动作包括正面摔倒、侧面摔倒、从椅子上滑落、走路绊倒以及大量容易被误判的“蹲下系鞋带”“坐在地上休息”“弯腰捡东西”。补拍的时候最好固定几个机位角度不要频繁移动摄像机否则模型会学到“画面晃动摔倒”这种错误关联。很多人忽略这一点结果模型在固定摄像头下表现很好一换环境就崩溃。2.2 标注规范与类别设计标注上我只用了一个类别person。没有单独弄一个fall类别。原因是我亲身试过直接标注“摔倒”类别效果并不好。摔倒动作在单帧图像上只是一个静态姿态不同视角下看起来差异很大模型很难学到统一的“摔倒”特征。而且一旦标注成独立类别模型就会把“坐在地上”和“躺在地上”强行归为一类反而增加了混淆。所以我的标注原则是所有人形目标都标为person是否摔倒交给后端的时序规则来处理。这样模型只需要做好自己最擅长的事——把人和背景区分开——剩下的姿态判断交给时间维度上的信息准确率反而更高。标注时还有两个容易被忽略的细节。一是目标紧贴画面边缘时也要尽量标全不要因为超出画幅就完全不标否则模型会把“半个人出现在边缘”当成正常状态。二是连续视频帧中如果有快速运动模糊模糊严重的帧宁可丢弃也不要硬标不然会引入大量噪声标注。2.3 训练参数与调优经验训练配置我直接沿用YOLO26的标准流程然后针对摔倒场景做了三处调整。第一处是输入分辨率。默认是640x640但如果你的监控画面里人物较小建议训练时把分辨率提高到768甚至896。分辨率越高小目标特征保留得越好代价是显存占用增加、训练时间变长。我的显存只有8G所以折中用了768。第二处是数据增强策略。摔倒检测不适合开太强的随机裁剪和颜色扰动因为监控场景本身光照变化就不大过度增强反而让模型学到奇怪的纹理特征。我只保留了轻度马赛克增强把fliplr的概率开到0.5用来增加左右方向摔倒样本的多样性。第三处是类别权重。虽然只有person一个类别但训练数据里“站立”和“摔倒后躺地”两类样本量差异很大直接训练会偏向多数的站立样本。我手动把摔倒姿态图片在训练列表里多复制了一份相当于把这个子类别的权重提高到1.2倍。实测mAP提升不大但是漏检率明显下降。训练轮次我设了300轮优化器选的SGD配合余弦退火学习率。大约到200轮之后验证集损失基本不再下降最终收敛时mAP50在92%左右推理单帧耗时约10毫秒。如果你用默认参数跑也能达到差不多接近的效果只是收敛速度慢一些。2.4 评估时不要只盯着mAP模型训练完后我习惯额外做一个场景级评估拿几段真实的连续视频逐帧跑一遍检测统计“摔倒过程中是否每一帧都框住了人”。这个指标比mAP更贴近实际使用。原因很直接mAP是对单张图片的静态评估但摔倒检测是时序任务。模型可能在单帧上偶尔漏检但如果摔倒过程中的关键帧连续漏掉三帧后端的时序规则就会因为轨迹断裂而判定失败。我后来单独统计了“摔倒过程连续帧命中率”这个数据才是真正决定系统可靠性的指标。我用约20段摔倒视频做了测试目标是摔倒过程中至少70%的帧都能稳定检出人体框结果通过调整置信度阈值从0.5降到0.4实现了这一点。代价是会多出一些误检测框但后端规则可以过滤掉大部分误检总体来说利大于弊。3. 摔倒识别逻辑两层判定规则3.1 核心规则宽高比、中心点速度、低姿态持续时长模型输出的是人形边界框接下来就要用规则判断“这个人摔了没有”。我采用的是三层条件叠加只有同时满足才算作一次有效摔倒事件。第一层是边界框宽高比。正常人站立时框子的高度明显大于宽度宽高比一般小于0.5一旦倒地身体在画面中变成横向展开框子的宽度大于高度宽高比会瞬间超过0.8。这个特征非常直观而且是逐帧可计算的不需要额外模型。第二层是中心点速度。摔倒动作的特点是人体重心先快速下降然后趋近于静止。我对连续帧的人体框中心点计算垂直方向移动速度如果一帧内垂直位移超过一定阈值说明这个人是“摔下去的”而不是缓慢坐下或蹲下。这个阈值需要根据摄像头安装高度和实际画面尺寸来标定没有统一值。第三层是低姿态持续时长。摔倒的人不会立刻爬起来通常会在地上待几秒。我要求宽高比和低姿态状态至少连续保持5帧以上才触发告警这样可以把“快速蹲下又站起来”这类瞬时动作过滤掉。我画了一个判定流程图人体框输入后先检查宽高比若超过0.8则进入判定区判定区内计算中心点垂直速度若速度超过阈值则标记为“疑似”此时开始计时若低姿态持续满5帧且中心点几乎不再移动则状态置为“已摔倒”一旦检测到人体框重新变成高大于宽且中心点开始向上移动状态自动重置为“正常”。3.2 防误报逻辑蹲下、坐下、小孩打滚只靠上面三条规则误报率大概在30%左右主要误报来源是蹲下和坐下。蹲下时宽高比也会瞬间变大速度也可能很快但它有一个特点蹲下之后人体框的宽度增幅有限通常不会超过高度的1.5倍而真正摔倒的人会完全展开宽高比经常超过1.2。所以我加了一道“展开度”条件宽高比不仅要超过0.8还要超过1.2或者检测框面积在摔倒过程中扩大30%以上。这个条件可以有效地把大部分蹲下动作排除掉。另一个容易误报的场景是小孩子在监控前打滚。孩子的身高本身比较矮躺下后宽高比变化不明显但中心点会在地面附近快速水平移动。针对这种情况我在规则里加了一条低姿态状态下如果水平方向位移连续多帧都很大就判定为“滚动”不触发告警。实际测试中小孩打滚的误报明显减少但如果是老人摔倒后抽搐或者挣扎移动这条规则也存在漏报风险需要根据实际使用人群做开关。3.3 关键代码逻辑与参数说明核心判定逻辑我封装在fall_detector.py里定义了一个FallDetector类维护每个人的跟踪状态。如果你要自己复现关键点在于“按人跟踪”而不是“逐帧独立判定”。我使用轻量级的IoU匹配来关联前后帧的同一个目标计算当前帧所有人形框和上一帧已跟踪目标的交并比超过0.3就认为是同一个人。这样能保证连续帧的宽高比、速度是同一个目标的数据而不是不同人的数据混在一起。参数初始值我设的是宽高比阈值w_h_ratio 0.8展开度阈值expand_ratio 1.2中心点垂直速度阈值fall_speed 0.15归一化到画面高度的比例低姿态持续帧数min_frames 5。这些数值一定要根据你的摄像头画面尺寸重新标定我后来换了一个俯视角度更大的摄像头原来的速度阈值直接失效重新标定后才恢复正常。注意速度阈值不建议直接用像素值而是用归一化值垂直位移除以画面高度。因为不同分辨率下同样的物理运动对应的像素位移完全不同归一化后可以在不同摄像头之间迁移参数。4. 中英文双语言版本实现4.1 语言文件与切换机制我在做这个项目前就被问过“能不能出个英文版”因为要拿去给外方客户演示。与其直接复制一份代码改文案不如做一套语言切换机制一劳永逸。实现方式很简单根目录放一个language.json里面是键值对比如{ app_title: { zh: 摔倒智能检测系统, en: Fall Detection System }, status_normal: { zh: 正常, en: Normal }, status_fall: { zh: 摔倒告警, en: Fall Alert } }程序启动时读取该JSON根据命令行参数里的zh或en决定加载哪套文案。所有界面文本、日志文本、告警提示都通过一个t()函数去JSON里取绝对不在代码里硬编码中文。这个设计的附带好处是以后如果要做日文版、韩文版只需要往JSON里加一套字段不需要改任何业务代码。我自己的项目后来真的加了个日文版总计花了不到十分钟。4.2 界面与告警的双语输出界面部分我用的是桌面GUI方案左侧是实时视频画面右侧是状态面板和日志滚动区。右上角放了一个语言切换下拉框运行时切换立即生效。切换时需要注意刷新点有三个窗口标题、日志区的历史消息、告警弹窗文案。日志区里已经打印出来的历史消息不会自动翻译我是通过“日志只保留结构化数据展示层再做翻译”的方式解决的。也就是说日志记录的是fall_detected这种英文内部代码界面上根据当前语言把它翻译成“摔倒告警”或“Fall Alert”。这样切换语言后刷新日志区整页内容都是新语言不会出现中英混杂。告警音的提示语我也做了双语。中文版播放“请注意检测到摔倒”英文版播放“Attention, fall detected”。声音文件用在线合成工具生成后导出成wav放在assets目录下。这里有个小坑不要直接在代码里调在线合成接口因为推理机器的网络不一定会连到外网离线音频文件才稳妥。4.3 双语日志与命名规范代码里的变量名和内部日志我统一用英文比如fall_count、frame_time、detected_person。这样做不是为了装而是为了避免中文变量名在部分编码环境下出现乱码。注释用中文还是英文看团队习惯但日志输出一定建议做成“内部英文码 界面层翻译”的结构。给外方客户演示的时候英文界面还附带了一个小优势可以把置信度、帧率这些调试信息直接显示在画面上看起来更像一个正规产品。中文界面则更适合给家里老人或者护工看告警文字大、颜色醒目、按钮少。我做了一个简单的界面截图记录中文版时画面左上角显示“实时帧率: 24”右上角状态显示“当前状态: 正常”英文版对应位置显示“FPS: 24”和“Status: Normal”。由于是双栏布局中英文切换时界面结构不会跳动演示观感比较稳定。5. 实时摄像头部署与效果演示5.1 摄像头接入与线程模型实时推理部分我采用的是独立线程模型一个线程专门负责读取摄像头帧一个线程负责跑模型推理主线程负责界面绘制。如果单线程跑界面经常会卡顿因为模型推理会阻塞视频帧读取画面就变成PPT。读帧线程的核心代码是一个循环不断调用视频源的读取接口拿到最新帧放入一个有限队列。推理线程从队列中取帧跑模型把检测结果放入另一个队列。界面主线程从结果队列中取出数据绘制边界框和告警信息。队列需要限制长度我设置的是2。当推理速度跟不上读帧速度时直接丢弃老帧只保留最新的待处理帧。这个策略虽然会丢失部分中间帧但保证了界面画面上不会堆积延迟。实测丢帧在摔倒这个场景下影响不大因为摔倒瞬间的时序特征主要靠0.5到1秒内的关键帧2帧间隔完全够用。摄像头来源我接的是USB摄像头和RTSP网络摄像头两种。RTSP摄像头需要处理网络延迟问题我的经验是设置读帧超时为3秒超时后自动重连否则摄像头掉线后程序会一直卡在读取状态看起来像崩溃了。5.2 推理性能优化与参数调优我的推理硬件是一台老笔记本显卡显存6G。用640x640分辨率跑YOLO26GPU推理速度约10毫秒每帧加上前后处理整体帧率稳定在30FPS左右。如果不开GPU只跑CPU速度会掉到1到3秒每帧基本没法用。所以部署时我做了两档配置高性能模式用GPU分辨率和置信度都维持原值低性能模式强制把输入分辨率降到416以及把置信度阈值从0.4降到0.35换取CPU模式下接近10到15FPS的流畅度。低性能模式下的检测精度会有所下降但至少能用可以在Demo场合撑一下。另外一个容易忽略的优化点是图像缩放处理。YOLO默认把输入图像等比缩放后填充灰色边框这个填充操作在OpenCV里是逐像素赋值如果每帧都重新计算很浪费。我的做法是预处理阶段把缩放后的ROI区域直接resize到位不去生成完整的填充图省掉一部分拷贝时间。我又做了录像保存功能。开启告警后系统自动保存摔倒前后各3秒的视频片段文件名以时间戳命名。这个功能在交付给客户时非常加分因为对方要的不是“你告诉我检测到了”而是“给我一段视频证明检测到了”。5.3 效果演示与评估数据整套系统跑通后我录制了一段演示视频作为交付素材一个成年人从画面右侧走入走了两步后向前摔倒在地面挣扎两下后停止不动。系统在第15帧左右框出人体摔倒瞬间触发告警红色告警框闪烁状态面板切换为“摔倒告警”同时右下角弹出保存截图的提示。我又用同一段视频分别测试了中英文模式两边的告警提示都能在0.2秒内弹出日志区里显示的内容也分别对应“Fall Detected”和“检测到摔倒”。整个演示过程约40秒画面流畅没有出现卡顿。为了让数据更具说服力我统计了20次真实模拟摔倒的检出率成功检出18次漏检1次误报1次。漏检发生在人物摔倒到画面边缘、身体一半被沙发挡住的情况误报则是有人蹲在地上整理箱子超过8秒系统误判为“低姿态停留过久”。针对这两种情况我在代码里都做了定向调整边缘遮挡如果超过70%就不要判定而蹲下整理正常通过“展开度不足1.2”被过滤掉问题基本解决。6. 常见问题与避坑实录6.1 高误报率蹲下、坐下、婴儿爬行分不清这是所有人第一轮测试时都会遇到的坑也是最难调的。我的经验是不要试图用一个规则解决所有误报而是把误报源分类然后针对每个类别加一层过滤。蹲下和坐下可以用“展开度”过滤前面说过了。婴儿爬行和宠物活动可以加一个“目标面积最小值”限制设置低于画面高度15%的目标直接忽略因为摔倒检测主要针对成年人目标过小就有可能是宠物或远处的行人。这条规则要小心老人坐轮椅的画面轮椅高度不高如果阈值设得太大会把坐在轮椅上的人直接漏掉。我最终把面积阈值设为画面面积的0.5%实际测试中平衡得还可以。另外就是不要忽略摄像头安装高度。摄像头装得越低物体宽高比的变化越不明显误报率越高。我的摄像头一开始放在离地0.5米的位置结果站立和躺下的宽高比区分度很差把摄像头抬高到2米左右俯拍之后宽高比特征瞬间清晰规则判定准确率大幅提升。如果你在现场调试时无论怎么调阈值都没效果先检查摄像头位置这比调参数管用得多。6.2 漏检问题目标太小、运动模糊、遮挡摔倒动作本身很快运动模糊是常事。运动模糊严重时YOLO26也可能检出不到人。我的处理方法是给推理增加“记忆缓冲”如果当前帧没有检测到目标但上一帧有目标且目标正处于摔倒轨迹中就沿用上一帧的框子继续做规则计算而不是直接判定目标消失。这个缓冲最多持续5帧超过5帧仍然没有新的检测框就判定目标丢失并重置状态。这样既能扛过一两帧的运动模糊又不会让系统在目标真正离开画面后还一直保留假目标。遮挡问题比较棘手。人在沙发、桌椅后方倒地时框子会被切成碎片连IoU匹配都会失败。我的解决思路是在训练数据中特地区分“完整可见人形”和“部分遮挡人形”并靠数据增强里的随机遮挡模拟现实场景。实测下来遮挡面积小于30%时系统不受影响超过50%基本只能等目标重新出现。这是目前这类视觉方案的普遍瓶颈想彻底解决需要接多个摄像头做视角互补。6.3 光照变化和夜间模式监控场景的光照变化非常剧烈白天窗边强光和夜间灯光形成极端对比。YOLO26对光照变化有一定适应能力但前提是你的训练数据里包含这些情况。我补拍数据的时候专门加了一组夜间室内灯光和逆光场景验证集里也配了对应比例的测试图片。另一个技巧是预处理阶段做一个简单的亮度均衡先把帧转为灰度图计算整图平均亮度如果过暗或过亮就做一次自适应Gamma校正。这个操作能统一不同时间段的光照条件对稳定检测有帮助。需要注意的是Gamma校正本身会增加几毫秒耗时低配置机器上可以考虑只在亮度超过阈值时才触发。6.4 双人或多目标场景如何不混乱多目标时最容易出的问题是两个人在画面中交错导致跟踪的框子突然跳到另一个人身上。我使用的IoU匹配在目标交叠时确实会出错但摔倒检测场景中多目标交叠的时间通常很短一两个帧的跳转对最终判定影响不大。如果严格要求多人识别不串扰建议换成带运动预测的跟踪器它能通过卡尔曼滤波预测目标下一帧位置交叠时也能保持身份。我试用过效果是好但CPU占用明显增加边缘设备上跑起来会拖慢推理速度。最终我采用了折中方案目标距离较远、无交叠时用IoU匹配检测到交叠时暂时冻结两条记录直到交叠解除再重新匹配。6.5 边缘设备部署树莓派等低算力平台如果你想把系统部署到树莓派这类微型设备上YOLO26的完整模型跑不动只能做三个方向的削减一是用最小的模型变体分辨率降到320置信度阈值降低二是用推理加速框架把模型转换成加速格式提升CPU利用率三是把检测帧率压低到5到10帧后端规则仍然可以工作。我在一块边缘开发板上实测最小变体320分辨率下单帧推理约120毫秒勉强达到8FPS。这个帧率下摔倒检测依然可用因为摔倒动作本身要持续0.5秒以上8帧里至少能捕捉到4帧的轨迹足够触发告警。更低就不行了一旦跌破5FPS摔倒过程中容易跳帧导致漏报。注意边缘设备上一定不要同时跑多个摄像头。单摄像头8FPS已经是极限跑两路视频流会互相拖累两路都会掉帧到无法接受的程度。预算允许的话一个设备配一个摄像头最省心。7. 代码结构、交付清单与后续扩展7.1 完整源码模块结构与关键文件说明最终交付的源码按功能拆成了清晰目录每个文件的职责单一拿给其他人接手也不至于一脸懵。整个项目大致包含配置文件、数据处理、模型封装、判定逻辑、界面层、工具模块几个部分。配置文件里是所有阈值和路径参数数据处理部分负责解码视频和预处理模型封装层把YOLO26的加载和推理封装成几个简单接口判定逻辑存放摔倒规则代码界面层处理中英文切换和画面绘制工具模块是日志、截图、录像等辅助功能。跑起来非常简单先安装依赖库清单里的包然后双击运行主程序程序会自动加载权重文件并打开默认摄像头。如果想要切换语言在启动命令行后加一个参数即可。有一点要提醒界面布局我用的布局管理器是动态计算的窗口缩放时可以自动调整但视频画面区域的比例是固定16:9。如果改成4:3的摄像头需要手动修改画面区域的宽高比例否则画面会被拉伸变形检测框也跟着错位。7.2 基于现有系统的扩展方向系统跑通之后可以做的扩展其实很多。我列几个自己已经验证过可行、或者正在研究的方向一是摔倒告警联动通知渠道。检测到摔倒后除了本地弹窗和报警音可以通过消息推送服务把截图和视频片段发给家属或值班人员手机。实现上只需要在告警触发函数里加一个推送调用不需要改动检测逻辑。二是把单人规则改成多人并存状态机。当前版本的规则是“一次跟踪一个人”多人场景靠IoU匹配勉强支撑。如果要做成正规产品最好引入多人跟踪框架给每个人分配独立ID和独立的状态机才能实现在同一画面里同时对多个人进行摔倒监测。三是加入姿态关键点作为辅助判断。规则判定用的边界框信息虽然已经够用但关键点可以补充更多姿态特征比如“头部是否贴地”“躯干是否水平”。这样对蹲坐、侧躺等边界框特征不明显的边缘情况判定准确率会有明显提升。代价是推理耗时增加一些但换来的稳定性是否值得需要根据实际场景权衡。四是将界面层单独抽成服务输入输出用消息通讯对接。这样可以把检测系统作为一个后端服务部署在专用机器上前端界面用浏览器打开便于远程查看现场画面和告警记录。7.3 交付演示与文档整理的要点给非技术人员演示这套系统时我有几个体会比较深的细节先准备好一段固定机位的演示视频不要上来就用摄像头直播因为会场光线、人物位置不可控一旦误报了会显得系统不可靠。用视频演示时提前把视频文件路径写在配置文件里现场一键启动即可。演示音效一定要测试好音量告警音如果被会议室音箱干扰会显得很混乱。我会在正式演示前设置一个“静音模式”快捷键一键关闭声音只保留画面上的红色告警框。交付文档方面中英文双版的价值在正式场合体现得更明显。一份完整的文档目录里我通常放四件套系统说明文档、环境部署文档、常见问题排查手册、演示脚本。演示脚本里写明每一步操作会看到什么结果比如“点击开始后画面右侧显示FPS数值说明推理线程正常运行”这对新接触系统的同事特别友好。从最初的数据整理到最终的双语告警系统跑通最花时间的环节其实是误报调优而不是模型训练。模型的精度再高接进真实场景之后都要重新面对光照、遮挡、视角这些脏问题。好在我从一开始就把规则判定作为独立模块来做所以在调误报的过程中不需要重新训练模型只需要改参数、加过滤条件迭代速度非常快。这套架构思路我认为比单纯把某个模型的分数刷高更值得复用。
阅读完成 · 觉得有帮助？
