人脸行为检测开源方案调研

摄像头人脸与行为检测开源方案调研

更新时间：2026-06-27

1. 结论

摄像头图片或视频中检测“人脸、是否躺着、是否在工位、是否佩戴工牌”等场景，有成熟的开源组件可以组合实现，但通常不存在一个开源项目能完整、稳定地覆盖全部业务需求。

推荐采用组合式方案：

摄像头/RTSP
  -> 抽帧
  -> 人体检测
  -> 人员跟踪
  -> 人脸检测/识别
  -> 姿态估计
  -> 工牌检测
  -> 工位区域规则
  -> 告警/记录/看板

优先推荐的 POC 技术组合：

人脸检测与识别：CompreFace 或 InsightFace
人体/工牌检测：YOLO 系列、RT-DETR、MMDetection
姿态判断：MMPose、RTMPose、YOLO Pose
人员跟踪：ByteTrack、DeepSORT、BoT-SORT
视频接入：OpenCV、FFmpeg、GStreamer
部署：Docker、NVIDIA GPU、边缘盒子或中心服务器

需要特别注意：开源不等于一定免费商用。部分项目代码许可宽松，但预训练模型、训练数据或平台商用部署可能存在限制。

2. 场景拆解

场景	推荐实现方式	是否需要训练	难度	备注
检测是否有人	通用目标检测模型识别 `person`	通常不需要	低	COCO 预训练模型即可初步验证
检测人脸	RetinaFace、InsightFace、OpenCV YuNet	通常不需要	低	受角度、遮挡、光照影响
人脸识别身份	InsightFace、CompreFace、DeepFace	需要录入人员库	中	商用时要重点确认模型许可与隐私合规
是否躺着	姿态关键点 + 规则判断	通常不需要，复杂场景可微调	中	判断肩、髋、膝、踝等关键点方向
是否在工位	人体检测 + 跟踪 + 工位 ROI 区域规则	不一定	中	需要人工标注每个工位区域
是否佩戴工牌	工牌目标检测模型	基本需要	高	工牌小、反光、角度变化大，需采集现场数据
是否佩戴安全帽/工服	PPE 检测模型	可用公开数据预训练后微调	中	公开 PPE 数据比工牌更多
离岗/睡岗/异常停留	跟踪 ID + 时间规则 + 姿态规则	视场景而定	中高	需要连续帧判断，避免单帧误报

3. 开源方案对比

3.1 人脸识别方案

方案	类型	优点	缺点	免费/许可判断
InsightFace	人脸检测、对齐、识别模型工具箱	精度高，业界常用，支持 ArcFace	工程服务化需要自己封装；官方预训练模型许可需谨慎	代码 MIT；官方预训练模型常标注为非商业研究用途
CompreFace	人脸识别服务	自带 REST API、管理界面、Docker 部署，适合 POC	灵活性不如自己集成 InsightFace	Apache 2.0，整体更适合自部署验证
DeepFace	Python 人脸识别封装库	上手快，集成多种模型	生产部署需要额外工程化	代码开源，具体模型许可需逐项确认
OpenCV YuNet + SFace	轻量人脸检测/识别	轻量、部署简单	精度和生态不如 InsightFace	需确认所用模型文件许可

建议：

快速验证：CompreFace。
自研平台长期集成：InsightFace 或 OpenCV + 自有服务封装。
商用生产：务必确认“代码、模型权重、训练数据、人员数据处理”四层许可与合规。

3.2 人体、姿态、工牌检测方案

方案	适用场景	优点	缺点	免费/许可判断
Ultralytics YOLO	人、工牌、安全帽、工服、姿态	训练和部署体验好，资料多	AGPL 对闭源商用有约束	默认 AGPL-3.0；闭源商用通常需企业许可
MMPose / RTMPose	姿态估计、躺卧判断	Apache 2.0，生态完整，模型多	配置和工程复杂度较高	项目 Apache 2.0；预训练模型和数据集仍需确认
MMDetection	目标检测训练框架	模型丰富、适合训练定制模型	上手成本高于 YOLO	Apache 2.0；数据集许可需确认
MediaPipe Pose	轻量姿态估计	移动端、边缘端友好	复杂多人场景能力有限	需按 Google MediaPipe 许可确认
OpenPose	姿态估计	经典方案	较老，性能和部署便利性一般	需确认许可和依赖

