DocRED: A Large-Scale Document-Level Relation Extraction Dataset 阅读笔记

DocRED: A Large-Scale Document-Level Relation Extraction Dataset

笔者自述:
DocRED主要是提出了一个全新的数据集,以往的Relation Extraction主要集中在 single sentence之中的(intra-sentence),而有些event或者说relation并不仅仅narrow在这个范围,可以会跨越好几个句子,段落,甚至达到整个文章的级别。因此,作者Yuan Yao提出了DocRED针对这样的现象提出了新的数据集,并在上面开展了初步的工作与公开了方法。

Abstract

该数据集来自Wikipedia和Wikidata. 有3个特征

  • DocRED同时标注了named entity与relations. 并且是目前为止最大的 document-level RE数据集
  • DocRED推断关系需要阅读多个句子并且综合整篇document来进行。
  • 在人工标注数据的同时,我们也标注了大量弱监督性数据,使数据可以被用于监督学习和弱监督学习。

为了度量document-level RE的难度与挑战性,作者实现了大量最近的在句内所做的SOTA方法并使用了完整的度量方法
基于数据集和目前通用的数据集,我们总结出了大量未来的研究方向。
代码:https: //github.com/thunlp/DocRED.

Introduction

  • RE在大规模知识图谱构建中有非常重要的作用。
  • 大部分现有的工作集中在sentence-level上
  • 近年来有很多neural models在sentence-level上有SOTA性能
    然后,尽管性能非常优异,在实际生活中依然有着不可避免的局限性,因为很多relation是存在于多个句子中的。如下两个例子。

Figure 1中的两个relation

