基于YOLO的打架斗殴实时检测系统设计与实践

1. 项目定位与整体设计思路

1.1 打架斗殴检测到底解决什么问题

安防监控领域有个很现实的痛点：摄像头越来越多，值班人员却不可能每一路都盯得住。传统的纯静态画面轮巡方式，往往等事件结束了才被人发现，事后溯源可以，现场干预完全来不及。打架斗殴检测系统的核心价值，就是把"事后调录像"变成"事中实时告警"——画面里一旦出现推搡、扭打、击打等异常行为，系统立刻在界面上弹出告警并保存证据片段，让安保人员有机会在事态升级前介入。

这套系统背后的技术栈并不神秘，本质上是目标检测加上行为判定两部分。目标检测负责找出画面里的人并锁定位置，行为判定则负责分析人与人之间的交互是否符合打架特征。用YOLOv5/v8/v10来做检测，是因为这套框架在工业场景里足够成熟，训练成本可控，且推理速度能扛住实时视频流。我最早用YOLOv5搭建了一个可以跑的Demo，后来逐步迁移到v8、v10，发现不同版本的特性差异正好对应了不同的部署需求，这个后面详聊。

1.2 为什么选YOLO系列而不是其他方案

其实打架斗殴检测还有别的技术路线，比如基于姿态估计的方案：先用关键点检测模型（像OpenPose、HRNet）提取人体骨架，再把关键点序列输入时序模型判断动作类别。这条路精度上限很高，但工程落地比较痛苦——姿态估计模型本身计算量大，多人的关键点匹配很容易乱，而且在小目标、遮挡严重的场景下，关键点检测的质量会断崖式下降。

相比之下，YOLO系列直接输出目标的边界框和类别，一阶段推理，效率和稳定性都非常适合监控场景。打架斗殴本质上可以建模成"两个人靠得很近 + 持续剧烈的身体接触 + 框内运动程度激烈"这几个可观测特征，单帧的目标检测框加上帧间位置变化，已经足够支撑一套有效的行为判定逻辑。不需要特别精细的姿态信息，反而更适合在低算力设备上跑。

另外，YOLO系列的生态优势非常明显：预训练权重好找、标注格式通用、部署工具链成熟（从PyTorch到ONNX、TensorRT都有现成路径）。对于要快速出成果或者做产品原型的团队来说，这几乎是性价比最高的起点。

1.3 系统整体架构与模块划分

整个系统我拆成了四条链路：数据链路、训练链路、推理链路、展示链路。

数据链路负责从采集到标注再到增强，最终产出合格的训练集；训练链路负责YOLO模型的迭代训练和评估；推理链路负责加载训练好的模型，对视频帧做目标检测，并执行打架判定算法；展示链路则是UI界面，负责实时画面渲染、告警弹窗、日志记录和参数调整。四条链路解耦之后，每一块都能独立替换和升级。比如，我不满意检测效果，只需要重新训练模型，推理链路不用动；想把桌面UI换成Web端，展示链路单独改造即可。

用一个比较通俗的比喻：数据链路是准备食材，训练链路是把菜做好，推理链路是上菜前的质检和摆盘，展示链路就是顾客面前的餐桌。绝大多数落地项目卡在数据和训练端，推理和展示反而是最不费劲的部分——但多数初学者恰恰把时间都花在了界面上，这个次序问题值得提醒。

2. 数据集构建与预处理全流程

2.1 数据从哪里来：公开数据集与自采数据的取舍

构建打架斗殴数据集，第一步就是确定数据来源。公开的打架行为数据集其实存在，但普遍规模偏小、场景单一，大多来自固定机位的监控录像或者YouTube上的街头斗殴视频。用公开数据集起步做验证是没问题的，但真正部署到客户现场时，画质、视角、环境光线和公开数据差异巨大，模型往往会出现明显的场景漂移。所以我的建议是：公开数据做预训练基础，现场数据做微调主力。

如果需要自行采集数据，优先模拟真实监控视角。正常情况下，打架事件在监控画面里大多是中远距离、俯视或平视角度，人员目标相对较小。采集时尽量贴近这些特征，避免近距离、大面积怼脸拍，否则模型学到的特征分布会偏离使用场景。我有一个经验：把摄像头架在2.5到3米高度、倾斜30到45度角，模拟走廊或广场监控，采集效果最接近真实场景。

另外，纯"打架"样本是远远不够的。模型需要大量负样本——拥抱、搀扶、握手、打闹嬉戏、排队推挤等近距离但没有敌意的交互。这些负样本如果缺失，检测出的"打架"框会满天飞，系统完全没法用。负样本和正样本的比例，我建议至少做到1:1，实际部署时甚至可以做到2:1。

