rete

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

ReteOO算法

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

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

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

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

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

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

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

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

• 向后链接
  支持用于反向链接的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仅评估活动AgendaGroup的规则，并且在该组中将尝试避免评估（通过显着性）不会导致规则实例触发的规则。

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

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

rete