數據賦能，高效防控：螞蟻數據智能如何守護金融安全

第三， 實時系統的高可用性。花唄作為一款國民級產品，直接影響到大家的日常生活，同時一些大商戶對 SLA 的要求也是非常高的。

因此，實時風控除了需要保障日常正常流量壓力下的極速響應，還需要在面臨一些特殊狀態依然保持高可用，例如大促、直播的高峰流量，以及當風險規則因為數據等原因導致異常，進行了遠超出預期的攔截，實時風控架構需要對上述特殊狀態進行快速的自適應響應，來將實時風控的響應時間和攔截率始終維持在一個合理的水位。

最後是 數據智能化的決策。整個花唄 / 信用卡的風控規則體系本質都是數據驅動演進，當風險政策同事基於離線數據研判出可能的風險模式、風險特徵，並加工出相應的風險規則後，技術需要提供必要的對這些規則進行優化和快速驗證的能力。

如果進行適當的抽象就是，圍繞規則期望優化的特定目標進行局部最優的求解，例如降低套現率的同時至少維持通過率不變，並在這些規則上線後持續針對該目標進行策略調優推薦，防止規則劣化。

圍繞著上述四個核心問題，我想簡單介紹一下貸中實時風控更為具體的業務形態，以便讓大家對我們所面臨的問題有更確切的體會，以及技術需要針對這樣的業務形態做怎樣的抽象來進行保障。

簡單來說，風險政策同事會根據業務場景、買賣家等級等維度劃分出具體的風險場景，我們俗稱為畫格子，而具體格子的不同會導致決策樹的形態不同，例如一個低風險買家在淘寶的大商戶使用花唄和一個有異常關聯的買家在疑似套現商家多次嘗試，所依賴的決策數據和決策邏輯是全然不同的，體現在架構圖上就是前者只需要跑特定場景的通用規則，而後者可能需要跑該場景的全部規則，同時結合一些圖計算和模型打分判斷花唄是否可用。

基於上述的業務抽象，我們將所有的決策流程和風險規則完全數字化，當一筆諮詢流量到達時，我們根據該流量所屬的具體的格子來動態的生成決策樹，並基於生成的決策樹獲取所有必要的風險數據進行計算，而這樣的抽象是我們解決上述核心問題的基礎保障。

結合上述的業務抽象和數字化基礎，簡單討論一下我們是如何解決上述四個核心問題的：

極速響應：除了自建的規則引擎進行常規的規則優化和 IO 合併之外，主要思路是提前計算和按需計算，特定流量只跑最必要的規則，只取最必要的數據。

極致安全生產：為了洞察風險政策相關數據變動對整個決策結果的全局影響，我們的核心思路是採集一部分的線上流量用做旁路流量，在基於變動數據生成的新決策樹上重放這部分流量，達到不生效但是重現與線上等價影響的效果。

高可用：為了應對大促或者直播，我們會對不同風險場景的流量提前生成切換檔位的降級方案，或者自適應的生成降級的決策樹，來保障尖峰流量來到時響應時效不受影響。

而對策略異常態，風險政策同事會對風險規則給出預期的攔截率波動範圍，如果實時採集的攔截率出現了預期之外的波動，那麼系統會對該規則進行自動降級或者對攔截量進行蓋帽。

數據智能化決策：風險規則在研發過程中，以及在上線後，我們通過完全自動化的周期任務來對該規則進行目標約束下的優化，同時並給出健康度評價，確保規則在全生命周期都有期望目標下的較優解，同時建設完整的 A/B 實驗體系幫助風險政策同事快速的驗證策略效果。

下面，我會逐一對每一個專題展開更詳細的分享：

我們第一個架構抽象就是多級決策。上面我們說到，如果優質流量和風險流量執行完全相同的決策樹，系統成本會非常大，因此我們在決策樹上形成了一種流量漏斗。

我們的架構分為四層。第一層是快速決策，依賴的數據都是非常基礎的，包括名單、准入、等級等，只做一些快速攔截或通過；第二層是量化決策，大部分流量都要經過，無論是優質流量還是風險流量，大部分規則都需要運行；第三層是深度決策，只有被認定為風險流量的才會進入，這一層運行的規則數據需求更大，可能包括圖計算、模型打分等。

這裡需要說明，前三層決策，即快速決策、量化決策和深度決策，都需要在百毫秒的時間窗口內響應。所以即使是深度決策，也受到響應時間要求的限制。例如，基於圖特徵的風險查詢度數就會受到限制。

因此，我們有第四層異步決策，與前三層不同，這層的決策結果不是對當筆流量生效的，而是形成一個反饋迴路，當同樣的買家、賣家的下一筆流量再次來到我們的風險決策系統時，這個異步決策系統中的數據將反饋給前三層的某些風險規則，來進行風險流量的判定。

