編輯導語：隨著信息化和互聯(lián)網的快速發(fā)展，數(shù)據(jù)交易已經成為社會熱點。與信息技術緊密融合的金融行業(yè)，伴隨著信息化程度的提高，與互聯(lián)網大廠的和合作越來越頻繁。那么當大廠和銀行聯(lián)合建模之后會發(fā)生什么呢？一起來看看吧!

之前寫過一篇：銀行和大廠的一次聯(lián)合建模慢銀行在聯(lián)合建模之后，借由快大廠的數(shù)據(jù)和流量，短暫地解決了獲客問題。

但好景不長，該模型效果衰減地非常厲害，通過率也掉了一個水平，當初建模未料到行業(yè)將如此下行，采用的樣本過于優(yōu)質?，F(xiàn)在不得不面對更下沉的客群。

不管是那次聯(lián)合建模過程中，還是之后，慢銀行和快大廠涉事雙方都對那次合作不置好詞。他們唯一達成了的共識是，聯(lián)合建模太麻煩了。但合作是上層戰(zhàn)略，總是要維持和推進的。

于是，快大廠提議，可以輸出我們內部的數(shù)據(jù)標簽作為標準產品給你們，這些數(shù)據(jù)不僅風險區(qū)分效果好還很穩(wěn)定。慢銀行雖然明知其套路，但迫于形勢惡劣，還是覺得可以一試。

畢竟，標準產品省去了聯(lián)合建模的麻煩，同時也避免了建模樣本過少導致過早失效的問題。于是，原班人馬把上個項目成立的微信群，“快與慢聯(lián)合建模群”，改成了，“快與慢數(shù)據(jù)產品合作群”。

只是聯(lián)合建模時快大廠的負責人，已經離職了。據(jù)說是因為當時合作太費勁，受不了了，也據(jù)說是在快大廠已經待了兩年多了，該走了。（不知道我為什么特意想黑一下）曾經發(fā)生的故事，或多或少，或變或沒變，地再次發(fā)生了。

一、立項會議

有了之前的經驗，這次兩方都沒怎么寒暄，就直奔主題了。慢銀行因為對上次合作不滿意，這次主動提了很多要求。你們那什么什么交易數(shù)據(jù)要加工這些字段，提供給我們。

此處可以代入，天貓?zhí)詫毦〇|拼多多等電商交易數(shù)據(jù)，也可以代入花唄借唄白條金條等支付借貸數(shù)據(jù)，等等。你們那會員等級數(shù)據(jù)要提供給我們。

此處可以代入支付寶會員等級、芝麻信用分，京東京享值、小白守約分，微信支付分等。另外，你們的賬齡數(shù)據(jù)要給我們。還有，你們提供什么模型評分給我們？是你們的A卡、B卡還是什么模型的評分？你們怎么建的模型？內部怎么用的？……快大廠，沒有話說。

項目是VP層級的，老板發(fā)了死命令，要服務好對方。慢銀行指定了一個同學，當然還是那個慢A，快大廠也指定了個同學，也還是那個快B。此外，雙方增加了策略同學的參與，分別是慢C、快D。慢A和快B仇人見面分外眼紅，但工資讓他們學會了安分和合作。

二、數(shù)據(jù)準備

關于標準產品，慢銀行體現(xiàn)了其專業(yè)性，提出的數(shù)據(jù)維度非常豐富，把快大廠的數(shù)據(jù)資產挖的是干干凈凈，多一個不能多，少一個不能少。

那是因為慢C同學參考了芝麻信用變量的維度，依葫蘆畫瓢，再排除了快大廠相對比較缺失的信息，提出了這么一個變量清單。芝麻信用的65個變量列表如下，其中標紅的是8個核心變量。

覆蓋信用歷史、行為偏好、履約能力、身份特質、人脈關系五個維度，正所謂“五大護法齊上陣，信用風險忙下場”。關于芝麻信用，我寫過揭秘：芝麻信用是怎么做的。

明顯可以看到，阿里系在人脈關系上是多么的弱勢，該部分信息主要都在騰訊和運營商手上。

不僅如此，慢C還提出了這些變量分段的要求，例如天數(shù)類的、金額類的、次數(shù)類的分段區(qū)間怎么設等等。只是最終分段還是要結合快大廠大盤數(shù)據(jù)分布情況再做定奪。

