【百度點石（WSDM）】 Retention Rate of Baidu Hao Kan APP Users 小白經驗分享

先說結論

這是我正兒八經參加的第一個資料科學競賽，心路歷程也是十分艱辛，隊友經歷幾次更換，自己也是經常遊走在崩潰的邊緣，同門都說我頭髮又見禿，總之不是很順利的，最後結果不是很理想。用我隊友的話就是100來人的比賽，不拿個top3真的沒用。
菜是原罪。?
這個比賽總結，拖了太久了，自己真的是拖延癌晚期，寫出來對別人實際參考意義不大，只是對我自己的一個總結，想在這個基礎上把程式碼整理一下，爭取下次別這麼丟人了～

百度點石

先來談談百度點石吧，常見的比賽陣地是天池、kaggle、datacastle等等，點石算是比較小眾的吧，含金量不高，參賽人數較少，倒是之前因為他和我交合作了一個比賽有點印象。

再也不想參加點石的比賽了，有問題官方不管不顧，題目不規範，對新手最終要的論壇也存在活躍度幾乎為0的情況，體驗感超差，太不友好了，費心費神。如果你和我一樣還是入門新手的話，建議還是平臺大一些的天池或者kaggle吧，和一些熱愛分享的人一起比賽，進步會很快的～

一次管夠，再也不想參加了。

賽題背景

學計算機還是需要點英文閱讀能力的～
如果你讀著很累，還是選擇有道滑詞翻譯外掛吧～

資料探索

獲取資料

資料呈現的特點是：真實脫敏資料，資料龐大，缺失值很多，原始特徵共21維。
當訓練資料下載下來的時候，我是懵逼的：

1. 原始資料以二進位制檔案儲存，以前沒碰到過。
2. 好不容易將資料切分開以後，發現訓練資料24G，測試資料8G。
   諮詢了大佬以後，我認為解決辦法有三個：選擇spark or 借一臺至少64G記憶體的伺服器 或者選擇將資料拆分開一組一組的跑模型～
   最終，厚著臉皮找同學借到了他們實驗室的伺服器，儘管有64G記憶體，但是還是時刻在崩掉的邊緣啊～

資料

    使用者id
    性別
    年齡
    教育程度
    地域編碼
    是否留存
    安裝渠道
    視訊id
    視訊分類
    視訊tag
    創作者
    上傳時間
    視訊時長
    是否展現
    是否點選
    推薦型別
    視訊播放時長
    行為發生時間戳
    是否評論
    是否點贊
    是否轉發

1. 資料特點
   因為是真實資料，所以缺失值非常多，還存在很多異常資料，比如這個使用者一會是男生一會是女人。
2. 滑窗法（pass）
   一般這樣的問題呢，大多數都是時候滑窗法，對一段時間的資料進行分割，劃分成多個自資料集（如果你還沒了解過滑窗法，請戳這裡），但是雖然此次資料的時間跨度如下

訓練集 10.15-10.31
測試集 10.15-10.31
預測：11.1日（週四的留存率）

但是每個使用者在這段時間內只有一天有資料，所以滑窗法失效。

3. 各個特徵與是否留存的相關性
   這段需要繪圖來檢視，這種常用的小程式碼，我會更新在文末，總結成一個專門的筆記。
   繪圖之後，都差不多，沒有特別相關和特別無關的特徵，這又給我們增加了難度。

資料整理

在最開始的時候我們糾結的點就在於，一個是滑窗法對此題該怎麼應用，另一個就是如何填充這裡大量的缺失資料。
事實證明，年輕人拿到資料就該多自己觀察資料，而不要就想著我該怎麼處理。這兩個問題都是無用的， 因為是線上資料，所以必然有很多缺失值，而且也是合理存在的，同時lightgbm是對缺失值不敏感的，所以還是經驗太少了，在此處耽誤了很多時間。
主要的處理資料步驟：
1. 刪除整份資料都相同的特徵。
2. 規範異常資料。
3. 對資料按照uid和timestamp_of_behavior升序排序。
4. 對必要特徵處理缺失值和異常值，比如性別的異常。將所以的缺失值替換成nan。
5. 時間戳轉化為日期。
6. 連續特徵離散化，離散屬性數字化。
7. 轉化資料型別，降低記憶體使用率。
8. 最後將原始資料整理成一個使用者一條資料的形式。（我覺得我成績不好的原因絕對是這裡出了問題）

我的問題？？？反思自己一下吧～

1. 資料觀察不夠，不夠詳細，也可能是沒有經驗吧，只知道觀察資料，但是忽略了“如何做”。
2. 這塊沒有一步到位的處理好，寫的bug太多，導致到最後的時間內我還在修改這塊的程式碼。
3. 沒有及時將資料儲存，節省程式碼執行時間。我在前面寫過，這次比賽的資料量非常大，執行一次簡簡單單的資料處理，可能就需要個把個小時，所以要隨機應變啊～
4. 變通性太差，一直在糾結，殊不知只有實踐才是檢驗真理的唯一標準，別猶豫，多查多做即可。
5. 前期積累太差，沒有做好常用小函式的筆記，寫的時候翻書，翻別人部落格浪費了很多時間。《利用Python進行資料分析》一定要多翻多看多用，我就是太久不用，非常生疏。

特徵工程

特徵工程的話，我還從user、item、user-item這三方面進行展開的，但是為啥最終效果這麼差，我覺得旁人沒法給我一個解釋，還需要我自己在去讀別人的程式碼，來進行自我反思吧。
我閱讀了幾個大牛開源的思路後整理一個這個，僅供新手使用，大牛勿噴～
特徵工程的特徵從何而來

構建特徵

1. 性別 one-hot；
2. 年齡、學歷 label-encode；
3. 安裝渠道總個數、該安裝渠道下留存得分；
4. 時間戳處理轉化，行為時間戳的星期、天、小時；
5. 最後一條行為資料距離轉天0點之間的時間差，連續兩次觀看視訊之間的時間差；
6. 視訊類別和安裝渠道進行one-hot，視訊tag取200維進行tf-idf向量；
7. 所看視訊個數、視訊類別數、展現、點贊、評論、轉發次數，所有行為總次數；
8. 觀看視訊時長和視訊總時長的比例的最大、最小、平均；
9. 使用者點選視訊中視訊類別個數，使用者展現視訊中視訊類別個數；
10. 使用者前10、20條記錄中show的比例，使用者後10，20條記錄中show的比列；

五個強特

1. 使用者安裝渠道；
2. 使用者APP使用時間；
3. 使用者最後使用APP的行為時間戳的小時；
4. 使用者觀看視訊時間的比例；
5. 使用者觀看視訊的總時長。

反思

在做特徵的時候就註定我是個loser了吧，後期進行程式碼排查的時候我發現我寫的幾個地方就把資料大變樣了，造成了很多問題，雖然後期糾正了，但是還是逃不過命運。在一個地方就是我沒有掌握如何判斷新加特徵是否能提高AUC，我就一味的加特徵加特徵，我覺得十分忙目，不知道如何處理。還有的就是在昨晚特徵之後也是可以把資料儲存成一個新資料的，節省時間，最後一次模型跑了8個多小時，都快哭了。

訓練模型

因為是第一次參加這種比賽，我就選用了對新手最友好的lgb訓練了一個模型，這個比xgb訓練速度會更快一些，效果也差不多。我沒有用網格搜尋來挑選最合適的引數，我覺得這點影響都是微乎其微的可以忽略。在這一階段我最大的收穫就是學習了lgb這種資料科學比賽大殺器，官方文件一生推，你想要的官方文件都有。

模型融合

到訓練模型我的歷程也就結束了，都沒做到模型融合的一步，真的是遺憾。
奉上我之前找到的非常好的博文：
https://blog.csdn.net/WxyangID/article/details/80205075

人生經驗

1. 練習賽和真實比賽絕對不一樣！！！比飛行棋更加緊張刺激～
2. 團隊協作很重要，如果你是新手菜鳥，一定要有隊友，孤軍奮戰真的太累～
3. 找到適合的入坑比賽。儘量選擇預測、分類這種常見場景的，資料集大小要適中，像我這次就是資料25G的資料，跑一次模型幾個小時，要快速迭代才能給我們更多反饋，進行更多優化。
4. 熟能生巧。表格型比賽大同小異，打上一兩次就能積累非常多的經驗，要有自信，也要把一些常見的程式碼積累下來，都是可複用的。
5. 版本控制。無論是你自己還是隊友之間都需要進行版本控制，才能不用浪費一遍又一遍的時間來記住我哪裡做了改動，而且現在github開放私人庫了，我覺得是十分友好的。
6. 海量資料處理時記得降低記憶體使用，優化儲存空間，我就因為對pandas資料處理機制不理解，沒有好好優化，跑崩過一次又一次。
7. 程式碼的耦合性一定要降低啊，一定要降低，我把資料處理、特徵工程、和模型都放在一起，後期好痛苦- -。
8. 學會多讀別人的原始碼，學習思路，學習程式碼優化，這樣才能快速提升。
   良心推薦，一個top solution集合，一個成電的學弟進行總結的。
9. 心態要好，打比賽嘛，肯定是要適當熬夜的，但是別讓自己太暴躁。

第三名的簡短經驗分享

https://developer.baidu.com/forum/topic/show/298191

結語

寫到最後，發現自己並沒有寫太多的乾貨，特別重要的特徵工程都是一筆帶過，因為自己真的菜吧，好多問題還是沒理解，真的很慚愧。