网络免费小说联盟

好书推荐|《决策知识自动化》-第三章:在决策服务中封装知识(一)

德先生 2018-06-19 13:32:42
欢迎点击上方“德先生”进行订阅!

内容提要
本书综合大量来源于业务流程自动化的主流应用场景,聚焦于组织管理及运营中经营决策的知识自动化这一主题,向读者展示如何在实践中应用知识自动化技术实施决策管理,以提高运营效率和组织收益

本书适合各企业CEO/CIO/IT架构师以及一切对知识自动化理论感兴趣的读者。


第3章概述了在决策服务中封装业务知识所需要的最为重要的几项技术(如业务规则、算法以及预测分析等)及其主要内容,并解释了这些技术的适用场景。然后阐明了如何使用由BPMS、预测分析模型和决策服务等构成的周期循环架构进行决策管理


注:在接下来的几周内,德先生将定期于每周四准时推送《决策知识自动化》的章节内容,欢迎感兴趣的朋友订阅德先生查看后续精彩内容。




众院士强力推荐、知识时代必读之作!





第三章:在决策服务中封装知识


人类的标志性特征之一即为语言,这是一种使用约定俗成的符号作为人类自身文化的一部分并用其进行交流的能力。自从我们的大脑进化到能够处理象征性姿势与言论,它便同时也具备了使用其他象征形式来传达和保存人类知识的能力。自此,人类文化的范围得到了进一步扩展,涵盖了史诗、歌谣、文本、图画、地图以及图表等。以文化形式流传下来的知识是具有进化价值的,它使得个体的成功经验可为他人所用,即便个体之间素未谋面。

尽管不再关乎生存或繁殖,知识依旧具有实用价值和经济价值,它赋予人类做事的能力。凭借一张地图,我就可以找到那些绘图者们曾经走过的、通往我从未到过地方的路线。严格地说,这种记录性的知识是仅仅介于两人之间的一种交流手段:一个人负责制定知识,而另一个人解读知识。但是,最近也出现了无需单方或双方参与的知识表示方法:
 
  • 一些形式的知识无需由人类解读,即可由机器直接执行。例如,使用道路网中的机器可执行知识,GPS导航系统可自动为你寻找抵达目的地的最优路线,并全程导航。


  • 一些形式的知识可以由机器生成。GPS导航系统使用的很多知识都是由系统从不同资源中半自动地编译和更新生成的。

 
业务流程中的决策自动化包括:识别并生成决策所需的业务知识,同时将业务知识编译成机器可执行的形式随后知识可被封装于执行决策的决策服务中,从而实现知识自动化。

本章简要介绍了业务流程自动化中用于构建决策服务的三项最常用的技术内容:业务规则、算法和预测分析模型,它们均可使用机器可执行知识的形式进行表示。业务规则和算法均为机器可直接执行的知识形式,但需要由人类专家构建。预测分析模型则更进一步:它允许机器使用历史数据自动生成新的机器可执行知识

用于生成、部署和执行决策服务的这类软件工具通常被称为业务规则管理系统(Business Rules Management Systems,BRMS)或业务规则引擎(Business Rules Engine,BRE)。其实这两个术语都有一点误导性,因为(后文将介绍)业务规则通常只是整个服务解决方案的一部分,甚至是极小的一部分。一个有些过时但是准确得多的术语是“基于知识的系统”(Knowledge-Based Systems,KBS)。它涵盖了可进行业务知识建模并将知识部署于决策服务之中的任何系统。但是,我认为使用目前业界普遍应用且易于理解的术语则更为重要。所以,本书依然使用BRMS来表示生成和管理业务知识的系统,并使用BRE来表示BRMS中真正执行知识的组件或模块。



3.1 业务规则

业务规则是一个逻辑语句,它使用一组条件判定一个结论。业务规则通常使用如下形式表示:“ IF <条件> THEN <结论> ”。以下是业务规则的一些例子,均出自于我在不同领域参加过的实际项目。

