之前介绍了基本的风控对抗思路，今天笔者再来给大家分享一下风控引擎的设计实现思路。

本文将从两个部分来对风控引擎进行拆解：

1. 风控引擎的演进历程
2. 风控引擎的设计思想

一、风控引擎的演进历程

1. 硬编码阶段

通常在一个业务的发展初期，所有资源的投入重点都在用户量或者流量上，在这个阶段，因为用户量级较小，所以黑产对业务的关注度比较低，黑产的变现效率也比较低。

在硬编码阶段，所有策略上线都是通过RD开发然后部署在线上的，这种形式就会导致策略的开发周期很长，并且在线上之前无法有效预估效果，上线之后对策略准召率也难以掌控。所以在这个阶段整个策略对抗是一个极其低效的过程，但是因为业务阶段比较初级，所以风险大致还都可以控制住。

2. 初级产品化阶段

随着业务的发展，用户量开始变多，业务对黑产的价值开始体现，在这个阶段开始就会有黑产涌入进行攻击，当攻击的情况达到了一定的程度，我们就会发现，原有处于“硬编码阶段”的策略体系因为自身的低效性，很难做到及时拦截黑产的攻击。

所以，这个阶段业务的负责人会自然而然地想到——能不能把原有的硬编码模式做得灵活一些。

这个时候，就会通过一些产品设计手段将原有的策略体系产品化，这个阶段我们把他称之为“初级产品化阶段”。

在初级产品化阶段，通常做的事情都是将原有的策略从代码中迁移出来，展示在风控引擎中。并且能够简单的修改一些策略的参数以及做一些策略上下线配置。

举个例子，比如“判断用户1天内发帖量是否大于5”，这里“发帖量”就是可以配置的参数。虽然在这阶段实现了一些基础的配置化，但是通常在这个阶段，策略依然是一条一条相互独立并行执行的，绝大部分的策略逻辑依然是由RD直接进行开发部署到风控引擎中的。

3. 成熟产品阶段

当业务进入到真正的高速成长期，或者从成长期进入成熟期的时候，业务会变得空前庞大，用户量会达到顶峰。这个时候业务对于黑产的吸引力也会同时达到顶峰。我们会发现黑产攻击已经变成每天都会发生的事情，跟吃饭喝水一样自然。

因为黑产的攻击时刻不停，虽然我们实现了部分策略参数的配置，但是我们的需求仅仅通过一些阈值的调整已经无法真正满足了。我们在风控对抗上衍生出了很多的想法，比如：

• 我们能不能不依赖技术直接自己实现大部分的策略逻辑？
• 我们能不能让策略实现与或非关系？
• 我们能不能有一些能力支撑特征的有效产出？
• 我们能不能提前预知风险的发生？
• 我们能不能提前预测策略的效果？

这个时候我们会发现我们会搭建一个体系化的解决方案，这个阶段我们把它称之为“成熟产品阶段”

在这个阶段，整个风控引擎已经能满足高强度的风控对抗需要，并且开始通过风控引擎本身衍生出更多的边缘安全产品。通常一般的公司风控引擎就会停留在这个阶段不会再有大幅的变化了。

4. 中台化产品阶段

绝大部分公司的风控引擎都不会进入这一阶段，只有一些业务十分复杂的集团企业才会在原有的风控体系中衍生出这种需求。

一般来说，在企业主营业务达到稳定期之后，企业一般会寻求其他方向发展的可能性，新业务就会跟随着需要不断产生。但是原有的风控体系都是围绕着主营业务展开的，与原业务耦合通常比较严重。这个时候在原有的成熟产品下，很难快速的将所有的风控能力移植到新的业务场景中，这个时候就会出现主业务风险可控但新业务风险失控的现象。

为了解决这样的问题，风控引擎就必须要将所有的功能进行高度抽象，实现低成本复用，完成对企业新增业务的安全赋能。这个阶段我们称之为“中台化产品阶段”

在这个阶段的风控引擎更像是一个ToB的商业产品，因为想让业务方更好的解决风控问题，就必须要覆盖绝大部分业务的安全需求，并且在体验上尽可能的优秀，让业务更简单的理解和掌握风控对抗。如果类比的话，此时的产品就像是一个第三方安全公司提供的服务，所有的事情都是为了让极低成本的解决风控问题变成现实。

以上就是风控引擎演进的常规过程，一般都是跟随着业务需求自然而然发生的迭代和进化。下面我们来看一下一个风控引擎在功能设计上的思路应该是什么样的。

二、风控引擎的设计思想

想设计一款好的风控引擎，我们需要知道风控的核心要点有哪些。

风控引擎的核心点：

• 满足高效率的策略迭代
• 策略尽可能的难以突破
• 尽可能的降低对正常用户的影响
• 充分的运营支撑
• 确保服务稳定可靠

1. 策略管理模块的设计

