写点什么

复杂语境下的实体关系抽取

  • 2021-08-07
  • 本文字数:5660 字

    阅读完需:约 19 分钟

复杂语境下的实体关系抽取

实体关系抽取是知识图谱构建过程中的一个重要环节,同时也是信息抽取中的一个主要任务。近年来,该课题受到了学术界与工业界研究者们的广泛关注,其主要包含多个子任务,如关系分类、远程监督关系抽取等。今天的分享主要为实体关系联合抽取与文档级关系抽取,可将它们归结为复杂语境下的实体关系抽取。

实体关系抽取任务介绍


一般情况下,我们将关系定义为两个或多个实体间的某种联系,而实体关系抽取旨在自动发现实体间存在的某种语义关系。在上图中,我们可以判别出“乔布斯(人)”和“苹果(公司)”之间有一种创始人关系。



传统的实体关系抽取我们称之为简单语境,其主要针对一个句子中的两个实体之间的语义关系特征,在这种语境下会忽略其他实体或者关系的影响。而复杂语境通常包括两种,如上图中所列出的:(1)同一个句子中多个三元组之间相互影响;如上图(左),Donald J. Trump 和 Queens 之间有 Born_in 关系,Queens 和 New York City 之间有 Located_in 关系,那么也可以推断出 Donald J. Trump 和 New York City 之间有 Located_in 关系;(2)大量的实体间关系是通过多个句子表达的,其主要涉及多个实体间的跨句关系抽取。上图(右)为从清华大学刘知远老师团队发布的 DocRED 数据集上所获得的截图,在发布该数据集时有进行简单的统计,统计结果表明:在维基百科数据集人工标注的结果中,至少有 40%实体关系相关的事实只能从多个句子中进行联合抽取。

实体关系联合抽取


对于实体关系联合抽取任务,目前有较多的框架/方法类别,如基于序列标注的方法,基于表填充的方法,序列到序列的方法,多任务学习的方法等,以下我们将就三类方法进行展开介绍。

1. 基于序列标注的方法


对于序列标注的方法,不得不提 2017 年在 ACL 上发表的一篇文章《Joint Extraction of Entities and Relations Based on Novel Tagging Scheme》,(当时这篇文章也获得了 Outstanding paper)。在上述 NovelTagging 方法中,作者提出了一种新的关系标注模式(Relation tagging schema),对于每种关系,将其与(Begin, Inside,End,Single)以及头实体和尾实体的序号(1,2)组会起来进行关系抽取,并根据最后的标注结果进行解码,进而得到关系三元组。再者,该方法额外考虑了一个 Other 标签,主要表示不属于任何一种关系。如果总共有|R|种关系,那么一共就有 2*4*|R|+1 个标签。



在上述方法中,作者也尝试了一系列经典的序列标注框架,如 LSTM+CRF,其中 CRF 善于捕捉近距离的标签依赖,而 LSTM 可以捕捉长距离的标签依赖。在此基础上,由于 LSTM 可以堆叠之前所有时刻的隐状态,所以我们在 Encoding-Decoding 框架的 Decoding 层同样采用 LSTM 结构,如上图(左);再者,考虑到 other 标签也占据较大的比例,所以作者加入损失因子(即 Bias weight)以对 other 标签的重要程度进行设置。



在实验中,作者选择 NYT 数据集,并将其看作是监督数据(即已标注的数据),通过在 24 种关系上进行尝试,实验结果表明:该方法的 F1 值并不是特别高,但是验证了该方法在处理关系抽取问题上的可行性,同时也为基于该方法的改进模型留下了空间。



在做实体关系抽取任务时,我们可以将关系三元组划分为 Normal、EPO 和 SEO 三种类型(也被称为关系重叠三元组)。EPO(Entity pair overlap)指的是两个实体之间存在不止一种关系类型;SEO(Single entity overlap)指的是一个实体同时参与了两个关系三元组。NovelTagging 模型能够较好地处理 Normal 三元组,然而却无法有效适应 EPO 和 SEO 的三元组情况。这是因为基于序列标注的方法只能为每个文本单词打上一个标签(即 N 输入 N 输出),所以这类模型不能同时处理 EPO 和 SEO 三元组。



基于 NovelTagging 模型,Wei 等人设计了一种名为 Hierarchical Binary Tagging 的模型,将关系三元组的抽取任务建模为三个级别的问题,从而能够更好解决三元组重叠问题。该方法不再将关系抽取的过程看作是对实体对离散标签的预测过程,而是将其看作是两个实体的映射过程。

2. 基于表填充的方法


