写点什么

大麦人脸识别系统,如何支撑马拉松赛事?

  • 2020-03-14
  • 本文字数:3664 字

    阅读完需:约 12 分钟

大麦人脸识别系统,如何支撑马拉松赛事?

大麦的人脸闸机在 2019 年杭州马拉松上成功的完成了刷脸入场功能的首秀,相比传统的马拉松入场核验方案在入场体验和入场效率上都有了很大的提升,下面介绍一下大麦的人脸识别是如何支持马拉松赛事的。


一、马拉松赛事流程介绍

马拉松赛事的流程主要分三步:


第一步,参赛者到马拉松官方网站报名,报名成功后会通知选手;


第二步,报名成功的选手需携带身份证到官方指定的地点领取装备;


第三步,比赛当天携带号码簿验票入场进行比赛。



我们面临的挑战是:


1)如何在指定时间内完成参赛者的装备领取工作:既要保证快速领取不造成人员积压,又要保证装备不会领错;


2)如何保证比赛当天在短时间内完成几万人的入场核验工作。

二、大麦人脸识别解决方案

在介绍大麦的人脸识别方案之前,首先介绍人脸比对的几个常用术语:


1 比 1:1 比 1 是指用照片跟人进行比对,通过算法判定照片和人是否是同一个人,简单理解就是证明“你就是你”。



1 比 N:1 比 N 是指在 N 个人的照片库里(底库)进行查找,通过算法判定这个人是否在这些照片里面,通俗来讲就是“我是谁”。



清楚了马拉松赛事的流程之后,下面介绍大麦是如何支持现场领取装备和比赛当天入场核验的,在我们的方案里面比赛当天的入场核验是压力最大,风险最高的,而且这个也是依赖前两步的。


选手入场比赛时不会携带手机和证件,那如何进行验票呢?


大麦传统做法:提前跟主办沟通,在号码簿中放置一个射频芯片,芯片号与号码簿上的号码一一对应,这样通过验票设备扫描到芯片后会查询到这个选手的参赛信息,包括照片(来源于第 1 步和第 2 步),为什么需要照片?只有拿到照片然后和本人进行比对才能确认是不是本人还是替跑,这就用到了人脸识别,也就是上面所说的 1 比 1 比对。



这个方案是可行的,但面临两个问题:


1)号码簿是第三方公司负责的,经常会遇到号码簿里没有芯片或者芯片号跟号码簿上的号码不一致(实际发生率还比较高),这就会造成选手无法直接核验入场,需要人工处理;


2)这种入场方案需要先核验芯片,再进行人脸比对,在马拉松赛事中有一些力不从心,因为几万名选手需要在短短的半个多小时完成入场,压力可想而知。


如何优化选手入场,既避免号码簿芯片的问题,又能快速准确的核验?


这就用到人脸识别的 1 比 N,我们提前拿到所有选手的照片,选手直接刷脸进行比对,快速核验入场。



这个优化的方案需要做到以下两点:


1)安全的人脸比对算法,该进去的人放行通过,不该进去的人拒绝开闸;


2)提前获取所有选手的照片,而且照片质量需要足够好,用作人脸比对的底库。


人脸比对算法这块要求是比较严格的,马拉松赛事每年都有很多替跑的人,我们的人脸算法必须要能找出替跑者,而且大麦的验票场景像演唱会的门票动辄上千,是决不允许让无票的人入场,当然也要让买了票的人能够正常通过,这样的场景与刷脸支付场景比较像,因此我们使用了成熟的金融级别的人脸算法。


获取所有选手的照片的问题,我们是通过前面介绍的报名和领装备的环节解决的:


我们会要求选手在报名的时候提交一张本人的照片,但是这不能保证所有人都提交了质量足够好的照片,而且提交的照片是本人。这就需要在现场领取装备的时候解决,因为这影响到比赛时能否正常顺利入场。


下面介绍我们是如何在完成领取装备的同时获取到选手的照片:


我们都知道,入场验票时是需要票的,选手在使用身份证领装备的时候其实他的身份证就是一张票,选手使用大麦的闸机系统刷身份证后,系统会根据身份证号读取到选手的信息,然后会通过闸机的打印系统打印出一张小票,选手拿着小票到相应的窗口领取参赛装备。但是这样无法满足主办的要求,必须要求选手持本人身份证到现场领取装备,当然也无法满足我们自己的需求——获取到所有选手的照片。因此我们在选手刷身份证的时候对他进行了 1 比 1 比对,确认是本人后再去采集一张用户现场的照片,这就完成了身份确认和照片的获取。