流程自动化中的许多业务规则常用于路径选择决策,如第2章所示的发放模板流程中的规则,举例如下。

  • IF 申请人信用报告中的客户纠纷指示器显示为“Y”, THEN 申请的流通路径为“拒绝”。


  • IF 申请人正在经历债务咨询且其贷款目的为负债整合,THEN 申请的流通路径为“待定”,且参考指标为“信用”。


  • IF 保险资格在接受治疗日期之前或在入院日期之前被取消, THEN 索赔的流通路径为“拒绝”。


  • IF 一项医疗索赔,但医生并未提交阐明医疗细节的索赔表的第二部分, THEN 索赔的流通路径为“搁置”。


但是业务规则也可用于许多其他类型的决策。以下为一些示例。

  • IF 资产评估日期早于贷款申请日期超过100天, THEN 资产评估结果无效。


  • IF 无担保贷款金额小于规定的无担保贷款金额上限 and 贷款价值比小于规定的贷款价值比的上限,THEN 抵押是安全的。


  • IF 申请类型为“已评分” and 请求的产品包括个人贷款或信用卡 and 请求的产品不包含现金账户,THEN  交叉销售现金账户。


  • IF 信用卡类型为“白金”and该卡的信用额度低于2000,THEN 销售行为降级为“普通”类型。


  • IF 申请人为老客户 and 申请人近期信用数据有效 and 申请人最近的信用评分并未介于595与629之间,THEN 所需的信用机构服务级别为“迷你”。


  • IF 申请人是新客户 and 申请人的就业情况显示其为合同工人或个体经营者and 风险等级低于3, THEN 保证金不能低于贷款数额的15%。


  • IF 理赔类型为怀孕保险 and 条件编码为660或670,THEN 起保日期为入院日期减去52周。


  • IF 医疗项目为MRI扫描 and 入住医院并未在医疗保险许可的MRI中心列表上,THEN该项目不予赔付。


如上所示,规则是离散且具有明确独立性的语句,每一条规则表达可执行业务知识的一个原子活动。独立性,意味着每一条规则的意义都完全包含在自身之中,并不依赖于其与其他规则之间的关系。这在传统的“IF…THEN…”编程语言中是不成立的。因为“IF…THEN…”语句在编程语言中是顺序执行的,修改或移除其中任一语句都可能影响后续语句的执行结果。业务规则(在规则集中)可用顺序无关的方式被定义。这简化了表达、实现和维护业务知识的任务,并允许业务领域专家及业务分析师直接使用规则,而无需IT开发人员的参与。

此处只对业务规则进行简单的介绍。更多内容请参考Ronald Ross的Principles of the Business Rule Approach1,Barbara von Halle的Business Rules Applied2,和Ian Graham的Business Rules Management and Service Oriented Architecture3。

3.1.1 对象模型

业务规则有一个非常重要的特征,即它由对象模型、事实模型及领域本体等结构语言中的词汇写成。对象模型是一个非常贴切的术语,因为它为规则中提及的事物提供了一个模型:一个精心为特定业务知识领域设计的模型。所以,对于一组判断医疗健康保险索赔的业务规则,该模型需要包含诸如索赔、医疗项目、病患、医院及医生等对象。

许多关于对象之间自然关系的逻辑,被包含于本体论而非规则中。例如,一项索赔与某一名病患正在医院进行的一系列医疗项目有关。规则中的条件和结论涉及的数据项从来都不是简单的变量,而是对象一些属性,例如病患的年龄或进行医疗项目的日期。这简化了规则,并使其可以使用类似自然语言的形式表达,从而易被业务领域专家所理解。

对象模型可以继承:一个对象可以是另外一个对象的类型或子类。例如,一名会诊医师可被定义为是医生的一种类型。在这种情况下,一名会诊医师可继承医生的所有属性,并且能够以此为基础扩展自身的属性。这即表示会诊医师可以使用医生的所有属性(如专业)进行描述,同时可使用会诊医师独有的属性(如所属医院和科室)进行描述。

对象模型中的对象,通常被更准确地描述为类,即它们表示一个特殊类型中的一组实体。类可以实例化:任何一个对象的实体都是对象所属类的实例。实例也会继承其“父对象”的所有属性。例如,我的猫“咪咪”就是猫这个对象的一个实例,而猫则是动物的一个子类,等等。

