论文：HOTPOTQA: A Dataset for Diverse, Explainable Multi-hop Question Answering翻译笔记（多跳问题解答的数据集）

---

论文标题：HOTPOTQA： 用于多样化、可解释的多跳问题解答的数据集

论文链接：https://arxiv.org/abs/1809.09600
arXiv:1809.09600v1 [cs.CL] 25 Sep 2018

摘要

现有的问答（QA）数据集无法训练QA系统进行复杂推理并为答案提供解释。我们引入了HOTPOTQA，这是一个包含113k基于维基百科的问答对的新数据集，具有四个关键特征：(1) 问题需要查找和推理多个支持性文件来回答；(2) 问题多样化，不受任何预设知识库或知识框架的限制；(3) 我们提供句子级别的支持性事实，以便进行推理，让问答系统能够在强监督下解释预测；(4) 我们提供了一种新型的事实比较问题，以测试QA系统提取相关事实和进行必要比较的能力。我们证明了HOTPOTQA对最新的QA系统具有挑战性，而支持的事实使模型能够提高性能并做出可解释的预测。

1 简介

在自然语言上进行推理和推断的能力是智力的重要方面。问答任务（QA）提供了一种可量化且客观的方式来测试智能系统的推理能力。为此，已经提出了一些大型的问答数据集，这激发了在这方面的重要进展。然而，现有的数据集存在局限性，这些局限性阻碍了机器对自然语言进行推理的进一步发展，特别是在测试QA系统进行多跳推理的能力方面，这里系统需要从多个文档中获取信息才能得出答案。

首先，一些数据集主要关注测试在单个段落或文档内推理的能力，或者单跳推理。例如，在SQuAD（Rajpurkar等人，2016）中，问题设计为给定一个单独的段落作为上下文来回答，而且大多数问题实际上可以通过将问题与该段落中的一个句子匹配来回答。因此，在测试系统在更大上下文中进行推理的能力方面存在不足。TriviaQA（Joshi等，2017）和SearchQA（Dunn等，2017）通过使用信息检索收集多个文档来形成给定的问题答案对的上下文，从而创建了一个更具挑战性的环境。尽管如此，大多数问题可以通过匹配问题与一个段落中的几个相邻句子来回答，这是有限制的，因为它不需要更复杂的推理（例如，跨越多个段落）。

其次，针对多步推理的现有数据集，如QAngaroo（Welbl等人，2018）和COMPLEXWEBQUESTIONS（Talmor和Be-rant，2018），是通过使用现有的知识库（KBs）构建的。因此，这些数据集受到它们使用的KBs架构的限制，从而在问题和答案的多样性方面存在固有的局限性。

第三，上述所有数据集只提供远程监督；即，系统只知道答案是什么，但不知道导致它的支持事实是什么。这使得模型难以了解潜在的推理过程，以及做出可解释的预测。

为了解决上述挑战，我们的目标是创建一个需要对多个文档进行推理的QA数据集，并且以自然语言进行推理，不局限于现有的知识库或知识结构。我们还希望它能为系统提供关于答案实际来源于哪些文本的强烈监督，以引导系统进行有意义和可解释的推理。

我们介绍了一个满足这些理想条件的大规模数据集HOTPOTQA。HOTPOTQA是通过众包基于维基百科文章收集的，其中众包工作者被展示多个支持性上下文文档，并被明确要求提出需要对所有文档进行推理的问题。这段文字确保涵盖了更自然的多跳问题，这些问题在设计时没有考虑到任何现有的知识库结构。此外，我们还要求众包工作者提供他们用来回答问题的支持事实，我们也将其作为数据集的一部分提供（请参阅图1示例）。我们为HOTPOTQA精心设计了一个数据收集流程，因为收集高质量的多跳问题并非易事。我们希望这个流程也能为未来的研究指明方向。最后，作为HOTPOTQA的一部分，我们也收集了一种新型的问题——比较问题，在这些问题中，我们需要系统对比两个实体在一些共享属性上的差异，以测试它们对语言和常见概念（如数值大小）的理解。我们将HOTPOTQA公开发布在https://HotpotQA.github.io。

