1. 首页
  2. 平台展示

新闻摘要: 巴伊兰大学:事件新闻推文的交互式摘要生成

冠亚体育app讯:

EMNLP 2017 System Demonstrations

事件新闻推文的交互式摘要生成

Interactive Abstractive Summarization for Event News Tweets

巴伊兰大学

Bar-Ilan University

【摘要】我们提出了一种基于摘要生成的新型交互式摘要生成系统,该系统来源于最近的多文本合并知识表示。我们结合几个交互机制,提供了一种子弹式(bullet-style)摘要方法,其允许先获取最重要的信息,然后再交互式地深入到具体细节。针对事件新闻推文的可用性实现研究,表明了我们方法对文本探索的实用性。

1 引言

多文档自动摘要(Multi-documentsummarization, MDS)技术能辅助读者在阅读一个主题的多个文本时获得最重要信息。主流MDS方法侧重于构建一个特定长度的短摘要,捕获最重要的信息,模仿一个手工制作的“静态”摘要。作为另一种选择,很少有论文考虑到交互式摘要生成。该方法中,用户可以根据需要和兴趣(Christensenet al., 2014; Leuski et al., 2003; Yan et al., 2011),交互式地对所提供的信息进行探索。

本文对这一方法做出了进一步贡献,关于于交互式摘要生成。基于提取的“原子”事实,我们认为摘要生成方法特别适合于交互式设置,因为它允许更灵活的信息表示。直观地说,对于用户来说,在个体事实的层面上探索信息更有意义,而不是像之前针对基于整个原始句子进行那样粗糙(见第6节)。

我们利用抽象的方法来支持两种有用的交互模式。首先,我们将信息呈现在一个子弹式(bullet-style)的摘要中,其中最重要的信息一开始在项目符号句子里显示的,而进一步的细节则可以通过展开额外的项目符号来获得。具体地说,我们采用该方法,针对新闻推文中的某个事件按照时间线进行摘要生成(见图2)。我们的第二个的交互模式是概念扩展,它允许通过其提到的替代术语查看概念的补充信息,并摘要中跟踪概念出现的(见图3)。这些信息是隐藏在使用原始的句子(萃取)或一个单一的词/概念(抽象)的静态摘要中。

为了促进交互式摘要生成的模块化构建,我们利用文本的合并表示作为输入,特别是在最近Witie等人(2017)开放知识表示(OKR)中。简而言之,这种表示捕获了文本句式,其中在保持句式原有提及的链接(见第二节)的同时压缩共指概念和论点。我们利用OKR结构,提取自动事实级别的信息,从离散提及扩张信息,从得到的摘要句子中检索来源。

我们交互方案的新颖之用是要求验证它对用户的有效性和有用性。为此,我们在一个原型系统中实现了我们的方法(第3-3节)。该系统从输入的OKR数据中自动生成交互式摘要,其中,我们假设输入数据由外部的黑盒工具从原始文本中解析。我们在黄金标准的OKR数据集上,通过一组标准的可用性测试来检查我们的系统(Brooke, 1996; Lund, 2001),这样我们能够在孤立的情况下研究它的贡献(第5部分)。我们的结果表明,本文提出的系统对读者来说是非常有价值的,它为标准的静态摘要提供了一个很有吸引力的替代方案。

2 准备

如上所述,我们的交互式摘要生成系统是基于多文本信息合并表示。接下来,我们将回顾这种表示的背景,然后描述我们使用的特定开放知识表示。

2.1 合并表示

在摘要生成和文本探索的激励下,最近的研究考虑整合不同结构中的文本信息。作为突出的例子,刘等人(2015)和李等人(2016)的研究构建了基于图形的表示,其节点是述词或述词论元,从原始文本中提取出来,并通过边捕获述词论元关系,并且相同或共引概念收缩到单一节点。

