風控系統從0到1的過程，極具借鑑意義
鄧文俊，小米高級研發工程師，2013 年加入小米，參與了數據後臺，風控系統，支付等系統的研發工作。
我來自小米支付，今天分享的主題是小米風控實踐。爲什麼選風控這個題目？其實在我看來風控對互聯網金融來說，風控就像是內褲，每個人都有，但是不會把它秀給別人看。對其他人來說風控是很神祕，今天帶給大家看看小米我們怎麼是一步步走過來，在風控方面做了哪些工作。 小米風控可以分爲三個歷程，嘗試、發展和擴展。
一、嘗試
2014 年的時候我們發行我們米幣短信充值渠道壞賬率非常高，高到我們幾乎賺不到錢。米幣像 QQ 一樣，是虛擬幣，用米幣可以在小米生態圈內購買所有服務。短信什麼渠道呢？用戶用短信發一條短信給運營商，運營商就會從它的帳戶裏面扣錢轉給我們。運營商每個月給我們結一次錢，他會告訴我們有一些帳是壞賬，他不會把錢給我們。他也不會告訴你哪些是壞賬，哪些是好帳。我們要自己想辦法解決壞賬問題，讓自己有錢可賺。
我們設定兩種風控規則，這是第一種規則，我們叫限額、限次、限頻規則。設備、帳戶、手機號是一個標識類。另外一個緯度是限制類，限制交易範圍，比如時間、業務、渠道等等。最後還有限制方法。我們的版本里面一個規則包括三個部分，一個是標識，一個是範圍，一個是限制方法。
一個帳戶一天之內他的消費金額上限是 100 米幣。還有一種情況是策略，大家支付都是用手機，這個設備每小時某個業務交易次數可以限制。還有交易的頻率，比如一個帳戶這次交易跟上次交易要超過，不然很可能是機器行爲。一般用戶不會頻繁交易，除非你是玩遊戲非常上癮，一般不會出現這樣情況。
第二類規則限制是標識屬性之間的關係，比如我們一般認爲一個帳戶只會登錄到有限幾個設備，不會登錄太多。反過來能夠登錄設備也是有性質，要排除測試情況。有了這兩個規則之後，我們迅速開始開發，以互聯網的模式用了四周就迅速開發，完成了這樣的規則引擎在控制檯，控制檯可以修改規則也可以看到實時效果。開發完了之後我們沒有立刻上線，先試運行 2 周，過程是什麼？
試運行過程中規則並沒有真正的生效。只記錄一些交易，會被哪些攔截不成功，有了這些數據之後，我們可以條件規則這些順序以及閾值，使我們的規則達到最佳效果。運行兩週之後有信心，才能真正起來。
上線之後的效果，首先上線一個月之後，運營商一個月之後給我們結錢。一個月之後我們才知道我們的風控效果。上線之後我們發現我們的壞賬率比之前最高峯的時候低 1/3。比歷史上的壞賬率低 1/2。我們渠道成本佔到 1/2，我們可以賺錢了。我們一個月的收入多了 50% 左右的增長。
通過這次風控實踐嘗試，我們有一些經驗。第一不要小看簡單規則，我們開始的時候我們認爲最簡單，效果相當好。風控是平衡的，我們目標是達到一種平衡。我們的交易額和我們壞賬率之間達到平衡，使我們收益率是最高的。爲了達到這個平衡，我們需要不斷的利用雲的手段，分析數據，調整規則，這是我們決定風控成敗很重要的關鍵。
2014 年底，我們有很多小米用戶，如何給小米用戶打分，可以是信用分，風險分。信用分可以用於信貸，風險分可以用交易時風險控制。數據有限，我們用米幣的形式做模型。
我們用三個緯度建立模型：
- 還款能力 ，包括用戶最近三個月的消費額、消費次數以及累計消費次數還有他的消費情況。比如他在遊戲、閱讀、視頻等不同業務說消費情況怎麼樣。
- 依賴性 ，對小米生態圈多麼依賴，會不會上癮，如果走了會不會很痛苦。我們在依賴性方面選取他的註冊時間，活躍度，每天花多長時間，還有他使用 App 的情況，最長使用 App 有哪些，頻率怎麼樣。
- 正常度 ，我們看這個人絕大部分正常，也有不正常。我們用之前積累，使用等待充值頻率，等待有風險。類似這樣的屬性，我們給用戶進行打分，這個是打分的圖，橫軸是依賴性，縱軸往上是它的還款能力。X 軸是依賴性，Y 軸是還款能力，Z 軸是正常度。
（點擊圖片全屏縮放）
大家可以看到用戶分佈是非常集中的。我們本來想通過這個圖能不能發現一批還款能力、依賴性和正常度都比較高的用戶，最後可以做我們的優質用戶，作爲未來信貸基礎。但是很遺憾，我們數據有限，我們沒有找到這樣的用戶。我們只是發現一個事實，我們絕大多數的用戶都是還款能力和依賴度很高的正常用戶。
二、發展
我們再看 2015 年之後，我們開始了開發自己的第三方支付。我們爲小米網、小米生活等小米生態內的其他業務進行金融服務。我介入服務越來越多，我們發現我們遇到的問題越來越多，我們有時候會遇到突發事件，有了方案之後我需要能夠迅速上線一些風控規則。因爲我們發現每晚一天可能我們的損失都是百萬級，希望快速創建風控規則。
業務越來越多，規則越來越多，規則之間的次序都是有嚴格的要求。制定規則越來越麻煩，越來越容易出錯，如何解決這兩個問題？我們最後選擇了一個開源 Drools，第一它是開源可以免費使用，第二它是 Java 可以很方便擴展，開發自如，進入自己的系統，第三它非常齊全。
這是 Drools 的例子，規則分爲三部分，第一是規則名稱和它的一些配置屬性。第二部分是描述什麼事件下會觸發這個規則。第三是規則理由。
基於 Drools，我們重新搭建了我們的風控系統，風控系統分成了三個部分，普通規則、CEP 規則和管理後臺。
CEP 規則引擎和普通規則引擎區別是它是一種狀態，能夠緩存數據。剛纔大家看到規則，數據實施同步到規則引擎中去。
使用了新的風控系統以後，我們的開發效率和我們運營效率明顯提升。5 分鐘上線規則，迅速止損。新規則上線到上線調整一週到一天。現在規則非常簡單，他們也可以來調整規則。業務同學可以調整規則。
當然規則的調整變容易之後，也是把雙刃劍，帶來一些其他的問題，有時候規則上線，沒有經過嚴格測試，也沒有注意觀察規則上的效果，只出現過一兩次的事故帶來一些小的損失。我們之後爲了解決這個問題，我們重新搭建了一個灰度風控系統，這個系統上上線新的規則，利用歷史訂單驗證規則效果，驗證成功測試再把放在上面去，這個效果非常好。
風控打點，應用系統要主動調用風控，所以風控在業務系統中需要打點，打點多少位置有技巧，太多風控系統有很多數據低於自己的分析，對業務系統來說非常麻煩。我們採取一般打兩個點夠了，第一是交易前創建訂單之前進行第一次調用，第二次是訂單完成之後，只需要調用兩次就可以了。
雖然我們有了新的風控系統之後，開發效率、研發效率提高，運行效率沒有達到我們期望。我們因爲風控系統要爲業務系統提供服務，風控系統響應時間過長，會影響業務響應時間，會影響用戶的體驗。第二，我們現在專門的數據緩存，我們數據都放在 CEP 系統中，拿不出來，無法做後續分析。爲了解決這兩個問題，替換 CEP 系統，自建一個數據累計服務蒐集數據。並且對於非實時性其他數據，我們採用日誌方式，離線去進行分析。
上圖是我們之前的風控系統，下圖是我們修改之後的風控系統。同時在服務裏面把數據導出來實時監控每天每分鐘，我們整天的攔截率。
我們的風控系統響應時間縮短爲以前的 1/4，並且能夠實時監控規則運行效果。
（點擊圖片全屏縮放）
可以看到將數據和計算分離能夠解耦帶來巨大的好處，另外一方面數據應該儘快用起來，不要只是放在那裏，儘快用起來，迭代起來，能夠通過反饋蒐集更高效的數據。
我們完成了風控系統建立之後，我們回到問題的本質，另外一個問題就是除了拍腦袋，還有其他的規則制定方法嗎？我們發現我們其實可以利用機器學習的方式，從案例庫中間學習模型，學習規律。同時對於案例庫中已知的壞人，我們通過關係找到它的同夥。
從案例庫學習方面，我們從案例庫中和線上正常交易庫中隨即挑選兩組數據。分別形成我們的訓練集和測試集，選取交易數據 17 個交易特徵：交易時間、交易者年齡、交易者所使用地理位置、註冊地理位置、手機號歸屬地是否一致等，尋求這些特徵，用了四組分類器，在測試集、訓練集上進行訓練，得到四組模型。最後再用測試集比較這四種模型優劣，最終 我們選擇隨機森林模型 。
找關係，我們利用交易數據裏面用戶、設備、手機之間關聯關係建立一個關聯圖，裏面很多關聯子圖。
從案例庫中導入相關的壞人的用戶和設備，找到有關係的設備和用戶，找到之後，在檢查這些設備帳戶交易特徵。如果發現是壞人就把它加入到黑名單。通過這種方式我們預防了盜刷案件。在隨機森林模型上線五天之後，我們發現好幾筆盜刷，豐富了黑名單 。從損失和錯誤中學習，把我們的損失變成我們財富。
隨着業務快速發展，我們的經驗越來越多，我們積累的案例庫越來越多。我們發現很多風控問題一個很重要的問題本質是我們的交易對手是誰？他是不是本人？是不是真人？還是一條狗。我們解決這個問題考慮到我們可以利用小米生態裏面海量全面的各種各樣的用戶數據。我們這裏面能夠知道一個小米帳號他是男是女，興趣愛好是什麼，年齡，學歷等等這方面都是有一個畫像的。
（點擊圖片全屏縮放）
這是我們畫像組提供一個頁面，這裏面他把用戶分成用戶畫像、設備畫像。設備畫像裏面包含了 793 條各種關鍵屬性，我們利用其中設備屬性以及消費屬性建立相應的規則來檢查用戶的真實性。這樣做了以後，我們的 盜刷案件的比例近幾個月來下降 40% 。
三、擴展
給我們的啓發是他山之石可以攻玉。最後 2016 年以來小米的業務不斷擴充，除了之以外，我們還陸續開展貸款、理財、保險、分期等等等等各種各樣的業務。這些業務都需要風控，在小米體系下如何共享資源，建立風控體系？
我們解決思路是 對內共享所有數據，對外分享合作 。首先 CTO 牽頭下我們建立一個基礎風控組，在小米內部協調資源。如果我們需要建立服務的時候，我們建一份，實名認證服務。一個組建立這個服務，分享給其他組使用。在外部合作方面，一個團隊有同盾和前海，也可以分享給同事使用。
小米這幾年在金融方面擴展非常快，我們陸續開發各種各樣業務，我們也希望這一方面牛人加入我們。謝謝大家。
Q&A
Q：做風控，你們利用一些簡單 Drools，這個 Drools 包括什麼？這個 Drools 怎麼定的？後續你們用的一個隨機森林框架，怎麼把 Drools 放在這隨機森林裏做的。效果提高了大概 40% 左右，您更詳細的介紹一下。如果不方面展開，能否簡單舉兩個例子。
鄧文俊：比如盜刷，有地理位置，他交易的時候他有一個地理位置。我們知道他註冊的時候有地理位置，他手機號歸屬地有地理位置，他的身份證也是有地理位置。他最近三個月使用的設備在哪登錄過，這些都是可以做限制。
Q：你們是怎麼在風控模型中選用隨機森林這個模型，底層是不是用了什麼開源技術或者一些開源學習框架？
鄧文俊：我們所有東西都是用開源的，怎麼用隨機森林？現在所有東西是基於剛纔看到框架叫風控 Drools 框架，它的規則引擎可以調用外面服務或者外面資源。可以由隨機森林模型，可以由別的模型，把每個模型學到的東西都可以做成一個獨立的服務或者合到一個服務裏面。在規則裏面調用這個服務，把參數一些背景信息告訴這個服務，這個服務判斷或者是有多少的概率是危險。再由規則本身來決定。我們是由規則引擎進行推理，其他所有服務只提供一些參考，最後規則服務來最終決定。事先學習好之後，以服務形式加載起來，放到內存起來，來調用。
Q：訓練的時候這個有多少個？
鄧文俊：有 17 個。
Q：剛剛我看到你們規則引擎開發是四周就可以上線，你們團隊規模以及你們現在運營團隊是大概什麼樣的配比？你們進行開源技術選型的時候所考慮這些方面是什麼？
鄧文俊：
- 當時風控就兩個人，我開發，還有一個定規則。
- 風控分三個部門，研發、運營、數據，大概二三十人。到了第三方支付牌照之後可以爲外部服務。支付寶據我所知至少一千人。
- 其實主要考慮方面就是一個，第一安全大家都用過，這是最重要。其次是不是很好用很好上手，文檔齊全不齊全。第一很重要，是不是用過，是可靠的。
Q：您剛纔說一開始的模型和後來的模型，模擬的模型是一直在迭代嗎？
鄧文俊：可以調整閾值，沒有用高大上的東西。
Q：我看你之前模型一直在，後來走到機器學習，也是四種不同分類器，您選了隨機森林。機器學習裏面有一個問題，過擬合的問題怎麼解決？
鄧文俊：不解決，隨它去吧。快速開發，快速上線，看迭代。
Q：您現在算法也是不斷迭代過程當中，可能有一些問題沒有暫時解決是吧？
鄧文俊：說實話，我自己感覺我們沒有過擬合的問題。
Q：您採用機器學習算法，有一個問題機器學習如果你樣本集和訓練集給到合適的劃分，劃分過程中、訓練過程中，如果劃分不合適或者算法有時候像過擬合抖動沒有到合適地步，可能就會慢慢繼續擬合，導致沒有沒有辦法恢復。您在機器算法上面現在走的方向上有什麼和大家有一些在互聯網金融方向特殊的一些設計嗎？
鄧文俊：目前沒有，我們也是剛剛開使用機器學習的方法，摸着石頭過河，走一步看一步。如果我要回答你的問題的話，我給的建議是我們做的時候在企業裏面其實不像高校管太多，設計那麼完美或者會考慮那麼多過擬合方面的科研問題、學術問題。我們先上再說，看效果，適者生存。我們並沒有太關注過擬合的情況，算出什麼結果就拿來用，有效，我們發現盜刷，發現有用，可以再調整。
Q：您剛剛說您樣本的這些特徵都是通過小米生態平臺獲得，包括地理位置，可能是一些帳單信息。現在有一個比較爭議的問題，您獲得這些緯度和用戶隱私政策上咱們有什麼思路？
鄧文俊：小米已成爲國內首家和 TRUSTe 公司就用戶隱私保護展開合作的手機廠商。我們有兩個原則， 第一、收集數據時，收集任何用戶隱私數據都是要獲得用戶允許 ，默認是不許可的，需要用戶明確授權。 第二、使用數據時，數據平臺保證用戶數據是機器可讀，人不可讀。 我們做分析的時候我們有一個樣本的數據做模型，做測試。做完了以後，我們把我們的系統代碼或者服務掉到線上跑得時候纔是跑的真實的數據庫。原來都是看不到，只有機器可以讀，人是不可以讀。
Q：我本身是做大數據研發，我對金融這方面感興趣，我又讀了金融 MBA。您說研發風控有一些系統，開始的時候是一個風控機組給你說一個業務去做。是不是一個人把金融和 IT 技術都掌握的比較好，把這個系統研發好一些，一個人就專業就建立一個好的團隊，大家去合作比較好一些？
鄧文俊：這個問題超出技術範疇，從我的角度我自己的體驗，我覺得首先應該把自己的事情做好，你有餘力可以瞭解其他人的合作。