3.1.2 推理策略

可执行此类知识的系统被称为业务规则引擎(BRE)。BRE对每条业务规则进行一次单独的逻辑推理:如果满足规则条件,那么其返回的规则结论为真。有些条件可根据输入数据的值进行直接判断,有些则依赖其他规则返回的结果。这意味着这些规则可以形成一个包含许多条规则链的逻辑网络。在这样的一个逻辑网络中,主要存在两种可行的推理策略:正向链式推理和逆向链式推理。商业中可用的大多数BRE都在一定程度上支持这两种推理策略:

  • 在正向链式推理中,BRE从初始的已知事实集合出发,不断地对规则进行判断,直到找到一条满足所有条件的规则为止。然后,BRE触发该规则,并将其返回的结论加入到已知事实集中,作为下一步推理的依据。重复此步骤,直至无法得出更多的推理结果。这种策略也被称为“数据导向”的推理,因为推理过程是从最初的事实数据出发,通过对规则链进行逐步推导,最终得出结论。若已给定一组固定的初始数据集,并需要以此为基础执行所有可能的推理,此时,正向链式推理即为最佳推理策略。该策略在本书讨论的领域中十分常见。


  • 在逆向链式推理中,BRE首先假设一个命题成立。系统先找到一条以该命题作为结论的规则,然后判断该规则包含的所有条件是否均可被满足。若其中某些条件涉及其他规则的结论,则必须依次评估相应的规则,直到完成整条规则链的推理。这种策略也被称为“目标导向”推理,因为该过程从期望的目标出发,不断地寻找支持目标结论的数据。若数据必须根据具体需求进行获取(例如,通过向用户提出一个问题或者查询一个外部数据库),并且只对特定结论感兴趣,那么此时,使用逆向链式推理策略更加合适。通常,逆向链式推理被用于诊断分析,在考虑下一个诊断之前,需首先对当前假设诊断进行调查和排除。


但是这些基本策略都颇为朴素,在一个包含上千条规则的知识库中进行应用时,就会变得非常低效。大多数BRE使用非常复杂的算法来提升大规模规则集上的推理速度。其中最为重要的一个算法是由Charles Forgy开发的Rete。4目前大多数BRE都支持Rete或其新版本Rete II和Rete III。实际上,Rete将所有规则预编译到一个可以表达规则之间依赖关系的网络中,然后基于该网络选择最佳调度对规则进行评估。给定当前已知条件,该网络可在每次有规则被触发时对自身进行调整,这使得只有被触发的规则才会被安排评估。

3.1.3 规则集和规则隐喻

另外一种提高推理效率的方法是将所有规则划分为一个个规则集(越小越好),并且每次仅对单个规则集进行评估。通过使用一个更高阶的规则集或一个程序流程图,我们可对“何时应用某一规则集”这一逻辑进行定义。规则集与决策服务制定的决策之间可能存在某种很强的联系:例如,每个规则集制定一个决策,并只包含那些支持该决策的规则。除提高效率之外这样做有其他好处。首先,它允许在规则集或决策层面——而不仅仅是在整个决策服务层面——重用知识。其次,对于业务领域专家们来说,它简化了规则的定义和维护。本书将在第4章和第6章着重解释如何在规则集与决策之间建立关联。

一旦使用规则集的形式组织规则,即可使用其他形式或隐喻,对规则进行表示,从而为业务用户提供方便。主要存在两种形式的规则隐喻:决策树和决策表。




1. 决策表


若某一规则集中的所有规则都满足:


(a) 规则中的条件均依赖于同一个小规模输入变量集
(b) 规则的结论均为同一输出变量

则该规则集可很方便地表示为表的形式。决策表为条件中的每个属性提供一列输入取值,并为结论中包含的每个属性集提供一列输出。表中的每一行表示一条业务规则。当规则不会用到某些条件属性时,其对应表格单元被置为空,或标记为“不可用”。

表格的形式十分便于业务用户理解,且易于检查规则是否已涵盖所有决策场景。在系统实际运行时,BRE将每个决策表作为一个规则集,并将每一行作为一条规则进行评估。表3-1展示了一张决策表。该表使用两个条件——抵押物品和应急储备金,给出两个结论——信用级别和最大贷款价值比。


