全面了解风控决策引擎

为什么要写这篇文章，因为决策引擎对很多风控从业者来说都是绕不开的必学知识点，每一个与金融业务相关的技术框架，都需要一个成熟稳定的决策引擎组件来支持，而目前，只有15%左右的互联网产品，配置了这一工具。

本文旨在帮助大家认识决策引擎，包括前台规则配置与后台技术搭建，另外提供几个比较不错的轻量级开源引擎供大家进一步学习。

全文总计1.7w字，因内容较长，可分四部分进行阅读：

1.决策引擎介绍（适用人员：还没使用决策引擎的老板）

1.1 决策
1.2 决策引擎
1.3 应用场景
1.4 功能需求

2. 前台规则管理（适用人员：业务、分析、模型、决策）

2.1 平台介绍
2.2 功能介绍
2.3 使用流程
2.4 规则设置建议

3. 后台引擎框架（适用人员：模型、开发、架构）

3.1 引擎框架
3.2 核心组件
3.3 扩展组件
3.4 执行流程

4. 决策引擎调研（适用人员：有开发需求或者学习需求）

4.1 开源决策引擎
4.2 商用决策引擎
4.3 决策引擎项目

drools
radar
urule
sparkling logic

本着对读者负责的态度，笔者行文时尽可能做到以下几点：结构完整、内容真实、逻辑清晰、重点突出、删繁就简，用关键词、数据、配图和案例体现决策引擎的定义优势、应用方法、框架流程等。

另，感谢开源引擎radar开发者“飞虎”、信数风控引擎老师“海棠”、maze开发者张宁以及drools社群对笔者的指导和支持。

注：文中内容，如有侵权处，请联系笔者删除，感谢支持。

1.决策引擎介绍

1.1 什么是决策

决策，指做决定时所用的策略或方法，是人们为各种事件出主意、做决定的过程。它是一个复杂的思操作过程，是信息搜集、加工、整合最后作出判断、得出结论的过程。在消费金融业务场景中，决策主要指技术人员、业务人员、管理人员共同参与制定的面向整个用户信贷生命周期各环节的策略规则。

1.2 什么是决策引擎

1.2.1 早期规则模型

传统的风控规则模型主要内嵌在后台代码中，直接用硬编码的方式实现数据的获取、规则的定义、风险的判断。

伪代码如下：

if (StringUtil.isBlank(fieldA)
    || StringUtil.isBlank(fieldB)
    || StringUtil.isBlank(fieldC)
    || StringUtil.isBlank(fieldD)) {
    return ResultDOFactory.createResultDO(Code.PARAM_ERROR, "门店参数缺少必填项");
}
if (fieldA.length() < 10) {
    return ResultDOFactory.createResultDO(Code.PARAM_ERROR, "门店名称长度不能少于10个字符");
}
if (!isConsistent(fieldB, fieldC, fieldD)) {
    return ResultDOFactory.createResultDO(Code.PARAM_ERROR, "门店xxx地址、行政区和经纬度不一致");
}

优点
当规则较少、变动不频繁时，开发效率最高。
稳定性较佳：语法级别错误不会出现，由编译系统保证。
缺点
规则迭代成本高：对规则的少量改动就需要走全流程（开发、测试、部署）。
当存量规则较多时，可维护性差。
规则开发和维护门槛高：规则对业务分析人员不可见。业务分析人员有规则变更需求后无法自助完成开发，需要由开发人员介入开发。

1.2.2 业务定制引擎

基于特定业务场景开发的定制引擎，可视为一种推理引擎。

优点
规则配置门槛低：视图和引擎内部数据模型完全贴合绩效业务模型，因此业务分析师很容易上手。
系统支持规则热部署。
缺点
适用范围有限：因为视图和引擎的设计完全基于特定业务模型，因此很难低成本修改后推广到别的业务。

1.2.3 通用决策引擎

通用决策引擎由推理引擎发展而来，是一种嵌入在应用程序中的组件。实现的功能包括：将业务决策从应用程序代码中分离出来，使用预定义的语义模块编写业务决策，接收数据输入，解释业务规则，并根据业务决策做出业务规则。

简单点，可以理解为：

决策引擎特点：

决策引擎将复杂的业务逻辑从代码中剥离出来，可以显著降低业务逻辑实现的难度，降低实现复杂业务逻辑的组件的复杂性，降低应用程序的维护和可扩展性成本，；
剥离的业务规则使用决策引擎实现，可以使多变的业务规则变的可维护、易维护；
配合决策引擎提供的良好的业务规则设计器，不用编码就可以快速编辑复杂的业务规则；
即使是完全不懂编程的业务人员，也可以使用决策引擎来定义复杂的业务规则；
业务系统运行过程中难免会发生业务规则变化的情形，有了决策引擎，业务规则部分采用决策引擎实现，这样在系统正常运行的情况就可以利用决策引擎对业务规则进行修改，从而实现业务规则的随需应便。

决策引擎功能：

可以看到，常用决策引擎在传统风控决策的基础上，提供更加丰富的功能，包括：

层次更加丰富的逻辑运算
包含规则、评分卡、模型、表达式、决策流等
个性化业务场景事件管理
资源包
规则配置
阈值管理
标签管理
可视化编排
决策结果分析
规则监控
模型分析
模型报告
复杂决策
决策流
丰富的特征变量与场景识别