建议：

快速做效果：YOLO 检测人 + YOLO Pose 判断姿态。
更重视商用许可宽松：OpenMMLab 体系，例如 MMDetection + MMPose/RTMPose。
工牌检测：不建议只找现成模型，应该采集现场图片自行训练。

4. 推荐部署环境

4.1 POC 环境

适合验证功能是否可行。

项目	建议配置
系统	Ubuntu 22.04 LTS
CPU	8 核以上
内存	16 GB 以上
GPU	NVIDIA RTX 3060/4060 或以上，8 GB 显存起步
驱动	NVIDIA Driver + CUDA
容器	Docker + Docker Compose
摄像头	RTSP 网络摄像头，建议 1080p
存储	SSD，按是否保存截图/视频决定容量

4.2 生产环境

适合多路摄像头持续运行。

摄像头规模	推荐部署
1-4 路	单台 GPU 工作站或边缘 AI 盒子
4-16 路	中心 GPU 服务器，按帧率抽帧处理
16 路以上	多节点推理服务 + 消息队列 + 中心管理平台

生产建议配置：

GPU：NVIDIA RTX 4070/4080/4090、L4、A10、A30、A5000 等
推理框架：ONNX Runtime、TensorRT、OpenVINO
服务框架：FastAPI、gRPC、Flask、Spring Boot 调用推理服务
消息队列：Redis Stream、Kafka、RabbitMQ
数据库：PostgreSQL/MySQL 保存事件，MinIO/NAS 保存截图
监控：Prometheus + Grafana

4.3 边缘部署

适合摄像头在工厂、园区、门店、机房等现场。

设备	适用情况
NVIDIA Jetson Orin Nano/NX	低功耗边缘推理，适合少量摄像头
工业 PC + NVIDIA GPU	稳定性和性能更好
普通 CPU 服务器	只适合低帧率或轻量模型

边缘部署优点：

视频不必全部上传，节省带宽。
隐私风险相对更可控。
本地告警延迟低。

边缘部署缺点：

运维成本高。
多点升级、模型更新、日志收集更复杂。
设备散热和稳定性要重点考虑。

5. 实施流程

阶段 1：现场调研

需要确认：

摄像头数量、位置、角度、分辨率、帧率。
是否有 RTSP 地址。
夜间、逆光、遮挡、强反光情况。
工位是否固定。
工牌是否统一位置、大小、颜色。
是否要求识别具体人员身份，还是只检测是否有人。
是否需要保存原始视频，保存多久。

阶段 2：定义检测规则

建议先把 AI 问题转成可执行规则：

业务问题	技术规则示例
是否在工位	人体框底部中心点落在某个工位 ROI 内，连续 N 秒
是否离岗	指定工位 ROI 内连续 N 秒无人
是否躺着	人体主轴接近水平，或肩髋关键点高度差小，连续 N 秒
是否睡岗	在工位区域内，姿态低头/趴伏/躺卧持续 N 秒
是否佩戴工牌	人体胸前区域检测到 `badge` 类别
是否为指定人员	人脸向量与人员库相似度超过阈值

阶段 3：POC 验证

建议先取 1-2 路摄像头，做最小闭环：

读取 RTSP
  -> 每秒抽 1-5 帧
  -> 检测人
  -> 画工位区域
  -> 判断是否有人在工位
  -> 检测人脸
  -> 输出事件日志和截图

POC 目标不是追求一次完成全部功能，而是验证：

摄像头画面是否足够清晰。
人脸能否看清。
工牌在画面中是否可见。
躺卧姿态是否能通过关键点稳定判断。
单路摄像头推理延迟和资源消耗。
误报、漏报主要来自哪里。

阶段 4：数据采集与标注

工牌检测、特殊姿态、睡岗等场景通常需要现场数据。

建议采集：

不同时间段：白天、夜间、逆光。
不同人员：身高、衣服、佩戴方式不同。
不同姿态：站、坐、趴、躺、弯腰。
正样本：佩戴工牌。
负样本：未佩戴工牌、胸前有手机/反光物/挂绳但无工牌。

标注工具：

Label Studio
CVAT
Roboflow
makesense.ai

阶段 5：模型训练与评估

建议指标：

