有贊風控規則引擎實踐

引言

作為一家SaaS公司，有贊向商家提供強大的微商城系統和完整的移動電商解決方案。伴隨着公司產品受眾不斷增長的同時，灰黑產業也慢慢伸出了觸角，妄圖利用有贊便捷的支付、傳播等能力獲取非法的利益，因此如何高效的遏制灰黑產業的侵蝕，是我們面臨的一個重要挑戰。總的來說，目前有贊面臨的主要風險類型包括：

• 盜卡。例：盜用用戶銀行卡，在有贊店鋪上消費
  
• 欺詐。例：通過發布低價商品，誘騙消費者購買
• 套現。例：在自己創建的店鋪里進行虛假交易用以套現信用卡
• 垃圾信息。例：發布虛假消息、色情等違規商品、頁面
• 盜賬戶。例：黑客用其他平台獲取的賬戶密碼通過撞庫來非法盜取用戶在贊平台的賬戶

以上所列各種違法、違規行為危害到正常商戶以及買家利益，同時也會平台帶來資損。在減少對正常用戶打擾的前提下如何高效的對風險進行防控，是有贊風控的願景和使命。

有贊風控架構

作為風控架構的“大腦”，規則引擎的運行依賴於其他系統的支撐，包括：

1. 實時特征庫
顧名思義，特征庫為實時規則引擎提供必要的特征支持。舉個例子，當一筆訂單傳入規則引擎時，我們不僅希望得到該筆訂單對應的各種靜態特征（誰何時在某地花費了多少代價做了什么），也希望得到該人累加交易情況，這樣做出的判斷才更有說服力，這里累加交易情況的任務主要由實時特征庫來完成，我們的風控特征庫主要采用Storm架構，通過接入NSQ消息，將消息內的各種特征進行剝離、匯總、統計，統一存入數據庫及緩存中，為規則引擎提供實時統計數據。

2. 規則管理中心
有贊風控規則管理中心是供運營配置線上規則的入口，並保持與規則引擎的定時同步，規則使用數據倉庫組織，底層數據用數據庫進行存儲。通過規則管理中心，將開發人員從繁雜的規則編碼中解放出來，只需要專心開發特征即可。

3. 風控離線任務
風控離線任務分為離線規則任務、離線特征計算任務。離線規則任務主要運行離線規則以及滿足運營的離線數據需求，離線特征計算任務提供規則引擎所需的深度定制特征（如用戶評分、可信特征），主要計算框架為Hive/Spark。

4. 運營平台及工具
包括審核中心、事件表、處罰中心、信息反查中心、黑白灰名單系統、操作日志查詢、案件庫、規則評估系統等。 風控是一項和業務結合特別緊密的工作，風控系統的好壞說到底需要業務指標來衡量。對整個風控系統而言，運營平台是最終的展示方，同時運營通過這些工具也為規則引擎提供了數據支撐，完成了風控系統的閉環。

風控系統架構圖

有贊風控規則引擎

在規則引擎構建之初，我們考慮過多種規則引擎選型方案，包括自建規則引擎內核以滿足自身業務的個性化需求，而后考慮到：

• 自建規則引擎對中小型公司並不適用，開發人員重復造輪子耗費大量的人力物力
  
• 部分開源的規則引擎內嵌了優化算法，保證了規則執行效率
  
• 部分開源的規則引擎有大量的社區及成功案例支持，可方便的對所遇到問題進行反饋
  

最終，我們選擇了使用較為廣泛的JBoss公司維護的Drools。

Drools是基於RETE算法的開源規則引擎，它具有性能高、可擴展性好、功能全等特點。有贊風控規則引擎基於Drools進行開發，將事件按業務風險類型進行分類，每類布控具體的規則、模型對風險進行防控。

天下武功，唯快不破，當發生一筆潛在案件時，如果不能在短時間內發現並處理，對於資金類案件來說，有資損的風險；對於信息類案件而言，有垃圾信息被大量曝光、損壞平台聲譽的風險。有贊實時規則引擎分為事中和事后兩類，其中事中引擎采用了有贊內部的統一接口框架youzan-boot，事后采用了Storm實時流處理框架。有贊風控規則引擎可在100ms內檢測、攔截潛在的風險行為。

規則引擎代碼示例

