标签：Rete Joint CLC 智能 引擎 zz 规则 执行
上文介绍了复杂控制逻辑（Complicated Logic Control，CLC）的一个设计实例，包含了R0数据库发现、R1强规则、R2弱规则（包含模型评级和反欺诈算法）、R3浅层CLC以及R4深层CLC的功能设计。这个逻辑设计框架要实际的发挥作用则需要依赖一种被称为规则引擎的系统，该系统是从推理引擎发展而来的，它实现了业务决策和代码的分离，并可以高效的处理规则。
在规则引擎出现之前，许多企业建立IT团队，由他们接受来自业务部门的需求，提炼出业务规则并将其转化为代码写入到程序中。这种模式的产生是非常自然的，因为业务规则总是可以表达为If…Then…的逻辑表达式，而这种基本的逻辑表达式在各种程序语言中是必然存在的。但是随着公司业务的迅速发展，这种方式很快就会受到巨大的挑战，这种挑战主要来自两方面。
首先，调整业务规则需要进行大量的检查。越来越多的业务部门会提出需求，每次的变更和调整都要求IT团队重新审视所有的代码，确保逻辑的一致性和准确性，这种检查的工作量是非常巨大的。为了保证程序的可靠性，IT团队还需要对变更后的程序进行大量的测试，排除各种可能的Bug。
其次，规则的执行效率非常低下。当业务规则是以If…Then…的方式嵌入在代码中，程序需要顺序地逐条执行完所有的规则才能获得最终的结果。假设程序中存在100条业务规则，每条规则需要1s的执行时间（不考虑IO），那么一次规则集的检查和执行需要花费100s。 当然，如果可以将规则集以矩阵的方式进行计算判别（相当于进行并行计算），那么规则集的整理执行时间可以缩短到接近单条规则的时间（忽略使用矩阵运算的额外开销）。但是一个企业的业务规则通常不会那么简单，这里需要引入“推断（Inference）规则”的概念。如果A规则的结果是B规则的执行条件，那么B规则为推断规则，或者说B规则的执行与否依赖于A规则的执行结果。由于推断规则的存在，使得直接使用矩阵并行执行所有规则变得不可能，因为有些规则的执行条件一开始是”未知“的。因此程序中需要存在循环检查的机制：一旦有规则成功运行，那么程序需要检查所有的规则，看是否有新的规则可以被执行。可以容易的看出，这种检查-执行的方式会浪费大量的资源（为了少数可能被执行的规则而检查整个规则集）。
从业务层面上看，以上两方面问题导致了需求从提出到实施需要非常长的时间（通常需要1个月），并且系统处理规则的吞吐量是很有限的（大量的资源浪费在了没有价值的等待和检查上）；从成本上看，IT团队需要安排大量的人力对规则进行乏味而冗长的录入、检查和调试工作。
规则引擎的产生解决了业务规则系统耗时长、效率低的状况。目前所有主流的规则引擎都是基于Rete算法发展起来的，Rete算法是Forgy博士于1974年提出的一种高效组织并处理规则的算法。Rete算法需要先对规则集进行编译，建立起表达规则依赖关系的网络（Rete网络），并通过联合节点来组织规则。由于Rete网络最大程度的利用了重复被使用的数据，在数据更新时（或推断规则的条件被更新时）只检查相关的后续节点，从而大大提高了运行效率；而规则录入则被规范为具有固定格式的文档（例如DMN）,这使得业务人员也可以很方便的制定或修改规则，最重要的是发布这些规则不需要再调试程序了，整个业务规则系统完全可以由业务人员自行管理。
图1是Rete算法的工作原理示意图，可以看到规则运行所依赖的条件以属性的方式存在于数据对象之下。例如ObjectA可以是申请人，而A1则可以是年龄，并且这些属性是可以被多条规则复用的。Joint Node则负责把多个属性连接起来，指向某个具体的行动，这个行动的内容可以是任意的内容；其触发则是由其依赖的属性变化引发的。
图1 Rete工作原理图
Fig1. Working diagram of Rete
在图1中，A1，B1两个属性是当前已知的条件，最初只有Joint Node1对应的规则满足执行条件，于是Rete执行动作，对A2进行赋值。此时由于Object A的属性发生了变化，算法对依赖于A2的Joint Node进行检查（而不是对所有的Joint Node）。由于A2此时已经具有了值，而B1是之前已知的，因此Joint Node2对应的行为被执行（给B2赋值），进而触发了Joint Node3的检查和执行，并最终得到了Accept的结论。从这个例子可以看出，数据，规则的执行条件和行为被很好的分开，新增规则（Joint Node）可以视为对数据（属性）进行不同的组合，而算法只有当数据（属性）变动时才检查必要的规则，这种处理规则的方式无疑是非常高效的。
通过规则引擎，CLC的每一个子逻辑块都可以视为一个小型的Rete网络，把这些网络连接起来就形成了完整的风控规则系统。如图2所示，CLC中逻辑块所依赖的事实存放在基本信息、个人信用、CLC等对象的属性中，Rete算法根据规则的依赖关系编译生成Rete网络，有效的执行和管理规则。逻辑块的执行也不总是完全按照顺序进行，例如R1.1基本信息核查出错，那么就没有必要进行后续的检查（节约时间或者查询数据的费用），图中的红线就是代表这种异常的跳转。可以看到，CLC的逻辑块最终和Rete算法中的数据对象、连接节点（Joint Nodes）联系起来，最终产生了行动（Actions），这意味着CLC中蕴含的业务逻辑的完美落地。
图2 CLC 结合规则引擎的应用
Fig2. Application of CLC implemented by rules engine
近年来规则引擎的技术还在进一步发展，不仅能够提供规则的有效组织和运行，还能够通过机器学习自动建模发现新的规则。例如明策决策引擎，它是由美国硅谷团队开发的使用最新一代Rete算法（Rete-NT）的规则引擎，不仅具备了更有效的组织和运行规则的能力，而且提供了机器学习的功能，能够完成变量的离散化、变量选择、自动建模、模拟测试等一系列的功能，从而发现更多更好的规则。
李彦宏说：“AI技术能把人从重复、低效、繁重的脑力劳动中解放出来“。这是对AI更为准确的一种定义：机器视觉处理（例如CNN神经网络）应用在工厂质检上解放了质检员的繁重工作；机器语言处理（例如RNN神经网络）应用在自然语言上解放了人类大量查阅资料的工作；当前研究的自动驾驶也会在未来解决人类长时间驾驶的痛苦。规则引擎已经解放了程序员编写业务规则程序、检查代码以及测试发布的繁重、冗长以及痛苦的工作，CLC和智能规则引擎的结合则会进一步减少业务人员设计、检查业务规则的难度以及花费的时间，并通过机器学习发现新规则的方式使得人工和智能有机的结合起来，创造更大的价值。
余锴
数据科学家、人工智能和机器学习专家
曾在华为、惠普、SAP合作伙伴从事市场、咨询和数据科学领域工作，并在互联网金融行业有丰富的大数据建模、智能算法研发以及决策引擎设计经验
标签：Rete,Joint,CLC,智能,引擎,zz,规则,执行 来源： https://www.cnblogs.com/end/p/15399337.html
本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享； 2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关； 3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关； 4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除； 5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。