知乎联合中国信息检索学术会议，发起用户行为预测数据比赛！本次比赛提供了 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 的交流群里。

▽ 点击 | 阅读原文 | 立刻参赛