关系抽取新SOTA: 《A Frustratingly Easy Approach for Joint Entity and Relation Extraction》论文笔记

一、前言

关系抽取作为知识图谱三元组抽取任务中最最重要的算法，一直受到工业界和学术界的广泛研究。关系抽取任务要做的是识别文本中的实体，并对相应的实体词预测正确的关系。其主要可以归纳为两种主要的技术框架：

1. pipeline方式的抽取：即先抽取实体，在预测已抽取实体之间存在的关系

2. joint方式的抽取：即实体和关系的联合抽取模式

由于pipeline抽取方法存在的误差积累、冗余实体计算、实体关系抽取任务交互缺失等问题，近些年来的SOTA模型的关注点都在于各类joint模型的改造，如共享参数的联合抽取模型、联合解码的联合抽取模型等。

二、简介

今天的这篇文章一改之前关系抽取任务的刻板印象，而是采用了pipeline抽取的方式，这篇SOTA的主要贡献和结论如下：

1. 设计了一种非常简单的end2end关系抽取方法，即采取2个独立的编码器分别用于实体抽取和关系识别，使用相同的预训练模型就超越了之前所有的joint模型～
2. 分别学习实体和关系的不同上下文表示，比联合学习它们更有效～
3. 在关系模型的输入层融合实体类别信息十分重要～
4. 提出了一种新颖并且有效的近似方法，在精度下降很小的情况下，就实现8-16倍的推断提速～

三、模型细节

文章提出的方法的框架如上图。下面分别介绍pipeline中的每一个子模型。

1. 实体抽取模型

