做信貸風(fēng)控這行快十年了從最早用SAS跑邏輯回歸到后來在集群上用PySpark跑LightGBM說實話很多人問我“大數(shù)據(jù)技術(shù)到底在風(fēng)控里起了多大作用”我一直覺得這個問題問得不好——真正的問題應(yīng)該是“數(shù)據(jù)科學(xué)在風(fēng)控里到底怎么落地才能不讓業(yè)務(wù)部門和合規(guī)部門把你建模的東西按在地上摩擦”。這篇不是通用科普是一個完整的實戰(zhàn)復(fù)盤從數(shù)據(jù)底座、樣本設(shè)計、特征工程、模型選擇到上線監(jiān)控和解釋性要求把一套真實可跑的金融風(fēng)控數(shù)據(jù)科學(xué)方案拆給你看。適合準(zhǔn)備入行風(fēng)控建模、或者已經(jīng)在做數(shù)據(jù)科學(xué)但想往金融場景轉(zhuǎn)的同學(xué)也適合業(yè)務(wù)團(tuán)隊里想了解模型在風(fēng)控體系中定位的朋友。1. 項目概述大風(fēng)控場景下數(shù)據(jù)科學(xué)的定位1.1 核心需求解析風(fēng)控到底需要什么金融風(fēng)控是一個極復(fù)雜的大系統(tǒng)數(shù)據(jù)科學(xué)在里面負(fù)責(zé)的環(huán)節(jié)簡單說就一句話把無序的用戶行為數(shù)據(jù)變成有序的風(fēng)險判斷。但這句話背后藏著的需求層次往往被外界低估了。首先是反欺詐層。黑產(chǎn)團(tuán)伙的作弊行為不是勻速發(fā)生的而是脈沖式、團(tuán)伙式的識別這類風(fēng)險需要的數(shù)據(jù)維度非常多設(shè)備指紋、IP關(guān)聯(lián)、注冊時間、操作頻次、收款賬戶關(guān)聯(lián)關(guān)系等單靠一兩張表根本做不了。其次是信用風(fēng)險評估層也就是判斷一個用戶“還不起錢”的概率這一層依賴的數(shù)據(jù)更多消費行為、社交特征、第三方征信數(shù)據(jù)、歷史借貸記錄、甚至App操作習(xí)慣的細(xì)節(jié)。最后是貸后管理層的應(yīng)用比如賬齡滾動分析、催收策略模型這些也需要數(shù)據(jù)科學(xué)參與。這個項目的核心需求可以拆成三塊數(shù)據(jù)整合能力把來自十幾個數(shù)據(jù)源、幾十個系統(tǒng)的散亂數(shù)據(jù)統(tǒng)一接入形成可分析的特征寬表。模型建設(shè)與迭代能力用可解釋性強(qiáng)、穩(wěn)定性好、效果達(dá)標(biāo)的模型完成信用評分、反欺詐打分、額度定價等任務(wù)。監(jiān)控與治理能力模型上線不是終點風(fēng)控模型必須可監(jiān)控、可回溯、可解釋否則監(jiān)管一查一個準(zhǔn)。這三塊需求相互依賴。數(shù)據(jù)整合做不好特征就是無源之水模型建設(shè)做不好數(shù)據(jù)整合就白費監(jiān)控治理做不好前面的成果隨時可能被合規(guī)挑戰(zhàn)推翻。所以做這一行千萬別把自己定位成“只調(diào)模型參數(shù)的人”那是最不值錢的位置。1.2 為什么風(fēng)控行業(yè)是數(shù)據(jù)科學(xué)應(yīng)用的最佳戰(zhàn)場金融風(fēng)控和別的數(shù)據(jù)科學(xué)應(yīng)用場景有一個本質(zhì)區(qū)別它同時具備高價值、高數(shù)據(jù)質(zhì)量要求、強(qiáng)規(guī)則約束、高試錯成本四個特征。以推薦系統(tǒng)為例建模用戶興趣推薦錯了頂多用戶不點推薦對了就賺錢模型收益是連續(xù)緩變的。但風(fēng)控不是審批一筆貸款如果模型把壞人放進(jìn)來損失可能遠(yuǎn)超這筆貸款賺的利息如果模型把好人誤殺又會直接損失業(yè)務(wù)量。這就是為什么風(fēng)控既不能“抓得嚴(yán)到?jīng)]業(yè)務(wù)”也不能“放得寬出風(fēng)險”必須在風(fēng)險和業(yè)務(wù)增長之間找那個最優(yōu)解。另外金融風(fēng)控對模型的可解釋性有硬性要求。歐盟GDPR里有“解釋權(quán)”條款國內(nèi)雖然沒有完全相同的規(guī)定但監(jiān)管對金融機(jī)構(gòu)的模型管理、客戶權(quán)益保護(hù)同樣有明確要求模型對客戶做不利決策時必須有合理解釋。這一點決定了風(fēng)控建模里永遠(yuǎn)有傳統(tǒng)機(jī)器學(xué)習(xí)的一席之地有些場景你塞個深度學(xué)習(xí)黑盒進(jìn)去業(yè)務(wù)和合規(guī)分分鐘把你打回重做。數(shù)據(jù)科學(xué)在這個行業(yè)里的核心價值不只是預(yù)測準(zhǔn)確率而是在約束條件下給出最優(yōu)的風(fēng)險定價和策略。理解了這一點再做技術(shù)選型、方案設(shè)計思路就清楚很多。2. 整體架構(gòu)與技術(shù)選型大數(shù)據(jù)底座怎么搭2.1 數(shù)據(jù)接入與存儲從十幾張表到一張寬表金融場景的數(shù)據(jù)鏈路大致長這樣核心交易系統(tǒng)產(chǎn)生訂單數(shù)據(jù)用戶行為采集系統(tǒng)產(chǎn)生埋點日志第三方征信機(jī)構(gòu)返回外部數(shù)據(jù)反欺詐系統(tǒng)記錄設(shè)備信息催收系統(tǒng)記錄貸后表現(xiàn)。這些數(shù)據(jù)不能直接拿給模型用因為它們分布在不同主題、不同粒度的表中需要先經(jīng)過采集、清洗、加工三個階段。采集層如果公司規(guī)模不大可以用Canal監(jiān)聽MySQL Binlog配合Kafka做消息隊列保證數(shù)據(jù)實時或準(zhǔn)實時地進(jìn)入數(shù)倉如果數(shù)據(jù)規(guī)模再上一點就用更完整的實時計算鏈路。我當(dāng)時接手項目的時候團(tuán)隊已經(jīng)有了一套基于KafkaFlink的實時數(shù)倉訂單數(shù)據(jù)從發(fā)生到進(jìn)入特征計算延遲控制在1分鐘左右這對反欺詐場景非常關(guān)鍵。存儲層核心是分層設(shè)計我習(xí)慣用經(jīng)典數(shù)倉分層ODS層存原始數(shù)據(jù)DWD層做清洗和標(biāo)準(zhǔn)化DWS層做明細(xì)匯總ADS層面向應(yīng)用。這套分層的核心價值有兩個一是讓不同團(tuán)隊有明確的職責(zé)邊界避免互相污染二是讓數(shù)據(jù)血緣清晰出了問題能快速定位。在存儲選型上方案是Hive做離線批處理 HBase做實時明細(xì)查詢 ClickHouse做即席分析和特征服務(wù)查詢。離線訓(xùn)練數(shù)據(jù)用Hive跑量大且離線容忍高延遲實時規(guī)則引擎和模型服務(wù)需要毫秒級查詢用戶畫像數(shù)據(jù)用HBase和Redis做KV存儲更合適ClickHouse則用來支撐風(fēng)控大屏和運營分析真的很能跑。2.2 模型開發(fā)環(huán)境離線訓(xùn)練與在線推理的接口設(shè)計可能有人覺得搞數(shù)據(jù)科學(xué)的大頭在算法環(huán)境配置沒技術(shù)含量。實際上風(fēng)控模型上線最大的坑往往是離線訓(xùn)練環(huán)境和在線推理環(huán)境版本不一致。經(jīng)典的坑是這樣踩的日志在Notebook里用1.4.2版本的xgboost訓(xùn)練出了模型文件但模型服務(wù)端的Python環(huán)境是1.1.0加載模型直接報錯。重裝版本服務(wù)端的容器依賴已經(jīng)鎖定改一個包可能連帶其他服務(wù)掛掉。最后只能把模型服務(wù)單獨做了一個Docker鏡像固定依賴版本才徹底解決。我的建議是從第一天起就把模型服務(wù)當(dāng)工程做訓(xùn)練環(huán)境和推理環(huán)境統(tǒng)一用Docker容器鎖版本號禁止漂移。模型文件建議統(tǒng)一用PMML或ONNX格式導(dǎo)出跨語言部署時超方便。但因為LightGBM的PMML導(dǎo)出對某些自定義評價函數(shù)支持不好我后來更傾向于“訓(xùn)練環(huán)境和推理環(huán)境Python版本一致直接序列化模型文件”的做法。每個模型記錄完整的特征版本和樣本版本信息做不到這一點后續(xù)排查線上問題會非常痛苦。2.3 為什么規(guī)則引擎還死不了這個話題在數(shù)據(jù)科學(xué)圈有爭議。很多算法工程師覺得規(guī)則引擎是落后的產(chǎn)物一堆if-else邏輯維護(hù)成本高、不優(yōu)雅應(yīng)該用機(jī)器學(xué)習(xí)模型全面替代。但在風(fēng)控行業(yè)待過的同學(xué)應(yīng)該都懂規(guī)則引擎不僅沒死而且在反欺詐場景中是主力。原因是反欺詐面對的是黑產(chǎn)集團(tuán)他們盯上你的模型后會用大量樣本試探你的評分卡找到漏洞后就批量發(fā)起攻擊。這種情況下模型再準(zhǔn)也未必能扛住主動攻擊因為黑產(chǎn)會在短時間制造海量低維度異常特征這時候規(guī)則能快速攔截模型則容易被噪聲干擾。另外很多場景下模型的可解釋性不夠業(yè)務(wù)部門需要找依據(jù)去拒絕用戶或跟客戶解釋這時候規(guī)則反而是更清晰的溝通語言。所以在真實的金融風(fēng)控系統(tǒng)里通常會走一條“規(guī)則前置、模型后置”的雙層策略規(guī)則引擎先跑黑名單攔截、多頭借貸過線、設(shè)備異常、欺詐團(tuán)伙關(guān)聯(lián)等命中強(qiáng)規(guī)則直接拒絕命中弱規(guī)則進(jìn)入流調(diào)或打分階段。模型后置未命中強(qiáng)規(guī)則的案件進(jìn)入評分模型給出分級結(jié)果再結(jié)合額度策略、渠道策略綜合決策。這套雙引擎的設(shè)計既能對抗黑產(chǎn)主動攻擊又能兼顧業(yè)務(wù)拓展需求同時在技術(shù)體系上讓數(shù)據(jù)科學(xué)和傳統(tǒng)計算各司其職。剛?cè)胄械臄?shù)據(jù)科學(xué)同學(xué)千萬別對規(guī)則引擎有偏見把兩種能力融合好才叫真的懂風(fēng)控。3. 核心環(huán)節(jié)樣本設(shè)計與特征工程實戰(zhàn)3.1 樣本定義觀察期、表現(xiàn)期與好壞客戶樣本設(shè)計是整個風(fēng)控建模中最容易做錯、也最反直覺的環(huán)節(jié)。風(fēng)控建模要解決的核心問題在于“好客戶”和“壞客戶”不是天生定義好的而是需要你自己根據(jù)業(yè)務(wù)目標(biāo)去構(gòu)造的。在消費信貸場景中樣本設(shè)計一般分成觀察期和表現(xiàn)期兩段。觀察期指積累特征數(shù)據(jù)的時間窗口比如申請日前6個月表現(xiàn)期指觀察客戶借了這筆錢之后的表現(xiàn)比如借后3個月或6個月。如果表現(xiàn)期內(nèi)客戶發(fā)生過M3逾期超過90天就定義為“壞客戶”如果一直正常還款或只發(fā)生過M1、M2級別的短期逾期就定義為“好客戶”。這兩個時間窗口的設(shè)計直接決定了模型的時效性。舉個例子如果表現(xiàn)期設(shè)為1個月定義M3為壞那你會發(fā)現(xiàn)壞樣本非常少模型學(xué)不到東西如果表現(xiàn)期設(shè)為12個月壞樣本倒是多了但樣本的“新鮮度”會下降——用兩年前的客群行為預(yù)測現(xiàn)在的客戶風(fēng)險效果大概率會衰減。實操中我常用的方式是表現(xiàn)期和觀察期配對滾動分桶把歷史存量客戶按放款月份分成若干桶再在各桶內(nèi)按固定表現(xiàn)期提取好壞標(biāo)簽這樣既能保證樣本量又能兼顧時間上的代表性。3.2 特征工程實操從原始數(shù)據(jù)到可用特征的完整鏈路特征工程這部分我想用一個個真實場景來展開直接對照著做就行。場景設(shè)定是消費信貸平臺目標(biāo)是構(gòu)造“申請評分卡”模型的輸入特征。第一步是基礎(chǔ)特征提取。假設(shè)線上流水表order_table記錄了用戶的注冊、登錄、點擊、申請等行為原始數(shù)據(jù)可能是這樣的SELECT user_id, count(*) AS app_cnt, -- 申請次數(shù) count(distinct device_id) AS device_num, -- 設(shè)備數(shù) max(apply_time) AS last_apply_time, -- 最近申請時間 datediff(now(), max(apply_time)) AS days_since_last_apply FROM user_behavior_log WHERE behavior_type apply GROUP BY user_id這一步得到的特征還只是對用戶行為的簡單描述信息量有限。數(shù)據(jù)科學(xué)家的價值體現(xiàn)在第二步——特征加工。第二步是比率與聚合特征。不要只看次數(shù)要看比率比如“白天操作占比”“深夜操作占比”“登錄到申請的平均時長”“近7天活躍天數(shù)”。這些比值和聚合特征可以更精細(xì)地刻畫用戶行為模式。舉個例子“近30天申請次數(shù)/近90天申請次數(shù)”這個比率實際上刻畫了“短時間內(nèi)行為集中度”對識別突發(fā)性資金緊張很有效。第三步是第三方數(shù)據(jù)交叉特征。很多平臺會采購征信公司的數(shù)據(jù)字段比如“近3個月征信查詢次數(shù)”“信用卡使用率”“已有貸款筆數(shù)”。這些外部字段不能直接用最好和自己的行為特征做交叉。我當(dāng)時有一個效果很好的特征“外部征信查詢次數(shù)×近30天App活躍天數(shù)”它解釋力強(qiáng)的原因在于高頻查詢征信說明用戶資金緊張高活躍天數(shù)說明最近在大量使用App兩者疊加風(fēng)險信號的置信度大幅提升。第四步是WOE分箱編碼。為什么特征需要做WOE編碼因為直接輸入原始數(shù)值到邏輯回歸模型模型可能學(xué)不到最優(yōu)非線性關(guān)系。WOE編碼也叫證據(jù)權(quán)重編碼它的核心思想是把連續(xù)變量分箱然后計算每一箱中壞客戶與好客戶的比值的對數(shù)用這個對數(shù)值代替原始輸入。這一步能自帶單調(diào)性約束讓評分卡更加穩(wěn)定。WOE的計算公式是WOE_i ln( (第i箱壞客戶數(shù)/總壞客戶數(shù)) / (第i箱好客戶數(shù)/總好客戶數(shù)) )分箱的目的是讓特征與標(biāo)簽之間呈現(xiàn)出單調(diào)關(guān)系而不是單純追求模型擬合。實操中我用的是等頻分箱少量手動調(diào)整的方式針對長尾極值做人工合并確保每箱的樣本占比不能過低一般要求不低于總體的5%。第五步是IV值篩選。特征做完WOE轉(zhuǎn)化后可以用IV值信息價值來篩選有效特征。IV值的經(jīng)驗閾值是小于0.02表示幾乎無預(yù)測能力0.02到0.1表示弱預(yù)測能力0.1到0.3表示中等預(yù)測能力大于0.3表示強(qiáng)預(yù)測能力。但要注意IV值過高超過0.5要警惕“看似過度擬合”——常見原因是特征被第三方數(shù)據(jù)源污染或泄漏比如你用了“用戶是否逾期”的標(biāo)簽去構(gòu)造特征那IV值當(dāng)然爆表。3.3 樣本不均衡與拒絕推斷信貸場景的壞樣本率通常只有1%到5%天然是高度不均衡的數(shù)據(jù)集。如果在不均衡數(shù)據(jù)上直接訓(xùn)練模型模型會傾向于把所有樣本預(yù)測為“好客戶”因為這樣總體準(zhǔn)確率很高但業(yè)務(wù)上根本沒法用。處理不均衡有幾個層次的手段第一層是樣本權(quán)重調(diào)整在損失函數(shù)中給壞樣本加權(quán)或在下采樣時保留全部壞樣本、隨機(jī)抽取部分好樣本。實操中下采樣比例通常控制在1:5到1:10之間太低會丟失好樣本的信息太高則壞樣本依然被淹沒。第二層是算法層面的處理LightGBM和XGBoost都支持scale_pos_weight參數(shù)它其實就是把正樣本的梯度放大了。我在實際項目中通常采用“下采樣scale_pos_weight”的組合方案訓(xùn)練時可以先用全量好樣本和全量壞樣本訓(xùn)練一輪查看PR曲線再根據(jù)業(yè)務(wù)期望的召回率調(diào)整權(quán)重。第三層容易被忽略拒絕推斷。建模樣本只包含“被審批通過”的客戶但被拒絕的客戶我們沒有其表現(xiàn)標(biāo)簽這樣直接用審批通過樣本建模會產(chǎn)生樣本選擇偏差。比如你早期審批策略偏保守很多優(yōu)質(zhì)客戶被拒掉模型只學(xué)會了在“保守策略通過的人群”里做區(qū)分它的區(qū)分能力就永遠(yuǎn)被限制在狹窄的樣本空間里。拒絕推斷的方法有幾種最樸素的是“給拒絕樣本推斷標(biāo)簽”用現(xiàn)有模型預(yù)測拒絕樣本的壞概率然后按后驗概率融入訓(xùn)練集。但這種方法存在自增強(qiáng)問題——模型錯的地方被自己放大。所以實操中拒絕推斷更傾向于只做一個“樣本權(quán)重修正”而非“標(biāo)簽推斷”通過調(diào)整被拒絕樣本的權(quán)重讓模型泛化性更好。這一塊沒有完美解決方案核心思路是承認(rèn)模型有偏差再用合理的假設(shè)去修正偏差。4. 模型構(gòu)建與評估從XGBoost到評分卡落地4.1 為什么信用評分卡至今仍是行業(yè)標(biāo)配說到信貸風(fēng)控模型繞不開“評分卡”這個詞。很多新入行的算法工程師喜歡堆模型、上復(fù)雜網(wǎng)絡(luò)但在真實金融項目里評分卡依然占據(jù)主導(dǎo)地位原因不外乎三點可解釋性強(qiáng)每個特征對分?jǐn)?shù)的貢獻(xiàn)權(quán)重清晰業(yè)務(wù)人員能一眼看懂個別高風(fēng)險客戶被拒后客服能清楚地跟客戶解釋原因。穩(wěn)定性和可監(jiān)控性強(qiáng)評分卡的輸入變量經(jīng)過分箱轉(zhuǎn)換后單變量變化對整體分?jǐn)?shù)的影響是可預(yù)期、可推測的模型上線后好做監(jiān)控和迭代。監(jiān)管友好金融機(jī)構(gòu)接受外部審計時評審更認(rèn)可這種可解釋、可追溯的方案黑盒模型則很難通過合規(guī)審查。評分卡的核心就是從邏輯回歸模型轉(zhuǎn)化過來的?；竟绞荢core Offset Factor * ln(Odds) Odds p/(1-p)p為逾期概率其中Offset和Factor通過設(shè)定“基準(zhǔn)分、基準(zhǔn)Odds、翻倍倍率”來解出。簡單說就是你定義好“當(dāng)Odds等于某個值時分值為多少”“Odds翻多少倍分?jǐn)?shù)加多少”然后由這兩個約束解出Offset和Factor。但這不代表XGBoost和LightGBM在風(fēng)控里沒價值。實際上我現(xiàn)在的做法是雙軌并行邏輯回歸評分卡作為審批主模型用于解釋、監(jiān)控、應(yīng)對監(jiān)管LightGBM模型作為風(fēng)險排序和貸中預(yù)警融合模型用于策略分層和額度定價。LightGBM的優(yōu)勢在于非線性擬合能力強(qiáng)能捕捉到特征交互效應(yīng)對風(fēng)險排名能力有一定提升。但它上線前必須做嚴(yán)格的穩(wěn)定性監(jiān)控任何特征波動都可能引起分?jǐn)?shù)劇烈變化而這在傳統(tǒng)評分卡中幾乎不會發(fā)生。4.2 模型評估AUC不是唯一答案KL散度和PSI才是很多數(shù)據(jù)科學(xué)同學(xué)習(xí)慣把AUC當(dāng)成衡量模型好壞的核心指標(biāo)。在風(fēng)控里AUC只是其中之一甚至不是最重要的。原因是風(fēng)控模型面對的真實場景里樣本分布是動態(tài)變化的AUC衡量的是區(qū)分度但不衡量穩(wěn)定性。更關(guān)鍵的指標(biāo)組合是這樣的指標(biāo)作用參考標(biāo)準(zhǔn)KS衡量好樣本和壞樣本分?jǐn)?shù)分布的差異越高區(qū)分度越強(qiáng)一般要求0.25以上高于0.5要警惕過度擬合AUC排序能力0.75以上基本可用0.8以上表現(xiàn)不錯PSI特征分布穩(wěn)定性指數(shù)小于0.1穩(wěn)定0.1到0.25輕微偏移大于0.25嚴(yán)重偏移遷移率各個逾期階段的滾動遷移分析觀察短期逾期向長期逾期的轉(zhuǎn)化趨勢PSI這個指標(biāo)以前很多團(tuán)隊不重視但我踩過坑之后強(qiáng)烈建議每個人都做。PSI的公式是PSI Σ(實際占比 - 預(yù)期占比) * ln(實際占比 / 預(yù)期占比)它衡量兩個時間窗口之間分?jǐn)?shù)分布或特征分布的偏移程度。假設(shè)模型上線時訓(xùn)練樣本的分?jǐn)?shù)分布是基準(zhǔn)到了第二個月實際客群的分?jǐn)?shù)分布和基準(zhǔn)對不上PSI飆到了0.2以上說明客群結(jié)構(gòu)變了模型可能已經(jīng)失效。這時候你不能干瞪眼等著模型效果崩盤而是要提前預(yù)警觸發(fā)重訓(xùn)練流程。實操中我每個月初的第一件事就是跑一篇模型監(jiān)控報表把以下內(nèi)容打印出來總體樣本量、好/壞客戶占比、分?jǐn)?shù)分布直方圖、分位數(shù)、PSI、KS分階段、AUC。這幾張圖和數(shù)據(jù)放在一起足夠用來判斷“模型狀態(tài)健康”還是“已經(jīng)開始退化”。4.3 模型調(diào)參與特征融合經(jīng)驗聊到調(diào)參先提一個原則風(fēng)控模型不需要追求極致的AUC。我們追求的是“在保證穩(wěn)定性的前提下把區(qū)分度做到可接受”。這個原則和Kaggle比賽選手追求第一的思路完全不同。在Kaggle上你把模型做到AUC 0.999都不嫌多在風(fēng)控中如果一個模型在測試集上做到AUC 0.95我反而會強(qiáng)烈懷疑變量泄漏或者過擬合。用LightGBM做風(fēng)控建模時我在實踐中總結(jié)的幾組相對穩(wěn)定的參數(shù)基線如下數(shù)據(jù)規(guī)模大概在百萬級import lightgbm as lgb params { objective: binary, metric: auc, learning_rate: 0.02, num_leaves: 31, max_depth: 5, min_child_samples: 100, feature_fraction: 0.8, bagging_fraction: 0.8, bagging_freq: 1, lambda_l1: 1.0, lambda_l2: 1.0, scale_pos_weight: 10, verbosity: -1, }這個基線的特點是學(xué)習(xí)率低、葉子數(shù)適中、正則強(qiáng)。模型更加平滑不會過度抓住個別的極端特征。如果是邏輯回歸評分卡特征則全都要經(jīng)過WOE轉(zhuǎn)換且特征之間要控制相關(guān)性。我當(dāng)時用的變量篩選方法可以總結(jié)為四個步驟按單變量IV值降序排序保留IV大于0.02的特征。檢查特征之間的相關(guān)系數(shù)如果兩個特征相關(guān)系數(shù)超過0.7保留IV更高的一方剔除另一方。按業(yè)務(wù)邏輯剔除可能導(dǎo)致“未來函數(shù)”的特征比如用了表現(xiàn)期的數(shù)據(jù)。用逐步回歸的簡化版本做最終特征準(zhǔn)入優(yōu)先保留業(yè)務(wù)上可解釋、可采集的特征。這套流程下來評分卡的特征數(shù)量一般控制在15到30個之間覆蓋用戶基本屬性、行為特征、征信特征、設(shè)備特征這幾個維度。5. 實操過程從零搭建一個申請評分卡5.1 全套流程的步驟拆解這部分用一個簡化的消費信貸申請評分卡來演示全流程所有步驟都是可以對照執(zhí)行的。第1步數(shù)據(jù)準(zhǔn)備數(shù)據(jù)源包含用戶基本信息表年齡、性別、收入、職業(yè)、借貸行為表申請歷史、還款歷史、產(chǎn)品信息表借款金額、期限、用途、第三方征信報告摘要。把這些數(shù)據(jù)按用戶ID關(guān)聯(lián)成寬表按“申請日”作為時間基準(zhǔn)往前取6個月的行為數(shù)據(jù)做特征往后取6個月的還款表現(xiàn)做標(biāo)簽。第2步樣本切分時間序列數(shù)據(jù)不能隨機(jī)切分要按時間切分。我用的是“過去12個月放款樣本作為訓(xùn)練集最近3個月放款樣本作為測試集”同時訓(xùn)練集中預(yù)留一部分做驗證集來做早停。隨機(jī)切分會造成時間穿越模型學(xué)到的規(guī)律會包含未來信息因為這個原因我見過太多團(tuán)隊模型上線后效果崩掉。第3步特征工程對連續(xù)變量做等頻分箱然后轉(zhuǎn)WOE編碼。對分類變量先按業(yè)務(wù)含義歸類再用目標(biāo)編碼或WOE編碼處理。這里要特別注意有的團(tuán)隊直接用one-hot把類別特征扔進(jìn)模型結(jié)果在邏輯回歸上特征維度爆炸而且泛化能力極差。具體寫一段特征轉(zhuǎn)換代碼示例方便理解import pandas as pd import numpy as np # 假設(shè)df包含特征 amount、train_flag樣本是否來自訓(xùn)練集、bad_flag好壞標(biāo)簽 def woe_encoding(df, feature, targetbad_flag, bins10): # 等頻分箱 df[bin] pd.qcut(df[feature], qbins, duplicatesdrop) grouped df.groupby(bin)[target].agg([sum, count]) grouped[bad] grouped[sum] grouped[good] grouped[count] - grouped[bad] grouped[bad_rate] grouped[bad] / grouped[bad].sum() grouped[good_rate] grouped[good] / grouped[good].sum() grouped[woe] np.log(grouped[bad_rate] / grouped[good_rate]) df[woe_ feature] df[bin].map(grouped[woe]) return df, grouped[woe].to_dict()這段代碼的邏輯是按分位數(shù)把連續(xù)變量分成10箱統(tǒng)計每箱中壞樣本和好樣本占比計算WOE值。注意WOE編碼一定是在訓(xùn)練集上計算好映射字典再應(yīng)用到測試集防止信息泄漏。第4步訓(xùn)練邏輯回歸評分卡主模型直接訓(xùn)練線性模型訓(xùn)練完成后每個特征的系數(shù)乘上WOE值就是這張評分卡的核心邏輯。邏輯如下Score Offset - Factor * (β0 β1*WOE_特征1 β2*WOE_特征2 ...)實際落地時評分卡生成的不是一個Python模型而是一張打分規(guī)則表每個特征、每個分段、對應(yīng)分?jǐn)?shù)。這張表會同步給業(yè)務(wù)系統(tǒng)和審批系統(tǒng)由規(guī)則引擎執(zhí)行。我當(dāng)時生成評分卡這張表的時候生成腳本用的是Pandas輸出到Excel文件交付給審批決策團(tuán)隊再由他們配置到?jīng)Q策引擎中整個過程是可以審計、可追溯的。第5步設(shè)定閾值和策略評分卡模型會輸出一個0到1000之間的分?jǐn)?shù)一般來說分?jǐn)?shù)越高風(fēng)險越低。審批策略一般是這樣做的分?jǐn)?shù)大于750自動通過不走人工。分?jǐn)?shù)在650到750之間視借款金額和期限走自動審批或抽查人工。分?jǐn)?shù)在550到650之間走人工審核或降低額度縮短期限。分?jǐn)?shù)小于550自動拒絕。這些閾值不是拍腦袋定的而是根據(jù)各分?jǐn)?shù)段的壞賬率、通過率、收益三者權(quán)衡得出。每次調(diào)整閾值都需要做策略模擬用測試集分?jǐn)?shù)分布模擬新策略對通過率和逾期率的影響綜合評估后才定。5.2 冷啟動階段沒有歷史標(biāo)簽怎么辦很多朋友問過我一個問題“如果是一個新業(yè)務(wù)沒有歷史放款樣本怎么建評分卡”這是金融風(fēng)控冷啟動的經(jīng)典難題。我的回答是冷啟動階段不要指望一開始就訓(xùn)練出完美的模型先解決“有比沒有好”的問題。冷啟動方案通常有三個階段第一階段0到3個月用專家規(guī)則和外部數(shù)據(jù)做準(zhǔn)入策略。比如年齡小于20或大于60拒絕、近3個月征信查詢次數(shù)超過10次拒絕、無收入證明拒絕。同時通過小額試放積累樣本。這個階段的核心目標(biāo)是“安全地搜集數(shù)據(jù)”而不是“最大化審批通過率”。第二階段3到6個月當(dāng)積累了1萬筆以上的放款樣本且最長表現(xiàn)期覆蓋了至少3個月就可以訓(xùn)練第一版簡單模型。這個時候不要直接上復(fù)雜的LightGBM先用邏輯回歸少量特征比如年齡、收入證明、征信查詢次數(shù)、借貸歷史做一張簡化評分卡。第三階段6個月以上積累的樣本足夠多、表現(xiàn)期足夠長之后再逐步過渡到完整的評分卡和機(jī)器學(xué)習(xí)模型。這個過程看起來慢但實際上是最穩(wěn)健的。很多團(tuán)隊冷啟動翻車都是因為急于訓(xùn)練模型導(dǎo)致樣本偏差嚴(yán)重后面模型的坑越挖越深。5.3 模型部署與服務(wù)的工程要點模型在Notebook里跑出好效果只是第一步要讓它真正在業(yè)務(wù)系統(tǒng)里干活有幾點工程上的細(xì)節(jié)值得多說幾句。第一點是特征的實時計算延遲。審批決策對響應(yīng)時間有要求一般在2秒內(nèi)要給出結(jié)果。所以模型服務(wù)里用到的特征不可能現(xiàn)場從Hive拉表算而是靠實時特征服務(wù)來支撐。具體做法是把常用特征預(yù)計算好寫到KV存儲比如Redis中請求來了直接查。如果用戶是新客需要實時計算特征就把需要實時計算的部分用Flink SQL或在服務(wù)內(nèi)完成控制延遲在幾百毫秒以內(nèi)。第二點是特征缺失值的處理方案。線上推理時經(jīng)常會遇到“用戶沒有某類行為數(shù)據(jù)”的情況比如借款記錄為空、征信查詢次數(shù)缺失。這就需要在訓(xùn)練階段就把缺失值處理做進(jìn)特征轉(zhuǎn)換邏輯中確保線下訓(xùn)練和線上推理對缺失值的口徑一致。最經(jīng)典的做法是WOE編碼時單獨分一箱“缺失箱”把缺失值映射到該箱的WOE值這樣缺失值本身也能貢獻(xiàn)信息量。第三點是模型版本管理與灰度切換。新模型上線不能直接全量切換要先在模擬環(huán)境中對比新舊模型的分?jǐn)?shù)分布、拒絕率、通過率再切小流量灰度觀察如果KS、PSI等指標(biāo)穩(wěn)定再逐步放量。這套流程聽起來簡單但在真實項目中執(zhí)行起來需要運維、算法、業(yè)務(wù)協(xié)同作戰(zhàn)一套規(guī)范的發(fā)布流程能省掉很多不必要的線上事故。6. 常見問題與排查技巧實錄6.1 數(shù)據(jù)質(zhì)量問題時間穿越與口徑不一致數(shù)據(jù)科學(xué)在風(fēng)控中最大的敵人不是模型復(fù)雜度不夠而是數(shù)據(jù)質(zhì)量差。我在項目里處理過大量這類問題遇到頻率最高的兩類是“時間穿越”和“口徑不一致”。時間穿越指的是特征中包含了未來的信息。舉例來說建模時你用“是否被拒過”做特征但被拒這個信息只存在于拒絕樣本中而拒絕樣本天然沒有表現(xiàn)標(biāo)簽。你用這個特征訓(xùn)練模型模型會學(xué)到“被拒過的用戶壞概率高”但實際上這個特征在線下推送時是拿不到的。解決時間穿越的核心方法就是在所有特征提取時都以“決策時點”為準(zhǔn)嚴(yán)格按照時點回溯不允許任何未來信息進(jìn)入特征。口徑不一致則更隱蔽。不同團(tuán)隊提交的特征看著字段名一樣但業(yè)務(wù)含義不同。比如“近三個月消費金額”A團(tuán)隊統(tǒng)計的是“支付成功金額”B團(tuán)隊統(tǒng)計的是“下單金額”一旦兩個數(shù)據(jù)源混在一起模型特征就會亂。所以特征倉庫要有統(tǒng)一的口徑定義文檔和血緣分線每一張?zhí)卣鞅矶家胸?fù)責(zé)人禁止無主特征。6.2 模型上線后效果衰減不是模型錯了是客群變了模型上線之后KS、AUC一路下坡是常規(guī)現(xiàn)象很多團(tuán)隊第一反應(yīng)是“模型需要迭代了”。但實際上絕大多數(shù)情況不是模型失效而是客群結(jié)構(gòu)變了。舉例來說平臺在某個季度做了一輪市場投放渠道獲客結(jié)構(gòu)變化明顯新客大多來自下沉渠道風(fēng)險偏好和之前完全不同。這時候模型沒變但輸入特征的分布已經(jīng)變了模型的判斷自然會失真。排查這個問題的正確姿勢是分兩層看看特征層面的PSI如果你的核心特征分布都發(fā)生了偏移那大概率是客群變了而不是模型本身壞了。看分?jǐn)?shù)層面的PSI如果特征分布沒怎么變但分?jǐn)?shù)分布變了問題可能出在特征計算的服務(wù)端要查評分服務(wù)的代碼和數(shù)據(jù)源。這兩個指標(biāo)分開看能快速定位問題出在哪一層。千萬別一開始就急著重訓(xùn)練模型那樣既費時間也解決不了問題。6.3 關(guān)于解釋性不是合規(guī)部門的事是模型設(shè)計者的事模型可解釋性在風(fēng)控項目中不是“加分項”而是“必答題”。監(jiān)管審計的時候評審會問“為什么這個客戶被拒絕”如果模型設(shè)計者拿不出來一個清晰的解釋這個模型就上不了線。實操中我做了三件事來保障可解釋性所有入模特征必須有業(yè)務(wù)含義純技術(shù)構(gòu)造的“黑箱特征”不允許入模。每個模型上線前都要準(zhǔn)備一份“模型說明文檔”包括特征清單、每個特征的業(yè)務(wù)解釋、WOE方向、系數(shù)權(quán)重、模型局限性等。做個體解釋時用SHAP值輔助解釋結(jié)合特征貢獻(xiàn)度給業(yè)務(wù)方提供參考而不是單純給一個風(fēng)險分?jǐn)?shù)。從整體來看數(shù)據(jù)科學(xué)在風(fēng)控中的價值越來越大但能不能真正落地考驗的不只是建模能力還有你對數(shù)據(jù)、業(yè)務(wù)、工程和合規(guī)理解的綜合水平。我個人碰過最多壁、學(xué)到最多東西的環(huán)節(jié)恰恰不是算法本身而是和數(shù)據(jù)鏈路、業(yè)務(wù)規(guī)則和合規(guī)要求對接的過程。如果你準(zhǔn)備往這個方向發(fā)展我最大的建議是先把底層數(shù)據(jù)摸透再把業(yè)務(wù)規(guī)則吃透最后再看模型怎么嵌入決策流這三步走完你的模型才能真正創(chuàng)造價值。最后再分享一個小技巧——每個新項目開始之前花一周時間把數(shù)據(jù)字典、字段統(tǒng)計和樣本標(biāo)簽分布詳細(xì)看一遍這周時間永遠(yuǎn)不會白費。