機器學習在信用評分卡中的應用

SIGAI推薦

SIGAI知識庫論文解讀小視頻升級上線

支持向量機1-從線性分類器到最大化分類間隔

支持向量機2-拉格朗日對偶

支持向量機3-線性不可分的問題

支持向量機4-核映射與核函數

支持向量機5-KKT條件的使用

Generative Adversarial Nets論文解讀

【含講解視頻、講解文檔、PPT以及源代碼】

Playing Atari with Deep Reinforcement Learning論文解讀

【含講解視頻、講解文檔、PPT】

Human-level control through deep reinforcement learning論文解讀

【含講解視頻、講解文檔、PPT以及源代碼】

詳見:www.sigai.cn 知識庫

作者簡介:

張中峯

中科院博士畢業,研究方向爲信息檢索、機器學習;曾任職於百度、億贊普,有多年計算廣告相關的算法研發經驗;前融360風控技術副總監,負責線上小額信貸產品的風控算法,包括反欺詐策略及模型、信用評分卡等。

互聯網金融,特別是P2P信貸在過去幾年可以說經歷了大起大落的過山車。在經歷了2016、2017年的高速發展後,隨着整體經濟環境遇冷、政策層面監管趨嚴,行業已進入洗牌週期。特別是隨着18年7月P2P暴雷潮的出現,更是爲行業前途蒙上一層迷霧。

拋開行業話題,在技術層面上,至少驗證了大數據和機器學習技術在金融風控領域的可行性。金融風控成爲大數據真正落地並展現其商業價值的領域之一。在P2P的一地雞毛之中,大數據風控技術仍在在茁壯成長,並逐步進入精耕細作的深水地帶。越是在行業寒冬階段,反而越能體現風控的重要性。

基於AI的風控應用

一個典型的風控體系,包含了貸前、貸中和貸後三個階段,每個階段都有相應的研究問題。

貸前主要解決用戶准入和風險定價問題,即面對一個新申請的進件用戶,判斷用戶是否符合產品的放款條件及相應的放款額度、價格、期限等問題。主要包括三類問題:

1)反欺詐識別:根據用戶提交的材料進行身份覈實,確保用戶不存在欺詐行爲;

2)信用評級:與傳統銀行的信用評分卡原理一致,綜合用戶的社交數據、行爲數據、收入數據等,判定用戶的信用風險等級,評估用戶的履約能力;

3)風險定價:根據用戶的負債能力和收入穩定性,判斷用戶可承擔的月供金額,確定用戶的放款額度、償還期限等,並根據用戶風險等級確定用戶的費率。這三個問題往往是互相影響、互爲前提的。比如,對一個月收入3000的用戶來說,月供在1000左右,用戶可能履約良好,信用等級良好;但如果月供提高到4000,嚴重超出了其收入水平,即便不是有意欺詐,也可能出現斷供的情況,從而得到比較差的信用等級。

貸中一般是針對已放款用戶展開。主要研究問題包括:

1)還款風險監控:比如用戶會否因失業、過度舉債、家庭突發狀況等一些突發原因導致還款能力降低,出現逾期風險;

2)貸中風險的政策制定:當用戶出現逾期風險時,如何根據用戶風險原因制定相應的策略,減少機構損失。如爲經濟暫時困難的用戶主動延長還款期限、減少月供,甚至提供延期還款服務;

3)用戶復貸:對履約良好,且收入水平明顯改善的用戶,提供增信服務,以滿足其更高水平的消費信貸需求;或在其授信額度範圍內,提供循環信貸服務。

貸後一般是針對逾期用戶展開。由於用戶已經出現逾期,貸後風控的目標是如何刺激用戶還款減少損失。主要研究問題包括:

1)催收評分卡:將用戶按照催收難度劃分等級,並制定相應的催收策略。如對偶然逾期、出現暫時性困難的用戶,主動溝通幫助其度過眼前困難,一方面減少了機構損失,另一方面也有助於與用戶建立長遠的信任關係;而對嚴重逾期的用戶,可能需要讓更有催收經驗的人員介入溝通,甚至採取必要的法律途徑;

