Skip to content

底层算法

顶层架构从外部关注引擎组件如何管理和运行,涉及规则中心/管理组件、引擎组件、业务中心;而底层算法则从引擎组件内部关注其构造和原理:决策引擎、事实库和规则库。

将这两个视角结合起来,我们似乎可以看到一种分形的美学,即宏观和微观之间存在着某种自相似性。顶层架构的设计原则和模式在底层算法中也有所体现,反之亦然。这种“一体两翼”的结构不仅在宏观上指导着整个系统的运行,也在微观上影响着算法的实现和优化。

Phreak-Algorithm

  • Phreak / Decision Engine: 事件驱动和延迟计算。事件驱动指的是规则引擎根据发生的事件来触发规则的执行,而延迟计算则意味着规则引擎会在合适的时机(而非立即)计算和推断结果,从而优化性能和资源使用。

  • Rules / Production Memory: 生产内存用于存储规则。这个术语源于生产性,即系统会根据规则生成新的事实或执行相应的操作。

  • Facts / Working Memory: 工作内存用于存储事实。事实通常来自外部的事件源,推理过程中也会产生新的事实。

  • Pattern Matcher / Agenda: 规则的匹配和执行。模式匹配负责匹配规则中的模式与工作内存中的事实。当模式匹配找到符合条件的规则时,这些规则会被添加到议程中,按优先级和执行顺序安排执行。

规则引擎

Rete 和 Phreak 两种规则引擎推理算法的多维度对比:

维度RetePhreak
发明时间1974年,由 Charles Forgy 发明2013年,由 Mark Proctor 发明,作为 Drools 的优化引擎
发明人Charles ForgyMark Proctor
核心原理通过匹配模式树来高效处理重复规则,避免不必要的重复计算基于 Rete 的改进,加入了延迟执行、批处理、以及增量计算优化
节点结构使用“匹配节点”和“测试节点”形成规则网络采用类Rete网络,加入了更高效的连接、节点共享和链式执行
性能优化对于高频率的重复数据集、避免重复规则检查的性能较好在大规模数据集下的性能优化更显著,特别是规则数量多时表现优秀
内存使用内存消耗较高,因为会存储中间结果和部分匹配状态优化了内存管理,通过增量计算和延迟匹配减少了内存开销
计算方式每次规则触发时都重新计算匹配状态提供批处理和增量计算,避免重新计算整个匹配集
适用场景适合规则数量中等且状态频繁变化的场景更适合复杂、多规则集、以及高频状态更新的场景
并行性支持支持有限的并行性,原始设计不具备并发执行能力原生支持并行和多线程执行,特别是在多核处理器下性能表现优越
推理机制前向推理,逐步匹配条件,计算输出结合了前向和推理优化机制,提供了更灵活的推理路径
使用框架CLIPS、Jess 等基于 Rete 算法的规则引擎Drools 6 及以上版本中的默认推理引擎
实际应用案例在一些经典的人工智能和决策支持系统中广泛应用现代企业业务规则系统、金融风控等高复杂度的决策系统

通过表格展示可以清晰看到,Phreak 是在 Rete 基础上的一种重大优化,特别是在现代多核环境下表现出色,适合处理大规模和复杂规则的场景。而 Rete 则是规则引擎领域的奠基算法,尽管在性能和内存优化上不如 Phreak,但其设计思路仍然是许多规则引擎的基础。

RETE是一张网(DAG,有向无环图),事实在网中流动(匹配)或消失(不匹配)

规则库

在设计规则库时,需要重点考虑以下几个方面,以确保规则库的可维护性、扩展性和高效性:

1. 规则的结构化表示与分类管理

  • 规则的分类:规则库需要按业务领域或功能模块对规则进行分类管理,便于查找、维护和调试。可以按产品、订单、用户、风控等业务场景进行分类,或按计算类型(决策规则、计算规则)进行分组。
  • 规则的版本管理:业务规则随着时间推移会不断调整,需为规则库引入版本控制机制,确保在规则变化时能够回溯到历史版本或不同业务场景下使用不同版本的规则集。

2. 规则的元数据管理

  • 每条规则应包含元数据信息,如规则的名称、描述、创建时间、修改时间、状态(启用/禁用)、适用场景等。这些信息不仅方便规则的管理和追踪,还能支持规则的动态加载、调试等需求。

3. 规则的可视化编辑与管理

  • 提供可视化的规则编辑器,使业务人员无需了解复杂的 DRL(Drools Rule Language)语法即可编辑规则。基于界面的规则管理平台可以提高规则的可维护性和可操作性。
  • 规则模拟与测试:在规则库设计时,应支持在可视化编辑界面中模拟规则执行,允许业务人员在修改规则后即时查看推理结果。

4. 规则的生命周期管理

  • 规则的启用与禁用:规则库需要支持规则的启用和禁用功能。某些场景下,业务规则可能需要根据具体条件临时调整,禁用部分规则并在特定情况下启用新的规则集。
  • 规则的上下线流程:引入规则的发布流程,避免未经验证的规则直接进入生产系统。可以设计审批、测试和发布等阶段,确保规则的稳定性和准确性。

