规则引擎最佳实践系列：如何做决策？

 

作者 | Carole-Ann Berlioz

译者 | Teki.D

 

我们已经介绍了一些基础内容：编写规则时不该做什么。现在我想重点谈谈该做什么。谈到这个话题，我的第一个念头，同时也是最基础的一点，那就是：做决策。

 

一个常见的误解是，决策服务只做一个决策。当然，会有一个最主要的决策将结果值设置为true、一个字符串或计算得到一个数值。例如：

 

·     批准贷款申请

·     核准保险索赔

·     将一笔支付交易标记为欺诈行为

 

决策服务通常会做出这个关键决策，但它往往会附带其他子决策。例如：

 

·      风险评估…

·      最好的抵押贷款产品…

·      付款金额…

·      可能的欺诈类型...

 

做多个决策还是一个决策

 

在我的职业生涯中，我见过许多不同行业的项目。它们适用于完全不同类型的决策。我时不时听到一些人想要简化决策结果的想法。‘某些情况下’仅仅做出一个决策是不够的。不要假定没有决策就等同于与其相反的决策。这种过于简化的做法不是一个好的设计。决策服务需要做出多个决策。

 

业务规则通常会标记出负面的结果，例如一个拒绝的决策、疑似欺诈等。一个诱人的想法是决策服务只在反面的行为发生时才做出响应。如果申请人没有被拒绝或转介，那么他或她的申请就被批准了。既然这是显而易见的事实，为什么还要明确地表述呢？

 

在这样的设计中，决策服务将在申请人被拒绝时返回"已拒绝"，而当申请人没有被拒绝时，则不会返回任何信息。

 

把糟糕的情况标注出来并不是什么坏事。同时我个人坚信正面的决策结果也需要肯定地表述出来。决策服务所给出的最终结果都是“申请被拒绝”，这是不够的。

 

如果符合申请规则，它应该能反馈结果“申请已批准”。只关注否定的结果似乎会很直观，但没有返回任何结果未必就是正面的，也可能是由于缺乏信息而无法对申请人进行审查。

 

不要让决策服务做出的决策有任何的不确定性。

 

为什么要同时准备正反两面的决策？

 

你当然可以认为‘没有错误的决定’等同于‘正确的决定’。不过我觉得这逻辑有点站不住脚。当出现例外状况时，在这种逻辑下会得出一个肯定的结果（“申请被批准”），这会使你的业务遭受损失。如果你的决策逻辑在中间步骤失败了，不要忽视了这一信息。

 

不要因此臆断我不信任业务规则。显然，业务规则会忠实地重现您所创建的决策逻辑。我担心的是数据会随着时间的推移而改变，既定的决策逻辑也会同样改变，而且很频繁。

 

不要想当然地认为所有可能的路径都被覆盖了。当前你的规则可能会检查是否所有必需的信息都已经提供了。假设第二天你的决策服务需要一个新数据，而负责该数据相关规则的业务分析师忘记提前检查，缺少此数据时，将无法做出决策。最终你会得到许多一开始就无效却被批准了的申请。

 

简而言之，我强烈建议为例外事件做好准备，不要让它在不经意间发生。一定要清楚地表述你的决策。如果申请没有被“拒绝”或“转介”，则添加一条规则将状态设置为“已批准”。

 

如果遇到这些无法做出决策的情况，只需要相应地更新你的决策逻辑。另外，这会大大增加在质量检查时发现这些问题的机会。你也不希望在决策逻辑部署到生产环境后还出现混乱。这就是关于做决策的101规则。

 

原文链接：https://www.sparklinglogic.com/making-decisions/

 

 

联系客服号获取更新文档