组会开到一半导师忽然说“今天到场的人帮我统计一下”。每到这种时候你就能体会到会议签到这件事看起来是小问题真做起来却特别烦。纸面签到要人工核对微信群接龙更乱老师要的是“谁来了、几点来的”可大家交上来的往往是“1”“收到”。我做毕业设计时索性把这件事做成了一个小系统摄像头对准会议室门口人一进来屏幕上自动弹出名字、记录签到时间全程不用手写也不用点名。整套系统的核心就是题目里这套组合——YOLO负责在画面里实时找人脸MobileFaceNet负责把人脸图像转换成特征向量再跟数据库里预注册的人脸特征做比对认出是谁就自动签到。这篇东西我会从方案选型讲到模型训练再讲到最后整套签到流程的落地包括环境配置、数据集标注、特征比对、数据库设计以及我在实际调试中踩过的一堆坑。不管你是正在做毕业设计还是单纯想在公司或社团活动里搞一个能离线跑的人脸签到方案这篇文章的思路和代码骨架应该都能直接拿来用。我尽量写得“可抄作业”但也会把每一步为什么要这么做的原因讲清楚免得你照着一顿操作之后换一个场景就不知道怎么改了。1. 项目整体设计与思路拆解1.1 为什么是 YOLO MobileFaceNet而不是一整套现成人脸识别 SDK拿到“人脸识别会议签到”这个需求时你可能会想现在云服务商不是都有现成的人脸识别 API 吗淘宝上甚至几十块钱就能买到一套人脸打卡机的方案为什么还要自己训练模型我当时考虑的核心因素有三个离线可用、可定制、成本可控。毕设答辩现场不可能依赖云端 API万一没网或者服务限流整个演示就卡住了。公司或学校会议室这种场景也未必愿意把员工/学生的面部数据传到第三方服务上去。所以系统必须能在本地离线跑通。至于为什么不直接用开源的人脸识别库比如 FaceNet 或者 InsightFace 的完整方案这就涉及毕业设计或者工程项目的“工作量与可解释性”问题了。纯调用现成 SDK论文里能写的技术点很薄而且那些大而全的框架很多细节被封装得太死摄像头角度变了、想加一个“检测是否低头/离场”的功能反而不好改。我自己训练一个 YOLO 人脸检测器再把 MobileFaceNet 当作特征提取器两个模型的分工非常清晰任何一个环节出问题都能单独替换或调试。1.2 系统处理流程的整体梳理整套签到系统的逻辑链路可以拆成五个环节视频采集调用摄像头USB 摄像头或笔记本自带摄像头获取实时帧。人脸检测YOLO 在画面中框出所有人脸输出每个人脸框的坐标。人脸预处理把框出的人脸区域裁剪下来做对齐、缩放统一变成模型要求的输入尺寸。特征提取与比对MobileFaceNet 把预处理后人脸图像映射成一个 512 维的浮点特征向量然后跟注册阶段存入特征库的向量计算相似度。相似度超过设定阈值就判定为同一人。签到逻辑识别成功的人在数据库里写入签到记录并更新界面上的参会名单。这个流程看起来简单但每个环节都有无数细节。尤其是第 4 步的特征比对阈值设得太低容易误识别设得太高又会把同一个人认成“陌生人”。后面我会专门讲我是怎么把这几个环节逐一落地的。1.3 选择这套组合的额外收益防“纸面签到”作弊之外的扩展空间传统的会议签到只解决“有没有来”的问题但人脸签到天然能多解决一层问题——代签和离场检测。YOLO 输出的不只是“这里有一张脸”还有这张脸在画面中的位置。结合目标跟踪你完全可以判断一个人签到后是不是一直留在会议室里。如果签到完就走了系统可以自动标记“早退”如果两个人挨得很近系统也能区分出左右两张脸而不是像传统红外打卡机那样需要凑上去刷一下。这个额外收益是方案选型时一个容易被忽略但很重要的加分项。特别是做毕业设计时“签到异常检测”“离场判断”这类功能点能直接写进论文的创新点里比单纯说“我调通了一个人脸识别 API”要有说服力得多。2. 核心模型解析与参数配置2.1 YOLO 在会议签到场景中的具体职责很多人看到“YOLO 人脸识别”的第一反应是YOLO 不是做目标检测的吗人脸识别不是应该用专门的人脸检测网络比如 MTCNN 或者 RetinaFace 吗为什么要在人脸签到系统里用 YOLO我在实验中也对比过 MTCNN 和 YOLO 的效果。MTCNN 的优点是轻量、在近距离大脸场景下检测速度很快但在会议室这种场景中人距离摄像头两到四米人脸在画面中占比不大而且经常存在多人互相遮挡、侧脸、低头看手机等情况MTCNN 对这类密集小目标的鲁棒性并不好。YOLO 虽然在设计上不是专门为人脸做的但它的多尺度特征融合机制对“小目标”非常友好配合合适的输入分辨率在会议室门口的视角下能稳定框出小到 40×40 像素的人脸。再说 YOLO 的版本选择问题。从 YOLOv5 开始这个系列就进入了一个“社区驱动迭代”的阶段现在已经有人用到了 YOLOv8、YOLO11 甚至更高版本。我最终选择的是YOLOv8n因为它在速度和精度之间比较平衡。具体版本对比我在下面这个表格里给你整理一下模型版本模型体积推理速度CPU特点与适用场景YOLOv5s约 14 MB较快资料最丰富部署教程最多适合新手入门YOLOv8n约 6 MB快精度比 v5s 略高训练和部署社区也很成熟YOLO11n约 5.5 MB快最新版本之一技术更新颖但资料相对少一些如果只是做毕设或者小规模内部使用YOLOv8n 是最稳妥的。它的输入分辨率我设成了 640×640在 NVIDIA GTX 1660 上单帧检测耗时大约 15 到 20 毫秒完全能满足实时性要求。即便在纯 CPU 环境下也能跑到每秒 8 到 10 帧配合人脸签到这种低频触发场景完全够用。这里还有一个容易被忽略的坑YOLO 检测出来的人脸框往往比实际人脸略大因为训练时标注框通常会多包进一点额头和下巴周边区域。如果直接把原始框送去 MobileFaceNet 做人脸识别周围背景比例会不一致影响识别效果。所以我在预处理阶段会做人脸框的“内缩”把检测框的宽高各缩小 10% 到 15%再送入特征提取模型。2.2 MobileFaceNet 的轻量化设计到底强在哪里MobileFaceNet 是专门为移动端和嵌入式设备设计的人脸识别网络核心是保证识别精度的同时把计算量压到极低。它沿用了 MobileNetV2 的倒残差结构Inverted Residual Block但在最后几层做了关键改进用全局深度卷积Global Depthwise Convolution替代了传统的全局平均池化。这个改动让网络在最后阶段保留了更多的空间位置信息从而更好地区分不同人脸之间的细微差异。我用的 MobileFaceNet 模型输出的特征向量是512 维。人脸识别本质上做的事情是经过训练后同一个人的不同照片映射出来的特征向量在空间中彼此靠近不同人的特征向量彼此远离。特征向量之间的相似度常用余弦相似度来衡量数值范围在 -1 到 1 之间越接近 1 表示两张脸越可能是同一个人。为了让这个“类内距离小、类间距离大”的目标成立训练时必须使用合适的损失函数。最常用的是ArcFace加性角度间隔损失它通过在角度空间中增加一个 margin让模型对“相同人脸”的要求更苛刻学出来的特征反而更具区分度。如果你在开源代码里看到ArcFace相关的配置文件别觉得它复杂——本质上就是在分类损失里多加了两个超参数s特征缩放因子和m角度间隔。一般使用s32m0.5作为初始配置效果就比较理想。可能有人会问直接用现成的预训练 MobileFaceNet 不就行了吗确实工程上用预训练模型就够了。但如果你是做毕设我建议至少要在自己的人脸数据集上做几轮微调哪怕数据量只有几百张。这样论文里可以写“针对会议场景进行了领域自适应微调”答辩时也更有底气。2.3 阈值设定识别准确率的分水岭人脸签到系统的“最后一道关卡”是相似度阈值。很多初次做的人会以为阈值设得越高越安全实际完全不是这么回事。我自己的实测经验是阈值设到 0.6 以上系统的拒识率会明显升高经常出现“明明是同一个人换个角度就识别不出来”的情况阈值降到 0.3 以下又会开始出现误识别——两个人长得稍微像一点就被认成同一个人。对我这个场景0.45 到 0.5 之间是比较合适的区间。但阈值不能想当然地拍脑袋定。更可靠的方法是注册 20 到 30 个人的面部特征然后分别采集每个人在不同角度的照片和库里的特征做余弦相似度计算画出“同类相似度”和“异类相似度”的分布图取两者交叉点附近作为阈值。这个方法看起来麻烦但一旦做好能在很大程度上避免后续使用中频繁遇到“误签到”或者“签不上”的问题。3. 实操过程与核心环节实现3.1 环境配置PyTorch YOLOv8 OpenCV 的版本搭配先把环境这件事说清楚因为很多人在这一步卡了一两天。我的建议是直接使用 Anaconda 创建独立的 Python 3.9 环境避免把系统 Python 环境搞乱。需要安装的核心依赖包括PyTorchCPU 版或 CUDA 版、ultralyticsYOLOv8 的开源库、opencv-python、numpy、faiss-cpu用于特征检索、pymysql或sqlalchemy数据库操作。以 GPU 版本为例安装命令大致是conda create -n face_checkin python3.9 -y conda activate face_checkin # CPU 版本 pip install torch torchvision torchaudio # CUDA 11.8 版本需要先确认显卡驱动支持 pip install torch torchvision torchaudio --index-url https://download.pytorch.org/whl/cu118 pip install ultralytics opencv-python numpy faiss-cpu pymysql这里特别提醒一点如果你用的是 AMD 显卡PyTorch 官方对 ROCm 的支持范围比较有限常规办法是先在 CPU 上把整套课程跑通再评估是否需要换设备推理。或者使用 OpenVINO 或 ONNX Runtime 做加速这块后面常见问题部分我会细说。3.2 数据集准备从自采数据到 YOLO 格式标注YOLO 要训练出稳定的人脸检测模型需要一定量的标注数据。如果你不想从零开始可以先用开源的 Wider Face 人脸检测数据集作为底座再用自己的会议室摄像头采集一些“实际场景数据”做补充微调。后者非常关键因为 Wider Face 里多是日常拍照场景会议室里常见的背光、顶光、稍远距离的人脸它覆盖得并不充分。自己标注时主流工具是LabelImg它可以输出 YOLO 格式的纯文本标注文件。标注时要注意一个很容易犯的错YOLO 格式的坐标是归一化后的中心点坐标和宽高也就是class_id center_x center_y width height所有值都在 0 到 1 之间用像素坐标除以图片宽/高得到。我第一次标注时不小心直接填了像素坐标训练时 loss 降不下去排查了很久才发现是数据格式问题。标注类别也很重要。人脸检测任务中一般就一个类别face所以class_id基本永远是 0。把几千张图标注好之后需要按训练集、验证集 8:2 或者 9:1 划分并生成对应的data.yaml文件内容大致是train: ./datasets/face_dataset/images/train val: ./datasets/face_dataset/images/val nc: 1 names: [face]3.3 训练 YOLO 人脸检测器的关键参数准备好数据集之后训练就可以开始了。如果你是微调而不是从头训练建议直接加载 YOLOv8n 的 COCO 预训练权重作为起点这样收敛快效果也稳定。一个可以直接套用的训练命令是yolo detect train dataface_data.yaml modelyolov8n.pt epochs100 imgsz640 batch16 patience15其中patience15表示 15 个 epoch 内验证集指标没有提升就提前停止防止过拟合。训练完成后在runs/detect/train/weights/目录下会生成best.pt和last.pt部署时用best.pt。关于 YOLO 训练里绕不开的“损失函数”话题简单说一下。YOLO 的损失由三部分组成边界框回归损失Box Loss、分类损失Cls Loss、置信度损失DFL。如果训练时发现边界框定位不准可以适当加大 Box Loss 的权重如果出现“框住了但不知道是啥”问题多半在分类或置信度分支。用 ultralytics 训练时这些权重可以在配置里调整但新手不建议轻易动先用默认参数跑一遍出问题再对症下药。训练完成后找一个实际的会议室视频测试一下看看不同距离和光照下的人脸检出率。我当时的经验是正脸检出率接近 100%侧脸在 60 度以内也基本没问题超过 75 度就会明显漏检。这是很正常的事没有哪个检测器能在所有角度下都完美工作所以后面部署摄像头时最好让人正对门走入而不是侧身经过。3.4 训练 MobileFaceNet 并生成特征库MobileFaceNet 的训练相对更“学术化”一些。如果你不打算从零训练可以直接下载预训练权重用它在自己的数据集上做微调。微调时需要注意人脸图片要先经过人脸检测对齐裁剪出标准化的人脸区域然后缩放到 112×112这是 MobileFaceNet 标准的输入尺寸。我在微调时针对会议场景单独做了数据增强随机调整亮度、对比度模拟室内光线变化随机水平翻转增强对左右侧脸的鲁棒性随机添加高斯模糊模拟摄像头轻微失焦随机小角度旋转抵消人员走动时头部姿态变化带来的影响。训练完成之后把注册人员的照片逐张通过 MobileFaceNet 得到 512 维向量存入特征库。特征库最简单的方式是直接存成 NumPy 矩阵每一行对应一个人工程上更规范的做法是存入 MySQL 的 BLOB 字段或者单独存成.npy文件数据库里保存文件路径。特征比对我建议用FAISS。这是 Meta 开源的向量检索库几百个人的场景用 CPU 版就非常快单次查询只有几毫秒而且代码很简单import faiss import numpy as np # features 是注册人脸的特征矩阵shape (n, 512) index faiss.IndexFlatIP(512) index.add(features) # 查询query_feature 是当前人脸特征 scores, ids index.search(query_feature.reshape(1, -1), k1) similarity_score float(scores[0][0])这里用IndexFlatIP是因为它直接计算内积和余弦相似度在向量都归一化之后是等价的。别忘了在存入和查询之前都对特征向量做 L2 归一化。3.5 签到主流程的代码骨架把检测和识别串起来的主流程核心逻辑可以抽象成下面这段 Python 代码import cv2 import numpy as np from ultralytics import YOLO import faiss yolo_model YOLO(face_detector.pt) # 人脸检测模型 face_model load_mobilefacenet(mobilefacenet.pt) # 人脸特征提取模型 index load_feature_index() # 已注册人脸特征库 cap cv2.VideoCapture(0) THRESHOLD 0.45 while True: ret, frame cap.read() if not ret: break # 1. YOLO 人脸检测 results yolo_model(frame, imgsz640, conf0.5, classes[0]) boxes results[0].boxes.xyxy.cpu().numpy() for box in boxes: x1, y1, x2, y2 map(int, box) # 2. 人脸区域轻度内缩减少背景干扰 dx, dy int(0.1 * (x2 - x1)), int(0.1 * (y2 - y1)) x1, y1, x2, y2 x1 dx, y1 dy, x2 - dx, y2 - dy face frame[y1:y2, x1:x2] if face.size 0: continue # 3. 预处理缩放、归一化 face cv2.resize(face, (112, 112)) face face.astype(np.float32) / 255.0 face (face - 0.5) / 0.5 # 4. 提取特征并检索 emb face_model(face).reshape(1, -1) score, idx index.search(emb, k1) if score[0][0] THRESHOLD: user_id id_map[idx[0][0]] check_in(user_id) # 写入签到记录 draw_success(frame, user_id, score[0][0])这套逻辑看着简单但把“检测—编码—检索—签到”这条链路完整串了起来。实际使用中还需要加一个“签到去重”的机制同一张脸连续多帧都被识别时不要每次都写一条签到记录否则一个人进场过程中可能产生几十条重复记录。我的做法是识别成功后将这个人加入一个“当日已签到”集合下次再检测到就只更新时间、不新增记录。3.6 数据库设计记录谁、什么时间、参加了哪场会议签到记录要能支撑后期查询和导出数据库表结构不能偷懒只做一张表。我的设计是至少三张表用户表user用户 ID、姓名、工号/学号、人脸特征文件路径或特征向量、注册时间。会议表meeting会议 ID、会议名称、地点、计划开始/结束时间。签到表attendance签到 ID、会议 ID、用户 ID、签到时间、签退时间、状态正常/迟到/早退。这里要特别提一下“同一个人在同一场会议中只签一次”的约束。用数据库层面的处理比较稳妥给(meeting_id, user_id)建联合唯一索引插入重复数据时用ON DUPLICATE KEY UPDATE更新时间即可。这样即使程序逻辑漏掉了去重数据库也会兜底。3.7 部署时摄像头的选点与角度调试摄像头放哪里直接决定了人脸识别效果的上限。我踩过最大的坑是会议室门口正上方安装摄像头结果人脸俯仰角度太大MobileFaceNet 对 45° 以上俯角特别不友好检出了人脸也匹配不上。后来把摄像头高度调整到 1.5 米左右与人脸基本平视识别率立刻上了一个台阶。如果实在无法避免俯角可以在预处理阶段把 YOLO 框出的人脸做一次仿射变换矫正但这会明显增加算力开销。优先建议在物理安装时把问题解决而不是在算法上硬刚。光线问题也同样重要。背光的会议室走廊里人脸经常是全黑的YOLO 很难检测到。一个低成本方案是在摄像头附近加一盏补光灯保证人脸区域亮度均匀。如果摄像头本身支持宽动态WDR功能记得打开这也是很多实际部署中把识别率从 60% 拉到 90% 以上的关键。4. 常见问题与排查技巧实录4.1 “能检测到人脸但识别总是失败”是怎么回事这是我被问得最多的问题。YOLO 框选人脸正常但 MobileFaceNet 比对后不管和谁都不够相似原因通常出在“域不匹配”上。检测出来的人脸和训练 MobileFaceNet 时所用的标准人脸格式有差异。MobileFaceNet 的训练数据基本都是经过人脸对齐的两只眼睛在固定位置脸型居中大小统一。如果你的系统直接从 YOLO 的检测框里裁出人脸就送进模型姿态、尺度和对齐程度千差万别特征自然提取不好。解决办法是在预处理环节增加一个人脸关键点检测。最轻量的做法是用 OpenCV 自带的Facemark效果不错或者直接用一个小的关键点模型如 PFLD来定位双眼和鼻尖然后根据关键点做仿射变换把眼睛对齐到目标位置。这样处理后同一张人脸的相似度分数通常会从 0.3 左右直接提升到 0.6 以上效果非常明显。4.2 识别速度慢视频画面明显卡顿入口摄像头画面通常是 1080p但如果直接把 1080p 的整帧交给 YOLO即使 GPU 能扛住CPU 环境下也会非常吃力。我的经验是先把帧 resize 到 640×640 再送检测然后把 YOLO 输出的检测框坐标映射回原始分辨率再去原图中裁剪人脸做特征提取。这样检测速度上去了裁剪出来的人脸清晰度也保证了。另一个更实用的优化是“跳帧检测”不用对每一帧都做完整的人脸识别只做目标跟踪。具体操作是每隔三到五帧跑一次 YOLO中间帧用目标跟踪器比如 ByteTrack 或简单的 IOU 匹配延续对人脸框的跟踪只在跟踪不稳定时重新触发检测。这个方案可以把 CPU 占用率直接降一半以上。4.3 不同显卡/硬件下的兼容性AMD 显卡、Intel 核显怎么办热搜词里很多人问“AMD 显卡跑 YOLO”相关的问题。实话说AMD 显卡跑 PyTorch 的体验确实不如 NVIDIA 省心主要原因是 PyTorch 对 ROCm 的支持目前只覆盖少数 Linux 发行版Windows 下的支持相对较弱。如果你手里只有 AMD 显卡有几个替代路径使用ONNX Runtime的DirectML执行后端可以直接调用 Windows 下 AMD 显卡的算力对 YOLO 这类模型效果不错使用 OpenVINO 工具套件Intel 核显和部分 AMD 显卡都有支持实在不行就 CPU 推理YOLOv8n 和 MobileFaceNet 本身就是轻量模型在 i5 级别的 CPU 上也能做到每秒 3 到 5 帧对一个“人走进门口触发签到”的场景来说已经够用了。4.4 误识别与“替身攻击”照片、视频、戴帽子怎么应对人脸签到系统最常被挑战的问题是拿一张照片放在摄像头前系统会不会直接签到成功拿手机播放一段人脸视频呢单纯用 YOLO MobileFaceNet 的静态方案确实防不住这种攻击。要解决需要加一层活体检测。成本最低的做法是“动作指令活体检测”系统提示用户眨眼、张嘴或左右转头检测到动作完成才继续识别。稍微高级一点的是用轻量深度网络判断图像是真人和翻拍屏幕屏幕上有摩尔纹特征。对毕设来说眨眼和转头动作检测已经足够支撑论文的“安全性分析”章节了。至于戴帽子、戴口罩这种遮挡场景YOLO MobileFaceNet 的表现会比较吃力。帽子口罩都遮住大部分面部特征余弦相似度基本达不到阈值。生产级系统会加多模态识别作为兜底比如同时检测员工工牌或者使用指纹二维码。签到系统的定位本来就应该是“提效”而非“绝对唯一认证”所以这个短板不用过度焦虑。4.5 常见问题速查表现象可能原因解决思路YOLO 能框住人脸但识别相似度很低没有做人脸对齐或检测框背景干扰多加关键点检测和仿射对齐检测框内缩正脸能识别侧脸完全不行训练数据中侧脸占比不足数据增强增加侧脸样本降低识别阈值识别结果不稳定同一个人时灵时不灵阈值设置不合理或光线变化大统计分析同类/异类分布后调阈值改善光照签到记录大量重复没有做人脸去重设置“当日已签到”集合或数据库唯一索引视频画面非常卡每帧全分辨率推理缩放图像 跳帧检测 目标跟踪摄像头调用失败被其他程序占用或索引错误释放占用确认设备索引检查 USB 供电5. 性能实测与后续扩展方向5.1 我当时跑出的实测数据最后把我在实际环境中的数据给你参考。硬件是 NVIDIA GTX 1660 6GB 显卡、i5-12400 CPU、普通 1080p USB 摄像头系统运行在 Windows 10 上。YOLOv8n 人脸检测单帧约 18msMobileFaceNet 特征提取单人约 5msFAISS 特征检索千级特征库下低于 1ms单次完整签到识别流程检测 对齐 编码 比对 写库约 30ms。在注册了 30 个“同事”的场景下正脸识别准确率约 96%漏识别主要发生在逆光或者人脸距离超过 3.5 米时误识别出现的次数为 0。人均签到时间大约 1 到 2 秒从走入摄像头视野到数据库写入成功。这个成绩谈不上顶尖但对一个“会议室门口自动点名”的场景来说已经足够实用。5.2 往后可以怎么扩展这个系统的架构决定了它很容易扩展。我觉得有四个方向比较值得做多路摄像头联动会议室正门和侧门各放一个摄像头使用消息队列把多路识别结果汇聚到签到服务实现“哪个门进都能签到”。会议预约系统对接和钉钉/企业微信的会议预约打通人到了自动发通知给主持人人没到自动提醒。异常人员检测配合 YOLO 再训练一个“陌生人”类别——检测到库里不存在的脸时触发告警这就从单纯签到变成了半安防系统。离场检测利用 YOLO 的检测框坐标和 ID 跟踪检测一个人签到后是否一直停留在会议室内停留时长低于阈值就自动标记为“早退”。这些方向不需要推翻现有架构都是在检测和识别的结果上再做一层业务逻辑这也算是选用 YOLO MobileFaceNet 这种组合方案的好处之一底层能力通用上层应用灵活。写在最后几点实操体会这个项目做完我最深的感受是人脸识别本身并没有想象中那么神秘真正耗时间的全在工程细节里。摄像头装多高、光线够不够均匀、阈值怎么定、对齐要不要做、数据库怎么去重、识别失败时是提示用户往前一步还是重试一次……每一件单独看都不难但堆在一起就足以让一个项目从“能跑”变成“好用”。如果让我重新做一遍我可能会在项目开始时就把摄像头安装位置和角度先确定下来而不是先把模型训练好再去迁就环境。算法和硬件之间永远是物理环境先决定上限模型再好也补不了光线和角度的差。最后再分享一个小技巧做演示的时候把识别结果和相似度分数直接显示在屏幕上观众能看到“即时反馈”比事后看签到表直观得多。这个小细节在答辩或者给领导展示时特别加分而且实现成本几乎为零——OpenCV 的putText就能搞定。项目代码我建议分开模块来组织检测、编码、检索、数据库、UI 各一个文件夹这样做毕业论文的架构图也更容易画后续自己想扩展也省心。