简介这是一份基于YOLO的智能安防监控系统完整方案面向毕业设计、课程设计学生及希望快速上手目标检测与全栈开发的深度学习开发者。资源将YOLO实时检测能力与前端可视化结合演示了从模型推理到告警日志、系统监控的闭环流程适合作为实训项目或系统原型参考。压缩包共89个文件大小约12.94MB以TypeScript前端源码tsx/ts为主辅以JSON配置、CSS样式、ONNX模型文件及PDF设计文档既有可运行的界面代码也有说明性资料结构清晰便于对照学习。目前已有28人学习下载。通过本方案读者可以了解如何在React与Supabase框架下集成YOLO模型完成目标识别学习系统健康监测、推理指标展示与安全日志记录等模块的设计思路同时也能参考其前后端交互与工程化配置用于自身项目的扩展与二次开发。1. 一套“基于 YOLO 的智能安防方案”先搞清楚它解决什么值班室同时挂着 16 路监控画面真正靠人眼盯盯不过 20 分钟等出了事再翻录像黄花菜都凉了。基于 YOLO 的智能安防监控系统方案做的就是把这 16 路画面变成一路“自动值班员”实时框出人、车、烟雾、安全帽按预设规则判断入侵、越界、人员聚集再决定截图、录段还是推送告警。这套方案的产物就是一个配套好模型、拉流脚本、推理服务、告警配置的 zip 包解压后按顺序跑就能把检测结果接到业务里。适合做园区、工地、工厂、仓库安防集成的开发者也适合想给已有摄像头加“大脑”的团队但不适合指望解压即完美、三维标注都不用做的新手。模型精度是数据喂出来的方案能给你的是地基没必要神话那个 zip。2. 方案整体框架与 YOLO 选型先定模型边界再写第一行业务代码2.1 安防场景为什么绕不开 YOLO三个硬约束决定选型拿到“智能安防”这个需求最怕一上来就谈算法排名。先看安防场景的三个硬约束第一画面是持续视频流单帧推理必须快30 帧的流给一帧的预算不能超过 33ms第二检测目标相对固定翻来覆去就是人、车、安全帽、反光衣、烟雾这几类不需要开放世界识别第三部署环境往往不是满血显卡可能是工控机、边缘盒子甚至一台旧 T4 服务器显存和功耗都是紧巴巴的。这三个约束叠加YOLO 几乎是默认答案。两阶段检测器精度高但慢在第二阶段的逐个候选框分类上到了多路并发就顶不住基于 Transformer 的检测器在小目标上有优势但是参数体量和延迟在安防这种长稳运行场景里容易翻车。YOLO 单阶段直接把分类和回归合在同一个网络里输出训练和部署一致性也高从 PyTorch 到 ONNX 再到 TensorRT 的链路被踩得非常成熟。还有一点常被忽略安防项目要长期迭代。今天只检测人下周客户可能就要检测倒地、聚集、烟火模型要能增量微调。YOLO 社区的资料、预训练权重、标注工具链最全招人也容易。很多讲 YOLO 算法讲解 PPT 的都会强调参数量越小越好但在安防里过小的 n 级模型对远距离小目标经常漏检选型要在“跑得动”和“看得清”之间妥协。我的习惯是先用 YOLOv8m 在真实监控截图上看效果再看推理耗时决定要不要降到 s 或 n而不是一开始就追求轻量。2.2 一份标准方案包里先有什么文件结构与跑通顺序我做这类方案zip 包一定按“模型、拉流、推理、业务”四层组织避免整个目录堆成一锅粥。你拿到的方案如果没写说明大概率也能按这个结构对号入座。文件路径作用落地要点weights/ 目录预训练权重与最终微调权重至少保留一个 COCO 80 类基础模型和一个业务微调模型datasets/ 目录数据集 YAML 与类别定义类别顺序一旦确定不要随意改改一次要重新训练scripts/train.py训练与微调入口参数化 batch、epoch、img-size方便不同显卡复用scripts/export.py导出 ONNX/TensorRT 引擎固定 opset 与动态 batch 开关services/rtsp_ingest.pyRTSP 拉流、解码、丢帧策略多线程 队列不能与推理耦合在主循环services/infer_server.py推理服务与后处理包含置信度阈值、NMS、类别映射services/alarm_dispatcher.py告警判别与推送ROI 规则文件独立存放修改规则不重启服务rules/roi.json区域划定与规则参数用多边形顶点描述支持越界与入侵判别README.md启动顺序与依赖说明写清 CUDA、TensorRT、OpenCV 版本跑通顺序有讲究不要先折腾视频流。第一步只做图片推理拿一张监控截图跑通 weights detect 脚本确认模型能出框第二步才接 RTSP用一帧一帧的画面验证推理稳定性第三步加业务规则先出告警记录再谈推送最后做多路并发压测。顺序反了你会分不清到底是拉流卡顿还是模型推理慢排查时非常痛苦。2.3 模型版本与分辨率怎么选用损失函数和帧率预算说话模型选型不能拍脑袋。YOLO 家族里v5 的工程生态稳v8 的检测头设计对尺度变化更友好v9、v10 也有自己的卖点但安防项目里我不追新。追新的代价是 TensorRT 算子兼容性要重新验证而安防系统一跑就是几个月稳比新重要。v8n/s/m 三个量级分别对应边缘盒子、低端显卡、中高端显卡。分辨率通常是 640 起步但安防的监控画面视野广人脸、安全帽这类小目标在 640 下只有十几个像素很难检出。我的做法是近景机位用 640周界和远景机位用 1280 或 960 输入再配合裁剪推理。分辨率提高一倍推理耗时增长不止一倍这一步必须靠压测数据决定。损失函数在这里不是纯理论问题。安防数据的类别极度不平衡白天“人”出现几千次“翻越围栏”可能只有几十次。YOLOv8 的损失由分类损失、边框回归损失和 DFL 组合而成默认权重更照顾大类。微调时我会先统计标注框的宽高分布如果小目标占比高就在损失权重上提高框回归项并调高小尺度特征层的贡献。很多人微调后模型“看起来收敛了”但实际部署对小目标漏检严重问题往往就出在没按目标尺度去调损失配比。帧率预算也要提前算假设一路 1080p25目标是在 200ms 内完成从取帧到出告警那么模型推理占多少、解码占多少、规则判断占多少要一笔笔列。以我的经验YOLOv8s 在 3060 上用 TensorRT FP16 推理 640 输入大约 5~8ms解码占 5ms 左右单路余量很足但到了多路并发显存和硬件解码通道会先到瓶颈这部分放到第 5 章展开。3. 视频流接入与实时推理RTSP 拉流、解码到推理的完整管线3.1 用 OpenCV 拉 RTSP 并不是无脑 start()缓冲、超时和帧率控制安防摄像头最常见的输出协议就是 RTSP。很多人写cv2.VideoCapture(rtsp_url)后直接read()结果要么延迟越来越大要么网络抖动后程序卡死。原因在于 OpenCV 默认的缓冲行为会把来不及处理的帧堆积在内存里看起来延迟只有几百毫秒实际已经堆了几十帧。我的拉流模板长这样import cv2 import time import threading from collections import deque class RTSPCapture: def __init__(self, url, queue_size32, timeout5): self.url url self.cap None self.running False self.frame_queue deque(maxlenqueue_size) self.timeout timeout self.last_frame_time 0 def connect(self): # 强制走 TCP 传输UDP 在弱网下花屏断流更常见 os_env OPENCV_FFMPEG_CAPTURE_OPTIONS self.cap cv2.VideoCapture(self.url, cv2.CAP_FFMPEG) self.cap.set(cv2.CAP_PROP_BUFFERSIZE, 1) self.cap.set(cv2.CAP_PROP_FPS, 25) # 检查是否成功打开失败不重试会直接抛异常 if not self.cap.isOpened(): raise RuntimeError(fcannot open rtsp: {self.url}) def read_loop(self): self.running True while self.running: ret, frame self.cap.read() if not ret: # 读流失败要做退避重连不能让线程空转 time.sleep(1) self.reconnect() continue self.last_frame_time time.time() # 队列满时丢弃最旧帧保证推理永远拿最新画面 if len(self.frame_queue) self.frame_queue.maxlen: self.frame_queue.popleft() self.frame_queue.append(frame) def reconnect(self): self.cap.release() time.sleep(1) self.connect() def get_frame(self): if len(self.frame_queue) 0: return None return self.frame_queue.pop()逻辑说明read_loop在独立线程里持续拉流主线程只从队列取最新帧。CAP_PROP_BUFFERSIZE设成 1 是让底层解码器不要囤帧deque(maxlen32)在服务端做二次限流满了丢旧帧。这么处理最大的好处是网络恢复后延迟能立刻回到正常不会出现画面永远慢半拍的情况。参数调整上timeout5代表超过 5 秒没读到新帧就进入重连对不稳定 WiFi 环境建议缩到 3 秒对有线监控可以放宽到 8 秒。另外解码器这块有个坑OpenCV 自带的 FFmpeg 软解一路 1080p 就要占掉一个 CPU 核心四路以上你还没做算法CPU 先报警了。后面第 5 章会专门说硬解这件事。3.2 把 YOLO 转成推理服务ONNX 导出与 TensorRT 加速PyTorch 模型不能直接上生产。常见做法是先导出 ONNX再用 ONNX Runtime 或 TensorRT 推理。TensorRT 是 NVIDIA 显卡上加速最明显的一条路同一个 YOLOv8s 模型PyTorch FP32 推理 640 输入可能要 20msTensorRT FP16 能压到 5ms 左右这对多路场景是质变。导出命令如下# 从 YOLOv8 导出 ONNX动态 batch 和动态输入尺寸建议都打开 yolo export modelyolov8s.pt formatonnx dynamicTrue opset16 # 用 TensorRT 的 trtexec 生成 FP16 引擎 trtexec --onnxyolov8s.onnx \ --saveEngineyolov8s.engine \ --fp16 \ --workspace4096 \ --minShapesimages:1x3x640x640 \ --optShapesimages:4x3x640x640 \ --maxShapesimages:8x3x640x640参数说明dynamicTrue让导出的 ONNX 支持多种 batch 尺寸配合trtexec的minShapes、optShapes、maxShapes指定动态 batch 范围。workspace4096是 TensorRT 构建引擎时允许使用的显存上限单位 MB不是运行时显存别把它当成唯一瓶颈。FP16 对精度影响在大多数安防场景可接受但如果检测目标很小建议保留 FP32 引擎做对照后面避坑章节会讲。导出后建议做一次输入输出对齐检查把 ONNX 的推理结果和 PyTorch 的原始结果对比IOU 低于 0.9 就要检查预处理是否一致。常见不一致在于 letterbox 的填充颜色、归一化方式、输出张量的形状解析。这一步省不得等部署后再发现是预处理不一致排查代价会高好几倍。3.3 生产者消费者模式不要在主循环里直接 infer如果写成“取一帧、推理一次、显示结果”的同步循环帧率会被最慢环节拖死。监控画面的处理应该拆成三块拉流线程只负责解码推理线程只负责跑模型业务线程只负责算规则。中间用队列解耦。import threading import queue import time import numpy as np from collections import deque class InferencePipeline: def __init__(self, engine_path, workers2): self.rtsp_captures [] self.frame_queue queue.Queue(maxsize64) self.result_queue queue.Queue(maxsize128) self.infer_lock threading.Lock() self.workers workers self.engine_endpoint self._load_engine(engine_path) def _load_engine(self, engine_path): # 实际按 TensorRT Python API 加载 engine这里保留接口 return engine_path def infer_worker(self): # 多个 worker 并发消费帧共享同一个 engine 实例 while True: camera_id, frame, timestamp self.frame_queue.get() # 推理前做 letterbox 与归一化 input_blob self._preprocess(frame) with self.infer_lock: boxes, scores, class_ids self._infer(input_blob) self.result_queue.put((camera_id, boxes, scores, class_ids, timestamp)) def _preprocess(self, frame): # 保持宽高比的 letterbox长边压到 640 h, w frame.shape[:2] scale 640 / max(h, w) new_w, new_h int(w * scale), int(h * scale) resized cv2.resize(frame, (new_w, new_h)) canvas np.full((640, 640, 3), 114, dtypenp.uint8) canvas[:new_h, :new_w] resized return canvas.transpose(2, 0, 1)[None] / 255.0逻辑说明frame_queue的 maxsize 是背压阀门拉流太快而推理跟不上时新的帧会被阻塞而不是无限堆积。result_queue独立存放带时间戳的结果业务线程可以按自己的节奏消费不会因为告警推送慢而阻塞后续帧。worker 数量一般是显卡的 1/2 或 1/4不是越多越好多了会争抢 GPU 资源反而增加抖动。这里有一个很容易踩的误区多个线程各自加载一份模型权重。显存被重复占用不说多个实例并行还会拉高显存带宽占用。正确做法是共享同一个 engine用lock或线程池串行化推理调用。如果业务场景需要兼顾多路不同分辨率也可以按分辨率拆成两个 engine但不要每一路都单独 load 一次。4. 把检测结果变成有效告警置信度阈值、区域规则与推送4.1 后处理参数conf、iou、类别白名单的实用调整方法模型输出一堆框直接拿来用一定会误报。YOLO 后处理有两个参数要盯置信度阈值conf和 NMS 的 IoU 阈值iou。conf 决定一个框“算不算数”iou 决定两个重叠框是合并还是保留。安防场景里conf 的合理区间比很多人以为的要高。def filter_detections(boxes, scores, class_ids, conf_thresh0.45, iou_thresh0.45): boxes: [N, 4]scores: [N]class_ids: [N] 返回过滤后的检测结果并只保留白名单类别 allowed_classes {0: person, 2: car, 7: truck, 14: bird} valid_indices [] for i in range(len(scores)): if scores[i] conf_thresh: continue if class_ids[i] not in allowed_classes: continue valid_indices.append(i) filtered_boxes boxes[valid_indices].copy() filtered_scores scores[valid_indices].copy() filtered_cls [class_ids[i] for i in valid_indices] # NMS 用 OpenCV 的 DNN 模块或者自定义实现 keep cv2.dnn.NMSBoxes( filtered_boxes.tolist(), filtered_scores.tolist(), conf_thresh, iou_thresh ) return filtered_boxes, filtered_scores, keep逻辑说明类别白名单是安防后处理里最有效的一刀。COCO 80 类里真正对安防有意义的不到 10 类如果不过滤模型会把“猫”“狗”“鸟”全当成需要告警的目标。COCO80 的类别索引在coco.names文件里按序号排列比如第 1 行是 person第 3 行是 car不同 YOLO 版本读取索引的起点可能不同导出后务必打印一行确认。conf 和 iou 的调参方法白天光线好conf 可以放到 0.5夜间监控噪点多conf 降到 0.35 才能保证不漏人但误报会上升。iou 一般固定 0.45不建议低于 0.3否则同一目标被拆成多个框跨线判定会被重复触发。调参一定要在真实监控画面上跑回放没有比真实数据更靠谱的测试集。4.2 越界、入侵、聚集用 ROI 多边形算的三种规则检测框只是“有什么”安防还要回答“在哪”。“在哪”靠 ROI 区域判定。比如周界告警只关心围栏外侧范围仓库入侵只关心入口内侧。ROI 用多边形描述规则用点在多边形内算法判断。def point_in_polygon(point, polygon): 射线法判断点是否在多边形内 polygon: [[x1,y1],[x2,y2],...] 顶点按顺时针或逆时针排列 x, y point inside False n len(polygon) j n - 1 for i in range(n): xi, yi polygon[i] xj, yj polygon[j] if ((yi y) ! (yj y)) and (x (xj - xi) * (y - yi) / (yj - yi) xi): inside not inside j i return inside def alarm_filter_regions(camera_id, boxes, scores, class_ids, roi_config): 对检测框的底边中心点做区域判定 人和车落点不同爬过墙的人和墙外走动的人要分开处理 for box, score, cls in zip(boxes, scores, class_ids): x1, y1, x2, y2 [int(v) for v in box[:4]] # 用框的底边中点代表“人站在哪里” point ((x1 x2) // 2, y2) for rule_name, rule_data in roi_config[rules].items(): if point_in_polygon(point, rule_data[polygon]): if rule_data.get(trigger_classes, []).__contains__(cls): # 连续 N 帧判定后触发不能单帧就报 push_alarm(camera_id, rule_name, (x1, y1, x2, y2), score)逻辑说明底边中点代表目标与地面的接触点比框中心点更稳。一个人在围栏外探头框中心可能还在围栏外但底边已经越过线用底边中点能更早触发越界。这里的“连续 N 帧判定”要在业务层维护一个状态机目标第一次进入区域只是“可疑”连续 3~5 帧都满足才算告警能过滤掉很多闪断和误检。ROI 的配置我通常单独存 JSON用鼠标在监控截图里点选多边形的顶点保存后由程序热加载。规则修改不要碰代码否则每改一次规则就要重新发版这是安防项目里最拖节奏的事。4.3 告警输出快照落盘、Webhook 推送与告警风暴抑制检测到目标只是第一步真正让客户觉得“这套系统有用”的是告警能触达值班员。常见做法告警时把当前帧截图、把触发前后 5 秒的视频片段存盘同时通过 Webhook 或 MQTT 推送到值班平台。import json import requests from datetime import datetime def push_alarm(camera_id, rule_name, box, score): # 快照带检测框便于值班员人眼确认 snapshot_path save_snapshot(camera_id, box) alarm_msg { camera_id: camera_id, rule_name: rule_name, box: [int(v) for v in box], score: round(float(score), 3), snapshot: snapshot_path, timestamp: datetime.now().isoformat() } # 推送到钉钉/企业微信/自建平台的 webhook try: resp requests.post( http://your-alarm-platform:8080/api/alarm, jsonalarm_msg, timeout3 ) if resp.status_code ! 200: log_alarm_failure(alarm_msg) except requests.exceptions.Timeout: # 平台挂了不能影响主流程落日志后重试 retry_queue.append(alarm_msg)逻辑说明snapshot_path要按“日期/相机/规则”分目录存否则一个月后回看告警记录时文件找起来非常痛苦。Webhook 推送要设置超时安防平台偶发故障很正常不能让请求失败反过来拖垮推理线程。重试要有退避策略连续失败达到 10 次就停止重试只保留日志避免死循环挤爆队列。告警风暴抑制是这个环节的隐性需求同一个目标在相邻两帧都被检测到就会产生两条告警。我在业务侧维护一个按相机分组的“最近告警时间窗口”同相机同规则 30 秒内只推送一次如果目标是持续静止的人改成每 2 分钟推一次维持活动状态而不是反复推送。这个 30 秒窗口的数值需要在项目初期就写进规则文件否则正式上线当天就会被值班电话打爆。5. 避坑与排查跑通这套方案后必遇的 5 个翻车点5.1 开发机跑得好好的换到工控机上全乱套现象模型在开发机上用 PyTorch 推理一切正常部署到工控机后检测结果明显变差甚至出现大量漏检还有的表现为推理耗时忽高忽低一帧 5ms下一帧 50ms。原因工控机没有独立显卡或者显存不够TensorRT FP16 引擎在部分 GPU 上对某些算子的精度处理不一致导致输出分布漂移。更隐蔽的原因是 CUDA、cuDNN、TensorRT 版本和开发机不一致旧版 CUDA 调用新版算子时行为不确定。很多人只做了一次“能跑”就交付没有做精度对照。解决部署环境必须固定版本组合用nvidia-smi、nvcc --version、trtexec --version三连查。上线前跑精度对照同一个测试视频分别用 PyTorch FP32、ONNX FP32、TensorRT FP16 推理统计每帧检测框的 IoU平均 IoU 低于 0.85 就放弃 FP16 或换驱动版本。千万别把 FP16 当成默认必须开的选项精度吃紧时 FP32 的延迟多一倍但结果可靠得多。5.2 四路 1080p 一接上CPU 先被解码占满现象单路跑得很流畅接入四路 1080p 后 CPU 占用直接拉满推理帧率掉到个位数GPU 利用率反而很低。原因OpenCV 默认的 FFmpeg 软解对每一路视频流都要分配至少一个 CPU 核心四路 1080p H.264 的解码开销已经把 CPU 榨干留给推理的算力自然不够。这是安防项目最容易忽略的解码瓶颈很多人第一反应是“显卡不够”实际换一张更好的显卡也救不了 CPU 解码。解决先看 CPU 占用是否被ffmpeg或opencv_videoio进程吃掉。如果是优先换支持硬解码的方案NVIDIA 平台用 DeepStream或者让 OpenCV 走 NVDEC 硬解没有硬解能力的平台把视频流改成子码流或者把 H.264 换成 H.265 并在解码前降分辨率。我一般在接入超过两路时就直接切到 DeepStream它的解码复用和显存管理比纯 Python 方案稳得多。5.3 白天不漏人一到晚上就漏检现象白天检测正常晚上同一位置同一目标检测不到或者把树影、车灯误报成人。原因夜间图像信噪比低YOLO 模型在训练时没见过足够多的夜间样本。凡是训练集以白天监控截图为主夜晚自然翻车。另一个原因是摄像头夜间自动切换到红外模式画面变成灰度而模型输入归一化时是按彩色三通道处理的灰度图的分布直接把有效特征稀释了。解决收集夜间监控片段按时间段和光线条件划分训练集。最有效的做法是同一个相机位置分别在白天、傍晚、夜晚各截取 1000 帧标注后混合训练如果采集成本太高先用图像增强脚本把白天样本做亮度扰动、加噪、灰度化但这只是缓解真实夜间样本必须要有。推断时可以按时间段切换到夜间专用权重靠一个模型打全天是偷懒的做法。5.4 RTSP 拉流半小时后卡死程序完全无响应现象系统刚启动一切正常运行一段时间后某一路画面停止更新CPU 占用下降但线程没有退出也没有报错。原因RTSP 连接被摄像头主动断开或者网络中间设备空闲超时OpenCV 的read()在连接断开后不会立刻返回False而是阻塞在底层的 socket 读取上导致拉流线程挂死。如果你的拉流代码没有设置 socket 超时和心跳检测就会无限期卡住。解决在拉流线程里维护一个“读帧间隔”监控超过 timeout 秒没读到帧就主动 release 并重建连接绝对不能依赖cap.read()的返回值因为它遇到某些错误会一直阻塞。还要定期发送 RTSP keepalive 请求我用FFMPEG的-stimeout参数或者在底层 socket 设置SO_RCVTIMEO两种都是有效路径。每路拉流独立一个线程任一路重连失败只影响自己不能拖垮整个服务。5.5 告警推送太勤值班员直接把通知关掉现象系统推了 200 条告警其中 180 条是“人进入区域”但画面里只是路过、修路、取快递值班员看多了以后对告警彻底免疫真出事了反而没人处理。原因规则太粗糙把所有“人出现”都当成“报警”没人做告警分级也没做目标行为关联。摄像头的安装位置决定了误报率俯视机位的人脸检测效果好水平机位的树影晃动却会被框成人形。解决做两级过滤——第一级用 YOLO 检测结果第二级必须有业务规则。比如“人进入区域”这条规则要加停留时长、运动轨迹、时段三个条件只有目标在区域内停留超过 5 秒、轨迹长度明显偏离正常路径、且在设定时段内才触发。再按风险分三级黄色告警只记录不推送橙色推给微信红色打电话。这套规则最初我是在纸上画的但跑了一个月才体会到把阈值从“能检出”调到“值得打扰人”是安防系统从 demo 到能用的关键一步。6. 进阶多路共享推理与回放验证的两个习惯6.1 多路并发不再“一路一个模型”而是批处理共享引擎当你从 4 路扩到 16 路时如果每路各自维护一个推理实例显存和 GPU 利用率都会很难看。常见做法是把多路画面凑成一个 batch 送进同一个 TensorRT 引擎推理。T4 上用 TensorRT FP16 跑 YOLOv8s 640 输入单帧耗时大约 3~5ms但把 8 路待处理帧合成一个 batch 后整体耗时可能只有 15ms等于一路模型跑了 8 路活。核心是动态 batch拉流线程各自取帧推理线程按“凑满 4 帧或等待 5ms”的规则批量提交。 batch 越大延迟越高16 路并不能无脑成一个 batch通常 4~8 路一组比较稳定。多路共用引擎后显存占用从“每路一份”变成“一个 batch 里最大份”这是质变。6.2 验证不看 mAP看回放视频的误报率和漏报率模型训练完很多人只盯着验证集 mAP上线才发现“指标挺高实际没法用”。原因是验证集和真实监控画面存在分布差异特别是摄像头安装高度、角度、光线条件完全不同。我会把真实监控录像切成 3 个时段的回放视频用系统跑一遍统计人工标注的“真事件”到底检出多少、误报多少。比较反直觉的结论是误报率比漏报率更影响客户评价。一个漏报可能是偶发但每分钟响一次的误报会让整个系统被关掉。我会把“特定区域一天最多误报 5 次”作为硬指标去压规则参数而不是追求最高的框准确率。这套方案走到这里已经从“能跑”到了“能信”。我最初做第一个项目时也迷信模型越新越好、参数越大越强结果被夜间漏检和告警疲劳连续打脸后来收敛成“先定边界、再选模型、用回放验证”这套习惯项目上线率明显提高。每一个坑都是拿真实画面换来的参数、阈值、规则这些你可以照抄唯一抄不了的是你们现场摄像头的视角所以务必把回放验证环节留给上线前的自己。希望帮到你。本文还有配套的精品资源点击获取
