从YOLO检测到ArcFace识别：人脸识别门禁系统实战解析

大概在两年前，我接到一个需求：把实验室门口的普通门禁改造成人脸识别门禁，还要做一套完整的算法研究和实现方法文档。那时候“YOLO26深度学习框架”这个说法听起来确实唬人，但拆开来看，本质上就是三件事：把人脸从画面里找出来，把找到的人脸变成可识别的特征向量，最后跟门禁系统联动起来。这篇文章就围绕这套人脸识别门禁系统，把算法选型、模型训练、系统落地和踩坑过程完整说一遍，适合正在折腾毕业设计、或者公司内部想快速搭人脸门禁原型的开发者参考。

先说结论：这套系统的核心不是“用哪个YOLO版本”，而是检测、识别、策略三条线怎么配合。我在模拟项目X里完整跑通过这套流程，从数据标注、训练调参、模型量化到嵌入式部署都过了一遍，累计踩过的坑比写出来的代码还多。下面直接进入正题。

1. 项目链路拆解：从“人形框框”到“开门权限”的完整思路

1.1 为什么人脸检测和人脸识别必须拆成两件事

很多刚接触这个项目的人会问：YOLO不是能分类吗？能不能直接让YOLO输出“张三”“李四”的标签？先说结论：可以，但生产环境没人这么干。

YOLO本质是目标检测模型，它学习的是“人脸在哪里”以及“这是不是人脸”这两个能力，输出的是边框坐标和类别置信度。而人脸识别要解决的是“这张脸是谁的”，它属于度量学习，核心是把人脸图像映射到一个特征向量空间，同一个人的特征向量距离近，不同人距离远。两者的损失函数、网络结构设计思路差距很大，硬揉在一起会有两个致命问题：一是类别数等于注册人数，每加一个人就要重新训练一次模型，根本不现实；二是检测模型学的是“人脸”这个大类，没有对身份做判别性约束，类内距离控制不住，冒充识别和误通过率会高得离谱。

所以标准做法是两段式pipeline：先用YOLO做人脸检测，把画面里的人脸框出来；再用专门的特征提取模型对框出来的人脸做识别。这套方案的好处很明显：注册新用户不用动检测模型，只需要往特征库里加一条记录；检测模型也不用关心这个人是张三还是李四，专心把框出得准、出得快就行。

1.2 门禁场景对算法的四个硬约束

门禁不像安防监控，它有一套非常具体的业务指标，这些指标直接决定了算法设计和模型选型的方向。我在模拟项目X里做技术方案时，把约束条件归纳成四条：

第一是实时性。门禁是高频交互场景，从摄像头抓到人脸到给出开门信号，端到端延迟通常要求在500毫秒以内。其中检测环节在嵌入式设备上最好控制在30毫秒左右，特征提取控制在50毫秒以内，剩下的时间留给业务逻辑和继电器动作。如果单次识别要一两秒，用户站在门口就有明显的“卡顿感”，体验非常糟糕。

第二是硬件资源限制。大多数门禁设备用的是嵌入式AI模组或者低功耗工控机，不是实验室里的多卡服务器。模型大小、算力消耗都得精打细算。一个YOLO模型加上一个特征提取模型，显存占用加在一起要控制在1GB以内，这在设计之初就必须定死。

第三是错误代价不对称。门禁场景里，误拒绝只是让用户多刷几次脸，顶多烦一点；但误识别放进来一个陌生人，就是安全事故。所以算法调优的方向是宁可得不到最优的准确率，也要优先压低误识率FAR（错误接受率），阈值设定要偏保守。

第四是环境复杂性。门禁装在室外或者半室外场景，逆光、夜间红外补光、戴帽子戴口罩、小孩子身高太低导致俯仰角度大，这些情况都会让算法的表现断崖式下跌。训练数据里必须显式覆盖这些情况，而不是等部署之后才暴露问题。

1.3 整体数据流和技术栈

这套系统的完整数据流是：摄像头抓帧，做亮度判断和模糊判断，跳帧采样后送入YOLO检测模型，检测到人脸后做质量过滤和人脸对齐，然后送入特征提取模型输出特征向量，最后在白名单特征库里做1:N比对，结合活体检测结果和权限策略输出控制信号，同时把通行记录写入数据库。