策略的设计实现直接影响着策略的迭代效率和是否容易被突破。

特征的设计（有些人称作变量）：

要实现迭代效率足够快，要求策略的底层逻辑特征要进行原子化的抽象设计。

什么叫做抽象，我们举一个例子：

我们有这样一个策略：用户手机号码是136开头并且注册时长小于1天则对用户发起验证码挑战，可以看到136手机和注册时长两个特征组成了这个策略的识别逻辑。

那我们如何让这个策略变化起来更灵活呢？我们可以把这个策略拆成两个特征：

检测用户手机号开头（自定义：136）+检测用户注册时长（自定义：24H内）

这个时候原来一个策略就变成了两个可配置的特征，这样一来，如果我检测170的号段也是可以直接实现的。但是这样依然不够灵活，难道我们只有检测手机号开头的需求么？并不是，我们应该更灵活地应用字段。我们还可以将这两个特征进一步抽象，由检测用户手机号开头+检测用户注册时长变为：

检测字段内容（以…开头：136，字段：手机号）+检测时间差（小于24H，字段1：注册时间，字段2：当前时间）

通过这样的抽象，我们尽可能的把核心逻辑保留下来，把其余的内容都参数化放到特征的配置中。

策略的设计（有人也称作规则）：

那我们该如何让策略更难以被黑产突破呢？我们知道逻辑越简单，特征越单一，策略越容易被绕过。逻辑复杂，组合特征，则绕过策略的成本就会增加。所以在策略上，我们需要每一个策略是一个复杂特征的集合，为了实现这种集合，我们需要在策略上实现特征组合的能力。

特征组合一般就是在特征之间实现与或非的逻辑运算：

• 与关系：满足A特征并且满足B条特征的时候才命中。例如：ip归属地在国外并且发帖城市在北京。
• 或关系：满足A或者满足B条件任意条件的时候命中。例如：芝麻信用分小于350或被列入失信人名单。
• 非运算：不满足A特征的时候。例如：A代表用户在黑名单中。那么非运算就是用户不在黑名单中。

实现与或非的逻辑运算与特征的组合其实比较简单，但是在前端交互时如何能高效的操作是比较复杂的，尤其是在非常复杂的特征组合下。推荐大家两种方案：

1. 简单的逻辑前端通过选择器进行选择，复杂的逻辑通过在文本框中填写表达式生成，两种方式可进行切换。
2. 通过评分卡设计实现特征组合和逻辑运算。这种见得比较少，在这里解释一下。这种方案是由用户将每个特征赋予一个分值，策略总分就是所有特征分值的加和。通过每个特征得分的控制来间接实现逻辑运算。

举个例子：

• 策略1：A与B。如果A特征命中得分50，B特征命中得分50。那么当策略得分等于100时策略命中。
• 策略2：A或B。如果A特征命中得分50，B特征命中得分50。那么当策略得分等于50时候策略命中

通过这样的方法，对策略得分和特征得分进行控制，就可以实现组合和运算。

策略状态的设计：

策略核心的业务状态有三种，分别是上线状态、预上线状态和下线状态。

其中预上线状态尤为重要，因为一切策略在上线产生影响之前都应该准确的预知效果才能操作上线，一旦评估不充分，可能在上线后对线上产生非常严重的影响。所以预上线状态是确保策略效果的一个重要状态。在预上线的状态下，风控引擎应该有足够的能力去预测策略上线后的效果。常用的方案有两种：

1. 是将历史已知明确结论的数据重新灌入风控引擎，以此来证明策略对已知数据的准召情况。这种方法通常需要将历史流量做镜像备份，已保证重新灌入时数据不会发生偏移。但是这样的方法也有一些弊端，就是当攻击行为与历史行为有着大幅差异的时候，准召率的判断可能出现不准确的情况。

2. 是将预上线后命中的数据进行随机抽样，比如抽取5‰的数据进行离线验证。这种方法因为使用的是真实的线上数据，结论比上一种更加精准，但是对数据的核验成本非常高，很难快速的产出结论。

所以建议上面两种方式混合使用，通过第一种方案做日常策略维护。当策略的召回数量非常大时（代表对线上产生了足够的影响），这个时候做第二种，确保策略上线的严谨。

进行策略的执行顺序：

在资源充足的前提下，一般来说策略的执行都是并行执行的，但是在一些情况下也会要求策略有先后的执行顺序。比如有些策略会依赖一些第三方数据源，这些数据在调用的时候就会产生成本，我们常见的有银行卡四要素、手机三要素等等。

所以有的时候为了节省成本，会将这些策略执行顺序后置，当前面的策略已经足够产出明确的结论时（比如拒绝这次申请/发帖等），就无需执行后续策略。在运算资源上也是同理，会优先执行对运算资源消耗小的策略。

2. 处置模块的设计

处置的设计，很大程度的决定了风控对正常用户产生的影响。

