详解如何充分发挥先验信息优势，用MRC框架解决各类NLP任务

本文内容整理自 PaperWeekly 和 biendata 在 B 站组织的直播回顾，点击文末阅读原文即可跳转至 B 站收看本次分享完整视频录像，如需嘉宾课件，请在 PaperWeekly 公众号回复关键词课件下载获取下载链接。

作者简介：孟昱先， 香侬科技算法工程师，本科毕业于北京大学数学系，先后从事负责信息抽取、舆情分析等多项产品的研发工作。 以第一作者身份在 ACL、NeurlPS 等会议发表多篇文章。

本文将讨论如何将命名体识别、指代消解、关系抽取、文本分类等 NLP 任务转化为 MRC（机器阅读理解）任务，利用 MRC 框架的 query 所蕴含先验信息的优势，不但由此获得效果上的显著提高，还将赋予模型 Domain Adaptation、Zero-shot Learning 等多方面的能力。

让我们先梳理一下 MRC 的基础知识。

什么是MRC？

MRC 主要分为三个部分，分别是 context，query 和 answer。所谓 context 可以简单理解为一段 passage，可以是一句话，也可以是一段话，也就是所谓的语境。query 或者 question 是一个提问。

我们要针对 context 去提出一个问题，根据 question 和 context，去文中找到一个 span，它可以是一个连续的字符串，从 start 为开始，以end为结束，将该字串作为这个问题的答案，这就是我们所说的 answer。

下面是一个简单的例子，图中的 context 是一个和降水相关的阐述，然后 question 就是对 passage 提出的问题， answer 就是从这个 context 中画出了 within a cloud 这一连续的 span 来作出回答。

MRC框架尝试解决的NLP任务

了解了基本结构后，让我们来看看 MRC 框架可以解决那些类型的 NLP 任务：

• 第一个任务是 NER，即命名实体识别；

• 第二个是 Relation Extraction，即关系抽取；

• 第三个是 Text Classification，即文本分类；

• 第四个是 Co-reference Resolution ，即共指消解。

我们首先介绍一下这些任务都是什么，以及我们如何将它们转化为 QA 任务。

2.1 MRC框架解决NER任务

NER——命名实体识别任务。上图是我们今年发表在 ACL 的一篇文章。NER 实际上就是在给定一段文章或一句话的情况下，识别出内容中所有的命名实体，比如说地名或者是机构名。那么在上图中的 at the Chinese embassy in France 实际上就包含三个命名实体，其中 Chinese 和 France 是地名， the Chinese embassy in France 是一个机构名。

那我们如何将这个 NER 的任务转化为 QA 任务呢？参照上文所讲的三要素 question, context, answer。首先context就是输入的这句话。那么 query 是什么？

可以通过一个简单方法来构造，直接去问：which location is mentioned in the context？我们希望对于这一 query 和 context 组合，模型能够帮我们抽取出 answer。answer 就是两个连续的子串 Chinese 和 France。需要注意的是，query 的构造方法还有很多种。

我们还尝试过另一种方法，直接拿 NER 数据集的标注规则，来作为我们的 query，比如说地名的 NER 的标注规则，就是 find all geographical regions,  such as … 这样的话我们就能更贴切的让模型知道什么样的命名实体是一个地名。

2.2 MRC框架解决Relation Extraction任务

接着我们来看如何把 Relation Extraction 的任务转换为 QA？上图是我们发表在 ACL2019 上的一篇文章。Relation Extraction 一般来说可以分为两个步骤，第一个步骤是先识别出来输入 passage 的形态，比如说上图 passage 中绿色标记的就是时间、红色的是人名、蓝色的是公司名，以此类推。

第二个步骤是找出不同的 entity 之间的关系，比如说大家可以看下面这张表。

比如说 Musk 这个人，他在 2002 年担任 SpaceX 这一公司 CEO。Relation Extraction 其实就是一个将非结构化的文档转化为一个结构化信息的过程，这个过程通常是通过先识别 entity，然后再识别 energy 之间的 relation 来完成的。

那我们如何将 Relation Extraction 这个任务转化成 QA？第一步先抽取 person，构造一个 query 叫做 who is mentioned in the text？这样的话我们希望模型会根据这个 query 和 context 进行回答，Musk 这个人出现在了结果中。

