我刚刚完成了我称为PHREAK的新规则算法的一些高级文档，这是混合推理中的一个文字游戏。 它仍然有点粗糙和高水平，但希望仍然很有趣。 它建立在ReteOO之上，非常好阅读。

ReteOO算法

ReteOO是在3、4和5系列发行版中开发的。 它采用RETE算法并应用了众所周知的增强功能，现有的学术文献都涵盖了所有这些增强功能：

• 节点共享
  共享同时应用于Alpha和Beta网络。 Beta网络共享始终来自根模式。

• 字母索引
  具有许多子级的Alpha节点使用哈希查找机制，以避免测试每个结果。

• Beta索引连接，不存在节点和存在节点使用哈希索引它们的内存。 这减少了相等检查的联接尝试。 最近，范围索引已添加到“不存在”中。

• 基于树的图
  联接匹配不包含对其父项或子项匹配的任何引用。 删除将不得不再次重新计算所有联接匹配，这涉及到重新创建所有那些联接匹配对象，以便能够找到应删除元组的网络部分。 这称为对称传播。 树形图提供了父级和子级引用，因此删除仅需遵循这些引用即可。 这是不对称传播。 结果更快，对GC的影响更小，并且更可靠，因为值的更改不会在不通知引擎的情况下导致内存泄漏。

• 就地修改
  传统的RETE将修改实现为删除+插入。 这将导致所有联接元组都经过GC处理，其中许多作为插入的一部分再次被重新创建。 相反，就地修改传播为单遍，检查每个节点

• 反应性
  也称为“新触发条件”。 允许更精细的反应性来更新。 模式可以对特定属性的更改做出反应，而忽略其他属性。 这样可以减轻递归问题，并有助于提高性能。

• 子网
  否，“存在”和“累积”可以各自具有嵌套的条件元素，这些条件元素构成了子网。

• 向后链接
  支持用于反向链接的Prolog样式派生树。 该实现是基于堆栈的，因此对于大型图不存在方法递归问题。

• 懒惰真相维护
  真相维护会产生运行时成本，无论是否使用TMS，都会产生运行时成本。 惰性TMS仅在首次使用时将其打开。 此外，它仅针对该对象类型启用，因此其他对象类型不会产生运行时成本。

• 基于堆的议程
  议程使用二进制堆队列按显着性对规则匹配进行排序，而不是使用任何线性搜索或维护方法。

• 动态规则
  可以在运行时添加和删除规则，而引擎仍将填充数据。

PHREAK算法

Drools 6引入了一种新算法，试图解决RETE的一些核心问题。 该算法不是从头开始重写的方法，它结合了ReteOO的所有现有代码及其所有增强功能。 尽管PHREAK是RETE算法的改进，但它不再被归类为RETE实现。 就像动物进化超过特定点并改变关键特征一样，该动物也被归类为新物种。 无论优化如何，有两个关键的RETE特征可强烈识别任何衍生菌株。 这是一个渴望的，面向数据的算法。 在插入，更新或删除操作期间完成所有工作的位置； 急于产生所有规则的所有部分匹配。 相比之下，PHREAK被描述为一种懒惰的，面向目标的算法。 其中部分匹配会被严重延迟。

RETE的这种渴望会导致大型系统中的大量用户流失，并浪费大量工作。 浪费的工作归类为不会导致解雇的匹配工作。

PHREAK受到许多算法的启发。 包括（但不限于）LEAPS，RETE / UL和面向集合的匹配。 PHREAK具有ReteOO部分中列出的所有增强功能。 此外，它还添加了以下增强功能集，将在以下各段中进行详细说明。

• 三层上下文记忆； 节点，段和规则存储器。
• 基于规则，分段和节点的链接。
• 懒惰（延迟）规则评估。
• 孤立的规则评估。
• 面向集合的传播。
• 基于堆栈的评估，包括暂停和继续。