图1：HOTPOTQA中多跳问题的例子。我们还用蓝色斜体强调了支持事实，这些事实也是数据集的一部分。

2 数据收集

我们工作的主要目标是收集一个多样化且可解释性强的问题回答数据集，该数据集需要多步推理。一种方法是根据知识库定义推理链（Welbl等人，2018；Talmor和Berant，2018）。然而，这种方法受限于实体关系的不完整性以及问题类型的缺乏多样性。在这项工作中，我们关注基于文本的问题回答，以使问题和答案更加多样化。总体设置是，给定一些上下文段落（例如，几段或整个网络）和一个问题，问答系统通过从上下文中提取一段文本来回答问题，类似于Rajpurkar等人（2016年）。我们还确保必须执行多跳推理才能正确回答问题。

收集基于文本的多跳问题并非易事。在我们的初步研究中，我们发现，简单地给众包工作者任意一组段落是事与愿违的，因为对于大多数段落集，很难提出一个有意义的多跳问题。为了解决这个挑战，我们精心设计了一个收集基于文本的多跳问题的流程。以下，我们将强调我们流程中的关键设计选择。

构建维基百科超链接图。我们使用整个英文维基百科的dump作为我们的语料库。在这个语料库中，我们发现了两个观察结果：（1）维基百科文章中的超链接通常自然地表示两个（已经消歧义）实体之间的关系，这可能有助于促进多跳推理；（2）每篇文章的第一段通常包含许多可以有意义查询的信息。根据这些观察结果，我们从所有维基百科文章的第一段提取所有超链接。使用这些超链接，我们构建了一个有向图G，其中每条边（a，b）表示从文章a的第一段到文章b存在一个超链接。

生成候选段落对。为了使用G生成有意义的两段式多跳问题回答，我们首先考虑一个示例问题：“Radiohead的歌手和词曲作者是什么时候出生的？”要回答这个问题，需要先推断出“Radiohead的歌手和词曲作者”是“Thom Yorke”，然后在文本中找到他的生日。在这篇文章中，我们将“Thom Yorke”视为一个桥梁实体。 在超链接图G中，给定一条边(a, b)，通常可以把b的实体视为连接a和b的桥梁实体。当我们观察到文章b时，它通常可以确定a和b之间的共享上下文的主题，但并不是所有文章b都适合收集多跳问题。例如，像国家这样的实体在维基百科中经常被提及，但不一定与所有进入的链接有多少共同点。此外，对于大众工作者来说，提出关于高度技术性实体（如IPv4协议）有意义的多跳问题也相当困难。为了解决这个问题，我们把桥实体限制在一组手动筛选的维基百科页面上（见附录A）。在筛选出一套页面B后，我们通过从超链接图中采样边(a,b)来创建候选段落对，使得b∈B。

比较问题。除了使用桥接实体收集的问题外，我们还收集另一种多跳问题——比较问题。主要的想法是，比较同一类别的两个实体通常会产生有趣的多跳问题，例如，“谁曾在NBA球队效力过更多，迈克尔·乔丹还是科比·布莱恩特？”为了方便收集这种类型的问题，我们从维基百科手动筛选出42个相似实体列表（表示为L）。为了生成候选段落对，我们从同一列表中随机抽取两个段落，并将其呈现给众包工作者。

为了增加多跳问题的多样性，我们还引入了一种子集的yes/no问题，以比较问题的形式出现。这补充了原来比较问题的范围，提供了新的方式要求系统对两个段落进行推理。例如，考虑来自英国的铁娘子乐队（Iron Maiden）和来自澳大利亚的AC/DC乐队。问题如“铁娘子乐队或AC/DC乐队来自英国吗？”并不理想，因为即使只阅读过关于铁娘子乐队的文章，人们也会推断出答案是“铁娘子乐队”。对于是或否的问题，可以问“铁娘子乐队和AC/DC乐队是否来自同一个国家？”，这需要对两段文章进行推理。