快大廠的策略同學快D秉著“最大化達成合作目的，最小化合作效果”的宗旨，剔除了其中一些過于敏感的數(shù)據(jù)，并進一步限制了變量分段數(shù)量。需求最終提給了模型同學快B去加工，這處加工費了快B半條老命。

不僅四處問人這些字段的取數(shù)邏輯，好不容易加工好還總有變量分布不符合預期。過程中，快D找出了無數(shù)個問題點，以至于快B天天吐槽快D事兒多。百年之后，快B終于改好了這些變量加工的代碼，對著大盤跑批了近兩年的數(shù)據(jù)，并校驗了分布穩(wěn)定合理。

同步慢銀行時，還被慢C同學質疑了-1和0取值上的不合理。

三、策略制定

慢銀行要了快大廠的大盤數(shù)據(jù)分布情況后，從行內提取了10w樣本，讓快大廠的模型同學快B回溯。隨后，慢銀行的模型同學慢A，對這些字段進行了IV和KS的計算，效果差強人意。沒有人驚喜，也沒有人發(fā)怒。

于是，慢A做了非常詳細的數(shù)據(jù)分析，回匹了行內的客群標簽，計算了變量每組下的風險水平。然后，交給了慢C制定策略。慢C操起了所謂的經驗之錘，寫了一堆case when，得到了最終的風險評級，繼而測算了各類人群結構上的占比、通過率、風險、額度水平等等。

寫了一些結論，做了一個文檔，獲得了行內認可?？霥苦求了半天，以方便更好的監(jiān)控服務效果為由，要到了這個毫無營養(yǎng)的文檔。如獲至寶地同步了快B和廠里的老板。

四、數(shù)據(jù)部署

標準產品的部署顯然跟慢銀行都沒關系，但即便如此，誰說又能小瞧呢？快B和快D首先討論了，客群要包括哪些。大盤用戶數(shù)量巨大，全都算人數(shù)太多了，很多人也沒有有效數(shù)據(jù)。

于是按活躍度選定了一個客群。然后討論了接口服務的困難。要輸出的字段有大幾十個，這些字段都是要推送線上的，跟模型分的一兩個字段部署完全不一樣。導致這個部署作業(yè)既吃資源，又耗時長。

于是一致決定月更。但日后隨著大盤活躍用戶增加，該作業(yè)的執(zhí)行和推數(shù)效率仍可能存在風險點。最后再制定了數(shù)據(jù)監(jiān)控的方案。

快B同學每月跑數(shù)完成后要校驗所有字段的分布，并郵件正式通知相關方。再第一時間推送線上接口，同時確保推送服務的有效性。對待這些需求，快B只是覺得他們吵鬧。

四、我說

這次合作，慢A和快B兩位模型同學都淪為了工具，非常弱勢，“人為刀俎，我為魚肉”。沒辦法，他們是“牛逼哄哄”的算法工程師，數(shù)據(jù)產品又不是模型，跟他們有什么關系。

算法工程師往往不等于風控同學。在數(shù)據(jù)產品合作這個項目過程中，他們被策略同學教做人了。我相信這對他們來說是一件好事。算法工程師不應該只會算法。

如果你只會對確定的樣本、確定的特征、確定的標簽，建一個所謂的大數(shù)據(jù)模型，不管這個模型是LR，還是XGB，還是神經網絡，還是圖算法，其實都是不夠的。但，這在國內往往是吃得香的。

有一類很難的面試考點叫system design，國外大廠很喜歡考，國內也有很多考的了。風控模型本應該也是一樣，如何對遇到的問題設計合理的解決方案，比模型本身重要的多得多。

但，還是有很多算法層面的面試仍然是XGB參數(shù)、AUC、KS等?？疾斓挠肋h都是候選人有沒有在認真準備面試?！按嬖诩春侠怼保依斫獠涣诉@句話的解析意，我就是想用其表面意。

#專欄作家#

雷帥，微信公眾號：雷帥快與慢，人人都是產品經理專欄作家。風控算法工程師，懂點風控、懂點業(yè)務、懂點人生。始終相信經驗讓工作更簡單，繼而發(fā)現(xiàn)風控讓人生更自由。

本文原創(chuàng)發(fā)布于人人都是產品經理。未經許可，禁止轉載。

題圖來自 Unsplash，基于CC0協(xié)議