第二步我们会问 Musk 这个人 which company did Musk work for？这样的话我们就能可以抽取出来 Musk 为哪些公司工作过。

第三步如果还想抽取他在这个公司担任的职务，可以再继续问 what was Musk’s position in SapceX？模型就会抽取出，他是在 SapceX 担任 CEO。

那么类似的也可以抽出来时间 2002 年，然后我们就会得到一张表。这里有个问题，比如说 Musk 他既在 SpaceX 工作过，又在 Tesla 工作过，那应该怎么去抽取？实际上阅读理解的答案也可以是由多个 span 来组成，可以借助 NER 的 BIO 的标注方式，从一个 passage 中去抽取多段答案，然后只需要对每一段做 QA，这样就可以用多轮 QA 的形式来抽出完整的表格。

2.3 MRC框架解决Text Classification任务

接着看 Text Classification 转化为 QA 任务的过程。这个任务相对简单，可以直接把原始文本作为 context，query 可以是这个类别的一个描述。因为是文本分类，answer 会跟别的 QA 任务不太一样，实际上只需要回答是 yes 或者 no。

借助这个槽填充机制，可以比较简单的实现任务转化。我们还尝试了一些其他的工作，提出使用不同的 query 生成方式。通常我们会使用如上图左边 template description 这样一种方法，也就是给出一个模板。我们还尝试了两种其他的方式，Extractive Description 和 Abstractive Description，这部分后文会详细讲到。

2.4 MRC框架解决Co-reference Resolution任务

最后一个任务来看 Co-reference，Co-reference 比较有意思，任务目的是识别一段话中指代同一个实体的不同描述，比如说上图这段话中 Jingle Bells。还有下图中的 the song 实际上就是在指代同一个东西。任务就是要把这段话中所有可能指代同一个物体的描述全都抽出来，并做出聚类。

context 是原本的输入，query 是抽取和 Jingle Bells 所指相同的词。我们的做法是，构造一个 query It was just “” Jingle Bells “”，这里的 mention 是一个 special token，其实是什么都可以。

然后再匹配前面的 it was just，在原文中出现的 context 作为一个简短的 query 来提问。我们期望得到的 answer 就是 the song，这样的话我们就完成了 Co-reference 任务到 QA 任务的转换。

如果没有答案 answer 就直接是 None 就可以了。

不同NLP任务转化为MRC的优势

上文转换的多个任务中，主要的工作都是在构造 query。Context 通常来讲就是任务本来的输入，核心目标就是构建 query 或 questions。

和将 context 推给模型来学习相比，为什么构建 questions 的效果要更好呢？原因在于 questions 是 encode 了一些先验知识的，可以更明确的告诉模型哪些信息或 token 要被注意到，看做一种 hard version of attention。

还是拿 NER 任务来举例，比如说 context 是 at the Chinese embassy in France，如果标注方式是 annotation guidelines，那么就会提到 geographical regions。

在 Bert 的头注意力机制中，government 这些词如果做可视化的话会被着重强调的。在这种情况下如果构造一个比较好的 query，在数据量很少的情况下也可以抽出高质量的结果。

还有 Domain adaptation 和 Few shot learning 两个优势，这两个优势都是由第一个优势引申过来的。我们在前文和 NER 相关的那篇文章实验中发现，在 question 先验知识的帮助下，只需要使用大概占原本数据集一半左右的数据量就可以达到原本直接用 encoder 来做的效果。

除此之外，我们认为还有一个非常大的优势，就是它的 flexibility，即灵活性。对于灵活性，下面会通过具体分析上述的任务来做逐一解释。

3.1 NER任务在MRC框架下的优势

和前卫的顺序一致，先看 NER 问题下 MRC 框架的优势。

目前主流 NER 任务的大数据集主要都解决的是 flat NER，每一个字可能都只属于一个 entity，但实际上在现实生活中经常不是这样，比如说中国人民解放军，其中的中国这两个字就是一个国家，但中国人民解放军可能又是一个组织，同样的在上图这两个例子中，蛋白和 DNA 或者说国家和机构其实都是会有重叠的。

熟悉 NER 同学都知道常规解决手段比如 Sequence labeling，会后面加一个 CRF，但这样做很难解决 NER 之间 overlap 的情况。

