我这两年陆续帮几个学生和同行看过类似的毕业设计项目人脸识别签到这个方向确实被选得很多。但大部分作品还停留在跑通Demo阶段——拿着开源模型套个界面能认出几个人就算完事。真正把会议签到场景的痛点想清楚、把YOLO MobileFaceNet这套组合背后的分工逻辑讲明白的其实很少。这篇文章就围绕这个题目把我做项目时积累的选型思路、数据准备、训练调参、系统集成、部署优化这些环节完整拆一遍。无论你是正在选毕设题目的在校生还是想快速落地一套刷脸签到方案的开发者应该都能从中找到可以直接复用的东西。1. 项目立项分析为什么选 YOLO MobileFaceNet 这套组合1.1 会议签到的真实痛点从手动签到到无感人脸签到的升级逻辑先说一个不少人容易忽略的问题会议签到和闸机门禁、考勤机打卡看起来都是人脸识别实际上场景约束差很多。门禁场景下人通常是主动配合的——站在固定位置正对摄像头光线可控一次只过一个人。而会议签到的典型画面是一群人同时走向签到台姿态随意有人低头看手机有人侧身和同事说话光线还可能被大屏幕的投影光干扰。如果照搬门禁那套先检测人脸-再对齐-再识别的单人流程第二个人就会被第一个人挡住产生大量漏检。所以会议签到系统的第一个核心需求是能在一帧画面里同时定位多个人脸。这就直接指向了目标检测模型而不是传统的图像分类思路。第二个痛点是识别速度。一场几十人的会议签到集中发生在会前十分钟。如果每个人的识别耗时超过一两秒队伍就会堵在门口。MobileFaceNet这类轻量级识别网络单次特征提取在CPU上都能做到几十毫秒配合GPU推理更是毫无压力这正好符合高峰期高并发的场景要求。第三个痛点是误识别的代价。会议签到不像支付场景那样对误识有极高的资金风险但也绝不能让A签成B——这会导致考勤记录错误后续补签很麻烦。所以识别阈值必须结合场景数据做校准而不是直接用模型的默认值。1.2 模型选型推演检测和识别为什么要分开做很多初学者会问为什么不直接用一个人脸识别模型搞定所有事情比如FaceNet、ArcFace这类模型输入一张人脸图就能输出特征向量。问题在于它们要求输入已经是对齐后的人脸也就是要先有人把脸从画面里切出来。而这个切出来的动作正是YOLO最擅长的事。于是整个系统被拆成两级第一级YOLO做人脸检测Face Detection。输入是完整的摄像头画面输出是每个人脸的边界框。YOLO的回归思想适合处理密集、多尺度、姿态各异的目标而且推理速度快单张1080P画面在GPU上几毫秒就能完成。第二级MobileFaceNet做人脸识别Face Recognition。把YOLO裁出的人脸区域缩放到112×112或96×96送入MobileFaceNet提取128维或512维特征向量然后与数据库中预存的签到人特征做余弦相似度比对超过阈值就确认身份。这两级是解耦的、可以独立优化。比如检测漏了某个角度的人脸你只调YOLO的推理阈值或增加训练数据不影响识别模型识别精度不够你只换更强的骨干网络或加大人脸数据集也不影响检测速度。这种各司其职的架构在工程上最灵活也最好排查问题。1.3 与其他人脸识别方案的对比为什么不用纯 FaceNet 或 ArcFace 全家桶顺便做个横向对比。有些人脸识别库自带检测器比如FaceNet官方实现里用的MTCNN或者是OpenCV里的DNN人脸检测器。它们能不能用能用但有几个问题方案检测能力识别能力工程复杂度适用性MTCNN FaceNet多尺度但对密集小脸一般强中等适合单人或小规模OpenCV DNN检测 自选识别速度快但边框质量一般取决于识别模型低适合快速原型YOLO MobileFaceNet密集场景强边框稳定强而且轻量中高适合真实会议场景商用SDK全家桶好但闭源好低适合预算充足的团队对于计算机毕业设计这个定位YOLO MobileFaceNet的优势不只是技术指标更在于每一层都有很好的可视化效果和可解释性。答辩时你可以展示检测框、置信度、特征比对的过程这些是评审老师非常吃的一套东西。而且这两个模型都有开源的预训练权重从零训练的门槛不高。2. 数据准备与标注决定上线效果的第一道关卡2.1 人脸检测数据的获取与标注格式转换YOLO要做的是通用人脸检测这类公开数据集其实很丰富。最常用的包括WIDER Face3万张图片40万人脸标注覆盖各种尺度、遮挡、姿态是人脸检测领域的标杆数据集。FDDB虽然主要用于评测但也可以拿一部分做训练。但有个坑WIDER Face 的标注格式是椭圆的而YOLO需要的是矩形框的归一化坐标格式是class_id x_center y_center width height这些值都是相对于宽高的比例。所以你得写一个转换脚本把WIDER Face的椭圆标注转换成矩形框。这里有一个细节椭圆的外接矩形要稍微外扩一点因为椭圆标注本来就很贴近人脸边缘直接取外接矩形会导致裁掉额头和下巴训练出来的检测框会偏紧影响后续识别分支的输入质量。如果只是想快速跑通也可以直接用ultralytics库内置的数据集下载工具拉取COCO128这种小型数据集验证流程。但为了检测效果最终还是要回到WIDER Face这种正经的人脸检测数据上。2.2 人脸识别数据集的组织策略一人多照与跨场景采集MobileFaceNet训练用的数据集主流是MS-Celeb-1M和VGGFace2。MS-Celeb-1M虽然名头大但官方版本有不少噪声标注需要清洗VGGFace2的类别数和图片质量都不错而且包含不同姿态、年龄、光线条件下的图片很适合做人脸识别训练。不过对于毕设项目我不建议一开始就跑全量数据集训练MobileFaceNet。更务实的做法是下载已经训练好的MobileFaceNet权重比如在MS-Celeb-1M上训练后发布的预训练模型。用VGGFace2或LFW做微调让模型适应你的业务场景。为你的会议签到人员每人采集5-10张照片加入训练集做最后的domain adaptation。第三点特别重要。公开数据集里的人脸和你们公司/学校会议室里的人脸在拍摄角度、光线、摄像头型号上都有分布差异。我见过不少项目用公开权重直接测试识别率看着还行但一放到真实会议室就明显下降——原因就是domain shift域偏移。所以花时间给实际参会人拍几组照片收益非常大。2.3 数据清洗与隐私合规处理人脸数据有一个绕不开的话题隐私合规。做毕设或者内部项目至少要遵守几个基本底线采集人脸照片前告知对方用途取得口头或书面同意。照片只用于特征提取和模型训练不用于其他目的。训练结束后原始图片建议删除或脱敏处理。系统中存储的应该是特征向量而不是人脸原图。特征向量无法直接还原成人脸图像这样即使数据库泄露风险也可控。在技术实现上MobileFaceNet输出的特征向量是固定维度的浮点数数组存储非常轻量。一张512维的特征用float32存储才2KB一个1000人的会议签到库也就2MB左右完全可以在本地SQLite或MySQL里存。你的签到系统按照摄像头抓拍-实时提取特征-与库中特征比对的流程来做原始画面只出现在内存处理管线中不落盘这种设计无论是答辩还是实际部署都说得过去。3. 模型训练的关键细节与踩坑记录3.1 YOLO 检测分支的训练要点与损失函数观察YOLO发展到今天从最初的YOLOv1到现在的YOLOv8、YOLOv9甚至更新的v10/v11核心范式一直在演进。对于人脸检测这个任务我的建议是用YOLOv8n或者YOLOv8s这种轻量规格起步。选择YOLOv8而不是更早期的v5的原因主要是工程便利性ultralytics库把数据加载、训练、验证、导出包装得很好接口统一对新手友好。v8内置了anchor-free的检测头对人脸这种目标尺寸分布比较集中的场景精度和召回平衡得不错。减少了很多手工调anchor的麻烦。但这里我要强调人脸检测的目标相对单一如果你不想被损失函数和anchor的细节占用太多时间直接套用YOLOv8的默认配置通常就能达到可用的水平。真正要盯的是训练过程中的三个指标曲线train/box_loss边界框回归损失。如果这个值在后期还持续大幅下降说明模型还在努力适应训练集中的尺度分布可以有意识地多等几个epoch再看。train/cls_loss分类损失对于人脸检测来说就是人脸 vs 背景的二分类。如果收敛得太快比如前5个epoch就降到很低要警惕过拟合尤其是训练集偏小的时候。metrics/mAP50-95综合精度。人脸检测的场景下mAP50-95比mAP50更能反映框的定位质量因为mAP50只要求IoU超过0.5框位置差很多也算对这在后续送识别网络时影响很大。我还踩过一个具体的坑训练时用了数据增强里的旋转degrees旋转角度给到了30度结果模型在检测正脸时反而出现了很多漏检。原因很简单人脸本身就很少出现大幅度旋转过度的旋转增强引入了大量现实中不存在的训练样本反而干扰了模型学习正常角度的人脸特征。这个问题在调参时特别容易被忽略因为训练集loss看着很漂亮但val集指标却上不去。3.2 MobileFaceNet 识别网络的训练配置与迁移学习MobileFaceNet是谷歌MobileNetV2在人脸识别方向上的改进版核心是用深度可分离卷积大幅降低计算量同时在网络设计中引入了针对人脸特性的调整——比如用Global Depthwise Convolution替代全局平均池化让网络更关注人脸中心区域的特征。训练时MobileFaceNet最常用的损失函数是ArcFaceAdditive Angular Margin Loss。它的核心思想是在特征向量与类别中心向量之间的夹角上加上一个角度余量m让模型学到区分度更大的特征。两个关键超参数s缩放因子一般设64控制logits的大小。m角度余量一般设0.5。调大m会增强类间距离但过大比如0.7以上会导致训练不稳定或难以收敛。我通常在训练MobileFaceNet时用这样的策略加载预训练权重冻结前面大部分层只训练最后的全连接层和ArcFace层。跑5-10个epoch把新类别的分类器学出来。解冻全部层用很小的学习率初始1e-4指数衰减再训练10-20个epoch。一个常见的错误是直接从头开始训练MobileFaceNet。这个网络虽然轻量但也有几十层结构从头训练需要海量数据否则必然过拟合。迁移学习在这种情况下几乎是个必选项。3.3 训练过程中的典型问题过拟合、难样本、类别不均衡这三类问题是训练人脸识别模型时绕不开的坎我分别说下我的处理方式。过拟合最直接的信号是训练集acc接近100%但验证集只有90%出头。除了常规的早停和数据增强对人脸识别特别有效的一个手段是随机擦除Random Erasing——把图中随机一块区域置为灰色或噪声强迫模型不能只依赖某一个局部特征比如只看眼睛或只看嘴巴做判断。这会显著提升模型对遮挡的鲁棒性。难样本这里的难通常指同一个人在不同光照、姿态下长得差别很大或者不同人脸长得极为相似。MobileFaceNet输出的特征向量本身是连续空间里的点ArcFace损失只是拉开分类边界的角度但它并不会主动去挖掘难样本。我的经验是训练完一轮后用验证集找出所有识别错误或置信度接近阈值的样本重点关注这些样本来自哪个类别、什么拍摄条件然后针对性地补充对应条件下的训练数据。很多情况下难样本问题靠数据增强是解决不了的必须额外采集数据。类别不均衡一个人有50张训练照片另一个人只有5张模型必然偏向前者。解决方案有两个方向采样层面对照片少的类别做过采样或者对照片多的类别做欠采样。人脸数据总量通常不大过采样更实用。损失层面ArcFace变体里有不少针对长尾分布的设计比如Circle Loss它的自适应权重天然缓解了类别不均衡的影响。如果你发现用ArcFace训出来的模型在少数类别上表现明显差可以试试换成Circle Loss做对比实验。4. 系统架构与签到业务流程设计4.1 整体架构摄像头采集、推理服务、数据库的协作方式一个能稳定运行的人脸签到系统架构上需要分三层采集层摄像头负责连续抓帧。这里有一个工程优化点不要每帧都送去做检测。通常1080P分辨率的摄像头实时流是30fps但人脸检测和识别不需要这么高的频率。如果5fps就足够覆盖人员走入签到区域的整个过程那么每6帧才处理一次CPU和GPU的负载直接降到原来的1/6。推理服务层这一层主要承担YOLO检测和MobileFaceNet识别两段推理。为了让两段逻辑解耦用一个队列把检测结果传递给识别线程。检测线程把每个人脸的裁切图放进队列识别线程从队列取出图片提取特征并比对这种生产者-消费者模式在Python中直接用queue模块就能实现。数据层签到记录、人员库、特征向量库三张核心表。人员信息与特征库分离的好处是之后重新训练模型生成新特征时不需要动人员表同理人员信息有变动比如新增参会人时也不需要重新训练特征库只用新照片提取一次特征入库即可。4.2 签到逻辑的核心设计检出-识别-记录三步如何串成闭环签到核心流程我建议按下面的时序设计人脸检出YOLO输出一系列检测框过滤掉置信度低于0.6的框这个阈值要根据实际摄像头距离调整太近会误检背景太远又会漏检。跟踪去重这是决定签到系统体验好不好的关键。如果每帧都做完整识别同一人在画面里停留3秒、每秒处理5帧就会产生15条记录全部写入数据库的话签到表直接爆炸。所以一定要做一个轻量级的目标跟踪去重对同一个检测框在相邻帧之间用IoU交并比进行关联只有新出现的人脸框才触发识别逻辑已经识别过的人脸框标记为已签到不再重复处理。更简单的方式是直接在内存里维护一个last_seen字典key是检测框的中心坐标value是最近一次出现的时间戳中心坐标移动距离小于一定阈值的就认为是同一个人。特征提取与比对拿到规范化后的112×112人脸图输入MobileFaceNet得到特征向量与库里所有特征算余弦相似度。相似度最高且超过阈值T的认为是匹配阈值建议从0.4-0.5之间起步具体看你们用的距离度量方式。记录与反馈签到成功后在界面显示姓名和签到时间插入数据库同时标记此人今天已签到。这里有个小细节会议签到允许一次识别永久有效但也要处理识别失败的情况。我建议设置一个最大重试次数比如3次。如果连续3次识别都低于阈值就把人脸裁切图存到unrecognized表里方便之后人工核对补签。这在真实场景中非常重要因为总会有人当天状态特殊比如刚换发型或者戴了口罩。4.3 并发场景与多人同时入场的处理策略多人同时入场的场景我在前面已经提到YOLO能同时检出多张人脸。但多人带来的挑战不止于检测还在于识别阶段的排队问题。假设一帧画面检出10张人脸每张人脸特征提取耗时20ms单线程跑一遍识别需要200ms。如果再加上摄像头采集和排队时间帧率就会掉下来。解法有三个思路批量推理Batch InferenceMobileFaceNet的输入支持多batch把10张人脸图拼成一个batch输入计算时间不会随batch线性增长通常batch10时单次前向时间反而比10次单独前向快了4-5倍。固定帧率策略只对关键帧做识别。例如每隔0.5秒从画面中选一帧只处理这一帧里检出的新人脸其他帧全部用于跟踪去重。这样同一人即使在画面里停留很久系统也只会在第一次出现时做一次识别。分时复用GPU如果同时有GPU和CPU资源可以把YOLO放在GPU上MobileFaceNet放在CPU上。这种流式架构可以在一定程度上延长设备的使用寿命也降低硬件成本。5. 模型部署与性能优化实战5.1 模型转换与推理引擎选型ONNX/TensorRT量化的取舍训练完的PyTorch模型不能直接用于生产环境因为PyTorch的推理路径太重依赖库多、启动慢、不适合长时间稳定运行。我通常的部署路径是PyTorch模型导出为ONNX。YOLOv8在ultralytics里一条命令就能导出ONNX权重MobileFaceNet需要写个导出脚本把模型forward里的动态维度固定住导出固定batch1的ONNX。用ONNX Runtime推理。ONNX Runtime在CPU上的优化比原生PyTorch好不少尤其适合MobileFaceNet这种小模型。实测中MobileFaceNet在ONNX Runtime CPU模式下单次特征提取从30ms以上降到15ms左右。追求极致性能再用TensorRT。如果是在NVIDIA显卡上部署TensorRT可以利用半精度FP16推理把YOLOv8n的推理时间从FP32的5-8ms压到3ms以内。但TensorRT的构建过程比较麻烦而且每个显卡型号/驱动版本的兼容性都可能出问题不适合作为毕设的默认选择。这个顺序能保证你做毕设时项目周期可控。ONNX Runtime的方案既跨平台又透明答辩现场只要机器不太差演示都能跑流畅。如果演示机是纯CPU且性能一般记得在答辩前把模型输入分辨率降到YOLO的imgsz640、MobileFaceNet的input_size112这两个尺寸已经是精度和速度的较好平衡点。5.2 端到端性能测试结果与瓶颈分析我拿一个中等配置的笔记本Intel i7-12700H不带独显做过一轮端到端测试数据供你参考环节单次耗时备注摄像头采集预处理10-15msOpenCV读取缩放到640×640YOLOv8n 检测ONNX Runtime CPU35-50ms与画面中人脸数量正相关人脸裁切对齐缩放2ms使用OpenCV仿射变换MobileFaceNet 特征提取CPU12-18ms单张112×112特征比对1000人库暴力检索1-2ms只需要算点积单帧全链路60-85ms无GPU的最坏情况这个数据意味着每帧全流水线处理大约能跑12-15fps。对于会议签到来说完全够用因为人可以放慢脚步配合系统识别。但也要认识到如果你的会议参与人数很多比如500暴力比对所有特征的时间会涨到几十毫秒这时就得引入更快的索引结构了。5.3 实测中的典型失败案例与兜底方案分享三个我在实际测试中遇到过的典型失败案例。案例一侧脸漏检。YOLO在人脸检测数据集上训练时正脸样本远多于侧脸。当一个人侧身从摄像头前面走过时检测框置信度会掉到阈值以下。解决办法是适当调低置信度阈值同时增加YOLO训练数据里侧脸图片的比例。我试过把conf_thres从0.6调到0.45侧脸召回率提升明显同时误检并没有显著增加。案例二逆光导致整个脸部过曝。会议室的窗户如果正对摄像头逆光环境下整个脸都是黑的YOLO能检测到位置的置信度低MobileFaceNet提取的特征与库里的正常光照特征距离很远。我的方案是在采集层加入简单的图像增强用cv2.createCLAHE做局部直方图均衡化能显著提升逆光人脸的对比度识别率可以提升10-15个百分点。案例三多人同时入会时只记录了一半人。这个问题在4.3节提到的去重逻辑下很可能发生——同一批次进入的多人如果只有前脸被YOLO锁定后面的人被遮挡自然不会被记录。兜底方案就是在签到区域设置双摄像头位一个正面一个侧面或者在会议结束后提供手动补签入口。毕设答辩时如果演示过程中出现漏签直接展示补签功能反而能体现你考虑得周全。6. 从毕设到可用产品的一步之遥6.1 还需要补充的功能活体检测与防作弊如果这个系统未来真的要在真实会务中投入使用有一个功能是绝对不能省的——活体检测。否则别人拿一张打印的照片甚至手机里的一张电子照片就能轻松冒充签到。活体检测的技术栈可以分几档简单档利用OpenCV直接要求用户做头部动作比如眨眼左右转头配合运动检测来完成。这是最容易被实现的方式但对用户不太友好。进阶档静默活体检测通过分析人脸图像中的纹理细节、反光特征、景深信息来区分真人和屏幕/纸张。MobileFaceNet结构稍作调整把最后的分类层换成一个二分类head真脸/假脸就可以在一个人脸检测框的基础上同时跑活体判断。这个方向也是很多开源项目比如InsightFace中的Anti-Spoofing模型已经验证过的路线。高阶档用红外或深度摄像头如RealSense、iPhone的FaceID传感器做3D结构光活体检测。但这对硬件有要求毕设做起来成本偏高一般不做重点。对毕设来说可以做配合式动作活体检测作为功能亮点但在架构设计上把活体检测做成一个独立模块方便之后替换成静默活体模型。这种模块化的设计在答辩时也会加分。6.2 如何包装演示与答辩材料最后聊一个非常实际的问题项目做完了怎么让它在答辩时拿高分。我的建议是答辩演示准备两个版本离线演示版准备好一段录制好的会议室签到视频最好是一个人前后走进画面、有说有笑那种用脚本回放视频流到系统中保证每次演示效果一致。线上实时演示容易翻车——摄像头位置不对、光线不好都会导致识别失败。功能演示版准备一个Web界面可以实时查看摄像头画面、YOLO检测框带confidence、MobileFaceNet的特征比对相似度条、签到结果的实时日志。这些可视化元素放在大屏幕上一个界面同时展示了检测-识别-记录三层逻辑比任何PPT都直观。另外答辩PPT里的技术架构图建议突出以下三个点YOLO负责密集人脸检测的并行优势与MobileFaceNet的轻量识别分工。特征向量存储带来的隐私与存储优势。系统模块解耦架构采集/推理/数据分离为之后扩展活体检测、多人同时签到等功能预留了接口。我在实际答辩中明显的感觉是评审老师对一个项目的技术评价往往不在于模型有多高级而在于你能不能把每个技术选型的理由说清楚以及面对真实场景中的失败案例时你是否有系统性的兜底方案。这套YOLO MobileFaceNet的组合虽然看起来不花哨但如果你能把场景中的每个坑逆光、侧脸、多人遮挡、活体攻击用文档和实测数据串起来它呈现出的工程思维比单纯堆一个高精度模型更有说服力。