为什么要跳帧采样？门禁场景的人移动速度不算快，每秒15到25帧的视频流里真正有效的帧占比不高，连续多帧都做推理纯属浪费算力。我实际的做法是每5到10帧取一帧做检测，既保证不漏人，又让整机有充足的算力去跑活体检测和业务服务。

技术栈方面，检测模型用YOLO26（项目内部代号）做骨架，特征提取用轻量级分类网络加ArcFace损失函数训练，推理端用ONNX Runtime或TensorRT做加速，后端服务用Python的FastAPI写业务逻辑，数据库用MySQL存通行记录和特征库，硬件端是带Tensor Core的嵌入式AI模组加双目摄像头。整体架构不复杂，但每个环节都有说头。

2. 检测环节：YOLO26模型训练与数据处理的实操要点

2.1 YOLO26的选型逻辑和模型定位

先解释一下“YOLO26”这个命名。它是我在模拟项目X里的内部代号，代码层面基于当前开源的YOLO系列版本调整检测头结构而来。如果读者想复现这套方法，不需要纠结版本号，直接用能拿到的官方最新稳定版YOLO做骨架，按下面的思路改造即可。

之所以选YOLO系列而不是Faster R-CNN或者SSD，核心原因有三点：一是YOLO的anchor-free设计让检测头更简单，对小目标比较友好，门禁场景里常见的2米外半身人像正好属于中小目标；二是它内置了Mosaic等数据增强策略，训练自己的数据集时省了很多事；三是部署生态成熟，导出ONNX或者做TensorRT量化都有现成工具链，对嵌入式平台支持得比较好。

在模型定位上，我只让YOLO24干一件事：输出人脸框、置信度和五个关键点。注意，这里我特意让检测头额外回归了一个5点关键点分支。为什么？因为后面做识别需要对人脸做对齐，如果全靠单独的关键点模型，会增加一次推理开销。让检测模型多输出5个点，基本不增加计算量，却能把整个pipeline简化很多。关键点坐标和人脸框一起输出，后续做仿射变换直接取用，省掉一次额外的模型调用。

2.2 数据准备和标注规范：训练集这样造才有效

检测模型的训练数据不是随便找一堆人脸照片就能用的。我在模拟项目X里采用了“公开数据集清洗加自采场景数据”的组合策略，比例大概在7比3左右。清洗公开数据集时要注意一件事：里面很多标注框其实质量不高，有的框只框住半边脸，有的把背景大面积包了进来，这些脏数据必须筛掉，否则训练出来的模型边界会非常含糊。

自采数据更重要，因为它决定了模型在真实场景下的表现。我们当时在门禁安装位置用摄像头录了一周的视频，按每秒抽帧的方式得到原始图像，然后做标注，重点覆盖了这么几类：逆光条件下的人脸、夜间红外补光的人脸、侧面30度以上的人脸、戴帽子和戴口罩的人脸、小孩和轮椅用户这种低机位人脸。标注格式转成YOLO的txt格式：类别编号、归一化后的中心点x坐标、中心点y坐标、框宽、框高。标注规范上有一条特别值得强调：人脸框要贴脸，上沿从额头开始，下沿到下巴，不要把手、脖子和大幅背景包进来。框太大，模型学到的是“人”而不是“人脸”；框太小，关键点和后续识别都会受影响。

标注工具用常见的开源标注软件就行，支持YOLO格式导出。标注完还要做数据增强，YOLO训练配置里把Mosaic增强打开，随机拼接四张图，能显著提升模型在小目标上的检出能力。另外建议把一部分样本做灰度化处理，模拟夜间红外图像的通道特征，否则到了晚上红外模式开启，模型效果会肉眼可见地下降。

2.3 训练超参配置和损失函数解读

下面给出一份我在模拟项目X里实测可用的训练配置，如果你用的也是YOLO系列，可以直接作为起点：

训练过程中核心关注的指标不是mAP50，而是mAP50-95。mAP50只要求在IoU为0.5时框得准，门禁场景里人脸框偏差一点，后面对齐和识别就会受影响。mAP50-95对框的精度要求严格得多，能更真实地反映模型定位能力。实测下来，模型在训练集上大约190轮后mAP50稳定在98%以上，mAP50-95达到81%左右。

