风控逻辑利器---规则引擎

李木林

前言规则引擎的定义规则引擎的执行转转风控规则引擎总结前言风控的职责是控制业务的风险。在识别风险过程中，要根据大量的用户行为和用户信息去做逻辑判断，最终给出决策结果。在决策过程中，大量的逻辑判断需要开发和维护，如果以传统的方式去开发和维护，需要付出巨大的时间成本并且隐藏着毁灭性的事故风险。所以将业务代码和复杂的逻辑代码剥离显得迫在眉睫。规则引擎的定义规则引擎由推理引擎发展而来，是一种嵌入在应用程序中的组件，实现了将业务决策从应用程序代码中分离出来，并使用预定义的语义模块编写业务决策。接受数据输入，解释业务规则，并根据业务规则做出业务决策。下图是规则引擎的组成部分：1）特征集合：表示当前传入的数据(例如：用户对象zzuser)2）条件：逻辑判断3）规则：对特征进行逻辑判断，得出结论4）规则集：多条规则组合成规则集规则引擎推理方式分为两种：正向链接推理：这是一种基于“数据驱动”的形式，基于用户的行为信息和基本信息，得出结论。反向链接推理：这是一种基于“目标驱动”的推理形式，与正向链接相反，以假设的结论出发，推断用户的哪些行为信息和基本信息符合假设的结论。规则引擎的执行规则引擎的执行方式分为解释执行、编译执行和自定义执行。解释执行表达式逐条转换成目标代码，逐条运行。编译执行表达式一次性动态的编译成字节码并执行。自定义执行早期在没有引入表达式引擎的时候，就是通过自定义实现的表达式解析。举个例子：特征a、特征b、特征c =>求特征dd=（a+b）/c  这是一个简单的四则运算表达式。这个表达式对于人的思维方式来说非常的简单，但是计算机识别起来就非常的困难。所以要将常规的表达式转换成计算机方便计算的表达式(逆波兰表达式)。上面的表达式转换成逆波兰表达式为：ab+c/这样计算机就可以比较简单的求出表达式的值。逆波兰表达式的转换算法感兴趣的可以自行百度。转转风控规则引擎转转风控规则引擎是一种正向链接推理的规则引擎，以数据为驱动，去推断相应的结论。比如说，业务要识别违禁品，可以根据图片模型分数大于0.9来推断出用户违规。特 征： 模型分数操作符号： 大于阈 值： 0.9这三部分构成了一个规则。转转规则引擎分三个发展阶段：第一阶段：硬编码阶段，此阶段所有的规则都是通过代码写死的，维护性和扩展性极差。第二阶段：规则引擎阶段，通过抽象业务，开发规则配置平台，可以非常方便的运营规则，增加了规则的机动性。下图是规则运行的一个用例图：特征(按类型划分)用户特征： 用户的昵称、年龄、注册时间等商品特征： 商品内容、等订单特征： 订单金额、订单的品类等操作符号规则引擎操作符：大于、小于、等于、敏感词匹配、用户标记等结果命中规则或者不命中规则下图是实际的一个规则配置(商品的当前价格是否小于等于30000,价格单位：分)：第三阶段：完善特征工程阶段，减少特征的开发上线。表达式引擎的引入1)表达式引擎的选择AviatorFel执行速度快快jar包的大小70kB200kB社区活跃度非常活跃一般执行方式动态编译/解释执行动态编译/解释执行两者性能差不多，最终选择了aviator，因为aviator社区活跃度和jar包大小要优于Fel。2)aviator表达式功能简介(1)支持绝大多数运算操作符，包括算术操作符、关系运算符、逻辑操作符、位运算符、正则匹配操作符(=~)、三元表达式(?(2)支持操作符优先级和括号强制设定优先级。(3)支持赋值。(4)逻辑运算符支持短路运算。(5)支持丰富类型，例如nil、整数和浮点数、字符串、正则表达式、日期、变量等，支持自动类型转换。(6)支持lambda匿名函数和闭包。(7)内置一套强大的常用函数库。(8)可自定义函数，易于扩展。(9)可重载操作符。(10)支持大数运算(BigInteger)和高精度运算(BigDecimal)。(11)小巧并性能优秀3)aviator表达式引擎在特征工程的实践(1)基本特征取值比如说，订单价格特征(orderFeture.price)、商品特征(infoFeature.title)、用户昵称特征(userFeature.nickname)。（注rderFeture,infoFeature,userFeature是系统中的一个实体对象）(2)特征的基本运算比如说，已有手机分类商品数特征(infoFeature.phoneTotalCount)、全部商品总数特征(infoFeature.totalInfoCount)，想要一个手机商品数在商品总数中的占比特征，就可以直接通过四则运算获取到：long(infoFeature.phoneTotalCount)*100/long(infoFeature.totalInfoCount)(3)内置函数aviator提供了大量的内置函数，可以通过它的内置函数获取想要的配置结果。比如说，商品长度特征string.length(infoFeature.title)，应用了求字符串长度的函数string.length。(4)自定义函数aviator除了内置的函数，还支持自定义函数，可以根据需求自定义函数。比如说，想通过配置获取redis里的值，就可以开发一个获取redis的函数(函数名字是jodisFeature)。jodisFeature('price_median',infoFeature.cateChildId)。这个特征配置就是为了获取rediskey为price_median的值。特征的代表的含义是：分类价格的中位数，当然这些数据已经提前计算好存储在redis里面了。(5) Lambda表达式个人感觉Lambda表达式的引入是一个质的飞跃，这样就可以操作集合，只要有源数据，就可以转换出任何想要的特征。比如说，已有订单流水list(orderFeature.orderFlow)，通过lambda表达式就可以转换成特征(发货时间到确认收货时间)：seq.get(map(filter(orderFeature.orderFlow,lambda(x)->(x.status==5)end),lambda(y)->y.latestOpTimeend),0)-order.deliverTime。总之，表达式引擎还有各种各样的玩法，感兴趣的可以自行尝试。特征数据源引入表达式引擎之后，可以通过各种函数转换获取想要的特征，特征的转换依赖数据源。由于数据源的获取需要开发上线，给特征配置化带来极大的不便。因此，数据源的获取成了特征配置的瓶颈。数据源哪里来呢？两种方式：一种是业务请求携带的参数数据，另一种是调用服务方获取的数据。第一种对应的解决方案是特征映射，第二种对应的解决方案是接口调用配置化。1）特征映射特征映射是为了将业务方的参数转换成需要的特征。业务方通过两种方式调用，一种是同步调用，另一种是异步调用(异步调用采用的是消息队列的形式)。为了将业务的数据源统一收拢，跟业务约定将参数放到map里面，规则需要什么数据就可以通过map去获取。为了方便特征配置，开发了一个获取业务参数的自定义函数(函数名：paramget)。例子：paramget('uid')代表的意思就是获取用户的uid。在实际开发过程中，MQ异步调用的方式遇到了一些困难。由于各个业务系统的MQ消息体字段名称不一致，导致配置兼容比较多。比如说，同样都是uid的特征，有的业务MQ中用uid字段表示，有的用userId字段表示。为了控制字段兼容对规则的侵入性，在MQ消息和风控特征数据源之间做了一层映射，这层映射解决了字段对应偏差的问题。2）接口调用配置化接口调用配置化是为了解决风控调用业务获取数据源的问题，每个接口只要传入相应的参数，就会返回相应的结果。这个问题可以抽象概括，只需要根据不同的业务方配置不同的参数，就可以获取相应的数据源。比如说，我们新接入一个zzuser的接口，通过配置表就可以获取用户unionid(微信id)关联的账户数。下图是配置表的信息：配置表里包含：服务名、类的全限定名、接口名、接口参数、接口参数值返回结果：{"code":0,"body":3}图中表达式中，13代表了配置表的id=13，commonfeature函数获取getCountByUnionId接口的返回信息({"code":0,"body":3})，jsongain函数获取json数据中key是“body“的信息3。由于服务间的通信是rpc调用的，要实现服务间通用的规则调用需要底层的支持。正好，架构部提供了服务的泛化调用，完美地解决了通用的调用问题。总结本文介绍了规则引擎的定义和执行方式，并且详细介绍了规则引擎在风控的落地。利用规则引擎辅助风控控制业务风险，实现业务数据源可配置、风控逻辑可配置，极大的降低了开发规则和维护规则的成本。