知乎聯閤中國資訊檢索學術會議，發起使用者行為預測資料比賽！本次比賽提供了 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 的交流群裡。

▽ 點選 | 閱讀原文 | 立刻參賽