Precision：报警是否准确，误报少不少。
Recall：异常是否能抓到，漏报少不少。
mAP：检测模型通用指标。
FPS：每秒处理帧数。
Latency：单帧延迟。
连续事件准确率：例如连续 10 秒离岗是否正确报警。

工牌检测建议：

不只检测整张图里的工牌，而是结合人体框，优先检测胸前区域。
小目标检测要保证输入分辨率足够高。
如果工牌太小或摄像头太远，视觉检测会不稳定。

阶段 6：生产部署

生产部署建议拆成几个服务：

视频接入服务
  -> 解码/抽帧

AI 推理服务
  -> 人体检测
  -> 人脸识别
  -> 姿态估计
  -> 工牌检测

规则服务
  -> 工位 ROI 判断
  -> 连续时长判断
  -> 告警去重

业务服务
  -> 人员库
  -> 工位配置
  -> 告警记录
  -> 截图/视频证据

前端看板
  -> 实时状态
  -> 历史查询
  -> 告警处理

6. 是否免费与许可风险

组件	是否开源	是否免费	商用注意点
InsightFace 代码	是	是	代码 MIT，但官方预训练模型多为非商业研究用途
CompreFace	是	是	Apache 2.0，适合自部署；仍需确认其内部模型与数据处理要求
Ultralytics YOLO	是	可免费使用	AGPL-3.0 对闭源商用有约束，企业内部/闭源产品需评估商业许可
MMPose	是	是	Apache 2.0；预训练模型对应数据集许可需确认
MMDetection	是	是	Apache 2.0；预训练模型对应数据集许可需确认
OpenCV	是	是	Apache 2.0，通常较友好
ByteTrack	是	是	需确认具体仓库许可
DeepSORT	是	是	不同实现许可不同
Label Studio	是	社区版免费	企业功能另计
CVAT	是	自部署免费	云服务/企业支持另计

商业项目建议：

区分代码许可、模型权重许可、训练数据许可。
不要默认把 GitHub 上的预训练模型用于商业生产。
人脸识别涉及个人敏感信息，需取得授权并明确用途。
尽量只保存特征向量和事件截图，减少原始视频长期存储。
设置数据保留周期、访问权限、审计日志。
高风险告警不要完全自动处罚，应保留人工复核。

7. 人脸识别原理

现代人脸识别一般不是直接比较两张照片，而是把人脸转换为特征向量，再比较向量距离。

典型流程：

输入图片
  -> 人脸检测
  -> 人脸关键点定位
  -> 人脸对齐
  -> 特征提取
  -> 与人员库向量比对
  -> 输出身份或相似度

7.1 人脸检测

模型先在图片中找到人脸位置，输出人脸框。例如：

face_bbox = [x1, y1, x2, y2]

常见模型：

RetinaFace
MTCNN
YuNet
SCRFD

7.2 人脸关键点与对齐

检测眼睛、鼻尖、嘴角等关键点，然后把人脸旋转、缩放到标准位置。这样同一个人在低头、歪头、侧脸时，特征提取会更稳定。

常见关键点：

左眼
右眼
鼻尖
左嘴角
右嘴角

7.3 特征向量提取

深度神经网络把对齐后的人脸变成一个固定长度向量，例如 512 维：

face_embedding = [0.12, -0.03, 0.88, ...]

同一个人的不同照片，向量距离应该比较近；不同人的照片，向量距离应该比较远。

ArcFace 的核心思想是通过角度间隔损失，让不同身份的人脸特征在向量空间中分得更开，从而提升识别区分度。

7.4 相似度比较

常见比较方式：

余弦相似度
欧氏距离

示例：

注册照：向量 A
摄像头抓拍：向量 B

cosine_similarity(A, B) > threshold
=> 判断为同一人

阈值不能照搬，需要结合现场数据调试。阈值过低会误认，阈值过高会漏认。

7.5 1:1 与 1:N

模式	含义	示例
1:1 核验	判断是不是某个人	刷脸登录，判断是否为张三
1:N 识别	从人员库中找最像的人	摄像头抓拍后，在员工库中检索身份

工位场景通常会用 1:N，但如果摄像头角度不好，人脸太小，稳定性会明显下降。

8. 推荐 POC 方案

方案 A：最快验证