第二类实体关系联合抽取的方法是基于表填充的方法,该类方法最早于 2014 年提出(请见 EMNLP’2014 上的《Modeling Joint Entity and Relation Extraction with Table Representation》)。在上图中,对角线元素用于填充实体标签(即通过命名实体识别后的结果),下三角元素用于填充关系(可被视为一个 softmax 的分类)。我们发现该方法存在一个明显的问题,即表格中每个单元格只能有一个标签,不能抽取 EPO 三元组。


基于表填充工作的一项较好的改进为多头选择工作(请见《Joint recognition and relation extraction as a multi-head selection problem》)。如上图所示,这个模型的框架看上去好像和表格填充没有太大的关系,实际上,这是一种多任务的框架。具体而言,该模型首先在 BiLSTM 的基础上使用 CRF 进行序列标注,找到实体。然后,将句子中的词进行排列组合;最后结合 LSTM 学习到的特征,标签的特征,将它们送到 sigmoid 分类器中,进而判断实体之间的关系。之所以将这项工作归结为表填充的类别,是因为该模型在进行两两词的组合过程中,就像表格中将一个词作为横纵坐标上的索引,进而填充该索引位置中的类别标签这一情形一样。值得一提的,为了使该模型能够支持上述提到的 EPO 和 SEO 情况,在进行关系分类(即表格填充)时,使用的是 Sigmoid 函数,允许两个词之间的多关系标签存在,因此可以解决关系重叠的问题。

3. 序列到序列的方法


然后介绍我们的工作 CopyRE,在该工作中,我们将关系三元组的抽取问题看成是序列到序列的生成问题,即根据输入的句子,借助于机器翻译的想法,将三元组看成是一个翻译的序列。在使用 Encoder-Decoder 框架时,在输出结果中可能会有部分实体不在输入的句子中,这是因为我们是立足于整个语料库来构建的词表,并将其作为 Decoder 的预测对象。因此,我们借助于拷贝机制,直接从源句中找到实体对象。与 NovelTagging 模型相比,我们的模型取得了性能的提升。



在 CopyRE 模型中,我们发现在进行拷贝时,主要是在控制实体的最后一个词(token),当头实体和尾实体是由多个 token 构成时,得到的关系三元组结果是不完整的。为了解决上述问题,我们提出了 CopyMTL 模型,该模型通过序列标注方法(Sequence-Labelling)来识别由多个词构成的实体,并增加非线性变换,改进了拷贝函数的计算方式,进而解决了实体拷贝不全的问题。



上述也是我们自己的工作,该工作的出发点在于:

(1)在序列到序列的标注方法(Seq2seq)中,一个固有的问题是:由自回归解码而导致的标记偏置问题,即在解码第一实体时,依赖于 start 标记;解码第二个实体时,依赖于第一个实体是什么,以此类推。如果解码过程中的某一步出现了错误,就会导致后续的解码过程不准确;因为在训练时,我们有正确的标签(ground truth),而测试时就没有了正确标签的指导,生成的标签不可避免的会出现一定的错误。因此,标记偏置是一类比较严重的问题;

(2)模型强制学习训练数据中三元组的先后顺序。如上图,例如,当模型在抽取得到“graduate_from”关系后,发现其与另外一种关系共现,进而就会再抽取这种关系,而将“graduate_from”关系遗忘。



为解决上述两方面的问题:我们提出了 Seq2UMTree 模型。该模型的逻辑框架如上图所示,其建模动机在于:(1)我们考虑是否能通过缩短解码长度来解决标记偏置问题;(2)我们在解码时,不考虑三元组之间的关系,而是采用树状结构的解码方式。在树状结构的第一层中,我们先预测有哪几种类型的关系;在第二层中,找到头实体开始(start)与结束(end)的位置;在第三层中,再找到尾实体开始(start)与结束(end)的位置。该方法取得了比较好的性能效果。在这个工作中,无论句子中有多少个三元组,我们的解码器最多只有三层(即最多可为 3 个时间步长(time step)进行解码),这样可以避免:如果解码的 time step 越多,标记偏置的问题可能会越严重。

文档级关系抽取


下面给大家介绍本报告中第二个系列的工作,即文档级关系抽取。上图为 DocRED 数据集中的一个例子。



文档级关系抽取的关键在于:

(1)如何有效的建模实体的多粒度信息,其主要包括 2 点:(a)如上图中,同一个实体可能在多个句子中出现(即实体在多个句子中的提及);(b)在文本写作中,自然出现的实体指代问题;

(2)如何建模文档内的复杂语义信息,其主要涉及多个方面的推理,如逻辑推理、指代推理和常识知识推理等。



早期的文档级关系抽取主要是基于句子级别的抽取,再进行聚合操作。这里,我主要介绍基于图神经网络来完成上述任务的若干工作,第一个工作发表在 ACL 2019 上(请见《Inter-sentence Relation Extraction with Document-level Graph Convolutional Neural Network》),作者提出的模型被称为 GCNN,主要的建模过程包括:

① 使用图神经网络来建模文档:在构建文档时,将输入文档中的每个词作为图中的一个节点,通过不同类型的边对整个文档的结构进行表示。如上图所示,作者用句法依赖标签建立句子中单词之间的远距离依赖;用指代消解工具将具有指代关系的词进行连接;将句子中相邻的两个词也连接起来;将句子中当前词的前后节点连接起来;最后将词本身进行连接。连接完成后,便构建出了一个图结构。

② 在下一步中,基于构建好的文档图,使用 GCNN 来学习节点之间的信息交互/传递,计算得到每个节点的表示。这样,不同句子中的不同提及都会得到表示。

③ 最后,通过多示例学习的方式聚合目标实体的所有提及并进行关系分类。



实验在 CDR 和 CHR 数据集上完成,并取得了较好的效果。特别要指出的是消融实验的结果,如上表所示。实验结果表明:大部分构建的边对模型效果能起到提升的作用,而指代的边并不影响句子内抽取,对于跨句子间的抽取确能起到重要的作用。



第二个工作也是同一批作者完成的,所提出的模型叫做 EOG(请见 EMNLP’2019《Connecting the dots: Document-level neural relation extraction with edge-oriented graphs》)。现有的方法主要使用基于图的模型,以实体作为节点,根据两个目标节点来确定实体间的关系。然而,关系是两个节点之间的核心,实体关系可以通过节点间路径形成的唯一的边表示来更好地表达。EoG 通过在不同类型的节点之间建立不同类型的边来决定信息流入节点的多少,如此可以更好地拟合文档之间异构的交互关系。



在 EOG 中,作者主要采用启发式的方法来构建图结构,图中的节点有实体提及、实体和句子,边主要包括:提及到提及(mention-mention, MM)、提及到实体(mention-entity, ME)、提及到句子(mention-sentence,MS)、实体到句子(entity-sentence,ES)和句子到句子(sentence-sentence,SS)之间的关系。构建好图之后,下一步就是推理处理。与使用 GCN 来进行推理不同,这里主要是训练连接两个实体之间的路径,多次迭代加权该路径上的信息,如上图(右)所示,从而将路径上的信息进行传递,起到推理的效果。



从实验效果上来看,与对比方法相比,EoG 模型取得了最好的效果。值得一提的是,EoG(full)表示的是一种全连接的图,EoG(NoInf)表示不采用在图中游走的策略,EoG(Sent)表示以句子级别来构建的图。实验结果表明,在构建文档级别的图结构时,跨句推理非常关键。另外,图的结构也非常重要,构建全连接图的方法与使用启发式的规则、有目的地构建图的方法(即 EoG 方法)的差距也很大。



基于上述工作,我们发现图的结构非常重要。这里介绍 ACL 2020 年的一项工作,即 LSR 模型(请见《Reasoning with latent structure refinement for document-level relation extraction》),这个工作的动机主要是:图的结构是否也可以从大量文本中进行学习?作者据此提出:将图结构视为一个潜在的变量,并且以端到端的方式对其进行归纳推理。即在初始建图时,可以采用随机初始化或其它方式来完成;后续每一步迭代都将该图进行修正,进而得到最终的结果。



从实验效果来看,通过与 GCNN、GAT、AGGCN 等方法进行对比,在 LSR 模型中,通过自动学习图结构的方式也取得了非常好的效果。



我认为,在文档级关系抽取中一项有意思的工作来源于北京大学(请见 EMNLP’ 2020《Double Graph Based Reasoning for Document-level Relation Extraction》),被称为 Double Graph。我们一直在讲,文档级关系抽取中最重要的包括:如何对文档进行建模以及如何进行关系推理。在 Double Graph 中,作者将以上两个部分分隔开,第一个部分是在提及级别的图(mention-level graph)上进行 GCN 或随机游走,进而完成图中的信息传递与推理。如上图(左),不同的颜色区域代表不同的句子,由于圆圈 2 表示的实体在多个句子中出现,故我们可将它们连接起来;一个句子中出现的所有实体也被连接起来。第二部分是比较创新的一个部分,即实体级别的图(entity-level graph),它是将所有提及级别的节点进行加权。在考虑两个实体之间的关系时,将它们的连接路径也考虑在内,并且进行压缩。最终在识别两个实体之间的关系时,将上述压缩后的向量送入 MLP 网络进行关系分类。



Double Graph 模型与之前提到的一系列模型(如 GAT、GCNN、EoG、LSR 等)进行了对比,取得了优质的效果。

总结与展望

