HopRetriever:Retrieve Hops over Wikipedia to Answer Complex Questions ; Shaobo Li, Xiaoguang Li, Lifeng Shang, Xin Jiang,
Qun Liu, Chengjie Sun, Zhenzhou Ji, Bingquan Liu; Harbin Institute of Technology; Huawei Noah’s Ark Lab
原文:https://arxiv.org/pdf/2012.15534v1.pdf
1. background
一开始先明确这篇问题针对的问题:开放领域问答中的多跳问题回答
1.1 开放领域问答(open-domain question answering)
开放领域问答,应当分类为机器问答中的一种,可以简单解释为 于开放领域中(例如维基百科全体信息,此时问题可以是各种领域的各种问题)利用机器回答人类以自然语言形式提出的问题,同其他几种机器问答系统不同在于此时是针对开放领域提问的,可以理解为此时的问题可以涉及不同的各式的领域,也可以理解为此时回答问题所需要的知识领域是很广阔的,例如:
- 传统机器阅读理解问题:给定一篇 / 多篇拜登 / 美国相关的文章,再提问美国总统是谁
- 开放领域问答问题:提问美国总统是谁?让子弹飞的导演是谁?北京是哪里的城市?所有问题都需要在庞大的知识库中(例如维基百科)寻找答案
同理,相较于传统机器阅读理解问题的数据集会给定文章的形式,对应大部分开放领域问答数据集会将允许的答案检索文段设定为维基百科全部词条。对应的知识库的形式,可以为以下三种:
- 1)结构化的,例如构造好的知识图谱的形式;
- 2)半结构化的,表格等;
- 3)非结构化的,如维基百科的自然语言形式的词条,本文所使用的为第三种形式(即问题与所依赖的知识库都是自然语言的形式)
对应开放领域问答的任务形式,一般针对此类问题的回答分为两个步骤:
- 信息检索(information Retrieval, IR):比如美国总统是谁的问题,此时需要机器先从知识库中得到美国相关的词条信息
- 机器阅读理解(Machine Reading Comprehension, MRC):也就是根据检索出的文段回答问题,类似传统的机器阅读理解形式
1.2 多跳阅读理解问题(multi-hop / complex question)
可以直观地理解为 需要多次跳转,将不同的信息进行进一步整合才能得到答案的阅读理解问题,举个例子(例子来自 CogQA):
这个问题本身问的是导演,但是没有给出电影的名字,首先需要后面的信息去推断是哪一部电影,才能进一步去寻找该电影的导演。也就是说相较于传统的简单问题形式,多跳阅读理解问题需要机器掌握一定推理的能力,能够依据问题信息多步寻找所需要的信息并不断更新证据链,最终得到需要的答案。
2 introduction
针对开放领域的多跳阅读理解问题,当前主流模型大多为 Retriever + Reader 的结构:
- D q = R e t r i e v e r ( q , K ) D_q = Retriever(q,K) Dq=Retriever(q,K):负责从知识库 K 中,依据问题 q 搜索可能的证据
- a = R e a d e r ( q , D q ) a = Reader(q, D_q) a=Reader(q,Dq):利用检索得到的证据 Dq 再结合问题 q 得到最后的答案
此时如何收集所需要的信息或成为整个问题流程中最大的挑战,考虑此时知识库内存有大量信息,而为回答多跳问题同时需要从多个相关信息词条中收集所需要的信息并聚合,对于上述 retriever + reader 结构形式的模型而言,此时相较于传统的简单阅读理解问题,信息收集部分模型的能力十分重要。
最近主流的方法是将多跳证据收集作为迭代文档检索问题来处理,也就是将一个复杂问题的分步搜索求解的,从整个知识源中检索证据链的过程,分解成多个单步文档检索。而本文的作者认为,在这样检索的过程中需要同时利用结构化信息和非结构化信息;举个例子来解释这里的结构化和非结构化:
- 结构化信息:也就是提及关系,例如左图中通过 spawned 关系提及了对应的三首歌,spawn 同时符合问题中的 song of 关系,故此时能够提示模型三首歌的信息是所需要的信息;
- 非结构化信息:也就是外来知识,比如此时可以通过对应歌名的超链接跳转到新的链接对应得到新的信息。注意此时三首歌中只有第一首是符合合作要求的,故此时模型需要探索三首歌对应的外部链接对应词条的信息,才能从三个选项中得到正确答案;
综上,对于开放领域的问答,此时需要同时关注
1)当前文档中对于下一跳实体的提及信息 = 结构化信息 = 关系证据;
2)下一跳实体本身链接对应的新的外部信息 = 非结构化信息 = 事实证据
本文重点即在于将上述两种类型的信息结合起来,为此,作者定义了 跃点 = hop 为 超链接 + 链接对应外部词条内容的组合,此时可以认为 超链接 记录了当前实体和前序实体的关系(也就是新的实体是怎样在前一个实体的文档中被提及的),而超链接对应的外部词条内容扩充了被提及实体的信息。同时,本文着重研究了如何 有选择地提取需要的非结构化信息,同时将 结构化信息与非结构化信息作融合
其实个人觉得这里的结构化信息 = mention 也就是 KGQA 中的实体关系的部分;而非结构化信息也就是其中尾结点的 embedding 的部分,对于 KGQA 而言本文的思路是十分常见的(也就是寻找在知识图谱上推理的路径的思路),只是在自然语言形式的文本下,实体的信息与各自的关系结构不像知识图谱中这么显式,需要一定的抽取整合工作
3 Method
3.1 Overview
先看看模型整体结构:
这里通过一个示例问题来展示模型流程:
- 首先从问题中可以获取 Big Stone Gap 的实体
- 以该实体作为出发点,可以在其相关的文档中发现提及实体 Adriana 和 Donna;注意此时超链接对应的上下文中包含了 (directed by)和(produced by)的信息,这些信息 = 上述的结构化信息 = 提示了电影和两个人名之间的关系;
- 以 Adriana 的提及为例,此时其超链接对应上下文的信息(蓝色部分)作为 mention,而超链接对应的外部词条(也就是 Adriana 词条)作为 document,分别提供关系信息和事实信息,模型将这两种类型的信息作融合,作为 跃点 = hop 的信息;
- 由上步骤,同理可以从被提及的实体(例如上面的 Adriana)再出发寻找下一跳的实体,由此不断生成证据链,且注意到证据链中的每一跳 = 每一个跃点 = hop 都是存在自己的表示的(由 document 和 mention 两方面的信息组成)
- 以一定的条件结束检索,得到证据链与最终答案
3.2 Hop encoding
首先考察如何得到跃点 = hop 的 embedding 信息,也就是同时得到 mention 和 document 的信息,并将其作融合(也就是同时融合结构化信息和非结构化信息 = 同时融合证据信息和事实信息的过程)
3.2.1 mention embedding
设此时在实体
e
i
e_i
ei 的文档
d
I
d_I
dI 中提到了实体
e
j
e_j
ej,提及部分的语句为
m
i
,
j
m_{i,j}
mi,j
以 the album spawned three singles On My Mind , … 这样的一句话为例,这句话标志了从实体 ei = album 提及了 single 实体 ej = On My Mind,则这句话本身作为
m
i
,
j
m_{i,j}
mi,j,本文采用的方法为在这句话的提及实体(也就是 On My Mind)的前后各加入一个特殊的
[
M
A
R
K
E
R
]
[MARKER]
[MARKER] 的token,将 原问题 + mention 部分的这一句话作拼接 → 再扔进 BERT,并取第一个
[
M
A
R
K
E
R
]
[MARKER]
[MARKER] 对应的 embedding 作为 mention 部分的 embedding
如果此时文档中没有直接提及实体 ej(例如相关词条的形式,在逛 ei 的词条的时候可能相关词条中出现了 ej 但是并没有一个明确的 mention 的一句话提到 ej)则用一个固定的向量
m
p
m_p
mp 作为 mention 部分的 embedding;注意
m
p
m_p
mp 是可学习的
也就是由下式获得提及
m
i
,
j
m_{i,j}
mi,j 的 embedding:
这个做法似乎是借鉴了 ACL2019 的文章:Matching the Blanks: Distributional Similarity for Relation Learning,具体有效性和理由可能需要读读这篇
3.2.2 document embedding
这部分比较简单粗暴,也就是将被提及实体
e
j
e_j
ej 对应的外部词条的整个内容
d
j
d_j
dj 同问题
q
q
q 拼接后,整个扔进 BERT,取
[
C
L
S
]
[CLS]
[CLS] 对应 token 的 embedding 作为外部文档的 embedding,记作
u
j
u_j
uj
3.2.3 knowledge fusion
再考虑如何将提及 = mention embedding 和外部文档 = document embedding 两部分的信息作融合
记 mention embedding 为
m
i
,
j
m_{i,j}
mi,j,而 document embedding 为
u
j
u_j
uj,此时目标为得到对应的跃点的 embedding,记为
h
o
p
i
,
j
hop_{i,j}
hopi,j,这里通过注意力机制将信息作融合:
其中 h 为过去检索的历史信息,具体是通过不断检索不断更新的(也就是每每从一个实体向下一个实体跳跃的过程中都会不断丰富 h 的信息,具体计算方式会在下面提及),这里的 h 实际上是作为注意力机制中的 query vector,而
m
i
,
j
m_{i,j}
mi,j 和
u
j
u_j
uj 作为 key vector,从中选出所需要的信息,并通过 softmax 获取 mention embedding 和 document embedding 相对的权重信息
ω
m
,
ω
u
\omega_m, \omega_u
ωm,ωu,再结合得到对应跃点 = hop 的 embedding 信息
从直观的角度来说,这里的 h 也就是我当前已经推理完成得到的信息;例如问题:让子弹飞的导演家乡哪里?在初始面对问题的时候关注点应该在让子弹飞,但是已经推出导演名后关注点应该在家乡,此时不同的推理步骤对应的关注点是不同的
3.3 Iterative Retrieval of Hops
注意到此时推理链的形成是通过不断跳跃不断寻找下一个 hop 来完成的,此时采用如下的形式完成接连的 hop 获取:
首先,初始的实体
e
s
e_s
es 来自问题,在从
e
s
e_s
es 跳跃至下一个提及实体
e
i
e_i
ei 的过程中使用一个初始的隐藏状态
h
s
h_s
hs,获得这一 hop 的对应 embedding =
h
o
p
s
,
i
hop_{s,i}
hops,i 后,将其和我初始的隐藏状态
h
s
h_s
hs 一同作为输入加入 RNN 网络, 并得到下一个 hop embedding 计算需要的隐藏状态
h
2
h_2
h2,由此不断循环
也就是说,假设此时第 t-1 跳结束后我们来到实体
e
i
e_i
ei,并期望得到实体
e
i
e_i
ei 到实体
e
j
e_j
ej 的
h
o
p
i
,
j
hop_{i,j}
hopi,j 的信息,则此时需要用到的
h
i
h_i
hi 隐藏状态通过如下的方式计算:
同时注意到,一个实体
e
i
e_i
ei 下可能有多个提及
e
j
e_j
ej,为从中选择出下一步确实需要移动的实体,我们计算每一个可能的
h
o
p
i
,
j
hop_{i,j}
hopi,j 确实为推理链中的一环的概率(通过对应第 t hop 的隐藏状态 ht 和该 hop 的 embedding 的点乘再 sigmoid)
为了标记何时结束跳跃,此时定义一个表示结束状态的 hop,记作
h
o
p
e
hop_e
hope,其对应为 mention embedding
m
p
m_p
mp(也就是前面如果我们的 ei 实体中没有直接提及 ej 的时候使用的 mention embedding)和一个虚拟的 document embedding
u
e
u_e
ue 的结合;如果此时
h
o
p
e
hop_e
hope 被选中,则停止 hop 的生成。
※ 整理一下上面提到的所有可能的 hop embedding:
3.4 Fine-Grained Sentence-Level Retrieval
注意到很多多跳阅读理解问题的数据集同时是要求给出当前答案所利用的证据的,故此时需要作支持句子检索 = 检索到底是哪些句子作为我推理链的证据
注意证据句子单使用 mention 的句子是不足的,也就是前面提到了 “mention 的信息只是结构化信息 = 标记了前后两个实体之间的关系信息”,但无法展示被提及实体本身的事实信息 = 非结构化信息。也就是说我的证据句子同时存在于被提及实体 ej 对应的外部词条 dj 中;
注意此时证据句子的检索和上述 hop 的迭代是同时进行的;假设此时经过 t 步的 hop 操作,我们位于实体 ei,想要从 ei 对应的文档 di 中寻找证据句子
di 文档中的第
l
l
l 个句子为证据句子的概率为:
首先在文档
d
i
d_i
di 的第
l
l
l 个句子后加入一个特殊的 token
[
S
M
−
l
]
[SM-l]
[SM−l],再将文档 di 和问题 q 拼起来扔进 BERT,将得到的
[
S
M
−
l
]
[SM-l]
[SM−l] 的 embedding 取出(类似于 mention embedding 的获取方式),再用 (9) 式计算该句子为证据句子的概率;若此时的概率 > 0.5,该句子将被认定为证据句子(因为一个文档中可能存在多句作为证据句子的所以并不是扔进 softmax 中取最大)
3.5 objective functions
综上,来定义最终的目标函数:
这里用交叉熵损失函数来处理,回忆一下,假设此时经过了 t-1 步的 hop,我们希望从当前的实体 ei 跳到下一个 ej,则我最终一通操作得到的是实体 ej 确实为下一跳实体的概率
p
(
d
j
)
p(d_j)
p(dj)
这里令
d
j
d_j
dj 为正确推理链需要用到的文档(注意本文使用的 HotpotQA 等都是提供了解决问题的推理链的证据句子的,也就是提供了解决多跳问题的中间步骤的 bridge entity 的信息),则 hop 检索部分的损失函数定义为:
对于证据句子检索部分,令
s
i
,
l
s_{i,l}
si,l 表示确实为证据的句子( ei 实体对应的词条 di 中的第 l 个句子),则损失函数同理用交叉熵定义为:
在训练中需要同时最大化以上两个损失函数
4 experiment
这里利用 HotpotQA 数据集作模型测试
4.1 HotpotQA
先简单说说数据集
考虑到传统的机器阅读理解数据集存在一定的缺陷,将模型的能力仅仅限制在了简单的模式匹配,而不是真正的理解问题与顺次推理,这里为展现模型在需要一定的理解推理能力的更为复杂的多跳阅读理解问题上的优势,采用 HotpotQA 来进行测试
HotpotQA 为专为复杂问题 = 多跳阅读理解问题设计的数据集,其中的问题至少为两跳(也就是根本不存在简单问题,这也是其和传统机器阅读理解数据集的主要区别),分为 distractor 和 full wiki 两个赛道;前者固定为问题提供了几篇用于解答来源的文章,而后者是在整个维基百科上进行,也就是典型的开放领域的多跳问题解答任务,相较于 distractor 赛道更具挑战;
数据集基本包括:
id
唯一标识question
问题字符串answer
正确答案字符串,注意这里的答案是有多种类别的,有些答案只是 yes / no 类型,仅仅从文中进行 answer span 的划分不能完全满足需要supporting_fact
包含所有解答这个问题所需要的事实推理证据,每一个证据包括 title 所在段落标题和 sent_id = 具体提供了事实证据的句子的下标,也就是说这里给出的证据是精确到句子的context
参考段落内容
HotpotQA 对应传统机器阅读理解的数据集(例如 CoQA,SQuAD 一类)提出了新的挑战:
- 1)要求模型能够有从多个文档中综合收集信息的能力,也就是多个来源筛选可能的支撑性事实
- 2)不再是简单的模式匹配,本身需要模型自己具有一定的推理能力,真正理解问题并结合信息进行推理,得到最后答案
- 3)一并给出最终答案的支持证据,支持句子的正确与否同样会打分,也就是同时考察了模型的可解释性
本文即在 HotpotQA 的 full wiki 赛道上测试模型,当前为排行榜 #3(2021.09.22)
4.2 results
注意其中用于对比的几个模型
- CogQA 是典型的仅利用结构化信息的模型(基本思路是将提及的实体都收集起来构造认知图,再在图上进行 embedding 的传播和更新,很类似于一些推荐系统的思路,但可以说影响了后面很大一批做多跳阅读理解的论文,带着大家都去构造图去了 → CogQA 论文笔记戳这里);
- Semantic Retrieval 是典型的仅利用非结构化信息的模型,同时检索支持文档和支持句子
- PathRetriever 是典型的路径检索类的多跳阅读理解模型,同理是检索推理链的形式,但是仅关注了非结构化信息
可以看到在 Ans = 提取答案 和 Sup = 找到支持证据的句子 两个任务上的提升都是比较明显的
同时,考虑到 HopRetriever 本身是针对检索部分作一定提升,在此特别考察其检索能力,主要和 PathRetriever 作对比(这里是考虑 topK 的击中率
检索能力确实是大大增强了
4.3 analysis
以下进一步考察模型的特点与优势方面:
4.3.1 for different question types
这里将 HotpotQA 中的问题分为两个类别:
- comparison 比较类,例如 A 和 B 谁年龄大,此时需要同时收集 A 和 B 的信息,再作比较,再给出答案
- bridging 中间实体类,例如 1999年在 A 地拍摄的电影的导演是谁,此时需要先找到电影是哪一部(也就是中间步骤的 bridge entity)才能回答问题
本身 hop 检索的方式就直观上更适应 bridging 类型问题的思路模式,最终结果也是在 bridging 问题上有所提升,而比较类问题表现较差;
可以理解,此时比较类问题更多关注的是非结构化信息;比如提问:A 和 B 谁的年龄更大,此时需要去寻找 A 和 B 的信息,再分别比较,关注的是 A 和 B 各自的信息 = 非结构化信息 = 事实证据,而不是 A 和 B 的信息之间的关系 = 结构化信息;故在比较类问题上,仅关注非结构化信息的 PathRetriever 和本文的模型效果差距不大
但是在 bridging 类型的问题上,此时我选择下一跳为哪一个实体等等子任务都是需要把握实体之间的关系的,也就是说相较于比较类问题会更关注结构化信息,因此本文模型于 bridging 类问题上有更好的提升
这里作者也确实去数据集检查了两类问题中的 mention 和 document 的比例:(这里也就是 mention embedding 和 document embedding 结合的部分的两个权重的比值(对应上面的
ω
1
,
ω
2
\omega_1, \omega_2
ω1,ω2)
再来几个例子:
可以看到确实在 Case1 中,mention 本身便已经足够帮助解答问题(已经点明了 directed by),此时非结构化信息对于(选择导演 Adriana 作为下一跳的实体)是没有帮助的;
但是对于 Case 2,此时 mention 提及的实体是模糊的(同时存在两个),此时需要两个实体对应的非结构化信息,结合题目中的限制,来帮助确定下一跳的实体该是哪一个;
对于 Case 3 此时则不需要 mention 的信息(比较类问题),此时只是需要回答两个简单问题(分别 located in?)再作比较即可;并不需要关注实体之间的关系证据
综上,此时为解决多样的问题形式,结构化信息和非结构化信息均需要重视,本文提升点亦在此
4.3.2 ablation experiment
为检验模型各部分各自的效果,作者同理进行了消融实验:
可以看到此时结构化信息对于模型是十分重要的;这也是模型相较于大多只关注非结构化信息的模型能够有所提升的原因
weighting 部分表示去除了结构化信息和非结构化信息各自的权重(也就是公式 (5) 中的两个权重 ω m = ω u = 1 \omega_m = \omega_u = 1 ωm=ωu=1,可以看到对于模型存在一定影响;例如上面的三个不同的 Case 情况,不同类型的问题对于 结构化信息和非结构化信息的关注度不是相同的,需要以一定的偏重进行结合;
sentence prediction 也就是证据句子的预测,一开始就是为了某些数据集的挑战要求而设计的,去掉本身不会影响模型效果。
阅读仓促,存在错误 / 不足欢迎指出!期待进一步讨论~
转载请注明出处。知识见解与想法理应自由共享交流,禁止任何商用行为!