Artificial intelligence CLIPS编程事实和规则库大小

剪辑的可伸缩性是什么？这是剪辑中规则和事实数量的最大限制是什么？我正在使用CLIPS 6.24，但无法上传一百万个事实

片段中rete算法的实现在规则之间共享公共模式，因此模式匹配性能将在添加规则时合理扩展。当规则之间没有共享模式时，将出现最糟糕的性能

版本6.3中还进行了大量改进，以提高大量事实的性能：

         CLIPS (V6.24 06/15/06)
CLIPS> (timer (loop-for-count (?i 100000) (assert (data ?i))))
3.78414106369019
CLIPS> (reset)
CLIPS> (timer (loop-for-count (?i 1000000) (assert (data ?i))))
885.884355068207
CLIPS> 

         CLIPS (6.30 3/17/15)
CLIPS> (timer (loop-for-count (?i 100000) (assert (data ?i))))
0.136654
CLIPS> (reset)
CLIPS> (timer (loop-for-count (?i 1000000) (assert (data ?i))))
6.046085
CLIPS>

我没有花太多时间来优化大型规则集的加载，因此很可能这个或其他相关的开发功能不能很好地扩展。我使用一个商业产品开发了一个专家系统，它有几千条简单的规则。性能和编译时间是可以接受的，并且可能会扩展得很好，但是桌面客户端和规则存储库之间的同步速度非常慢，而且有缺陷。我无法想象在不改进产品组件的情况下尝试扩展该应用程序

除了事实和规则的数量之外，还有许多因素影响可伸缩性，特别是规则的设计、它们的复杂性以及事实和规则模式之间的关系。在评估工具时，最好的办法是编写一个简单的程序，生成大量与您设想编写的规则类似的规则，以及与这些规则相匹配的相关事实，并使用这些规则测试可伸缩性

我写过的最大的CLIPS系统有大约600条复杂的规则，处理了成千上万的事实，并且CLIPS 6.24的性能可以接受。我不记得有人提到过大得多的系统，但实际上我不认为你能用6.24扩展到一百万个事实，除非你对可接受的性能很慷慨

---

在6.3中，我认为您可以构建一个至少包含数千条规则和几十万条事实的系统是合理的，但同样，您最好的选择是以编程方式生成规则和事实，并测试性能

事实上，我正计划使用CLIPS从一个大数据集中提取信息。例如：-如果我们有（name college place）形式的事实，那么（？name collegeA？place）将返回属于collegeA的所有人。这比使用传统的RDBMS更可行吗？（考虑到CLIPS可能处理也可能不处理大型数据集）——将单个规则的条件与事实集合相匹配类似于进行数据库查询。当您有多个规则时，规则引擎（如CLIPS）会增加两个好处。首先，因为您有多个条件，所以要进行多个查询，因此规则引擎将共享查询的类似部分，以提供更好的性能。第二，在允许执行每个规则时，重复执行同一组查询，因此，规则引擎会记住查询结果，并以增量方式重新评估受影响的查询部分。@GaryRiley非常感谢您的帮助。非常高兴收到专家系统专家的帮助。我仍然有几个挥之不去的问题：1。对于此类数据，CLIPS是否比RDBMS或图形数据库更好？二,。我还看到了几篇关于神经专家系统的文章。我对它们不是很清楚，你在这方面有什么资源吗？如果你所做的只是在一个大的预定义数据集上进行查询，我会使用RDBMS。