// 反欺詐訂單業務
String bizName = "antiCheat";  
String bizModel = "order";  
Order order = new Order();  
order.setShopScore(86);  
order.setOrderNo("E2017xxxxxxxxxx");  
order.setPay(100L);  
order.setPayTime("2017-01-01 00:00:00");  
order.setPayPlace("浙江省杭州市");

// 獲取已初始化的規則數據
KnowledgeBase kBase = LoadRuleBase.knowledgeBase;  
FactType modelType = kBase.getFactType(bizName, bizModel);

// 新建無狀態的會話
StatelessKnowledgeSession session = kBase.newStatelessKnowledgeSession();

// 會話中添加監聽器
TrackingAgendaEventListener trackingAgendaEventListener = new TrackingAgendaEventListener();  
session.addEventListener(trackingAgendaEventListener);  
Object modelObj = null;  
try {  
    // 將業務模型數據轉化為相應的規則引擎模型數據
    modelObj = order.bizMO2rMO(modelType);
    // 執行規則
    session.execute(modelObj);
} catch (Exception e) {
    logger.error("Exception occurs, orderNo:{}, detail:{}", order.getOrderNo(), ExceptionUtil.getTrace(e));
}

// 獲取激活規則信息
List<Activation> activations = trackingAgendaEventListener.getActivationList();  
if (null != activations) {  
    for (Activation act : activations) {
        String actRuleName = act.getRuleName();
        logger.info("訂單:{}, 激活規則:{}", order.getOrderNo(), actRuleName);
    }
}

// 獲取規則執行后，引擎的返回值
Integer actionCode = (Integer) modelType.get(modelObj, "action_code");  
String actionReason = (String) modelType.get(modelObj, "action_reason");  
String actionRes = "actionCode: " + String.valueOf(actionCode) + "  actionReason: " + actionReason;  
logger.info("訂單:{}, 執行結果:{}", order.getOrderNo(), actionRes);  
AntiCheatRiskDTO acrDTO = new AntiCheatRiskDTO();  
acrDTO.setActionCode(actionCode);  
acrDTO.setActionReason(actionReason);  
return acrDTO;  

  
  
 
 
         

   
   
  
  
          1
   
   
  
  
          2
   
   
  
  
          3
   
   
  
  
          4
   
   
  
  
          5
   
   
  
  
          6
   
   
  
  
          7
   
   
  
  
          8
   
   
  
  
          9
   
   
  
  
          10
   
   
  
  
          11
   
   
  
  
          12
   
   
  
  
          13
   
   
  
  
          14
   
   
  
  
          15
   
   
  
  
          16
   
   
  
  
          17
   
   
  
  
          18
   
   
  
  
          19
   
   
  
  
          20
   
   
  
  
          21
   
   
  
  
          22
   
   
  
  
          23
   
   
  
  
          24
   
   
  
  
          25
   
   
  
  
          26
   
   
  
  
          27
   
   
  
  
          28
   
   
  
  
          29
   
   
  
  
          30
   
   
  
  
          31
   
   
  
  
          32
   
   
  
  
          33
   
   
  
  
          34
   
   
  
  
          35
   
   
  
  
          36
   
   
  
  
          37
   
   
  
  
          38
   
   
  
  
          39
   
   
  
  
          40
   
   
  
  
          41
   
   
  
  
          42
   
   
  
  
          43
   
   
  
  
          44
   
   
  
  
          45
   
   
  
  
          46
   
   
  
  
          47
   
   
  
  
          48
  
  
 
 
         

其中，每個規則的執行后的返回值是由運營人員根據業務需求事先配置好的。需要說明的是，我們不需關心每個規則具體返回的結果，運營人員通過在規則管理中心調整規則的優先級及執行邏輯，最終返回的執行結果將是最符合業務邏輯的值。

除了會讓具體的事件（登錄、下單、支付、發布微頁面等）過相應的規則外，有贊風控規則引擎還內嵌了一些與業務契合度較高的算法，如GBDT、FM、優化的Bayes等，作為規則的重要補充，這些算法訓練出來的模型，可以抓取到規則未覆蓋或難以覆蓋的案件。

以GBDT為例，下面介紹下算法模型在有贊規則引擎中的使用方法。

GBDT(Gradient Boosting Decision Tree)，是一種迭代的決策樹模型，與傳統的boost方法不同的是，它的每一次優化都是利用梯度下降方法往殘差減少的方向進行。這里因為我們是二分類任務（例：判斷一筆訂單是有無欺詐嫌疑），因此我們采Friedman論文中的negative binomial log-likelihood作為損失函數:
其中， 並依次設置好殘差、葉子節點值。