核心技术与挑战：

在目前围绕大数据、大数据决策为核心的风控技术体系中，整体的数据量达到一定水平，存在的挑战将会是数据的稀疏化。随着风控业务覆盖的行业越来越多，平台间的数据稀疏问题就越明显。

此外，对于大数据来说，具有数据和大数据决策，却没很稳定的落地平台也不行。大数据应用要做到完整，还需要符合以下要求的平台：

容纳量：能容纳特别多的数据；
响应：任何决策都能实时响应；
并发：在大量数据并发时也能保持调用。

1.2.4 未来发展趋势

更高阶的风控决策引擎，在现有的风控决策引擎上融入了自言语言处理平台、流计算平台、实时预警、深度学习、可视化科学计算等，提升了现有决策引擎的算力和处理时效。

随着技术的革新，未来的决策引擎，会向着功能更加丰富，性能更加优良的风控实时决策系统演进。

1.3 应用场景

1.3.1 互联网金融风险决策

互联网金融行业是近期发展最为迅速的一个金融业务领域，而其中的风险控制更是整体业务体系的核心环节。互联网金融的门槛核心在于风控系统，面向C端客群的线上产品线，如消费分期、现金贷及信用卡代偿等业务方向，需实时支持大量业务的自动化处理，风控系统将承担贷前、贷中和贷后的风控评估、处理及预警的角色，极大地解放人工处理的瓶颈与效率。

根据设计好的风险模型和业务规则，实现商户和客户评分、评级；
根据不同渠道、不同产品的用户的申请信息、第三方数据、存量数据等，并结合设计好的业务规则，实现实时自动审批规则（拒绝、通过）的系统落地；
根据已有模型和规则，实现商户和客户的额度测算；
实现不同的催收策略配置，实现催收客户风险排序以及高危客户检测；
根据业务规则，实现贷后预警指标的落地。

业务规则的制定和变更，是贯穿于金融行业的各项业务环节中的重要任务之一。如：

资格审查
额度费率计算
信用评分评级
风险发现
积分管理
市场营销
渠道收费

这些业务中都有大量的规则，规则的来源包括：

政策法规
市场营销策略
产品合同
专家经验

1.4 功能要求

好的决策引擎产品甚至无需 IT 人员的参与就可以实现规则的变更，减少了维护的成本。同时决策引擎响应规则变更的速度相当快，1－3 天就可以完成，大幅度减少业务人员与技术人员的沟通成本，花更少的时间处理数据，加速业务扩展。

一个优秀的决策系统，应该具备以下几个条件：

1.4.1 灵活可配

易用性：改善用户体验，使业务用户能轻松编写规则，降低进入门槛。零基础简易便捷的配置多种复杂规则，实时高效管控用户异常行为；
安全性：风控规则完全由风控部门知晓和负责演进
高效性：实现快速实施，开发人员能够快速建模，与其他系统集成，提高工作效率；
兼容性：可以在各主流操作系统，中间件，浏览器，数据库上运行和使用；
平台化：与业务场景分离的通用规则引擎平台，一个平台可快速的应用在各个业务系统中；
可视化：规则设计器、打包测试工具，全部基于浏览器实现，所有的规则设计器皆为可视化、图形化设计器，通过鼠标点击即可实现复杂的业务规则定义，多条件组合也可以用图形方式展现。

1.4.2 快速启动

决策引擎目前已广泛的应用于金融行业的 IT 系统。配置好的规则模型可实时生效，如果涉及一般规则修改时，可做灰度部署。
简单的使用方式

1.4.3 高性能可用

应对海量业务申请，实现毫秒级审批
借鉴Rete等算法的优势，结合中式规则引擎的特点，开发一套自己的规则模式匹配算法，从根本上保证规则运行的效率，实现大量复杂业务规则计算时的毫秒级响应。

1.4.4 部署模式多样化

本地部署
（VA虚拟镜像/Docker容器）
嵌入式部署
JAVA/.NET，API调用
云端部署
Saas云

1.4.5 支持外部多方数据源调用

支持各种数据源，可自定义增加删减
引擎按需动态调用外部数据
支持RPC远程函数，由决策节点按需动态调用数据
动态调用外部黑名单数据
远程函数配置简单

1.4.6 高效能规则管理

支持全中文编写，高可用性
支持多样化的编写方式
支持零代码规则开发
拉拖拽即可搭建决策流
可以直接调用决策库中的决策
支持外部规则导入

1.4.7 支持模型评分的部署与维护

支持模型的部署——线性回归、决策树等简单模型容易将其变成规则来部署，但支持向量机、深度学习等对模型支持的功能有更高的要求。

不仅支持业务规则，还全面支持AI模型
支持外部PMML模型导入决策引擎中
兼容python模型，支持动态调用外部python模型
支持多种统计指标度量模型效果
支持多算法选择
自动生成数据规则，快速迭代算法模型

1.4.8 严谨、便捷的版本控制机制

无论是单个规则文件、或是用户调用的规则包，都可以提供完善的版本控制机制。对于规则文件来说只要有需要，就可以回退到任何一个历史版本；对于给用户调用的规则包，可以在不同的历史版本之间灵活切换。

