写点什么

人脸识别:城市公共交通

  • 2023-04-26
    北京
  • 本文字数:3044 字

    阅读完需:约 10 分钟

Hi,您好,欢迎使用百度人脸识别服务。

本文档主要针对 城市公共交通行业相关场景,描述百度人脸识别产品的相关 架构方案。如果您对文档内容有任何疑问,可以通过以下几种方式联系我们:

  • 在百度云控制台内 提交工单,咨询问题类型请选择 人工智能服务

  • 如有需要讨论的疑问,欢迎进入 AI社区 与其他开发者们一同交流。

1、业务背景

随着人脸识别逐渐广泛的应用,轨道交通行业也逐渐试点及落地一些刷脸项目。应用人脸识别,不仅可以提升用户使用体验,也可更加精细化管理,解决丢卡、串票、二次核验困难等情况发生。

随着国家相关部门及省市等文件的出台,人脸识别在公共交通方面的应用,也将愈加积极与紧迫。

1.1 主要场景及需求:

  • 地铁:刷脸支付过闸、工作人员通道核验、老人儿童核验

  • 高铁:实名制进站验票、刷脸验票进站

  • 有轨电车:刷脸验票

  • 城市公交:刷脸验票、老年刷脸乘车、学生刷脸乘车

  • 观光汽车:刷脸验票(多次搭乘)

  • 长途汽车:刷脸验票

1.2 面临的场景困难

  • 人脸底库大:公共交通乘客人员基数动辄几十万、几百万。甚至千万级,传统的 1:N 方案难以保障高精度识别,涉及到频繁的支付,业务操作更需要谨慎。

  • 人员流量大:存在早晚高峰时段,通闸速度要求高,识别速度需要有效保障,不可显著低于刷卡形式。

  • 稳定性要求高:设备和业务程序需要经过严格测试,如出现现场问题,将引发较大的人员通行堵塞。

1.3 场景特殊要求

  • 网络条件:网络环境不一定十分稳定,如果出现断网、网络抖动情况,对核验效果会有很大影响。

  • 数据隐私:必须要求离线化部署,人脸信息统一进行局域网部署,或者集中化专线管理。

  • 识别精度:涉及支付核验,对于识别精度要求更高,容错率很低。

2、业务架构



上图为整体产品及技术架构的方案示意图,下面进行拆解分述。

2.1 人脸采集与业务关联

相比于传统的卡证形式,人脸的录入需要进行一个必要的采集过程,需要确保采集人脸的质量同时,还要确保实名录入、账户与人脸有效关联等问题。我们为您提供了一系列产品方案,用于快速集成应用。

2.1.1 APP 采集

通过轨道交通相关 APP,进行「人脸二次关联操作」,将账号与人脸信息进行关联,作为后续消费的主要依据,同时也充当了账号+密码、或账号的作用。

  • 优点:使用百度手机端采集 SDK,可以有效提升采集的用户体验,及采集图片的质量,确保入库的图片符合后续识别的要求,如模糊度、遮挡、光照等。同时 APP 方式也可使用 SDK 本地化的有动作活体校验,配合云端活体检测接口,做到二次活体核验,避免作弊。

  • 缺点:用户安装成本高;推广成本高;开发成本较高,需要强行推动用户在 APP 中进行刷脸验证。

相关产品链接

2.2.2 H5/PC Web 采集

主要应用与 H5 方案、微信公众号或小程序、PC Web 站点。

  • 优点:用户接入成本低,覆盖渠道广,便于宣传推广。

  • 缺点:安全性差,活体检测容易遭到攻击;仅具备浏览器权限,对于图片的质量把控不容易很严格,容易造成采集的人脸图片质量不佳,影响后续业务应用效果。

相关产品链接:

2.2.3 固定设备采集

使用在柜台或者固定地点的设备,需要用户自助或者在被指导情况下,进行配合录入人脸。

  • 优点:因为是单独定制的设备,具备更好的镜头效果、更流畅的业务应用运转效果;同时可以让用户充分进行配合,录入图片质量更好。

  • 缺点:初期建设成本高;采集人数有限,用户很难全部到指定地点操作;维护和人员指导成本高。

相关产品链接:

2.2.4 实名认证

用户在初次录入人脸时,需要确保是「真人」的同时(通过活体检测实现),也要确保是「本人」,故需要在用户首次录入人脸并关联账户时,做一次远程的 实名认证。此认证需要链接公安居民身份库,进行权威官方数据核验,可以使用下方身份验证 API,使用官方直连数据服务。

另外如使用固定设备采集方式,也可以要求用户使用身份证进行 1:1 身份对比,保留实际采集到的那张生活照照片。

相关产品链接:

  • 身份验证API ,具备身份验证公安官方数据源资质。

  • 离线识别SDK ,如需要采集照片和身份证芯片照对比,请使用【证件照模式】