2. 决策树

当规则集中的规则共享一些条件,且这些规则均用于判定某单一属性的取值时,它们有时可被方便地表示成决策树的形式。一个决策树通过一系列测试对一个案例进行归类:树中的每个节点测试一个单独的属性,节点延伸而出的树枝则表示该属性的所有可能取值。末端节点(又称为树“叶”)表示所有可能的结论。决策树向相关规则的映射并不像决策表那样显而易见:树中的每条路径等同于一条规则,路径上的每个节点(除叶节点外)都是规则中的一个条件。

对于业务用户来说,决策树也是一种比较自然的规则表达形式,特别是对案例进行分类或细分的那些逻辑而言。图3-1展示了一棵简单的决策树(大多数决策树都会有更多的树枝)。这棵决策树决定发放贷款的额度区间。它等同于一个包含10条规则的规则集,每个叶节点对应一条规则。其中的一条规则如下:

  • IF 申请类型为新 and 细分结果为高档 and 申请分数≤745 THEN 额度区间为C。


体现这条规则的路径已在图中使用粗体实线标出。

注意,对于不同案例,需使用不同的测试并设定不同的测试次数:新客户的额度区间可根据细分结果和申请评分进行判断,而老客户的额度区间则仅需依据其行为评分进行判断,即时客户可通过判断其策略编码和行为评分为之选择相应的额度区间。所以,决策树是非对称的。

规则的对称属性决定了究竟该选择决策表还是决策树作为其规则隐喻。强对称性的规则(即每条规则都具有相同数目的条件,且条件基于相同的共享变量)可很自然地表示为决策表的形式;若将强非对称性的规则表示成决策表的形式,则会留下很多“不可用”的单元,所以此类规则应使用决策树表示。

决策表和决策树均要求规则是完备的且互斥的。完备意味着规则必须能够涵盖所有可能的决策场景;互斥意味着在任意场景中仅能有一条规则被触发。对于决策表来说,若其所有可能的列值组合都存在已被定义好的结论,则它是完备的;若对于任一场景都只有一条规则适用,则它是互斥的。对于决策树来说,如果对于任一案例都存在唯一决策结果,则决策树是完备并且互斥的。


不以决策表或决策树形式表示的规则集仍须具有完备性,但只要规则集是一致的,则无须具有互斥性。一致性表示:当一个案例同时触发了多条规则并产生了不同结论时,存在一种可以鉴别出正确输出结果的机制。这种机制被称为“冲突消除”机制。这种特定的方法依赖于业务知识领域。例如,在一个路径选择规则集中,有些规则提议“拒绝申请”而有些规则提议“待定”。此时可能出现这种情况:一个案例同时触发了这两条规则,但此时我们要求给出一个唯一的决策。在许多场景中,可通过设定一组优先级别(例如,“拒绝”优先于“待定”,“待定”优先于“接受”)来解决这个问题,这种优先关系可被建立在本体论中。




3.1.4 产生式规则及约束式规则


2002年,业务规则组织(BRG)发布了一则公告5,某种意义上宣告了业务规则的独立地位。这份文件是一个言简意赅的关于业务规则使用原则的声明,它对于规范人们认识和讨论业务规则的方式产生了很大的影响。对于初次接触业务规则概念的读者,我建议将这份公告作为学习的入门教程。

尽管我发自内心地赞同公告中的大部分内容,但此处还是需要强调一下其中的两项原则。因为,乍看上去,这两项原则与我在本书中使用的方法并不是十分一致。

4.5 一条规则不同于为其定义的任何执行。规则与规则的执行是两个独立的问题。

4.6 对规则的定义应该独立于规则执行的人员、地点、事件及执行方式等具体内容。

3.1节一开始列举的4条决策路径的示例规则与这两条原则并不相符,因为示例规则中合并了业务政策与“如何执行业务政策”。BRG坚持认为业务规则应该是纯粹的陈述性约束,带有单独的“执行机制来表述规则被打破后会产生什么后果”。6我们用第一个例子来看一下,此规则将会产生什么影响:

  • IF 申请人信用报告中的客户纠纷指示器显示为Y,THEN 申请的流通路径为“拒绝”。