而对 MRC 来说这就是非常简单的一个问题，因为我们的 query 构造先天的避免了问题，对每一类的 entity 都会问一个不同的问题，比如说对于图中的第二句话，我们就可以先问：这句话里出现了哪些地名？

然后 MRC 会告诉我们有 Chinese、France，接着问这句话里又出现了哪些机构名，它会告诉我们是 the Chinese embassy in France，可以看到嵌套命名实体的情况对于 MRC 框架来说就根本不是一个问题。

上图是在 Nested NER 数据集上实验的结果，大家会发现我们的优点非常明显，相比于 Flat NER 领先优势是一个点左右。Nested NER 突破了之前一些方法的瓶颈，所以相应的提升会非常的明显。

3.2 Relation Extraction任务在MRC框架下的优势

接下来看 relation extraction。一般的方法是，首先提取不同类型的 entities，比如说人名、公司名、时间等等。第二步就是去构造 entity 之间的关系，比如说这个 Musk 跟 SpaceX 就是 work at 这样的一种 relation。

这样操作的问题是很难去解决 hierarchies 的问题，还是看上图简单的例子， Musk 可以在不同的公司工作，在一家公司也有可能担任多个职务，单纯的通过 two stages 的方法是解决不了问题的。

那么在 MRC 的框架下，这样的问题就会迎刃而解，这一切都可以通过多轮问答的形式来解决。上图是在 relation extraction data 上的实验结果。

3.3 Coreference Resolution任务在MRC框架下的优势

接下来我们讲一下 Coreference Resolution 这个任务。我们常规的做法也是分两步执行。第一步是抽取出 mention 指代的 proposal，也就是我认为这一段文字或者说在指代某一样东西。

第二步常规的做法是说对 Mention 之间做一些 linking，比如说这里的 my cat 和 the cat，实际上指代的是同一个东西，那么我们希望模型判断出来它们指代同一个东西。这里的 my cat 和 Jingle Bells 指代的不是一个东西，相应的我们希望模型去判断它们不是一个东西。

这种方法的问题是如果第一步抽取了一些 mention proposal，就会丢失了 mention，到了 mention linking 这一步实际上就不太可能再把它找回来。那我们 MRC 的这个框架是怎么解决这个问题呢？

我们在第一步中可以只抽出 Jingle Bell 这一个可能的 mention，在第二步，也就是 QA 的这个步骤，其实就完全可以通过 QA 的形式把 the song 给找出来，即便 the song 开始并没有被我们抽成一个 mention proposal。

大家看上面这张实验里的图也可以很明显的发现我们的 recall 比之前的 SOTA 都要高很多，尤其是在当控制了 mention proposal 的数量的情况下。

3.4 Text Classification任务在MRC框架下的优势

接下来我们看 text classification 任务。常规的方法非常简单，把这段话输入一个模型，得到输出预测，直接去拿最终的 representation 来计算分布。

但实际上有时候我们的需求会更加的复杂，比如说有一个常见的分类是 aspect sentiment classification。

正常的 sentiment classification 直接去分这句话或者这段话的感情是正面还是负面，但 aspect sentiment classification 就是要求你去区分不同的 aspect。

比如 clean updated room 就是说卫生环境很好，friendly efficient staff 可能是说它的服务很好，rate was too high 可能会说它的价格不太好，所以它这一段话可能有一部分是某些 aspect 的正面，然后另外一部分又是某些aspect的负面。

对于一个 encoder 来说，他能够学到关于不同 aspect 以及不同 aspect 的正负的表示，实际上都是集中在了最后一层 fully connected layer。最后一层才学这个特征，实际上对于一个网络来说是非常不友好的，实际上没有很好的去监督他学习这个特征。

那在 MRC 的这个任务里，我们其实通过 description 避开这个问题。

比如说如果我们要抽取这段话，关于这个价格的情感极性，那么我们就可以去构造一个 query 叫做 positive price。那这样的话 price 和 rate 这种词就会通过 BERT attention 连接在一起。

所以在这种 hard attention 的情况下，就会非常容易的去预测每一个 aspect 的类别。

然后接下来详细介绍在不同 query 构造方法上的探索。本文一共尝试了三种 query 构造方法。