当PHREAK引擎启动时，所有规则都被认为是未链接的，因此，当规则未链接时，将不会进行任何规则评估。 进入Beta网络之前，插入，更新和删除操作已排队。 根据最有可能导致解雇的规则，使用一种简单的启发式方法来选择下一个评估规则； 这会延迟评估和触发其他规则。 尽管尚未完成任何工作，但只有在规则中填充了所有正确输入后，该规则才被视为已链接。 而是创建一个代表规则的目标，并将其放入优先级队列中。 这是由显着性命令的。 每个队列本身都与AngendaGroup相关联。 只有活动的AgendaGroup会检查其队列，以最高显着性弹出规则的目标，并将其提交评估。 因此，完成的工作从插入，更新，删除阶段转移到fireAllRules阶段。 仅评估为其创建目标的规则，而根据这些事实进行的其他潜在规则评估将被延迟。 在评估各个规则时，仍然可以通过分段过程来实现节点共享，这将在后面说明。

RETE中每次成功的加入尝试都会生成一个元组（或令牌，或部分匹配），该元组将传播到子节点。 因此，它被描述为面向元组的算法。 对于到达的每个子节点，它将尝试与该节点的另一侧进行联接，再次，每次成功的联接尝试都将立即传播。 这将产生下降递归效果。 当节点网络从进入beta网络的点到所有可到达的叶节点上下左右波动时，对节点网络进行处理。

PHREAK传播是面向集合（或面向集合）的，而不是面向元组的。 对于正在评估的规则，它将访问第一个节点并处理所有排队的插入，更新和删除。 将结果添加到集合中，并将该集合传播到子节点。 在子节点中，所有排队的插入，更新和删除都将被处理，并将结果添加到同一集合中。 完成后，该集合将传播到下一个子节点，依此类推，直到到达终端节点。 这将创建一个单一的管道类型效果，该效果与当前正在评估的规则隔离。 这将创建批处理效果，可以为某些规则构造提供性能优势。 例如具有累积作用的子网。 将来，它将依靠多种方式来利用多核计算机。

链接和取消链接使用基于网络分段的分层位掩码系统。 构建规则网络后，将为由同一组规则共享的节点创建分段。 规则本身是由段的路径组成的，尽管如果没有共享，则将是一个段。 将位掩码偏移量分配给段中的每个节点。 另外，将另一个位掩码（分层）分配给规则路径中的每个段。 当至少有一个输入（数据传播）时，节点的位设置为on。 每个节点的位设置为on时，段的位也设置为on。 相反，如果任何节点的位设置为关闭，则该段也将设置为关闭。 如果将规则路径中的每个细分均设置为启用，则将规则链接到该规则中，并创建一个目标来计划该规则以进行评估。 相同的位掩码技术还用于跟踪脏节点，段和规则。 如果自上次评估以来认为已变脏的规则，则可以安排已链接的规则进行评估。

这样可以确保没有规则会评估部分匹配，如果由于其中一个联接没有数据而导致它无法导致规则实例的情况，则不会评估。 这在RETE中是可能的，并且即使最后一个连接为空，也会为所有节点产生混乱的匹配尝试。

虽然增量规则评估始终从根节点开始，但脏位掩码用于允许跳过不脏的节点和段。

使用每个节点至少存在一项数据是一种相当基本的启发式方法。 未来的工作将试图进一步延迟链接； 使用诸如弧一致性的技术来确定匹配是否会导致规则实例触发。

由于RETE仅具有一个单一的存储器单元（节点存储器），因此PHREAK具有3个级别的存储器。 这样可以在评估规则期间获得更多的上下文理解。

PHREAK 3分层存储系统

示例1显示了具有三种模式的一条规则； A，B和C。它形成单个段，节点的位1、2和4。

示例1：单一规则，不共享

示例2演示了添加另一个共享模式A的规则时会发生的情况。A放置在其自己的细分中，每个规则导致两个细分。 这两段构成了各自规则的路径。 第一条路段由两条路径共享。 当链接A时，该段将被链接，然后迭代该段共享的每个路径，将位1设置为on。 如果稍后打开B和C，则链接到路径R1的第二段； 这将导致R1的位2被打开。 将R1的位1和位2设置为打开后，现在将链接该规则，并创建一个目标以计划该规则以供以后评估和触发。