2.2 标注规范：框什么、怎么分类、标签如何设计

标注是数据集构建中最耗时也最关键的一步。打架斗殴检测的标注策略和常规目标检测不太一样，落点不在于标注"哪个人在打架"，而是标注"哪里正在发生打架行为"。我实践的方案是：只有画面中存在实际推搡、击打或纠缠行为时，才对交互区域标注一个"fight"类别的目标框；普通行人一律不标，或者在另一个类别里作为负样本存在。

实际标注中有几个关键原则：

• 交互目标框要同时覆盖参与交互的两个或多人，比单人的人的检测框大一圈。
• 若画面中有多人，但只有其中两人在打架，目标框只框住那两人，而不是框住整个群体。
• 目标框在交互过程中要相对稳定，不要因为手部挥动大幅抖动。一帧只标一次，交给模型去学习边界。
• 多人的情况下，只要有一个发生打架的交互对，就标注一个fight框，允许画面中同时出现多个fight框。

标注工具我用的是LabelImg，开源、轻量、支持YOLO格式导出。如果数据量大，也可以考虑X-AnyLabeling这类带辅助标注的工具，在检测框基础上做插值可以省不少时间。标注产出的是txt文件，每行格式：类别ID（0代表fight）、归一化中心点x、归一化中心点y、归一化宽度w、归一化高度h。

需要注意的是，YOLO格式的归一化是基于整个图片尺寸的百分比，标注完要抽查一遍汇总文件，常见的问题是类别ID写错、坐标范围超出0到1、宽高为0。一个最简单的校验脚本，解析所有txt再转成可视化方框，输出在图片上人工扫一遍，比盯数据表格高效得多。

2.3 数据增强与样本均衡策略

监控场景下的打架样本天然稀有，正样本数量通常就几百到一两千张。这个量级远不够让YOLO这类深度模型收敛出稳定的行为语义，所以数据增强是必不可少的一环。YOLO训练代码内置的Mosaic增强非常有效——它把四张图拼成一张，极大地丰富了小目标的上下文信息，同时对"目标出现在画面边缘"这类监控常见情况有明显增益。

除了内置增强，我建议额外做两类边界增强：尺度变换和HSV扰动。尺度变换模拟不同监控距离下的目标大小变化；HSV扰动模拟不同时段光线变化。夜间监控红外模式下的灰度偏转、逆光环境下的强曝光，这些都可以用HSV参数模拟出来。注意增强的幅度不能过大，比如饱和度不要调的太过分，否则模型会把颜色当成关键判别特征——室内暖光灯下的打架和户外阴天下的打架不应该在颜色层面产生巨大差异。

样本均衡方面，除了前述的正负样本比例，还要关注不同动作姿态的覆盖。推搡、挥拳、抱摔、锁喉、倒地扭打都要有足够样本。我做过一次统计，早期训练集大量是推搡和挥拳的视频帧，结果模型对倒地扭打的召回率很低——没有见过自然学不会。

提示：保证数据集多样性，从动作姿态、距离尺度、光线条件、遮挡程度四个维度去审视样本构成，比盲目堆总量更有价值。

3. 模型训练与YOLOv5/v8/v10选型对比

3.1 三个版本到底有什么差别，应该选哪个

先说结论：同一个数据集，三个版本训练出的模型做打架检测，精度差异远没有框架差异带来的工程适配区别大。对新手，YOLOv5是最稳的入口；对需要更高精度或更好泛化的场景，YOLOv8是目前综合性价比最好的选择；YOLOv10则适合对推理延迟有极致要求的实时多路场景。

从模型结构上看：

YOLOv5依旧是Anchor-based思路，C3模块结构简单稳定，训练技巧的社区积累极其丰富。遇到问题随便一搜就是答案，这个生态优势在工程落地时非常值钱。我第一版系统就是基于YOLOv5s训练的，3060显卡上跑到60到80FPS毫无压力。

YOLOv8换成了Anchor-free的检测头和C2f模块，同时默认集成了一系列训练上的优化，比如Decoupled Head、TaskAlignedAssigner。这些改动带来的实际体验是：精度比v5高一截，尤其是中小目标上更明显，同时训练过程更省心，不用反复调整Anchor超参数。v8的另一个优势是超参数的默认值更加合理，随便跑都不会太差。

