简介针对打架检测任务整理的数据集引导资料包面向监控场景安防算法工程师、目标检测学习者与相关项目开发者。PDF内全面介绍了真实监控场景下的打架图片数据覆盖街道、酒吧、商店、公交车、监狱、空旷地等环境包含两人打架与多人斗殴等多种情况统一标注fight类别同时说明了使用labelimg标注并输出VOC/xml、COCO/json、YOLO/txt三种常见格式可直接用于YOLO等模型训练。正文还附赠YOLO11一键训练脚本覆盖GPU、CPU、Mac(M芯片)多平台运行方案并给出训练结果日志供参考。资源包共1个PDF文件大小5.6MB内容为数据集的基本情况说明与百度网盘获取方式解决实际下载大体积数据前的预览与决策需求。目前已有695人浏览学习适合作为打架检测项目的前期资料准备与方案参考。1. 打架检测数据集1000 张标注图能撑起一个什么样的安防项目晚上九点半的监控室保安盯着十六路画面真正出事的那一路往往是最没人在看的那一路。打架检测要解决的就是这个问题——用 YOLO11 在 GPU 服务器、机房旧 CPU 机器或者 MacBook 上把标注好的数据集训练成模型让摄像头自动发现「推搡、挥拳、倒地纠缠」这些动作在事态升级前弹出报警。这个标题的核心是一条完整的落地链路带标签的 1000 张打架场景图片VOC/COCO/YOLO 三种格式的标注外加一套能在三种硬件平台上跑起来的 YOLO11 训练脚本。1000 张图听起来不多但对于打架检测这个垂直场景它刚好卡在「能用」和「要省着用」之间。打架动作的共性是姿态突变和肢体交错背景相对固定这决定了它不是那种需要十万级数据才能收敛的任务。真正让新手翻车的往往不是数据量而是标注格式转来转去把坐标搞错、训练平台切换时环境不一致、以及 YOLO11 新增的模块在旧显卡上跑不动的兼容性坑。这篇笔记就照着这三件事把数据怎么验、三种格式怎么互转、三平台训练脚本怎么调一条一条说透。2. 打架检测数据集的内容拆解1000 张图该验什么、三种格式该信哪个2.1 拿到数据集先做的三件事看类别、看分辨率、看标注框质量无论是自己采集还是接手现成数据集第一件事不是急着训练而是把目录结构和标注文件过一遍。一个合格的打架检测数据集图片文件夹下应该躺着三类文件原始 JPG 图片、VOC 的 XML 标注、COCO 的 JSON 标注、YOLO 的 txt 标注。先用一条命令看全貌find . -type f | awk -F. {print $NF} | sort | uniq -c # 输出示例1000 jpg / 1000 xml / 1 json / 1000 txt这条命令统计每种扩展名的文件数量能从总量上判断格式是否齐全。正常情况 jpg、xml、txt 各 1000 个json 如果是 COCO 标准格式则是整个数据集打包成一个文件。数量对不上先别急着训练去翻一下 classes.txt 或 json 里的 categories 字段确认类别名是不是你期望的fight或person——有些数据集会把打架行为标注成assault训练脚本里类别名写死的话loss 直接飘成 NaN。标注框质量检查是最容易被跳过的环节。建议抽 50 张图把标注框画出来人眼过一遍重点看三类问题框是不是完全包住纠缠中的两个人打架场景里肢体交错半个人身的框特别常见是不是有大量重叠框两个人叠一起被标成两三个框训练时 NMS 会很难受标注框有没有滑出图像边界。最后这个用 Python 验一把最稳妥import os for txt in os.listdir(labels): with open(os.path.join(labels, txt)) as f: lines f.readlines() for line in lines: parts line.strip().split() # YOLO 格式归一化坐标必须满足 0 x_center 1 if not all(0 float(v) 1 for v in parts[1:]): print(f越界标注: {txt} - {line.strip()}) break这段代码检查的是 YOLO 格式 txt 里的归一化坐标有没有超出 [0,1] 区间。越界的原因通常是标注工具导出设置错误或者图片 resize 后标注没跟着缩放。遇到越界框别手动改文件找生成标注的工具链去修手动改 1000 张图的坐标能改到怀疑人生。2.2 VOC、COCO、YOLO 三种标注格式的边界差异不是简单的换壳很多初学者有个错觉觉得三种格式只是换了个文件后缀实际用转换脚本跑一遍就完事了。这是打架检测数据集落地时最大的坑。三种格式的差异在组织方式而不在文件后缀。VOC 格式是 XML 文件一张图一个 XML框坐标用xmin, ymin, xmax, ymax表示绝对值原点在左上角。COCO 格式是单 JSON 文件里面嵌套images、annotations、categories三个数组框坐标虽然是[x, y, width, height]的绝对值但还带一个area字段——打架场景里两个人纠缠时area计算稍有差错很容易被过滤掉。YOLO 格式最简单txt 文件里每行一个框class_id x_center y_center width height全部归一化到 [0,1]。三者的核心区别在于坐标系和归一化方式VOC 的绝对像素坐标转 YOLO 时要做除法# VOC (xmin, ymin, xmax, ymax) - YOLO (x_center, y_center, w, h) x_center (xmin xmax) / 2 / image_width y_center (ymin ymax) / 2 / image_height width (xmax - xmin) / image_width height (ymax - ymin) / image_height这个转换的坑点在于image_width和image_height必须以实际图片像素为准而不是数据集文档上写的某个设计分辨率。打架检测数据集的图片经常来自不同摄像头分辨率从 720p 到 4K 都有如果统一按 1920x1080 做归一化4K 图上的标注框位置会全部偏移训练出来的模型在真实场景下完全不能用。我习惯在转换脚本里用 PIL 读一遍图片真实尺寸再算虽然慢但稳from PIL import Image img Image.open(images/0001.jpg) w, h img.size # 真实宽高 # 再用 w, h 做归一化分母2.3 一个合格的标签体系应该长什么样类别 ID 的前后一致性打架检测数据集最常见的坑不是坐标而是类别 ID。VOC 里类别名是字符串fightCOCO 里categories数组给fight分配 ID 可能从 1 开始YOLO 的 txt 里存的则是纯数字。三者之间的映射关系必须人工确认一遍。训练框架内部读标签时有的按类别名匹配有的按 ID 匹配还有的按classes.txt文件里的行号顺序匹配。如果classes.txt里写了person和fight两行但 COCO 的 JSON 里fight的 ID 是 2、person的 ID 是 1那么从 COCO 转 YOLO 时 ID 会错位——模型学到的是「person 就是打架fight 就是普通人」。为了避免这种低级错误我一般会在训练前跑一段验证脚本随机挑三张图把三种格式的标注框画到图上人工对比一次import cv2 for i in range(3): img_path fimages/{i:04d}.jpg img cv2.imread(img_path) # 叠加 VOC XML 的框画绿色 # 叠加 YOLO txt 的框画红色 # 肉眼确认两套框是否重合这一步十分钟就能搞定但能省下后面调一周模型的时间。很多翻车现场不是模型结构出了问题而是标签文件在格式转换环节悄悄错了模型没法学到真正的打架特征。3. 把 1000 张打架图喂给 YOLO11数据划分与三平台训练脚本的设计思路3.1 数据集的目录结构YOLO11 训练器认的是这套组织方式YOLO11 沿用 Ultralytics 的目录约定数据集必须按 train/val 划分并提供一个 YAML 配置文件。打架检测数据集的落地第一步是把三种格式统一转成 YOLO 格式然后按下面的结构摆好fight_dataset/ ├── images/ │ ├── train/ # 800 张 │ └── val/ # 200 张 ├── labels/ │ ├── train/ # 800 个 txt │ └── val/ # 200 个 txt ├── data.yaml # 数据集配置文件 └── classes.txt # 类别列表data.yaml 的内容是 YOLO11 训练器的入口train: fight_dataset/images/train val: fight_dataset/images/val nc: 1 names: [fight]这里nc是类别数打架检测通常就 1 类如果想区分「推搡」「挥拳」「倒地」也可以扩到 3 类但 1000 张图分三类每类 300 多张训练难度会大不少。data.yaml 的路径建议用绝对路径或相对 YAML 文件所在目录的路径Ultralytics 对相对路径的解析在不同版本间有过调整写绝对路径最省心。划分数据时注意一点同一段视频抽帧出来的图片要归到同一个集合里。打架检测数据集里常见的情况是 10 段打架视频各抽 100 帧如果按图片随机划分同一段视频的帧会同时出现在 train 和 val 里模型在 val 上的表现会虚高实际部署到新场景效果大打折扣。按视频片段划分是血泪经验务必检查一下数据集的文件名前缀是不是同一段视频的编号。3.2 GPU 服务器上的 YOLO11 训练命令batch 和显存怎么权衡GPU 机器上训练 YOLO11核心参数是 batch size 和 workers。1000 张图的数据集在单卡上训练batch 设 16 或 32 都行但要看显存够不够。YOLO11 有 s、m、l、x 四个尺寸打架检测这种单类别任务用 s 就足够了m 以上在 1000 张图上很容易过拟合。yolo detect train \ modelyolo11s.pt \ datafight_dataset/data.yaml \ epochs100 \ batch16 \ imgsz640 \ device0 \ workers8 \ projectfight_output \ nameexp_gpu这段命令在 GPU 服务器上跑device0指定第一张显卡workers8是数据加载线程数。数据增强方面 YOLO11 默认开 mosaic1000 张图做 mosaic 增强后等效训练样本量能扩大好几倍但训练后期建议关掉 mosaic让模型在接近真实的分布上收敛。纯新手最容易犯的错是把epochs设太大。1000 张图按默认的 300 epoch 训练前 50 轮就过拟合了后面 250 轮全是浪费时间。设 100 epoch 配早停就够了Ultralytics 默认有 patience 机制val loss 连续 50 轮不降自动停。3.3 Mac 与纯 CPU 平台的一键训练yolo11s 是唯一理智的选择Mac 和 CPU 机器上训练 YOLO11型号选择上只有一个答案yolo11s.pt。YOLO11n 理论上更快但精度在打架场景这种小目标较多的任务上不太够用——注意打架检测的「目标」是两个人纠缠成的不规则形状不是常规的独立人框。Mac 上如果芯片是 M1 及以上PyTorch 会优先走 MPS 后端Ultralytics 在较新版本里对 MPS 支持得不错。但 MPS 在跑 YOLO11 的某些卷积算子时可能报 not implemented这时候有两个选择降级到 CPU 跑或者用PYTORCH_ENABLE_MPS_FALLBACK1环境变量强制走 CPU 回退。# Mac (Apple Silicon) 上用 MPS 加速训练 PYTORCH_ENABLE_MPS_FALLBACK1 yolo detect train \ modelyolo11s.pt \ datafight_dataset/data.yaml \ epochs100 \ batch8 \ imgsz640 \ devicemps \ projectfight_output \ nameexp_mac纯 CPU 机器上训练batch 必须降下来workers也调低否则数据加载会成为瓶颈# 纯 CPU 平台batch 和 workers 都要保守 yolo detect train \ modelyolo11s.pt \ datafight_dataset/data.yaml \ epochs100 \ batch4 \ imgsz640 \ devicecpu \ workers2 \ projectfight_output \ nameexp_cpuCPU 平台一个 epoch 可能要跑十几分钟100 epoch 就是十几个小时这在项目时间上要提前算进去。如果只是验证流程可以把epochs先设 5 轮跑通确认数据加载、损失计算、验证流程都没问题再挂上全量训练过夜。3.4 一键训练脚本把三平台差异封装在一个 bash 里三平台训练的本质差异就三个变量device 类型、batch 大小、workers 数量。把它们抽出来做成一个自动检测平台再分配参数的脚本就能实现真正的「一键训练」#!/bin/bash # train_fight.sh - 打架检测自动训练脚本 DATASETfight_dataset/data.yaml MODELyolo11s.pt # 自动检测平台 if command -v nvidia-smi /dev/null; then DEVICE0 BATCH16 WORKERS8 elif [[ $(uname) Darwin $(uname -m) arm64 ]]; then DEVICEmps BATCH8 WORKERS4 else DEVICEcpu BATCH4 WORKERS2 fi echo 检测到平台: $DEVICE, batch$BATCH, workers$WORKERS PYTORCH_ENABLE_MPS_FALLBACK1 yolo detect train \ model$MODEL \ data$DATASET \ epochs100 \ batch$BATCH \ imgsz640 \ device$DEVICE \ workers$WORKERS \ projectfight_output \ nameexp_auto这段脚本的逻辑很直白优先探测 NVIDIA GPU有就按 GPU 的高参数跑没有 GPU 再看是不是 Apple Silicon 的 Mac是就用 MPS 加速都不是就回退 CPU 保守参数。脚本开头加了set -e能让训练中断时直接退出避免跑到一半报错还在那挂着空转。4. 训练 1000 张打架图的参数调优过拟合控制与数据增强的平衡4.1 100 轮训练里看什么指标val loss 比 mAP 更早知道你overfit了打架检测数据量只有 1000 张最核心的矛盾是过拟合。训练过程中要盯的指标顺序val loss 最先反映过拟合——train loss 一直在降val loss 从某个 epoch 开始回升就是过拟合信号mAP 是最终裁判但它在小数据集上波动很大单看 mAP 很难判断该不该停。我用的是这样的策略前 50 轮主要看 val loss 曲线一旦确认连续 10 轮不降就停后 50 轮用早停机制兜底Ultralytics 的 patience 默认 50 轮对小数据集我会手动调成 20 轮# 在 Python 里微调 yolo11s 训练流程自定义早停 from ultralytics import YOLO model YOLO(yolo11s.pt) results model.train( datafight_dataset/data.yaml, epochs100, patience20, # 20 轮不下降就早停 batch16, imgsz640, device0, cos_lrTrue, # 余弦退火学习率小数据集聚合同样有效 close_mosaic10, # 最后 10 轮关闭 mosaic让模型平稳收敛 )这个配置里close_mosaic10特别关键。YOLO11 默认前 90 轮开 mosaic但打架场景里两个人形拼接出来的合成图有时候非常诡异——肢体交错被 mosaic 一拼模型学到的是「拼接缝就是打架特征」真实场景里自然翻车。最后 10 轮关掉 mosaic 相当于让模型忘掉这些拼出来的纹理只看真实的姿态特征。4.2 数据增强参数怎么调打架场景的增强偏好与默认值差异YOLO11 自带一套增强默认值直接跑也能出效果但在打架检测上值得调两个参数。第一个是hsv_h、hsv_s、hsv_v这套色彩增强——打架检测依赖的是姿态和轮廓颜色本来就是干扰项建议把色彩增强系数调低甚至直接关闭# fight_augment.yaml 传给 Ultralytics 的自定义增强配置 hsv_h: 0.0 # 关闭色调扰动 hsv_s: 0.0 # 关闭饱和度扰动 hsv_v: 0.0 # 关闭明度扰动 degrees: 10.0 # 轻微旋转打架场景常有倾斜视角 flipud: 0.0 # 不翻转人倒了语义会变第二个值得调的是scale和translate。打架检测的难点是两个人纠缠在一起时目标框特别大有时几乎占满整张图。默认的 scale0.5 会对大目标做很大尺度的缩放相当于把纠缠体缩小成小目标模型学出来的特征对真实场景的大目标不敏感。我一般把 scale 调到 0.3让目标尺度变化更温和。4.3 小数据集下的迁移学习预训练权重选哪个哪些层要冻住1000 张图从头训练 YOLO11 基本不可能收敛必须用预训练权重。yolo11s.pt是在 COCO 上预训练过的对 person 这一类已经有很强的特征提取能力。打架检测本质上是在 person 检测的基础上精调「纠缠姿态」所以迁移的收益非常直接。Ultralytics 支持 freeze 参数冻结底层特征层但在 1000 张图这种规模下我反而不建议冻结——数据太少时冻结底层确实能防过拟合但打架场景的纹理特征和 COCO 差异太大底层冻结住了模型就学不到新的姿态特征。我的做法是全量微调但把学习率调低yolo detect train \ modelyolo11s.pt \ datafight_dataset/data.yaml \ epochs100 \ lr00.005 \ # 默认 0.01小数据集降到一半 lrf0.01 \ # 最终学习率是初始的 1% weight_decay0.0005 # 默认 0.0005保持 batch16lr00.005是降低过拟合最直接的手段。全量微调加低学习率模型有足够的容量去拟合打架特征又不会在训练后期震荡太大。观察训练日志里cls_loss的下降曲线如果这个损失一直降不动说明特征提取层的学习率还是偏高可以再降一档。5. 一键训练脚本避坑指南跨平台训练常见的 6 个坑与排查路径5.1 坑一MPS 后端跑一半报 not implemented训练直接中断现象在 Mac M1/M2 上跑训练前几十个 iteration 正常突然抛出NotImplementedError: The operator aten::_slow_conv2d_forward is not currently implemented for the MPS device。原因YOLO11 网络里的某些卷积算子没有在 MPS 后端完整实现PyTorch 的 MPS 支持虽然在快速完善但新网络结构的边缘算子经常漏掉。解决脚本里加PYTORCH_ENABLE_MPS_FALLBACK1环境变量让 PyTorch 在遇到未实现的算子时自动回退到 CPU 计算而不是直接抛异常。这个变量的原理是允许算子调度器把不支持的 op 映射到 CPU 实现代价是这部分计算慢一点但训练能正常跑完。另一个更稳妥的方案是直接用 CPU 训练YOLO11s 在 M1 Pro 上用 CPU 跑 1000 张图的 100 epoch 大概 8 到 10 小时对于只跑一次的实验完全可以接受。5.2 坑二同一份数据在 GPU 和 Mac 上训练验证集精度差一大截现象GPU 上训练完 val mAP0.5 到 0.85拿 Mac 重新训练同一份数据集同样的 epoch 数只有 0.7 左右甚至更低。原因不是 Mac 算力不够而是 batch size 不同带来的 BatchNorm 统计量差异。GPU 上 batch16Mac 上 batch8BatchNorm 的均值和方差估计在更小的 batch 上噪声更大模型的表现自然不同。另一个可能是 Mac 上某些算子在 CPU 回退时数值精度处理不一致比如浮点累加顺序不同导致的微小误差。解决Mac 上把 batch 从 8 调到 4 甚至 2如果 val mAP 反而更低了说明是 batch size 太小导致 BatchNorm 不稳定。可以用batch-1让 Ultralytics 自动检测可用内存并选择最大 batch它在 Mac 上会给出一个相对合理的值。实在不行就固定用 GPU 训练Mac 只做推理验证。5.3 坑三1000 张图训练完 mAP 很高但一上真实监控画面全乱报现象训练时 val mAP0.5 到 0.9部署到真实摄像头画面满屏都是误报框把路人走路、拥抱、甚至两个人正常聊天都标成 fight。原因这是小数据集最典型的问题——训练集和验证集来自同一批视频抽帧分布高度相似模型记住了画面背景而不是打架姿态。前面提到过按视频片段划分 train/val 就是为了缓解这个但如果数据集本身只有少数几段视频再怎么划分也躲不开背景泄露。解决最有效的办法是加背景负样本——收集 200 到 500 张没有打架行为的监控画面标注文件是空 txt混入训练集。YOLO 训练里空的标注文件不会被跳过模型会在这些图上学会「没有打架就不输出框」的特征误报问题能大幅改善。如果数据集没有附带负样本可以用数据增强随机裁剪背景区域补充。5.4 坑四windows 上跑一键脚本路径分隔符导致 data.yaml 读取失败现象在 Windows 上运行训练脚本报错Unable to read train dataset但路径看起来没问题。原因Windows 的路径分隔符是反斜杠\在 YAML 里会被解析成转义字符。例如train: D:\fight_dataset\images\train在 YAML 解析时\f会被当作换页符路径自然失效。解决在 data.yaml 里统一用正斜杠写路径Windows 的 API 完全兼容正斜杠路径或者在 bash 脚本里先转换路径格式再写入 YAMLDATASET_PATH$(realpath fight_dataset) sed -i s|fight_dataset|$DATASET_PATH|g data.yaml # 把相对路径替换成绝对路径同时规避 split 符问题5.5 坑五改了标注类别数但预训练权重的类别头没对齐现象自定义数据集的 YOLO 类别数是 1只有 fight加载 yolo11s.pt 时模型自动调整了输出层训练能跑但 loss 一开始就特别高前几个 epoch 的 loss 直接到 20 以上。原因预训练权重是 80 类 COCO 模型最后一层检测头的输出维度是(8041) x anchor 数换到 1 类数据集需要把类别分支改成(141)。Ultralytics 训练时会自动重建检测头并随机初始化新参数但随机初始化的头需要更多 epoch 才能稳定前几轮 loss 虚高是正常的。解决别自己手动改权重文件Ultralytics 的自动重建机制在新版本里可靠但要注意训练日志里是不是出现Transferred 434/456 items from pretrained weights如果 transferred 数量异常偏少比如只有 100 多说明预训练权重和模型的网络结构不匹配大概率是 yolo11s.pt 版本和 ultralytics 包版本不一致。检查一下pip show ultralytics的版本和权重文件的下载来源对应上。5.6 坑六训练到一半显存溢出OOM 中断现象GPU 训练到第 20 轮左右报CUDA out of memorybatch16 没动过前面 20 轮明明好好的。原因不是显存真的不够而是 PyTorch 的显存缓存碎片化。YOLO11 的 mosaic 数据增强在训练中段会生成较大张量加上 Ultralytics 默认缓存了一些中间结果累积下来就可能触顶。另一个常见原因是开了rectTrue矩形训练时batch 内图片尺寸不一致大的图会把显存峰值顶上去。解决最简单的方法是用batch8重新跑模型本身就小8 的 batch 在 8G 显存上很稳。进阶方案是加ampTrue混合精度训练显存占用能降三分之一左右但要在训练前确认数据集里没有 NaN 标签否则 AMP 的 loss 缩放会放大异常值导致训练发散。6. 用训练好的模型做视频推理OpenCV 接入摄像头与实时报警实现训练完不是终点打架检测最终要落到摄像头画面上。用一个 Python 脚本把验证集跑一遍视频推理确认模型在真实帧序列上的表现是上线前最该做的一件事。这个脚本的核心是把 YOLO11 的推理结果转成画框和报警信号import cv2 from ultralytics import YOLO model YOLO(fight_output/exp_auto/weights/best.pt) cap cv2.VideoCapture(demo_fight.mp4) fight_frames 0 while cap.isOpened(): ret, frame cap.read() if not ret: break results model(frame, conf0.45, imgsz640, verboseFalse) for r in results: boxes r.boxes for box in boxes: if box.cls[0] 0 and box.conf[0] 0.6: fight_frames 1 # 画框和置信度 x1, y1, x2, y2 map(int, box.xyxy[0]) cv2.rectangle(frame, (x1, y1), (x2, y2), (0, 0, 255), 2) cv2.putText(frame, ffight {box.conf[0]:.2f}, (x1, y1-10), cv2.FONT_HERSHEY_SIMPLEX, 0.7, (0, 0, 255), 2) cv2.imshow(fight detection, frame) if cv2.waitKey(1) 0xFF ord(q): break cap.release() cv2.destroyAllWindows()这段代码里conf0.45是推理置信度阈值打架检测场景建议设到 0.6 左右甚至更高——误报一次可以让保安白跑一趟漏报一次是安全事故两害相权宁可误报。fight_frames变量用来做帧级连续计数如果连续 5 帧以上都检测到 fight再触发报警能过滤掉单帧的抖动误检。实际部署到监控系统里我习惯的做法是在这个脚本基础上加一个每秒的报警聚合逻辑一秒钟内 10 帧里有 6 帧命中 fight 就推一次报警推到微信或者短信网关。这个阈值是血泪经验调出来的报警太频繁保安会静音报警太慢又失去意义。真上了生产环境还会遇到多路摄像头并发推理、GPU 利用率分配、旧 CPU 机器上推理帧率不足 10fps 的问题那时候可以建议部署方用 TensorRT 量化模型把推理压到 5ms 以内但那是下一个项目的事了。如果你手里的机器跑不动 YOLO11K230 这类带 NPU 的边缘盒子可以试试 yolo11n 量化版——精度会掉一些但换个部署可行性回来。这套流程走下来1000 张打架图训练出的模型在场景固定、摄像头角度变化不大的前提下基本能撑起一个演示级或者轻量生产的打架检测系统。至于要不要投入更多——真实项目里打架检测最大的瓶颈已经不是模型精度而是数据多样性。一个工地和一个地铁站的打架画面差异极大换场景就得补数据继续训这一点想清楚再动手希望帮到你。本文还有配套的精品资源点击获取