Span-based Joint Entity and Relation Extraction with Transformer Pre-training

作者：Eberts et al., ECAI 2020.

目录

• 简介
• 模型
• 实验
• 总结

1 简介

本文基于BERT做实体关系联合抽取任务。其中，比较关键的点我觉得除了BERT编码之外，主要是local-context的加入以及可能加入negative采样也有些作用。

2 模型

如下图1所示为模型的整体结构，清晰明了。

• BERT对输入语句分词、编码
• span类型预测：对span内(span width < L)的所有token做maxpool操作聚合信息得到红色的span表示，同时将其与蓝色的训练学到的span width embedding以及special token [CLS]的embedding拼接作为span分类器(简单的softmax全连接分类器)的输入，进而预测每个span的类型
• 关系类型预测：将红色span表示、蓝色width embedding拼接以及黄色的local context(即span pairs之间的所有token经过max pooling后得到的表示)拼接作为关系分类器(简单的二分类器，针对每个关系的得分大于某个阈值即代表当前实体对有此关系)的输入，进而进行关系分类，同时考虑方向性，需要对同一对实体正反预测两次。
• 除此之外，作者在训练过程中，无论是实体分类还是关系分类，都选取gold sample之外的，no relation的实体对/no entity的span，作为negative sample加入训练。
• 训练对两个分类器的损失一起计算即\(\mathcal{L}=\mathcal{L}^{s}+\mathcal{L}^{r}\)。
• 补一下忘记说了：span filtering这里是采用两种过滤：一是限制span长度，因为是span-based的嘛应该就是嵌套排列判断每个span这要是不限制span长度复杂度太高了；二是将非entity span去掉，但这里我不太理解，这里去掉了后面训练又加入了negative 采样，对于实体分类部分加入的还是gold entity span外的无意义的span啊，这个negative sample还有其他的意思？而且即便加负采样是怎么加的得看看代码。

3 实验

数据集：CoNLL04、SciERC、ADE。

• 对比多个sota包括DyGIE/DyGIE++依旧稳占上风无论是实体类型还是关系分类的结果，如Table 1所示。

• negative sampling还是有一定的效果的
• 结合localized context对关系类型的判断有很大帮助，而且多种不同方式获取的localized context对比，发现还是取span pairs之间的token context效果最好。

4 总结

• 这篇paper模型简单有效，也证明实体加入能够辅助模型判断的实体周围的context信息是很有用的。

• 这篇和(Zhong et al., NAACL 2021)\(^{[2]}\)极其相似，两者时间上都差不多可能这篇还要稍微早些。不同点在于这篇是两个子任务联合训练，而(Zhong et al.,2021)这篇是pipeline方法做联合抽取这是一点不同。另外两者的核心点不同(除了BERT之外)，本文我个人认为local context起了很大作用对于关系分类以及[CLS]整个sent的context信息对实体的分类也是有用的(两者均加入了span width embedding)，而(Zhong et al.,2021)这篇关键点在于NER子任务做完之后，将实体的类型信息以special markers的形式直接插入每个span的前后标识span同时加入的实体类型信息，起了很大作用在关系分类上。也就是说(Zhong et al.,2021)没用local context以及[CLS]的信息也没用如果我没记错的话，而对于关系分类来说很重要的实体类型信息本文也没用，(这两点是不是可以考虑一下？)但最后结果，但就SciERC吧其他数据集不一样，评估的标准可能也稍微有些出入因为本文没说entity span以及relation type判断正确的标准，(Zhong et al.,2021)这篇说了，这里也贴一下(Zhong et al.,2021)这篇的实验结果如下图，其中SciERC数据集F1结果。

• 对于负采样问题，我感觉就是类似(Zhong et al.,2021)这篇里代码实现的时候在如SciERC原有的实体和关系类型下加的no span、no relation类型，就是在数据集中没有此span以及两个entity span构成的entity pair没有对应的关系就归到这一类里，挺像的，不知道我对于本文的这个negative sample理解的对不对，而且这里的negative sample在本文作者的另一篇又用到了--(Markus Eberts and Adrian Ulges.EACL 2021)\(^{[3]]}\)，是本文future work的延申？延申的这篇是做doc-level的联合抽取了也挺好的，好像是第一个做doc-level联合抽取的？按照他paper里自己说的。

• 这两篇整体结构其实都很简单，但效果出奇的好，所以不是说模型越复杂就越好，相比那些基于GCN图结构的模型结构要简单很多，但同时性能却不差，两个模型均在多个数据集均达到sota，所以也不是说模型越复杂效果就一定好。

ToDO

• 回顾一下(Markus Eberts and Adrian Ulges.EACL 2021)\(^{[3]]}\)这篇
• 本文paper的代码大致看看？pipeline的那个代码实现没问题了，联合训练的怎么实现的简单看看。

补

span过滤两种:

1)限制span长度

2)直接将非gt(ground truth)的span去掉此操作只针对mode=evaluate

负样本(negative sample):采样或者说数据处理大致逻辑为

首先解析数据集(如conll04经过作者处理后转换为json格式，一行可以看作是一个doc以字典形式存储，其中每个字段信息即为如实体关系的位置信息)，将整个数据集中各个字段信息封装到Dataset类中的自定义属性中(后续也要将ground truth的实体关系信息封装到Evaluator自定义类属性中便于后续计算损失)。此时只是将数据集中给定的信息解析存储，采样才是根据数据集中的tokens字段即doc语料获取训练或评估的数据。

其次，采样是在加载数据时处理的即使用Dataloader加载数据，由于Dataloader与Dataset类之间的关联性，加载数据时通过dataloader中的collate_fn属性来自定义对数据的处理，collate_fn传的参数为函数，此函参的输入即为Dataset中__get_item__的输出，采样则是在get_item中调create_train_sample/create_eval_sample函数(根据mode)完成。其中，以span采样为例，使用嵌套排列获取所有可能的span(有长度限制)，此时获取的span可能既有正样本即确实是entity span也有负样本即不是entity span，那么至此为eval采样。但尽管我们确实希望训练时有些负样本但我们想要的是可控的负样本如负样本数量等，尽管之前的嵌套排列获取所有可能的span可以拿到负样本但样本不可控，所以对于train样本采样我们手动操作，先拿到所有的正样本根据doc.entities，之后再嵌套排列获取span，判断是否再正样本中若不在则是负样本，将其加入负样本中，那么至此train/eval的采样和数据加载结束。

之后，run model (forward pass, model=train/eval, forward中对应不同的处理)，对于eval，执行self._forward_inference对实体和关系进行分类，其中在做关系分类时要先做一步处理即span过滤，因为上一步可知eval的样本是有负样本的，所以span过滤就是直接将负样本即直接引下注释ignore entity candidates that do not constitute an actual entity for relations (based on classifier)，之后再去做关系分类。对于train，我们就直接用采样的样本训练就可以了。最后将预测的实体和关系与Evaluator中的gt_entities、gt_rels计算交叉熵损失。

最后，将两个损失加在一起实现联合训练，#joint loss train_loss = entity_loss + rel_loss, train_loss.backward()反向传播梯度更新参数进行训练。

参考

[1] Markus Eberts.Adrian Ulges.Span-based Joint Entity and Relation Extraction with Transformer Pre-training.ECAI 2020.

[2] Zexuan Zhong Danqi Chen.A Frustratingly Easy Approach for Entity and Relation Extraction.NAACL 2021.

[3] Markus Eberts.Adrian Ulges.An End-to-end Model for Entity-level Relation Extraction using Multi-instance Learning. EACL 2021.