QCon 演讲火热征集中,快来分享技术实践与洞见! 了解详情
写点什么

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

  • 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:001940

评论

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

60岁代码匠的几篇小作文,解决了大多数程序的迷茫(下)

图灵社区

java 编程

深入解析Apache Pulsar系列: Broker消息确认的管理

博文视点Broadview

LeetCode 每日一题 No.1220 统计元音字母序列的数目

DawnMagnet

rust LeetCode 力扣

前端开发之Vue事件修饰符和按键修饰符

@零度

Vue 前端开发

物联网场景中灵活实施对设备的控制管理

亚马逊云科技 (Amazon Web Services)

analytics

数据安全是指什么?有什么意义?

行云管家

防火墙 信息安全 数据安全 堡垒机

带你玩转Flink流批一体分布式实时处理引擎

华为云开发者联盟

flink 分布式 实时计算 批处理 流处理框架

第二节:SpingBoot单元测试

入门小站

java 编程

4 种高速安全混合云解决方案,助力您的云迁移之旅!

亚马逊云科技 (Amazon Web Services)

网络

在字节,A/B 实验是这么做的!

字节跳动数据平台

大数据 字节跳动 AB testing实战 ab测试

阿里云视频云「 vPaaS 」演绎了怎样的音视频应用开发「未来图景」?

阿里云CloudImagine

阿里云 音视频 低代码 低代码开发平台 视频云

手把手教程|通过部署 Apache Superset 实现 Amazon S3 的数据可视化

亚马逊云科技 (Amazon Web Services)

analytics

iOS——解密RunLoop原理

iOSer

ios iOS面试 ios开发 RunLoop

建木持续集成平台v2.2.0发布

Jianmu

开源 持续集成 CI/CD

17 Prometheus之服务发现介绍

穿过生命散发芬芳

Prometheus 1月月更

打造手淘极简包的轻量化框架

阿里巴巴终端技术

ios android 框架设计 移动开发 包大小

这8个JS 新功能,你应该去尝试一下

华为云开发者联盟

JavaScript 前端 开发 索引 开发语言

IT运维人员日常工作包含哪些?核心任务是什么?工作量多吗?

行云管家

运维 IT运维 服务器运维

实战 MongoDB Aggregate

PingCode研发中心

mongo pipeline Expression

聚类算法有哪些?又是如何分类?

郑州埃文科技

数据分析 聚类算法

Flink是如何支持批流一体的

编程江湖

flink

java开发之Redis数据结构

@零度

redis JAVA开发

Linux下玩转nginx系列(一)——初识nginx及其使用入门

anyRTC开发者

nginx Linux 音视频 WebRTC 服务器

大数据平台中的企业级数仓建设

五分钟学大数据

数据仓库 1月月更

恒源云(GPUSHARE)_实例关机后如何操作迁移?

恒源云

gpu 运维 实例

腾讯自选股如何实现单位小时内完成千万级数据运算

ninetyhe

腾讯 海量数据 分布式,

2022年RPA行业发展十大趋势,六千字长文助你看懂RPA

王吉伟频道

RPA 机器人流程自动化 RPAaaS 超自动化 自动化优先

改进企业CRM系统实施的方法

低代码小观

企业管理 CRM 企业管理系统 CRM系统 企业管理工具

无服务器应用DevOps最新实践(内附完整演讲+视频)

亚马逊云科技 (Amazon Web Services)

计算

推动数字化人才发展|奈学科技CEO孙玄受邀出席2022年CXO领导力峰会

科技热闻

【网络安全】2022年第一次靶场渗透实战学习

H

网络安全 渗透测试

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