知乎聯合中國信息檢索學術會議，發起用戶行為預測數據比賽！本次比賽提供了 700 萬名用戶的 2400 萬條閱讀、搜索、回答、提問、感謝、點贊等行為的數據，要求預測他們感興趣的文章。前 10 名的隊伍將獲得總額 10 萬的獎金。之前因為測試集較大，為了鼓勵更多的創新算法，組委會特別縮小了測試集。目前離初賽結束還有一定時間，只要合理利用一些基線模型，仍然很有機會進入前 20 名，進入復賽。

▲ 您可以掃描二維碼或訪問以下鏈接參加比賽：

https://biendata.com/competition/CCIR2018/?

背景簡介

近年來，隨著互聯網產業的發展，時刻有海量的信息產生，也產生了信息過載等問題。如何在這些信息中幫助用戶找到符合其需求的信息是個重要的課題，而個性化推薦系統被視為解決這個問題的一個重要途徑，同時也是當前學術研究的熱點。目前在工業界，在購物、影音、閱讀、社交等許多場景下，個性化推薦技術都在發揮著越來越重要的作用。?

因此，由中國信息檢索學術會議（CCIR）主辦，清華大學計算機系信息檢索課題組（THUIR）、知乎信息流與個性化推薦產品技術團隊（Zhihu-Feeds）聯合承辦，舉辦本次個性化推薦評測。本次評測任務的主題是“移動環境下知識分享平臺上的內容推薦”。評測任務的數據來自知乎移動端的信息流推薦數據，包括用戶和內容的信息。

除了整體推薦的效果之外，本次評測希望參賽選手對“冷啟動”問題更加關注，即如何對新加入的、行為較少且用戶標簽及資料等信息不是非常完善用戶進行推薦。這些用戶的歷史交互記錄較少，資料并不是非常完善，一些傳統算法，例如協同過濾等，無法直接應用在冷啟動用戶身上。如何對這些用戶推薦合適的內容，一直是個性化推薦領域的一個重要問題，對推薦質量的提高有重要意義。

另外，本次評測任務還創新性地借助知乎公司的實際應用提供在線評測平臺。對于推薦類任務來說，傳統的離線評測方式中評測效果常常受到數據的制約。例如，對于未在線上召回的優質推薦結果，在離線評測中無法獲得用戶歷史交互，從而使得離線測試評分不好，因此離線測試結果往往無法準確反映實際在線測試效果。

因此，在這次比賽的在線測試階段，參賽隊伍提供的推薦結果將會被按照一定的投放量和投放規則投放到真實用戶的信息流中，并收集用戶對這些推薦結果的反饋作為評估指標。在線評測將有助于更加科學地驗證和比較不同模型的效果。

任務描述

本次比賽的任務為：給定一系列內容條目和用戶，目標是將合適的內容推薦給相應的用戶，希望被推薦用戶對該內容感興趣，反映在交互上表現為點擊、收藏等行為。

數據集

本數據集是 CCIR 2018 推薦算法比賽賽題所使用的數據。數據集中包括以下信息：?

• 用戶信息

• 內容信息

• 用戶與內容的歷史交互?

本任務的目的是，從一個約 6w 條的候選集合中產生推薦給用戶的內容列表。數據集中的數據包括如下幾個文件：

?

flag

flag?決定測試集中參與評測的行數，1?對應的測試集條目參與評分，0?對應的測試集條數不參與評分。

?

training_set.txt

訓練樣本集合。一共有 8 列，列與列之間以 \t 分割。樣本展示了用戶在閱讀每條文章之前的一段時間發生的用戶歷史交互行為。訓練樣本集合中一共包含大約 2400w 條數據，來自約 700w 不同的用戶。每列的含義為：

- 用戶 ID

- 在閱讀該條樣本中的文章之前，用戶與其他的文章（問題或者回答）的交互數；

- 在閱讀該條樣本中的文章之前，用戶與其他的文章（問題或者回答）的交互；可能有 0 條或多條，以半角逗號分割；每條的格式為：

• DocType DocID|文章展示時間|文章閱讀時間

• DocType 取值為 Q（問題）或者 A（回答）

• DocID 為壓縮的數字表示；為節省空間，沒有使用 32 位字符串作為 DocID，而是使用了一個較小的數字；數字與實際?DocID 的對應關系可以在 answer_id.dict 或者question_id.dict 中找到

• 文章展示時間，以秒為單位