满足以下条件：

版本发布：快速高效的热部署，不影响线上业务的运行，可直接实时切换。
回滚机制：当新版本线上突发事故，可直接一键回滚切换原有策略版本，后再进行事故排查，降低事故带来的损失。

得以解决一下问题：

逐步迭代分离商业决策者的商业决策逻辑和应用开发者的技术决策；
能有效的提高实现复杂逻辑的代码的可维护性；
在开发期间或部署后修复代码缺陷；
应付特殊状况，即客户一开始没有提到要将业务逻辑考虑在内；
符合组织对敏捷或迭代开发过程的使用；

1.4.9 技术对接成本低

决策引擎和其他系统基于Http/Https的通用接口API进行调用
交互数据文件为json格式数据文件
提供标准的SDK接口文档
系统参数配置
报文

1.4.10 系统监控及状态检查

状态检测
心跳检查
工作台状态
系统日志

2.前台规则管理

2.1 平台介绍

使用者通过浏览器打开规则设计器来定义业务规则，完成后的业务规则文件会被存储在规则存储仓库中（规则存储仓库既可以是文件系统中的某个目录，也可以存储于数据库当中）。规则文件调用时引擎会从规则存储仓库里把指定的规则文件取出，再通过规则构建引擎对规则进行解析、编译，最后由规则执行引擎执行并返回结果。

开发人员在程序中使用规则引擎基本遵循以下5个典型的步骤：

创建规则引擎对象；
向引擎中加载规则集或更换规则集；
向引擎提交需要被规则集处理的数据对象集合；
命令引擎执行;
导出引擎执行结果，从引擎中撤出处理过的数据。

接下来我们分步拆解，着重了解规则模块的组件功能及使用流程。

2.2 功能介绍

规则引擎平台一般由两部分构成：一个是设计器部分；另一个是规则执行引擎部分。设计器部分主要是由库文件设计器以及具体的规则文件设计器两部分构成，由浏览器直接可视化、图形化操作。

2.2.1 知识库管理

库文件设计器包括变量库设计器、参数库设计器、常量库设计器以及动作库设计器四个部分，通过这些库文件设计器，可以将业务系统中使用的实体对象、枚举值、常量以及需要在规则中调用的Java方法映射到引擎中备用。

特征库

在业务系统开发过程中，会用到大量包含Getter和Setter方法的简单的Java对象，它们被称之为POJO（Plain Ordinary Java Object），或BOM(Business Object Model)对象，这些对象在开发中作为数据的载体，负责数据的传递。变量库就是用来映射这些POJO对象，从而使得我们可以在具体的规则文件中使用它们，从而完成规则与业务数据的交互。

规则库中所需要的变量通过预处理，可存储为特征因子，提高变量复用率和规则的简洁度。

根据全域风控需求，特征库中的特征因子分为用户特征因子和全局特征因子。用户特征因子以账户为主键，聚合用户维度的特征数据。得到的数据是反应用户维度的交易、登录、设备等特征。全局特征因子是从全局数据中抽象所需要的其他维度进行组合、计算。

此外，由于商业规则和业务场景不断变化，规则经常需要根据实际变化做出频繁调整。业务人员在前端的特征管理界面，对特征库中的特征因子进行增删改查的操作，不直接对规则库进行频繁变更，避免了特征因子的重复开发。因此，特征因子的存储具有稳定性、聚合性和可复用性。

1）内部数据

2）名单库

名单数据的维度包括：用户ID、IP、设备号、支付账号、手机号。

黑白名单

名单包含三个类型：黑、白、灰名单

名单必须属于某个项目(用于确定名单的范围)，可以在名单管理-名单项目管理中添加项目。

其他名单

后续也可以根据自己的需求扩充其他的维度。为名单型策略提供基础的数据管理功能。

变量库、参数库、动作库、常量库这些库文件定义好后，就可以在各种类型的规则文件中导入并使用它们，一旦某个库文件在规则中被使用，我们就不能再随便修改这些已定义好的库文件的名称、值或数据类型，如果因为业务调整需要必须要进行修改，那么可以通过这些变量、常量、参数、动作定义的操作列上的重构图标来对它们进行修改，这样可以保证引用文件同步更新；如果不采用重构功能而直接修改的话，那么引用的其它类型的规则文件就会出现打开报错的情况。

3）其他数据

常量库

在业务系统开发过程中，常常会用到一个枚举数据，比如用户的性别、学历等，在URule Pro当中，通过定义常量库文件，可以将系统中使用的这些枚举数据映射到规则中使用，这样就可以避免规则定义过程中枚举数据手工输入存在错误的可能性。

参数库

在规则的条件判断与计算过程当中，难免会用到一些临时的变量来存储值，这些临时变量数量和类型都可能是不固定的，对于这种类型的临时变量，以参数的形式提供，通过参数库就可以定义这些在规则中要使用到的临时变量。

动作库

动作库文件的作用是对配置在spring中的bean方法进行映射，使得我们可以直接在规则当中调用这些方法。

2.2.2 规则管理