在这个方案里,领取装备的这个流程其实是可以优化的,用户在第 1 步报名时提交的照片有很多是质量很好可以直接用的,没有必要到现场再进行一次采集,对于这部分用户我们有了他们的照片之后会引导他们直接通过 1 比 N 人脸刷脸比对入场打印小票进行领取装备,这个方案的优点是:


1)直接刷脸,无需刷身份证+1 比 1 比对+采集,让领取效率更高,避免现场排队


2)解决了很多已上传人脸的用户忘带身份证或者身份证丢失导致的无法领取装备的问题



小结:我们通过报名的时候引导选手提交照片,通过现场引导让提交照片的选手直接刷脸领取装备,对于刷脸识别失败和未成功提交人脸的选手通过 1 比 1 进行本人确认并进行人脸采集,这样就确保了所有选手的照片都到了我们的人脸底库,也就使得我们在比赛当天可以让选手直接使用 1 比 N 比对直接刷脸入场。

三、保护用户隐私与数据安全

我们的人脸识别入场的方案是基于用户的照片,这就涉及到用户的隐私,我们会在马拉松报名的时候提前告知用户,获得用户的授权,我们需要做的更多的是如何保证用户照片的安全。下面介绍我们的方案:


闸机识别到用户后需要显示用户的照片,为了保护用户的照片不被泄露,我们对读取用户照片的接口做了授权判断,非授权设备无法获取照片数据,只有已授权的设备才能获取到照片数据,且是已经进行过加密处理的,保证了数据不会从端上泄露。


现场采集用户照片时,我们会将采集到的照片进行编码之后再进行一次加密操作,加密之后上传到服务端,上传成功之后会立即删掉本地的照片。在本场比赛结束之后服务器会自动将所有照片删掉。


通过以上操作,保证了用户的照片数据安全,也就保护了用户的隐私。

四、人脸闸机软件架构演进

讲完了我们的人脸识别方案,下面再介绍一下我们的软件架构是如何支撑我们的人脸识别入场:


我们的闸机采用的是安卓系统,开发闸机的人脸核验系统跟开发普通的安卓应用稍有不同,我们需要针对硬件进行适配:机芯(摆闸、辊闸),打印机,二维码模块,RFID 模块,身份证模块等。


那整个闸机的软件架构很自然的就成下面的样子:



这样的方案用起来是没有问题的,但是时间长了会发现几个问题:


  • 无论是改动业务代码还是硬件驱动代码都需要针对整个应用升级

  • 随着闸机型号的增多,程序中会有各种型号的驱动,导致硬件驱动的代码臃肿,不易维护

  • 关于硬件的适配,由于跟业务代码合在一起,只能我们自己来做,无法交给闸机的厂商


因此在这个基础上我们对软件架构进行了优化:业务程序与驱动程序分开,采用了面向接口编程的思想,业务程序通过 AIDL 的方式将命令给到驱动程序。



这样的好处显而易见:


  • 业务和驱动代码不再耦合在一起,各自独立,业务应用只需关心业务逻辑,驱动应用做好硬件驱动的事情;

  • 业务程序无需关心驱动程序如何实现,驱动程序的实现可以交由厂家实现,我们制定标准就好了;

  • 业务程序和驱动程序独立升级,按需升级;

  • 每种型号的设备使用统一的业务程序,只安装自身的驱动程序,不再需要将所有的不同型号的设备驱动代码都放在一起。

五、人脸识别能力优化

我们采用了安全的人脸识别算法,但这不表示算法就能解决我们现场的所有问题,大麦的现场环境较刷脸支付场景更为复杂,下面介绍我们是如何优化和提升我们的人脸识别能力。


  1. 解决底库增大 &&降低误识率


研究过人脸算法的同学应该清楚,再完美的人脸算法也会有误识的情况,也就是误识率,而且随着底库的变大,误识率也会跟着上升。马拉松的场景几万人很正常,既要降低误识率又要满足底库的变大,看似一个矛盾的问题,而且算法层面目前是无法解决,但必须要解决业务问题,我们的思路是:既然算法无法解决,那只能通过业务去解决,我们知道马拉松赛事还细分为全马,半马,情侣跑,迷你跑,家庭跑等不同的种类,那我们就可以根据这些不同的种类将人群分开,这样就做到了减少了底库,那误识率自然会降低。


  1. 人脸数据全流程打通


上面讲过通过报名网站进行人脸采集或者现场刷身份证进行现场采集,完成人脸采集,但是还有一种情况是用户既没有在报名时上传照片,又没有携带身份证,这些用户只能通过大麦 APP 进行采集,那如何保证 APP 上采集了之后能马上入场领取装备?那就需要把整个流程打通,具体如下:



  1. 动态远程调优