适合快速判断效果。

CompreFace
+ YOLO 检测人/工牌
+ YOLO Pose 判断姿态
+ OpenCV 读取 RTSP
+ 简单 Web 页面显示结果

优点：

上手快。
人脸服务不用自己封装。
适合 1-2 周做 POC。

缺点：

商用许可和长期扩展仍需评估。
工牌检测仍需自训练。
多路视频性能需要单独压测。

方案 B：偏生产自研

适合后续做平台。

OpenCV/FFmpeg
+ InsightFace 或自选人脸模型
+ MMDetection/RT-DETR 检测人和工牌
+ MMPose/RTMPose 姿态估计
+ ByteTrack 跟踪
+ FastAPI 推理服务
+ PostgreSQL + MinIO

优点：

架构可控。
更适合模型替换和优化。
可围绕许可做更审慎选择。

缺点：

初期开发成本更高。
需要算法、后端、运维共同参与。

方案 C：边缘盒子

适合现场部署和低延迟告警。

Jetson/工业 PC
+ TensorRT/ONNX Runtime
+ 本地推理
+ 只上传事件和截图

优点：

节省带宽。
延迟低。
原始视频可不出现场。

缺点：

设备运维复杂。
模型升级和日志收集需要平台化支持。

9. 成本估算

9.1 软件成本

项目	成本
开源代码	多数可免费使用
商业许可	YOLO、部分模型权重可能需要
标注平台	自部署可免费，云服务可能收费
数据库/对象存储	自部署可免费
看板与业务系统	需要开发成本

9.2 硬件成本

主要成本来自：

GPU 服务器或边缘 AI 设备。
摄像头升级。
存储设备。
网络带宽。

粗略建议：

场景	成本级别
单路摄像头 POC	低，可用已有 GPU 电脑
4-8 路生产	中，需要 GPU 工作站或服务器
多园区多摄像头	高，需要平台化和运维体系

9.3 人力成本

至少需要：

后端/平台开发
算法工程或熟悉 CV 模型训练的人
前端看板开发
运维/部署
业务人员参与规则定义和误报复核

10. 主要风险

风险	说明	缓解方式
人脸太小	摄像头距离远，无法稳定识别	调整摄像头位置或只做人形检测
工牌太小	工牌检测最容易受距离影响	采集真实数据，提升分辨率，检测胸前区域
光照变化	夜间、逆光、反光导致误报	增加补光，分场景训练
遮挡	口罩、低头、背对摄像头	多摄像头、多规则融合
姿态误判	弯腰、趴桌、躺卧边界模糊	连续时间判断 + 人工复核
许可风险	开源代码和预训练模型许可不同	上线前做许可证审查
隐私合规	人脸属于敏感个人信息	明确授权、最小化保存、访问审计

11. 建议落地路线

建议按三步走：

先做 1-2 路摄像头 POC。
确认人脸、工位、姿态、工牌在真实画面中的可检测性。
再决定是否训练工牌模型、是否购买商业许可、是否边缘部署。

最小 POC 目标：

能读取 RTSP。
能检测人。
能配置工位区域。
能判断在岗/离岗。
能检测人脸。
能保存事件截图。
能初步判断躺卧或趴伏。

第二阶段再加入：

工牌检测模型训练。
人脸人员库。
多路摄像头调度。
告警看板。
权限与审计。

12. 参考项目与资料

InsightFace: https://github.com/deepinsight/insightface
InsightFace Python README: https://github.com/deepinsight/insightface/blob/master/python-package/README.md
CompreFace: https://github.com/exadel-inc/CompreFace
CompreFace Helm Chart: https://github.com/exadel-inc/compreface-helm-chart
Ultralytics YOLO Docs: https://docs.ultralytics.com/
Ultralytics YOLO Pose: https://docs.ultralytics.com/tasks/pose/
Ultralytics Licensing: https://docs.ultralytics.com/
MMPose: https://github.com/open-mmlab/mmpose
MMDetection: https://github.com/open-mmlab/mmdetection
ByteTrack: https://github.com/ifzhang/ByteTrack
DeepSORT: https://github.com/nwojke/deep_sort
OpenCV: https://opencv.org/
Label Studio: https://github.com/HumanSignal/label-studio
CVAT: https://github.com/cvat-ai/cvat