第一种是 template-based，基于模板的方法，正如上文提到的 positive price，就是基于 template 的 query。

之后还有 extractive-based 和 abstractive-based 两种构造方法。extractive-based description 是针对每个 context 都找到与当前 context 相关的 query，然后输入模型当中，在此作为先验知识去帮助模型分类。

比如，要确定这段话是不是在描述车辆相关的主题， template-based的 description 可以复述 Wiki 百科上的描述：什么是一辆车？然后把这句话作为 query 输入模型中。

第二种 query 构造方法是 extractive-based 的 description, 该方法对于一段话去抽取一个连续的 span 作为可能的 query。

第三种 query 构造方法是是 abstractive-based 的 description，利用 Seq2Seq 的模型令 context 去生成一段 description。

后两种 query 构造方法是怎样的呢？在本文中利用的是强化学习的方法，强化学习有三个要素，action，policy，reward。

对于 extractive based 的 query 构造方法， action 在本文中实际指从书中文本中选取一个文章的 span， policy 在本文中实际是指要根据这个文本判断这个 span 的起始位置和终点位置，reward 是指当把 span 作为我们的 query 之后，整个 QA 模型能够输出正确标签的概率，之后可以根据这个 reward 去做 reinforcement learning。

对于 abstractive based 的构造方法，原理也十分类似，区别在于 action 从原文的 span 变成了直接 Seq2Seq 生成的一个过程，policy 从原文中选取 span 变成了在此表中选取的过程。Reward 与 extractive based 的方法是一样的。

实验结果如图所示。从实验结果中看出，在文章比较长，比较难分类的情况下，QA 框架下表现很好，这是因为在文章较长的情况下，分类的 attention 机制实际上很难去学习要重视哪些词，然后忽略哪些词，如果加上 query 的先验信息之后，就会比较好地对文章做分类。

生成query的方法

这里总结一下有哪些生成 query 的方法。第一类方法是 handcrafted rules，正如在做 NER 使用的标注的 guideline，或者是文本分类使用的 Wiki 的定义。第二类方法在文本分类中对不同的 text 或者 context 生成不同的 queries，然后用强化学习的方法进行优化。

除了上述介绍的 MRC 的优点，由 flexibility 可以引出 MRC 的一个最后的优点。

各种任务其实都可以转化为 MRC 的框架，然后再在 MRC 框架下去设计一个大一统的模型来解决问题。Google 的 T5 和这个十分类似，他们主要做 language model、Masked language model 相关的训练。但如果把所有的任务都转化为 MRC 框架下的任务，可以利用 multitask 的训练方法。

关于数据实战派

数据实战派希望用真实数据和行业实战案例，帮助读者提升业务能力，共建有趣的大数据社区。

更多阅读

#投 稿 通 道#

 让你的论文被更多人看到 

如何才能让更多的优质内容以更短路径到达读者群体，缩短读者寻找优质内容的成本呢？答案就是：你不认识的人。

总有一些你不认识的人，知道你想知道的东西。PaperWeekly 或许可以成为一座桥梁，促使不同背景、不同方向的学者和学术灵感相互碰撞，迸发出更多的可能性。 

PaperWeekly 鼓励高校实验室或个人，在我们的平台上分享各类优质内容，可以是最新论文解读，也可以是学习心得或技术干货。我们的目的只有一个，让知识真正流动起来。

📝 来稿标准：

• 稿件确系个人原创作品，来稿需注明作者个人信息（姓名+学校/工作单位+学历/职位+研究方向） 

• 如果文章并非首发，请在投稿时提醒并附上所有已发布链接 

• PaperWeekly 默认每篇文章都是首发，均会添加“原创”标志

📬 投稿邮箱：

• 投稿邮箱：[e-mail] 

• 所有文章配图，请单独在附件中发送 

• 请留下即时联系方式（微信或手机），以便我们在编辑发布时和作者沟通

🔍

现在，在「知乎」也能找到我们了

进入知乎首页搜索「PaperWeekly」

点击「关注」订阅我们的专栏吧

关于PaperWeekly

PaperWeekly 是一个推荐、解读、讨论、报道人工智能前沿论文成果的学术平台。如果你研究或从事 AI 领域，欢迎在公众号后台点击「交流群」，小助手将把你带入 PaperWeekly 的交流群里。