起點課堂會員權益
職業體系課特權
線下行業大會特權
個人IP打造特權
30+門專項技能課
1300+專題課程
12場職場軟技能直播
12場求職輔導直播
12場專業技能直播
會員專屬社群
榮耀標識一次風控聯合建模，我總結出了這些
編輯導讀：如今，銀行和互聯網大廠的和合作越來越頻繁。其中，一項重要的合作是聯合建模。本文作者根據自己的一次風險聯合建模的經歷，從中總結出一些問題，希望對你有幫助。
最近雷帥慢銀行著實愁壞了，行內消費信貸業務新增客戶越來越少，活躍度也越來越低了。疫情長期結束不了，消費下滑經濟下行，監管持續趨嚴，資產規模和質量都開始面臨很大的增長壓力。
雷帥慢銀行尋思，這么下去不是辦法，形勢再差，也要人為，得主動出擊去找優質資產。
怎么找，流量和質量都掌控在互聯網大廠手上。
于是，找到了雷帥快大廠，你把優質用戶給我，我們來做款產品，一起分潤。
互聯網公司都是在做流量變現，雷帥快大廠就爽快同意了。
win-win。
那快大廠怎么把優質用戶給慢銀行呢？
快大廠雖然自己也做消費信貸業務，也有內部風險評分。但風險是由用戶和產品決定的，慢銀行想要的是適合他們產品的優質用戶，快大廠的優質用戶雖然不錯，但不是最優。
這就是合作中最重要的一環，聯合建模。
慢銀行提供一批有風險表現的用戶給快大廠去匹配特征，風險是慢銀行的，特征是快大廠的。
由慢銀行同學去建模，有了模型之后就可以對快大廠的流量做精準風險評估了。
一般來說，誰用模型誰建模。
于是慢銀行和快大廠分別成立了一個小組，兩方各自指定了個負責人，專項對接該模型開發工作。
一、立項會議
小組成立之后，馬上開了一次語音會議，聊這個模型怎么建。
兩方負責人先拉了個微信群，把慢銀行和快大廠這次聯合建模相關的人員都拉進去了。
慢銀行一堆問題就跟機關槍一樣發射了，
- 你們有多少特征，能回溯到什么時候？
- 需要用什么主鍵去匹配特征？
- 你們的數據能不能傳給我們，我們直接在行內建模？
- 我們要建xgb模型，你們xgb模型怎么部署？
- ……
快大廠不爽了，你們急個毛線，
- 我們數據多著呢，近兩年都可以回溯，身份證和手機號做主鍵，我們上千個特征不出庫，我們準備好電腦和建模環境，你們帶著標簽過來。
- 你們準備多少樣本建模，最好多帶點？
- 你們自己怎么定義標簽的？
- 你們準備建幾個模型，輸出幾個字段？
一來二回，都覺得對方不給力。
慢銀行嫌快大廠特征數據不出庫，還要他們派模型同學駐場建模。
快大廠嫌慢銀行能帶出的樣本太少了，建模效果不好的話還要怪數據質量。
但好歹，一些事情還是確定下來了。
慢銀行指定了一個模型同學（慢A），快大廠也指定了個同學（快B）。
然后，慢A去準備建模需要的10w樣本，走申請流程帶出。
快B就去準備了兩臺電腦，搭建建模環境。
二、數據準備
慢A同學在慢銀行苦心經營，找了許多人開了許多會，終于確定了如何選取這10w樣本。
又潛心寫了幾行代碼抽取這些樣本，還請同事幫忙review一下這幾段sql。
然后走起了漫無邊際的審批流程，匹配加密的主鍵，樣本出庫等。
這個時候的慢A覺得自己是張騫。
此時，快B同學在快大廠申請了兩臺舊電腦，確保了無網絡訪問權限，然后安裝了下必備的Python包。
然后開始準備怎么做都有問題的特征，從特征庫里選擇了幾張合適的穩定有效的特征表，開始做一些脫敏處理。
變量的值要脫敏，例如分段處理，變量的含義也要做脫敏，巴不得改名為變量1、變量2……。
無所不用其極，這個時候的快B覺得自己是SB。
最后，還要計算變量的分布，確保分段處理后的變量分布逐月穩定且合理。
三、無窮無盡的拉扯
許多天以后，慢A終于準備好了樣本，快B被慢銀行罵了幾次SB后，變量的含義還是沒改，不過加了一個維度列。
這些加密的主鍵被發送到快B，匹配了早已不知道是什么的特征。
終于，慢A帶著這10w個好壞樣本，不情不愿地來到了快大廠的所在地，快B給安排了工位，電腦桌面放好了10w個樣本的匹配結果。
慢A開始了無腦的數據分析，統計了數據的匹配情況，對著f1、f2……的特征強壓著內心的怒火。
在旁邊拿出了自己帶來的電腦，連上熱點，開始了百度一下。
找出了早已備好的計算woe、iv的代碼塊，對著所有的變量跑了一通，篩出了一些區分度高的變量后，又看了他們的風險分布。
問天，這個單增的變量是不是應該單增；問地，這個單減的變量是不是應該單減；問自己，這個U型分布變量是個什么鬼。最后問快B，快說，我有刀。
時間無情的流逝。
模型終于建好了，慢A算了幾個KS，不由得想罵人，怎么有點低，怎么波動這么大。
找快B，找慢銀行，多方討論，也沒有什么高招，只好就這樣。
然后定了個閾值做了一些業務指標的測算，出了一個報告。
慢A把成果發送回了慢銀行，進行了遠程匯報……
最后，模型就這么定了。
這個階段慢A很煩躁。
四、模型部署
慢A把模型文件和模型變量交給快B之后，就逃也似的離開了快大廠。
此時的快B覺得氣定神閑，上線過很多個模型之后，誰還會把這這當回事呢。
然后不緊不慢地打開了慢A給的文件，差點沒吐血。
這些變量咋還被再次處理了，給的變量都被分段好了，還合并分組干什么，不知道xgb是二叉樹嘛。
怎么入模了這么多變量。
模型文件一解析，又發現這樹怎么長這樣，這xgb參數也太扯淡了。
快B大叫一聲不好，一個電話打給了慢A，慢A說有些變量分組人數太少就合并了，參數是網格搜索找出來的。
快B很吐血，這意味著，要多一層特征處理作業，這一步很容易出錯。另外，模型打分作業耗時久，需監控的變量多。
因為徒增了這些工作，重要但不緊急的模型部署變成了重要又緊急的todo。
但好歹，模型文件給到了快大廠，離線打分總遠遠好于實時打分。
模型終于被部署好了，并經過了一致性校驗。
這個階段快B很暴躁。
五、我說
有件事情特別重要，而很多建模的同學并沒有意識到。
離線打分再把分數推送至線上接口，會比推送特征線上實時計算分數容易地多。
前者，模型復雜度就不太重要，計算作業再耗時也不是什么大問題。
但后者，就注定不能用太多變量，不能讓模型過于復雜，因為推送幾百個特征至線上是很困難的，保證接口響應速度是很吃資源的，驗證分數的一致性也是更不容易的。
這決定了你如何去做特征工程，如何去訓練模型。
所以，最為要緊的事情是，在啟動建模前就必須想清楚最終將如何上線應用。
負責建模的A和B同學，一定要清楚這個流程，即使他們本人還沒有這些經驗，也需要有人告知并提醒他們。
并且保持一定頻率的交流。
如果你們在聯合建模，或者任何建模，確保你有辦法知曉更全的信息。如果沒辦法，我可以盡一點綿力。歡迎交流。
本文由@雷帥 原創發布于人人都是產品經理。未經許可，禁止轉載
題圖來自Unsplash，基于CC0協議
這個建模是C4D 攪拌機那種建模嗎？？？？ 我不是做程序的
太真實了，笑死我了