2.2.5 业务关联构建

录入人脸后,需要与系统中已有的账号 ID 进行关联,并先进行业务数据库构建,此时需要储存的原始数据包括:

  • 人脸数据(保留原图,便于后续更新模型时刷库)

  • 人脸-ID 的关联映射表

  • ID-支付账户-支付信息的关联映射表

  • 上述两表做关联

2.2 前端设备模块

在闸机、核验卡口等身份核验的关键位置,需要布设人脸核验设备,此设备一般采用定制化研发,形成一个整机,并与通行管理的设备联动应用。

以下简要介绍以下核验设备的几个核心部分构成及作用。

2.2.1 镜头

镜头外设一般为四种选择:

  • 单目可见光:成本低,活体安全性差,如有人看守下首选。

  • 双目近红外:有 IR 活体,RGB 做识别,成本相对较低,是安全性和成本的平衡选择。

  • 3D 结构光:RGB+Depth 活体,安全性高,技术稳定成熟,但成本较高。

  • ToF:RGB+Depth 活体,安全性高,技术相对稳定成熟,但成本较高。

参考链接

2.2.2 主板

主板的选型,一般要考虑以下几个因素:

  • 功耗:涉及整机的散热及产品稳定性

  • 兼容性:与 SDK 的兼容性,避免使用特别特殊的选型

  • 芯片推荐:Rockchip、MTK、高通、NXP

2.2.3 设备整体

此处主要有一些注意事项:

  • 整体散热

  • 信号(如使用无线网络)

  • 各项接线的稳定性

  • 架设角度(一般推荐与垂直方向相差 10°—15°)

2.2.4 离线 SDK

需要在设备前端动态实时地获取人脸信息,SDK 需要具备以下几个核心能力:

  • 离线人脸检测

  • 离线质量判断

  • 离线活体检测

  • 离线活体检测

  • 离线识别比对(一般为后端统一对比,但也可在前端进行小库查询)

性能方面,如 rk3288,整体全流程耗时在 300ms 左右。

产品链接:

2.3 局域网人脸私有化部署

因为使用超大库检索,我们推荐使用私有化部署包,应用大模型进行特征比对环节的处理。

私有化部署包具备以下几个特点:

  • 大模型,精度更高。十万分之一误识率下,准确率 99%以上

  • 服务器部署形态,可直接构建后端整套人脸识别服务

  • 完全离线形态,可满足数据隐私和安全性要求

  • 预设基础业务逻辑接口,包含人脸对比、人脸搜索、人脸库管理、活体检测二次核验接口

产品链接:

2.4 业务逻辑模块

此模块主要包括以下几个常见能力:

  • 刷脸与支付的业务关联:进出站扣费逻辑、去重逻辑、阈值设定等

  • 人脸管理逻辑:更新、删除人脸;关闭人脸支付等

3、应用策略

3.1 人脸底库构建

3.1.1 分组方式

以身份证 ID 尾号,或者手机尾号作为组命名依据,将整体大人脸库分为若干个小组。

3.1.2 用户 ID 定义

用户 ID 可使用身份证 ID、手机号码,或者系统单独定义的 ID

3.1.3 模型替换与刷库

特征抽取模型的更换,涉及到要将所有原图重新刷一遍特征值(不同模型的特征值不能通用),所以为了后续的长期维护,请务必要保留用户采集注册的人脸原图。

3.1.4 底库图片例行更新

如果用户在识别过程中,人脸得分非常高(95 分以上),且质量较好,可使用识别过程中的图片,更新用户的底库原图。通过对底库的持续动态更新,不断修正识别的效果。

3.1.5 注意事项

  • 注册图片一定要质量较好,详细请参考:如何保证图片采集质量

  • 不要使用身份证的芯片照注册,如需要通过人证对比来采集图片,请使用实际采集的生活照

3.2 超大库人脸库检索

3.2.1 最佳库大小

单个分组库大小,最好不要超过 30w,如果分组可足够精细,推荐最佳不要超过 5w。

3.2.2 预检索

可基于以下几点进行数据库维度的预检索,查询到固定的组,将实际检索的人脸库锁定到这个组上。这个数据库预检索的方案,包括:

  • 基于手机蓝牙

  • WiFi 探针

  • 相关证件

3.3 活体检测选型

详细请参见:活体检测选型

3.4 人脸采集质量

详细请参见:

发布于: 51 分钟前阅读数: 5
用户头像

关注百度开发者中心,收获一手技术干货。 2018-11-12 加入

汇聚百度所有对外开放技术、平台和服务资源,提供全方位支持,助力开发者加速成功,实现开发者、消费者和百度三方共赢。https://developer.baidu.com/

评论

发布
暂无评论
人脸识别:城市公共交通_人工智能_百度开发者中心_InfoQ写作社区