2)催收策略制定:由於互聯網金融主要進行電話催收,而用戶提供的通話記錄或聯繫人往往內容複雜且包含大量噪音,如何從中準確找出聯繫緊密的電話,提升催收效率;

3)失聯修復:對已經失聯用戶,如何觸達,進行用戶找回;

其中,貸前反欺詐評分卡一般稱爲F卡;信用評分卡一般稱爲A卡;貸中評分卡稱爲B卡;貸後催收評分卡稱爲C卡。

本文重點介紹A卡的建模過程。

風控評分卡建模流程

如圖1所示爲一個典型的風控評分卡建模流程,也是機器學習模型的算法過程。我們僅針對信用評分卡的建模過程,簡單介紹每個步驟。

問題定義

海森堡曾言,『提出正確的問題,往往等於解決了問題的大半』。在動手建模型之前,一定花點時間審視下建模的問題。雖然在實際工作中,我們所做的模型往往都是需求方或更資深的工程師已確定好的需求,但深入理解問題提出的背景、目標及抽象邏輯,有助於在實際建模過程中有的放矢、更準確把握每個步驟的產出。

以A卡建模爲例,建模目的包括如下幾方面:

1)確保政策的一致性,儘量減少人工干預,並利用機器學習的優勢提升決策效率;

2)準確反映並量化用戶的風險級別,政策人員可以控制和減少風險損失,因此對評分卡等級的排序能力、穩定性要求會比較高。

信貸類問題一大特點是時效低,反饋週期長。

在純互聯網領域,如廣告CTR預估、推薦算法等,算法的反饋週期往往是秒級。在廣告CTR預估問題中,用戶對所展示的廣告如果感興趣,幾秒之內便會決定是否要點擊。同時,藉助互聯網巨大的流量優勢,一天時間便能收集到千萬甚至億級的樣本,從而滿足算法快速迭代的需求。CTR預估問題中,對算法時效性要求往往更高。一些時效類特徵即便在幾天內對廣告投放有指導意義,只要模型能夠及時捕捉到這些特徵的變化,也可以放心的將這類特徵加入模型中。

但在金融場景下,用戶從拿到借款到有還款表現,週期往往是以月計。有些場景下要等半年甚至一年以上的表現週期,纔可以充分觀察到信貸人羣的實際表現。從而一個模型或策略至少要等幾個月甚至一年以上才能評估其實際效果。因此,在金融場景下,對算法的穩定性要求更高,模型分析人員更傾向於捕捉長期穩定有效的特徵,一些實時熱點類的話題反而不適合放到模型中。

好壞用戶定義:對樣本標籤的定義,需要與實際業務場景、政策目標相一致,並綜合考慮樣本量、業務歷史等的需要。如在現金分期場景中,如果畫一下用戶回款率和逾期天數趨勢分佈曲線,用戶逾期30天以後回款率便已經趨於穩定,因此可以30天以上逾期爲篩選壞樣本的依據。在某些場景下,如曾經的Payday Loan,由於整個業務週期只有半月或1個月,爲加快模型迭代速度,有時甚至會定義7+甚至1+逾期用戶爲壞客戶。在一些銀行場景中,出於壞賬計提考慮,可能定義90天以上逾期爲壞客戶。

獲取樣本

在實際項目中,綜合考慮業務發展歷史和建模目標,選取合適的建模樣本集,是影響模型效果的關鍵因素之一。建模人員有必要提前瞭解、溝通樣本時段中的關鍵政策變化,市場環境波動及產品結構調整等因素,並充分考慮到這些因素對樣本結構的影響。

如對現金貸場景,去年12月份的監管政策直接導致各小貸機構產品逾期率異常飆升,本來不會逾期的用戶大範圍產生了逾期,而在正常市場環境下選取建模樣本時,有必要排除這段時間的樣本。

對金融場景來說,觀察週期越長,樣本表現越充分。但同時也說明樣本產生時間距離現在越久遠,從而一些近期發生的市場變動便不能被捕捉到。如何選取樣本時間週期是樣本選擇中需要考慮的。

數據採集及治理,數據倉庫建設