采用span-level的NER方式，即找出所有可能的所有片段的排列，通过softmax函数对实体进行类型判断。采用span-level的好处是可以解决嵌套实体的问题，缺点是计算的复杂度会很高(对于含n个token的文本，理论上共有  种片段排列）,所以通常会通过限制span的长度来解决。

2. 关系分类模型

• 如上图所示，对所有的实体pair进行关系分类。其中最重要的一点改进，就是将实体边界和类型作为标识符加入到实体Span前后，然后作为关系模型的input。例如，对于实体pair（Subject和Object）可分别在其对应的实体前后插入以下标识符：
  • <S:Md>和</S:Md>：代表实体类型为Method的Subject，S是实体span的第一个token，/S是最后一个token；
  • <O:Md>和</O:Md>：代表实体类型为Method的Object，O是实体span的第一个token，/O是最后一个token；

对于关系模型，对每个实体pair中第一个token的编码进行concatenate，然后进行SoftMax分类。

需要特别指出的是，上述实体模型和关系模型采取的两个独立的预训练模型进行编码（不共享参数）。

对于这种关系模型，我们不难发现：对每个实体pair都要轮流进行关系分类，也就是同一文本要进行多次编码，不是one-pass的关系抽取，计算开销必然会很大。

3. 近似模型

为解决这一问题，提出了一种加速的近似模型（如下图所示）：可将实体边界和类型的标识符拼接到到文本之后，然后与原文对应实体共享位置向量。上图中相同的颜色代表共享相同的位置向量。具体地，在attention层中，文本token只去attend文本token、不去attend标识符token，而标识符token可以attend原文token。综上，通过这种「近似模型」可以实现一次编码文本就可以判断所有实体pair间的关系。

此外，由于跨句信息可用于帮助预测实体类型和关系（尤其是在代词性提及中），所以还通过简单方式引入了跨句信息，即文本输入的左右上下文中分别滑动( − )/2(W−n)/2个words， n为文本长度， W 为固定窗口大小。

四、实验结果

上图给出了各个关系抽取榜单的对比结果（梅花图标代表引入了跨句信息，Rel+为严格指标），可以看出：

1. 不使用跨句信息(单句设置)就超越了ACE04/ACE05曾经的SOTA（使用同一预训练模型），使用跨句信息更是了不得啊。
2. 使用跨句信息登顶了SciERC（文档级）的SOTA；

而上图也给出了加速版「近似模型」的效果，可以看出：

1. 在单句设置中，ACE05和SciERC分别提速11.9倍和8.7倍，而指标仅仅下降0.5%和1.0%。
2. 「近似模型」加速明显（划重点）：我们先不要考虑是不是SOTA的事情，这个「近似模型」one-pass编码的的方式就足够让我们眼前一亮，这种方式与预训练模型兼容的恰到好处，权衡性能和准确性，相信在实际应用中具有重要意义！

以上就是这篇paper的模型介绍

五、总结与分析

pipeline为何如此强悍，是哪些因素让它可以“秒杀”众多joint模型？论文对关系模型其关键作用的因素做了探究。

首先分析了不同实体表征方式的影响，文中设计了6中实体表征的方式：

• TEXT：直接提取原始文本中，实体span所对应的编码表示。
• TEXTETYPE：在TEXT的基础上，concatenate实体类别向量。
• MARKERS：将标识符S、/S、O、/O插入到原始文本中，但是标识符没有实体类别信息。
• MARKERSETYPE：在MARKERS的基础上，concatenate实体类别向量，这是一种隐式的融入实体类别的方法。
• MARKERSELOSS：在关系模型中，构建判别实体类别的辅助loss。
• TYPEDMARKERS：就是本文所采取的方法，实体类别“显式”地插入到文本input中，如<S:Md> 和</S:Md>、<O:Md>和</O:Md>。

如上图所示（关系模型的实体是gold输入），我们可以发现：

1. 本文采取的TYPEDMARKERS,即实体类别信息“显示”地插入到文本中的实体表征方式，秒杀其余方式；
2. 实体类别信息对关系模型很重要，“显式”地编码实体类别信息好于隐式编码；在构造标识符时，不仅要区分span边界、更要显示融入实体类别信息。
3. MARKERSETYPE比MARKERSELOSS好，说明直接引入实体类型特征好于辅助loss的设计。

实体边界标识符加入到文本中来强化实体表征的这一idea，在之前Google的工作中《Matching the Blanks: Distributional Similarity for Relation Learning》就有所体现。

 

只是Google这个工作没有引入实体类型信息进行标识。这更能证明了实体类别信息对于关系模型很重要。

另外这篇文章并没有基于参数共享编码的joint模型来建模实体和关系的交互、促进彼此，而是实体抽取和关系分类任务采取了两个独立的编码器老构建实体模型和关系模型。论文也做了相关的对比实验

可以看出共享编码反而使实体和关系的F1都下降了，文中也解释道：这是由于两个任务各自是不同的输入形式，并且需要不同的特征去进行实体和关系预测，也就是说：使用单独的编码器确实可以学习更好的特定任务特征。对于实体和关系确实需要特定的特征编码，在构建joint模型时如果只是简单的强行共享编码，真的可能会适得其反。

最近EMNLP20的一篇《Two are Better than One:Joint Entity and Relation Extraction with Table-Sequence Encoders》（这篇SOTA之前的SOTA）也认为：大多数joint模型都是共享同一个编码，但这种方式存在一个问题：针对一项任务提取的特征可能与针对另一项任务提取的特征一致或冲突，从而使学习模型混乱。于是乎，作者设计了2种不同的编码器（表格编码器和序列编码器），以在表示学习过程中互相帮助，最后通过实验表明使用2个编码器好于只使用1个编码。

还有一点就是对于pipeline模型的误差传播问题。关系模型在训练的时候，输入的是gold实体进行关系判断，这会导致训练和推断时候的差异（暴露偏差）。那是不是在训练的时候输入预测的实体进行关系判断，会在推断时效果变好呢？于是论文采用10-way jackknifing方式（一种交叉验证）做了相关实验，发现训练时输入预测实体反而降低了F1值，毕竟这种方式会在训练的时候引入噪音。

采取pipeline进行推断时，如果有些gold实体在实体模型中没有被抽取出来，那么关系模型也就不会预测与该实体相关联的任何关系了。那有没有可能通过召回更多的实体，来减轻这种误差传播呢？论文也尝试召回更多的实体进行了实验，发现并没有提升F1值。

对于pipeline模式的误差传播问题，COLING2020的一篇paper为了缓解这个问题，提出了一种单阶段的联合提取模型 TPLinker ，其不包含任何相互依赖的抽取步骤，因此避免了在训练时依赖于gold的情况，从而实现了训练和测试的一致性。

六、思考

通过这篇论文的工作，我们可以得到一些关系抽取模型的trick：

• 引入实体类别信息会让你的关系模型有提升～
• 对于实体关系抽取，2个独立的编码器也许会更好～

 

当然还有一些需要我们进一步思考或解决的问题：

• 怎么减轻/避免误差传播呢？
• pipeline是不是推断效率还是慢？比如，还是会存在冗余实体的计算？
• 落地场景中，是不是pipeline更容易迭代优化呢？

 

参考：

https://zhuanlan.zhihu.com/p/274938894