決策引擎——決策流路徑規劃的方案演進

0 評論 4676 瀏覽 29 收藏 11 分鐘

決策引擎是整個風控系統的大腦,承載著風控策略編排和計算的任務,對決策的耗時與精度有著嚴格的要求。本文以決策流執行路徑實現方案為切入點,探討決策引擎高效執行的基本原理,一起來看一下吧。

決策引擎是整個風控系統的大腦,承載著風控策略編排和計算的任務,對決策的耗時精度有著嚴格的要求,同時業務部門對數據源成本也有一定程度考量。網上介紹決策引擎通識的文章有很多,這里不再贅述,本文主要以決策流執行路徑實現方案為切入點,探討下決策引擎高效執行的基本原理。

一、背景

決策流的編排能力,可以滿足策略運營人員對當前風險場景下的防控策略部署的靈活、高效。

“靈活”往往意味著不可控,從開發經驗來看,產品的功能在既定的范圍內,基本不會出現不可控的問題(除非是 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)缺點

  • 決策流的編排需要通力合作,導致性能問題的點可能隨著編排而山下浮動,需要異動監控機制。

三、總結

本文梳理了決策引擎編排決策流過程中為了提高決策性能和節約成本上做出的一些列優化方案,針對不同的場景,可自由選擇激進的方案 or 性能和成本兼顧的方案。

最后啰嗦一句,脫離規劃的設計再好,也未必能能真正的落地,這就對產品經理的產品規劃能力提出了極高的要求,產品經理一定要從實際出發,充分資源、環境與體驗等因素,制定切實可行的方案。

作者:王小賓;微信公眾號:一起侃產品

本文由@并不跳步交叉步 原創發布于人人都是產品經理。未經許可,禁止轉載。

題圖來自 Unsplash,基于 CC0 協議

該文觀點僅代表作者本人,人人都是產品經理平臺僅提供信息存儲空間服務。

更多精彩內容,請關注人人都是產品經理微信公眾號或下載App
評論
評論請登錄
  1. 目前還沒評論,等你發揮!