【连载一】强对抗弱监督场景下的实时风控在极验决策引擎中的应用

持续更新：这是极验汪豪老师在Datafun平台上的精彩公开演讲的文字记录。汪豪老师目前负责设计和搭建极验验证码的全面防控体系，并负责其整体运营，统筹前后端研发，逆向，策略，模型在风控中的应用。

风控这行业很多时候都在打信息差，稍微一点东西都藏着掖着，所以这个行业标准就比较破碎。而我们持续进行的宣传或者是产品设计，都是希望将风控这种行业进行了标准化，这在以前是难以想象的，而标准化的好处就是在于可以更好的衡量效果，聚焦业务上的内容。这样企业才能减少不必要的且重复的各种风控建设，浪费各种运营和试错成本。

本文字稿的第一部分，详细阐述了数据驱动的决策系统和透明化流程，旨在应对业务安全领域的快速变化与挑战。我们将其分享出来，主要是想把如何识别异常这种逻辑更加直观的呈现给客户，鼓励行业从业者参考这些前沿的防御策略和实践经验。

演讲原文PPT共60页，请添加极验EVA助手微信获取，微信号：Geetest_1024

作为一家以验证服务为核心的公司，我们在过去12年中，协助客户在多种风控场景中广泛部署验证码。

面对黑产对抗的日益激烈，我们开发了基于图像、答案、设备环境检测、隐藏式问答和附加标记等多种策略，有效增强了对抗能力。

然而，对于快速发展的独角兽企业、新涌入的高流量业务以及缺乏风控历史数据的场景（我们总结为强对抗下弱监督场景，指没有充分的风控判定维度、标签和数据供以建模的条件下，且存在激烈黑产对抗的环境），我们仍面临挑战。

特别是在短信验证码方面，近年来短信盗刷事件频发，导致登录和注册场景下的需求迅速变化，往往他们会很急促地来找到我们，这对我们的风控策略提出了更高的适应性要求。

我们需要迅速适应这些的场景。我总结了这些场景的几个关键特点：一是黑产手法变化迅速；二是风控需要对巨量的请求进行决策，对性能的要求极为严格；三是客户期望在接入过程中尽可能减少对业务的干扰，例如很多公司会有openRecity通过网关层面进行介入的做法，而大型公司更倾向于从平台层或基础设施层进行接入，但这往往伴随着较高的接入成本；

以上三个因素相互交织，引发了一系列的挑战。这些挑战导致我们的代码运营和分析工作变得碎片化和离散化，使得整体管理和风险应对变得更加困难。

一、风控痛点分析

在强对抗弱监督场景中，会放大这些痛点。其根本原因是这个场景的对手组织严密，分工明确，善于伪装，调整速度快。上述痛点导致了如今的风控现状，使得策略、代码需要频繁变更，风控运营，策略，开发，测试，运维疲于应对。

长期下去，我们只能扮演救火的角色，将长期受制于人，失去这场战争的主动权。

二、以注册登录场景为例，我们的解决方案

针对这种情况，我们重新审视了业界已经成熟的风控体系，并将我们常用的方法与行业内的通用策略相结合，通过极验业务决策引擎(可复用编排决策系统)，基于符号智能和实时计算的风控设计，以灵活编排为核心，以应对这些问题。

以注册场景为例，我们探讨这套体系的运作机制。注册场景的特殊性在于，客户接入时我们能够获取的信息通常较为有限，主要依赖于我们积累的IP数据和客户共享的画像库进行查询，而其他可用信息则相对较少。

特别是我们发现许多强对抗场景，如注册或短信盗刷登录，尤其是在H5页面或小程序平台上，设备与环境检测往往不够强大，导致我们能收集的数据通常比较受限。

我们在注册场景识别并总结了以下异常行为：异常高的IP访问频率，尤其是那些源自特定地区的IP；在非活跃时段，例如凌晨，业务遭遇大量请求，这要求我们进行迅速响应；尽管业务主要面向国内市场，却遭遇大量来自国外的IP请求；IP注册时间间隔异常，要么过短要么过长，且呈现规律性，这往往预示着黑产活动的存在。

