笔者自述:
DocRED主要是提出了一个全新的数据集,以往的Relation Extraction主要集中在 single sentence之中的(intra-sentence),而有些event或者说relation并不仅仅narrow在这个范围,可以会跨越好几个句子,段落,甚至达到整个文章的级别。因此,作者Yuan Yao提出了DocRED针对这样的现象提出了新的数据集,并在上面开展了初步的工作与公开了方法。
该数据集来自Wikipedia和Wikidata. 有3个特征
- DocRED同时标注了named entity与relations. 并且是目前为止最大的 document-level RE数据集
- DocRED推断关系需要阅读多个句子并且综合整篇document来进行。
- 在人工标注数据的同时,我们也标注了大量弱监督性数据,使数据可以被用于监督学习和弱监督学习。
为了度量document-level RE的难度与挑战性,作者实现了大量最近的在句内所做的SOTA方法并使用了完整的度量方法
基于数据集和目前通用的数据集,我们总结出了大量未来的研究方向。
代码:https: //github.com/thunlp/DocRED.
- 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.
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
数据收集有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作为语料库,因为高质量与包含基本信息。
- 使用 spaCy 实现NER,再将entity连接到Wikidata items,有相同Knowledge Base IDs的entity将会合并。在合并了的entity pair中的relation将会通过搜索wikidata来进行标注。
- 文档少于128字,少于4个entity或者少于4个relation的,全部不要,保留107050个文档,使用spaCy 进行弱标注。
- 在107050个文档中,随机选取5053个document使用人工标注。
- 为了提供高质量的共同引用信息和named entity,进行人工检查。
- 链接每一个entity至多个Wikidata items,再下一个阶段会有relation recommendation. 每一个entity都有一个wikidata items数据集,至少是名字完全匹配上的。 (为什么要这么做? 有什么意义)
- 使用entity linking toolkit TagMe.
- 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的
将人工标注数据移出弱标注数据,为了确认有同样的entity和relation分布,使用BERT进行确认。
使用同样的KB IDs合并named entity.
最后通过弱监督的方式合并entity pair
在 documents, words, sentences,entities,特别是relation种类的数量上,都要比现存的数据集要大。
有非常多的entity types 常见的person,location,organization,time and number此外还包含了非常多杂项的named entity type 像event,laws等等。
96个常见的relation type,非常广泛的范围
并且良好的定义为了层级与同义语,非常适合document-level的RE system.
并不明白reasoning types是怎么定义的,没有找到。
平均每个relation需要1.6个句子的支撑。46.4%的句子需要超过一句以上的支持句。
对于每一个entity mention
(从第s个word到第t个word) m k = 1 t − s + 1 ∑ j = s t m_k = \frac{1}{t-s+1}\sum_{j=s}^{t} mk=t−s+11∑j=st
对于意指同一个entity的representation
e i = 1 K ∑ k m k e_i = \frac{1}{K}\sum_{k}m_k ei=K1∑kmk
猜测是通过 human annotated BERT,然后再去标注 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 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