以这种方式表现的规则被称为“产生式规则”,因为对它进行评估时会产生一个新的数据项(在这个案例中,新产生的数据项为申请流通路径的一个建议值)。若使用约束重写这条规则,即可写为:

  • 在申请日期当天,申请人必须没有任何客户纠纷指示器显示为“Y”的机构报告。


此外,还需要有一个分离的执行规则表述:若在申请时打破了这条约束规则,则申请人应被拒绝。

根据我的经验,极少有情况需考虑业务约束中的抽象陈述。大多数实际情况中,业务规则仅在负责执行它们的决策点上被评估,并可能仅在这一刻两者是相关的。这也在我们的示例中成立:仅在考虑申请流通路径时会使用“拒绝正处于机构纠纷中的申请人”这一条业务政策。一旦产品已被销售,即使客户随后与某一机构产生了新的纠纷,产品也不会被取消。所以在这个案例中,没有必要为一条仅在申请时刻才会被执行的规则来建立一个通用的业务约束。这条约束规则可作为制定决策所需的知识的一部分。

该示例并不特殊:大部分规则都是或者仅在一个单独的决策点上被调用,或者在不同项目版本中的不同决策点上被调用。正因如此,本书使用的方法为:为每个决策点单独定义其所需的决策规则,并将规则定义为同时包含使用约束及执行机制的产生式规则的形式。再次强调,这并不冲突,实际上,几乎所有用于业务流程自动化产业的规则都是使用这种方式定义的。

这种以决策为中心的方法生成的业务知识,并不如以抽象业务约束表示的业务知识灵活。例如,不能使用多种方式查询规则,且它们只能用于制定其所定义的决策,但该方法简单易行。通用业务政策约束所需的逻辑和本体论则相当复杂。例如,OMG定义了一种标准业务词汇及业务规则的语义(Semantics of Business Vocabulary and Business Rules, SBVR),其内容长达422页7。具体的决策规则实施起来更加方便且执行起来更为高效,同时,我认为这也更易于对业务进行描述。

这并不是说泛化和重用规则就没有任何价值。我们的示例业务规则可能会在业务流程的两个决策点上接受检查,假设这两次检查之间隔了很长一段时间(例如,一个客户首先拿到了申请,然后1个月后才提供正式申贷额度)。如果是这样的情况,该规则就应该包含在一个通用规则集中,然后使用决策服务对其进行封装,并使用一个通用对象模型对其进行表示。这种通用规则集可对一些一般性的决策,如“某一申请是否合格”进行判断,而这一判断结果同时可被其他规则在对应的决策点判断申请流通路径。这在一定程度上区别了政策和政策执行。同时,我还注意到,甚至在SBVR的一个租车公司(EU-Rent)8的工作案例中,规则也被划分成了可在不同时间点上被使用的规则集,并且包含如“实际取车日期/时间”和“返还车辆日期/时间”这种表达方式的规则,这就将规则绑定在了特定的决策点上。所以,正如我们在第2章末尾所观察到的,也许这两种方法并非像一开始看起来那样差异巨大。


未完待续……

由于版权限制,本文只列出《决策知识自动化》第二章“在决策服务中封装知识”的部分内容,在 “3.2 算法”和“3.3 预测分析建模” 章节中,Alan概述了 算法以及预测分析的主要内容,并解释了这些技术的适用场景


感兴趣的读者可点击“阅读原文”进入京东自营店铺进行购买!


声明:
本文摘编自今年1月份出版的新书《决策知识自动化(Knowledge Automation)》(Alan N.Fish著,王飞跃、王晓、郑心湖等译),由人民邮电出版社享有中文版权。本文授权“德先生”微信原创首发。欢迎原文原版转载,并注明原作者姓名以及“来源:德先生(D-Technologies)微信公众号”。


相关阅读
 







识别封面二维码,加入“知识自动化专题讨论组”,享受知识盛宴!


长按识别二维码,
获取更多精彩内容!
点击“阅读原文”,进入店铺购买!

Copyright © 网络免费小说联盟@2017