针对这些情况，我们升级了原有只是基于标签、画像、模型、规则，且固定死板、不透明的策略风险决策系统，根据数据流条件进行可视化灵活编排，把所有孤立的策略形成可解释的立体风控体系，实现持续监控和防御。

三、对比传统风控的优势

传统的决策引擎往往像是一个不透明的黑盒。这样就导致在激烈对抗的场景中，一旦有漏检和误封，只要是被问及具体的处理流程。就很难回答，因为可能规则设定者也不清楚。

为了满足客户对清晰解释的需求，我们打造了一个透明的白盒系统。我们的流程通常始于线条流程白名单的设定，将白名单的判断逻辑从传统的规则引擎中独立出来，转化为可封装的函数，并通过用户界面进行模块化组装。通过这样的方法，结合白名单、黑名单以及指标计算，我们能够输出最终的风险决策结果。

我们这样做后，让客户的安全团队可以向运营团队全面展示防御策略，增强透明度和信任，并作用于规则高效的迭代进化。

四、规则流程设置‍‍‍‍‍‍‍‍‍

让我们再次聚焦于账号注册场景，在请求阶段，我们仅能获取到IP地址和手机号作为样本数据。在白名单验证环节，我们执行自定义函数进行查询以确定结果。如果白名单验证成功（即返回值为true），则流程立即结束。若样本不在白名单中，我们则继续进行黑名单的检查。同样，如果黑名单检查也未命中，我们将进入下一步，执行指标计算。

在指标计算过程中，我们会利用特定函数对IP地址进行了操作：一方面用于计算最近一分钟内的请求总数，另一方面则统计在这一分钟内有多少不同用户的请求。

此外，我们还考虑了一个固定参数，即注册场景的常量值，也就是在特定场景下，近一分钟内有多少个不同的IP地址。在此过程中，我们还整合了IP地理位置函数，以便基于地理位置信息进行筛选。最终，这些数据将在决策表中汇总输出。这就是我们构建的防御体系。

采用这种表示方式，团队成员可以更直观地把握整个流程，不再需要像过去那样详尽地阐述规则的优先级，因为流程图上的连线已经清晰地指示了各个步骤的先后次序。

五、指标计算和仿真测试

我们首先考虑白名单，其次是黑名单，最后进行相关指标的计算。显然，我们构建了一个较为严格的评估场景，在此场景中，我们优先解决误封问题，其次是漏封问题，对各种模式进行时间窗口计数（指标计算），进而能够识别的异常情况。

在仿真过程中，我们记录每个节点的元数据，这样可以在界面上进行可视化展示，并对满足条件的项进行突出显示，这有助于与运营团队进行深入的沟通和解释。决策表中包含的其他名单、指标计算和地理函数，其设计宗旨是确保每个节点都能清晰展示其输入与输出数据。这种设计使我们能够便捷地在数据流中进行编排和调整操作。

我们汇总了注册相关数据，以生成最终输出结果。大家会发现，这些步骤在日常操作中十分常见。

六、阈值设定

通过构建这套系统，我们实现了规则流程的标准化，它适用于绝大多数（99%）客户场景。但是，确定基于这些计算的阈值仍是一项挑战。例如，在T1时刻，如果某个手机号通过IP1注册了多少个账号，为了解决这个问题，我们可能需要依赖历史日志，通过离线分析来计算这些阈值。

我们可以通过离线分析或线上计算来得出分位数，或者在确认异常行为后，甚至在紧急情况下，基于统计分位数来临时设定阈值。

鉴于我们已经部署了黑白名单作为初步筛选机制，任何由流程中条件触发导致的封禁操作都会被详细记录在日志中，以便我们精准追踪是由哪项规则触发的。若出现误封情况，我们可以将该实体添加到白名单，或者临时排除相关规则。得益于我们的热更新功能，我们能够迅速适应业务需求的变动。

未完待续...