平安銀行的機器學習實踐

前言

12月份應邀在ctrip的大數據沙龍專題，分享了銀行在機器學習演算法方面的實踐，下面是主要的一些觀點和內容，在這裡也重新發布一下。

背景

銀行是偏傳統的行業，目前正在遭受互聯網和P2P等公司的競爭壓力，所以我們正在進行零售轉型，擁抱互聯網和金融科技。在最近不到一年的時間裡，我們在演算法方面做了一些嘗試和探索，並對未來的一些演算法應用有一些思考。整體來說，今天我想分享的內容主要分三大塊：

1. 業務背景介紹
2. 演算法實踐分享
3. 一些思考

第一部分：業務背景

首先來看銀行的核心KPI。從下圖中可以知道，銀行核心的KPI有兩個：AUM和LUM。

AUM表示的是在管資產，包括了一些存款、大額存單、同業拆借、央媽給銀行代管的錢，表示的是銀行從其他渠道拿到的錢；LUM表示的是借出資金，信用卡也是其中一種類別，表示的是銀行借給其他人、政府或者機構的金額。只要借出資產的利率超過借入資產的利率，那麼這筆資金的轉換就是有收益的。

在這兩個資產匯總，在管資產是重中之重，因為國家有規定，LUM/AUM應該小於某個比例，所以銀行資產規模的大小由AUM決定的。LUM相對來說是比較容易達成，需要錢的個人、機構很多，但因為風控方面的考慮，另外很多人沒有人行徵信報告，所以正常情況下從銀行申請貸款是件非常痛苦的事情，也正因為如此，現如今P2P行業、消費金融行業層出不窮，因為供給和需求的不對等催生了如今的亂象。

從上面的業務背景描述可以看出端倪，AUM的核心是客群管理，銀行要從其他渠道獲取資金是非常艱難的。LUM的核心是風控，壞賬率是需要關注的一個指標，當然壞賬率高低和利差高低有直接關係，這也就是為什麼現在的消金公司的逾期率和壞賬率比銀行高很多的原因。以上兩點之外，我們也可以了解到銀行受到的一些挑戰：1. 受監管 2. 合規性 3.獲客難 4. 數據稀疏。

受監管是因為平安銀行屬於全國性商業銀行，受到國家政策的限制和監管，所做的一切都是合規性先行，我們不能做非政府允許或者非個人授權的事情。數據稀疏是針對老客戶和新客戶來說，老客戶因為我們的產品的頻次較低，所以能夠獲取的用戶數據較少。而新客戶因為我們可以獲取的數據量更少，所以我們經常會跟外部的供應商進行合作。在這點上，其實是個機會，所以針對銀行、保險和證券這部分的金融領域公司來說，外部的數據供應商是有一定的機會的。

關於業務知識就說到這，面對這些挑戰。我們也嘗試在用一些演算法實踐來幫助提升銀行的AUM或者降低風控風險，接著我們進入第二部分，演算法實踐這塊。

第二部分：演算法實踐

在說演算法實踐之前，我們整體的數據應用的架構如下。分別是基礎設施、數據層、應用層三部分。

數據服務層主要提供的一些通用的產品和服務，而最底層的基礎設施層，我們使用的現在常用的大數據技術組件，比如hadoop，hive，spark，ES，Redis等組件。

提一下AI基礎能力這塊，說的是專門針對的演算法的一個平台級別的設計，其中核心思想是基於Docker來進行演算法方面的封裝和部署應用，達到一鍵部署和訓練的目的。目前我們正在自研這個平台，如果未來設計完成了，可以針對這部分內容進行專題分享。基於新型的架構設計，我們大大的加快演算法的迭代速度，加快產出。

之前提到了一些架構面的事情，現在重點說一下我們在演算法應用的探索，我們這邊整體的應用概覽如下：

此圖中，我們把AI能力建設大致區分成了深度學習和演算法應用這兩塊。