YOLOv10最大卖点是去掉了NMS后处理，用一对一的标签分配策略直接从网络输出端产生无冗余的检测结果。这使推理流程更干净，延迟更稳定。但在我的测试里，v10的精度和v8相比没有显著优势，而且训练配置和部署工具链相对新，部分设备上的兼容性还在完善。监控项目里如果每路视频都要接多个摄像头后处理，v10省掉的NMS时间会积少成多。

3.2 训练参数配置与经验值参考

我用YOLOv8做一次完整训练的参考配置如下。选v8讲是因为它在三个版本中参数最直观，训练指标也最具代表性；换成v5或v10，只需微调配置文件结构。

bash复制# 训练命令示例
yolo train data=fight_dataset.yaml model=yolov8s.pt epochs=200 imgsz=640 batch=16 device=0 optimizer=AdamW lr0=0.001

参数方面，重点讲几个实际影响大的：

• imgsz=640是标准尺寸。监控画面通常较大，如果原图是1920x1080，640输入意味着检测框对大图做了降采样，小目标信息有所损失。我测试过865和1280输入尺寸，mAP确实提升3到5个点，但推理耗时几乎翻倍。实际部署要看算力卡在哪。
• batch优先由显存决定。16G显存跑yolov8s、640输入、batch=16是安全的；没这个条件，batch=8配合梯度累积也能训练，只是收敛慢一点。如果batch设得太小且学习率按默认0.01，很容易出现loss震荡。
• epochs起步设150。数据量少、场景单一，500轮之后基本就是过拟合；如果数据量充足且做了预训练，200到300轮能榨出更多性能。关键是盯着val/box_loss，拐点出现后继续训练超过50轮基本没收益。
• optimizer我推荐AdamW。SGD收敛更钝但在测试集上可能更好一点，AdamW在正负样本比例不太均衡的打架数据集上收敛更快。

3.3 训练结果评估与阈值选择

训练结束后，最重要的评估指标不是总体的mAP，而是打架类别的PR曲线和召回率。因为打架检测本质上是罕见事件检测——漏报一次可能就有安全责任，宁可误报也好过不报。

我训练完成后的指标大致如下，供参考：

• 类别为fight的mAP@0.5约在0.86到0.92之间，具体取决于数据集质量和难度。
• Precision约0.9以上时，Recall大概在0.8左右浮动。
• 如果您发现Precision高但Recall低，说明模型把大量打架行为识别成了普通场景——需要通过扩充正样本或降低置信度阈值来平衡。

推理时的置信度阈值很关键。默认0.25在通用检测上表现不错，但对打架场景，推荐把置信度降到0.2，同时把NMS的IoU阈值略调到0.45，减少漏检。这带来的代价是误检增多，但误检可以在后端的判定逻辑里继续过滤，两段式把关比单靠模型更稳。

4. 打架行为判定逻辑与后处理优化

4.1 从单帧检测框到连续行为判定

模型输出的是每帧画面里的fight框，但单帧的"疑似打架"不足以支撑告警。监控视频是连续帧序列，打架是个持续过程。如果画面里两个人只是擦肩而过，可能连续好几帧都有重叠框——它们并不是真正的打架事件。我的方案是用一个多帧滑动窗口来平滑单帧的检测结果。

具体来说，维护一个长度为N帧的时间窗口，窗口内只要有M帧检测到fight框，就触发一次"打架事件"判定。N取15到30，M取N的60%到70%，这是基于25帧每秒实时流推算的：也就是0.6到1.2秒的持续性观察窗口，跳变噪声能被平滑掉，短促的错检不会积累成事件。阈值参数必须在界面里做成可调的，不同场景的容忍度不同。

还有一种更细化的做法是加入"热区"机制：记录每个fight框中心点在连续帧中的位移。如果中心点长时间不动，但框大小剧烈变化，通常意味着两个人在原地扭打；如果框快速滑动，可能是追逐或拖拽。这两种模式都能被简单的位置和尺度变化特征区分开，但不太适合一开始就做得过于复杂，先把主体逻辑跑通再迭代。

4.2 距离判定与重叠度计算

除了依赖模型输出的fight框，我额外加了一道兜底的检测逻辑：对人进行普通检测，判断任意两个人之间的距离。这道兜底存在的意义是，模型在某个特殊角度下漏检了fight类别，但只要两个人的位置关系足够接近且维持足够久，同样可以触发告警。

具体计算方式是对两个person目标的边界框计算交并比和中心距离。中心距离的阈值不固定，而是跟随目标框自身尺寸缩放。比如两个人的边界框平均宽度为w，那么中心距离小于0.5倍w就视为"接触"。这个相对阈值的自适应能力很强，近景人物和远景人物的距离度量标准可以自然拉开。

