KBQA论文笔记(1):Modern Baselines for SPARQL Semantic Parsing(上)

484 阅读10分钟

携手创作,共同成长!这是我参与「掘金日新计划 · 8 月更文挑战」的第9天,点击查看活动详情

导语

本文研究KBQA中的Query Building(QB)部分,即假设gold entity和gold relation已知的情况下,如何将用户的自然语言问句转换为知识图谱查询SPARQL语句。作者在这种setting下对一些现代的先进模型做了实验,比如BART, T5 和 PGNs (Pointer Generator Networks) with BERT embeddings模型。实验结果表明,T5模型在LC-QuAD 1.0和LC-QuAD 2.0模型上都取得了非常好的表现。

由于本人也是刚接触该领域不久,所以尽量翻译的比较仔细,行文略显繁琐,敬请谅解。

本篇博客主要记录了原论文章节1到章节3的内容。

1 简介

知识图谱问答(KGQA)是使用知识图谱中存在的三元组,为自然语言提出的问题找到答案的任务。通常在KGQA中遵循以下步骤:

  1. 检测自然语言问题(NLQ)中感兴趣的对象,并通过称为实体链接(EL)的步骤将其链接到KG。
  2. 发现对象之间的关系并将其链接到KG,这一步称为关系链接(RL)。
  3. 将关联的实体和关系组成形式化查询,通常为SPARQL。在KG上执行查询以获取答案。

第3步称为查询构建(Query Building, QB),也是本文的重点。即假设gold entity和gold relation是可用的,如何将用户的自然语言问句转换生成正确的SPARQL查询。

作者实验了带有Pointer Generator Network(PGN)和特殊向量化的网络,以及最近比较新颖的预训练语言模型比如BART和T5。同时,文章选取了需要模型具有复制能力的数据集LC-QuAD 2.0作为实验基准。LC-QuAD 2.0的一个示例如下:

[Natural language question]: 
Is it true that an Olympic-size swimming pool’s operating temperature is equal to 22.4 ?

[SPARQL]:
ASK WHERE 
{
    wd:Q2084454 wdt:P5066 ?obj
    filter(?obj = 22.4) 
}

文章发现之前的SPARQL QB工作不能处理这样的问题。在不需要复制的数据集(LC-QuAD 1.0)上,这些方法仍然表现出强大的性能。

本文的主要贡献如下:

  • 在正确的输入分词的情况下,T5的表现优于之前的所有工作,并在LC-QuAD 1.0和LC-QuAD 2.0上取得了最先进的性能表现。

2 相关工作

Diefenbach et al.研究了几种QA系统,并得出结论,QB步骤通常与管道中的其他模块交织在一起,因此不能单独评估。后来,随着Frankenstein和Qanary的出现,它们是允许模块化构建端到端的KGQA管道的框架,可以看到QB模块是管道中研究最少的方面。不久后,Singh等人对KGQA管道的各个组件进行了全面的调查,并对Sina和NLIWOD作为独立的QB组件进行了评估。

最近的一些工作试图通过构建中间查询表示来解决复杂的查询构建,例如基于λcalculus\lambda-calculus或骨架结构的分阶段查询图。这些系统没有内置的方法来执行从输入文本到输出查询的复制操作。基于骨架结构的系统除了最终生成查询外,还需要人工将查询标注到相应的骨架结构上。其他一些解决方案依赖于模板,这些模板通常具有自然的局限性,即查询仅局限于预先选择的模板。在Ding等的工作中,模板是从输入的训练数据中发现的,然而,在查询中发现这些模板、结构和子结构的方法的实现是特定于数据集的。目前尚不清楚相同的发现方法是否可以扩展到所有数据集。

大多数处理查询图并使用λcalculus\lambda-calculus的系统都以这样的假设开始:实体已经链接,而且仍然必须找到关系。然而,随着EARL和Falcon等实体和关系联合链接器的出现,可以开发出只专注于查询构建的语义解析器,并同时接收预先链接的实体和关系。