• 文章閱讀時間，以秒為單位；如果這篇文章展示給用戶但用戶并沒有點擊閱讀，則取值為 0

- 在閱讀該條樣本中的文章之前，用戶的搜索行為數；

- 在閱讀該條樣本中的文章之前，用戶的搜索行為；可能有 0 條或多條，以半角逗號分割；每條的格式為：

• 搜索詞|搜索時間

• 搜索時間，以秒為單位

- 閱讀樣本中的文章的時間，以毫秒為單位；

- 文章的類型，取值為 Q（問題）或者 A（回答）；在本問題的推薦場景下，都為 A；

- 文章的 ID。

?

answer_infos.txt

在訓練集中出現的所有的回答信息，無論該回答出現在用戶的交互歷史中，還是出現在要預測的目標中。列與列之間通過 \t 分割。一共 130 多萬個答案信息，各列的信息如下：

- 答案 ID

- 對應的問題 ID

- 是否匿名回答；如果是，則作者信息為 default 值；

- 是否被標記為優質答案

- 是否被編輯推薦

- 創建時間，unix 時間戳，單位為 ms

- 是否有圖

- 是否包含視頻

- 答案被感謝的次數

- 答案被贊同的次數

- 答案的評論數

- 答案被收藏的次數

- 答案被反對的次數

- 答案被舉報的次數

- 答案收到的「沒有幫助」的次數

- 答案的文本信息

- 答案綁定的話題 ID 列表，以半角逗號分割

其中，部分答案可能已經被刪除或者被關閉，為防止用戶的隱私泄露，這部分內容除答案 ID 外，其余都以默認值填充。

?

question_info.txt

在訓練集和測試集中出現的所有的問題信息，包括答案對應的問題信息。在訓練集中一共包含 47 萬多個問題信息。其中有部分在訓練集的歷史交互中出現的問題可能已經被刪除或者關閉，這些問題的詳細信息不回出現在 question_info 中。列與列之間以 \t 分割。各列的信息如下：

- 問題 id

- 問題創建時間

- 問題一共有多少答案

- 問題有多少人關注

- 問題下有多少邀請

- 問題收到的評論數

- 問題的 title

- 問題綁定的話題 ID 列表，以半角逗號分割

?

question_id.dict 和 answer_id.dict

由于交互歷史中的內容 ID 較長，在文本格式下占用空間非常大，所以使用短編碼來縮減空間。question_id.dict 和answer_id.dict 都包含兩列，第一列是在 training_samples.txt 和 testing_samples.txt 的交互歷史一列中出現的 id，第二列為對應的真實內容 id。所以，如果要找到一條樣本中，用戶都看了哪些內容，正確的做法是：先從交互歷史中的內容 id，通過 quesiton_id.dict 和 answer_id.dict 找到真正的問題或者答案的 id，然后再從 question_infos.txt 或者 answer_infos.txt 中查找內容的原始信息。

?

user_info.txt

在訓練集和測試集中出現的所有的用戶信息。一共 713w 個用戶。列與列之間以 \t 分割。各列的信息如下：

- 用戶ID

- 用戶注冊時間

- 性別

- 訪問頻率

- 關注用戶數

- 關注話題數

- 關注問題數

- 用戶發表的回答數量

- 用戶提出的問題數

- 用戶發表的評論數

- 該用戶的回答被點贊數

- 該用戶的回答被評論數

- 該用戶回答收到的贊同數量

- 該用戶的回答收到的反對數量

- 注冊類型

- 注冊平臺

- 是否用android

- 是否用iphone

- 是否用ipad

- 是否用pc

- 是否用移動web

- 設備model

- 設備品牌

- 用戶平臺

- 用戶所在省

- 用戶所在市

- 用戶的關注話題 ID 列表，以半角逗號分割

?

author_infos.txt

內容的作者信息。列與列之間以 \t 分割。各列的信息如下：

- 作者 id

- 作者是否優質作者

- 關注該作者的人數

- 作者是否優秀回答者

需要注意的是，作者 id 和用戶 id 不在同一空間。e.g, 如果一個用戶既是作者又是待推薦的讀者，那他在?user_infos.txt 和 author_infos.txt 中的 id 是不同的。

?

topic_infos.txt

話題信息。列與列之間以 \t 分割。各列的信息如下：

- 話題 ID

- 話題 Name

- 話題的描述

?

candidate.txt

候選條目 ID 集合。訓練樣本中，樣本閱讀的文章都來自該集合；在測試集及驗證集上，待推薦給用戶的文章也都應該從這些候選條目中產生。每行有兩列：