之前在另一篇文章里讲过去做处置时的一些基本思路，大家可以参考《风控对抗中的常规特征及处置选择》，在这篇文章里主要讲处置还有哪些需要关注的重点。

优先级：

在执行处置的时候，难免会遇到同时命中了多种处置方式的情况。这种时候，我们需要去确认以哪个执行为准。一般来说，越是处罚严重，优先级越高。严重的处置方式会覆盖较轻的处置方式。比如封禁用户和删除帖子同时命中，会执行封禁用户。

留证：

当我们对用户进行处置之后，因为所有的风控策略准确率不可能达到100%，这样一来就一定会产生用户申诉的情况。所以我们每一次的处置操作，都应该尽量做到留证全面。

当用户申诉的时候，我们可以很清晰地看到每一次处置都是因为什么样的问题而产生的。常见的留证实现方式是数据快照或者内容快照。数据快照可以更好的复现行为，内容快照可以更好的复现内容。留证模块准备的越充分，风控的每一次处置就会越有底气。

反馈与出口：

用户对处置的感知主要是通过的我们的通知下发，所以确保处置信息向用户的有效传递是尤为重要的。越是对用户影响大的处置，越是要多渠道分别下发，确保用户可以接收到信息。同时用户在被处理之后通常会产生为什么处理我的疑问，那么处置相关的话术也是需要用心设计的。因为风控的特性，很多的特征不能直接对外明示，特征选取的越偏向行为，越复杂则越难以向用户解释，所以话术的设计要尽可能的既解决用户的疑惑，又保护核心识别逻辑。

对于部分用户而言，误判和话术的不清晰一定会导致用户体验变得极差，所以针对误判的出口是非常必要的，所有的判罚都应该有有效的出口和流程去解决用户被误判的问题，只有实现了这样处置闭环，才是相对完整的产品体系。

3. 数据运营支撑产品模块设计

一款好的风控引擎仅仅有策略对抗的能力是不够的，完善的运营支撑同样重要。整个运营体系可以从风控前，风控中和风控后三个阶段来搭建。

风控前：

简单来说，在真正的做对抗之前，我们关注的就是风险何时出现。所以风控前的运营支撑应该是一个比较完备的预警体系。预警体系的作用就是让风险尽可能快的被定位。

常见的预警监测项可以提供一些给大家参考：

业务的产生量、 过风控的量、出现频率高的top资源（IP、手机号、UID、设备等）、出现频率高的top内容（文本、图像、音频、视频）、数量异常的top群组等等

风控中：

在做对抗的时候，运营支撑的设计考虑的就是如何辅助策略人员快速的产生决策。所以风控中的支撑在产品表现上更像是一个数据大屏。这个大屏可以很好的展示一个资源从在业务中出现到目前为止的全貌。一个资源的全生命周期的行为或内容表现都可以很好的在这个模块中进行展现，并且在此之上，提供一些简单的统计和分析来将特征提取的过程尽可能的缩短。

风控后：

在策略上线之后，我们更应该关注的应该是策略在线上产生的效果和影响。所以风控后的运营支撑体系应该是个效果的评估体系，通过各种核心指标的展现辅助策略人员优化策略。

常见的一些评估指标可以给大家参考：

污染率（有问题的数量/总量），策略的命中量，策略的独立命中量（用来说明某条策略的不可替代性），策略的准召率、策略造成申诉的量等等。

4. 系统的稳定性

跟所有系统一样，风控引擎的稳定性也是非常重要的，在一些比较大的企业中，风控引擎一天承载的检测量级甚至可以达到上百亿次。在如此庞大的业务量级中，稳定性就变成一个必须要考虑的问题。

怎么解决稳定性问题偏技术实现，这里就不做具体的介绍。但是发生异常后的方案选择应该比较清晰和明确。

拿两个场景举例子，比如当用户发帖时，如果我们风控检测超时或发生异常，我们可能会选择放直接放过这个帖子或者直接将帖子推入人工审核。这个时候因为用户一次发帖动作带来的风险有限，所以在面对异常情况的时候，我们通常就会不处理来避免对用户产生不良的影响。

但是如果用户在app上申请一个小额贷款，这个时候检测环节出现异常，因为这个结论会直接跟资金挂钩，所以我们通常会进行重试，如果重试依然不通，我们可能会选择拒绝这次申请操作。

所以在面临不同的业务场景时，我们应该能清晰的判断业务对风险的接受程度，通过这个来设计兜底策略。

以上就是风控引擎的演进历史及基本的设计思路，本来还想分享一下风控引擎中台化的产品思路以及对这个产品后续发展的一些思考和设想，但是因为时间原因，这部分就放到后面有时间再说吧。

希望这篇文章能对大家理解风控和风控产品有所帮助~就这样。

本文由 @gology 原创发布于人人都是产品经理。未经许可，禁止转载

题图来自 Unsplash，基于 CC0 协议