數據倉庫建設是建模準備工作中最基礎,也是最耗時的步驟之一。數據質量好壞直接決定了抽取特徵的有效性,是模型成功的關鍵因素。

在互金場景下,系統可利用的數據源通常包括用戶自述基本資料、APP本地信息、授權抓取數據及第三方採購數據幾大類。數據來源複雜且數據量大,有必要根據業務需求、數據性質及內在邏輯對數據進行歸併、清洗,建立規範化的數據倉庫。

其中,用戶自述數據,除性別、年齡等少數信息外,諸如用戶職業、收入水平等信息在申請過程中往往很難進行覈驗。一般不推薦在正式模型中使用這類無法覈驗真僞、且用戶可隨意修改的特徵,以防止模型被有組織的hack而失效。第三方採購數據通常是結構化數據,可根據性價比及是否可回溯酌情采納。

用戶授權抓取數據通常是積累數據源中處理最耗時的數據來源。常用數據抓取項包括運營商、電商數據(包括支付寶、淘寶、京東等)、信用卡賬單、社保公積金等。這些數據的爬蟲來源複雜多樣,以運營商爲例,不僅三大運營商的服務官網結構差異很大,甚至不同省份的運營商服務網站也各不相同。運營商數據的採集首先要進行不同來源數據的對齊,其次要根據對運營商業務的理解,對數據進行基本的清洗。 如對手機號中的+86、86-、(86)等格式進行統一;同樣是主叫、被叫,在不同省份/通信服務商的名稱可能是主叫/被叫、呼入/呼出、本市主叫、異地被叫等。需要進行歸一化處理。

在實際項目中,數據倉庫的建設雖然有專門的BI或數據團隊支持,但具體數據清洗的邏輯、策略,建模工程師需要深度參與並提出建設性的意見。

特徵工程

實際工作中,對具體算法的改進、優化通常比較少,更多是直接使用線程的工具包,如R、Python的Sklearn、XGBoost等。算法工程師之間使用的具體算法上往往差異不大。此時,對特徵工程的建設則更能體現出差異。特徵工程一般包括特徵提取、特徵加工變換和特徵選擇幾個步驟。

特徵提取

特徵提取就是從規範化的數據源中挖掘有效特徵集合。可採取工程化的方法,從數據源中批量挖掘儘可能豐富的備選特徵,然後從中選擇有效特徵。具體提取的特徵集,依賴於算法人員對具體數據源的理解。

下文以運營商類數據爲例,詳細列舉特徵提取的幾個參考思路。

首先,數據源中通常可以直接解析出一些基本信息及統計類特徵。如運營商中,在網時長、運營商賬戶星級、用戶使用的套餐類型、套餐額度、月均消費金額、主/被叫次數、通話時長等特徵。

其次,從標籤分類角度。分析運營商類數據的結構,可發現其核心是詳細的通話記錄及短信發送記錄。兩類記錄的結構類似,以通話記錄爲例,一個典型的通話記錄包含如下信息:

其中每個字段都可以從某個角度爲特徵工程提供依據。根據通話日期,可將通話記錄劃分爲近7天、半月、近1月、近3月、近6月等時間窗口,也可按照具體日期劃分爲工作日、節假日等日期類別;根據通話時間,可將一天24小時劃分爲不同的時間片段,如凌晨(0-6點)、上午(7-12)、下午、晚上等;通話時長爲連續類特徵,可用來彙總通話時間。

通話對象的電話號碼集合一般非常龐大,可對其進行歸併處理。一種思路是按號碼歸屬地劃分,可區分出全國各省市的電話。 另一種思路是對號碼打標籤,根據標籤對號碼進行聚類。如根據電話邦、百度手機衛士或搜狗號碼通的標記,區分出騷擾電話、生活服務類電話、快遞外賣類、金融機構電話等,甚至根據業務積累區分號碼是否爲黑名單用戶、申請用戶或申請被拒用戶。用戶與不同號碼標籤的通話情況,可以從側面反映用戶的通話習慣和生活特點。對號碼進行標籤管理的前提,是需要維護一個足夠全面、準確的黃頁標籤庫。

由此,從黃頁標籤的思路,結合通話記錄結構,我們可以設計一套黃頁標籤類特徵衍生邏輯,總結如下:

