当前位置: 首页 > 后端技术 > Java

风控决策引擎——决策流路径规划

时间:2023-04-02 01:30:01 Java

介绍决策引擎服务是风控系统的大脑,承载着风控策略安排和计算的任务,对决策的耗时和准确性有着严格的要求-制作。本文以决策流执行路径实现方案为切入点,一窥风控决策引擎的高效原理。背景上述风控决策引擎-决策流构建实践中详细介绍了风控决策引擎的开发过程,决策流编排能力满足了当前战略运营商对防控策略的需求风险场景要灵活高效。部署。“灵活”往往意味着无法控制。从多年的开发经验来看,产品的功能都在既定的范围内,基本不会出现不可控的问题(除非是BUG)。和SQL查询语言一样,它对数据分析师来说非常灵活。抽象的语法可以满足任何数据组装查询的组装需求,但此时危机正在蔓延:慢查询随时可能引发性能问题!“灵活性”和“效率”在程序中往往是相互排斥的,充分的灵活性往往是以牺牲一定的效率为代价的。研发人员能做的就是在两者之间进行博弈,寻找最佳平衡点。决策流程执行演化如下:比较常见的战略运营人员配置决策流程图:流程图看似简单,但在程序的实际执行中会遇到各种问题和挑战,根源在上游而下游业务对风控决策的执行耗时也有严格的控制要求。第一代——串行执行工作流这个阶段就像一个工作审批流,从起始节点到结束逐级串行执行。在决策过程中,完全取决于节点路径的复杂程度。假设一个节点的平均耗时是100ms,那么下面红色的执行路径耗时500ms。500ms对于风控来说是奢望。我们可能大部分时间都消耗在一个请求整个业务线,这显然是不能接受的。可以想象,随着业务场景越来越复杂,战略家安排的决策流程也越来越复杂,导致整个决策流程的决策路径越来越长,时间消耗呈线性增长。这种技术实现方案肯定是不行的。总结:优点所见即所得,不多执行,不少执行串行执行对程序调试和日志友好,便于调试缺点性能极差,策略人员无法接受二代-并发执行工作流做不完,就堆人吧。同样,如果一个线程完成不了,我们把线程堆起来,并发计算。基于以空间换时间的思想,决策流中的所有节点都提前预加载,结果缓存起来。在真正执行决策流时,直接计算请求缓存并执行,大大节省了决策时间。此时影响决策性能的卡点就在消耗时间最多的节点。你只需要集中人力解决这个节点的性能问题,减少决策流程的执行时间。总结:优点性能一流,空间换时间,最大效率提升缺点是算力大,所有节点并发请求,对下游系统的负载要求高,浪费,在A节点做请求决策时,是rejected,但是后面的所有节点都计算一次,非常浪费;比如有些收费节点是提前调用的,但是没有使用,在不考虑节点依赖问题的情况下成本极高。假设C节点依赖A节点的结果,这会导致并发加载C节点时,没有对应的入参,发生错误。第三代——依赖分析&并行方案2,除了没有考虑成本问题,最大的痛点就是依赖问题,这是致命的。此时,需要在运行时动态分析决策流节点之间的依赖关系。从图中可以看出,节点C依赖于节点A,节点D依赖于节点B,其他节点互不依赖。此时可以通过依赖分析出节点间的分组关系,按组头节点顺序执行。节点依赖分析那么如何实现节点依赖分析和执行顺序呢?流程图本身可以是一个DAG(DirectedAcyclicGraph),节点执行的顺序可以通过BFS(广度优先遍历)遍历得到一个一维数组,然后遍历分析每个节点的输入参数和前面节点的输出参数是否有关联,关联的合并到前面节点组链表的“尾”,否则独立,可以并行执行。此时,整个决策流的执行时间如下:决策流执行耗时=并行组1耗时+并行组2耗时+...+并行组N耗时依赖问题有对战略人员的配置有一定的要求。需要尽量避免依赖,或者减少依赖分组。缺点是方案2的开销还是没有解决,每个节点还是加载一次,算力浪费严重。Forecasting&dynamicpruning方案2和3都是全量并行加载各个节点的数据,消耗了大量的算力和成本。在实际操作过程中,公司的成本肯定是无法接受的,可能会出现资金损失。召回不一定值得服务器和外部资源的成本。通过分析决策流图可以发现,分流节点的作用是排他性的,即决策数据流只选择一条路径,所以我们可以在并行前确定当前决策请求中哪些路径不会通过执行。然后可以排除不会通过该路径的节点,从而减少不必要的计算能力和成本。独享网关剪枝如上图所示。先找出独占网关节点S1和S2,分析入参是否依赖上游节点。此时S1依赖B节点,S2没有依赖。然后,可以根据排他性节点分组并发执行决策。此时S1节点对应的节点C被“剪枝”,S2节点对应的节点G被“剪枝”。总结:优点最小算力,只并发加载行进路径中的节点算力缺点行进路径中的节点没有考虑成本问题,可能已经被前面的节点拒绝了,直接点算力就可以了浪费第五代项目——饿鬼计划4,已经解放了很大一部分不会去分支的算力,但是在正确的决策路径上还是有浪费。例如,如上:节点A是一个列表节点。如果命中链表,则直接pass或拒绝,后续节点的并行加载是一种浪费。节点D和节点F是付费节点,并发调用成本极高。他们可能在没有实际使用支付结果的情况下在途中被拒绝。这时候需要识别付费节点(或者任何需要控制资源的节点),改为懒加载模式,即在所有节点并发加载时剔除懒加载节点,计算何时决定流程路径真正执行到这个节点,要保证调用一定是有效的,这个时候在构建节点的时候,需要区分一下是设置节点类型为hungry还是lazy。总结:优点基本避免了上述方案涉及的问题,实现了利用率最大化和性能的平衡。缺点决策流的安排需要全员配合,导致性能问题的点可能会随着安排而波动,需要变更监控机制在决策引擎编排决策流程的过程中。针对不同的场景,您可以自由选择激进方案或兼顾性能和成本的方案。研发就是从产品规划的角度来思考实施方案。如果没有规划,再好的设计也无法真正实施。记住。从0到1,构建智能风控决策引擎是性能优化的必经之路——火焰图我是如何入行做风控的?github.io/