前言：最近刚接触了决策引擎，所以搜了一点关于决策引擎的资料看，下面针对资料进行回溯。
part one
本part 主要讲解了现在市面上主流风控决策引擎产品包含的核心功能模块，其中主要是规则、评分卡、表达式、模型、决策流等功能模块。
互联网金融的兴起，金融科技向传统金融渗透，智能风控平台应运而生。决策引擎担任着智能风控平台的核心角色，在当代的互联网金融浪潮中至关重要，在介绍决策引擎之前，首先要明白什么是大数据风控。
什么是大数据风控？
百度百科解释：大数据风控即大数据风险控制，是指通过运用大数据构建模型的方法对借款人进行风险控制和风险提示。
抽象出来就是：
风控决策引擎作为模型的载体，实际上就是实现大数据风控的工具。
什么是风控决策引擎？风控决策引擎是对复杂的业务逻辑抽象化剥离出来的业务规则进行不同的分支组合、关联，然后层层规则递进运算，最终输出决策结果的产品。
传统的风控决策引擎主要实现规则的逻辑判断，例如：女厕所的规则可以制定成“性别为女，才能进入，否则不能进入”，因此在数据段输入的人性别为“男”时，则规则判断为不能进入；
现有通常使用的风控决策引擎，在传统的基础上功能更加丰富，可以实现规则、评分卡、模型、表达式等多种类型的逻辑嵌套，实现层次更加丰富的逻辑运算，满足现在的互联网金融业务要求；
高阶的风控决策引擎，是在现有的风控决策引擎上融入了自言语言处理平台、流计算平台等，提升了现有决策引擎的算力和处理时效；
现在主要还是介绍通常使用的风控决策引擎平台，包含的常用功能模块主要是规则、评分卡、模型、表达式、决策流。
规则模块
规则模块常用的产品实现方式主要有规则集、规则表、规则树。
规则集
其中规则集分为普通规则、循环规则，普通规则由变量、表达式、条件值、决策结果组成，如下：
变量：会员年龄表示、表达式：大于等于、条件值：18，这只是规则集的一条规则，其中规则与规则之间存在且、或逻辑关系，然后就是决策结果：满足rule1，输出会员名名称“金牌会员”，不满足输出会员名称“普通会员”。
循环规则可以对集合对象进行循环的执行规则，一个循环规则可以有一个或者多个循环单元，每个循环单元都是一个普通的规则，定义的方式同普通规则。只是在执行的循环规则时，需要添加循环条件，以及循环结束后输出的决策结果，在风控决策引擎中，循环规则运用的较少，这里不做详细的讲解，感兴趣的可以留言讨论。
规则表
规则表是一种表格形式的规则工具，在处理判断条件较多的时候，决策结果较多的情况时，可以快速定义出决策规则。
规则表分为条件列、决策列，其中上图借款人年龄、借款人是否有驾照、借款人命中黑名单是条件列，决策结果是决策列。
现在虽然风控决策结果输出的结果类型不要求多样化，但是规则种类、数量很多，采用规则表方案实现规则的决策配置可以更加便捷、清晰。
规则树
规则树也是规则集的另一种表现形式，在展示上更加形象，在风控业务上通过规则树、规则表进行规则的配置可以更加形象、快捷。
其中每条规则的实现方式同普通规则，都有变量、表达式（条件）、条件值、决策结果（变量赋值）构成。
评分卡模块
评分卡是对目标的信息进行分析打分的表达方式，表示此人或此机构由于信用活动的拒付行为所造成损失风险的可能性，评分通常用于对个人或机构的风险管理与评估。
评分卡实际也是规则的变形，通过有变量、表达式、条件值、得分四部分组成，当然评分卡还会有得分的计算方式，例如求和、加权求和等。
模型模块
通过主观意识借助实体或者虚拟表现构成客观阐述形态结构的一种表达目的的物件（物件并不等于物体，不局限于实体与虚拟、不限于平面与立体），风控决策引擎中使用的模型更多的是数据模型，描述的是目标的行为和特征。
模型在决策引擎中，对于决策引擎平台实际是一个已经封装好了的产品，决策引擎只会负责入参变量的配置、出参变量的配置以及模型的调用，所以这个模块的核心主要是考虑模型的类型（py、model）、调用逻辑、入参以及出参变量的配置。
表达式模块
表达式模块主要是规则、评分卡等逻辑判断实现困难时，可以直接通过代码*编辑实现决策的规则判断，其中规则的表达式、条件值、决策结果都是通过编码实现，通过这样的方式可以运用于更多小众难实现的决策场景，灵活性更大。
表达式模块类似模型模块，规则的入参和出参配置也是重点。
决策流模块
决策流它实现整个分开工决策引擎的工作流配置，用来对已有的规则、评分卡、模型、表达式进行执行顺序的编排，清晰直观的实现大型、复杂的风控规则。
决策流核心的构成包含“开始节点、规则/评分卡/模型等已封装好的规则包节点、决策节点、分支节点、聚合节点。
开始节点为一个决策流开始的地方，决策流程必须有始有终且必须以开始节点作为开始；
规则包节点，实际就是用来添加之前在规则、评分卡、模型、表达式中已经创建好的规则产品；
决策节点是在决策时，根据为其下流出连接配置的条件来决定究竟应该走哪条连接的节点，所以根据这一特性，决策节点下流出连接至少要有两条，否则决策节点就没有意义了；
分支节点实现规则流多条并行的节点，通过这个节点，可以根据当前节点下流出连线数量，将当前规则流实现拆分成若干条子的规则流实例并行运行；
聚合节点用来聚合由分支节点拆分出来的多个子的规则流，实现多条规则流的汇合；
有始有终，决策流程的结束，一般是伴随着决策总、分的流程的执行，执行到最后节点自动结束，输出决策结果。
决策引擎除了以上核心功能模块以外，实际上为了风控决策引擎灵活多变，能够实现尽可能多的风控业务场景，通常会实现规则、评分卡、表达的相互嵌套调用，这样可以更好应对不同的风控业务场景。
以上只是对风控决策引擎做了简要的介绍，其中的规则、评分卡等功能在风控业务复杂的情况下还可以对规则和评分卡进行产品升级，实现复杂规则、复杂评分卡的决策能力。
实际应用中的产品只靠风控决策引擎是远远不够的，风控决策引擎的应用还会搭配指标平台、接口管理平台、风控报告等产品一同服务于风控业务。
part two:
在第一part中，只是对风控决策引擎的核心功能规则、评分卡、模型、表达式、决策流等模块做了简介。
大数据风控，大数据输入决策引擎通过规则、评分卡、模型、表达式、决策流等功能模块就能输出理想的风控结果了吗？
实际业务中的风控流程依靠这几个功能模块是无法完全达到风控目的，成熟的风控方案有一套严谨的策略体系，风控决策引擎要结合风控策略体系，最终才能达到风险控制的目标。
大数据风控通用流程主要为贷前、贷中、贷后全信贷生命周期风控，分别对应的评分卡有A卡（Application score card）申请评分卡、B卡（Behavior score card）行为评分卡、C卡（Collection score card）催收评分卡。评分卡的开发需要丰富的数据支撑，在信贷业务初期由于数据不充分，则不具备评分卡的开发，这时候就会选择规则判断进行初期的风控。
信贷通用的风控都是包含了规则和评分卡两部分，贷前流行的风控策略流如下：
基于准入、反欺诈（黑名单）、信用评级、定额定价四部分构成，具体的信贷场景在此基础上也会有部分调整，在自有存量客户较大的时候，新上线信贷产品之前很多厂家都会在准入之前加入预授信策略。
无论是准入、反欺诈、授信评级中的规则还是评分卡，通常是都是通过决策引擎进行逻辑判断，在智能风控平台之决策引擎（一）中介绍了四个常用的决策引擎功能模块，其中决策流配置模块就是用来配置信贷风控策略流，评分卡模块配置评分卡模型进行封装成规则包、规则模块配置规则进行封装成规则包，在通过决策流配置模块配置风控流程。
信贷风控流程就是决策引擎对于传入数据的组合运算，有风控策略流程就有规则的优先级运算也就有数据传入的优先级概念，优先级制定的原则主要是从数据源、规则的强弱（强规则命中直接拒绝、弱规则需要组合判断决策）、数据成本、效率、数据积累等方面进行考虑：
自有数据源对应的规则优于三方数据源对应的的规则
自有数据源在接口请求、性能、价格等方面都优于三方数据源，如自有 的黑名单库数据，在命中黑名单规则可以直接拒绝。
强规则（强规则命中直接拒绝）优于弱规则（弱规则需要组合判断决策）
很多决策引擎的性能伴随着规则数量的增加下降，考虑更好的利用决策引擎的资源，强规则决策优于弱规则决策。例如命中前科拒绝这种强规则，应该优于命中多头借贷且命中逾期3次拒绝这种组合的弱规则。
低成本数据对应的规则优于高成本数据对应的规则
大数据风控，数据的费用在整个智能风控中占据着较重的比列，在制定的风控策略流程的时候，低成本规则优于高成本规则。三方数据服务主要由查得、查询两种计费模式，其中查得是指三方数据返回有结果进行计费；查询是指请求三方数据，不管三方数据是否返回结果就进行计费，因此查得对应的规则优于查询对应的规则。
效率高的规则优于效率低规则
有些规则比如规则甲只需要一个接口A就能做出决策，而规则乙则需要三个接口B/C/E才能做出决策，因为接口的请求是需要时间，这时候就需要考虑规则效率，效率高的由于效率低的规则。
需要积累数据的规则优于无需积累数据的规则
在模型冷启动的时候，有些变量作为后期模型潜在核心变量，需要尽可能多的收集这些数据，此时需要积累数据的规则优于无需积累数据的规则。
以上的优先级原则不都是固定不变的，很多规则优先级的制定都是基于几个原则的综合考虑。
由规则的优先级原则，对于风控决策引擎在决策运算时的功能要求是，能够对于决策流程命中拒绝结果后实现决策流程的决策终断以及决策继续，决策流程不仅可以在大的决策流上实现决策流程开关，而且也可以对小的支流某条规则实现决策流程的开关。
数据接入优先级确认，传入决策引擎进行规则、评分卡、模型的决策，此时还需考虑数据缺失时，数据缺失太多规则、评分卡等的风控也会失灵，那此情形下的决策引擎应该怎么处理呢？
通常规则类的策略，在命中数据缺失的时候，可以在规则中配置决策结果直接输出缺失的结果。但是评分卡类的策略，如果在数据缺失时通过配置其得分，最后计算总得分，依据总分进行评分卡的结果决策，这样很难保证评分卡的效果。例如评分卡中的变量丰富的时候，其中核心变量是不能允许缺失，但是如果决策引擎没有对于的判断机制，在核心变量缺失时，其他变量没有缺失同时其他变量的得分较高，此时拉高了整体的评分卡的得分，最后的得分做出决策为通过，实际该客户因为核心变量缺失需要通过人工审核，因此在这种情形下并不能准确的判断客户的征信情况。那么决策引擎应该怎么去解决这个问题呢？
设计决策引擎产品下到规则集、评分卡的每一条决策判断，上到规则包、模型包的决策判断都需要进行数据信息值的计算，在决策引擎中的规则、评分卡配置上需要具备信息值的配置、信息值的阈值配置以及信息值的决策结果配置等。决策引擎在进行规则的判断的时候，首先应该计算的是信息值，然后在进行策略的运算，通过对缺失值的管控，实现更精准的风控效果。
决策引擎主要的用户是模型策略人员，风控策略伴随着业务的发生，会进行不断地调整、迭代，同时不同的业务场景所使用的模型策略也是不同的，因此决策引擎还需要满足模型版本管理、模型对比的功能，可以更方便用户配置操作、支撑更多的业务场景。
模型的优化、迭代是需要丰富的历史数据作为支撑，这里的历史数据可以分为两部分：一是传入决策引擎的元数据，二是决策引擎计算出来的结果数据包含规则、评分卡等数据。数据在传入决策引擎进行计算后需要对元数据和结果数据进行存储，这里的存储也会存在两种方式：一是缓存，这样可以避免同一个客户在规定的时间内重复调用三方数据，造成不必要的成本浪费；二是存储所有的风控数据，便于后期模型的调优、迭代，同时也可以用于贷中、贷后的管理。数据存储的功能，更多的规划在决策引擎的配套产品接口管理平台中，在后面决策引擎配套产品介绍中会详细的介绍。
实际业务中，风控的结果输出，不仅仅只是“通过”、“拒绝”、“人工审核”，还会有很多详细的内容包含触发的规则、预警的规则等，这就要求需要一个详细的风控报告输出，以备人工审核的人员获取数据，这也是决策引擎配套的风控报告产品。
参考以下博文：https://blog.csdn.net/qq_43036596/article/details/100697541