据我们所知，基于文本的比较问题是一种新颖的问题类型，以前的数据集并未考虑过。更重要的是，回答这些问题通常需要进行算术比较，例如根据出生日期比较年龄，这为未来模型的发展提出了新的挑战。

收集支持性事实。为了提高问答系统的解释性，我们希望它们在生成答案时输出一组必要的支持性事实。为此，我们还从众包工作者那里收集决定答案的句子。这些支持事实可以作为对哪些句子值得关注的强大监督。此外，我们可以通过比较预测的支持事实与实际事实来测试模型的可解释性。

数据收集的整体过程如算法1所示。

3 处理和基准设置

我们总共在 Amazon Mechanical Turk4 上使用 ParlAI 接口（Miller 等人，2017）收集了112,779个有效的例子（参见附录A）。为了从所需的多跳问题中隔离出潜在的单跳问题，我们首先从数据集中划分出一个子集，称为 train-easy。具体来说，我们从贡献最多的Turker中随机抽取了一些问题（每个Turker约3-10个），并将他们所有的问题归类到训练简单集，如果样本中的绝大多数问题只需要对其中一个段落进行推理。我们选择这些Turker是因为他们贡献了超过70%的数据。这个训练简单集包含18,089个主要是一跳的例子。

我们实现了一个基于当前最先进架构的问题回答模型，详细讨论在第5.1节。基于这个模型，我们在剩余的多跳例子上进行了三折交叉验证。在这些示例中，模型能够正确回答60%的问题（通过设置模型损失的阈值确定）。这些正确回答的问题（总共56,814个，占多步推理示例的60%）被分离出来并标记为train-medium子集，也将作为我们训练集的一部分。

在划分出训练简单和中等难度的样本后，我们剩下的是困难的例子。由于我们的最终目标是解决多步问题回答，因此我们将重点放在最新建模技术无法回答的问题上。因此，我们将开发和测试集限制为困难的例子。具体来说，我们将困难的例子随机分为四个子集：train-hard、dev、test-distractor 和 test-fullwiki。数据划分的统计信息可以在表1中找到。在第5部分，我们将证明结合train-easy、train-medium和train-hard来训练模型可以得到最佳性能，因此我们使用合并后的集合作为默认的训练集。另外两个测试集test-distractor和test-fullwiki用于两种不同的基准设置，接下来我们会介绍这两个设置。

表1：数据拆分。训练易、训练中和训练难的数据合并用于训练。干扰者和全维基设置使用不同的测试集，以便在全维基测试集中保持黄金段落对任何模型的未知性。

我们创建了两种基准设置。在第一个设置中，为了挑战模型在噪声存在下找到真正的支持事实的能力，对于每个例子，我们使用bigram tf-idf（Chen等人，2017）从维基百科检索8个段落作为干扰项，使用问题作为查询。两个金色段落和八个干扰项在输入模型之前被打乱。在第二个设置中，我们全面测试了模型定位相关事实以及对它们进行推理的能力，要求它在没有指定金色段落的情况下，根据所有维基百科文章的第一段来回答问题。这个完整的维基百科设置真正测试了系统在多步推理方面的性能。两个场景的难度不同，需要运用从阅读理解到信息检索等一系列技术。如表1所示，我们为这两个场景使用单独的测试集以避免信息泄露，因为黄金段落对于在分散注意力设置中的模型是可用的，但在完整维基百科设置中不应可访问。

我们还试图理解模型在train-medium分割上的良好性能。手动分析表明，train-medium中多跳问题的比例与硬示例相似（train-medium中为93.3%，dev中为92.0%），但有一种问题类型在train-medium中比硬分割更频繁出现（类型II：train-medium中为32.0%，dev中为15.0%，请参阅第4节了解类型II问题的定义）。这些观察结果表明，在足够的训练数据下，现有的神经网络结构可以被训练来回答某些类型和某些子集的多跳问题。然而，当不仅仅是黄金段落存在时，train-medium仍然具有挑战性 - 我们在附录C中展示了在这些问题上的检索问题与它们的困难表亲一样复杂。

4 数据集分析

在这部分，我们分析了数据集中涵盖的问题类型、答案类型和多跳推理类型。