对于non-KG的语义解析,PLMs最近的评估重点是组合泛化。对于KG语义解析,基于Compositional Freebase Questions (CFQ)数据集已报告了基于transformer的非预训练模型的结果,而在同一数据集上的后续工作已对plm进行了实验。这一行工作可能被认为是最接近本文的,然而,他们的重点是组合泛化,而我们的重点是忠实地将输入标记复制到生成的查询的能力。CFQ没有问题需要这样的复制操作。此外,由于Freebase不再是一个活跃的项目,我们的重点是DBPedia和Wikidata。通过探索两个新的数据集和相应的知识图谱,扩展了研究范围。

最近一些关于复杂时间问题回答的工作处理了需要从输入问题中提取时间戳的问题。他们使用特定任务的时间提取工具,如SUTime和HeidelTime,然而最终,他们没有形成SPARQL查询,而是试图通过实体重排序方法直接找到正确的答案。我们的努力是找到这样灵活的单一模型,可以在构建SPARQl查询的同时执行这样的提取任务。

所实验的模型无论是在中间阶段还是在解码期间都没有结构或基于模板的约束,并且能够产生任何可能的查询结构,因为我们一个token一个token地生成最终的查询token。它们需要输入问题、链接的实体和关系,以及所有可能的SPARQL标记的固定词汇表。这使得他们可以对所有可能的数据集和知识图谱进行操作。

3 模型

3.1 T5

T5,即Text-to-Text Transfer Transformer,是一种基于Transformer的编码器-解码器架构,使用文本到文本的方法。每个任务,包括翻译、问答和分类,都被视为将模型文本作为输入,并训练它生成一些目标文本。这允许在不同的任务集上使用相同的模型、损失函数、超参数等。实验了T5模型的两种变体:具有6000万个参数的T5-small和具有2.2亿个参数的T5-base。用于预训练模型的未压缩C4语料库大小为750 GB。

3.1.1 Input tokenization

假设自然语言输入的问题为Q=[w1,w2,,wn]Q = [w_1, w_2, \cdots, w_n]其中ww表示问题中的单词。链接的实体由E=[E1,E2,,En]E=[E_1, E_2, \cdots, E_n]和关系R=[R1,R2,,Rn]R=[R_1, R_2, \cdots, R_n]。对于每个实体和关系,我们从各自的KG中获取相应的标签,其中Elab1E_{lab_1}表示E1E_1的标签,关系也类似。SPARQL词汇表设置为VV。模型的输入字符串格式如下:

image.png

其中每个单词用一个空格隔开。我们用它们各自的KG IRIs来表示实体。例如DBpedia中的一个实体和关系表示如下:

[实体]
http://dbpedia.org/resource/Dolley_ Madison

[关系]
http://dbpedia.org/onto logy/spouse

对于Wikidata数据,典型的实体看起来像wd:Q76(BarackObama)wd:Q76(Barack Obama),而典型的关系看起来像wdt:P31(instanceof)wdt:P31(instance of)。前缀wd:、wdt:和其他几个根据在线可用的列表进行了扩展。在将实体和关系传递给模型之前,我们将其顺序随机打乱。

当输入字符串按原样传递给T5时,准确率接近于零,因为自动标记器按其认为合适的方式分割url,并且稍后在输出时无法正确连接这些片段。为了解决DBpedia的这个问题,我们使用了T5提供的100个哨兵令牌(sentinel tokens)。哨兵标记最初在预训练目标中用于表示掩码标记,但在我们的情况下,我们使用它们来表示前缀,例如,dbpedia.org/ontology/ 作为特定的哨兵标记,被标识为<extra_id_2>。此外,我们将SPARQL词汇表VV中的每个条目表示为每个关键字具有特定ID的标记。我们对LC-QuAD 2.0的维基数据中的前缀做了同样的处理。

3.1.2 Output