评估规则时，正是可以共享匹配结果的细分。 每个段都有一个临时存储器，用于将该段的所有插入，更新和删除排队。 如果要评估R1，它将处理A并得到一组元组。 该算法检测到有分段分割，并将为集合中的每个插入，更新和删除创建对等元组，并将它们添加到R2的暂存中。 这些元组将与任何现有的暂存元组合并，并等待R2最终被评估。

示例2：共享的两个规则

示例3添加了第三条规则，并演示了共享A和B时发生的情况。 这次仅显示段的位。 证明R4具有3个段，R3具有3个段，R1具有2个段。 A和B由R1，R3和R4共享。 而D由R3和R4共享。

示例3：共享的三个规则

当“不存在，存在或累积”节点包含多个元素时，形成子网。 在示例4中，“ B not（C）”形成子网，请注意，“ not（C）”是单个元素，不需要子网，并且在Not节点内部合并。

子网拥有自己的网段。 R1仍具有两个段的路径。 子网形成了另一个“内部”路径。 链接子网时，它将链接到外部网段。

示例4：单规则，具有子网且不共享

示例5显示了可以通过不具有子网的规则对子网节点进行分片。 这导致子网段被分成两个部分。

示例5：两条规则，一条与子网共享

并非具有约束的节点和累积节点都具有特殊的行为，并且永远无法取消链接段，并且始终将其视为打开状态。

所有规则评估都是递增的，不会浪费已经重新产生的工作重新计算匹配项。

评估算法基于堆栈，而不是方法递归。 通过使用StackEntry表示要评估的当前节点，可以随时暂停和恢复评估。

当规则评估到达子网时，将为外部路径段和子网段创建StackEntry。 首先评估子网段，当集合到达子网路径的末尾时，将其合并到其馈入的外部节点的暂存列表中。 然后恢复先前的StackEntry，在其中可以处理子网的结果。 这样做的另一个好处是，所有工作在传播到子节点之前都将被成批处理； 这对于累积节点效率更高。

相同的堆栈系统可用于有效的反向链接。 当规则评估到达查询节点时，它会通过将其放在堆栈上来再次暂停当前评估。 然后对查询进行评估，生成结果集，该结果集保存在内存位置中，以供恢复的StackEntry拾取并传播到子节点。 如果查询本身调用了其他查询，则该过程将重复，暂停当前查询，并为当前查询节点设置新的评估。

关于性能的最后一点。 通常，使用PHREAK的单个规则不会比使用RETE更快。 对于使用根上下文对象启用和禁用匹配的给定规则和相同数据集，它们都尝试相同数量的匹配并产生相同数量的规则实例，并且花费的时间大致相同。 除了带有子网的用例和积累。

但是，对于规则编写得不好的规则库，PHREAK可以认为比RETE更宽容，并且随着规则数量和复杂性的增加，性能会更适度地下降。

RETE还将为不包含所有联接的数据的规则生产部分机器。 PHREAK会避免这种情况。

因此，并不是说PHREAK比RETE快，它不会随系统的增长而变慢。

AgendaGroups对RETE的性能没有帮助，因为所有规则都在任何时候进行评估，而与组别无关。 显着性也是如此。 这就是为什么经常使用根上下文对象来限制匹配尝试的原因。 PHREAK仅评估活动议程组的规则，并且在该组内将尝试避免评估（通过显着性）不会导致规则实例触发的规则。

通过PHREAK AgendaGroups和显着性现在已成为有用的绩效工具。 根上下文对象不再需要，并且有可能对性能产生反作用，因为它们会强制刷新和重新生成规则的匹配项。

翻译自: https://www.javacodegeeks.com/2013/11/r-i-p-rete-time-to-get-phreaky.html