2023 Machine Learning Intern 作業解析
這次的 Engineering 實習計畫中，很開心有數百位同學參與我們的面試流程。感謝大家用心地完成作業，我們收到了許多同學有趣的做法，同時不少同學也好奇團隊的工程師們會如何撰寫這份作業，因此，我們彙整成了建議做法給大家參考：
2023 Machine Learning Homework
給予文章發佈後前 6 小時的狀態，預測 24 小時後的愛心數
About Problem Definition
在這次的作業中，有不少同學都把它定義成一個 Regression 問題：預測發文 24hr 後有多少愛心，但是透過觀察「24hr 後的愛心數一定大於 6hr 時的愛心數」，也可以改成預測殘差，或者對預測做後處理，可以得到一點點 marginal improvement。
About Objective & Metrics
建議同學可以嘗試的做法：
- MAPE：是最佳的選擇，但需要注意 target（分母）很小的情況，有些人會對這些資料給予比較高的權重
- 因為 label 的分佈很長尾，可以嘗試做 sqrt 或者 log-transform，有一些人從中獲得 improvement
較不建議同學實作的做法：
- MSE：跟最終 evaluation 有差距，所以會得不到好的結果。
About Dataset Construction
- 許多同學好奇爬額外的資料是否能得到更好的結果，這點我們沒有絕對的答案，然而，此次幾份出色的作業中，皆無爬額外的資料，不過在 Dataset Construction 或許可以嘗試看看幾個做法：
- 由於資料集相對乾淨，可以選擇把 public test dataset 作為 eval set 後得到 hyper-parameter 後再放進去一起訓練
- 使用 cross-validation 讓 evaluation 的結果更 robust
About Feature Engineering
團隊整理了一些同學嘗試的 feature engineering 方法，因為不一定每個 feature 都適合選擇的模型，最後可以透過實驗或 Tree-based model 做 feature selection 來決定最終使用的 feature。
created_at
- 取出小時
- 取出 Weekday
- 轉換成 (cos, sin) 兩維度的 feature 試圖保留連續性
like_count
- 多數人做了分析後，都注意到
like_count是對預測最有幫助的 feature，所以進行了不少 Feature engineering - 計算
like_count每個小時間的差值 - 計算
like_count在每個小時的成長 % 數 - 計算
like_count在這六小時的成長速度
comment_count
- 雖然不像
like_count那樣如此有幫助，但可以 applied 相同的 feature engineering
title
- 相對困難做處理，但有部份高分的作業從中得到成效的提升
- 主要分成 hand-craft 及 embedding 的作法
- 偏統計值的 feature engineering，例如字數、是否包含某些關鍵字
- embedding: pretrained-model (e.g. BERT), 自己訓練的模型
- NER-related token
forum_id
- 統計看板發文數、挑出熱門看板做 binary feature
- 因為與 forum_stats 有對應關係，所以不會直接拿來使用
author_id: 不少同學發現作者重複率不高，是此題上無幫助的 feature
forum_stats: 是一個統計看板熱度的數字，可以對他做 normalization 讓數值更穩定
About Modeling
- 最佳的模型幾乎都是 LSTM，因為相對適合這種 Sequential 的未來預測問題
- MLP 也是得到最高分的模型之一，但因為資料集沒那麼大，需要特別注意控制 parameter size
- XGBoost 或 Tree-based 的模型也表現得很好，相對容易訓練，但會遇到不好處理 categorical 或 text feature 的問題
- 除此之外，結合多個模型進行 ensemble 也是高分的關鍵之一
我們的一些觀點
團隊會建議從最簡單的模型逐步加深模型的複雜度，去了解這個任務的資料量能夠支持到多複雜的模型。如果可以先做一些 baseline 掌握可能的成效落點，那就更好了！有些同學會做 Ablation study 以了解每個選擇帶來的影響，也是一個很不錯的嘗試！
如何使用 text embedding 是一個挑戰，但在幾份結果優秀的作業中，並非都有使用 text embedding。實務上我們也覺得不一定需要 text embedding，應該要從實驗中選擇最好的做法
- 我們更在意你的思考方式，如：你認為 text embedding 有沒有幫助？而原因又是什麼呢？有幾位同學在作業中呈現了對應的分析資料佐證，這也是一個令我們印象深刻的做法。
- 需要注意 embedding 帶來的高維度 feature，直接 concat 其他 feature 可能會產生不良的影響
讓我們印象深刻的作業通常有做完整的 EDA，這也符合我們在實務上的經驗：先了解資料再進行 modeling
這次許多作業都相當優秀，高分作業的 Public test set MAPE 約落在 0.29 ~ 0.30，Private test set MAPE 則是 0.30 ~ 0.32
About Programming
由於我們期待實習期間的開發成果能夠進入 production，所以程式碼的品質也是我們此次的評分要點之一
如果程式碼是這樣做，那就太好了：
- 符合 PEP8
- 良好的 module 切分幫助閱讀
我們建議同學們可以避免：
- 使用過多 Jupyter Notebook 可能會讓我們無法評價 code quality。在分析的時候使用 Jupyter Notebook 可以幫助我們快速的試錯，但在主程式（e.g. train.py/predict.py）等檔案則需要注意維護性
About Report
我們希望透過報告讓團隊更了解同學的作業內容及思考方式，因此整體報告呈現的方式及說明也相當重要。一個好的報告包括以下的要素：
- Top-down 介紹自己的作法，讓讀者能夠有大致的輪廓，而不是照順序的把嘗試過程一一說明，也不應該太快深入細節
- 良好的切分 section，每個 section 都有想要傳達的主旨
- 利用圖表來呈現實驗結果，尤其是需要比較的數據
- 對於每個變因 (e.g. feature selection, model architecture, objective selection) 都能夠獨立出來闡述為何這樣做並用數據輔助說明
Acknowledgement
感謝大家願意投注心力完成這份作業，我們在看作業的時候都覺得團隊最終只能招募一位 Intern 實在是太可惜了，各式各樣有趣的想法、作法也讓我們學習不少，最後，還是希望這份作業能夠讓大家有所收穫，如果有任何問題，都歡迎到 Dcard Tech Studio 和我們一起交流，期待未來有機會再一起聊聊或是合作！