• 應用層面中機器學習主要說的是結合業務的場景進行的演算法應用，幫助業務提升智能化和自助化。
• 知識圖譜是針對現有知識的梳理和串聯，這部分數據在風控方面用處很多，我們現在在嘗試串聯一切，通過圖譜的方式來去發現數據不一致的地方。
• 圖像、語音和文本是根據現在業務存在的大量人工的事情，可以藉助現在新型的技術和方法來提高自動化。文本這塊，我們服務於app搜索和智能客服這兩塊。這裡提一下文本這塊，因為是場景化的需求居多，所以我們會重點發展自有的技術。
• 關於演算法引入外部供應商的原則是：如果利用一些開源的技術短時間內也和市場主流的產品有很大的差距，那麼這部分技術可以採用採購的方法來短時間內達到市場主流競爭中去。舉個例子，語音的 ASR方面，科大訊飛的效果最好，那麼我們就會直接採用訊飛的技術進行ASR轉換，但是在語音前處理和後處理方面，我們就會自研，因為在語音方面的去噪和增強方面，很多供應商是要做定製化開發的，對於定製化開發這部分，我們會自研，否則我們就只能一直依賴外部供應商，這個從長遠來說，對我們是不利的。

說完了面上的應用。我們來看一些具體的例子，有助於理解我們在某些應用是怎麼思考的。

演算法應用案例分析

先看第一個例子，關於客群管理的。

案例1：客群管理

從上圖可以看到，我們的客群是根據客戶的生命周期來進行分析和管理的。橫軸是客戶的生命周期，從獲客、遷移到流失，縱軸是業務的細分維度，這樣交叉可以區分出不同的客群出來。根據不同的客群我們會給出不同的offer和權益，不同的權益享受不同的待遇。

在客群管理中，我們會建不同的子模型用來對客戶進行精準化運營。這些不同的子模型，我們的落地方案基本是走客戶畫像這套體系，落地在標籤系統裡面，這樣其他人想調用的時候都可以直接拉出相應的結果出來。

關於客群經營這塊，其實很多公司都有涉及，但是很多公司都沒有盡心深入挖掘並細化，沒有一整套的解決方案，基本都是各個部門各自為戰。根據我們的測試上來說，通過精細化運營的方式比傳統的粗放式運營方式，成本和效益最少會提高5倍。我們銀行也在積極的進行探索，希望能夠用更加智能化的方式來提高運營，提升業務產出。

案例2：客戶畫像

第一個案例結束，接下來我們看一下客戶畫像如何賦能一線人員。下圖是我們在給一線人員開發的客群分析的界面。

可以從上圖看到，我們提供了不同的數據智能模塊，前面是一些事實性的標籤數據，用來表示當前客戶的一些基本信息，後面是一些演算法給出的推薦和預測結果。其中需要留意的是，在預測類標籤中，我們額外提供了很多的輔助決策類的數據，比如流失預測概率中，我們會提供計算流失概率的重要因素，把這些重要因素展示給一線人員，告訴他們什麼因素導致此客戶的流失概率較高。同時，我們也會提供模型預估的流失準確率和實際準確率的比較結果，用來發現當前模型是否有比較顯著的下降，以方便我們及時的進行模型的更新。

從這個案例中，告訴我們賦能一線的時候，不僅僅需要提供精準預測的結果，還需要提供更多的決策依據，否則無法指導執行的人進行有針對性的改善。

當然，提供輔助決策的前提是預測結果是不是直接可以用來決策。接下來我們來看一下直接利用模型結果進行決策的例子。

案例3：業務預測

我們接著看比較常規的業務預測的案例

這個是某業務量預測需求，項目需求是預測未來3天的業務量，根據這個業務量我們會進行排班的設計，所以這個需求是直接用預測結果進行決策的例子。

針對這個項目背景和需求，我們先拉取了數據來進行分析，發現歷史數據不全，能拉取到的數據就不到半年，所以周期性的規律我們都沒有辦法捕捉。所以我們嘗試了右邊的模型融合的方法，嘗試了不同的預測方法進行預測，然後再結合規則進行了最終模型結果的輸出。

