早高峰的闸机口永远是门禁系统最残酷的考场。我们之前在某园区的刷脸门禁试点高峰期一群人堵在闸机前有人歪着头怎么都刷不过有人戴着口罩被保安拦住还有人在逆光下被识别成了另一个人。问题不在闸机硬件而是算法——通用的人脸识别SDK根本没法适配这个具体场景的相机角度、光照和人流节奏。后来我们干脆基于YOLO框架自己做了一套完整的人脸识别门禁算法方案内部代号就叫YOLO26覆盖检测、关键点对齐、特征提取、比对、部署到现场调优的全链路。这篇就把整个研究实现过程写清楚网络结构怎么改、数据怎么标、训练怎么调以及端侧落地时那些不试不知道的坑。先说清楚这个YOLO26不是某个公开的官方版本而是我们团队在YOLO系列结构基础上加了人脸关键点分支和识别特征头之后得到的一套内部迭代模型。所以文中所有设计思路你完全可以平移到YOLOv8、YOLO11等现成框架上使用本质上是一套“检测识别”双任务人脸门禁方案的工程化方法论。1. 为什么门禁系统需要重新设计算法栈需求边界与选型逻辑1.1 门禁场景的三个特殊约束很多团队一开始下意识想用现成人脸识别SDK一调用就返回“是否通过”省事。但真正部署到门禁机上会发现这类通用SDK的参数黑盒你根本调不动底层逻辑。门禁场景核心就三个字快、准、稳。快指的是从人站到闸机前到闸机开门延迟不能超过300毫秒否则早晚高峰就会出现“人比闸机快”的拥堵准指的是不能误识也不能把人拒之门外行业里一般用FRR误拒率和FAR误识率来衡量稳指的是无论晴天逆光、晚上暗光、雨天反光识别结果不能有大波动。还有一个容易被忽略的约束是隐私和成本。很多园区要求人脸底库和识别全部在本地边缘设备完成不允许把人脸特征传到云端这意味着模型要能跑在几瓦功耗的小盒子上。另外摄像头往往不是高端设备噪点、畸变、低照度全占了。这些约束叠加在一起就不是调一个SDK参数能解决的得从算法层开始定制。1.2 为什么选择“检测识别”一体化的YOLO框架人脸识别门禁的传统方案非常经典先用MTCNN做检测和对齐再把人脸区域送给FaceNet或ArcFace模型提取特征最后做比对。这套链路在服务器上完全没毛病但放到边缘盒子上就难受了——两个模型串行跑MTCNN输出的人脸框还要在原图上抠图、缩放、再进第二个模型端到端耗时被拉得很长而且两个模型的误差会叠加。今天甲模型检测框稍微偏了一点明天乙模型可能就提取了一个不那么标准的特征这种脆弱的管线在光线复杂的现场会被放大。YOLO这类anchor-free检测框架则天然适合做单阶段多任务。它的decoupled head可以分出检测分支、边界框回归分支和分类分支我在设计YOLO26时在这个基础上加了两样东西一组人脸关键点回归分支以及一个全局特征嵌入分支。这样一来一个模型同时输出人脸框、五个关键点坐标、以及512维的人脸特征向量。检测和识别共用同一个backbone前向计算只跑一遍边缘端延时可压缩到原来的60%左右。更关键的是检测出的高置信度人脸区域自带特征向量不需要再做二次抠图推理整个刷脸流程的流水线结构大大简化。1.3 完整算法链路从原始帧到闸机信号门禁系统不是只做一个识别模型就完事完整的算法链应当包括五个环节人脸检测、质量评估、关键点对齐、特征提取与比对、活体判断。摄像头每一帧进来首先检测有没有人脸紧接着评估这张脸是否适合识别比如是不是太小、太模糊、角度太大然后通过关键点做人脸对齐消除姿态差异再提取特征向量和底库做余弦相似度比对最后还要排除照片、视频攻击。这五个环节在最终系统里全部串成一条管线任何一个环节出问题结果都会体现为闸机的“拒”或“误开”。2. 从检测到特征嵌入YOLO26框架下的识别算法拆解2.1 Backbone与检测头的设计取舍人脸检测和通用物体检测有一个显著区别人脸在门禁画面中通常占比不大人站在闸机前大概占到画面高度的三分之一到二分之一但人脸可能只占几十个像素。所以我在设计时特别强调保留高分辨率特征图也就是在P3层上做密集预测。如果直接套用标准的640×640输入、输出三层特征图的检测头小脸会大量漏检尤其是1.5米外的排队人脸。为了平衡速度和精度YOLO26整体结构采用了CSP风格的跨阶段特征融合模块并在P3、P4、P5三个尺度上做预测输入分辨率固定为640×640。关键点分支的设计也有讲究。人脸对齐通常需要5个点——双眼中心、鼻尖、左右嘴角如果是口罩场景下巴的嘴角点不可见就要考虑关键点遮挡掩膜。我在关键点回归头上对每个关键点做独立回归损失函数用带遮挡掩膜的smooth L1。简单说如果一个关键点因为遮挡不可见它的真实标签就会带一个“无效”标记计算损失时直接跳过避免模型被不可靠标签带偏。2.2 识别分支怎么接共享Backbone的双任务设计很多人会问检测和识别共用backbone会不会互相干扰我的答案是会所以要分阶段训练而不是直接一上来就联合训练。YOLO26的识别分支是一个全局平均池化加全连接层输出512维归一化特征然后接ArcFace分类头。ArcFace的核心思想是在特征和权重向量之间夹角上加上一个固定margin让模型对同类样本更紧凑、对异类样本更疏远。对门禁场景来说底库里的人脸类别数通常几万到几十万不能用普通的softmax否则类别一多特征区分度就不够。整体损失函数是四个损失的加权和检测分类用Focal Loss边界框回归用CIoU Loss关键点回归用带掩膜的Smooth L1识别分支用ArcFace Loss。四个损失之间的权重我踩过不少坑detection和keypoint的损失量级大如果不做平衡识别分支基本学不到东西。我最终把权重设为检测分类1.0、框回归1.0、关键点0.5、ArcFace 1.0在大约5万张人脸训练集上跑出来的效果比较稳定。2.3 比对策略余弦相似度的门限为什么不能固定模型输出512维L2归一化特征后比对阶段实际上就是计算两个向量之间的余弦相似度也就是特征空间里的夹角余弦。理论上夹角越小越像但实际却远没这么简单。不同时段的光照会让同一个人脸的特征发生偏移早起逆光和中午顺光的余弦相似度差异能达到0.1以上。如果全系统用一个固定阈值比如统一设0.55那上午9点逆光时段就会出现大量误拒傍晚夕照时段误识风险又会上升。我的做法是建立阈值自适应机制按时间段、按摄像头位划分不同阈值比如上午逆光时段阈值放宽到0.48夜间红外模式阈值收紧到0.58。更稳妥的做法是设双阈值——相似度大于高阈值直接放行落在中阈值区间则进入人工复核或二次识别流程低于低阈值直接拒绝。这个机制在后面的系统集成里还会详细展开但算法研究阶段就必须预留这个接口否则模型再好也救不了现场误拒。3. 数据才是门禁系统的命门数据集构建与标注细节3.1 门禁数据要解决的真实分布公开人脸数据集再多也解决不了一个核心问题你和现场设备的安装姿态不匹配。公开数据集大多是网络自拍或者近距离人脸而门禁摄像头是从上往下略带俯仰角的人脸的形状、关键点位置比例跟网图差距明显。我做的第一件事就是在闸机位置架了一台同型号相机采集了大约200多人的多时段视频流再把视频拆帧得到自采数据集按8:2划分训练和验证。同时从公开数据集中补充不同肤色、不同年龄段样本但来源比例严格控制不让自己采的数据被公开数据淹没否则现场效果会被“平均脸”拉低。自采数据要覆盖的关键条件包括逆光、暗光、侧光、阳光直射、戴口罩、戴帽子、低头看手机、快速通过、多人同框、远距离、近距离。每个条件至少拍一段持续一分钟的视频。这些真实分布样本比任何算法调参都管用。因为门禁模型的分数再高如果在真实逆光分布上FRR是5%那闸机前就一定有人刷不过去不用怀疑。3.2 标注规范框、点、ID、质量四类标签人脸框标注看似简单实际上门禁场景需要定义严格规范。我们的规范是只要人脸可见区域大于画面高度的5%就必须标出完整外接矩形即使被口罩遮挡也一样。关键点标注使用5点制——双眼中心、鼻尖、左右嘴角鼻尖被口罩遮挡时标为不可见嘴角同理。每个样本同时打一个质量标签分成“高可用”“低可用”“不可用”三档。模糊、过小、严重大侧脸都被标为低可用或不可用训练时这些样本不会进入识别分支的监督信号防止模型学到垃圾特征。这个质量标签在后续训练里帮了大忙。因为识别分支非常容易被“看起来是脸但完全无法确认身份”的低质量样本带偏。模型可能会为了迎合这些样本而产出一种平均化特征导致相似脸误识率上升。标注质量直接决定了识别精度的上限这一点怎么强调都不过分。3.3 数据增强怎么针对闸机场景人脸检测与识别的数据增强不能照搬通用目标检测。我总结的增强组合是随机仿射变换旋转±10度、缩放0.8~1.2、平移、亮度/对比度扰动模拟不同时段光照、灰度化模拟红外夜视模式、随机遮挡黑框遮眉眼、遮鼻嘴模拟口罩和帽子。因为没有用生成对抗网络我另加了一项关键的“多尺度训练”——同一个样本在一批训练里缩放到不同分辨率再进网络确保模型对距离远近不敏感。这里要特别提醒一点增强过度会导致特征失真。有一版实验我加了很强的HSV色彩抖动训练损失下降很快但真实闸机识别性能反而变差了——原因是模型学会了利用极端颜色信息来区别人脸而门禁相机的色彩还原远没有这么理想。后来我把色彩抖动的强度砍掉一半换成模拟传感器噪声的高斯噪声现场鲁棒性明显回升。3.4 难例挖掘不是可选项训练集做出来之后难例挖掘是必经之路而且是一个循环迭代过程。第一版模型上线后我会每天从真实闸机日志里捞两类样本误识样本FAR即相似度超过阈值但其实不是同一个人误拒样本FRR即相似度低于阈值但其实是同一个人。把这两类汇聚成难例池混合到训练集里再训一版。每次难例回灌之后模型在真实场景的FRR能下降到原来的三分之一到四分之一。难例挖掘听起来费功夫其实是门禁识别系统里收益最可持续的投入。4. 训练一台能稳定“认出人”的模型训练策略与调参记录4.1 模型结构与训练配置说一下我们最后定下来的实验配置你可以直接参考输入分辨率640×640backbone深度适中大约10M到12M参数量特征维度512。训练集规模是自采加公开合计约15万张人脸其中标注高质量可用样本约11万张。训练用一台单卡GPU好在我们这套结构不算特别大也能跑起来。优化器用SGDmomentum 0.937初始学习率0.002cosine学习率调度总epoch 120。前30个epoch用warmup避免早期梯度爆炸。batch size按显存尽量给到64。这里有个常见的认知误区batch size越小越好或者越大越好。我的经验是检测分支对batch size相对不敏感但识别分支在底库类别较多时batch size太小会导致ArcFace的margin惩罚难以收敛因为每个batch里同一个ID可能出现不了几次。所以我采用了一个折中策略前30个epoch用较大的batch size做检测预训练后90个epoch把batch拆分成mini-batch给识别分类头保证每个子批次里同一个人脸的样本对能被充分看到。4.2 三阶段训练为什么不能一步到位我强烈建议不要一开始就联合训练所有的头。三阶段训练是这套方案里最关键的工程经验之一。第一阶段只训练检测分支和关键点分支backbone和检测头学习“哪里有人脸”、“人脸的结构是什么”大约60个epoch后检测mAP能达到一个不错水平第二阶段冻结backbone单独用高质量对齐后的训练集训练ArcFace识别头让特征分支在固定特征提取器上做类别学习稳定收敛第三阶段才整体解冻用很小的学习率初始0.0002联合微调30个epoch。这样做的好处是识别分支不会在早期干扰检测分支学习几何结构同时检测分支的丰富语义又能在最后阶段辅助识别特征。如果跳过第一阶段直接联合训练你会看到一个典型的失败场面检测框位置越来越准但识别准确率卡在90%上不去因为backbone在早期被识别分类任务带偏变成了“人脸身份特征提取器”丢失了一部分通用几何细节检测框稳不住。4.3 指标监控和过拟合信号训练过程中不能只看Loss因为四个Loss的加权和很难直观反映门禁到底好不好用。我每周会把当前训练权重导出放到一个固定评估集上跑指标包括检测mAP0.5、关键点NME、识别正阳率TPRFAR1e-4以及门禁业务指标——FRRFAR1e-4。这个业务指标才是最终需要盯的。因为模型可能检测mAP很高但识别阈值下的FRR不可接受说明底库特征分布不够紧凑。过拟合的表现也很有意思验证集检测mAP很高但训练集和验证集之间的FRR差超过3个百分点就要警惕识别分支过拟合到训练集合里的特定人群了。门禁系统应用的最大风险不是欠拟合而是这种“看起来指标很好、上新现场就翻车”的过拟合。4.4 我踩过的一个最典型的调参坑有一版实验把识别分支的特征输出维度从512改成128想试试能不能提速。结果训练损失也很漂亮验证识别准确率下降不到1%我觉得可以上线。结果到了真实闸机上FAR暴增了将近一倍。原因是128维特征表达能力不足在公开测试集上掩盖了缺陷但在我们自采的那些相似面孔多的员工样本上特征空间捉襟见肘相似人脸的类间间隔压不住。最后老老实实回到512维。教训很简单识别模型的维度不能只看公开数据指标要用实际底库的相似人群密度来定。5. 端侧部署与工程化把模型塞进门禁机的那些坎5.1 目标平台与性能预算门禁设备一侧是典型的边缘环境。我们拿到的目标盒子算力大概在4T到6T之间内存4GB不支持GPU通用计算但支持TensorRT加速。经过ONNX导出到TensorRT之后FP16精度下YOLO26单帧推理耗时大约25毫秒INT8量化后进一步压到15毫秒上下。如果部署平台连TensorRT都不支持就要考虑换成NCNN或者ONNX Runtime。但要记住INT8量化对识别分支的特征分布影响很大。我有一次量化完ArcFace特征向量的平均余弦相似度漂移了0.08个别样本漂移超过0.15误识率翻倍。所以量产后必须用底库特征做回回归测试而不能只看检测框准不准。5.2 RTSP拉流、ROI区域与管线并行门禁摄像头一般走RTSP协议取流解码后进入算法管线。这里最容易犯的错是对整帧图像跑算法。闸机前的画面大量区域是墙壁、地板和排队区不存在人脸做全图推理就是浪费算力。我们的做法是先设置ROI区域只对闸机前方一米范围内的区域做检测其他部分直接裁剪掉。ROI设定还能天然过滤掉侧面路过的人降低误识别风险。管线并行是另一个隐蔽的性能提升点。解码线程负责不断取帧检测线程以固定帧率运行比如每秒10帧识别线程只在检测到新的人脸track时被触发比对线程负责特征向量和底库的余弦相似度计算。四个线程之间用环形缓冲区连接把原本串行的“取帧-检测-识别-比对”压成了流水线整体刷脸延迟可以从400毫秒降到250毫秒左右。实现时要注意缓冲区的锁粒度锁太重会导致流水线阻塞反而更慢。5.3 活体检测防照片攻击的稳定做法活体检测是人脸门禁不能省的部分因为一张A4纸打印照片就能骗过静态人脸识别模型。我测试过几种方案动态指令活体随机要求眨眼、摇头、深度相机、红外活体。动态指令活体体验最差早晚高峰没人愿意配合做动作只能用在低流量场景。深度相机成本高而且室外强光下深度质量不稳定。我们最终选用的是红外加可见光双目方案红外相机下真人的眼睛会有一个独特的高光点照片打印后在红外下是平面纹理缺少这个高光点。算法只需在红外图像上检测眼睛区域的梯度特征配合可见光特征做交叉验证。这套方案实现很简单大概是在识别分支通过后再额外跑一个小分类模型输入红外ROI图输出“真脸”或“假脸”。它可以不参与每帧推理只在可见光识别已经通过后才做所以几乎不增加延迟。5.4 时延分配表每一毫秒都要有数交付部署时我给整个刷脸链路做过一次完整的时延拆解。以一次正常刷脸流程为例摄像头取帧到检测线程约40毫秒ROI裁剪和预处理约10毫秒YOLO26检测前向约25毫秒人脸对齐和特征提取约20毫秒底库比对约30毫秒底库5000人加上活体校验30毫秒最终闸机IO指令约10毫秒。合计165毫秒加上系统调度抖动能在300毫秒目标内完成。如果哪个环节超过了预算我建议先从底库比对开始优化因为很多遗留系统底库人脸上万暴力比对延迟会线性上涨解决方式是把特征向量存成预索引结构或者分片比对。6. 阈值、并发与活体系统集成阶段最容易翻车的三个点6.1 阈值不是调一个数那么简单前面算法设计阶段提过阈值自适应这里说实测细节。我们刚开始统一用0.55作为余弦相似度阈值结果晴天上午有6%的员工刷不进来一片投诉。查日志发现这些人集中在逆光侧特征向量被光照拉远了而同一阈值在夜间低光条件下FAR又有上升风险因为夜间图像噪声让不同人的特征趋同。后来我们把一天按四个时段切分每个时段单独标定阈值并针对每个摄像头位置单独配置。同一栋楼东门早上是逆光、西门下午是逆光不可能共用一套参数。阈值标定方法是拿一周的闸机日志把所有比对成功的特征对和失败的比对按相似度画分布直方图找两个分布相交点附近的区间做一个偏保护的偏移。然后定期重跑因为季节光照变化会导致分布整体平移。6.2 多人同框与并发跟踪ID让门禁不乱门禁场景的真实画面经常同时出现五六个人闸机第一次开门后后面的乘客就排队往前挤。最初版本在多人同框时选最大的框来识别结果后面一个人脸更大前面刷到一半的授权人反而不被处理了闸机莫名其妙先给后面的人开了门。这是不可接受的。解决办法是人脸跟踪ID机制。检测到人脸后为每个框分配track ID只有当track ID连续出现在画面里足够时间比如3帧时才触发识别任务。识别通过的track ID在一个短时间窗口内拥有“闸机授权”状态即使他继续往前走系统也会持续跟踪直到他离开ROI或闸机开启。多人同框时优先处理“正在闸机正前方且track年龄最大”的人脸避免频繁切换目标。这个逻辑看起来很朴素但缺了它门禁系统在高峰期就是一场灾难。6.3 模板库注册与更新一次性录入根本不够门禁系统上线时大家想当然觉得录入一张正脸照片就完事了。实际上人的外貌随时间变化发型、眼镜、胡须、体重都会变。我们设计的底库不是存一个固定特征而是每个员工保存一个特征列表录入时采集两到三个角度的样本后续每次成功刷脸后把当日相似度最高的特征做滑动平均合并回模板里。这样模板会缓慢地向这个人当前的真实样貌漂移不用重新录入。底库更新还有一个风险点防止模板被污染。如果某一次算法发生了误识把另一个人A的特征混进了员工B的模板那之后A再刷脸相似度会越来越高形成闭环污染。所以我对模板更新设了一个严苛条件不但当前识别相似度超过阈值还必须连续三次成功通过才允许合并回模板。这个条件基本杜绝了单次误识带来的模板污染。7. 实测效果与一组值得关注的失败样本7.1 自建测试集上的最终指标最后交付出的一版模型在覆盖多时段、多光照的自建测试集上检测mAP0.5达到99.3%人脸关键点平均归一化误差在5%以内识别部分在FAR1e-4条件下FRR从最初的6.2%降到了0.8%左右。端侧整体全流程平均延迟约210毫秒满足项目验收要求。但我始终觉得任何静态测试集指标都比不上一线真实闸机一个月的日志。上线第一周我们的真实FRR是1.8%比测试指标高出一个百分点难例回灌后又降了下去。7.2 三个印象深刻的失败案例第一个案例是双胞胎员工。他们的特征相似度长期稳定在0.75以上而正常情况下同事间的相似度很少超过0.35。0.6的阈值根本压不住他们两人来回串门刷脸系统毫无办法。最终方案是给这对双胞胎强制追加刷卡因子人脸识别只作为二级确认。任何算法在面对这种极端相似个体时都很难只靠视觉解决。第二个案例是“逆光加黑口罩”的组合。检测分支可以稳定输出口罩遮挡的人脸框但识别分支因为没有下半张脸的信息FRR显著上升。我试过单独训练口罩感知分支效果一般最终保留的增强策略是口罩场景下调低识别阈值并叠加红外活体优先保证通过率而不是绝对精度。第三个案例是剧烈运动模糊。有人在闸机前小跑图像产生运动模糊检测框抖动严重识别特征很不稳定。这个问题用后处理解决了大半在跟踪ID存在的50毫秒窗口内缓存3次识别结果做简单投票连续两次一致才放行暴力降低了瞬时模糊造成的误拒。7.3 后续演进方向模型压缩与多模态融合YOLO26这套方案跑通之后我一直在想下一步怎么做。一条方向是模型压缩和蒸馏用一个更大的教师模型在数据分布上蒸馏学生模型在相同参数量下能再压出一个精度点。另一条方向是多模态融合人脸识别叠加刷卡、手机蓝牙或者声纹在敏感区域采用“人脸另一因子”的策略而不是把宝全部押在视觉识别上。还有一个很实际的方向是把底库检索做到库里用类似向量数据库的方式管理特征索引把上万人的比对耗时从线性扫描降下来。说白了门禁识别算法的终极考验不在论文指标而在真实人群、真实光线、真实情绪下能不能稳定运行。我自己最受益的一个习惯是在上线前给自己搭一套“每日晨测”脚本每天早上定时用当天第一缕逆光的光线实测闸机误拒率自动生成报告。这套脚本后面帮我发现了好几个只在特定光照条件下出现的问题比任何测试集都灵敏。如果你也在做类似的人脸门禁系统建议早点把这条晨测链路建立起来它能替你省下大量半夜去现场救火的时间。