如果我们的业务给出的是零散的逻辑规则，那么可以使用规则集来实现；如果给出的是表格形式的业务规则，那么可以直接使用对应的决策表或交叉决策表（决策矩阵）来实现；如果需要对实体进行综合评分，则可以使用评分卡或复杂评分卡来实现；最后还可以通过规则流对一系列复杂的规则个体进行编排，将这个规则流作为实际业务规则调用入口，从而实现任意复杂的业务规则。

规则模块常用的产品实现方式主要有规则集、规则表、规则树。

2.2.2.1 规则集

规则集也叫决策集，是一种由一组普通规则和循环规则构成的规则集合，是使用频率最高的一种业务规则实现方式。

普通规则由变量、表达式、条件值、决策结果组成，是指一种由如果、那么、否则三个部分构成的规则，如下：

而循环规则就是可循环的规则，它允许指定一个集合类型的对象，对这个集合中每个对象进行循环迭代，在循环体中则是若干个由如果、那么、否则构成的普通规则。

在执行的循环规则时，需要添加循环条件，以及循环结束后输出的决策结果，在风控决策引擎中，循环规则运用的较少。

规则集按照使用者的不同，也可以分为向导式规则集和脚本式规则集：

向导式规则集：采用全向导方式的规则集设计器，通过鼠标点击就可以完成规则配置。

脚本式规则集：如果是程序员，可能会更青睐代码的方式来定义业务规则。

脚本式规则集里可以实现向导式规则中能实现的所有功能，反过来也是一样。

2.2.2.2 决策表

普通决策表

决策表是一种以表格形式表现规则的工具，它非常适用于描述处理判断条件较多，各条件又相互组合、有多种决策方案的情况，决策表提供精确而简洁描述复杂逻辑的方式，可将多个条件及与这些条件满足后要执行动作以图形化形式进行对应。

交叉决策表

交叉决策表又叫决策矩阵，是一种特殊类型的决策表。与普通决策表相比，交叉决策表的条件由纵向和横向两个维度决定，而普通决策表的条件只是由纵向维度决定；但在普通决策表的动作部分可以是三种类型，分别是赋值、输出和执行方式，而在交叉决策表中动作部分就是纵向和横向两个维度交叉后的单元格的值，一般来说，这种交叉后单元格的值都是赋给某个变量或参数，所以交叉决策表的动作基本就一个，那就是赋值。

从excel中导入决策表

效果如下：

2.2.2.3 决策树

决策树又称为规则树，是规则引擎中另外一种构建规则的方式，它以一棵躺倒的树形结构来表现规则（之所以将其躺倒是为了节省空间，否则一棵稍微大点的树将会占用很大的页面空间），决策树表现业务规则更为形象，实际上，无论是决策树、决策表还是评分卡，都可以通过决策集来实现，只是，对于某些业务规则来说，通过决策树或决策表或评分卡实现起来更为形象、快捷。

2.2.2.4 评分卡

普通评分卡

评分是对个人或机构的相关信息进行分析之后的一种数值表达，表示此人或此机构由于信用活动的拒付行为所造成损失风险的可能性，评分通常用于对个人或机构的风险管理与评估。

使用二维表形式展示目标对象的各个属性，针对不同属性设置不同区段的条件，每个区段条件对应不同的分值，运行时引擎会根据定义的区段条件自动计算目标对象的评分。一个定义好的评分卡效果如下图所示：

复杂评分卡

对于普通评分卡，它可以针对某个对象的一些属性值进行评分，但只能针对是单个对象属性进行条件判断，如果需要对多个对象属性进行条件叠加判断，那么普通评分卡就实现不了，所以需利用复杂评分卡，实现评分时多条件叠加判断，进而使得评分卡的功能更加的完善和强大。

2.2.2.5 复杂模型

通过主观意识借助实体或者虚拟表现构成客观阐述形态结构的一种表达目的的物件（物件并不等于物体，不局限于实体与虚拟、不限于平面与立体），风控决策引擎中使用的模型更多的是数据模型，描述的是目标的行为和特征。

模型在决策引擎中，对于决策引擎平台实际是一个已经封装好了的产品，决策引擎只会负责入参变量的配置、出参变量的配置以及模型的调用，所以这个模块的核心主要是考虑模型的类型（py、model）、调用逻辑、入参以及出参变量的配置。

2.2.2.6 决策流

决策流又称规则流，它整个的结构类似于工作流，用来对已有的决策集、决策表、交叉决策表、决策树、评分卡、复杂评分卡或其它决策流的执行顺序进行编排，清晰直观的实现一个大的复杂的业务规则。

规则引擎中的决策流可以实现对已有的决策集、决策表、交叉决策表、决策树、评分卡、复杂评分卡或其它决策流进行编排执行；编排过程中即可以常见串行执行，也可以并行执行、或者是根据条件选择分支执行。

基于网页的流程设计器，通过简单拖曳就可以快速实现对已有的决策集、决策表、交叉决策表、决策树、评分卡、复杂评分卡或其它决策流执行顺序的编排。

可把不同的规则和模型串到一起，形成一个决策流，实现贷前、贷中、贷后的全流程监控。它要可实现对数据的按需调用，比如把成本低的数据放到前面，逐步把成本较高的数据放到后面。因为有些决策在前面成本较低的数据下已经可以形成，就不必调用高成本的数据

