編輯導語：隨着信息化和互聯網的快速發展，數據交易已經成為社會熱點。與信息技術緊密融合的金融行業，伴隨着信息化程度的提高，與互聯網大廠的和合作越來越頻繁。那麼當大廠和銀行聯合建模之後會發生什麼呢？一起來看看吧!
之前寫過一篇：銀行和大廠的一次聯合建模慢銀行在聯合建模之後，藉由快大廠的數據和流量，短暫地解決了獲客問題。
但好景不長，該模型效果衰減地非常厲害，通過率也掉了一個水平，當初建模未料到行業將如此下行，採用的樣本過於優質。現在不得不面對更下沉的客羣。
不管是那次聯合建模過程中，還是之後，慢銀行和快大廠涉事雙方都對那次合作不置好詞。他們唯一達成了的共識是，聯合建模太麻煩了。但合作是上層戰略，總是要維持和推進的。
於是，快大廠提議，可以輸出我們內部的數據標籤作為標準產品給你們，這些數據不僅風險區分效果好還很穩定。慢銀行雖然明知其套路，但迫於形勢惡劣，還是覺得可以一試。
畢竟，標準產品省去了聯合建模的麻煩，同時也避免了建模樣本過少導致過早失效的問題。於是，原班人馬把上個項目成立的微信羣，“快與慢聯合建模羣”，改成了，“快與慢數據產品合作羣”。
只是聯合建模時快大廠的負責人，已經離職了。據説是因為當時合作太費勁，受不了了，也據説是在快大廠已經待了兩年多了，該走了。（不知道我為什麼特意想黑一下）曾經發生的故事，或多或少，或變或沒變，地再次發生了。
一、立項會議有了之前的經驗，這次兩方都沒怎麼寒暄，就直奔主題了。慢銀行因為對上次合作不滿意，這次主動提了很多要求。你們那什麼什麼交易數據要加工這些字段，提供給我們。
此處可以代入，天貓淘寶京東拼多多等電商交易數據，也可以代入花唄借唄白條金條等支付借貸數據，等等。你們那會員等級數據要提供給我們。
此處可以代入支付寶會員等級、芝麻信用分，京東京享值、小白守約分，微信支付分等。另外，你們的賬齡數據要給我們。還有，你們提供什麼模型評分給我們？是你們的A卡、B卡還是什麼模型的評分？你們怎麼建的模型？內部怎麼用的？……快大廠，沒有話説。
項目是VP層級的，老闆發了死命令，要服務好對方。慢銀行指定了一個同學，當然還是那個慢A，快大廠也指定了個同學，也還是那個快B。此外，雙方增加了策略同學的參與，分別是慢C、快D。慢A和快B仇人見面分外眼紅，但工資讓他們學會了安分和合作。
二、數據準備關於標準產品，慢銀行體現了其專業性，提出的數據維度非常豐富，把快大廠的數據資產挖的是乾乾淨淨，多一個不能多，少一個不能少。
那是因為慢C同學參考了芝麻信用變量的維度，依葫蘆畫瓢，再排除了快大廠相對比較缺失的信息，提出了這麼一個變量清單。芝麻信用的65個變量列表如下，其中標紅的是8個核心變量。
覆蓋信用歷史、行為偏好、履約能力、身份特質、人脈關係五個維度，正所謂“五大護法齊上陣，信用風險忙下場”。關於芝麻信用，我寫過揭秘：芝麻信用是怎麼做的。
明顯可以看到，阿里系在人脈關係上是多麼的弱勢，該部分信息主要都在騰訊和運營商手上。
不僅如此，慢C還提出了這些變量分段的要求，例如天數類的、金額類的、次數類的分段區間怎麼設等等。只是最終分段還是要結合快大廠大盤數據分佈情況再做定奪。
快大廠的策略同學快D秉着“最大化達成合作目的，最小化合作效果”的宗旨，剔除了其中一些過於敏感的數據，並進一步限制了變量分段數量。需求最終提給了模型同學快B去加工，這處加工費了快B半條老命。
不僅四處問人這些字段的取數邏輯，好不容易加工好還總有變量分佈不符合預期。過程中，快D找出了無數個問題點，以至於快B天天吐槽快D事兒多。百年之後，快B終於改好了這些變量加工的代碼，對着大盤跑批了近兩年的數據，並校驗了分佈穩定合理。
同步慢銀行時，還被慢C同學質疑了-1和0取值上的不合理。
三、策略制定慢銀行要了快大廠的大盤數據分佈情況後，從行內提取了10w樣本，讓快大廠的模型同學快B回溯。隨後，慢銀行的模型同學慢A，對這些字段進行了IV和KS的計算，效果差強人意。沒有人驚喜，也沒有人發怒。
於是，慢A做了非常詳細的數據分析，回匹了行內的客羣標籤，計算了變量每組下的風險水平。然後，交給了慢C制定策略。慢C操起了所謂的經驗之錘，寫了一堆case when，得到了最終的風險評級，繼而測算了各類人羣結構上的佔比、通過率、風險、額度水平等等。
寫了一些結論，做了一個文檔，獲得了行內認可。快D苦求了半天，以方便更好的監控服務效果為由，要到了這個毫無營養的文檔。如獲至寶地同步了快B和廠裏的老闆。
四、數據部署標準產品的部署顯然跟慢銀行都沒關係，但即便如此，誰説又能小瞧呢？快B和快D首先討論了，客羣要包括哪些。大盤用户數量巨大，全都算人數太多了，很多人也沒有有效數據。
於是按活躍度選定了一個客羣。然後討論了接口服務的困難。要輸出的字段有大幾十個，這些字段都是要推送線上的，跟模型分的一兩個字段部署完全不一樣。導致這個部署作業既吃資源，又耗時長。
於是一致決定月更。但日後隨着大盤活躍用户增加，該作業的執行和推數效率仍可能存在風險點。最後再製定了數據監控的方案。
快B同學每月跑數完成後要校驗所有字段的分佈，並郵件正式通知相關方。再第一時間推送線上接口，同時確保推送服務的有效性。對待這些需求，快B只是覺得他們吵鬧。
五、我説這次合作，慢A和快B兩位模型同學都淪為了工具，非常弱勢，“人為刀俎，我為魚肉”。沒辦法，他們是“牛逼哄哄”的算法工程師，數據產品又不是模型，跟他們有什麼關係。
算法工程師往往不等於風控同學。在數據產品合作這個項目過程中，他們被策略同學教做人了。我相信這對他們來説是一件好事。算法工程師不應該只會算法。
如果你只會對確定的樣本、確定的特徵、確定的標籤，建一個所謂的大數據模型，不管這個模型是LR，還是XGB，還是神經網絡，還是圖算法，其實都是不夠的。但，這在國內往往是吃得香的。
有一類很難的面試考點叫system design，國外大廠很喜歡考，國內也有很多考的了。風控模型本應該也是一樣，如何對遇到的問題設計合理的解決方案，比模型本身重要的多得多。
但，還是有很多算法層面的面試仍然是XGB參數、AUC、KS等。考察的永遠都是候選人有沒有在認真準備面試。“存在即合理”，我理解不了這句話的解析意，我就是想用其表面意。
#專欄作家#雷帥，微信公眾號：雷帥快與慢，人人都是產品經理專欄作家。風控算法工程師，懂點風控、懂點業務、懂點人生。始終相信經驗讓工作更簡單，繼而發現風控讓人生更自由。
本文原創發佈於人人都是產品經理。未經許可，禁止轉載。
題圖來自 Unsplash，基於CC0協議