内容速览
- 什么是语义解析(Semantic Parsing)
- 什么是逻辑形式(Logic Form)
- 语义解析KB-QA的方法框架
- 实验结果
本期我们从传统方法之一的语义解析(有时也被称为语义分析)开始,以一个经典的语义解析baseline方法为例,介绍语义解析如何进行KB-QA。该方法来自斯坦福Berant J, Chou A, Frostig R, et al. 的Semantic Parsing on Freebase from Question-Answer Pairs,文章发表于2013年的EMNLP会议。
注:语义解析的方法涉及到一些传统linguistic的知识,也是KB-QA三大传统方法中最难以理解的一种方法。这里由于篇幅有限,我们将不再对相应的linguistic知识进行详细介绍,为了方便大家理解,我们可能并未使用最标准的定义来解释linguistic相关的名词,而是给出方便大家理解的直觉上的解释。如果您对linguistic相关的知识感兴趣,可以关注我,之后我们将开设专栏,对传统linguistic的知识进行介绍和梳理,敬请期待。
什么是语义解析
在揭开知识库问答KB-QA的面纱1·简介篇中我们谈到,知识库Freebase由大量的三元组组成,并且这些三元组的实体和实体关系都是形式化的语言,比如
(BarackObama, PlaceOfBirth, Honolulu)
给定一个自然语言的问题
“Where was Obama born?”
我们面临的第一个挑战,就是如何建立问题到知识库的映射?
语义解析KB-QA的思路是通过对自然语言进行语义上的分析,转化成为一种能够让知识库“看懂”的语义表示,进而通过知识库中的知识,进行推理(Inference)查询(Query),得出最终的答案。
简而言之,语义解析要做的事情,就是将自然语言的问题,转化为一种能够让知识库“看懂”的语义表示,这种语义表示即逻辑形式(Logic Form)。
什么是逻辑形式
为了能够对知识库进行查询,我们需要一种能够“访问”知识库的逻辑语言,Lambda Dependency-Based Compositional Semantics ( Lambda-DCS)是一种经典的逻辑语言,它用于处理逻辑形式(在实际操作中,逻辑形式会转化SPARQL query,可以在Virtuoso engine上对Freebase进行查询)。如果我们把知识库看作是一个数据库,那么逻辑形式(Logic Form)则可以看作是查询语句的表示。
我们用z表示一个逻辑形式,用表示知识库,表示实体,表示实体关系(有的也称谓语或属性)。简单而言,逻辑形式分为一元形式(unary)和二元形式(binary)。对于一个一元实体,我们可以查询出对应知识库中的实体,给定一个二元实体关系,可以查到它在知识库中所有与该实体关系相关的三元组中的实体对。并且,我们可以像数据库语言一样,进行连接Join,求交集Intersection和聚合Aggregate(如计数,求最大值等等)操作。具体来说,逻辑形式有以下形式和操作:
有了上面的定义,我们就可以把一个自然语言问题表示为一个可以在知识库中进行查询的逻辑形式,比如对于问句
“Number of dramas starring Tom Cruise?”
它对应的逻辑形式是
当自然语言问题转化为逻辑形式之后,通过相应的逻辑语言(转化为SPARQL query)查询知识库就可以得到答案。那么,语义解析要如何把自然语言问题正确地转化为相应的逻辑形式呢?
语义解析KB-QA的方法框架
语法解析的过程可以看作是自底向上构造语法树的过程,树的根节点,就是该自然语言问题最终的逻辑形式表达。整个流程可以分为两个步骤:
- 词汇映射:即构造底层的语法树节点。将单个自然语言短语或单词映射到知识库实体或知识库实体关系所对应的逻辑形式。我们可以通过构造一个词汇表(Lexicon)来完成这样的映射。
- 构建(Composition):即自底向上对树的节点进行两两合并,最后生成根节点,完成语法树的构建。这一步有很多种方法,诸如构造大量手工规则,组合范畴语法(Combinatory Categorical Grammars,CCG)等等,而我们今天要讲的这篇论文,采用了最暴力的方法,即对于两个节点都可以执行上面所谈到的连接Join,求交Intersection,聚合Aggregate三种操作,以及这篇文章独创的桥接Bridging操作(桥接操作的具体方式稍后会提到)进行结点合并。显然,这种合并方式复杂度是指数级的,最终会生成很多棵语法树,我们需要通过对训练数据进行训练,训练一个分类器,对语法树进行筛选。
自然语言转化为逻辑形式的流程如下图所示:
上图红色部分即逻辑形式,绿色部分where was Obama born 为自然语言问题,蓝色部分为词汇映射(Lexicon)和构建(Composition)使用的操作,最终形成的语义解析树的根节点即语义解析结果。
接下来,我们还剩最后三个待解决的问题,如何训练分类器?如何构建词汇表?什么是桥接操作?
- 训练分类器
分类器的任务是计算每一种语义解析结果d(Derivation)的概率,作者通过discriminative log-linear model进行modeling,使用Softmax进行概率归一化,公式如下:
其中x代表自然语言问题,是一个从语义解析结果和中提取出来的b维特征向量(该特征向量包含了构造该语法树所有操作的对应特征,每种操作的具体特征之后会提到),是b维的参数向量。
对于训练数据问题-答案对(xi,yi),最大化log-likelihood损失函数,通过AdaGrad算法(一种动态调整学习率的随机梯度下降算法)进行参数更新。
可以看出特征向量的训练实际上是一种弱监督训练(准确的说是一种远程监督,Distant Supervison)。
- 构建词汇表
词汇表即自然语言与知识库实体或知识库实体关系的单点映射,这一操作也被称为对齐(Alignment)。我们知道自然语言实体到知识库实体映射相对比较简单,比如将“Obama was also born in Honolulu.”中的实体Obama映射为知识库中的实体BarackObama,可以使用一些简单的字符串匹配方式进行映射。
但是要将自然语言短语如“was also born in”映射到相应的知识库实体关系,如PlaceOfBirth, 则较难通过字符串匹配的方式建立映射。怎么办呢?没错,我们可以进行统计。直觉上来说,在文档中,如果有较多的实体对(entity1,entity2)作为主语和宾语出现在was also born in的两侧,并且,在知识库中,这些实体对也同时出现在包含PlaceOfBirth的三元组中,那么我们可以认为“was also born in”这个短语可以和PlaceOfBirth建立映射。
比如(“Barack Obama”,“Honolulu”),(“MichelleObama”,“Chicago”)等实体对在文档中经常作为“was also born in”这个短语的主语和宾语,并且它们也都和实体关系PlaceOfBirth组成三元组出现在知识库中。
有了这样的直觉,我们再来看看这篇文章是怎么构建词汇表的,利用ReVerbopen IE system在ClueWeb09(注:该数据集由卡耐基梅隆学校在09年构建,还有一个12年的版本,ClueWeb12)上抽取15millions个三元组构成一个数据集,如(“Obama”, “was also born in”, “August 1961”),可以看出三元组的实体和关系都是自然语言的形式,取出其中的一个三元组子集,对里面的每一个三元组的主语实体和宾语实体通过字符匹配的方式替换为知识库的实体,并使用SUTime对数据进行归一化。
如(“Obama”, “was also born in”, “August 1961”) 经过预处理后转化为 (BarackObama, “was also born in”, 1961-08)。
接着我们对每一个三元组中的自然语言短语r1两边的实体对(entity1,entity2)进行统计,注意,由于自然语言短语和知识库实体关系的对应关系是多对多的,比如“was also born in”可能对应PlaceOfBirth,也可能对应DateOfBrith,我们需要对每一个进行区分,我们可以通过知识库查询到每一个实体的类型(type),比如1961-08的类型是date而honolulu的类型是place,我们对两边的实体类型进行查询可以得到主语实体的类型和宾语实体的类型,因此可以进一步表示为,我们对其所在三元组两边的实体进行统计,得到实体对集合。
同样的,通过对知识库进行统计,对每一个知识库三元组中的实体关系r2也统计其两边的实体,可以得到实体对集合,通过比较集合和集合类似Jaccard距离(集合交集元素数目比集合并集元素个数)这样的特征来确定是否建立词汇映射,如下图所示
图中绿色字体为r1,蓝色字体为。作者定义了词汇映射操作的三种特征(用于训练分类器),对齐特征(Alignment features),文本相似度特征(Text similarity features),和词汇化特征(Lexicalized features),具体内容如下表所示
其中文本相似度特征中的S2指的freebase name。
在实际使用中,我们可以通过词性标注(POS)和命名实体识别(NER)来确定哪些短语和单词需要被词汇映射(Lexicon),从而忽略对一些skipped words进行词汇映射。并且,作者还建立了18种手工规则,对问题词(question words)进行逻辑形式的直接映射,如“where,how many”映射为Type.Location 和 Count。
- 桥接操作
完成词汇表的构建后,仍然存在一些问题。比如,对于go,have,do这样的轻动词(light verb)难以直接映射到一个知识库实体关系上,其次,有些知识库实体关系极少出现,不容易通过统计的方式找到映射方式,还有一些词比如actress实际上是两个知识库实体关系进行组合操作后的结果(作者最后提到这个问题有希望通过在知识库上进行随机游走Random walk或者使用马尔科夫逻辑Markov logic解决),因此我们需要一个补丁,需要找到一个额外的二元关系来将当前的逻辑形式连接起来,那就是桥接。
这里举个具体的例子,比如
“Which college did Obama go to?”
假设“Obama” 和 “college” 可被词汇映射映射为 BarackObama 和 Type.University, 这里"go to" 却难以找到一个映射,事实上,这里我们需要去寻找一个中间二元关系b(即Education)使得上面的句子可以被解析为,如下图所示
具体来说,给定两个类型(type)分别为t1和的一元逻辑形式和,我们需要找到一个二元逻辑形式,在对应的实体对类型满足的条件下生成逻辑形式,这就是桥接,由于这里有类型的限制,所以我们可以在知识库中相邻的逻辑关系中暴力搜索符合条件的二元关系。
(注:在论文中还提到了另外两种需要进行桥接的场景,这里我们则不再赘述)
同样的,作者也为桥接操作定义了相应的特征(为了分类器的训练),定义如下表所示
对于构建(composition)的其他三种操作,连接Join,求交集Intersection和聚合Aggregate,作者也定义了相应的特征(为了分类器的训练),如下表所示
至此,语法树的构建,分类器的训练,和分类器的输入——特征向量 的构造方式我们都已经介绍完毕。最后我们再简单的介绍一下实验和实验结果。
- 实验结果
由于语义解析树的构建方式是指数级的,因此,在训练和测试的时候,作者执行了标准的自底向上的集束分析器(Beam-based bottom-up parser),如果不了解Beam search的同学,请
。在这篇论文之前,KB-QA流行的数据集是由
构建的Free917,该数据集只包含了917组问题答案对,因此,作者构建了一个更大的benchmark数据集WebQuestion,包含了5810组问题答案对,该数据集的构建方式我在
中进行了简单介绍。
作者测试了仅使用Alignment和Bridging以及都使用下的正确率,如下表所示
作者该论文的语义解析器Sempre进行了开源,感兴趣的朋友可以点击这里。
我们可以看出传统的语义解析方法还是存在大量的手工规则,也涉及到了一些linguistic的知识,对于没有传统NLP先验知识的朋友可能理解起来会稍微困难一些。
最后,让我们再思考一下该方法有些什么缺陷?
首先,词汇映射是整个算法有效(work)的基点,然而这里采用的词汇映射(尤其是关系映射)是基于比较简单的统计方式,对数据有较大依赖性。最重要的是,这种方式无法完成自然语言短语到复杂知识库关系组合的映射(如actress 映射为)。
其次,在答案获取的过程中,通过远程监督学习训练分类器对语义树进行评分,注意,这里的语义树实际的组合方式是很多的,要训练这样一个强大的语义解析分类器,需要大量的训练数据。我们可以注意到,无论是Free917还是WebQuestion,这两个数据集的问题-答案对都比较少。
那么这些问题怎么解决呢?
在下一期中,我们将以2014年ACL的Yao X, Van Durme B. Information Extraction over Structured Data: Question Answering with Freebase[C]//ACL (1). 2014: 956-966. 这篇论文为例,介绍KB-QA的第二种传统方法——信息抽取,该方法在WebQuestion数据集上的F1-score相比本篇论文有一个较大的提升(大于10%)。
敬请期待。
系列相关文章: