复杂风控场景下，如何打造一款高效的规则引擎

#2

思路总结

在确认清楚挑战和解决方案之后，规则引擎的整体建设思路就已经形成了。现今，规则引擎随着业务的快速扩张，由一个内部系统逐渐发展为服务多个风控团队的公共平台。

从初期主要围绕风控防控痛点进行搭建的表达式服务包，升级到配置化平台，在配置效率和执行效率也得到了很大的提升。同时，随着人工智能技术的应用和风控对抗进入白热化，规则引擎也将从配置化快速迭代至自动化、智能化。

1.确定核心快速论证、快速落地

执行层：通过场景获得一堆规则集合，规则执行完成后将其结果和对应的决策返回。

计算层：在规则执行时会进行其构成因子计算。

2.根据角色，进行定向提效

（1）风险用户处理提效（风险用户）

业务已经可以实时获得风控的决策，但发现风险用户会在很多场景下重复攻击。对这类用户的处理，除了对当次行为阻断，还要阻断其未来的行为，因此就有名单管理的诉求。我们通过与名单库的联动，提升该类用户的处理效率。

例如：在美团金融项目场景下，严重逾期的用户会加入禁贷名单，再次申贷时取消其贷款资格。

（2）业务接入提效（业务方）

除了上面介绍的统一接入外，还有一种常见的情况：业务无法在发起请求时就将执行所需要的全部参数准备好，此时就需要引擎能主动获取外部数据。针对这类情况，规则引擎通过数据接口的方式实现了外部数据的补充，在策略执行时根据计算需要动态获取相关的参数。在实现与外部数据联动的功能后，大大降低了使用规则引擎业务方数据准备阶段的压力，从全部参数准备简化为仅提供核心参数即可，剩余参数按需引擎自行调度即可。

（3）策略管理提效（产品）

策略产品是规则引擎的主要用户，主要的工作流程是围绕策略管理、分析、验证进行提效。如何管理大量的规则和应用场景？怎样快速验证策略有效性、评估误伤率？客诉反馈问题，如何快速还原规则命中情况？针对这些维度，我们分别提供不同的产品功能进行提效。

在策略管理层面，可通过规则组方式、因子工具等，进行同类规则集合的管理、打包和复用。

在规则分析层面，可通过实时查询规则的执行详细数据和将规则执行流程进行回放提升分析效率。

在策略验证层面，提供标记、双跑和回溯提升策略验证速度。

（4）工程效率提效（工程师）

复杂的逻辑且具有通用性就可以对特征逻辑封装，避免工程师重复进行逻辑开发工作，释放出的开发资源可以进行其它维度的提效。

（5）算法/模型接入提效（算法工程师）

当对抗升级时，策略的产生者由人变为算法/模型。而机器的生产效率远远高于人，人工搬运算法/模型会成为迭代效率的瓶颈，怎样跟算法、模型平台进行快速联动呢？最简单、快速的方式就是使用引擎提供的外部数据联动方式，将模型结果包装成数据接口使用。但在实践过程中，我们发现模型的出入参数较多且存在变化，整体的配置化效率低，模型应用和迭代频率受限制。公司内部提供的深度学习还是算法工程平台，目前主攻计算、训练等场景，在上下游应用提供标准化的数据产出，但无法同类似引擎的平台对接。

因此，仅聚焦在引擎与算法平台的联动上，可通过建设调度模块实现：1.训练样本预处理-->2.算法平台对接-->3.自动化生成接口-->4.自动注册接口/策略至引擎-->5.评估任务启动-->6.评估结果处理（策略上下线、样本数据沉淀）-->1.训练样本预处理的闭环流程。

3.发现问题、横向扩展、兼容更多场景

在实时引擎已经覆盖的逻辑基础上，我们引入新的封装逻辑-个体因子，全局因子实现SQL语句的配置化管理，进而实现批量累计、聚合特征的计算，比如：近一年某商家的平均下单金额，近30天商户大盘下单均值，标准差等批数据的复杂逻辑。并基于Spark和实时引擎底层，实现多流和批数据的处理，解决上述场景无法处理的一些问题。

4.业务实践结果

• 交易安全
  

策略产品在日常工作中，通过对业务分析发现风险、挖掘风险特征并应用在策略中。通过Zeus实现策略的部署和应用，大大降低了业务风险，提升风险防控效率。例如：在某业务地推场景中发现B、C端联合刷单风险，以返利、送赠品收到诱骗下单。