两套逻辑的融合策略是：fight框检测结果优先，一旦存在fight框并持续帧数达标，就直接告警；persons距离接触持续帧数达标时，作为第二级告警条件。这样可以同时兼顾模型直接识别和几何推断的互补性。

4.3 误报抑制与告警去重

误报抑制是这套系统能够在生产环境活下去的关键。我踩过的典型误报有这么几类：视线遮挡造成的框抖动、拥抱和搀扶场景、密集人群中的随机接触、以及隔着桌椅的争吵。前两类靠增大连续帧阈值能滤除一部分，后两类需要额外的逻辑来压制。

我加入了一个简单的运动幅度评估：计算fight框内部图像的帧间差分像素占比，如果差分占比低于某个阈值，说明画面里根本没有剧烈动作，只是两个框长期重叠而已，可以忽略。打架事件通常伴随高频肢体运动，静止接触的帧间差分值很低——用这个特征可以滤除拥抱、搀扶、窃窃私语等场景。

告警去重采用事件锁机制。触发告警后，同一跟踪ID组合的视频源进入锁定状态，在设定的冷却时间（比如10秒）内不再重复弹窗，但后台可以继续记录。这个机制避免了一次打架导致几十个告警刷屏、值班人员直接麻木的问题。锁定解除后，如果事态还在继续，则再次触发告警。

5. UI界面设计与完整系统集成

5.1 界面技术选型：为什么用PyQt5而不是Web

展示链路我最终选了PyQt5，而不是Web前端，核心出发点在于需要同时满足实时性、低延迟和本地化部署。PyQt5配合OpenCV的QImage转换，可以直接在界面上显示视频帧，延迟可以控制在几十毫秒量级，不经过浏览器渲染的中间环节，对实时监控场景非常友好。打包成Windows桌面应用也方便，不需要搭服务器配前后端环境。

如果未来要做多客户端远程查看，Web方案有天然优势。我目前的建议是：单机部署现场大屏展示用PyQt5起步，后续要扩展成网页端时，只需把推理端做成一个HTTP服务，前端换成Vue加WebSocket就成，后端逻辑不用重写。

5.2 界面模块拆解与线程模型

一个实用的打架检测界面至少应该包含：实时画面显示区、检测框绘制层、告警状态区、事件日志列表、参数调节面板、录像回放入口。这些模块里最容易翻车的是线程模型。整个推理过程涉及视频帧采集、模型推理、行为判定、UI刷新四个环节，如果全部挤在主线程，界面无限卡顿。

我的实践是三个线程各司其职：

• 采集线程：负责OpenCV读取视频流（本地文件或RTSP地址），对读取到的帧做必要的缩放和格式转换，放进线程安全的队列。
• 推理线程：从队列里取帧，执行YOLO推理、行为判定逻辑，把结果（检测框、告警标记、帧数据）放进另一个队列。
• UI线程：主线程定时器取推理结果，刷新画面和告警状态，响应按钮事件和参数调节。

线程间用queue.Queue传递，注意推理线程处理完的一帧必须及时清理，否则队列堆积会导致画面延迟越来越严重。我在队列上设了最大长度，满了就丢最旧的帧，这样在高帧率场景下，界面始终显示的是最新状态而不是积压的历史帧。

5.3 界面核心实现要素与告警机制

画面显示部分用QLabel容纳QImage，每帧从推理结果里拿到检出框的数据，在图像上画出矩形框和类别标签。颜色约定是打架框红色加粗、普通行人框绿色，视觉上一眼能区分。如果告警触发，帧图像外圈套红并在状态栏闪烁文字。

告警机制至少需要三类输出：屏幕弹窗提示、声音提醒、日志存储。声音可以用PlaySound播放一个短促的beep文件，也可以播放一段预录的语音提示"第3号点位检测到打架行为"。日志要记录告警时间、摄像头编号、置信度、事件持续时长，并保存告警前后的视频片段，这个用OpenCV的VideoWriter可以轻松实现，关键是写清楚时间戳。

参数面板提供给用户调节的是"工程参数"，不是训练参数。包括：检测置信度阈值、打架判定连续帧数、距离接触阈值、告警冷却时间。这些参数全部做成SpinBox控件并实时作用于推理逻辑，方便现场调试。

5.4 性能优化：让系统跑得更稳更快

推理性能优化从三个层面入手。

