决策引擎选购指南
决策引擎或规则引擎的概念在2015年随着互联网金融业的发展迅速普及并逐渐被大型企业接受纳入企业基础设施用于集中管理高频变化的业务运营策略相对于传统的硬编码维护方式更为方便
虽然市面上有不少决策引擎的共享，但主要集中在技术层面的经验共享上。 例如，如何构建从0到1的决策引擎，如果有兴趣的话也可以自己调查。 反倒是在公司层面，由于如何评价和选择决策引擎的文章非常有限，公司在购买时往往会因为信息不对称而处于被动状态。 因此，本文从一个决策引擎用户的角度来分享我所认为的公司对采购决策引擎的考虑或注意事项。 (注：本文没有涉及与数据紧密结合的APP融合引擎产品。 这类产品的可扩展性非常有限)
一般来说，市面上的决策引擎主要分为两大类。 一种是基于开放源代码引擎(如Drools )或开放源代码引擎的二次开发(服务层)的产品，另一种是FICO Blaze、IBM ODM、Experian SMG3、sparklinglogics 高度定制化，能够完全按照业务需求进行设计和开发，初期投资不高，但对公司技术力量要求高，后期维护成本不低。 后者的优点是成熟的产品化设计，但初始投资因供应商、产品版本、功能模块而异，产品购买成本高，几乎不支持项目定制开发。 但后期由于只需要维护部署的策略，软件本身的升级和迭代完全由供应商负责，维护成本相对较低。
至于选择开源引擎产品，还是选择成熟的商业引擎，主要取决于公司的实际需要和技术能力。 首先，要明确决策引擎在公司整个基础设施中的定位，同时理顺主要需求和次要需求。 其次，要综合评估开发前期投资、后期持续投资和运输成本。 简单来说，如果需求中存在业务引擎无法涵盖的关键功能，我们建议您使用开源引擎进行定制开发。 当然，前期的开发成本、后期的维护成本会相当高。 如果市面上的商业引擎能够满足主要需求，我们建议您选择合适的引擎制造商。 毕竟，对于决策引擎来说，最重要的功能是支持业务战略的方便高效的迭代。 接下来，如何选择发动机制造商进一步展开？
对公司来说，选择引擎制造商和其他软硬件产品，本质上是选择长期合作伙伴。 选择伙伴，首先我们要衡量他的能力。 对于决策引擎来说，首先需要理解的是其开发团队的从业经验，这往往是产品生命力的无形背书。 接下来需要明确的是该产品版本的重复情况。 有生命力的产品往往会在几个月内进行小更新，1-2年内进行大版本更新，更新内容往往包括技术更新、添加功能、修复错误等。 如果一个引擎产品长时间没有迭代，请仔细考虑。 当然，也要考虑售后服务。 这可以通过与客户的交流得知。 最后，是价格。
Rule 1：选择技术实力过硬，从业经验丰富的厂商，并且产品要保持生命力。
接下来，我们从用户的角度来看如何选定。 通常，基于决策引擎构建数据驱动的自动决策系统涉及三种类型的人员：业务、IT和模型。
对于业务团队来说，决策引擎必须能够快速将业务需求转换为自动化决策的业务规则，并且产品必须易于使用。 简单的训练后，一定程度的经验(熟悉EXCEL公式或SQL )可以让同事快速掌握规则的制定。 从这个角度来看，引擎软件应该是可视化的，规则编写语言应该是明确易懂的。 另外，以我过去的经验，我还需要支持平台上的直接可视化验证和测试，包括通过编写报告来查看测试结果。 这一点非常重要，从这样的结果中得到的测试方法比离线分析方式能够更有效地进行规则测试和业务验证。 从业务的角度来看，在生产环境中运行的策略版本也必须由业务团队管理。 因此，决策引擎必须支持接口化的版本控制和发布功能。
Rule 2: 选择支持可视化规则编辑和分析的低代码/弱代码的决策引擎，并且需要支持完善的版本管理功能
其次，因为越来越多的场景将经验策略(可读)和模型策略(大多数黑匣子都很难理解)结合起来构成实际的自动化决策。 因此，对于模型团队来说，决策引擎必须能够支持算法模型的导入、导出和调用。 当然，如果能直接提供对应的模型开发和调试功能就更好了。 但是，这不是必须的。 毕竟有专用的工具。 利用决策引擎的可视化测试功能，在决策上下文中验证模型的正确性和正确性。
Rule 3: 选择支持算法模型集成和调用的决策引擎
最后，对大多数企业来说，IT资源非常匮乏。 因此，还需要考虑如何能迅速建立业务系统和决策引擎之间的相互作用。 这要求决策引擎提供标准化的API接口，能够适合不同的开发平台。
Rule 4: 选择提供标准API接口，支持便捷集成的决策引擎
以上就是我个人的总结经验，市面上符合上述条件的决策引擎产品其实并不多，大家可以一个个筛查。 相对而言，关于产品力和产品功能的完整性，我个人推荐国外产品。 希望国内出现更优秀的决策引擎产品。
/p>星标我，每天多一点智慧