104 Hackathon 推薦系統 覆盤
參與過許多黑客松，有農業、漁業的，但跟自己的專業資料分析差比較遠，比較偏向服務或產品，這次是成熟的機器學習題目－推薦系統，跟打Kaggle很像，但真正參加才發現自己太蔡，感謝隊友carry QQ
1. 輕忽系統的重要性
由於工作時系統是架在IT，前期數據量也不大，根本不用擔心效能，但這次比賽資料量很大，有個資料高達一億，I/O、雲端與本地的設置、系統評估與運行時間，跟一般嚴格限制在內網作業的電信業大不相同，所幸有竣逸、庭瑋的神carry。
Solution：要有基本評估標準，可能是讀取10~30分鐘，網速等等，放棄沉默成本，快速轉換策略，適應不同的環境，如快速prototype，善用本地(既有)資源。
2. 算法的構想到落地過程
Spec的構想到UAT完成是一個循環，就算是DevOps也是有固定的流程，但是我有個壞習慣，就是過於樂觀的規劃，跟夢想有點像，會有想完就成功的錯覺，雖然一開始規劃是全局思考，但卻沒有進行沙盤推演，除了習慣，其二是比賽經驗不足，無法權衡，雖然有些特徵的想法，但對於大量資料，其實還有很多工程的困難需要克服，模型部分幾乎都是靠Pei來cover的。
Solution：(1)WOOP思維
Wish: 贏得比賽
Outcome(最好的結果): 完成模型並得到第一
Obstacle: a. 系統建置 b. 資料清洗 c. 變數處理 d. 模型調整
Plan最好/最壞的情況:
a. 最壞情況：資料還沒進系統，比賽就結束了
b. 最好情況：快速完成系統後，進行EDA，嘗試各種模型並取得佳績，並完成資料視覺化與簡報。
c. 合理規劃：先盡快完成系統建置，再開始進行模型Prototype，確定完成後，回頭進行EDA與模型調整，最終有時間才是簡報與視覺化。
(2)IF… THEN…： 執行意圖的沙推
按照最好的預期，做最壞的準備。
by 知名生涯規劃師古典
a. IF系統在雲端有效能issue
THEN 在本地端也匯入資料，建置相同的分析環境
b. IF 網路可能有問題
THEN 先在本地端建立可離線環境
c. IF 軟體雲端I/O有效能瓶頸
THEN 使用本地檔案
ELSEIF 運作時間還是太久
THEN 在不同環境並行，直接使用程式做Ad-hoc
3. 格局－資源錯置
短期的分析競賽，最基本就是成績，除非到了模型的極限，否則後續的視覺化(Visualization)與簡報，都根本不需要，但是這次其實投了滿多資源在裡面，應該要做的把模型分數衝到最高，目標要聚焦。
相對於商業環境，雖然結果都是最重要的，但技術上比較不要求，反而在解釋性要花更多時間，但比賽就是模型準確一翻兩瞪眼，長跑與衝刺的差別，具體問題，具體分析。
4. 基礎的重要性
盲目策畫與盲動一樣慘，方向錯了，可能繞路，甚至到不了終點，AI Chat Bot有一組答題速度特別快，僅僅是因為把AWS架在Slack附近的國外地點，就展現出一騎絕塵的超高回應速度，從根本上疊加決策的效益，能疊加的關鍵細節必須盤整。
a. 分佈(Distribution)
在推薦場景裡，位置是很重要的因素，頭幾個結果就決定了效果，但主辦單位可用運用類似(stratified sample)分層抽樣，把每個位置的點擊量都調成一樣，導致位置重要性降低，或許可以讓正負樣本的抽樣減少負擔，但也會讓數據出現偏差，雖然我有發現這個蹊蹺，但沒有進一步的去調整。
但推薦系統的第二名超精準預測之神就有發現這個問題，利用抽樣的方式，進一步將樣本數調整為類似帕松分佈( Poisson distribution)的方式，較符合常見的點擊在位置上的分布。
另一部分是針對不熱門的工作將點擊率降低，針對離群值修正，所以是在基礎資料的統計上做調整，以相對簡潔的方式獲得了好的名次，在我心目中是比第一名的作法更簡單而優雅。
5. Notes
a. 序列分析：滿多隊伍運用RNN、LSTM針對搜尋結果做了序列的向量， 我們的model， Pei也利用了word2vec做了類似的分析，概念類似買了甚麼東西後會買甚麼，第一名也用了這個方式，可能也是他們能取得佳績，並與第二有不小的差距
b. Learning to Rank: 學習排序有些基本的類型，pointwise, pairwise, listwise有一個隊伍使用了listwise，紀錄一下
c. 104官方演講時提到推薦系統使用的演算法，因應求職網站與一般推薦場景不同，工作是稀有的，媒合成功後就會消失，使用了穩定配對理論Gale-Shapley Algorithm，感覺跟配貨有點關係，Note一下
最後感謝念念願意花時間跟我參加這個比賽，大概了解我工作的實際情形，以及資料科學這個領域。
