漫话规则引擎(1): 推理机和规则引擎

本文最新版已更新至:http://thinkinside.tk/2012/03/20/rule_engine_1.html

问题的提出

假设这样一个场景:

某公司生产两种型号的设备,M{m1,m2},两种型号都支持四种功能F{f1,f2,f3,f4},但开放哪些功能取决于出厂设置。在出厂之前需要对设备进行多方面的测试,目前定义了五种测试T{t1,t2,t3,t4,t5},要执行哪些测试取决于型号。对每台设备的每种测试都有一个最晚执行日期D的要求,D取决于设备要执行的测试项。

由于业务需要,每种型号的设备要进行哪些测试、D与要执行的测试项的关系会经常变化。比如其中的一组规则是:

测试项规则:

if m=m1, exec(t1,t2,t5)

if m=m2 and m.hasfunction(f1), exec(t2,t3)

if m=m2 and m.hasfunction(f2), exec(t4,t5)

if m=m2 and m.hasfunction(f3), exec(t3,t4)

if m=m2 and m.hasfunction(f4), exec(t1,t3)

测试时间规则(其中d表示天数,如3表示最晚执行日期为3天后)按照优先级从高到底如下:

if m.todo(t1), d=3

if m.todo(t2),d=7

if m.todo(t3),d=10

if m.todo(t4),d=12

if m.todo(t5),d=14

 

要实现的功能是,根据给定的规则和一组设备,得出每个设备的测试项和测试时间。

 

即使不考虑规则的变化,要实现这样的业务规则也是非常繁琐和乏味的。而为了避免频繁的部署,规则必须能够以某种形式进行定义和配置,不能硬编码实现。(当然,如果你采用OSGI架构,定期更新规则的bundle我也无话可说)。

推理机和规则引擎

上面例子中的问题是典型的推理问题:根据已有的知识,分析实际情况并给出结论。如果由程序来处理推理过程,那么这个程序就叫做推理机/推理引擎(Inference Engine)。推理机是专家系统(专家系统是人工智能的一个分支)的核心模块。

NewImage

 

推理引擎根据知识表示的不同采取的控制策略也是不同的,常见的类型包括基于神经网络、基于案例和基于规则的推理机。其中,基于规则的推理机易于理解、易于获取、易于管理,被广泛采用。这种推理引擎被称为“规则引擎”。

在规则引擎中,将知识表达为规则(rules),要分析的情况定义为事实(facts)。二者在内存中的存储分别称为Production Memory和Working Memory,如下图:

NewImage

rules和facts是规则引擎接受的输入参数,而规则引擎本身包括两个组成部分:Pattern Matcher和Agenda。Pattern Matcher根据facts找到匹配的rules,Agenda管理PatternMatcher挑选出来的规则的执行次序。在外围,还会有一个执行引擎(Execution Engine)负责根据Agenda输出的rules执行具体的操作。

其中Pattern Matcher是规则引擎负责推理的核心。和人类的思维相对应,规则引擎中也存在两种推理方式:正向推理(Forward-Chaining)和反向推理(Backward-Chaining)。

正向推理也叫演绎法,由事实驱动,从 一个初始的事实出发,不断地应用规则得出结论。首先在候选队列中选择一条规则作为启用规则进行推理,记录其结论作为下一步推理时的证据。如此重复这个过程,直到再无可用规则可被选用或者求得了所要求的解为止。

反向推理也叫归纳法,由目标驱动,首先提出某个假设,然后寻找支持该假设的证据,若所需的证据都能找到,说明原假设是正确的;若无论如何都找不到所需要的证据,则说明原假设不成立,此时需要另做新的假设。

 

规则引擎是一种相对简单的推理机,可以将规则引擎作为一种组件潜入到应用系统中,从而将业务决策从应用程序代码中分离出来,并使用预定义的规则语言编写业务决策。使用规则引擎带来的好处是:
1. 避免业务规则变化带来的重新编译和重新部署的问题;
2. 使用声明性编程方法,大大提高业务规则代码的可读性;
3. 开发人员不需要过多关注业务逻辑(根据各种情况判断发生了什么事情),可以专注于应用逻辑(在发生了什么事情时进行什么样的处理)

posted @ 2012-03-20 20:54  心内求法  阅读(11279)  评论(2编辑  收藏  举报