• 金融安全

金融风控主要有反欺诈和信用安全。反欺诈同业务安全在策略形态上相同，都是判断有无风险，在决策结果上是通过和拒绝。因此，通过普通决策即可满足业务需求。

但信用安全会比前两者复杂一些，在决策上，除了通过和拒绝外，对于通过的请求要进行分层实现金融的差异化定价。因此，需要在规则引擎中引入更多功能，来满足业务需求。主要包括：

路由场景：可支持多层，决策流模式，即一堆规则的集合，支持按照逻辑进行分流，满足指定条件可以指定走向在每个节点进行条件设置，实现最终流向。例如：对于某分期场景用户申请一笔贷款，需要经过欺诈识别、信用评估后方可给出最终的额度、定价。

决策衍生参数：适用于复杂的多级路由决策场景Key-Value型数据，在决策中指定衍生参数信息从而在路由场景中产生全局传递变量，比如：流转过不同的场景需要将用户进行等级分类。

决策附加信息：适用于复杂决策场景Key-Value型数据，在决策中指定附加信息从而实现更多决策信息的计算及返回，比如：加入风控名单库，加入什么风险类型、风险等级、名单类型。

#3

未来发展与思考

目前规则引擎正处于配置化阶段，正在向自动化、智能化的阶段发展，从而不断提升策略的管理和迭代的速度。但业务间的智能化诉求和进程不同，平台可以提供更多集成托管服务，从而提升各业务的智能化覆盖度。

其次，引擎仍然存在无法处理的几个问题：

一些长时间周期特征无法快速应用的问题，例如近一年的时间周期。如何将离线引擎和实时引擎在特征计算上组合，实现特征的快速生产、验证和应用，从而扩展引擎的计算能力范围、提升风控业务的对抗效率。

当前引擎的接入对非复杂逻辑需求的业务就比较重。而接入成本是各业务接入时重点评估的因素，如何实现快速、低成本的业务接入（包括技术接入和人员操作接入），考虑提供模块化的引擎计算服务能力适用于各类业务诉求，实现按需接入，比较“臃肿”的全局接入会更快速和便捷。但这种在引擎侧怎样更好地管理这些模块，也是一个挑战。

最后，业务流量和策略的增长速度仍在高速增长，引擎的稳定性和策略管理效率也需要持续提升。

#4

踩过的坑

1.如何实现产品功能高聚合架构上低耦合

例如：在用户修改生产策略时的强制更新流程优化项目中 ，就涉及了这个问题。在产品功能上用户修改策略-->双版本策略并行执行-->两版本数据核验-->修改完成；但在系统架构上，上述的产品流程就产生了系统架构高耦合，即生产修改双版本问题，配置层、执行层、计算层高度耦合。项目一期上线后在性能上、后续功能扩展性上都有瓶颈。随后，技术项目优化配置层的缓存模式，采用增量更新方式。产品功能上增加用户进入修改模式后修改。重新立项后，实现了用户修改流程闭环、系统架构上仅配置层兼容双版本，执行层和计算层无耦合。

因此，在产品功能设计上除了用户闭环操作外，还需要考虑是否低耦合。在技术优化时需要前瞻性的开展去耦合项目。

2.如何平衡系统复杂度与业务需求

• 定：重新定义“定制和通用”。在现实中有些定制化需求其实是业务速度已经远远领先于其它业务，所有需求看上去是定制化，实际上是未来可预见性的问题。

• 判：将业务需求进行分类，判断需求是针对主干流程还是分支节点。

• 看Gap：需求同当前建设情况比对差距。
  

对于系统模块升级功能，可逐个完成。对于非系统功能，可通过提供公共对接服务的外挂来实现。

3.特别需要“防呆”设计

4.产品功能最佳实践的意外惊喜

（1）规则组功能建设初期目标是实现规则的高效管理、复用。在A业务场景基于规则组除实现规则的高效管理、复用外，还实现了决策计算。但这种用法在随着其业务的发展复杂度增加，已经不再利于策略高效管理，目前还在寻找更优的解决方案。

（2）累计因子的功能是将对多条请求进行计数或求和逻辑进行封装。B业务基于上述功能上还是实现了事件行为记录、多事件时序性累计和拦截行为的累计。目前在其业务下广泛使用并有效地识别了跨事件风险。

总结而言，做好业务定期应用回访和应用监控是非常有必要的。