- 文章類型。取值為 Q（問題）或者 A（回答）；在本問題的推薦場景下，都為 A；

- 文章 ID。

?

Q & A

* 以下 Q & A 內容由知乎工程團隊根據目前參賽選手提問進行撰寫。

Q：樣本數據是如何產生的？

我們的樣本數據來自知乎 700 萬用戶的瀏覽記錄。當然這些記錄都做了非常嚴格的脫敏處理，避免泄露用戶隱私。樣本從知乎的首頁和搜索產品中產生，分別記錄了用戶在知乎首頁的瀏覽行為、用戶的搜索行為等，同時還有用戶在知乎整站產生的數據，例如關注數據和從整站日志中挖掘出來的用戶興趣等。

?

Q：數據集規模怎么會這么大？

我們此次評測一共提供了 2000w 條樣本數據。在我們自己的經驗中，數據量越大，能夠發揮作用的模型越多，預測能力和泛化能力也就越強。這也是深度學習出現后的趨勢，使用大規模的數據及大量的計算資源，提高模型的復雜度，來獲得更好的效果。

我們線上使用了 DNN 來做推薦，在這個數據量級下，DNN 展示出比協同過濾更好的推薦效果。同時，由于推薦領域 state of theart 的算法中，基于 DNN 的模型越來越多，我們希望在此次競賽中，大家也能利用這些樣本，來檢驗 DNN 在推薦領域的實用性，或者提出更好的算法。

?

Q：我的機器配置不夠，使用不了這么大規模的數據怎么辦？

在比賽過程中我們也會接到這方面的反饋，很多選手提到自己并沒有足夠的計算資源，用個人電腦在這個數據集上跑起來相當吃力。我們認為，并不是所有的方法都需要使用到這么大規模的數據，對于 GBDT、協同過濾、LR、FM 等算法，數據量增大到一定程度后，并不會取得很好的收益；即使是 DNN，我們也希望選手能探索出更加節省計算資源的方法，在計算量和模型效果之間達到平衡，這無論對于學術界還是工業界來講，都是有非常重大的意義的。

經過討論，專委會決定，選手可以根據自己能調用的的計算資源，自行裁剪數據量；在數據量縮小的情況下，如果能夠取得比現有算法（例如上面提到的 FM、協同過濾等）更好的效果，我們也歡迎選手提交數據篩選的方案、可重現結果的代碼及模型、方法說明等，經專委會評估確有創新之處的，我們同樣可以增加一部分線上測試的名額，邀請參加線上測試；同時，這些選手也會受邀參加 9 月底 CCIR 的workshop。

?

Q：在比賽中有沒有什么技巧？

我們不建議大家一上來就使用非常占用資源的方法解題，可能會帶來比較大的不可控性。我們建議在這份數據集上先使用一些簡單有效的方法，例如 CF、FM 等，作為 baseline，在此基礎上再嘗試更好的方法。例如，協同過濾和關聯推薦也能取得一定的效果，這些算法用到的計算資源并不高。另外也可以使用一些數據降維的手段，例如瀏覽和搜索的歷史記錄，在數據集中直接提供了原始文本，大家可以使用一些 word embedding 的方式將數據維度先降下來。此外也可以考察僅使用測試集交互數據來建立模型，等等。

?

Q：比賽中常常發現一些數據上的問題，比如行數/列數和描述不一致等，是什么原因？

這個問題在選手反饋的時候我們也注意到了，經過詢問，這些選手大部分使用的是 windows 系統。數據本身是在類 unix 平臺下生成的，windows 的換行符和制表符與類 unix 系統存在較大的兼容性問題。建議大家也使用 linux/unix/mac 系統來探索這份數據。此外，我們還注意到一些選手使用R/matlab 等語言直接讀取文本數據，這也可能會存在兼容問題，最好使用 Python 語言先規整一下數據格式。

?

更多信息請點擊“閱讀原文”去比賽頁面查看。

關于PaperWeekly

PaperWeekly 是一個推薦、解讀、討論、報道人工智能前沿論文成果的學術平臺。如果你研究或從事 AI 領域，歡迎在公眾號后臺點擊「交流群」，小助手將把你帶入 PaperWeekly 的交流群里。

▽ 點擊 |?閱讀原文?| 立刻參賽

總結

以上是生活随笔為你收集整理的知乎用户行为预测数据比赛，10万奖金等你来Battle！的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。