问题类型：我们通过经验法则为每个收集到的问题确定了问题类型。为了确定问题的类型，我们首先找到问题中的中心问题词（CQW）。由于HOTPOTQA包含比较问题和是/否问题，我们认为疑问词包括WH-词、连系动词（如“是”、“are”）和助动词（如“does”、“did”）。因为问题通常涉及以WH-词开头的相对从句，我们定义CQW为问题中的第一个问题词，如果它可以在前三个词中找到，否则就是最后一个问题词。然后，我们通过提取CQW右侧最多两个词以及左侧的一个词来确定问题类型，前提是它是一个常见介词（例如，“在哪”和“由谁”的情况）。

我们将在图2中可视化问题类型的分布，并标记那些在250个问题中共享的问题。如图所示，我们的数据集涵盖了各种各样的问题，围绕着实体、地点、事件、日期和数字，以及针对两个实体进行比较的“是/否”问题（例如“A和B都是…吗？”），等等。

图2：HOTPOTQA中涵盖的问题类型。问题类型是通过启发式方法从问题词或它们前面的介词开始提取的。空彩色方块表示太罕见而无法单独显示的后缀。有关更多详细信息，请参阅正文。

答案类型。我们进一步从数据集中抽取100个示例，并在表2中呈现答案的类型。如所见，HOTPOTQA涵盖了各种各样的答案类型，这与我们对问题类型的初步分析相匹配。我们发现，大多数问题都是关于文章中的实体（68%），而且还有相当一部分问题询问了各种属性，如日期（9%）和其他描述性属性，如数字（8%）和形容词（4%）。

多跳推理类型。 我们还从开发和测试集中抽取了100个例子，并手动分类了回答每个问题所需的推理类型。除了比较两个实体外，回答这些问题还需要三种主要的多跳推理类型，如表3所示，并附有示例。

表3：HOTPOTQA开发和测试集中需要的多跳推理类型。我们用橙色粗体斜体显示桥接实体（如果适用），用蓝色斜体显示与问题直接连接的支持性事实，用绿色粗体显示段落中的答案或问题之后的答案。其余8%是单跳（6%）或无法回答的问题（2%）。

大多数问题需要从每个段落中至少找出一个支持事实来回答。在所抽取的问题中，有42%的问题需要进行链式推理（表中的类型I），在这种情况下，读者必须首先识别出一个桥梁实体，然后才能通过填充桥梁来回答第二个问题。解决这类问题的一种策略是将它们分解为连续的单跳问题。桥实体还可以隐含地帮助推断与之相关的其他实体的属性。在某些问题（类型III）中，问题中的实体与桥实体共享某些属性（例如，它们位于同一位置），我们可以通过桥实体推断其属性。另一种类型的问题是通过满足多个属性同时来定位答案实体（类型II）。在这里，为了回答问题，可以找到满足所有提到的属性的实体集，并取交集以得到最终答案。比较两个实体的问题（比较）也需要系统理解关于两个实体（例如，国籍）的问题属性，有时还需要进行算术运算，如计数（如表中所示）或比较数值值（“A和B谁更年长？”）。最后，我们发现有时问题需要超过两个支持事实来回答（其他）。在我们的分析中，我们还发现对于表格中显示的所有示例，Turkers提供的支持事实与这里显示的有限上下文完全匹配，表明收集的支持事实质量很高。

除了上述提到的推理类型外，我们还估计大约有6%的样本问题可以通过两个段落中的一个来回答，还有2%的问题无法回答。我们还从train-medium和train-hard组合中随机抽取了100个例子，推理类型的比例为：Type I 38%，Type II 29%，比较20%，其他7%，Type III 2%，单跳2%，无法回答2%。

5 实验

5.1 模型架构和训练

