1. 背景综述
规则引擎主要实现的功能是存储、分类和管理规则,执行规则、推断其它事实的应用程序。其中的规则主要是指企业或商务业务逻辑、法律条款等。在规则引擎发展的过程中,Rete算法和Prolog语言是两个重要的理论分支,多数规则引擎都是基于以上二者扩展而来的。在工业活动铸造中,发展时间较长、应用广泛的两个体系是Clips体系和Prolog体系。
Clips是美国航空航天局NASA- JOHNSON太空中心为弥补LISP 语言的不足而开发的C语言内核的专家系统。它的推理机是基于正向推理(Rete算法)的控制策略,即在事实的基础上通过设定的规则推演新的事实。因为LISP语言编写规则复杂、引擎不支持反向推理等原因也在一定程度限制了它的发展,但在其他语言开发(javaEE、Python等)的规则引擎仍有很多参考、引用了Clips,包括Drools、Jess、PyClips等。
Prolog语言基于谓词逻辑的理论。最基本的写法是定立物件与物件之间的关系,之后可以用询问目标的方式来查询各种物件之间的关系,进行匹配及回溯,找出所询问的答案。因而Prolog具备作为规则引擎的充分条件,也有若干开源项目(java为主)沿用其思路设计规则引擎,如tuProlog、jena等。下文所提到的Pyke,普遍说法其前身也是Prolog。此外,有文献提到prolog基于Markov算法。Markov算法可以作为规则引擎的基本准则,但是如果系统中存在着大量的规则,那么效率就会变低。
针对项目开发的实际需要,依据 “Python语言驱动引擎、规则语言语义全面、时间开销适中”的原则选取规则引擎,具体操作过程中选择了Pyke和PyClips分别进行研究,二者分别对应上文提到的Prolog体系和Clips体系,有一定代表性。经过手册研读和实验测试,目前可得到的结论是:PyClips在规则表达和性能效率方面优于Pyke,更符合应用开发的需要。具体分析见下文。
2.PyClips与Pyke的规则表达方式比较
2.1 Pyke的规则描述方式和特性
Pyke的优势、特点:
l 支持正向推理和反向推理两种推理方式,可以针对不同问题选用不同方式定义规则;
l 可以在规则中嵌入Python代码段补充描述;
l 专用谓词较多,如first,notany等可以简化表达。
Pyke的不便、局限:
l 数据倾倒方式单一,只显式支持将结果推送到控制台输出(只能间接从其内部取得数据List);
l 不支持批量的事实导入;
l 正反向推理不能在同一个规则库中并存。
2.2 PyClips的规则描述方式和特性
PyClips的优势、特点:
l 在规则定义环节,支持声明函数。支持OO(面向对象):包括类的定义,模板(类似C++中的template)的定义。针对未来复杂的规则描述可能适用;
l 规则定义时,支持事件触发;
l 支持动态地撤销事实或规则(不可逆,需谨慎)。
l 互动性良好,方法完全“继承”自0Clips。PyClips相当于对Clips做了Python的“客户端”封装。运行时,在内存中既有PyClips的存在,也有Clips的存在。因而只要Clips支持的功能,都可以由PyClips发送指令操作Clips。
PyClips的不便、局限:
l 规则描述使用LISP语言,上手难度较高(例如数值计算式的书写、各关键字的语法格式);
l 只显式支持正向推理。相关英文文献也指出Clips本身不能使用反向推理,只有部分中文文献给出了通过事件触发来自定义反向推理的方案,但可重现性都很差,没有一个完备的解决方案目前。所以保留意见认为,PyClips不支持反向推理;
l 不支持批量的事实或规则导入;
3. PyClips与Pyke的性能比较
3月20日-3月22日,Pyke性能测试数据截取,见表1、表2:
| 侧重较多事实 |
|
规则数 | 事实数 | 时间开销(秒) |
5 | 10000 | 21 |
10 | 10000 | 27 |
5 | 20000 | 65 |
10 | 20000 | 96 |
| 侧重较多规则 |
|
规则数 | 事实数 | 时间开销(秒) |
500 | 500 | 23 |
600 | 500 | 28 |
700 | 500 | 32 |
800 | 500 | 37 |
900 | 500 | 42 |
1000 | 500 | 46 |
1100 | 500 | 51 |
1200 | 500 | 55 |
| 均等 |
|
规则数 | 事实数 | 时间开销(秒) |
500 | 500 | 23 |
600 | 600 | 34 |
700 | 700 | 46 |
800 | 800 | 59 |
900 | 900 | 73 |
1000 | 1000 | 88 |
表1
规则数 | 事实数 (运行时加载) | 事实 加载时间(秒) | 反向推理 时间(秒) |
1 | 20000 | 16.656 | 1.18 |
5 | 20000 | 16.828 | 1.40 |
10 | 20000 | 18.588 | 1.678 |
15 | 20000 | 17.996 | 1.92 |
20 | 20000 | 17.987 | 2.324 |
25 | 20000 | 16.021 | 2.434 |
30 | 20000 | 15.959 | 2.699 |
表2
3月27日,PyClips性能测试,见表3:
规则数 | 事实数 (运行时加载) | 事实 加载时间(秒) | 正向推理 时间(秒) |
1 | 20000 | 3.516 | 5.514 |
5 | 20000 | 3.314 | 6.024 |
10 | 20000 | 2.892 | 6.566 |
15 | 20000 | 2.934 | 7.244 |
20 | 20000 | 3.445 | 7.472 |
25 | 20000 | 2.832 | 7.918 |
30 | 20000 | 3.116 | 9.168 |
表3
将3张表中红色的数据行进行对比可以发现:
l 在事实加载环节上,两种引擎都只能逐条加载, PyClips的加载效率远高于Pyke;
l 客观环境不变,推理方式及引擎算法不同的情况下,推理效率排序应为:
Pyke反向推理时间开销 < PyClips正向推理时间开销 << Pyke正向推理时间开销
虽然Pyke在推理阶段(2万条事实数据)可以通过推理方式同比节约4-6秒,但它在事实加载阶段比PyClips慢12-14秒。
时间开销应是所有环节消耗时间的总和,故而在实际使用中能明显感觉到PyClips的运行速度优于Pyke。
原文链接:https://blog.csdn.net/u010159842/article/details/78889576