其中 Riddarhuset 是 in Stockholm的( 在sentence 4
并且 Stockholm 是 Sweden的capital( 在sentence 1
这样递推才可得,Riddarhuset 的 country是 Sweden
所以evidence是1,4

但是第一个relation我个人觉得有点问题,因为仅从第五句话来说并不能得到Royal Court Orchestra是属于 Royal Swdish Opera的。evidence需要加上sentence 1才可以得到 Kungliga Hovkapellet 是 Royal Court Orchestra.

DocRED: A Large-Scale Document-Level Relation Extraction Dataset 阅读笔记
至少存在40.7%的关系只能从多个句子中抽取出来

document level的数据集其实还是有的

  • Quirk and Poon 2017 和 Peng et al. 2017 使用自动化标注, 验证不可靠。
  • BC5CDR只考虑 chemical-induced disease. 很难在这个数据集上开发普适性的方法
  • Levy et al. 2017 在QA问题中解决包含了 document-level RE,却不能使用 专门的document-level RE的方法。
  • 现存的数据集不是人工标注数据量太小,就是标注有误差,或者仅适用于专门的领域与方法。
    large-scale, manually-annotated, general-purporse

Data Collection

Human-Anootated Data Collection

数据收集有4个Stages:

  • 1.为wikipedia documents生成弱监督标注
  • 2.标注文档和引用中所有的named entity
  • 3.链接named entity与wikidata items
  • 4.标注关系与对应的证据

与ACE一样,Stage2和4需要用3个迭代的步骤

  • 1.使用NER模型生成named entity或者 使用RE模型 relation recommendations
  • 2.人工纠正和补充relation
  • 3.检查和进一步修改数据

为了确保步骤1中的NER或者RE模型训练的足够优秀,annotator在开始标注之前需要通过测试,只有达到性能要求才可以开始标注。
只使用wikipedia document中的introductory section作为语料库,因为高质量与包含基本信息。

Stage1: Distantly Supervised Annotation Generation

  • 使用 spaCy 实现NER,再将entity连接到Wikidata items,有相同Knowledge Base IDs的entity将会合并。在合并了的entity pair中的relation将会通过搜索wikidata来进行标注。
  • 文档少于128字,少于4个entity或者少于4个relation的,全部不要,保留107050个文档,使用spaCy 进行弱标注。
  • 在107050个文档中,随机选取5053个document使用人工标注。

Stage2: Named Entity and Coreference Annotation.

  • 为了提供高质量的共同引用信息和named entity,进行人工检查。
  • 现在的数据集是一个中间状态,因为既有一大堆的链接状态,也有很多的entity

Stage3: Entity Linking

  • 链接每一个entity至多个Wikidata items,再下一个阶段会有relation recommendation. 每一个entity都有一个wikidata items数据集,至少是名字完全匹配上的。 (为什么要这么做? 有什么意义)
  • 使用entity linking toolkit TagMe.

Stage4: Relation and Supporting Evidence Collection.

  • entity pair太多了(每一个entity pair之间都可以存在关系?—)
  • relation types太多了
    RE方法提供一些relation的推荐和弱监督标注 entity linking(使用多个entity linking的方法)(类似于Figure 1 的relation 1的subject吗?),然后人工基于此标注。

每篇document 需要19.9个relation推荐, 7.8个RE supplement

是用人来选取 supporting evidence的

Distantly Supervised Data Collection

将人工标注数据移出弱标注数据,为了确认有同样的entity和relation分布,使用BERT进行确认。
使用同样的KB IDs合并named entity.
最后通过弱监督的方式合并entity pair

Data Analysis

Data Size

在 documents, words, sentences,entities,特别是relation种类的数量上,都要比现存的数据集要大。

Named Entity Types

有非常多的entity types 常见的person,location,organization,time and number此外还包含了非常多杂项的named entity type 像event,laws等等。

Relation Types

96个常见的relation type,非常广泛的范围
并且良好的定义为了层级与同义语,非常适合document-level的RE system.

Reasoning Types

并不明白reasoning types是怎么定义的,没有找到。

Inter-Sentence Relation Instances

平均每个relation需要1.6个句子的支撑。46.4%的句子需要超过一句以上的支持句。

数据集已经介绍完了,实验部分不赘述。(写写太麻烦了,反正也没什么人看,细节都在下面。)

entity mention 的计算方式通过:

对于每一个entity mention
(从第s个word到第t个word)mk=1ts+1j=stm_k = \frac{1}{t-s+1}\sum_{j=s}^{t}
对于意指同一个entity的representation
ei=1Kkmke_i = \frac{1}{K}\sum_{k}m_k

问题:

  1. Section3中,并不明白reasoning types是怎么定义的,全网没有找到。
  2. 在Table 3中的Setting为什么既有S又有W?(第3,4两行), 照理来说 文中提到 ”We remove the 5,053 human-annotated documents from the 106,926 documents, and use the rest 101,873 documents as the corpus of distantly supervised data.“的话,W setting的情况下,测试不应该包含这些句子了。但是应该问题不大吧,毕竟都确认过是same entity distribution了。
    3.需要再去focus一下 具体的过程
    我觉得其实stages之间没有很明显的gap
    DocRED: A Large-Scale Document-Level Relation Extraction Dataset 阅读笔记

已解决的自问自答和想法

猜测是通过 human annotated BERT,然后再去标注 distantly supervised data?

  • 并不是的,只有entity type embedding,human annotated就用人来区分id然后mapping到vector space,而distantly supervised data就是用

Evaluation Metrics处把训练集和测试、dev集中的overlap sample去除了,避免了 evaluation bias,非常nb

实验部分做了不同的feature ablation study. 就是看将不同的,concate起来的embedding进行删除等等。

And the entity ids are mapped into vec- tors as the coreference embeddings.

  • 这句话的意思我读出来就是,可能两个entity的mention不同,但其实指的是同一个entity,那么这两个entity mention的 coreference embedding会是相同的。

文中基本的方法其实都是先做entity extraction然后再去对entity pair(每个entity已经通过了entity linking的计算,通过 entity mention的计算方式(本文中aforementioned))进行一个BCE loss的计算。是常规的relation extraction方式。公式在文中是(1)和(2) 非常简单。
因为跨越句子了,所以entity会非常非常的多,而且任何两个entity之间都可能存在relation(每两个pair都需要通过公式来计算存在relation的概率,这会大大增加计算复杂度(原本的intra-sentence之间的relation并不会存在这样的问题,一个句子也没几个entity嘛))

自己感觉能做的工作:

先说一句,虽然这文章一直在说提供了非常多的future direction,但是并没有future work这个section,文中其他地方也没有明显提示。无语

自己能感觉做的,我觉得可以考虑提高计算效率来看。具体的思路,和传统方法的改进,需要将papers to read finish了,才能了解relation extraction上具体的改进和方法。

看完这篇文章需要增加阅读的论文:

  • 文中所做实验的CNN的那个
  • 文中所提到的context-aware