以工程化方式,對上述不同維度之間做交叉,能夠從通話數據中衍生出幾千甚至上萬維的黃頁類特徵,爲後續建模提供豐富的備選特徵集。

用戶的通話記錄也是用戶社交關係的反映,可以從社交圖譜的角度對運營商通話數據進行重構,得到一個龐大的通話社交關係網,如下圖所示:

從而可利用Graph Mining相關技術,從通話圖中挖掘特徵。

1)利用社區聚類算法,從通話網絡中挖掘中介團伙;

2)借鑑信息檢索的鏈接分析,使用PageRank、HITS等算法,計算每個節點的社交權重;

3)標籤傳播: 通話網絡中一些節點在業務中已存在一些狀態,如申請被拒、正常還款、逾期等。可利用Label Propagation算法,將節點狀態在網絡中進行傳播。

以上,從不同角度審視運營商通話數據,可引申出不同種類的特徵工程策略。從單一數據源中可挖掘出成千上萬維特徵。這些特徵可能存在大量稀疏特徵,且很多特徵的穩定性或相關性並不能滿足建模需求。但通過特徵工程的挖掘,至少爲後續建模提供了豐富的可選特徵集。“巧婦難爲無米之炊”,足夠多樣化的特徵挖掘是模型優化的必備條件之一。

特徵預處理

抽取的特徵在放入模型之前,通常需要進行一些必要的預處理過程。此處僅簡單介紹幾個基本的預處理技術。

1)缺失值處理

對特徵的缺失值,常用的幾種處理策略是:特徵分bin時將缺失值作爲NA或單獨一類;將缺失值取特徵的中值、均值或衆數填充;缺失值直接填充爲0或-1;缺失值根據實際風險表現,填充爲風險表現最接近的一類;

2)離散特徵聚類

離散類,如省份區域等,直接使用類別取值會過於繁雜。可以考慮根據特徵在不同取值處的風險表現,將風險表現接近的值聚爲一類;

3)連續特徵分bin

對連續特徵分箱是在LR模型中常用的處理技巧。最容易想到的分箱策略是等頻或等寬分箱,但在實際建模中通常比較少採用。可以考慮借鑑決策樹的思路,每次選取使信息熵或信息增益最大的點,作爲連續特徵的分裂節點。另一種常用策略是,將連續特徵空間細分爲N個bin,合併相鄰且壞賬率接近的bin,直到整體分bin區間單調。

其他特徵預處理技術,如WOE計算、特徵歸一化等在此不再贅述。

特徵篩選

正式建模之前,一般會對特徵工程挖掘到的特徵集進行篩選,以選擇相關性高、穩定性強的特徵,作爲入模變量。

常用特徵篩選一般會考慮如下幾方面:

1)特徵覆蓋率(cover rate),選取覆蓋率達到一定閾值的特徵;

2)特徵相關性:如根據特徵本身的KS值、IV或卡方值,選擇與建模label相關性高的特徵;

3)特徵穩定性:比如通過衡量特徵的PSI,選擇隨時間波動性儘可能小的特徵。

此外,還可以通過VIF、相關性係數等指標,排除特徵之間的共線性。

評分卡建模

特徵和樣本標籤準備好後,評分卡建模的過程則比較自然。雖然深度學習等技術在互聯網領域已大行其道,在信用評分卡建模中,邏輯迴歸或GBDT等仍然是目前主流的建模算法。一方面是金融領域對特徵的可解釋性要求會更高,通過LR或GBDT建模,比較容易直觀得到每個特徵在模型結果中的權重,並根據業務經驗解釋權重係數的合理性。另一方面,實際評分卡建模中,一般入模特徵維度並不高。在低維度建模中,LR和GBDT已經可以取得比較可觀的效果。

模型評估

模型建立後,需要對模型的預測能力、穩定性進行評估。信用評分模型常用的評估指標爲KS、AUC等。 考慮到金融業務反饋週期長的特點,除了劃分訓練集、測試集外,通常會預留一段訓練樣本時間段之外的數據集,作爲OOT(跨時間)集合,以測量模型在時間上的穩定性。

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章