损失函数方面，YOLO系列用的是分类损失、边框回归损失加DFL（Distribution Focal Loss）的组合。DFL这个东西值得单独说一下，它不直接回归边框坐标的单一值，而是预测坐标的概率分布，对遮挡、模糊边界的处理更鲁棒。门禁场景里的人脸经常在逆光边缘或者快速移动中产生模糊边界，DFL这一项帮了很大的忙，能减少框的抖动。

训练回调里尽量保存best.pt而不是last.pt，因为门禁任务中过拟合风险不高，但最后一轮往往因为学习率降得太低而出现轻微过拟合到训练集的迹象，用验证集上指标最好的权重更稳妥。

2.4 模型压缩和边缘部署：量化不只是把fp32改成int8

训练好的模型不能直接扔到嵌入式设备上跑，得先导出为ONNX，再对计算图做优化和量化。我在模拟项目X里对比了几种精度的部署表现：

INT8量化的精度损失看似只有0.8个点，实际跑一遍真实夜景数据就会发现，误检数量可能从个位数变成十几条。所以我实际部署用的是“FP16为主、INT8作为备选”的方案，这不是说INT8不行，而是门禁场景对漏检的容忍度很低，精度的每一分损失都可能变成一个没被框出来的侧脸。

另外特别提醒一点：不要对检测模型做激进的通道剪枝。YOLO的检测头对小目标的响应本来就依赖足够多的特征通道，剪枝后模型的FPS确实上去了，但对1米开外小脸的检出率会明显下降。如果一定要压缩，优先剪backbone的冗余层，保检测头不动。门禁场景里帧率稳定比峰值FPS更重要，推理耗时忽高忽低会直接导致抓帧策略出错，比如该处理的帧被丢弃，人已经走到闸机前了检测结果才出来。

3. 识别环节：从人脸框到“确定这是谁”的完整实现

3.1 人脸质量过滤和对齐：垃圾进、垃圾出

检测模型输出的人脸框不能直接送去识别，中间必须经过质量过滤和对齐。我见过不少半吊子项目跳过了这一步，结果特征提取模型吃进去一堆模糊脸、侧脸、过曝脸，输出特征自然乱七八糟，识别准确率永远提不上去。

质量过滤分四步：第一，置信度过滤，检测框置信度低于0.45的直接丢弃；第二，尺寸过滤，人脸框的短边小于60像素的丢弃，小到这种程度的人脸在门禁距离下通常意味着人已经在两米开外，识别没有意义；第三，宽高比过滤，正常人脸宽高比在0.5到2.0之间，超出这个范围的框大概率是误检；第四，清晰度判断，用拉普拉斯算子计算图像方差，方差过低的模糊脸丢弃。这四个门禁滤器的参数都设有保守余量，不能太激进，否则会出现真人站在门口却因为侧脸角度偏大被拒识的情况。

接下来是对齐。通过检测模型输出的五个关键点（左眼、右眼、鼻尖、左嘴角、右嘴角），计算与标准人脸关键点位置的仿射变换矩阵，把人脸图校正为标准正脸。这一步直接决定了特征提取模型的输入质量，同一张侧脸照片，对齐前后提取的特征相似度可能有0.1以上的差距。对齐后的人脸图再缩放到112x112像素，送入特征提取模型。

3.2 特征提取模型训练：ArcFace和MobileFaceNet的组合

特征提取模型选择的是轻量级骨干网络加ArcFace损失函数的方案。骨干网用MobileFaceNet，它的参数量小、推理速度快，提取的特征维度我设置为512维，足够区分几千人的特征库。ArcFace损失函数的意义在于，它能在训练时给不同身份的人脸加上一个角度margin，强行拉开类别间的特征距离，让最终学习到的特征分布更紧凑。这个margin值不是越大越好，实测在0.5附近表现最好，太大反而让困难样本难以收敛。

训练数据同样用公开人脸数据集清洗版加自采数据。这里有个大多数人都会忽略的点：训练特征提取模型时，输入分辨率一定要和部署时一致，我们用的是112x112。如果训练用224x224、部署却跑112x112，模型输出的特征会退化得很厉害，类间距离明显缩小，误识率直接翻倍。