這一層的計算更複雜，依賴的數據範圍也更大，例如基於更大規模數據集的圖計算任務，或是進行多流 Join 的實時計算任務等等，從當筆流量進行異步決策到下一筆流量生效時延大約是秒級。

綜合來看，我們通過多級決策區分了優質流量和風險流量，並讓這些流量儘可能只運行最必要的規則，只查詢最必要的數據。

即使實現了上述的多級決策，在各個分層，特別是量化決策和深度決策兩個分層，仍然會有一些必要的風險數據查詢的 IO 瓶頸，而流量需要在百 ms 的窗口內作出響應，那麼一個自然的想法是我們能否將這些慢查詢進行前置，甚至提前對流量給出諮詢結果。

基於這個想法，我們建設了預決策鏈路，這個鏈路得以實現依賴於支付寶收銀台決策 – 花唄業務決策 – 花唄風控決策的架構。

簡單來說支付寶的收銀台渲染時，在調用花唄業務系統的同時，會生產一個消息，我們作為花唄的風控決策系統，通過監聽這個消息，並利用花唄業務決策系統處理自身業務的時間擋板，通常在幾十 ms，來做一些前置的工作，等諮詢流量從花唄的業務系統調用過來的時候，這些前置工作可以被利用起來為快速響應創造更多的可能性。

這個架構簡單講可以分為三層：

第一層在離線，通過對線上日誌和規則元數據的離線分析，預測出最具性價比的風險規則，這裡的性價比有很多維度，包括讀 IO 的時效、線上整體查詢量、是否有利於整體決策樹的裁剪、是否可以在預決策鏈路被查詢和計算等等，然後通過天級別的生效方式將這些風險規則灰度彈出到第二層，也就是真正的預決策鏈路。

第二層是預決策鏈路，通過監聽支付寶側的消息，結合離線預測的風險規則元數據，提前進行必要的查詢和計算，然後將這些前置計算的結果存入緩存，方便真正的線上鏈路使用。

第三層是在線鏈路，通過讀取緩存獲得部分前置計算結果來加速對花唄業務系統的響應，當然，我們還有一整套的機制來保障儘管預決策和線上鏈路的入參有差異，但是仍然會有一致的決策結果，否則不予生效，這裡不做贅述了。

預決策通過提前計算高性價比規則的方式，讓部分流量可以減少、甚至不需要在實時鏈路進行風險數據的查詢和計算，大大加速了風控決策的響應。

風控引擎是實時風控系統的核心組件，也是我們完全自研的，一方面通過為風險政策同事提供類 SQL 的 DSL 編寫方式，大大加速了他們對線上規則研發的參與度，風險規則的疊代效率得到顯著提升，另一方面在風險數據都 ready 的情況下，風險規則的計算都在 ms 級別，是極速響應的基礎保障。

不過實時風控作為一個更重 IO 的系統，其實壓縮響應時間更多還是要靠降低不必要的 IO，前面講到的多級決策和預決策其實也都是這個思路，而我們的引擎在設計以及產品態的包裝時都沿著這個思路進行了拓展，下面簡單介紹兩個功能點，我自己稱之為靜態和動態的決策樹剪枝。

前面提到過，我們會對流量進行風險維度的劃分，即畫格子執行最必要的規則。引擎的產品態設計也充分考慮了這一點，風險政策同事可以對特定場景定義自己需要進行畫格子的特定維度，在線鏈路只需要基於這份靜態數據先查詢出必要的維度數據，就可以最大可能的對決策樹進行裁剪，達到降低不必要數據查詢的目的。

同時，並不是所有業務場景都適用於畫格子來將風險規則的生效限定在一個特定的範圍內，某些泛場景的規則依賴很多風險數據，例如行為時序異常，如果全部查詢會對讀 IO 有很大壓力。

我們設計了一套方案來支撐對這些規則進行動態剪枝，簡單來說就是發現決策樹中的一些關鍵節點，不需要其他節點的結果也能大機率產生整體的決策結果，這裡的其他節點也意味著更多的風險數據查詢。

具體的實現分為兩步，首先在離線基於線上日誌分析具有傾斜數據分布的關鍵節點，將具有這樣節點的風險規則彈出到預決策鏈路，之後預決策鏈路只查詢這些關鍵節點的關鍵風險數據，有很大機率可以提前獲取決策結果或者只需要查詢其他節點的部分風險數據。

綜合來看，決策引擎將數字化的規則執行控制在 1ms 以內，同時提供了很多降低 IO 成本的可能性，大大加速了風控決策的響應。

前面提到過，在日常的業務疊代中，風險政策同事會基於風險對抗的需要去調整一些風險數據，例如名單、買賣家等級、限額處置、風險規則等等，這些風險數據的的改變都會對整個決策樹的決策路徑產生影響。當一些影響比較大的變動上線前，風險政策同事需要對變動的數據對攔截率有多大影響有一個明確的感知，這是在離線無法完全模擬的。

