2023年决策引擎-决策流路径规划的方案演进

决策引擎——决策流路径规划的方案演进class="aligncentersize-fullwp-image-5722538"src="/wp-files/2023/01/iMCGoVJGezWQK1Ch7G8e.png"alt=""width="900"height="420"/>

决策引擎是整个风控系统的大脑，承载着风控策略编排和计算的任务，对决策的耗时与精度有着严格的要求，同时业务部门对数据源成本也有肯定程度考量。网上介绍决策引擎通识的文章有许多，这里不再赘述，本文主要以决策流执行路径实现方案为切入点，探讨下决策引擎高效执行的基本原理。

一、背景

决策流的编排力量，可以满意策略运营人员对当前风险场景下的防控策略部署的敏捷、高效。

“敏捷”往往意味着不行控，从开发阅历来看，产品的功能在既定的范围内，基本不会消失不行控的问题（除非是BUG）。像SQL查询语言，对数据分析人员来说特别的敏捷，抽象的语法可以满意任何数据组装查询组装需求，但此时危机正在扩散：随时可能消失一个慢查询导致性能问题！

“敏捷”和“高效”往往在程序内是互斥的，足够的敏捷，往往是牺牲肯定的效率得到的。产品与研发人员能做的，就是在两者中博弈，找到最佳平衡。

二、决策流执行演进

以下是策略运营人员配置的较常见的决策流图：

流程图看似简洁，但是在实际执行程序执行过程中会遇到各种各样的问题和挑战，根本缘由还是上下游业务对风控决策执行的耗时有严格的掌握要求。

方案1：串行执行决策流

此阶段就像一个工作审批流，从开头节点一步一步的往下串行执行，直到终点。决策过程中，完全依靠节点路径的简单度，假设一个节点的平均耗时为100ms，那么如下红色执行路径需要耗时500ms。

500ms对风控来说是比较浪费的，整个业务线一次恳求耗时可能大半时间都被我们消耗掉了，这明显是不能接受的。可以想象，随着业务场景越来越简单，策略人员对决策流的编排简单度越来越高，导致整个决策流的决策路径越来越长，耗时呈线性增长，这种技术实现方案确定是不能接受的。

总结：

1）优点

所见即所得，不会多执行也不会少执行；串行执行对程序调试和日志友好，便利调试。2）缺点

性能极差，策略人员可能无法接受。方案2：并发执行决策流

活干不完，咱就堆人。同样的，一个线程干不完的，咱就堆线程并发计算。

本着空间换时间的思想，预先将决策流内的节点全部预加载完成，将结果缓存住，真正执行决策流的时候，恳求缓存直接计算执行，大大节约了决策时间。

此时影响决策性能的卡点在最耗时的那个节点，只需集中人力解决掉这个节点的性能问题就能降低决策流执行时间了。

总结：

1）优点

性能一流，空间换时间，最大化地提效。2）缺点

算力很大：全部节点都并发恳求，对下游系统的负载要求很高；铺张巨大：当笔恳求决策在节点A就被拒绝了，但是后续全部节点都计算了一遍，很铺张；成本高：又比如有些收费节点，提前调用了，但是并未使用，成本极大；未考虑节点依靠问题：假设节点C依靠节点A的结果，此处会导致并发加载节点C时没有相应的入参而出错。方案3：依靠分析并行

方案二除了不考虑成本问题外，最大的痛点在于依靠关系问题，这是致命的。此时需要在运行时动态分析决策流节点之间的依靠关系。

从图中可以看出，节点C依靠节点A，节点D依靠节点B，其它节点相互不依靠，那么此时可以通过依靠分析出节点与节点之间的分组关系，通过分组头结点先后挨次串行执行。

节点依靠分析：

那么如何实现节点的依靠分析及先后执行挨次呢？流程图本身可以就是一个DAG（有向无环图），节点执行的先后挨次可以用BFS（广度优先遍历）遍历出一维数组，然后遍历分析每个节点的入参和之前的节点的出参是否有关联，有关联的归并到之前节点组链表的“尾巴上”，否则即为不依靠，可并行执行。

此时整个决策流执行耗时状况如下：

决策流执行耗时=并行组1耗时+并行组2耗时++并行组N耗时

总结：

1）优点

解决了决策流中并行处理中前后依靠问题。2）缺点

对策略人员的配置有肯定的要求，需要尽量规避掉依靠关系，或者削减依靠分组；依旧没有解决方案2的成本问题，每个节点还是加载了一遍，算力铺张严峻。方案4：路径猜测动态剪枝

方案2、3都是全量并行加载各节点数据，对算力和成本的消耗是巨大的，实际在运行的过程中，公司在成本这块确定是不能接受的，可能资损召回都不定能抵得上服务器和外部资源的开销。

通过分析决策流图，可以发觉，分流节点的功能是排它，即决策数据流向只会选择一条路径执行，那么此时我们能在并行执行之前确认哪些路径在当次决策恳求中不会经过，则可以排解掉不会经过路径上的节点，从而削减不必要的算力和成本。

排它网关剪枝如上图，优先找出排它网关节点S1,S2，分析入参是否依靠上游节点，此时S1依靠节点B，S2无依靠，则可根据排它节点分组并发执行决策出排它路径，此时S1节点对应的节点C被“剪枝”，S2节点对应的节点G被“剪枝”。

总结：

1）优点

算力最小化，只并发加载行进路径中的节点算力。2）缺点

行进路进中的节点未考虑成本问题，可能在前置节点已经拒绝，后直接点算力铺张。方案5：饿汉式懒汉式

根据方案4，已经解放了一大部分不会走到分支的算力，但是在正确的决策路径上，依旧存在铺张，举例如上：

A节点是名单节点，假如命中名单，直接通过或者拒绝，后续节点并行加载都是铺张的，节点D和节点F都是付费节点，并发调用，成本极高，可能在途中就被拒绝而未实际用到付费结果。

此时，需要标识出付费节点（或者任何需要掌握资源的节点），改为懒加载模式，即在前置并发加载全部节点时剔除懒加载节点，在决策流路径真正执行到该节点时再去计算，确保调用了肯定是有效的，此时，构建节点时需要区分设置节点类型是饿汉式or懒汉式。

总结：

1）优点

基本规避了上述方案涉及到的问题，在最大化利用率和性能之间取得平衡。2）缺点

决策流的编排需要通力合作，导致性能问题的点可能随着编排而山下浮动，需要异动监控机制。三、总结

本文梳理了决策引擎编排决策流过程中为了提高决策性能和节省