編輯導讀：如今，銀行和互聯網大廠的和合作越來越頻繁。其中，一項重要的合作是聯合建模。本文作者根據自己的一次風險聯合建模的經歷，從中總結出一些問題，希望對你有幫助。

最近雷帥慢銀行著實愁壞了，行內消費信貸業務新增客戶越來越少，活躍度也越來越低了。疫情長期結束不了，消費下滑經濟下行，監管持續趨嚴，資產規模和質量都開始面臨很大的增長壓力。

雷帥慢銀行尋思，這么下去不是辦法，形勢再差，也要人為，得主動出擊去找優質資產。

怎么找，流量和質量都掌控在互聯網大廠手上。

于是，找到了雷帥快大廠，你把優質用戶給我，我們來做款產品，一起分潤。

互聯網公司都是在做流量變現，雷帥快大廠就爽快同意了。

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協議