AWS AI Service Card 解释了该服务预期的使用案例、该服务如何使用机器学习(ML),以及负责任地设计和使用服务时的关键注意事项。Service Card 将随着 AWS 收到客户反馈以及服务在其开发过程中的迭代而演变。AWS 建议客户针对他们需要解决的每个使用案例在自己的内容上评测任何 AI 服务的性能。有关更多信息,请参阅《AWS 负责任地使用机器学习》指南和末尾的参考文献。另请务必查看您计划使用的服务的 AWS 负责任的人工智能政策和 AWS 服务条款。
本 Service Card 适用于截至 2023 年 11 月 27 日发布的 Rekognition Face Liveness 版本。
概览
Amazon Rekognition Face Liveness 使应用程序提供商能够预测试图访问服务的用户是否是摄像头前的真人。Liveness 旨在检测演示和数字注入攻击,防止第三方试图通过伪造人脸来冒充他人身份或逃避识别。演示攻击的示例包括实际呈现给摄像头的打印照片、数码照片、数字视频或 3D 面具。数字注入攻击是一种绕过摄像头的欺诈手段,例如使用预先录制或深度伪造的视频。本 AI Service Card 描述了负责任地部署和使用 Rekognition Face Liveness API 和 SDK 时的注意事项。通常,客户会利用 Amazon Rekognition Face Liveness 来验证用户是否真实出现在摄像头前,以便在验证完成后进行面部识别、年龄验证或机器人检测等后续可选任务。
Amazon Rekognition Face Liveness 要求用户将面部移入屏幕上的椭圆内,并在设备显示一系列不同颜色的灯光时保持静止。Face Liveness 使用该视频生成置信度分数。客户可以利用该评分来预测用户是否为真实出现在摄像头前的真人。 最低置信度分数为 0,表示可能存在欺诈攻击,最高置信度分数为 100,表示是真实用户。 客户应根据其使用场景选择合适的置信度分数。例如,中等置信度分数阈值(如 50 或 60)可能适合检测演示攻击和部分数字注入攻击。而较高的置信度分数阈值(如 80 或 90)可能更适合检测复杂的数字注入攻击,如深度伪造或预先录制的视频。总体性能由两个数字表示:真实接受率(TAR),即在置信度阈值以上未通过 Liveness 检查的真实用户百分比;真实拒绝率(TRR),即在置信度阈值以下未通过 Liveness 检查的欺诈攻击百分比。这些成功指标通常呈反比关系。例如,随着 TAR 的上升,TRR 会下降,反之亦然。更改置信度分数阈值会改变 TAR 和 TRR。Rekognition Face Liveness 本身无法独立确定自拍视频中的人脸是真实的还是伪造的。该决策是多个因素的结果,其中可能包括客户设定的置信度分数阈值、人工判断或两者的结合。
除了置信度分数外,Rekognition Face Liveness 还将返回从合作最终用户的视频中提取的高质量自拍画面。客户还可以将自拍画面用于其他用途,例如通过 Rekognition CompareFaces API 将自拍与身份证件照片进行比对,以完成身份验证;或通过 Rekognition DetectFaces API 进行年龄估算,作为最低年龄检查的参考。
Rekognition Face Liveness 旨在返回 2D 照片、3D 全脸面具、显示在设备屏幕上的数字照片或视频、以及预先录制的视频中的人脸的低置信度分数。相反,对于在活动检查过程中实时执行指定用户操作的真实用户面部,Rekognition Face Liveness 的置信度分数较高。然而,需注意的是,各种被称为“混杂差异”的因素可能会影响视频中面部的呈现,从而对真实用户的 Face Liveness 置信度分数产生影响。混杂差异的示例包括:(1)光线方向和强度的变化;(2)头部姿势;(3)摄像头焦点及视频拍摄缺陷;(4)视频分辨率;以及(5)面具、太阳镜、手、手机、围巾、帽子或其他物体造成的遮挡。
Rekognition Face Liveness 的性能会因多种因素而有所不同,包括预期的混杂差异量、设备屏幕特性(如亮度、尺寸和分辨率)、以及摄像头特性(如分辨率、焦距、帧率和比特率)等。
预期使用案例和限制
Amazon Rekognition Face Liveness 可以部署到许多不同的用例中。四个示例如下:
用户入门使用案例:金融科技、教育科技、医疗保健等行业的客户可能会选择进行人脸活动检查,以便新用户注册其线上应用程序。通过人脸活动检查后,可以使用 Rekognition CompareFaces API 将检测的自拍画面与政府颁发的身份证件上的人脸照片进行比对,进一步验证身份(更多关于负责任部署人脸匹配的信息可见此处)。
加强身份验证使用案例:金融科技、拼车、电商等行业的客户可以通过活动检查,提升用户在设备更换、密码更改或资金转账等重要操作中的安全性。通过活动检查后,可以使用 Rekognition CompareFaces API 将活动检测中的自拍画面与用户先前存储的图像进行比对。
用户年龄验证使用案例:在线游戏和约会平台在新用户注册时可能会选择实施年龄验证措施。在这些情况下,客户可以选择先进行面部活动检查,然后再通过 ID 检查和用于年龄预测的 Rekognition DetectFaces API 来验证用户的年龄。
机器人检测使用案例:为了防止机器人接管其平台,社交媒体和约会行业的客户可以选择采取措施来验证其用户是真实的人。为了实现这一目标,这些客户可以选择在用户每次登录其应用程序时进行人脸活动检查,从而帮助限制自动机器人账户。
局限性:Rekognition Face Liveness 对真实用户有最低设备要求。设备须配备前置摄像头,屏幕刷新率至少为 60Hz,屏幕尺寸至少为 4 英寸,且未越狱或 root,并具备至少 100 kbps 的网络带宽。摄像头须支持彩色录制,不得为虚拟摄像头软件,支持每秒 15 帧的录制速率,且最低录制分辨率为 320x240。台式机须配备安装在屏幕上方的网络摄像头以进行活动检查。最后,对于网页用户,支持的浏览器包括 Google Chrome、Mozilla Firefox、Apple Safari 和 Microsoft Edge。 上述混杂差异在室内和室外环境中可能都会发生。但是,在室内进行人脸活动检查时,通常通过在光线充足的条件下(例如办公室照明)拍摄正面姿势的自拍视频,可最大程度减少混杂差异的变化,从而为真实用户带来较高的 TAR。在这些最佳条件下,较高的置信度分数阈值(例如 80 或 90)可能会更有效地实现 TAR 和 TRR 之间的正确平衡。 在户外进行人脸活动检查时,可能会遇到不理想的环境条件,例如强烈的阳光会减少从用户面部反射的不同颜色光的可见度。因此,这种情况下,真实用户可能会面临较高的误拒率。在这些次优条件下,较低的置信度分数(如 50 或 60)可能更有助于实现 TAR 和 TRR 之间的正确平衡。
Rekognition Face Liveness 的设计
机器学习:Rekognition Face Liveness 通过机器学习和计算机视觉技术构建,涉及以下步骤:(1)活动检查要求用户将面部移入屏幕上的椭圆内,并在一组颜色序列显示时保持静止,前端 SDK 会将其录制为视频。 (2)视频被发送到后端 API,并通过一系列检查来验证是否成功完成。(3)一系列模型检查人脸是否为伪造,例如人脸照片、全脸 3D 面具或虚拟注入攻击。(4)如果上述任何检查未通过,或通过的置信度较低,API 返回的置信度分数将会降低。(5)对视频的不同帧进行分析以确保质量。质量得分最高的帧将作为人脸参考图像返回。(6)还会返回 0 到 4 之间的一系列可由客户配置的审计图像,以供将来审计之用。
性能预期:混杂差异可能要求不同的应用程序使用不同的置信度分数来实现所需的性能。以两个身份验证应用程序 A 和 B 为例。对于每个应用程序,用户首先使用护照风格的图像进行注册,然后使用实时自拍视频来验证自己的身份。这些实时自拍视频可能以不同的方式拍摄。例如,应用程序 A 可能是一款办公室内使用的工作应用程序,利用笔记本摄像头在光线良好的条件下拍摄用户的自拍视频,然后授予服务访问权限。应用程序 B 则可能使用安装在建筑物入口处的平板设备,在户外拍摄用户的自拍视频。应用程序 B 的方式可能会受到更极端的光照条件影响,例如强烈的阳光。由于 A 和 B 的输入条件不同,它们在相同的置信度阈值下可能会有不同的人脸活动检查误差率。因此,两者需要根据各自的使用场景设置适当的置信度阈值。
测试驱动的方法:我们使用多个数据集来评估性能。我们无法采用单一评估数据集衡量整体性能。这是因为,评估数据集会根据其人口构成、混杂差异量、可用标签的类型和质量以及其他因素而有所不同。我们通过测试包含真人用户自拍视频和欺诈攻击的视频评估数据集来衡量 Rekognition 的性能。我们选择一个活动分数阈值,使用 Rekognition 计算每个视频的活动分数,并根据阈值确定视频中的人脸是真实的还是欺诈攻击。 数据集中的群体可以由人口统计属性(例如性别)、混杂变量(例如面部遮挡存在与否)或结合两者来定义。不同的评估数据集因这些因素和其他因素而异。因此,TAR 和 TRR 因数据集而异。考虑到这一差异,我们正在进行的开发过程使用多个评估数据集来检查 Rekognition 的性能,并采取措施降低 TAR 和 TRR。
公平与偏见:Rekognition Face Liveness 的设计适用于所有人类面孔。为此,我们使用上面描述的迭代开发过程。在此过程中,我们使用数据集,涵盖在各种混杂差异下获取的不同人类面部特征和肤色。我们会定期对包含欺诈攻击和真实最终用户自拍视频的数据集进行测试,这些数据集拥有可靠的人口统计标签,如性别、年龄和肤色。总的来说,我们发现 Rekognition 具有很高的准确性。 例如,iBeta(一个获得 NIST 认证的实验室)使用其质量保证演示攻击检测(PAD)框架,对 Rekognition Face Liveness 进行了两项测试(一级和二级),测试包含一系列演示攻击和真实用户尝试。PAD 测试根据 ISO/IEC 30107-3 进行。在每项测试中,iBeta 都邀请受试者提供真实样本和冒充样本(演示攻击),并招募了不同年龄、性别和种族背景的受试者。在一级测试中,使用了 6 种不同类型的攻击,包括打印照片、3D 面具、智能手机上的照片和笔记本上的视频等不同类别。900 次攻击尝试的真实拒绝率(TRR)为 100%,置信度分数阈值为 50。在同一项测试中,300 次真实用户尝试的真实接受率(TAR)为100%,置信度分数阈值为 50。在二级测试中,使用了 5 种不同的攻击类型,包括硅胶面具、乳胶面具、3D 轮廓面具、3D 打印面具和 3D 动画软件。750 次攻击尝试的 TRR 为 100%,置信度分数阈值为 50。在同一项测试中,250 次真实用户尝试的 TAR 为 100%,置信度分数阈值为 50。
可解释性:如果客户对 Rekognition 返回的自拍视频活动置信度分数有疑问,我们建议客户使用 Rekognition 返回的参考和审计图像来手动查看人脸图像中是否存在真实用户或欺诈攻击信号。
稳健性:我们通过多种技术最大限度地提高稳健性,包括使用涵盖许多个体中多种差异的大型训练数据集。客户必须根据其使用案例设定对虚假接受率和虚假拒绝率的预期,并测试工作流程性能,包括他们对内容相似度阈值的选择。
隐私与安全性:Rekognition Face Liveness 处理用户自拍视频,并将活动分数以及视频中的精选画面返回给客户,用于人脸匹配、年龄估算或审计跟踪目的。客户之间绝不会共享输入和输出。客户可以通过 AWS Organizations 或我们可能提供的其他选择退出机制选择退出有关客户内容的培训。有关更多信息,请参阅 AWS 服务条款第 50.3 节和 AWS 数据隐私常见问题。有关特定于服务的隐私与安全性信息,请参阅 Rekognition 常见问题的“数据隐私”部分和 Amazon Rekognition 安全文档。
透明度:将 Amazon Rekognition Face Liveness API 纳入其工作流程的客户应考虑向最终用户和其他受应用程序影响的个人披露其使用机器学习和人脸分析技术的情况,并且支持最终用户能够提供反馈以改进工作流程。在其文档中,客户还可以引用此 AI Service Card。
治理:我们采用严格的方法,以负责任的方式构建我们的 AWS AI 服务,包括在设计阶段融入负责任的人工智能的逆向工作产品开发流程,由专职的负责任人工智能科学和数据专家设计咨询和实施评测,执行例行测试,与客户共同审查,以及进行最佳实践开发、分发和培训。
部署和性能优化最佳实践
- 工作流程设计:任何使用 Rekognition Face Liveness 的应用程序的准确性都取决于客户的工作流程设计,其中包括以下几个因素:(1)预期混杂差异水平,(2)活动置信度分数阈值的选择,(3)用户设备屏幕、摄像头和网络的特性,(4)使用最新版 Liveness SDK,以及(5)不断进行测试,以考虑随着时间的推移而发生的任何变化或偏差。
- 混杂差异:在录制自拍视频的工作流程中,应采取措施来保持最佳的照明条件,既不能过于明亮,也不能太暗。如果照明条件不理想,应该引导用户在不同的区域进行活动检查,这样可以降低误拒的可能性。此外,工作流程应当建立明确的政策,规定可接受的自拍画面质量,并定期对自拍画面进行抽样检查,以确保符合这些政策。对自拍画面的随机抽样可以帮助监控和维护工作流程的质量。
- 活动置信度阈值:为应用程序设置适当的活动置信度阈值至关重要。否则,工作流程可能会错误地判断真实用户的存在(导致误接受),或反之(导致误拒)。误接受的影响可能与误拒有所不同。例如,与零工经济工作者的交付前验证相比,金融科技的用户注册可能需要更高的置信度阈值。要确定合适的活动置信度阈值,客户应积极开展有代表性的实际测试,并确定满足其需求的正确置信度阈值。
- 用户设备屏幕、摄像头和网络的特点:用户设备必须满足 Rekognition Face Liveness 文档中提供的最低规格要求。设备屏幕正上方应装有摄像头。设备应完好无损,屏幕完好无损,摄像头正常运作。用于实时传输自拍视频的 Wifi 或蜂窝网络应支持所需的速度和延迟。
- 最新 SDK:AWS 定期更新 Face Liveness AWS SDK(用于客户后端)和 AWS Amplify SDK(用于客户端应用程序)的 FaceLivenessDetector 组件,以提供新功能、更新 API、增强安全性、修复错误、改进可用性等。我们建议您保持 SDK 处于最新状态,以确保功能的最佳运行状态。如果您继续使用旧版本 SDK,则出于可维护性和安全原因,请求可能会被阻止。
- 人为监督:如果客户的应用程序工作流程涉及高风险或敏感使用案例,例如影响个人权利或基本服务访问权限的决定,我们建议酌情将人工审核纳入应用程序工作流程。人脸活动系统可以充当工具,减少全手动解决方案所产生的工作量,并且支持用户快速审查和评测可能的欺诈手段和真实用户拒绝。
- 一致性:客户应针对如下方面制定并实施策略:人类如何将活动置信度阈值与自己的判断相结合来确定活动性。这些策略应在所有人口群体中保持一致。
- 性能偏差:客户提交给 Rekognition Face Liveness 的自拍视频种类的变化可能会导致不同的输出。为了应对这些更改,客户应考虑持续测试 Rekognition 的性能,并在必要时调整工作流程。
更多信息
- 有关服务文档,请参见 Rekognition、Face Liveness、Face Matching Service Card。
- 有关身份验证工作流程设计的示例,请参阅使用 Amazon Rekognition 进行身份验证。
- 有关帮助优化工作流程,请参阅 AWS 客户支持、AWS 专业服务团队、Amazon SageMaker Ground Truth Plus、Amazon Augmented AI。
- 如果您对 AWS AI Service Card 有任何疑问或反馈,请填写此表单。
词汇表
公平性和偏见是指人工智能系统如何影响不同的用户亚群(例如,按性别、种族)。
可解释性是指拥有理解和评估人工智能系统输出的机制。
稳定性是指拥有确保人工智能系统可靠运行的机制。
隐私与安全性是指保护数据免遭盗窃和泄露。
治理是指采用流程在组织内定义、实施和执行负责任的人工智能实践。
透明度是指交流有关人工智能系统的信息,以便利益相关者能够就其是否使用该系统做出明智的选择。