决策流核心的构成包含“开始节点、规则/评分卡/模型等已封装好的规则包节点、决策节点、分支节点、聚合节点。

开始节点为一个决策流开始的地方，决策流程必须有始有终且必须以开始节点作为开始；

规则包节点，实际就是用来添加之前在规则、评分卡、模型、表达式中已经创建好的规则产品；

决策节点是在决策时，根据为其下流出连接配置的条件来决定究竟应该走哪条连接的节点，所以根据这一特性，决策节点下流出连接至少要有两条，否则决策节点就没有意义了；

分支节点实现规则流多条并行的节点，通过这个节点，可以根据当前节点下流出连线数量，将当前规则流实现拆分成若干条子的规则流实例并行运行；

聚合节点用来聚合由分支节点拆分出来的多个子的规则流，实现多条规则流的汇合；

有始有终，决策流程的结束，一般是伴随着决策总、分的流程的执行，执行到最后节点自动结束，输出决策结果。

2.2.2.7 知识包

2.2.3 阈值管理

专家阈值

由于每日风控请求量都是海量的，首先利用专家阈值进行初步过滤，基于多维度指标的静态阈值对明显存在风险的账号和行为执行相应的风控措施。专家阈值是基于专家征询法（DelphiMethod）对单个指标的阈值进行一一确定，具有客观性和代表性。

基于用户行为的动态阈值

用户行为模型是基于用户行为，动态调整阈值的一种综合性方法。技术路径流程具体分为三个步骤：

基于用户行为，以用户为主键，利用设备指纹、历史风控请求等特征，采用聚类分析、随机森林等深度模型进行用户分类和特征挖掘；
构建用户的风险评级系统，其实现逻辑是对模型结果进行计算，对各个群体分配不同的风险等级；
线上沿用训练好的模型参数对样本进行计算，实现高可用的个性化智能风控。线上采用这样的浅度模型方式进行判断和匹配，减少运算压力且提高效率。

特征工程来源于风控系统的离线特征库。深度模型用于离线环境下的模型训练，包含用于特征探索的非监督模型和用于风险概率预测的监督模型，输出结果为预测的风险概率。

基于时间序列的动态阈值

时间序列（或称动态数列）是指将同一统计指标的数值按其发生的时间先后顺序排列而成的数列。时间序列分析的主要目的是根据已有的历史数据对未来进行预测。

传统的时间序列预测方法有：简单平均法、移动平均法、指数平滑法等。风控系统的阈值计算常使用移动平均法（moving average），即：通过对时间序列逐期递移求得平均数加/减标准差作为预测值。

2.2.4 规则监控

规则监控针对的是对知识包调用的监控。规则是放在知识包是调用的，所以规则监控也就是对知识包的监控。

报表
仪表板

2.2.5 权限管理

知识库的权限控制指的是针对规则项目、项目里的各种类型文件的读写权限控制。

知识库里多个规则项目，每个项目由不同的人负责，同时又有多人负责定义规则项目里不同的规则文件，这时就有必要通过知识库权限控制机制，让不同的操作人员只能读写自己负责的规则项目或规则文件，这样可以防止误操作的发生。

2.3 使用流程

购买/搭建

购买或者自主搭建决策引擎，注意配套的产品文档、说明文档、技术支持。

2.3.1 安装配置

运行模式

实际使用时，有三种使用方式，分别是嵌入式模式、分布式计算模式以及独立服务模式。

权限配置

客户端服务器配置

服务器配置

2.3.2 创建项目

项目可以用于定义需要设定复杂决策的业务场景，当调用引擎时，传入相应的项目编码，决策引擎会将不同事件的数据请求路由到相应的策略集合中进行相应运算。

项目包含以下几部分：

表单
决策
文档组

项目名称建议使用易理解的业务场景名称，设置成功后一般不支持修改。

2.3.3 定义表单

有表单窗格
表单编辑模式
区块
字段
字段类型

支持快速增、删、查、改
支持外部表单导入，CSV、json等格式
自定义变量类型
支持全中文编写

2.3.4 创建决策流

一个决策流里面可以包含若干个具体的规则文件，这些文件可以是若干个规则集（决策集）、决策表、交叉决策表（决策矩阵）、评分卡、复杂评分卡以及决策流。需要注意的是，规则文件里引入的库文件（变量库、参数库、常量库以及动作库文件）是不需要导入的，引擎会自动处理规则中包含的库文件。

策略创建

策略基础信息输入

策略计算逻辑

输入条件名称，此项为非必填项，为方便可视化预览时直观展示策略逻辑，建议输入易于理解的内容。

计算逻辑与预览

计算逻辑编排采用条件序号与符号进行编排。输入编排的内容后，点击“可视化逻辑”即可预览。

策略输出与状态

策略输出标签指，在前面的步骤中设定的策略条件逻辑满足的情况下，决策引擎系统返回的内容。

策略运行状态定义

草稿状态为保存但不执行计算的状态；试运行为保存且执行计算但不执行输出标签；正式运行为保存且执行计算和执行输出标签。为减少配置操作风险，建议先将策略置为试运行状态，观察运行后再切换为正式运行。

2.3.5 规则编写

2.3.6 决策保存