其中歷史同天平均值表示的是最近三個月的同一天的業務量預測平均值。

其中規則的方法針對的是月初的情況，我們發現月初的結果和其他的走勢很不一樣，所以我們針對月初使用了一些固定的規則來進行預測。

通過以上方法，我們可以把預測的絕對偏差控制在9%以下，在數據量如此小的情況下能達到如此精度，我們覺得還是做的不錯的。也在此把方法分享給大家，看一下對大家有沒有一些啟發。

說完了一些預測類的事情，我們接下來說一下我們在圖譜方面的嘗試，這是個體力活。

案例4：圖譜

上圖是我們在圖譜方面做的兩個嘗試，左邊的這張圖是卡號、進件號碼和激活號碼之間的聚類結果，我們根據這個聚類結果發現了一些疑似薅羊毛的團伙，並針對這些團伙進行定點的分析，比如地域，發現的結果還是蠻有意思的，福建和山東地區的同志們比較不老實。

右邊這個圖是我們根據左圖的測試案例進行外衍生出來的知識圖譜結果，這個是我們的一個數據產品。我們可以利用這個產品查詢到不同電話之間有關係的人、不同卡號之間有關係的人出來，這個產品在對某些風險案件的反查和一些新的規則的發現是有幫助的。

在對圖譜的存儲上，我們嘗試部署了一些圖資料庫，比如neo4j、OrientDB和JanusGraph。對比結果如下：

OrientDB和JanusGraph，我們都在一定的嘗試，目前在使用OrientDB做了一些地址方面的POI存儲，用來進行多個三元組的存儲。

關於圖資料庫上，它是一個存儲介質。在圖挖掘上，我認為重要的是根據場景來進行分析和挖掘，所以多做一些數據分析和探索是重中之重，存儲只是解決了快速部署應用的問題。

我們希望在未來有更多的圖譜方面的挖掘和應用，萬物串聯是我們在做各種應用的基礎能力。

以上就是一些案例的分享，類似的案例點很多，我們現在分享的很多經驗和做法希望對大家有所幫助。

案例分享完了，接下來說一下最後一部分，在我們做一些應用實踐的時候，我們也有一些感悟，這些感悟對我們加快數據賦能公司也有一些幫助。

一些思考

第一個感悟是：

在很多演算法落地的場景中，我們都比較需要數據產品經理的角色，比如客戶畫像、客群管理、業務預測等，數據產品經理會梳理好業務和數據對接的場景，讓演算法工程師的工作職能變得相對專一一點，他只要了解業務，數據梳理並把模型開發上線就可以，而在最終的頁面展示和業務系統對接和溝通、協調上面會由數據產品經理去完成，他們同時會兼任一些項目管理的工作。通過這個分工，可以讓整個演算法項目進度完成的更加順暢。我以前帶團隊的時候，這個角色一般是由我來承擔的，即分組經理承擔，但是分組經理因為顧及的面較多，涉及到多個項目的跟進和資源協調，所以在單個項目完成度上打了一定的折扣。

現在，通過新增的數據產品經理角色，可以加快數據落地和閉環過程。演算法應用人員、數據產品經理、外部系統開發各司其職，很好的完成了數據賦能的任務。

第二個感悟是：

我們需要一個統一的AI演算法平台，集模型訓練、部署、可視化於一體。通過這個平台可以減少很多不同演算法工程師的重複工作。

上圖是我們目前使用的一個演算法平台，挺好看的，但是功能上需要完善很多，所以我們也在設計一個新的演算法平台，用來減輕一些重複工作量。現在外界也有很多公司也在開發相應的產品，其實目的就是想通過減少使用演算法的門檻來提高演算法在公司的使用情況。從目前來看，很多演算法的壁壘和門檻已經慢慢的變低了，所以未來對演算法工程師的要求就更加嚴格了。

最後，說一下比較理想的演算法平台可以參考一下UBER設計的平台模式，從數據源頭到部署運維一體化，覆蓋了online和offline渠道，架構如下圖：