训练完成后还要做特征归一化。全连接层输出的512维特征向量统一做L2归一化，让它的模长为1，之后用余弦相似度做比对。归一化这步看起来简单，但它能消除不同图像亮度、对比度差异带来的特征尺度漂移，是特征库真正可用的前提。

3.3 特征库建库和1:N比对：阈值这样标定才靠谱

注册用户的流程是这样的：正脸采集一张，左右各30度各采集一张，一共三张图像，分别经过检测、对齐、提特征后得到三个512维向量。这三个向量可以选择直接存三条记录，也可以先归一化再平均成一条最代表性的特征向量。我更推荐前者，因为存多条记录可以在比对时把最高相似度作为最终值，能容忍用户日常姿态的波动。

1:N比对的实现是：把当前识别出的特征向量与特征库里所有向量逐一计算余弦相似度，取最高值，然后判断这个最高值是否超过阈值。如果超过阈值且对应的库内人员有当前时段权限，就开门，否则拒绝。

阈值怎么定？这是整个项目里最容易被低估的环节。很多团队直接照搬网上的0.4、0.45，这是不对的。正确做法是：让系统在门口连续运行几天，收集真实的通行数据，把“已注册人员刷脸”和“未注册人员刷脸”的相似度分布分别画出来，用约登指数寻找两个分布交集最小的点。我在模拟项目X里实测的合理阈值范围在0.36到0.44之间，但这个值在换了摄像头、换了补光灯之后必须重新标定。摄像头的感光芯片、镜头畸变、补光波长都会影响特征分布的形态，抄别人的阈值百分之百要出事。

3.4 活体检测：防止照片和手机屏幕糊弄系统

人脸识别门禁如果不做活体检测，一张打印照片就能破解，这在物理安全场景里不可接受。我在模拟项目X里采用的是硬件优先、软件辅助的方案。

硬件方案是配合双目摄像头做深度估计，用近红外和可见光的双通道信息来判断面前的人脸是否有真实深度，照片和屏幕是平面的，深度值天然无法通过。软件方案是做指令式活体，随机要求用户眨眼、点头或者张嘴。考虑到嵌入式设备的算力资源宝贵，主路径以硬件深度为主，软件活体只在深度信息不可信时自动触发。加活体检测后，系统整体延迟增加了约80毫秒，但换来的是安全性的大幅提升，这个代价很值。

4. 门禁系统完整落地：架构、代码和评估方法

4.1 系统架构与硬件选型

整体架构我分为采集层、推理层、业务层、执行层四部分。采集层使用网络摄像头通过RTSP协议取流，或者用USB摄像头直连嵌入式模组；推理层是检测模型加特征提取模型，跑在嵌入式AI模组上；业务层是一个Python服务，负责调度推理结果、执行权限策略、写数据库；执行层是继电器控制模块，接到闸机或者电锁的开关信号上。

数据库设计方面，特征库表至少包含：人员ID、姓名（用脱敏编号替代）、分组ID、特征向量（以BLOB存储）、注册时间、最后通过时间。通行记录表包含：通行时间、人员ID、识别相似度、活体结果、抓拍图片路径。日志表单独建，主要记录异常情况，比如连续多次匹配失败、黑名单人员出现等。

硬件选型有一条核心经验：先定硬件，再定模型复杂度。如果你选的是低功耗CPU工控机，那检测模型就得压缩到非常轻量的版本，识别模型可能只能用8位量化；如果选的是嵌入式AI模组，模型选择余地就大很多，但显存依然要精打细算。我在模拟项目X里的做法是先选一块带Tensor Core的AI模组，然后在一开始就把模型的总显存占用锁死在900MB以内，所有后续调整都在这个资源边界内进行。

4.2 核心代码流程：从取流到控制信号的完整实现

核心业务逻辑用Python写，推理框架用ONNX Runtime。下面是这个流程的简化代码：