按照业务需求将规则文件定义好后，就可以将涉及到的所有规则文件打包成知识包备用。

2.3.7 传入测试数据

支持批量上传测试样本数据

2.3.8 获得策略结果

请求示例如图所示：

2.3.9 规则效果分析

支持自定义分析报表，可视化呈现运行结果
触发次数分布
风控措施响应

规则新增或修改后，业务方需要分析效果。本模块会提供：规则内部执行路径、运行时参数和结果的镜像数据，数据可以存储在hbase上。

2.4 规则设置的建议

2.4.1 规则设置

自有数据源对应的规则优于三方数据源对应的的规则
强规则（强规则命中直接拒绝）优于弱规则（弱规则需要组合判断决策）
低成本数据对应的规则优于高成本数据对应的规则
效率高的规则优于效率低规则
需要积累数据的规则优于无需积累数据的规则

2.4.2 A/B测试和冠军挑战

对于规则修改、调优时尤其重要。两套规则跑所有的数据，最终来比较规则的效果。另一种是分流——10%跑新规则，90%跑老规则，随着时间的推移来根据测试结果的有效性。

冠军/挑战者实验：

便捷的流程分支部署
实现进件数据的随机分流
对所有分流数据明确策略标签，支撑策略有效性评估。

3.后台执行引擎

3.1 引擎框架

3.1.1 例：陌陌静默规则引擎

aswan 是陌陌开发的风控系统静态规则引擎，零基础简易便捷的配置多种复杂规则，实时高效管控用户异常行为。

3.1.2 例：美团点评Maze框架

MazeGO核心主要由3部分构成：资源管理器、知识库和MazeGO引擎。另外两个辅助模块是流量控制器和规则效果分析模块。基本构成如下图。

主要由3个模块构成。

知识库

负责提供配置视图和模式因子。知识库之所以叫“知识”库一个很重要的特征是知识库可以低成本扩展知识。知识扩展包括视图和模式的添加，视图和模式有一对一映射关系。

视图：用于业务分析师等非技术背景的人员配置规则。作用两方面：

模式：构成规则的最小单位，不可拆分，可以直接被规则引擎执行。

资源管理器

负责管理规则。

版本管理：支持规则迭代更新、回滚和灰度等功能。

依赖管理：负责将规则解析为模式树。为了最大限度地增强规则的表达能力，每一个模式设计都很“原子”，如果想配置一个完整语义的规则，则必须由多个子规则共同构成，因此规则之间会有树形依赖关系。如$参数1 + $参数2 > $参数3这样的规则便是由多个模式“复合”而成，则他的依赖关系如下所示。