马拉松的人脸识别场景其实要比人脸支付的场景复杂,人脸支付大多是在室内,光线的影响会相对小一些,而马拉松既要考虑室内场景(领取装备)又要考虑户外场景(开跑入场),面临着曝光过度、逆光侧脸和远距离等的影响,因此需要根据具体环境来进行调优,我们通过在管理端动态修改影响人脸算法的各种参数,以及是否采用降级方案等,远程下发到现场所有设备,确保选手顺利高效入场,不会引起排长队的问题。

六、总结

我们根据马拉松赛事实际的业务场景,将人脸识别功能 1 比 1 和 1 比 N 应用到马拉松赛事,开启了马拉松行业的新的入场模式,但是我们的路还很长,人脸算法需要继续提升:提高识别率与降低误识率,不同环境下人脸算法的优化配置,室内与户外的不同验票方案以及已经开始商业化的 5G 能否给我们的业务带来新的突破,我们会将人脸识别功能应用到更多的核验场景,持续提升现场用户的入场体验和通行效率。


作者简介


阿里文娱技术专家 墨贤


相关链接


基于云原生的边缘计算在大麦现场的探索应用


2020-03-14 09:001907

评论

发布
暂无评论
发现更多内容

从recat源码角度看setState流程

flyzz177

React

从深度学习框架到开发工具,百度飞桨携最新成绩单亮相 GTC

飞桨PaddlePaddle

英伟达 百度飞桨 GTC

基于大规模边缘计算的千万级聊天室技术实践

环信

聊天室 大规模边缘计算 千万级

【明晚直播】KunlunBase 1.1 版本发布:完善MySQL 兼容性,OLAP性能提升

KunlunBase昆仑数据库

MySQL 数据库 PgSQL 线上直播

深入React源码揭开渲染更新流程的面纱

goClient1992

React

从计费出账加速的设计谈周期性业务的优化思考

鲸品堂

运营商 业务流程优化 企业号 3 月 PK 榜

假如面试官要你手写一个promise

helloworld1024fd

JavaScript 前端

滴滴前端一面常考手写面试题整理

helloworld1024fd

JavaScript 前端

手写一个react,看透react运行机制

goClient1992

React

BNB Chain 2023年40佳DAPP评选,Zebec赫然在列

威廉META

Unity 荣膺 2022 鲸鸣奖“影响力出海品牌”及“新势力出海服务商”两项大奖

Geek_2d6073

一次配置,设备就可实现毫秒级的全球就近接入——实践类

阿里云AIoT

阿里云 物联网 IoT

极光笔记 | 极光PUSH服务助力企业提升抢单速度

极光JIGUANG

技术干货 移动推送 智能推送

从源码角度看React-Hydrate原理

flyzz177

React

技术写作的“坎”

码猿外

程序员 写作

从零手写react-router

helloworld1024fd

JavaScript 前端

基于开源IM即时通讯框架MobileIMSDK:RainbowChat-iOS端v6.2版已发布

JackJiang

网络编程 即时通讯 IM

深度分析React源码中的合成事件

goClient1992

React

云原生消息队列Pulsar浅析——实践类

阿里云AIoT

阿里云 物联网 IoT

轻量易部署!Coolbpf 发布不依赖 Clang 的脚本化编程特性 lwcb | 龙蜥技术

OpenAnolis小助手

开源 rust ebpf coolbpf lwcb

BNB Chain 2023年40佳DAPP评选,Zebec赫然在列

鳄鱼视界

从react源码看hooks的原理

flyzz177

React

自动化测试工具加入黑科技带来新纪元

石臻臻的杂货铺

人工智能

京东前端二面常考手写面试题(必备)

helloworld1024fd

JavaScript 前端

墨天轮2022年度数据库获奖名单

墨天轮

数据库 opengauss TiDB oceanbase 国产数据库

你的聊天室该升级啦!融云平滑迁移方案助你「无感换乘」

融云 RongCloud

通讯

DockQuery 天狼 v1.2.0 正式发布

BinTools图尔兹

#数据库

ChunJun 1.16 Release版本即将发布,bug 捉虫活动邀您参与!

袋鼠云数栈

适合开发团队的文档管理系统盘点

爱吃小舅的鱼

文档管理软件 团队协作管理

大麦人脸识别系统,如何支撑马拉松赛事?_文化 & 方法_阿里巴巴文娱技术_InfoQ精选文章