因此我們提供了全鏈路 beta 的能力，建立在決策流程的完全數字化之上，任一決策流節點都有 release 和 beta 兩個實現，對風險數據變動而言主要是獲取數據的方式不同，任一變更的風險數據也會有 beta 版本，通過採樣部分線上流量用做旁路流量，在 beta 版本決策流節點組成的決策樹重放這部分流量，就可以實現洞察全局影響的效果。

如同 PPT 上的例子，調整賣家等級後，基於 beta 版本的決策流節點基於 beta 的賣家等級動態生成了新的決策樹，不論是決策路徑還是規則風險矩陣都產生了變化，那旁路流量在新的決策樹上執行就有可能產生不一樣的諮詢結果，風險政策同事會根據這樣的測算結果來評估整體的上線影響。

從這個例子也能看出，金融業務對嚴謹性要求是非常高的，而這也只是我們對安全生產所做的努力中比較有技術特色的工作，在這裡拋出來與大家分享。

實時風控業務除了面臨日常的流量壓力以外，還會面臨很多特殊狀態，正常業務向的有大促、直播等，而異常向的有諸如風險規則異常攔截等等，如果對於上述特殊狀態的保障都完全需要人工介入，特別是對於沒有提前告知的特殊狀態，勢必無法滿足快速的響應要求，造成線上故障。因此，在面臨這樣的特殊狀態時，實時風控系統需要有一定的自適應能力進行保障。

這裡舉兩個例子來解釋我們如何通過建設系統的自適應能力來應對上述的特殊狀態。

前面已經提到過，我們會對所有線上的風險規則進行健康度的監控，包括攔截率等等，同時結合風險政策同事在平台配置的風險規則健康度閾值。

如果全局視角來看風險規則的健康度指標與前述配置產生了預期外的嚴重差異，該差異是通過當前時間窗口的攔截率與時序資料庫中存儲的之前時間窗口的攔截率比較得到的，比較的規則和依賴的數據來自於平台配置，那麼實時計算任務會將信息推送到所有線上機器，線上機器會對該風險規則進行熔斷或者降級，並通知相關風險政策同事，從而達到系統的自適應降級。

另外，對可能出現的直播流量突增的風險場景，線上的單機會有對應場景的限流器感知秒級別的流量變化，如果流量增長有超出單機承載能力的趨勢，那麼會對該風險場景自適應的降級到事先配置好的降級方案，從決策樹的視角看就是會裁剪某些節點，而從多級決策的視角看可能是原本需要深度決策的部分流量只跑前兩層的規則，來保障系統不會被突增的流量壓垮。

同時，之前提到的旁路模式更偏重於安全生產的範疇，回放的流量是線上流量的採樣，不真實對客生效，因此也沒有實際的風險表現。最後，疊代效率也很慢，離線研發的規則需要等到全量在線生效後才能去看到該變更的實際風險影響。

我們期待實現一個由數據智能驅動的研發流程，既能幫助風險政策的同事更快地疊代策略框架，也能為風險政策同事優化甚至推薦策略框架。

首先，我們建立了一個 AB 實驗體系。我們參考了 Google 的 AB 實驗體系，通過分層解決了流量飢餓的問題。在同一層級中，我們根據風險規則的主鍵維度，進行流量分流，例如針對買家的規則和針對賣家的規則，分流因子是不同的。

這樣，我們主要解決了旁路驗證無實際風險表現的問題，可以幫助我們的風險政策的同事，根據切出的小部分流量，快速驗證某項規則是否有效，加速他們的研發流程。

其次，我們有一個 閾值優化的框架，即在目標約束下去優化現有的策略框架。舉個簡單的例子，在風險規則制定時，通常有一個預期的目標，比如他們想降低套現率，但在線上不能增加攔截率，因為增加攔截率意味著會影響 GMV。

在上述的策略框架中會有一些閾值，例如多大時間窗口內反覆嘗試多少次會被認定為一個異常行為，之前的策略研發經驗這些閾值更多是專家直接定性然後離線大致測算的，我們提供了算法能力來調節這些閾值使之更接近該策略框架的預期目標，幫助風險政策同事優化他們的策略框架。

今天我主要分享了如何使實時風控決策系統實現極速響應和高可用性。實時風控決策系統的在性能方面的核心優化手段是降低 IO，我之前提到的多級決策、分層決策、預決策和規則精簡，本質上都是為了減少 IO。

除此之外，我們還需要考慮金融領域的嚴謹性問題，進而衍生出來極致安全生產和高可用的要求。最後，就是我們期望在數據智能化的道路上進行一些更深入的探索，也希望我今天的分享能為大家帶來一些收穫，謝謝大家。

嘉賓介紹

馬希民，螞蟻金服高級技術專家，本科和碩士就讀於清華大學精密儀器系，碩士畢業後前往新加坡，期間主要從事大數據研發相關工作，2020 年回國後加入螞蟻金服，目前帶領團隊致力於打造高可用、高並發、數據智能的在線實時風控決策系統。

活動推薦