输出由来自Q,V,EQ, V, E和R$$的token组成。在LC-QuAD 1.0的情况下,由于没有需要从Q复制标记的问题,因此输出由来自V,EV, ERR的token组成。这里作者强调的一点是,由于输入包含了实体和关系,因此模型总是要执行某种形式的“复制”。甚至决定在输出SPARQL查询中放置实体和关系的位置。对于来自LC-QuAD 2.0的问题,在某些情况下,这种复制机制还必须决定从QQ中复制哪个输入标记,以及复制到输出中的哪个位置。EERR的输出不是逐字生成的,而是被分割为一个特殊的令牌前缀,然后是实体或关系ID。需要一个后处理步骤,将这些标记id解析为原始前缀,并与相邻的id合并。例如,wdt:P31在输出中以<extra_id_3> P31存在的。

3.2 BART

Bidirectional and Auto-Regressive Transformer或BART是一种将双向编码器和自回归解码器结合成一个Seq2Seq模型的Transformer。用BART-base模型进行实验,该模型由1.39亿个可训练参数组成。该模型使用Bookcorpus[45]、CC-News[24]、OpenWebText[13]和Stories[38]四个语料库组合产生的160 GB数据进行预训练。

3.2.1 Input Tokenisation

本文以与3.1.1节中讨论的T5相同的方式形成BART的输入字符串。然而,BART中没有哨兵标记的概念。因此,为了处理特殊的标记,这里使用add_tokens函数将它们添加到BartTokenizer中,并使用resize_token_embeddings函数适当地调整标记嵌入空间的大小。

3.3 Pointer Generator Network

PGN是一个具有编码器和解码器块的seq2seq网络。本文专门用基于LSTM的PGNs进行实验。虽然PGNs可以通过softmax选择从给定词汇表中生成输出标记,但它们也能够通过利用解码器的注意力权重将标记从输入文本复制到输出。T5、BART和PGN之间的一个显著区别是,PGN没有对语料库进行预训练。该模型由5300万个可训练参数组成,与T5-small的6000万个参数大小相当。

PGNs通常被用于抽象摘要任务,但最近Rongali等人使用PGNs来执行SQL语义解析。图1描述了这个解析示例查询的架构。

image.png

3.3.1 Input Tokenisation

本文通过将问题token与gold entity和gold relation连接起来来构建输入向量(图2)。在问题标记之间添加了分隔符标记[SEP]和实体候选词,以及实体候选词和关系候选词之间的候选词,以帮助模型理解输入标记片段。每个标记由一个968维向量表示,其中前768维是问题标记的BERT上下文嵌入,或实体标签或关系标签,视情况而定。接下来的200维保留给KG嵌入。对于问题标记,KG嵌入不适用,因此我们用1.0的序列填充200维。[SEP]标记由一个全为-1.0的向量表示。链接的实体和关系在最近200维中携带各自的KG嵌入。

image.png

3.3.2 KG embedding

对于这两个数据集,由于其受欢迎程度和易用性[4],本文使用TransE嵌入。对于DBpedia,使用PyTorchBigGraph[21]自己训练TransE embedding。在训练阶段,进行30次迭代,并使用余弦点操作符作为比较器函数。对于Wikidata,使用Pytorch-BigGraph 4在其网页上提供的现成的TransE嵌入。

3.3.3 Re-Ranker

作者发现PGN产生的beam search中通常包含正确的查询,但不在顶部位置。为了进一步提高查询的排名,本文在PGN的输出上微调了一个预训练的基于bert的分类器(distil-bert-base-uncased)。在val集上获取PGN的前10个波束输出,并查询KG。我们保存所有从KG中产生有效响应的查询的输出。为了训练基于bert的分类器,文章通过连接问题token、SPARQL查询和KG响应来形成输入字符串。在监督方面,本文提供了二进制标签0和1用于正误查询。一旦训练完成,使用模型倒数第二层的logit值来重新排序PGN在测试集上产生的查询。