为了测试领先问答系统在我们数据上的性能，我们重新实现了Clark和Gardner（2017）中描述的架构作为我们的基准模型。我们注意到，没有权重平均的我们的实现，在SQuAD上表现非常接近作者报告的结果（F1得分约低1分）。我们实现的模型涵盖了问题回答方面的最新技术进步，包括字符级模型、自注意力（Wang等，2017年）和双向注意力（Seo等，2017年）。结合这三个关键组件正成为标准做法，各种最先进的或有竞争力的架构（Liu等人，2018年；Clark和Gardner，2017年；Wang等人，2017年；Seo等人，2017年；Pan等人，2017年；Salant和Berant，2018年；Xiong等人，2018年）在SQuAD上可以看作与我们实现的模型类似。为了适应是/否问题，我们还在最后一个循环层之后添加了一个三路分类器，以产生“是”、“否”和基于跨度的答案的概率。在解码过程中，我们首先使用三路输出来确定答案是“是”、"否"还是文本跨度。如果它是一个文本跨度，我们进一步搜索最可能的跨度。

支持事实作为强监督。为了评估基本模型在预测可解释的支持事实方面的性能，以及它们如何提高问答性能，我们还设计了一个组件，将这种强监督融入到我们的模型中。对于每个句子，我们将自注意力层在第一个和最后一个位置的输出连接起来，并使用二元线性分类器来预测当前句子是支持事实的概率。我们为这个分类器最小化二元交叉熵损失。这个目标与正常问题回答目标在多任务学习环境中共同优化，它们共享相同的低级表示。通过这个分类器，模型还可以在支持事实预测的任务上进行评估，以衡量其可解释性。我们的整体架构如图3所示。虽然可以构建一个管道系统，但在这项工作中，我们关注的是端到端的系统，它更易于调整，训练速度也更快。

图3：我们的模型架构。在多任务设置中使用对支持事实的强监督。

5.2 结果

我们在两个基准设置中评估我们的模型。在完整的维基设置中，为了在5,000,000+个维基段落中实现高效的tf-idf检索，给定一个问题，我们首先使用基于倒排索引的过滤策略返回一个最多包含5,000个段落的候选池，然后在池中选择top 10段落作为最终的候选者，使用bigram tf-idf进行选择。检索性能如表5所示。在检索到这10段内容后，我们使用在干扰项设置下训练的模型来评估其在这些最终候选段落上的性能。

表5：在完整维基设置下的检索性能。平均排名是根据两个黄金段落的排名平均得出的。

根据之前的研究（Rajpurkar等人，2016），我们使用精确匹配（EM）和F1作为两个评估指标。为了评估模型的解释性，我们进一步引入了涉及支持事实的两组度量指标。第一组关注直接评估支持事实，即在支持事实句子集上计算EM和F₁与黄金标准集的比较。第二组则采用联合指标，结合回答范围和支持事实的评估，具体如下。对于每个示例，给定其在答案范围（P^(ans)，R^(ans)）和支持事实（P^(sup)，R^(sup)）上的精确度和召回率，我们计算联合F₁为

联合EM的值只有在两个任务都实现精确匹配时才为1，否则为0。直观地说，这些度量标准会惩罚在任一任务上表现不佳的系统。所有度量标准都是逐个示例进行评估，然后在评估集中的示例上进行平均。

我们在基准设置下的模型性能如表4所示，其中所有数字都是在支持事实的强监督下获得的。从干扰设置到全维基设置，扩大上下文范围增加了回答问题的难度。在完整的维基环境中，性能显著降低，这给现有的基于检索的问题回答技术带来了挑战。总的来说，在所有环境中的模型性能都远低于人类的性能，如第5.3节所示，这意味着未来的工作需要更多的技术进步。

表格4：主要结果：在两个基准设置下，问题回答和支撑事实预测的性能。我们鼓励研究人员在评估他们的方法时报告这些指标。

我们还通过测量支持事实预测性能来研究我们模型的解释性。我们的模型实现了60+的支持事实预测F1和约40的联合F1，这表明在解释性方面还有进一步改进的空间。

在表6中，我们分析了不同问题类型的性能。在干扰项设置中，比较性问题的F1得分低于涉及桥梁实体（如第2节所定义）的问题，这表明更好地模拟这种新颖的问题类型可能需要更好的神经网络架构。在完整的维基设置中，桥接实体问题的性能显著下降，而比较问题的性能仅略有下降。这是因为比较问题中的两个实体通常都会出现，从而降低了检索的难度。结合表5中的检索性能，我们认为表4中完整维基设置下的性能恶化主要是由于检索两个实体的难度较大。