最终结果 /* 变量模式 /

中间结果 > $参数3 /* 关系运算模式 /

$参数1 + $参数2 /* 算数运算模式 /

规则引擎

负责执行规则

调度器：根据规则的依赖关系以及硬件资源驱动模式执行器执行模式，目标是达到最大吞吐或最低延迟。

模式执行器：负责直接执行模式。执行器可以根据业务的表达能力需求选择基于Drools、Aviator等第三方引擎，甚至可以基于ANTLR定制。

MazeQL引擎核心模块如下图：

3.1.3 例：美团酒旅Aviator引擎

总体来看，系统组成模块及功能如下：

规则引擎：集成于Storm拓扑中，执行运营活动条件转换成为的具体规则，作出对应响应。
时间窗模块：具有可选时间跨度的滑动时间窗功能，为规则判定提供时间窗因子。
定时触达模块：设定规则判定的执行时间，达到设定时间后，执行后续规则。
自定义函数：在Aviator表达式引擎基础函数之上，扩展规则引擎功能。
报警模块：定时检查系统处理的消息量，出现异常时为负责人发送报警信息。
规则配置控制台：提供配置页面，通过控制台新增场景及规则配置。
配置加载模块：定时加载活动规则等配置信息，供规则引擎使用。

其中，规则引擎由核心组件构成的最小功能集及扩展组件提供的扩展功能组成。由于规则引擎解耦了业务规则和系统代码，使得实时数据在处理时变的抽象，对数据监控、报警提出了更高的要求。

3.2 核心组件

规则引擎核心组件为构成规则引擎的最小集合，用以支持完成基础规则判断。

3.2.1 流量控制器

负责不同版本规则的调度。方便业务方修改规则后，灰度部分流量到新规则。

3.2.2 资源管理器

数据存储系统

格式化数据存储于关系型数据库，例如：用于离线分析的会员属性数据、历史订单数据等；非关系型数据库用于存储需要频繁更新的数据；实时风控请求数据、设备指纹数据。

在构建一个风控系统之前，需要根据企业的业务场景确定数据来源，通常需要解决跨业务系统的数据接入问题。

在关键业务节点，需要设置业务埋点、SDK数据采集等配合，实现对风控事件的实时追踪，并将实时数据接入到数据存储模块中。

变量库、直属库、规则库

接口管理

由于规则引擎是软件组件，所以只有开发人员才能够通过程序接口的方式来使用和控制它，规则引擎的程序接口至少包含以下几种API：

加载和卸载规则集的API
数据操作的API
引擎执行的API

3.2.3 规则设计器

3.2.4 规则执行引擎

调度器

规则大多由多个规则组合而成，因此也需要调度管理，实现层面完全一致。

驱动器

驱动平台进行规则计算。

预加载规则

首先为了避免访问规则时需要实时执行远程调用而造成较大的时延，另外规则并不是时刻发生变更没有必要每次访问时拉取一次最新版本，基于以上两个原因规则管理模块会在引擎初始化阶段将有效版本的规则实例缓存在本地并且监听规则变更事件（监听可以基于ZooKeeper实现）。

预编译规则

因为规则每次编译执行会导致性能问题，因此会在引擎初始化和规则有变更这两个时机将增量版本的规则预编译成可执行代码。

计算集群

包括实时计算集群和离线计算集群。实时计算集群用于实时风控所需的预计算，为后续的规则判断而准备。通常需要借助统计方法，得到所需维度的统计值。离线计算集群用于周期性执行的任务，通常周期时间至少为一天。

主要用于满足非实时的大数据分析和模型训练的需求，将原始的风控数据在计算层进行计算处理，形成各个维度的特征数据，例如：频次统计、最大统计、最近统计等。

3.2.5 时间窗模块

时间窗模块为规则引擎提供时间窗因子。时间窗因子可用于统计时间窗口内行为发生的次数、时间等。

3.2.6 配置中心

版本管理。同“系统模型”一节。
数据源绑定。即是定义参与计算的SQL逻辑中使用到的数据源，便于系统进行管理。
结构查询定义。即是定义SQL规则，这是主体规则内容。
向量计算定义。定义VectorC类计算（VectorC见“Maze框架”章节开头的介绍）。
供权限设置使用，精确限定某个用户能看哪些页面的数据。详见其它 -- 权限管理。

3.3 扩展组件

规则引擎扩展组件在核心组件的基础上，增强规则引擎功能。

3.3.1 自定义函数

自定义函数可以扩充规则引擎功能，规则引擎可通过自定义函数执行因子及规则条件，如调用用户画像等第三方服务。

3.3.2 定时触达模块

定时触达模块支持为规则设定定时执行时间，延后某些规则的执行以满足运营活动规则。定时触达模块涉及的数据流图如图所示：

3.3.4 监控与报警

对比离线数据，实时数据在使用过程中出现问题不易感知。由于系统针对的运营活动直接面向C端，在出现系统异常或数据质量异常时，如果没有及时发现，将会直接造成运营成本浪费，严重影响活动转化率等活动效果评估指标。针对系统稳定性问题，从监控与报警两个角度入手解决。

监控

利用公司数据平台现有产品，对系统处理的实时事件按其事件ID上报，以时间粒度聚合，数据上报后可实时查看各类事件量，通过消息量评估活动规则和活动效果是否正常。

报警

监控只能作为Dashboard供展示及查看，无法实现自动化报警。由于用于监控所上报的聚合数据存储于时序数据库中，需基于HTTP API，定制报警模块，定时调度、拉取数据，对不同事件，按事件量级、活动重要性等指标，应用环比、绝对值等不同报警规则及阈值。超出设定阈值后，通过公司IM及时发送报警信息。

3.4 引擎执行流程

引入规则引擎后，业务需求被转换为具体场景和规则进行执行

规则引擎在执行规则过程中，涉及以下数据模型：

场景：业务需求的抽象，一个业务需求对应一个场景，一个场景由若干规则组成。用不同的规则组成时序和依赖关系以实现完整的业务需求。
规则：规则由规则条件及因子组成，由路由至所属场景的事件触发，规则由规则条件、因子及规则响应组成。
规则条件：规则条件由因子构成，为一个布尔表达式。规则条件的执行结果直接决定是否执行规则响应。
因子：因子是规则条件的基础组成部分，按不同来源，划分为基础因子、时间窗因子和第三方因子。基础因子来源于事件，时间窗因子来源于时间窗模块获取的时间窗数据，第三方因子来源于第三方服务，如用户画像服务等。
规则响应：规则执行成功后的动作，如将复合事件下发给运营业务系统，或发送异步事件进行后续规则判断等。
事件：事件为系统的基础数据单元，划分为同步事件和异步事件两种类型。同步事件按规则路由后，不调用定时触达模块，顺序执行；异步事件调用定时触达模块，延后执行。

3.5 系统开发的建议

3.5.1 规则匹配优化

在规则的模式匹配中，使用Rate算法提升匹配效率，减少了重复计算造成的时间冗余性。在规则数量和事实样本较多时，每条事实数据都需要与Rete网络中的Aplha节点相匹配。

大多数规则所含的条件原子相同，即存在被多个规则同时包含的条件原子，依次与每个Alpha节点匹配就存在了一定时间浪费。

因此，一个预匹配模块，将多条规则聚合成少量的规则组。通过规则组筛选，在预匹配阶段过滤掉部分正常数据，减少事实和节点的匹配次数。实现逻辑是将含有多个相同条件原子的规则划分到同一规则组中，规则组中出现次数最多的条件原子作为该规则组的特征条件。

全量数据通过预匹配模块中规则组的筛选，即可过滤掉部分数据，对剩余样本执行所在规则组内的规则判断。对于多条规则的规则组划分，需要首先构建一个键值对，存储所有条件原子和该条件在所有规则中出现的次数。

也可以从业务角度设计规则组，按照不同的业务线划分规则所属的规则组。但系统的响应速度容易受到业务场景的影响。

3.5.1 规则评价机制

有效的风控规则体系包括识别风险用户，以及实时的风险拦截措施，防患于未然。同时，风险措施将直接作用于产品终端，影响到用户体验。

因此，基于业务的风控系统需要将风险的误报率和漏报率降低到可接受的范围内，提升产品终端的用户体验。本系统基于规则触发次数和风控反馈结果，构建了规则评价体系，以验证规则有效性，并有助于业务人员对风控规则进行监控和优化调整。规则评价机制的作用逻辑如图所示。

规则评价机制根据两种数据来源进行，一是根据风控分值得到的触发次数分布；二是触发规则后对风控措施进行响应，所得到的最终请求结果。

规则命中准确率评价

规则引擎输出每条规则的触发次数，基于此计算查准率（p）和召回率（r）；其中，TP为触发规则但未通过验证的请求次数，以及来自黑名单中用户的请求；FP为触发规则中通过验证的请求次数；FN为未触发规则中来自黑名单用户的请求次数。

查准率反应了该规则识别风险用户的准确率，召回率反应了规则能否识别出尽可能多的风险用户。当上述风险评价机制的性能指标超过了正常范围，系统或自动发送报警邮件，通知策略负责人员核实策略的准确性。

风控措施合理性评价

系统根据每次请求的返回分值，匹配滑动窗口验证、短信验证、禁止访问等实时风控措施。对于验证类措施，请求的验证结果有助于区分该请求是否来源于黑产群体的模拟用户。

接下来，我们进入第四部分，在调研期间，笔者总计独立测试了4款产品，包括规则管理平台的测试和模型引擎的部署。分别做如下介绍：

4.规则引擎调研

4.1 开源规则引擎

JBoss Drools
Mandarax
OpenRules
JEOPS
InfoSapient
Roolie
Apache Camel

4.2 商业规则引擎

ODM
Oracle Business Rules
旗正规则引擎
Jess（可研究，商用收费）
TopRules
明策智能决策
是隶属于信数金服这家公司的一个决策引擎，搭载了最新一代Rete-NT算法，由决策引擎之父Charles Forgy博士参与研发，FICO Blaze Advisor与IBM ILOG产品缔造者
益博睿决策引擎
目前主流的信贷决策工具之一Experian SMG3（Strategy Management Generation 3），作为信贷决策管理工具，可服务于各个信贷生命周期中的各个阶段。贷前的信贷审批，贷中的账户策略管理以及贷后的催收和保全，都可以用SMG3作为统一的决策管理平台。
神州融大数据风控平台就是基于SMG3构建的，帮助小微金融机构实现整个信贷生命周期中各个阶段的模型及策略管理与优化调整，做到面向业务用户的企业级统一决策管理平台和灵活的模块化信贷流程配置。

4.3 项目实测

4.3.1 drools

Drools 是用 Java 语言编写的开放源码规则引擎，使用 Rete 算法对所编写的规则求值。Drools 允许使用声明方式表达业务逻辑。可以使用非 XML 的本地语言编写规则，从而便于学习和理解。并且，还可以将 Java 代码直接嵌入到规则文件中，这令 Drools 的学习更加吸引人。

Drools 还具有其他优点：

非常活跃的社区支持
易用
快速的执行速度
在 Java 开发人员中流行
与 Java Rule Engine API（JSR 94）兼容

Drools 是业务逻辑集成平台，被分为4个项目：

Drools Guvnor (BRMS/BPMS)：业务规则管理系统
Drools Expert (rule engine)：规则引擎，drools的核心部分
Drools Flow (process/workflow)：工作流引擎
Drools Fusion (cep/temporal reasoning)：事件处理

官网：http://www.drools.org/#

官方文档：http://www.drools.org/learn/documentation.html

测试结果

使用Drools后的规则配置流程如下图

规则主题代码演示：

rule "1.1"
    when
        poi : POI( source == 1 && brandType == 1 )
    then
            System.out.println( "1.1 matched" );
            poi.setPassedNodes(1);endrule "1.2"
    when
        poi : POI( source == 1 && brandType == 2 )
    then
            System.out.println( "1.2 matched" );endrule "2.1"
    when
        poi : POI( source == 2 && brandType == 1 )
    then
            System.out.println( "2.1 matched" );
            poi.setPassedNodes(2);endrule "2.2"
    when
        poi : POI( source == 2 && brandType == 2 )
    then
            System.out.println( "2.2 matched" );
            poi.setPassedNodes(3);end

在实践中，Drools方案有以下几个优缺点： 优点 * 策略规则和执行逻辑解耦方便维护。 缺点 * 业务分析师无法独立完成规则配置：由于规则主体DSL是编程语言（支持Java, Groovy, Python），因此仍然需要开发工程师维护。 * 规则规模变大以后也会变得不好维护，相对硬编码的优势便不复存在。 * 规则的语法仅适合扁平的规则，对于嵌套条件语义（then里嵌套when...then子句）的规则只能将条件进行笛卡尔积组合以后进行配置，不利于维护。