ner(named entity recognization)，命名实体识别旨在提取句子中预先定义的不同类型的实体，如person，location，organization等等。从概念上来讲，ner任务有点类似于目标检测任务，ner首先需要detect实体空间(entity span)，然后分类实体类型(classification)。
ner方法分类：
ner方法上从解决的ner问题出发，大致分为2种类型[ps:看的文章不多，总结或许有误]：
Flat ner
Nested ner
Flat ner: 解决常见的标准的ner任务，实体之间不存在嵌套关系，每个句子token只会属于一种实体类型。对于这种类型的ner任务，通常采用序列标注模型，典型的如: BiLSTM+CRF、bert+biLSTM+CRF，在输出层，每个token进行softmax分类，因此每个token只会输出一个标签，无法解决实体嵌套的问题。
Nested ner: 解决实体嵌套的ner任务。实体嵌套大体上可以分成2类：1）不同实体类型间嵌套; 2) 同种实体类型间嵌套。不同实体类型间嵌套，如例子"chinese"属于contury类型，"chinese embassy in France"属于facility类型，chinese这个token即存在不同类型实体间的嵌套；类似的，同类型间实体的嵌套，"chinese"属于person类型， "chinese girls"属于person类型，chinese这个token即存在同种类型之间的嵌套
BERT-MRC为了解决嵌套的ner任务，提出了一个基于MRC(机器阅读理解)的QA框架来统一的解决flat ner以及nested ner任务，并取得了SOTA的性能。
个人感觉这个文章很有开创性，后续一些信息抽取的文章"CASREL"等jointly方法都有这篇文章的影子，遂记录一下。
2.2.1 解决不同类型间的实体嵌套
前面提到，序列标注模型不能解决嵌套问题。而这篇文章提出了基于问答的框架来解决嵌套实体识别的问题，对于每种类型的实体，都会构造一个相关的query，也可以把它当作一个"prompt"。例如，假如要抽取person类型的实体，我们可以构造一个query: "which people did mention in this sentence?"，于是ner任务就变成了基于给定的句子来回答query这个问题，答案就是对应的实体文本，是连续的文本空间(注意是连续的)。
训练：
首先训练集会事先构造成(Query, Context, Answer)三元组的形式，query是和实体类型相关的，编码了实体类型信息，query到实体类型是一一对应的。context是原始句子，answer即该类型下的实体。entity通过text span表示，即在一个句子通过实体的开始位置索引(start)和结束位置索引(end)来表示一个实体。
模型上使用Bert模型， query和context concat后输入bert中获取每个token的向量表示，输入形式: CLS "query" SEP context ，每个token后面接2个二分类任务，一个用来分类是否是start索引，一个是用来分类是否是end索引。这里本质上是N个2分类任务， N是序列长度，而不是2个N分类任务。前者使用sigmoid loss，后者使用softmax loss，前者可以在一个句子中输出多个start索引，而后者只能输出一个start索引[即一个实体]。一个句子中，同种类型的实体可能不止一个，因此本文采用n个2分类任务。
解码：
这里还存在一个特殊的解码问题，基于MRC的QA框架只能解决不同类型间的实体嵌套问题，对于不同类型的实体，构造一个特殊的query，独立地去获取该类型下的实体。而对于同种类型的嵌套问题，一个句子中有多个start index和对应的多个end index，如何解码？如果不存在同类型实体嵌套问题，我们可以直接使用基于启发式的就近匹配原则，start index寻找最近的end index进行匹配即可。对于同类型嵌套，如句子"chinese girls", 有2个实体, "chinese" ，和"chinese girls"，start index 只有1个1，而end index有2个1，基于上述启发式匹配就会漏识别。因此为了cover这个问题，本文提出了match网络，将start向量和end向量concat后，进行一个二分类任务，判断start和end是否是match的
推理：
每种类型构造的query拼接原始句子，输入到网络中，获取每种类型下得到的entity span。
2.2.2 一些问题点讨论
首先简单说一下效果，在flat ner以及nested ner上任务上都取得了SOTA
2.2.2.1 如何构造query
这一点在论文中有反复的提到，构造的query很重要，且对最终的性能影响很大。其实也不难理解，套用QA的框架也能知道，Question是核心要素之一，没有好的问题怎么能得到你想要的答案呢？原文做了一些详细的实验对比，感兴趣的可以仔细阅读原文对应的章节。
其实在没有看到这篇文章的时候，心中有一个想法，那就是不去构造query，而是使用实体的类型，比如说"OGR"，"PER"等作为一个special token放在句子的开头，这个特殊的token编码了具体的实体类型信息，引导模型输出对应类型的entity。这样也能完成统一建模，但是这种想法其实也刚好在构造query这一节被作者实验过了。但是按照我的理解还是有一点点不同，其中keyword方式就是使用类型的关键词，比如"person"，"organization"等，本质上其实还是想query具有一定的语义信息[去套用qa的框架]，但是想person， organization这种类型在句子中可能很常见，导致embedding不能唯一去编码任务信息，可能会影响性能。
TODO: 后续有ner相关的任务，可以尝试一下这个想法，感兴趣的读者也可以试试吧～
2.2.2.2 MRC框架的好处
MRC框架的好处在论文中也被反复提及，主要有以下好处: 1) 能够解决嵌套的实体识别问题；2）通过构造query的方式，其实编码了需要提取的实体的类型信息，这是以往序列标注模型做不到的；3）具有很好的zero-shot能力(很nice~)，由于query通过自然语言的方式编码实体类型信息，即使训练集中没有出现的实体类型，通过理解query的语义，能够得到正确的答案(entity)。个人觉得prompt方式是解决zero-shot的一种很好的方式，prompt(也即query的构造)就很重要。
回到前面那个点，如果使用实体的类型作为special token这种范式，那模型就完全不具有zero-shot能力了