Rospocher等(2016)提出一个更多的监管方法,其中图中的概念链接到DBPedia(http://wiki.dbpedia.org/)条目中。这与其他元数据一起用于检测共引和消除歧义概念。

这些工作都没有考虑交互式摘要,特别是没有一个结合足够的数据用于我们的用户交互模式。接下来,我们简要回顾一下我们系统中使用的,由Witie等(2017)所引入的开放知识表示。

2.2 开放知识表达OKR

我们通过图1中的示例展示OKR结构(参见witieet al(2017)的详细说明)的组成部分,这些组件是我们摘要生成方法的核心部分。在顶部,有四个原始推文。在底部,有从这些推文中派生出来的两个合并句式命题 (标记P1和P2)和四个实体(标记为E1-E4)。该图描述了在OKR中捕获的三种链接类型,如下所描述。

图1 一个事件的四条推文和他们的OKR结构

提及链接将每个句式或实体与它的一组提及术语联系起来,即在整个文本中,每一种形式的引用都是关于实体/句式的。例如,在推文中提到的E1就是“人”、“枪手”或“雷德克里夫豪顿”。提到的句式被存储为带有参数占位符的模板,例如“a2死于a3”。通过它们的提到,实体和句式进一步与它们在原始文本中出现的事件联系在一起(从图中省略)。

论元链接将句式与它们的论元连接起来,这些论元可能是实体或(嵌套的)句式。由于一个句式可能有几个带有不同论元的模板,论元ID(在P1中标记为a1-a3)被用于捕获相同句式中的共引论元。例如,a2和a3在P1的两个模板中作为论元出现,分别引用实体E2和命题P2。

隐含连接,在图1中以有方向的边标记的连接链接,跟踪不同类型的OKR组件之间的语义关系(上下文)。例如,在E1中,“RadcliffeHaughton”需要“人”或“枪手”,即前者在给定的背景下更具体、更有信息。

3 综合概要信息

我们系统的体系结构包括两个主要步骤:(1)一个预处理步骤,其中我们生成综合摘要信息和(2)所选信息的交互显示。在本节中,我们将描述第一个步骤,该步骤基于输入的OKR结构。我们用于交互式地探索汇总信息的用户界面将在下一节描述。

我们系统生成摘要信息的一般方案如下。

1.将OKR句式划分为组;

2.为每组句式生成具有代表性的摘要句子,这些都产生了项目符号式的摘要句子;

3.为每个代表性语句生成元数据:知识得分、概念扩展和时间戳。

对于当前的系统,我们为每一个步骤实现了一个基线方法,尽管如此,在可用性研究中仍然获得了很高的满意度(见第5部分)。

我们在OKR结构中把句式划分为不同的组,使得每组句式由论文链接连接(忽略链接方向)。例如,在图1中,P2被嵌套在P1中,因此两者被分到一组。

其次,对于一个组中句式的“根”(即:不是嵌套),我们会生成备选的候选句子。这是通过在模板中填充所有可能的相关论元提及的组合以及递归的嵌套句式来完成的。例如,对于P1,我们会产生“[3 people] dead in [shooting in[Wisconsin]]”,“[3 people] dead in [[spa] shooting]”,“[Three] dead in [[spa]shooting]”,等等(总共有22个候选句子)。

从每一组候选集合中,我们选出一个具有代表性的句子。重要的是,这意味着不同于有长度边界的摘要段落,我们的综合摘要信息有效地涵盖了原文中的所有句式。与预想过滤不太重要的信息不同,它最初只隐藏在UI中,可由用户来展开(见第4节)。为代表的句子,我们选择一个语言模式分数高、知识分数高和长度小的候选集合(对于语言模型,我们在一个100M的推文集合上训练了一个LSTM模型(https://github.com/yandex/faster-rnnlm))。这些是通过优化这些因子的加权和来完成的。

每个句子的知识分数直观地反映了它在原始文本中所提及的常见程度,以及基于OKR暗含的链接的信息(具体)有多大。例如,回顾图1中,在“Threedead in spa shooting”的推文中,“three”、“dead”和“spashooting”的概念应该会因为出现在两个推文中而得到奖励,但是,“three”应该没“3people”得到的奖励要多,这是一个更有意义的信息。

我们用下列启发式公式来计算每个生成句子的分数:

其中,mentions(s)是句子中述词和实体的提及。depth(m)在OKR的相关词汇表中指定一个给定的词的深度。我们有经验设置α= 1, β = 0.1。

摘要句中的每一个概念(实体或命题)都用OKR与它的提及和原始文本联系在一起。这个提及集合清除重复(带有小编辑距离的字符串),为大于1的不同提及集合提供概念扩展。这就提供了概念的额外信息,否则可能有遗漏。例如,在图3中,“suspectedgunman”也被确认为“Jamaican”。对于推文摘要生成场景,我们还计算每个代表性语句的时间戳,作为第一个推文提到它的根句式的时间。

4 交互式用户界面

我们现在描述我们实现的,为在一个特定事件的多个微博互动探索的web应用程序(http://u.cs.biu.ac.il/shapiro1/okr)。我们的后端是在Python 2.7中实现的,并在CentOS服务器上运行。前端是用AngularJS库实现的。JSON用于数据交换。

图2显示了从我们的运行示例中获得的关于威斯康星州spa枪击的109条twitter消息的初始屏幕。子弹式风格的句子(如第3节所解释的那样生成)按时间戳的顺序降低排列。在每句话的右边,一个饼状图根据它的归一化的知识分数显示了它所涵盖的知识的“百分比”。顶部的饼图显示了目前可见的句子所包含的全部知识。

图2 关于威斯康星州一家温泉疗养中心枪击的109条推特报道的初始视图。10个生成的句子按照事件时间顺序涵盖了这些推文中最突出的信息。

最初,只有显示超过某个信息分数门限值的句子,作为一种简洁的子弹风格的事件摘要。其他句子被折叠起来(例如:在图2中,时间戳01:07和22:55之间),用户可以根据(a)时间轴上的时间间隔;(b)折叠句的数量如在行中所示;(c)需要展开的额外;(c)展开的额外知识数量,来决定是否展开和展开哪些句子,并悬停在折叠的句子上方时高亮显示顶部的饼图。通过不断地展开句子,用户可以逐渐发现事件的完整时间轴,并使用来自推特的所有整合数据。

另一种发现信息的模式是通过概念扩展:悬停在突出显示的概念之上(例如:“suspectedgunman”)将会打开一个弹出窗口,含有摘要中同一个概念的不同提及(图3);在摘要中,点击它会进一步突出它的所有共引。最后,用户还可以单击Twitter图标来查看源推文(图4)。

图3 “扩展弹出”的概念,包括提到与“suspectedgunman”相同的人,透露更多信息(例如“Jamaican”).

图4 弹出的推文显示一个可滚动的面板,其中有一个生成的句子的源推文。

5 系统可用性测试

为了评估和改进我们的系统的价值,我们采用标准可用性测试进行了两个可用性研究。这些测试是在由Witie等人(2017)发布的人类注释的OKR结构(图1的形式)的数据集上执行的。我们使用了他们的6个最大的事件推文集,每个有大约100条推文。这个黄金标准的数据集使我们能够独立地研究我们的新系统的优点。考虑到我们下面所报告的积极结果,我们计划在未来的工作中,在一个完全自动化的管道中集成和研究我们的系统。

5.1 初始可用性研究

第一个可用性研究是通过两个目标进行的:检查我们的想法的有用性和理解用户需求。

方法 根据简易可用性测试原则(Nielsen,1993),原型的评估阶段只需要几个评估者。因此,6名不熟悉我们项目的学生被招募为评估员。我们要求他们在六个选定事件中的一个上执行一系列预定任务。在系统使用期间,我们观察用户的活动,并使用“自言自语”技术来获得用户的评论。使用“首款视频捕捉软件”(http://www.nchsoftware.com/capture/)获取每个屏幕上的活动。在执行完所有的任务后,用户被要求填写系统可用性量表(SUS)问卷(Brooke,1996),以进行主观的可用性评估。

结果 表1列出了10个SUS问题中每一个问题在1到5量表上的平均得分。总的来说,用户发现这个原型很容易使用,并且愿意经常使用它。SUS问卷在[0,100]中产生一个重要的单一数字,表示系统的总体可用性。这个数字是根据10个问题的分数来计算的。如表2所示,除了一个不满意的用户(这个用户有软件质量保障背景,并且似乎检查出了非常小的软件和用户体验错误,我们稍后讨论了这个问题)。该系统的得分从70到95不等。在测试期间的观察和口头报告产生了一系列的需求,这些需求帮助改进了我们的原型。

表1 可用性研究后问及的十个SUS问题和从1到5量表上的平均回答得分

表2 SUS对每个用户的评分,基于是个SUS问题得分计算

5.2 对比可用性测试

在更新了我们的系统,使其从初步研究中得到改进后,我们进行了另一项比较研究,以检验我们的系统的相对效能。

方法 我们比较了我们的系统,这是用IAS(用于交互式抽象摘要生成)表示,有两种基本方法:

推文:一个事件数据集中所有原始推文的列表。

静态:由我们系统生成的句子的完整有序表(第3节),没有交互特性和元数据(例如概念扩展、知识得分等)。

正如前面提到的,我们已经使用了由Witie等人(2017)发布的6个事件的黄金标准的OKR结构。六个用户分别在每个界面(IAS、推文、静态)中显示了两个事件,其中事件到界面和界面顺序的分配对于每个用户都是不同的。用户在指定的界面中探索了每个事件的描述信息,并在最后要求完成使用问卷(Lund,2001)。

该问卷要求用户根据33个语句从1到3的范围对3个接口进行排序。最初的30个USE表述代表了四个维度:有用性、满意度、易用性和易学性。我们添加了三种表述来对用户的知识探索经验进行排名(另外三种表述是:系统激励我积极探索更多信息;这个系统让我觉得我知道这个事件的亮点;系统帮助我注意到事件的重要细节)。

结果 表3显示了每个被检查的维度中的每个界面的平均排名。虽然我们的系统比基线更复杂,它只需要阅读,但它在有用性、满意度和知识探索方面一直都是最高的。这表明不管概要句是什么,交互性确实为用户提供了大量的价值 (与基线静态的比较是很明显的)。

表3 在1到3范围上三个系统的USE问卷各维分数比较

与其他基线相比,排名的USE陈述也可以作为一个我们概要质量的指标。标准摘要生成度量标准是为静态摘要而设计的(ROUGE和金字塔方法是评估摘要的常用指标),由于其内容是动态的和用户操作的,因此对于我们的交互式系统来说,这还不够的。在这里演示了交互式总结是有用的,设计和进行交互式摘要生成的专用质量测试是我们未来的工作重点。

6 相关工作

大量的工作致力于解决多文本摘要生成问题。这里,我们关注的是一些很少的研究,这些研究增强了用户交互的摘要生成。

iNeATS系统(Leuskiet al., 2003)是一种早期的交互式摘要生成系统,允许对长度、参与元素等参数进行明确控制。Yan等人(2011)研究了一种更隐式的方法,试图通过用户点击来发现用户的偏好,比如主题和上下文。这两种方法都需要根据用户的反馈不断更新摘要。

最近的SUMMA系统(Christensenet al.,2014) 在支持层次化的摘要生成上与我们的相似。突出的摘要句子在层次结构中是很高的,进一步的细节可以通过深入到较低的层次来发现。

上述所有的方法都计算提取摘要,这些摘要是由原始文本的句子组成的。相比之下,我们的提取方法有一些吸引人的优点。最重要的是,因为不局限于现有的句子,这可能结合了几个不同的原子事实或者需要文本上下文,我们的方法有助于构建灵活的子弹式摘要。这样,用户就可以在原子事实的级别上浏览数据,从而避免重新生成摘要以便合并用户的反馈。

7 结论和未来工作

本文提出了一种新的用于对抽象摘要信息进行交互式探索的系统。我们的系统建立在开放的知识表示OKR(Witieet al,2017)上,以整合多种文本的信息,并生成一个完整捕获这一信息的摘要。交互式UI允许关注最突出的事实,并通过不同的交互模式逐渐获得更多的细节。我们的可用性研究为我们的方法的有效性提供了支持性的证据。

我们的研究结果阐明了未来研究的几个重要方向。一般来说,我们的交互式抽象方法应该被移植到其他的领域和其他类型的语料库。比如,在新闻推文的情况下,句子顺序是按时间顺序完成的,而合并总结句的排序一般来说是一项重要的任务。此外,我们的概要语句生成方法可以得到增强。通过使用机器学习技术来选择最具代表性的句子。对于评估,我们将设计足够的测试来评估一个交互摘要的质量,并在一个集成完全自动化的管道中更广泛使用它们,进行用户研究(比如,一个OKR解析器)。

论文下载链接:

http://www.aclweb.org/anthology/D/D17/D17-2019.pdf

留言 点赞 发个朋友圈

我们一起探讨AI落地的最后一公里

本文来自投稿,不代表本人立场,如若转载,请注明出处:http://shmgfj.com/pingtaizhanshi/2693.html