參加了 2018 年 104 主辦的黑客松比賽，項目是推薦系統。這篇主要內容為推薦系統項目的比賽概述、評分機制、閃電秀摘要，以及個人賽後反省，不涉及比賽實作內容。
比賽概述
這次推薦系統的題目，主要是針對使用者在 104 網站搜尋工作的內容，返回最佳排序的工作清單，也就是使用者愈可能點擊的工作要排在愈前面。在 testing data 上有一個欄位包含了 20 個工作代號，把這 20 個工作排序好上傳就能得分。
原本預想會有但資料集沒有的兩個欄位為 User ID 跟 Query ID，沒有前者就無法辨識出不同人，也就無法去做不同人的偏好特徵；沒有後者就比較無法直接辨識出哪幾個結果是出於同一次的搜尋，不過拐個彎大概還是能辨識出來。更詳細的說明還有資料集都在 104 Github 上。
評分方式 NDCG
這次的評分標準主要是根據 NDCG，花了一些時間研究，但很難找到講人話版本的說明。首先在知乎看到了這張圖覺得有趣：
裡面說：「NDCG 在序列前 20–30 项以后就基本和 Precision 相似了，所以在算法中一般应用 NDCG 时都是截取最前面一部分进行计算，这也是它的优势。」、「对排序靠前的10项左右特别敏感。实际情况下，前10多项的排序错误会使NDCG显著降低，使我们能更好地评价该排序结果的价值。」也難怪 104 的題目只要求參賽者預測 20 個工作的排序。
最後對 NDCG 有點感覺是看了 WIKI，似乎得先理解 CG（Cumulative Gain），再理解 DCG（Discounted Cumulative Gain），接下來才是 NDCG（Normalized Discounted Cumulative Gain）。WIKI 裡面的例子是這樣的，假設今天經由搜尋返回了 6 篇文章：
D1, D2, D3, D4, D5, D6接著我們根據文章跟搜尋的相關程度，或是使用者實際點擊的次數，為文章們標上 0–3 的分數（relevance score），3 是最好，0 是最不好：
3, 2, 3, 0, 1, 2這時候的 CG 為：
3 + 2 + 3 + 0 + 1 + 2 = 11但我們都知道在搜尋返回結果時，會希望分數愈高的文章能夠排在愈前面，而 CG 並無排序上的差異，任兩篇文章的順序對調都對 CG 值沒有影響。因此，為了把排序納入分數的考量，需要根據文章的順序給一些 discount，這時候就是 DCG 出場的時候了。根據剛才的返回結果，DCG 的算法是這樣的：
其中 i 為排序位置，rel 為剛才說的分數（relevance score），DCG 會把這些分數做加總，因此這個排序的 DCG 為：
3 + 1.262 + 1.5 + 0 + 0.387 + 0.712 = 6.861這樣的計算方式下，任一文章的順序調動都會導致分數的不同。而 NDCG 是將 DCG normalize 後的結果，計算方式是先計算出最完美排序的 DCG 分數（Ideal DCG）後，將目前的 DCG 分數除以 IDCG，取得一個 0–1 的分數，就是 NDCG。
閃電秀
比賽過程中穿插了一點短講，其中對最後一場印象特別深刻，講者是 104 的數據部門主管張閔隆。覺得內容相當不錯，說明得很清楚，而且深淺拿捏得宜，舉例用了很多阿宅梗超可愛的。他說一開始 104 要做優化排序時，先採用了雙邊匹配理論，也就是把使用者最想要的工作清單先排出來，這樣確實讓使用者應徵的次數大幅上升，但卻發現了一個嚴重的問題：媒合的機率大幅下降。也就是說的確返回的內容都是使用者最想應徵的工作，但卻不是他們真的會上的工作。
為了改善這個問題，後來演算法調成將使用者比較可能會上的工作往前排，結果導致了使用者的應徵次數下降，但媒合機率並沒有上升。於是最後加入了一個心理學的概念「啦啦隊效應」：有些人個別來看，也許並不會被認為長相特別出色，但當他跟幾個長得不錯的人站在一起，旁觀者一眼望去會覺得這些人的長相都是不錯的。基於這個想法，將演算法調成在使用者比較有可能會上的工作中，穿插一些他們會想要應徵的工作，讓使用者對於搜尋的結果是滿意的。
最後他分享了在 104 做資料分析的結論：「要主動，主動的人通常會得到比較好的結果，無論在工作上或感情上。」在看到某個想要卻好像能力不及的工作內容時，無論如何應徵就對了，通常被動地等工作找上門的人，不會得到比較好的結果。
套用今天 ChatBot 項目比賽的賽制，覺得被動的人面臨的好像是「是非題」，對於眼前的選項判斷 O 或 X，而且選項通常不會同時出現，所以有 2 的 N 次方個選擇的機率不高。而對於主動的人來說，面臨的是「選擇題」或者是「填空題」，選項更多、可能性更高，臉皮厚一點、心臟強一點，也就沒事了。
賽後反省
比賽完主要有兩個感想：第一個是在遇到任何題目前，要先做足功課，了解其他人的做法，不要以既有經驗假定要怎麼處理題目；第二個是在捲起袖子動手處理資料前，頭腦要想清楚後再開始做。
這兩點都是老生常談的基本原則，但在各種限制下會變得困難。由於之前在忙別的事情，導致活動前一個禮拜才開始著手，本身也沒有推薦系統的實際經驗，只有打過一次 Kaggle，所以在時間的限制下就決定直接套用打 Kaggle 的經驗來做。
第二點則是在還沒有太清楚的做法前就開始整理資料，在面對龐大資料的處理感到壓力跟限制時，很容易就放棄更多的可能。這好像是自已的壞習慣，這樣的狀態下只會急著求有不求好，但事後回想起來，有一些屬性蠻基本的，應該是有能力在那樣的狀態下做出來，卻沒有去做。
之前打 Kaggle 的經驗深知特徵才是王道，Feature is the king，模型的參數怎麼去優化都有他的限制在，但在最後剩下的時間我卻都在找最佳參數，而不是去想新的特徵。下次要更專注在這邊才行。