简单总结一下,上述报告主要围绕联合抽取和文档级别抽取两方面工作进行介绍。在联合抽取中,主要从序列到序列的角度进行展开。我们认为该方向仍有一系列的工作可以深入地去做。在之前的讲述中,我们一直提到标记偏置的问题,虽然 Seq2UMTree 模型能够在一定程度上缩短解码的长度,但是不可避免的,它还是存在偏置问题。是否有一种序列到集合的方式,既能不捕获三元组的顺序,又能解决偏置问题,值得进一步探索。对于文档级别的抽取,如今 GCN 已成为主流的方法,在 NLP 相关的会议上,基于 GCN 的文档级别抽取方法的论文应该是最多的。但是,总体而言,这类方法主要是将提及(Mention)、实体、句子级别的信息进行聚合以及传递,但是我们在做关系抽取时,更多的是要关注实体对级别的信息传递,这方面的工作仍然可以做进一步的展开。还有一点,如何有效解决 GNN 可能面临的“过平滑”问题。再者,在基于文档而建立的异构图中,不同节点之间的信息是如何进行传递的,这也是值得研究的一个点。


本文转载自:Datafuntalk(ID:datafuntalk)

原文链接:复杂语境下的实体关系抽取

2021-08-07 07:005663

评论

发布
暂无评论
发现更多内容

新版Redis不再“开源”,对使用者都有哪些影响?

华为云开发者联盟

数据库 redis 华为云 华为云开发者联盟 华为云GeminiDB

深入理解精准测试理论与技术:揭秘测试技术的核心原理

测吧(北京)科技有限公司

测试

云端简易指南:快速启动与管理您的ECS实例

Geek_2d6073

深入了解一下http和https的区别

秃头小帅oi

数据可视化与分析:利用Kibana展现数据的视觉化洞见

测吧(北京)科技有限公司

测试

自定义Elasticsearch索引模式:优化数据存储结构以提高检索效率

测吧(北京)科技有限公司

测试

ECS公网连接指南:精明选择公网IP计费策略

Geek_2d6073

软件测试学习笔记丨Allure2 报告中添加附件(视频)

测试人

软件测试

深度解析代码变更对业务的影响范围:业务影响范围关联分析

测吧(北京)科技有限公司

测试

利用Shell二次封装Elasticsearch客户端:简化数据检索与操作

测吧(北京)科技有限公司

测试

TikTok直播专线:解决出海网络问题痛点,提升商业效率

Ogcloud

海外直播专线 海外直播 tiktok直播 tiktok直播专线 tiktok直播网络

利用Elasticsearch进行文本数据的深度分析

测吧(北京)科技有限公司

测试

阿里云实时计算Flink的产品化思考与实践【上】

Apache Flink

大数据 flink 实时计算

分享一些大数据处理算法

宇文辰皓

大数据

JVM字节码分析与修改:探索代码覆盖率底层实现框架

测吧(北京)科技有限公司

测试

数字化工厂MES/MOM一体化解决方案PPT

工赋开发者社区

AlphaGPT在法律大模型圈子火了,案件仅需3分钟搞定

科技汇

解锁TikTok直播专线,提高使用体验

Ogcloud

海外直播专线 海外直播 tiktok直播 tiktok直播专线 tiktok直播网络

更轻松地部署和升级 NGINX Service Mesh

NGINX开源社区

nginx Kubernetes Helm Service Mesh 服务网格 mTLS

码上时刻|通过逻辑视图 Logic View 快速实现批流一体

Kyligence

实战代码静态分析工具:利用语法树数据工具提升代码质量

测吧(北京)科技有限公司

测试

互联网公司裁员现象调查:探寻背后原因与应对策略

小魏写代码

TikTok直播专线是什么?有什么用?

Ogcloud

海外直播专线 海外直播 tiktok直播 tiktok直播专线 海外直播网络

OLAP性能再获突破!火山引擎ByteHouse性能白皮书发布

Geek_2d6073

中国 10 亿参数规模以上大模型数量已超 100 个;GitHub 推出代码自动修复工具丨 RTE 开发者日报 Vol.172

声网

代码覆盖率提升策略:利用静态分析工具优化测试覆盖率

测吧(北京)科技有限公司

测试

RocketMQ 流数据库解析:如何实现一体化流处理?

阿里巴巴云原生

阿里云 RocketMQ 云原生

搭建Elasticsearch、Kibana和Logstash环境:构建强大的数据分析平台

测吧(北京)科技有限公司

测试

软件测试学习笔记丨Allure2报告中添加附件-日志

测试人

软件测试 测试开发

比 MyBatis 效率快 100 倍...

Java技术精选

敏捷开发:想要快速交付就必须舍弃产品质量?

敏捷开发

项目管理 Scrum 敏捷开发 产品研发 研发

复杂语境下的实体关系抽取_语言 & 开发_DataFunTalk_InfoQ精选文章