人脸识别为什么要眨眼还要闪各种颜色的光

今天办业务需要人脸识别，拿起手机把我的小胖脸放入框中眨眨眼，等待灯光闪烁，随后就是通过，这个已经见怪不怪了，偶尔还要张张嘴，左右摇头，我知道他这是在确认我是不是真人，但是哪怕我做过简单的人脸识别，我也没有深究过人脸活体检测具体有多少方法，以及闪光是在干嘛，本文对此做了调研和解释。

差不多在 23 年有一个小项目，要做离线人脸识别来替换百度人脸识别 API。没太多性能要求，我搜刮来一个 facenet-retinaface-pytorch 仓库，扒拉两下就集成进系统了。

这个仓库只需要把人脸向量存起来，再把新照片转换成向量做对比。底层不用懂也能跑通，后来需求搁浅，我也就没有继续深究。

首先，人脸识别是怎么实现的

不展开神经网络和数学公式，整个过程可以粗略分成三步。

摄像头拿到画面后，先找到人脸的位置，把脸裁出来并校正角度；接着模型把五官、轮廓和纹理压成一串数字，也就是人脸向量；最后，把这个向量和之前保存的向量计算相似度。

相似度超过阈值，系统就认为两张脸可能属于同一个人。阈值越严格，冒认更少，但真人也更容易被拒绝。

所以，人脸识别主要回答的是“这张脸像谁”，而像谁并不能代表眼前真的就是谁。一张照片、一段视频，照样能提取出很像的人脸向量。

为什么要做人脸活体检测以及怎么做

当然，不做活体检测的话，拿张照片或者播放一段视频就可能通过人脸比对。它要补上的问题是：镜头前的东西，究竟是现场真人，还是照片、屏幕、面具或被替换的视频流。

来点专业词汇，活体判断可能会组合随机挑战、RGB 纹理与时序、深度或红外、材质与光反射、可信采集链路和服务端风控。一下子就懵了，还是先从我最早的两个问题说起。

眨眨眼是干嘛的

最早、最直观的用途，是排除一张不会动的静态照片。系统连续观察眼睛，如果看到“睁开—闭合—再次睁开”的时序，就认为镜头前至少不是一张完全静止的普通照片。

系统通常会在每一帧里定位眼角和上下眼睑，计算眼睛高度与宽度的比例。这个数值短时间内从高变低、再变高，就很像一次眨眼。现代模型可能直接输出眼睛开合概率，原理差不多。¹

如果系统临时提示“现在眨眼”，它还构成了一次简单的挑战—响应：系统刚发出要求，用户随后作出动作。这比静静等待一次自然眨眼，多了一点“正在发生”的证据。

但它的证明力有限。视频中的人也会眨眼，挖掉照片的眼睛区域也能模拟眨眼，实时换脸则可以直接跟随攻击者的动作。眨眼能对付普通照片，却不能单独对付视频重放。²

屏幕颜色变化是干嘛的

在典型的活体认证实现里，手机屏幕被临时当成了一个可编程光源。系统随机生成一串颜色、亮度或图案，让它们依次照到脸上，同时让前置摄像头记录脸部反射。颜色不是主要让人去识别、记住或回答；真正“回答问题”的是脸对光的即时反射。

它想核对三件事：

1. 时间是否对得上。 本次认证临时生成的随机颜色序列，相当于一次性口令。脸上的颜色变化必须紧跟本次序列，不能是过去录好的一段固定画面。
2. 空间形状是否像人脸。 鼻尖、眼窝、额头、面颊朝向不同，受到同一块屏幕照明时会出现不同的明暗分布。普通照片或显示屏是近似平面，反射分布不同。
3. 材料是否像皮肤。 皮肤、纸张、玻璃屏和硅胶面具的反光方式不一样，模型会尝试找出这些差异。

2018 年的 Face Flashing 研究系统化提出了这种做法：屏幕随机闪现颜色或图案，再分析脸部反射的时间、纹理和三维形状。³ AWS 的商用活体服务也提供“面部移动 + 彩色光序列”的模式。⁴

当然，屏幕变色也可能兼有曝光、白平衡校准，甚至只是界面效果。只看页面闪了几下，无法确定某个 App 到底用了哪些模型。

如果我用一段眨眼视频会怎么样

答案是：有可能，但取决于系统检查到了哪一层。

• 只检查有没有眨眼： 预录视频本来就有“睁—闭—睁”，存在通过的可能。
• 还检查屏幕重放痕迹： 系统会寻找摩尔纹、屏幕刷新、玻璃反光、二次压缩和平面运动，视频就没那么容易过。
• 再加随机光、深度或红外： 固定视频不知道本次颜色序列，普通屏幕也缺少真实人脸深度，通过难度会进一步提高。

还有一种更危险的情况，是不拿屏幕对着摄像头，而是直接用虚拟摄像头或修改 App 的相机画面。这已经不只是活体算法的问题，还需要系统确认视频确实来自可信的真实摄像头。

最后

人脸识别回答“这张脸像谁”，眨眼检查“画面里的脸有没有做动作”，随机变色则检查“这张脸有没有立刻响应本次随机光”。可靠的系统不会只押宝其中一项，而是把多种线索放在一起判断。