表6：在分散设置下，不同问题类型的性能分解。开发集上的“桥接实体”收集的问题用“Br”表示，比较问题用“Cp”表示。

我们在干扰项设置中进行了消融研究，并在表7中报告了结果。自我注意力和字符级模型都对最终性能有显著贡献，这与之前的研究一致。这意味着针对单跳问答的技术在我们的环境中仍然有一定的效果。此外，取消对支持事实的严格监督会降低性能，这证明了我们方法的有效性和支持事实的有用性。我们通过只将支持事实作为模型的上下文输入来建立强监督的上限估计，与不使用支持事实相比，F₁得分提高了10%以上。与我们模型中的强监督收益（约2个F₁点）相比，我们提出的支持事实监督的方法可能并不最优，我们将更好地对其进行建模的挑战留给了未来的工作。最后，我们证明了结合所有数据分割（训练-简单、训练-中等和训练-困难）可以取得最佳性能，这被作为默认设置。

表7：在分散设置中问题回答性能的消融研究。“– sup fact"表示从我们的模型中删除对支持事实的强监督。”– train-easy"和"– train-medium"表示在训练过程中丢弃相应数据集。"gold only"和"sup fact only"分别指使用黄金段落或支持事实作为模型的唯一上下文输入。

5.3 建立人类表现

为了确定人类在我们数据集上的表现，我们从开发和测试集中随机抽取了1,000个例子，并让至少另外三个Turker为这些例子提供答案和支持事实。作为一个基准，我们将数据收集期间的原始Turker的预测视为预测，新收集的答案和支持事实作为参考，以评估人类的表现。对于每个示例，我们选择能够最大化F1分数的答案和支撑事实参考，以报告最终的度量指标，从而减少歧义的影响（Rajpurkar等人，2016）。

如表8所示，原始众包工人在找到支持事实和正确回答问题方面都取得了非常高的表现。如果基准模型一开始就提供了正确的支持段落，它在找到支持事实上可以与众包工人持平，但在找到实际答案方面仍然不足。当存在干扰段落时，基线模型与众包工作者在两个任务上的性能差距扩大到约30%，无论是精确匹配（EM）还是F1分数。

表8：比较基线模型在1000个随机样本上的性能与人类性能。"Human UB"表示HOTPOTQA上注释员性能的上限。有关详细信息，请参阅正文。

我们进一步确定了HOTPOTQA中人类表现的上限，方法是取每个例子的最大准确率和F1值。在这里，我们依次使用每个Turker的答案作为预测，并将其与所有其他工作者的答案进行评估。如表8所示，大多数指标都接近100%，这表明在大多数示例中，至少有一部分Turkers彼此之间达成了共识，显示出了高互注释者的一致性。我们还注意到，众包工作者在支持事实上达成的共识较少，这可能反映出这个任务比回答问题更具有主观性。

6 相关工作

最近提出的一些大规模问答数据集可以分为四类。
单文档数据集。SQuAD（Rajpurkar 等人，2016，2018）的问题相对较简单，因为它们通常只需要在段落中找到一个句子就可以回答。
多文档数据集。TriviaQA（Joshi 等人，2017 年）和 SearchQA（Dunn 等人，2017 年）包含问题答案对，这些对伴随着多个文档作为上下文。这进一步挑战了问答系统处理较长上下文的能力。然而，由于支持性文档是在问题答案对之后通过信息检索收集的，所以这些问题并不一定能涉及到多个文档之间的有趣推理。
基于知识库的多跳数据集。最近的数据集，如QAngaroo（Welbl等人，2018）和COM-
PLEXWEBQUESTIONS（Talmor和Berant，2018），探索了使用预先存在的知识库（KB）和预定义逻辑规则的不同方法来生成有效的问答对，以测试问答模型在执行多跳推理方面的能力。多样性的问题和答案在很大程度上受到固定的知识库架构或逻辑形式的限制。此外，由于知识库的不完整性，一些问题可能只需要一个文本句子就能回答。
自由形式的答案生成数据集。微软信息检索竞赛（Nguyen等人，2016）包含10万个来自必应搜索的用户查询，以及人类生成的答案。系统生成自由形式的答案，并通过自动指标（如ROUGE-L和BLEU-1）进行评估。然而，这些指标的可靠性值得怀疑，因为它们与人类判断的相关性较差（Novikova等人，2017）。