import cv2 import numpy as np import onnxruntime as ort # 加载检测模型和识别模型 det_session = ort.InferenceSession("yolo_face.onnx") rec_session = ort.InferenceSession("face_embedding.onnx") # 标准人脸关键点，用于仿射变换对齐 REF_POINTS = np.array([[38.2946, 51.6963], [73.5318, 51.5014], [56.0252, 71.7366], [41.5493, 92.3655], [70.7299, 92.2041]], dtype=np.float32) def face_detect(frame): # 图像预处理：resize到640x640，归一化，转CHW img = cv2.dnn.blobFromImage(frame, 1/255.0, (640, 640), (0, 0, 0), swapRB=True) outputs = det_session.run(None, {"images": img})[0] # 解析YOLO输出，得到框、置信度、关键点坐标 # 过滤置信度 < 0.45 的框，并按NMS合并重叠框 boxes, keypoints = postprocess(outputs, conf_thres=0.45) return boxes, keypoints def face_align(face_img, keypoints): # 根据5个关键点计算仿射变换矩阵 M = cv2.estimateAffinePartial2D(keypoints, REF_POINTS)[0] aligned = cv2.warpAffine(face_img, M, (112, 112)) return aligned def face_embedding(face_aligned): # 归一化后输入识别模型，输出512维特征 blob = cv2.dnn.blobFromImage(face_aligned, 1/127.5, (112, 112), (127.5, 127.5, 127.5), swapRB=True) feat = rec_session.run(None, {"input": blob})[0].flatten() feat = feat / np.linalg.norm(feat) return feat def compare_with_db(feat, threshold=0.40): # 遍历特征库，计算余弦相似度，返回最相似的人员ID max_sim = 0.0 match_id = None for person_id, db_feat in DB_FEATURES.items(): sim = float(np.dot(feat, db_feat)) if sim > max_sim: max_sim = sim match_id = person_id if max_sim >= threshold: return match_id, max_sim return None, max_sim

这段代码的要点有两个：一是检测模型的输入必须做与训练时完全一致的预处理，差一个像素的resize方式都会导致mAP明显下降；二是特征向量的归一化不能省，余弦相似度计算要建立在归一化后的向量上。

4.3 通行逻辑与权限管理：识别通过不等于开门

很多人以为人脸识别模型给出“通过”就可以直接开锁，真实项目里不是这样。业务层还必须叠加三道校验逻辑。

第一道是活体检测结果校验，活体不过直接拒绝。第二道是权限校验，人员分组、时段、门禁点位都要匹配。比如某员工有8点到21点的门禁权限，凌晨两点刷脸，模型识别对了也不能开门。第三道是防尾随和防重复校验：系统检测到当前画面里有多张人脸时不执行开门动作，防止一人刷脸多人进入；同一人员两次识别通过的时间间隔小于1.5秒时，只执行第一次的开门，防止门口有人故意反复触发继电器。这些策略看起来简单，但解决了门禁系统“识别准但不好用”的很大一部分问题。

黑名单和陌生人策略也要单独设计：黑名单人员识别通过后，系统不产生任何提示，只静默记录并推送告警给管理员；陌生人在5分钟内出现超过3次，触发重点关注告警。这样做的好处是避免引起现场人员警觉，把安全事件留给管理员处理。

4.4 系统评估方法：分场景测，别把混合数据当救命稻草

系统上线前必须做评估，但我发现很多团队的评估方式有问题：把不同场景的照片混在一起，算一个整体准确率，得出“98%”这种好看的数字。问题在于，混合评估会把场景短板掩盖掉。比如正常光照下准确率99.8%，夜间红外下只有85%，混合一下变96%，看起来还行，实际夜间场景就是不可用。

我在模拟项目X里的做法是把测试集按场景拆开单独评估。实测数据如下：

戴口罩场景识别率掉到73.5%，说明特征模型的上半脸特征利用还不够充分。这个结果暴露出两个问题：一是模型训练时的遮挡样本还不够多，二是特征维度512在遮挡场景下表达力偏弱。后续可以在训练数据里增加口罩样本的占比，或者把特征维度提升到1024，但1024维会带来更大的内存占用和比对耗时，需要重新权衡。

5. 调优实践与踩坑实录：这些问题我全都遇到过

5.1 检测环节的常见问题排查

先说小脸漏检。门禁场景里最常见的投诉是“人走到摄像头正面了还识别不了”，排查下来往往是因为人脸框短边小于60像素被质量过滤规则丢弃了。这种情况不一定是模型问题，而是过滤参数太激进。我踩过这个坑之后，把尺寸阈值从80像素降到了60像素，同时把距离判断条件改成了“人脸短边与画面宽度比大于1/12即可识别”，效果立竿见影。

