YOLOv11实现人脸识别与异常行为检测的端到端部署实践

简介基于YOLOv11的《人脸识别异常行为检测端到端部署指南》是一份面向安防行业与计算机视觉开发者的技术手册旨在解决传统目标检测效率低、成本高及复杂场景下识别精度不足的问题。资源为单个PDF文档共34页大小仅2.02MB却系统串联了从算法原理到项目落地的完整知识链从YOLO系列发展历程、YOLOv11整体架构与骨干/颈部/检测头设计到人脸识别与人脸特征提取的融合再到异常行为检测的规则、机器学习与深度学习方法并进一步展开端到端部署所需的服务器与摄像头环境搭建、数据集清洗与增强、模型训练与调优、量化剪枝与推理加速以及商场、厂区、校园等真实案例评估。文档支持目录章节跳转和阅读器大纲显示图表与代码展示完整。目前已有125人学习浏览适合安防方案设计、模型部署与算法升级人群参考。1. 为什么YOLOv11能把人脸识别和异常行为检测做成一条部署链路安防项目里人脸识别和异常行为检测长期是两套独立子系统一边抓拍比对身份一边盯打架、跌倒、闯入。真动手做时你会发现两类任务底层是同一个问题先定位目标再分类或抽取特征。YOLOv11提供了一个统一的检测基座人脸走“检测加特征比对”异常行为走“目标框加时序判定”两边共享同一套推理引擎、同一份算力调度、同一种标注规范。下面按数据准备、模型训练、推理部署、调试验证四个环节把端到端方案的完整做法讲清楚。它可以落地成毕业设计、中小型安防项目也可以给现有监控系统叠加智能识别能力面向手里有GPU、想快速跑通一版可交付方案的人。2. 数据准备与标注人脸和异常行为怎么喂给YOLOv112.1 人脸识别在YOLOv11里的正确拆法先纠正一个常见误解YOLOv11不做人脸识别做的是人脸检测。想让检测器直接输出“张三”“李四”这种身份标签单帧看勉强能跑换角度换光线就崩。原因在于检测器的分类分支是闭集分类没有度量学习的约束同一张脸的类内距离可能比不同人的类间距离还大开集比对完全不可控。标准做法是两级结构。第一级YOLOv11只输出人脸框类别固定为face第二级把人脸框从原图裁剪出来resize到112x112或160x160交给FaceNet或ArcFace提取128维或512维特征向量再和注册库里的特征做余弦相似度计算超过阈值才判定为同一人。这样拆最大的工程收益是增量注册免训练。安防项目的人脸库每周都在变新员工入职、访客登记只需要往特征库里加一条记录YOLO模型和embedding模型都不用动。之前有一个项目坚持让YOLO直接认保安每次换人都要重训两个小时换成两级结构后新增人员变成了两秒入库。这里顺带说明embedding模型的选型。离线环境下优先用MobileFaceNet或者带量化版本的ArcFace模型体积小CPU上也能跑实时。FaceNet的优点是开箱即用、权重好找缺点是推理比MobileFaceNet重放在树莓派这类边缘设备上会吃力。选哪个不取决于准确率取决于部署目标GPU服务器上没有差别边缘设备上差距立刻显现。2.2 异常行为数据集的类别设计与标注格式异常行为检测极度依赖业务定义。同样是“摔倒”病房里是缓慢倒地厂区车间是瞬间栽倒标注形态完全不同。类别设计建议控制在3到8个以内数目更多模型会互相混淆。实际项目里我习惯把类别定义为face、person、fall、fight这4个覆盖安防场景的常见诉求多余动作留给规则层去判。类别ID名称标注目标后续判定特征0face人脸框送入embedding比对身份1person完整人体框所有行为分析的主体2fall倒地的完整人体框宽高比大于1.3且连续保持3fight互相接触的两个人双框重叠大且帧间位移剧烈标注文件用YOLO格式一张图像对应一个同名txt每行是“类别ID 中心点x 中心点y 框宽 框高”xywh全部归一化到0到1# images/train/000001.txt 0 0.421 0.385 0.128 0.231 1 0.510 0.402 0.110 0.205 2 0.613 0.455 0.094 0.197第一行是类别0的face框中心点在(0.421,0.385)宽0.128高0.231第二行是类别1的person第三行是类别2的fall。标注环境用X-AnyLabeling或LabelImg直接导出YOLO格式坐标不用手工转。数据采样推荐按每秒2帧抽帧异常行为相邻帧姿态差异极小全标只会浪费时间打架这类高频动作单独提到每秒4帧避免漏掉接触瞬间。类别不平衡也要在前面处理。行为数据集中person框占比可能超过九成fall和fight只有百分之几直接训练的话梯度被person类主导行为类到后期很难收敛。常规做法是把行为类别样本复制两到三遍或者对行为类别单独做水平翻转和亮度抖动扩充再合并回训练集。动手训练之前先跑一次类别计数把每个类别的样本数打印出来这个动作花不了几分钟能省下后期反复重训的时间。2.3 小目标优化切图推理和训练分辨率怎么配合监控画面里人脸经常只有几十个像素缩放到640x640输入后更小YOLOv11的浅层特征图负责小目标但十几个像素的信息量不足以稳定检出。常用手段有两个第一是推理分辨率提高到960或1280mAP能小幅上涨显存和延迟也同步上涨第二是切图推理把大图切成512x512的patch逐个推理再合并人脸被等效放大检出率提升非常明显。切图overlap建议设64像素防止目标正好卡在patch边界被切开。合并结果后跑一次NMS去重import cv2 from ultralytics import YOLO model YOLO(best.pt) img cv2.imread(camera_1080p.jpg) H, W img.shape[:2] patch_size 512 overlap 64 detections [] for y in range(0, H, patch_size - overlap): for x in range(0, W, patch_size - overlap): patch img[y:y patch_size, x:x patch_size] result model.predict(patch, imgszpatch_size, conf0.25, verboseFalse) for box in result[0].boxes: cx, cy, bw, bh box.xywh[0].tolist() # patch内的坐标要加上起点偏移才是原图坐标 detections.append((int(box.cls[0]), cx x, cy y, bw, bh))外层循环的步长是patch_size减overlap等于448像素这样相邻patch之间有64像素重叠。内层每检测到一个框就把patch内坐标平移回原图坐标。切图推理的耗时约为整图推理的2.5倍部署时可以在画面上只对远端区域切图近景区域整图推理最后按区域拼接效果几乎不受影响。3. 训练与调参YOLOv11的关键超参数与收敛判断3.1 数据集描述文件与模型档位选择训练走Ultralytics标准流程先准备一个数据集描述文件data.yaml# data.yaml path: /data/security train: images/train val: images/val names: 0: face 1: person 2: fall 3: fight其中names的顺序必须和标注txt里的类别ID严格一致否则训练出来的模型语义会错位。path指向数据集根目录train和val是相对path的路径目录结构就是images/train和images/val下面各放图片和同名txt。模型档位一般选yolo11n或yolo11s。人脸检测任务单一yolo11n足够行为检测要覆盖小目标和姿态轮廓yolo11s的浅层特征图通道数更大小目标信息保留更好推荐作为默认。网络结构本身不需要改yolo11s.yaml里边的backbone和head配置是ultralytics官方调好的重点放在数据和超参上。如果目标检测框一直偏大或者偏小优先确认标注有没有系统性偏差不要一上来就动anchor相关配置YOLOv11已经用anchor-free的decoupled head把这个问题弱化了很多。3.2 训练命令与五个必调参数yolo train \ datadata.yaml \ modelyolo11s.pt \ epochs200 \ imgsz640 \ batch32 \ lr00.01 \ patience30 \ workers8 \ projectruns/security \ nametrain_v11sbatch32适合24GB显存显存不够降到16时lr0最好同步降到0.005梯度噪声变大后学习率不变容易震荡。imgsz640是常规训练尺寸如果推理确定用960先640跑30个epoch再改imgsz960接着finetune直接拿640权重在960上推理前几十帧bbox会有一段适应期。lr00.01对yolo11s是合理起点训练过程中出现nan就降到0.005不要只顾着等。patience30表示验证指标30个epoch不更新就提前停止安防数据类别不平衡150个epoch后常有平台期不提前停就是在等过拟合。workers8是数据加载线程数CPU核数少或磁盘慢时降到4。参数推荐值过低过高batch24G显存用3216时同步降lr64时确认显存和迭代数imgsz640起步检测性能下降显存和训练时间翻倍lr00.01收敛慢损失曲线震荡或出现nanpatience30容易过早停机浪费训练时间close_mosaic10模型适应不了真实分布小目标增广不足close_mosaic这个参数值得单独说。mosaic增强在数据集中小目标占比高时经常把目标裁掉一半难以学到完整形状。ultralytics支持在最后N个epoch关闭mosaic让模型回归真实数据分布。安防项目里设成10比较稳妥最后一个类的收敛和mAP都会有改善。3.3 收敛判断与常见失败模式不要只看训练loss验证集上的mAP50和mAP50-95才是判断依据。实用标准人脸mAP50到90以上行为类mAP50到75以上。如果行为类别卡在60附近上不去先查一件事训练集是不是全来自同一个摄像头。行为数据的背景多样性比数量更关键至少从3个不同机位采集否则模型学到的是机位特征而不是动作特征换场景直接失效。训练到一半loss出现nan优先检查lr0和batch的组合lr00.01配合batch16有时候会撞上异常梯度降到0.005基本能解决。训练结束前再看一眼验证集的混淆矩阵person被误检成fall、face被误检成person这类跨类别错位往往说明标注边界不清晰回炉修标注比调参有效得多。YOLOv11的训练日志会输出每一类的precision和recall逐类检查比只看整体mAP更容易定位问题。4. 端到端部署YOLOv11的模型导出与推理管线组装4.1 从pt权重导出ONNX和TensorRT Engine训练完在runs/security/train_v11s/weights下会得到best.pt。部署前先转格式常见流程是先ONNX再Engineyolo export modelbest.pt formatonnx imgsz640 dynamicTrue opset12 simplifyTrue yolo export modelbest.pt formatengine imgsz640 dynamicFalse halfTrue第一行导出带动态batch的ONNX视频流场景每帧检测目标数不定动态维度很有必要。第二行导出TensorRT engine固定batch1用FP16精度单路1080p视频在常见GPU上检测耗时可压缩到2至3毫秒。导出后一定要做精度对比用同一份验证集分别跑pt和enginemAP50差异应该在0.5个百分点以内。差异大优先怀疑FP16精度损失去掉half转一版FP32的engine再对比。这一步省不得很多项目上线后才发现部署格式和训练格式之间有精度黑洞。注意TensorRT engine与GPU型号和驱动版本强相关换一台机器必须重新导出。这个约束写进部署文档能省不少现场排查时间。边缘设备走哪条路要看算力。NVIDIA Jetson系列可以直接跑engine延迟可控。树莓派这类不带TensorRT的平台只能用ONNX Runtime或OpenVINO的单精度模型延迟会高一个量级这时候考虑把推理分辨率降回640并用切图只覆盖关键区域。4.2 推理管线目标跟踪、人脸特征与结构化输出端到端部署最终是把视频流转成结构化事件YOLO输出只是开头。完整步骤是解码视频帧运行YOLO检测多目标跟踪稳定track_id人脸框裁剪后做embedding规则层消费检测序列判断异常。Ultralytics的predict接口已内置ByteTrack跟踪不用额外维护跟踪实例from ultralytics import YOLO model YOLO(best.engine) results model.predict(frame, conf0.3, iou0.45, trackerbytetrack.yaml, verboseFalse) xyxy results[0].boxes.xyxy.cpu().numpy() ids results[0].boxes.id.cpu().numpy() clses results[0].boxes.cls.cpu().numpy() for box, tid, cls_id in zip(xyxy, ids, clses): x1, y1, x2, y2 [int(v) for v in box] if cls_id 0: # 裁剪人脸送入FaceNet/ArcFace和注册库比对余弦相似度 face_crop frame[y1:y2, x1:x2] elif cls_id 1: # person框交给规则层维护时序判定队列 fall_rule.update(box, frame.shape[0])tracker参数传一个yaml文件ultralytics会创建对应的ByteTrack跟踪器。track_id只在当前视频流内有效摄像头重启或切换场景后ID会重新分配所以身份识别要依赖embedding比对结果不能依赖track_id这一点在多人同时进出画面时尤其重要。embedding推理本身要控制线程。一个线程跑YOLO检测和跟踪另一个线程消费裁剪出来的人脸图做特征提取两个线程之间用队列解耦。人脸特征提取在CPU上也能跑但和检测抢CPU会拉高延迟GPU有空闲时把embedding也放GPU上显存占用多几百MB换来的是整体吞吐翻倍。4.3 行为判定的规则层实现打架、摔倒天然是时序事件单帧检出说明不了问题连续几帧的语义连贯才是报警依据。模型层提供空间事实规则层做时间约束两层各司其职。摔倒的规则层可以用deque维护时序队列from collections import deque class FallRule: def __init__(self, frames5, ratio1.3, min_move0.05): self.history deque(maxlenframes) self.frames frames self.ratio ratio self.min_move min_move def update(self, box, frame_h): x1, y1, x2, y2 box w x2 - x1 h y2 - y1 r h / w if w 0 else 0 center_y (y1 y2) / 2 / frame_h self.history.append((r, center_y)) if len(self.history) self.frames: return False first self.history[0] last self.history[-1] # 宽高比连续超过1.3且中心点相对首帧下沉超过5%画面高度 return all(r self.ratio for r, _ in self.history) and last[1] - first[1] self.min_move为什么用宽高比而不是面积人倒地后面积变化不大但宽高比会从0.6左右跳到1.5以上信号稳定得多。打架规则也类似两个person框的中心距连续6帧小于画面宽度的15%同时重叠面积超过40%才判定为打架事件。这类参数不要硬编码放进配置文件现场根据摄像头安装高度和角度调整。场景模型层输出规则层判定条件上报方式跌倒person框宽高比连续5帧以上大于1.3中心下移5%单摄像头事件打架两个person框中心距连续6帧小于画面宽15%重叠面积大于40%单摄像头事件长时间逗留person框同一track_id在指定多边形内停留超过设定秒数联动截图规则层解决了两个模型解决不好的问题单帧误检和帧间抖动。墙上的人形海报被识别成person尺寸位置长时间不变不满足下拉和位移条件不会触发摔倒报警。这比换模型压误报更可控。5. YOLOv11部署后的阈值调优与报警结果保存5.1 三个推理参数的设置经验conf_thres默认0.25在安防场景并不总是最优。人脸识别建议调低到0.15人脸小遮挡多漏检比误检代价更大多余的误检框交给embedding过滤余弦相似度过不了阈值自然不会报身份。异常行为反过来conf调高到0.35或0.4行为误报会快速消耗安保人员对系统的信任连续两次假报警之后真报警也没人看了。iou_thres默认0.7密集人群场景建议降到0.5两个人擦肩时检测框重叠大iou阈值太高会把两个框合并跟踪ID也会跟着跳。这三个参数之间有关联改conf之后最好重新统计一遍事件级prec和recall不要单独调一个就上线。conf调低会让跟踪链路上多出很多低置信度框ByteTrack的匹配逻辑也会受到影响。5.2 报警结果与推理结果的落盘方式验证阶段不能只看控制台输出要把推理结果落盘方便回查现场。按帧保存报警截图用frame_id命名每隔30帧保存一张抽样图from pathlib import Path import cv2 save_dir Path(alerts) / cam01 save_dir.mkdir(parentsTrue, exist_okTrue) frame_id 0 while cap.isOpened(): ok, frame cap.read() if not ok: break results model.predict(frame, trackerbytetrack.yaml, conf0.3, verboseFalse) # 检测结果画框并标注track_idaudio_triggered为规则层返回的报警标志 rendered render_alerts(frame, results) if frame_id % 30 0 or event_triggered: cv2.imwrite(str(save_dir / fframe_{frame_id:06d}.jpg), rendered) frame_id 1event_triggered来自规则层的判定结果报警帧额外保存没报警时只做抽样磁盘压力小。部署实践中也可以把每个框的box、conf、track_id、cls写进SQLite一张表存帧级框信息一张表存事件信息事后审计直接查库需要重新出图时按frame_id定位。5.3 事件级验证与回归对比最终验收前录一段15分钟的混合场景视频覆盖白天、逆光、密集人流三种情况。人工标注每个事件发生的帧区间跑一遍完整推理链路按事件级统计precision和recall同一事件连续触发30帧只算一次。单帧级指标会被连续性噪声污染事件级指标才代表安保业务的实际收益。把统计分析脚本固定下来之后每次调整阈值或更换模型都跑同一段视频结果输出JSON和上一次对比。对比内容包括mAP、事件级prec/recall、平均报警延迟数据会回答“这次的改动是变好了还是变差了”。这套流程每次只需要十几分钟但能在模型迭代过程中持续兜底。本文还有配套的精品资源点击获取