1. 特征提取
要訓練出高可用的模型，好的特征必不可少。好的特征的重要特點是區分度較高，這就需要算法開發人員和業務敏感度高的風控運營人員緊密配合，對配置的規則進行分析，提取出較好的規則因子，同時，算法開發人員還應對業務流程非常熟悉，發揮自己的想象力，結合實際情況，創造出高可用的特征。對實際業務而言，很多情況下，一個好的特征的加入比模型參數調優甚至模型優化更加有效，同時，好的特征還可以防止過擬合的發生。 將確定好的特征，利用Spark（出於性能方面考慮，主要采用Spark Sql導入到Hive中（對於如已知收貨電話，需要求取收貨電話歸屬地等需要二次加工的情況，采用PySpark對數據進行處理），將Hive表分區作為相應的版本號（方便對數據質量進行評估），作為單次訓練樣本。

2. 模型訓練
機器學習一個重要的需求就是樣本的數量要盡可能的多，然而風控業務天然有這方面的缺陷，以交易為例，實際被風控的案例極少，這就導致正負樣本數量極不平衡，因此我們采用重采樣的方法增加正樣本（有風險訂單）的數量，具體方法是將樣本包含的數值化特征采用SMOTE方法進行重采樣，對標簽化特征采用隨機選擇的方法重采樣，最后將二者組合成新的樣本。 實際訓練過程中，需要對算法包含的最大迭代次數、步長、最大樹深等參數進行多次適當的調節，選擇出識別率最高的參數。這里，考慮到GBDT采用的boosting方法的進化能力較快，同時為維護性能，我們的數深在5-7層之間，最大迭代次數在5-10次之間。

3. 規則引擎中運行代碼示例

GBDTTree[] gbdtTree = new GBDTTree[treeNum];  
for (int i=0 ;i < treeNum; i++){  
    String treeString = treeStringList[i];
    gbdtTree[i] = new GBDTTree();
    gbdtTree[i].getGBDTTreeFromString(treeString);
}

// 傳入字符型和分類型數據
order.setNumeric1(num1);  
order.setNumeric2(num2);  
order.setNumeric3(num3);  
order.setCategoricalA(categoryA);  
order.setCategoricalB(categoryB);  
order.setCategoricalC(categoryC);

// 得到樣本為正樣本（可疑訂單）的概率
float fValue = 0.0f;  
for (int i = 0; i < treeNum; i++) {  
    float value = gbdtTree[i].getPredictValue(order);
    fValue += learnRate * value;
}
float posRate = 1 / (1 + Math.exp(-2 * fValue));  
// 超過預設閾值，上傳至審核中心
if (posRate > GBDT_CHEAT_THRESHOLD) {  
    upLoad2ReviewCenter(order);
}

  
  
 
 
         

   
   
  
  
          1
   
   
  
  
          2
   
   
  
  
          3
   
   
  
  
          4
   
   
  
  
          5
   
   
  
  
          6
   
   
  
  
          7
   
   
  
  
          8
   
   
  
  
          9
   
   
  
  
          10
   
   
  
  
          11
   
   
  
  
          12
   
   
  
  
          13
   
   
  
  
          14
   
   
  
  
          15
   
   
  
  
          16
   
   
  
  
          17
   
   
  
  
          18
   
   
  
  
          19
   
   
  
  
          20
   
   
  
  
          21
   
   
  
  
          22
   
   
  
  
          23
   
   
  
  
          24
   
   
  
  
          25
   
   
  
  
          26
  
  
 
 
         

代碼中，由於業務的敏感性，將具體特征名稱隱去。

小結

基於Drools開發的有贊規則引擎，在Storm、Spark/Hive等流數據及分布式處理引擎的計算支撐下、多種算法模型的“法力加持下”，目前很好的滿足了有贊的風控需求，但隨着公司業務的增長，未來規則引擎的穩定性、性能、有效性也面臨着更大的挑戰，總體而言，后續還是會從規則引擎本身及算法模型兩方面出發，在增強規則引擎框架的同時繼續研究更多機器學習算法在風控業務上的作用。

參考

Drools
GBDT
SMOTE: Synthetic Minority Over-sampling Technique

			</section>

原文地址：https://tech.youzan.com/rules-engine/?utm_medium=hao.caibaojian.com&utm_source=hao.caibaojian.com