基於規則引擎的客戶風險評分 – IBM ODM實現

通常的業務規則我們使用If then的形式來描述，而現實生活中的企業業務決策要復雜得多，一般由多個規則組成，而且其復雜性很難直接通過經典的基於rete的規則引擎利用其推理能力執行多個if then語句來解決。需要對規則流的設計，模型的建立，規則的層次結構有一個整體的考慮設計，以真正達到企業運營決策邏輯的敏捷變更的目的。

本文將使用一個金融行業常見的客戶風險評分場景，來說明怎么利用業務規則技術（IBM ODM/JRules）實現復雜決策。

客戶風險評分需求

所謂客戶風險評分，就是根據客戶信息使用特定的公式規則算法計算出用於標識客戶風險級別的分值，在金融行業廣泛的應用，如銀行信用卡申請，個人或企業貸款審批。自動化的客戶風險評分可以提高風險管理的及時性，確保評分決策的一致性，減少人工干預，進而實現業務流程自動化，降低運營成本。通常企業希望評分機制可以根據情況隨時調整，包括評分參數，計算公式，風險因子等。如果使用代碼方式或者數據庫參數表的方式實現評分邏輯，其靈活性通常難以達到用戶的期望。

一個客戶的具體風險評分需求如下：

1. 准入規則

- 申請人的年齡比如大於18歲，小於60歲

- 申請的金額不得超過1,000,000

- 申請人必須有正當職業，不接受無業者的申請

2. 評分規則

以下表格是客戶風控部門設定的評分標准的一個子集，實際的評分模型當然遠遠比示例復雜，某些因子之間有關聯關系，其權重或者風險分值也可能相互影響。

風險要素	權重	缺省分值	風險要素取值范圍	風險要素分值
Age	10%	10	< =25	75
			26 - 30	30
			31 - 45	10
			> =46	50
Gender	5%	20	Male	100
			Female	50
Education Level	15%	20	High School	80
			Associate Degree	50
			Bachelor Degree	20
			Master Degree	20
			Doctor Degree	50
Employment Type	10%	20	Employed	20
			Self Employed	50
Corporate Type	10%	30	Top 1000 Corporations	10
			State Owned Corporations	20
			Others	30
Business Nature	5%	20	Investment	80 - Employed 100 - Self Employed
			Banking	60 - Employed 100 - Self Employed
			Consultancy	50 - Employed 100 - Self Employed
			Agriculture	30 - Employed 50 - Self Employed
			Construction	30 - Employed 50 - Self Employed
			Education	10 - Employed 30 - Self Employed
			Others	10 - Employed 20 - Self Employed
Monthly Income	20%	20	<=5000	80
			5000 - 10000	40
			10000 - 40000	20
			>=40000	60
Position In Company	15%	20	Sole Proprietor	80
			Top Management	60
			Manager	40
			Professional	20
			Contractual	50
			Others	10
Months Of Employment	10%	20	0-12	100
			12-36	60
			36-60	20
			>=60	10

至於這個評分標准是如何出來的呢？通常有兩種基本途徑：

1）根據金融機構風控業務專家的經驗，確定要素及其權重分值

2）通過對大量歷史數據的統計分析，發掘出用戶行為模式，由此關聯到特定風險要素，

具體做法不是本文討論的重點。

3. 分級規則

根據風險分值進行分級，確定應該采取的動作，供后續系統或人員參考。

分值	風險級別	動作
<=30	low risk customer	Accept
31 - 50	Medium risk customer	Accept
51 - 80	High risk customer	Review
>80	Very high risk customer	Reject

總體而言，客戶希望可以靈活添加更多的准入規則，增加刪除風險要素，修改各要素的權重及分值，調整分級策略。

模型設計

在ODM/JRules中，規則模型包含兩層，執行對象模型（eXecution Object Model）和業務對象模型（Business Object Model），XOM的設計類似於Java對象模型的設計，

針對上述需求，我們設計如下簡單的對象模型