• 第一个层面是模型轻量化。训练时从yolov8s甚至yolov8n级别切入，实测yolov8n在打架检测上精度损失约3个百分点，但推理速度比s级快一倍。如果现场算力紧张，这是最有效的优化。
• 第二个层面是推理框架。训练完的PyTorch模型转成ONNX，再用ONNX Runtime推理，比原生PyTorch的推理速度快30%左右；更进一步用TensorRT做FP16量化，在N卡上的速度优势非常明显。
• 第三个层面是业务逻辑优化。比如检测区域可以屏蔽无用区域，通过界面画出ROI区域，模型只对ROI内的区域执行推理，减少无效计算。这个功能我强烈建议做，监控画面的很多区域（天花板、墙、空地）根本不需要检测，省下来的算力非常可观。

注意：转ONNX或TensorRT时，输入输出节点名称、动态维度设置是踩坑高发区。务必先用单张图片验证转换后的推理结果与PyTorch原模型一致，再做整体替换。

6. 常见问题与排查技巧实录

6.1 训练阶段的高频问题

模型不收敛或loss曲线诡异。 先检查数据集。最常见的情况是标注文件里混入了没有对应图像的txt，或者图像和标注文件不对齐。用一个脚本遍历全部图像文件，逐一校验对应的txt是否存在、坐标是否在有效范围，十分钟能排查完。

训练过程中mAP很低但训练集loss很低。 典型过拟合。数据集太小、增强不足、训练轮数太多是三大主因。打架行为本身类别内部差异巨大，跌倒、扭打、挥拳都算一类，如果样本总量只有几百张，模型只能死记硬背。增加样本量或多样性是唯一的根治路径。

不同摄像头画质差异导致的性能暴跌。 这是典型的域偏移。解决办法是把不同画质、不同色域的数据混合训练，甚至用图像增强模拟到训练集中。实测在训练集里混入红外黑白监控片段，日间模型在夜间场景下的表现改善非常明显。

6.2 推理阶段的问题

检测框抖动严重。 单帧检测的结果天然有抖动，尤其是小目标。最简单的缓解手段是跟踪——用ByteTrack或DeepSORT把同一个人的框关联起来，对历史帧的框坐标取平滑值。打架场景的交互动态变化很快，我建议平滑窗口不宜过大，5帧左右的EMA指数移动平均比较合适，既平滑了抖动又不至于滞后太多。

误报反复出现同一个场景。 高发区域往往有特定的视觉特征，比如通道口的门框、摆放固定的盆栽，模型偶尔会把它们当成人的一部分框出接触区域。处理方案：一是把这些区域划入ROI屏蔽区；二是针对该场景收集负样本并单独做一次finetune。第一个方案见效最快。

打架检测框和行人检测框的概念混淆。 很多初学者自定义了"打架"数据，却把所有普通行人全标注为打架。模型根本学不会打架语义。请务必保持负样本的充足和正确标注——姿态异常、距离靠近并不等于打架。

6.3 系统集成与UI运行的问题

UI界面卡死或崩溃。 绝大多数是线程问题。OpenCV的VideoCapture反复重启导致的崩溃、跨线程访问Qt控件抛出的异常，是最常见的情形。我的做法是：视频采集重连逻辑放到独立子线程，跨线程更新UI统一通过信号槽机制而不是直接修改控件属性。给QThread加terminate是在自找麻烦，正常退出配合wait()是正路。

运行一段时间延迟越来越大。 队列堆积和显存泄漏是两大元凶。检查内存占用曲线，如果持续上涨，优先查是否每帧都创建了新的QImage而没有释放。摄像头长时间运行后RTSP连接断流的问题也很常见，重连逻辑里必须设置超时，否则卡在connect()不回。

多路视频扩展。 推流一路能跑，推到四路就丢帧。重点看推理线程是否够用。多路场景的合理方案是每个摄像头一个采集线程和一个推理线程，或者把所有摄像头都交给一个异步IO循环读取，再在推理线程里做批处理。批处理的吞吐量远大于逐个处理，但需要留意batch维度每帧必须对齐。

写到最后的几句实在话

回看这个项目，从零到一落地一套可用的打架检测系统，最大的心得不再是模型精度怎么调到最高，而是系统性思维：数据集决定了上限，模型结构决定了效率，判定逻辑决定了可用性，UI决定了产品能不能被业务方接受。每一步都走扎实，系统整体才立得住。

我在实际迭代过程中体会最深的一点是：最早跑通Demo只是万里长征第一步，真正让这套系统活在监控中心里的，是持续收集新场景数据、不断微调和阈值迭代。 没有任何一个模型可以一劳永逸地适应所有环境，保持反馈闭环，系统能力才会越用越强。如果你正在做类似的安防行为检测项目，希望这篇记录能帮你少踩几个坑，也早点让系统跑在真实场景里发光发热。