再一个是夜晚红外图像效果差。YOLO在RGB图像上训练惯了，一旦切到近红外灰度图，特征分布变化很大。我的解决办法是在训练集里人为把30%左右的样本转成灰度图，让模型学习到灰度域特征，部署后夜间模式的表现从70%左右直接拉到90%以上。

密集排队场景重框问题也值得提一句。几个人并排站在门口，检测模型输出重叠的候选框，NMS默认阈值0.45会把相邻人脸的框合并掉，导致漏检。把NMS的IoU阈值调到0.6之后，重叠框被保留的比例更合理，并排场景的准确率提升了约5个百分点。

5.2 识别环节的常见问题排查

最头疼的问题是注册人脸照片和现场通行人脸差距过大。用户在注册时精心整理了头发、摘了眼镜，现场却是戴着帽子加黑眼圈，特征相似度往往只有0.3。解决办法是强制多重注册：注册时采集正面、低头、仰头、左右侧脸各一张，全部存入特征库。比对时取最高相似度，才能把现场通过率稳住。

相似脸误通过问题，比如双胞胎，任何深度学习模型都很难只靠算法解决。我的处理方式是两段式：系统先用0.35的阈值粗筛出候选人员，如果最高相似度和第二高相似度都在阈值之上且差距小于0.05，就判定为“疑似多人”，要求现场人员二次核验或者点击确认。这比单纯调低阈值更灵活，也减少了真人被误拒的频率。

还有个容易被忽略的问题：摄像头换了但特征库没重建。不同摄像头的色彩矩阵、白平衡风格完全不同，同一张脸在不同摄像头下提取的特征可能差0.08以上。遇到“换了摄像头之后一片拒绝”的情况，先检查特征库是否需要重建，别盯着模型死调。

5.3 系统性能优化和稳定性保障

性能优化方面，第一个手段是推理异步化。视频流采集线程、检测推理线程、业务逻辑线程完全分离，用队列传递数据。这样即使某帧检测耗时突然增加，也不会阻塞业务流程。第二个手段是跳帧策略，检测模块每N帧执行一次，识别模块只在检测到新的人脸且与上一帧的框位移超过一定距离时才触发，减少无效推理。这两个手段配合后，整机CPU占用下降了40%左右，端到端延迟也更稳定。

稳定性保障上，程序自启动和看门狗是必须的。门禁设备经常在无人维护的环境下运行，进程意外退出没人发现会导致门口彻底瘫痪。我使用了简单的systemd守护进程加心跳监测，每30秒检查一次主进程状态，异常时自动拉起。数据库连接做成连接池，避免长时间运行后连接泄漏。

5.4 全项目避坑清单

• 数据标注框不贴脸，或者把脖子包进去，训练出来的模型框位飘忽不定，后续对齐全部白做。
• 训练时全程不冻结backbone，前期损失震荡得像心电图，白白浪费几十轮迭代。
• 公开数据集和自采数据不做比例控制，公开样本过多会让模型在特定场景下过拟合，特征泛化能力下降。
• 1:N特征库不做索引或分段管理，注册5000人之后，比对耗时从10毫秒飙升到80毫秒，现场明显变慢。
• 阈值直接抄网上经验值，不重新标定，真实场景的误识率可能比想象中高一倍。
• 用FP32模型直接上线，结果嵌入式模组跑不满30帧，被迫临时减帧率，用户体验直接拉垮。
• 活体检测在原型阶段不做，等到现场演示被一张A4纸照片打破安全记录才意识到问题，这个坑踩一次就够丢人了。

这套系统做完之后，我最大的体会是：算法能力决定系统的上限，而工程细节决定用户能不能感知到这个上限。人脸检测模型再准，业务策略不合理，照样会出现尾随混入；特征模型再优秀，日志和告警没做好，安全问题也追溯不到。先定硬件，再定模型资源预算，最后再谈精度优化，这个顺序不要反过来，否则返工成本极高。最后给做同类项目的朋友一个建议：上线前一定要留出一周左右的试运行窗口，专门用来收集真实场景数据、重新标定阈值、调整过滤参数，这段时间花的成本，远小于事后到现场反复救火的成本。