7 结论

我们介绍了HOTPOTQA，这是一个大规模的问题回答数据集，旨在促进开发能够进行解释性、多跳推理的自然语言多样性问题的回答系统。我们还提供了一种新型的事实比较问题，以测试系统从文本中提取和比较各种实体属性的能力。

A 数据收集详情

A.1 数据预处理

我们下载了2017年10月1日的英文维基百科的dump文件，并使用WikiExtractor提取了文本和超链接。我们使用Stanford CoreNLP 3.8.0（Manning等人，2014）进行单词和句子分词。我们使用得到的句子边界来收集支持事实，并使用标记边界来检查Turkers提供的答案是否覆盖了整个标记，以避免不合理的部分单词答案。

A.2 更详细的资料收集

关于整理维基百科页面的详细信息。为了确保采样的候选段落对可以直观地让众包工作者提出高质量的多跳问题，我们从WikiProject的热门页面列表中手动策划了591个类别。对于每个类别，我们从图G中随机抽取（a，b）对，其中b属于所考虑的类别，并手动检查是否可以根据对（a，b）提出多跳问题。那些允许出现高概率的多跳问题的类别被选中。
奖金结构。为了激励众包工作者更高效地生产高质量数据，我们遵循Yang等人（2018）的方法，采用奖金结构。在我们的数据收集过程中，我们混合了两种设置。在第一种设置中，我们每200个例子奖励表现最好的（即数量最多的）工人。在第二种设置中，工人的奖金基于他们的生产力（以每小时的例子数量衡量）。

A.3 众包工作者界面

我们的众包工作者界面基于ParlAI（Miller等人，2017），这是一个开源项目，旨在促进对话系统和通过对话接口进行数据收集的开发。我们通过将收集工作流转换为面向系统的对话，使ParlAI适应于收集问题答案对。这使我们能够更好地控制turkers的输入，并为turkers提供实时反馈和有用的提示，以帮助他们完成任务，从而加快数据收集过程。

请参阅图4，了解在数据收集期间工作者界面的示例。

图4：亚马逊Mechanical Turk工作界面的截图。

B 进一步数据分析

为了更深入地研究HOTPOTQA数据集的多样性，我们进一步可视化了问题长度分布如图5所示。除了在类型上具有多样性（如正文所示），问题在长度上也存在很大差异，这表明问题涵盖了不同复杂程度和细节。

图5：HOT-POTQA中问题长度的分布。

C 完整维基设置详情

C.1 倒排索引过滤策略

在完整的维基设置中，我们采用了一种基于倒排索引的高效过滤策略，用于初步检索候选段落。我们在算法2中提供了详细信息，在我们的实验中，控制阈值N设置为5000。对于某些问题q，其相应的黄金段落可能未包含在输出候选池Scand中。在评估过程中，我们将此类缺失的黄金段落的排名设置为Scand的大小+1。因此，本文报告的MAP和平均排名是其真实值的上界。

C.2 将训练-中等分割与困难分割进行比较

表9显示了在全维基设置下，训练-中等划分与像开发和测试这样的困难示例之间的检索指标比较。我们可以看到，训练-中等划分与其开发/测试之间的性能差距较小，这表明在全维基设置下的训练-中等划分与困难示例具有相似的难度水平，在这种情况下，检索模型作为第一步处理是必要的。

表9：在完整维基百科设置下，针对train-medium、dev和test的检索性能比较，每个数据集包含1,000个随机样本。MAP和均以百分比表示。Mean Rank平均了两个黄金段落的检索排名。CorAns Rank指的是含有答案的黄金段落的排名。