由於風險要素需要動態添加，我們定義RiskFactor類型，包含名稱，權重，缺省值等屬性，Result中使用list存儲運行時創建的風險要素。常我們會在XOM中定義一些操作，用來描述比較技術化的邏輯，例如Result中的addRiskFactor方法會創建RiskFactor對象並加入列表，這樣可以避免將不必要的復雜性暴露到規則層面。

接下來，利用規則設計器生成BOM，詞匯化模型中相應的屬性和操作，並將Application和Result分別指定為決策服務規則集的輸入輸出參數。

規則設計與實現

規則設計一般從規則流開始。規則流是現在規則管理系統中一個基本組件，把決策流程以圖形化可理解的方式展現出來，並在執行期幫助規則引擎更合理的控制規則執行，

有人可能會問，規則引擎不是可以根據規則和事實進行推導嗎？為什么需要顯式的指定其執行順序？事實上目前的企業應用中，很少完全利用規則引擎的推導能力來做出決策，業務決策通常是可解釋的，當規則業務含義層面的前后依賴關系非常明顯，我們就可以使用規則流來顯式定義其執行順序，這也可以幫助業務人員/開發人員更好的理解決策的流程，從性能的角度規則引擎只選擇一部分規則執行。

根據前面的需求描述，我們設計如下的規則流來描述決策流程：

1）首先是准入資格的檢查，即根據用戶信息進行篩選，如果用戶不符合准入資格，規則流將直接退出

2）第二步進行評分，使用了一個Subflow，包含Definition和Scoring兩個步驟。

3）最后根據用戶風險分值進行分級。

每個規則任務中均引用了一部分規則，當規則任務執行時，規則引擎將使用規則集輸入參數或Working memory中的事實數據驗證該部分規則。

下面我們來具體看看規則的設計。據准入檢查的要求，Eligibility規則主要檢查用戶數據，相互獨立，如果申請人違反了任何一條准入規則，結果中的qualified標識將被設置為false。反之，如果沒有任何准入規則被觸發，規則流將進入風險評分流，否則直接退出。

根針對用戶年齡的規則如下：

我們也可以隨意增加其他的規則，例如

缺省情況下，所有的Eligibility規則都會驗證。一個常見的需求是，只要有一條規則被觸發，即意味着該客戶不符合准入資格，規則任務立即退出無需執行其他規則，此類需求可以通過設定該規則任務的Exit Criteria為RuleInstance實現。

接下來在評分子規則流中，Definition任務的目的是在評分之前實例化必要的風險因素，設定相關參數，如Name，Weight等，並將風險要素加入到Result對象中。

請注意這個決策表中所有的規則都將被規則引擎執行，示例中的condition列僅作為開關之用（ODM/JRules要求決策表必須有條件列）。這種參數化決策表是規則設計中常見的做法，可以讓用戶靈活添加新的風險要素。

下一步Scoring任務的目的則是將風險因素與用戶數據進行規則匹配，確定其分值。我們首先利用Scoring任務的Initial Action將definition階段定義的風險要素加入Working Momory

在評分決策表中，我們使用預定義變量通過唯一的名稱來綁定Working memory中對應的風險因素對象，Age評分所使用的預定義變量和決策表如下所示：

其他風險要素的評分可用類似決策表定義，如教育程度：

我們也可以使用決策表表示更復雜的打分邏輯，如組合多個用戶屬性：

Scoring任務執行完規則后后，使用Final Action對各個風險因素的評分進行匯總：

最后我們根據風險評分結果進行簡單的分級，依然應用決策表實現。

當然我們可以結合用戶申請中的其他信息，比如金額，產品等定義更為復雜的個性化的分級策略。

總結

使用業務規則技術實現復雜決策的關鍵是：

1）建立適合規則處理的靈活的領域模型

2）用規則流准確描述決策的邏輯步驟

3）合理使用規則，暴露/隱藏合適的參數邏輯

注：本文也發表於http://decisionrule.com/zh/2014/07/riskscoring,  轉載請注明出處。