决策引擎的常见方案

决策引擎是一个能够帮助企业自动化决策过程的工具。在复杂、动态的环境中，决策引擎可以根据预设的规则、策略、数据和模型，自动做出决策，从而提高企业的运营效率和决策质量，常见于金融服务、供应链管理、客户关系管理、医疗诊断等多个领域。

以下是一些决策引擎的常见方案及其特点：

硬编码实现方式

当规则较少、变动不频繁时，硬编码实现方式具有较高的开发效率。当存量规则较多时，可维护性差，规则开发和维护门槛高。此类规则需要由开发人员介入开发，对业务分析人员不可见，业务分析人员有规则变更需求后无法自助完成开发，其规则迭代成本高，对规则的少量改动就需要走全流程（开发、测试、部署）。

商业方案

商业方案一般包含完整的规则管理能力，包括可视化拖拽编辑、版本管理、用例自测、试验等等，在模型组件方面也有较完整的覆盖，支持决策流、决策树、决策表、规则集等等。缺点是代码较闭源，需要购买license以及有限制使用人数，二次开发的空间不大，部署方式较为传统（整包重发重启）。

开源方案Drools

Drools依靠DRL来编写规则，本质上也是通过代码语言来描述，属轻量的“硬编码”，因此，Drools的规则配置流程一般只适合开发人员使用。其优点在于策略规则和执行逻辑解耦，方便维护。然而，其规则的语法仅适合扁平的规则，在面对复杂、交叉的业务逻辑时较为吃力，最后还是会演变成臃肿的硬编码。虽然Drools有完善的开源方案，但是其代码量庞大，二次开发的门槛较高。

自研决策引擎

针对硬编码和Drools方案的不足，可以开发一套能够满足多方面功能诉求的，适用于运营、产品、业务、开发等人员的决策引擎。这种轻量级决策引擎会更适合企业的实际需求，能够平衡规则维护的灵活性和开发的效率。

下面列举了一些常见的技术方案，作简要比对：

方案比对的Q & A

为什么都是用RETE算法？

• RETE算法本身是逻辑计算网络，属于正向推理，其入参支持多个主体，中间的计算网络支持主体之间交叉比对，在比对过程产生的值会追加到工作区，因此这里有空间换时间的概念。RETE算法是个立体的交叉网，其算法效率远优于foreach遍历（笛卡尔积）；
• 由于RETE算法的入参支持多个主体，具备强大的推理能力，可用于多方面多方向的汇总计算、复杂的数据挖掘计算，例如：购物车勾选多个产品的最优惠计价规则（入参是产品集合、优惠券集合）。若用于针对单个用户的评估（整体过程比较平面、流水线式），有种杀鸡用牛刀的感觉。

Drools为什么被弃用？

• Drools代码量大，其core模块也要比URule大不少，如果再加上完整的功能包就更庞大了；
• Drools的core包核心能力是RETE算法 + 工作区（fact对象处理过程），几乎没有二开的空间，可以理解为是一个比较纯粹的、高级的RETE算法实现，RETE算法本身是逻辑计算网络，没有模型组件的概念，不能直接支持决策流、决策树、决策表；
• Drools的可视化方案，最终也是输出一套DRL，因此Drools的规则终究是没有离开硬编码方式，在相关的维护工作方面，对开发者依赖较高，对运营人员很不友好。

自研决策引擎的必要性？

• 企业的软件方案的趋势是：统一化、平台化、中台化，对此，开发者对决策引擎的诉求是：功能开放、有二开空间（包括功能、devops整合），但是无论是商业方案还是Drools，其都有较完善的生态，实际上有较高的封闭度；
• 当下对决策引擎的需求：高频决策，复杂规则，频繁更新，机器学习等等，因此对决策引擎的诉求是方方面面的，包括：分布式能力、完善的模块化和运营功能设计、可维护性（整合ops发布平台）、可拓展性（整合大数据平台）等等

决策引擎的核心价值在于能够实时、准确地根据业务需求和内外部环境变化，执行相应的决策策略，同时保持高可配置性和可扩展性。实际上，上述几类决策引擎方案都能够满足，而企业决策引擎的发展趋势是：自研决策引擎，并向智能化方向发展。