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.

至少存在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） $m_k = \frac{1}{t-s+1}\sum_{j=s}^{t}$
对于意指同一个entity的representation
$e_i = \frac{1}{K}\sum_{k}m_k$

问题：

Section3中，并不明白reasoning types是怎么定义的，全网没有找到。
在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

已解决的自问自答和想法

猜测是通过 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

【论文笔记】DocRED: A Large-Scale Document-Level Relation Extraction Dataset