在机器阅读理解界的ImageNet——SQuAD挑战赛中，排在前几名的算法，都能拿到八十多分的成绩。

可是，为什么我们依然觉得机器不太听/看得懂人话？

科学研究界有句老话说得好，世界上最远的距离，就是从实验环境到工程实际。

这句话是量子位现编的，不过现有的这些阅读理解数据集，的确和现实有一些距离。用DeepMind最近一篇论文里的话来说，它们“不能测试出阅读理解必要的综合方面”。

为了给算法准备一套不那么小儿科的试题，DeepMind今天发布了一个难度更高的阅读理解任务和数据集：NarrativeQA。

更长的文档，更难的问题

DeepMind说，NarrativeQA是第一个基于整本书或整个剧本的大规模问答数据集。

它最大的特点，就是其中大部分问题不能仅靠文档表面的模式匹配和凸显来回答，而是至少要读上几段内容，这几段内容甚至会分布在故事的各个部分。要正确答出问题，算法必须真的理解文档所讲的故事。

其实，测试机器阅读理解能力的数据集已经有不少。

比如我们在文章开头提到的SQuAD挑战赛就有同名数据集，是斯坦福大学2016年发布的，包含从536个Wikipedia条目中提取的23000个段落，10.8万个人工生成的问题。其他数据集还有以童书为阅读材料的Children’s Book Test (CBT)、BookTest，小学水平的MCTest，新闻构成的CNN/Daily Mail、NewsQA，以及搜出来的文章组成的MS MARCO和SearchQA。

DeepMind研究了这些数据集，发现他们有的规模太小或者不够自然，就算比较自然的数据集，难度也不够，里边大部分问题根据文章中一两句话，就能回答出来。

基于这些数据集存在的问题，他们在设计NarrativeQA时，先确定了几个必需的特质：要有很多问答对，这些问答要基于大量文档或者少量的长文档，问答需要是自然、自由、人工生成的，回答问题需要参考文档中的几处内容或者一长段话。他们还希望数据集的标注者不要用文档中的话来回答问题，而是换个说法，或者要考虑到文档中实体、地点、事件之间较高层次的关系。

最终，他们的NarrativeQA数据集包含1572个故事和46765个问题。

数据集中的故事文档基本是书和电影剧本，书来自古腾堡计划中的电子书，而电影剧本是从网上抓取来的。数量虽少，但是与其他数据集相比，这些文档都非常长，最长的有430061个token（也就是一本几十万字的书），而且有着不错的词汇覆盖面和多样性。

而其中的问答对，是亚马逊众包平台Mechanical Turk上的标注员根据这些书和剧本的维基百科摘要写出来的，每个文档大约对应着30对问答。

NarrativeQA中大部分问题都是“WH-”开头的，也就是“什么、谁、为什么、怎么、哪里、哪个、多少”等等。

而其中的回答，有44.05%来自文档概要，29.57%来自文档本身。

NarrativeQA数据集包含的故事中，书和剧本所占的比例差不多。整个数据集约70%被划分到训练集，7.5%被划分到验证集，22.5%被划分到测试集。

相关论文

The NarrativeQA Reading Comprehension Challenge

作者：
Tomáš Kočiský, Jonathan Schwarz, Phil Blunsom, Chris Dyer, Karl Moritz Hermann, Gábor Melis, Edward Grefenstette

地址：
https://www.arxiv-vanity.com/papers/1712.07040v1/

数据集下载

DeepMind自己公布了一个GitHub地址：
https://github.com/deepmind/narrativeqa

不过，这里只有NarrativeQA中文档的名称、链接、维基百科概要、问题和答案，并没有这些文档的全文，只给出了抓取这些文档所需要的脚本。

纽约大学的NLP专家Kyunghyun Cho表示这不能忍……他说，互联网是动态的，网页总在变，脚本说不定哪天就不管用了。

保险起见，他抓取了数据集中该有的所有文档，上传到了Google Drive。

地址：
https://drive.google.com/file/d/19ol41J8Obu-0bp5eOcaDqtt-dR_syrU-/view

量子位搬了一份到度娘的网盘，在公众号QbitAI对话界面回复“NarrativeQA”提货。