5. 规则的动态加载与热更新

  • 规则库设计中应支持规则的动态加载与热更新。业务变化频繁时,不希望每次规则修改都重启整个引擎系统,因此可以通过规则缓存、动态加载技术来实现规则的热更新。

6. 规则的复用与继承

  • 在复杂业务场景中,许多规则会有重复或共性部分,设计规则库时应支持规则的复用和继承机制。可以通过设计规则模板或基于已有规则的规则派生机制,减少冗余,提升规则库的维护效率。

7. 规则的执行与优化

  • 执行顺序:规则库中需合理设置规则的执行顺序,以确保先后逻辑正确。这可以通过定义优先级或规则的依赖关系来实现。
  • 规则的并发执行与优化:当规则数量庞大时,应关注规则执行的性能优化。可通过批量执行、分布式执行或并行计算的方式提升规则引擎的性能。

8. 规则的监控与审计

  • 执行日志与监控:引入监控机制,记录规则的执行情况,输出详细的日志供事后分析。每条规则的执行结果及其影响都应有相应的审计日志,以便排查问题时参考。
  • 规则库的审计追踪:对于规则的创建、修改、发布等操作,需保留审计记录,确保规则在整个生命周期内的可追踪性。

9. 规则的扩展性设计

  • 支持多种规则表达格式:除了 DRL,还可以支持决策表(Decision Table)、PMML(Predictive Model Markup Language)等多种规则表达方式,方便不同业务场景下的规则输入和管理。

总结:规则库的设计需要充分考虑业务需求的复杂性、规则的动态性以及性能优化等因素。通过结构化的规则管理、版本控制、可视化编辑、动态加载等功能,可以提高规则库的可维护性和可扩展性,确保在复杂业务环境中,规则引擎能够高效执行和维护规则逻辑。

事实库

在设计和管理事实库时,需要关注以下几个关键方面,确保其在规则引擎中的有效运作:

1. 事实的结构化与一致性

  • 数据模型设计:事实库中存储的事实必须是结构化的,通常使用标准化的数据模型或类定义(如 JSON Schema、Java 实体类等)来表示。在复杂业务中,确保事实的字段、类型、层次结构与业务需求一致,避免不一致导致推理错误。
  • 模式验证:在事实进入规则引擎前,需对事实进行模式验证,确保其符合预定义的结构。例如,可以借助 JSON Schema 进行数据验证或利用数据库模式设计。

2. 事实的来源与治理

  • 数据来源的可信度:事实库中的数据可能来自不同的业务系统或外部来源,因此需要关注数据来源的可靠性。对于不同来源的数据,需定义清晰的事实采集和更新策略,避免不准确的事实干扰推理。
  • 事实的版本控制:事实数据会随着时间变化而更新,规则引擎在不同时间点执行可能需要依赖历史版本的数据。因此,事实库应具备版本管理功能,确保历史事实可以追溯。

3. 事实的生命周期管理

  • 创建、更新和删除:需要定义事实的生命周期策略,例如何时创建事实,何时更新或失效,过期事实如何处理。这不仅影响推理结果,也关系到事实库的存储效率。
  • 事实的缓存与更新频率:在高性能需求下,频繁访问数据库查询事实可能影响性能。可引入事实缓存机制,定期更新缓存中的数据,提升事实访问的效率,同时保持推理结果的准确性。

4. 事实的关联性与依赖性

  • 事实的聚合与组合:在复杂业务场景中,单一事实往往无法满足业务推理需求,多个事实可能存在关联关系。事实库需支持不同事实的聚合与组合,以便规则引擎进行更复杂的推理。
  • 跨系统的事实同步:当一个事实库的数据来源于多个业务系统时,需确保不同系统间的数据同步和一致性,避免跨系统依赖导致推理错误。

5. 事实的隐私与安全性

  • 数据隐私:事实库中可能包含敏感的业务数据,因此必须遵循相关的隐私保护法规(如 GDPR)。数据的存储、访问和处理都需具备强健的权限控制机制。
  • 访问控制与审计:为确保业务规则的执行合规,需记录事实库中数据的访问和变更情况,具备详细的审计日志,以便进行事后分析与追踪。

6. 事实的可视化管理

  • 图形化展示:事实库往往与可视化管理工具结合使用,特别是在复杂的业务决策中,事实的关系和依赖性通过图表或层次结构图呈现,帮助业务人员更直观地理解。
  • 数据探查和调试工具:在调试复杂规则时,规则引擎需要提供探查工具,便于查看当前加载的事实,帮助分析规则运行的结果与数据之间的关系。

7. 事实的扩展性

  • 水平扩展能力:对于大规模数据和高并发访问的场景,事实库需要具备良好的扩展性。可以采用分布式存储或分片等技术,确保在规则引擎处理大规模事实时,仍能维持较高的性能。
  • 动态加载与更新:事实库应支持动态更新,而不需要中断整个规则引擎的执行过程。事实的动态加载机制可以在运行时及时获取新的数据,提高系统的实时性。

综上,事实库不仅仅是数据的存储仓库,它承担着将业务数据转化为规则推理基础的重任,涉及到数据模型、生命周期、关联性、治理、隐私、扩展性等多个维度的考量。通过以上这些方面的优化,事实库可以更加高效、安全地支持业务规则的执行。