?PaperWeekly 原創 ·?作者｜張成蹊

單位｜北京大學碩士生

研究方向｜自然語言處理

序

命名實體識別（Named Entity Recognition, 下稱 NER）任務，主要目的是從一段話中抽取出其中可能為實體的所有元素。比如：

“Hi Siri, 今天北京天氣怎么樣？”

如果下游任務要求我們從其中抽取出地點，那我們期望 北京 能被識別成 Location，如果我們希望從中抽取的產品名稱，那么 Siri 應該被標記成 Product —— 換言之，能從句子中抽出什么實體，是由我們提前給定的標簽集合定義的。

在一個任務型對話系統中，一些可能在后臺處理中使用到的實體都應該被抽出來：我們有理由相信，Siri 是真正將 北京 給提取出來了，然后再通過后臺查詢到了天氣~~，而不是找了一個人工客服在后臺即時回復~~。

NER 在很多下游任務中都是非常重要的一環。比如在電商行業，我們可能需要從用戶的查詢中提取出品牌或商品，來針對性地給用戶返回內容。金主爸爸可能也希望用戶在查指定品牌的時候，將一些商品放在第一位。

在任務型人機對話方面，正如上面所說，一個合格的 Chatbot 需要能夠準確地識別時間、地點、事件等元素以回答相關問題或安排日程，同時做到不偷聽用戶的日常對話。

而嵌套 NER，顧名思義，就是識別的實體中可能會存在嵌套的情況。比如北京大學不僅是一個組織，同時北京也是一個地點；雅詩蘭黛小棕瓶是一個產品，同時雅詩蘭黛是一個品牌。

準確地識別嵌套內容有什么作用呢？簡單來講，如果一個模型能夠識別出北京大學是一個組織，它傾向于將所有出現的北京大學都標記成組織。

但如果它能夠在識別前者的同時將北京標記成地點，我們就認為它有能力將所有[地點]大學的模式都識別出來，因為后者的角度，模型學到的是一種 pattern，而非記住了一種具體情況。此外，提取出來的額外信息也能作為輔助特征，增強其他任務的效果。

具體地，我會介紹以下幾部分內容：

• 當前普遍使用的傳統 NER 解決方案；

• 傳統 NER 在解決嵌套 NER 任務時存在的問題；

• 如何解構 NER 任務，從不同的角度解決問題，使模型能夠識別嵌套的 NER；

• 介紹近幾年嵌套 NER 領域有代表性的解決方案。

從 NER 到 Nested NER

2.1? NER 任務的解決方案

在進入 Nested NER 之前，我們先來簡單談談目前普通 NER 任務（下稱 Flat NER）的解決方案，即，將實體識別當做序列標注問題。

具體來說，對于一個長度為 的句子 ，其中 表示句子中的第 個 token。序列標注即給每個 token 打一個標簽，來表示這個 token 所在的實體類別。

一組相鄰且類別相同的 token 構成的子序列 就是我們想要的實體。這樣，一個抽取實體的問題就被轉化為一個給每個 token 進行分類的問題。

在序列標注中，需要定義不同的 Schema，來使得將序列標注的結果從 token 層面提高到實體層面，并且保持其唯一性。定義有效的 Schema 的意義在于消除從 token 標注復原出實體時的歧義，例如：

如果我們希望識別出地點。給定句子：北京市海淀區。我們希望抽取出來兩個實體，分別為：北京市+海淀區。然而如果只對每個 token 進行分類，所有的 token 都將被分到 Location 標簽中，這樣兩個相鄰的同類型實體邊界就無法正確區分開來。

為此，我們需要定義一個 Schema（即類型標簽），使得給 token 打完標簽之后，能夠從 token 復原出實體，同時有效標識兩個實體之間的邊界。在這里介紹兩種最常見的 Schema：

• BIO：即 Beginning、Inside、Outside，對于一個實體的第一個 token，標注為 B-[type]，實體其他位置的 token 標注為 I-[type]，不屬于任何實體的 token 標注為 O；這樣，對于一個標簽數 ? ?的實體集，使用 BIO 標注將轉變為 個標簽；

• BIOES：即 Beginning、Inside、End、Outside、Single。其中 End 用來標識一個實體的結束，而 Single 用來標識僅包含一個 token 的實體。

在給定 BIO 標注 Schema 的前提下，北京市海淀區的標注結果為：B-Location, I-Location, I-Location, B-Location, I-Location, I-Location。能夠完整且沒有歧義地復原出模型的標注結果。

基于上述表述，我們可以將一個基于序列標注（Sequence Labeling）的 NER 任務解決方案總結為兩個簡單的步驟：

選擇一個有效的標注 Schema；

選擇分類模型（常用 CNN/Bi-LSTM/BERT），對每個 token 進行分類；根據分類結果復原出原文中的實體。

2.2 Nested NER

我們現在回頭來看嵌套 NER 的解決方式，一步步提出該問題的基礎解決方案，并探討這些方案存在的不足。

很顯然，2.1 節中所定義的 Flat NER 解決方案是沒有辦法解決嵌套情況的，因為在嵌套 NER 中，一個 token 可能分別擁有兩個不同的類型。

例如：北京大學中的北同時屬于 B-Location，也屬于 B-Organization；而京也擁有 I-Location 與 I-Organization 兩個標簽。

如果從最簡單的角度出發，能夠想出什么方法，使得現有的NER解決方案支持嵌套的情況呢？

2.2.1 將分類任務的目標從單標簽變成多標簽

一個容易想到的解決方式是：Schema 不變，模型也不變，將輸出從單分類轉變為多分類：即在最后分類的時候，從輸出一個類到輸出所有滿足一個指定閾值 的所有類。更為具體地，存在以下兩種方案：

• [1] 完全不改變 Schema，只是在輸入訓練集的時候，訓練集中的 label 從原來的 one-hot 編碼形式變成一個指定類別的均勻分布；在訓練時將損失函數改為 BCE 或 KL-divergence；在進行推理時，給定一個 hard threshold，所有概率超過這個閾值的類別都會被預測出來，當做這個 token 的類。

• [2] 修改 Schema，將可能共同出現的所有類別兩兩組合，產生新的標簽（如：將 B-Location與 B-Organization 組合起來，構造一個新的標簽 B-Loc|Org）；這樣做的好處是最后的分類任務仍然是一個單分類，因為所有可能的分類目標我們都在 Schema 中覆蓋了。

我相信在這些年探索中，這個方案是有學者研究過的，因為它簡單易行，改動也小；不過除了 NAACL18 與 ACL19 中的兩篇文章仔細探討了這些方案以外，我很少有見到有使用這種思路解決問題的 paper。因為它存在一些比較明顯的問題：

（僅針對第一種實現方式）模型學習的目標設置過難，閾值定義比較主觀，很難泛化；

（僅針對第二種實現方式）指數級增加了標簽，導致分布過于稀疏，很難學習；對于多層嵌套，需要定義非常多的復合標簽；

以及最初的問題：修改后的 Schema 預測的結果，復原回實體的時候又不再具有唯一性了。

當然，我們仍然能夠給模型添加規則與約束，來一一解決這些問題，具體內容在論文中有相應的闡述。

2.2.2 修改模型的Decode過程

在這里，Decode 過程指的是基于模型輸出的 token 表示來給 token 分類的過程，在 Sequence Labeling 中指的是 FFN + Softmax/CRF + Argmax 這一套操作。

嚴格來說，解決方案 1 的第一個實現方式也算是非常 naive 的修改了 Decode 過程，不過在這里我們討論一些更加有效的方案。

值得注意的是，修改 Decoder 的目的是為了保證能夠給一個 token 同時賦予多個類別，所以我們仍然將下面的方案視作 Sequence Labeling 任務（盡管最后輸出的 label list 長度可能與 token 的數量不同，但這是因為由原來的單分類變成了多分類所必然導致的）。

• [2] 既然直接使用 FFN 映射做單分類沒法解決嵌套問題，做多分類又不容易做work，那是否可以考慮使用生成式的方法，如?seq2seq 中的 Decoder 來逐個生成每個 token 的標簽？使用 Decoder 能夠將輸入的 token 數量與輸出的類別數量解綁，允許給token打上超過一個的標簽——但是與原來的生成方法不同，除了使用特殊字符[EOS](end of sentence)來標識整個生成過程結束以外，我們需要引入一個特殊字符[EOW](end of word)來標識接下來生成的是屬于下一個 token 的標簽。

• [3]?使用分層的方式對token的表示進行預測也是一個非常有意思的方案：如果一次分類無法解決實體嵌套的問題，那就對第一次的分類結果繼續做分類，如是迭代，直到達到最大迭代次數或是不再有新的實體產生為止。這種解決方案存在的問題是對 Decoder 的學習要求較高，如果前面的迭代過程中出現了錯判，這個問題可能會傳遞到后續迭代過程中。

這一類方法相較于普通的多標簽分類，從任務本身的角度來進行設計，通過橫向（序列生成）與縱向（分層標注）兩個層面修改了原始的 Sequence Labeling 模型將輸入 token 與輸出 label 強制綁定的形式。

2.2.3 拋棄Sequence Labeling

依稀記得之前看過一篇讓我印象深刻的知乎文章，名為"丟掉幻想，全面擁抱Transformer"。借由此名，最后一種解決嵌套 NER 問題的方式可以叫做"丟掉序列標注，全面擁抱 Multi-Stage" 。

我們已經在上文中多次提到，序列標注任務是天然不支持給一個 token 賦予多個標簽的，盡管我們已經進行了多個層面的修飾，使它能夠應用到多標簽分類上。

但是既然它應用到 Nested 任務上時效果并不突出，也沒有其不可替代性，為什么不直接舍棄掉這個任務形式，嘗試其它的解決方案呢？

撇開原來的 NER 解決方案，從頭考慮一個實體識別的方案，我們仍然從一個非常 naive 的 proposal 出發：

將句子中所有的子序列全部枚舉出來，即得到一個子序列集合：。

訓練一個分類器?，負責將子序列映射到給定的標簽集合（即：Location, Organization, ..., O）中：。

如果上面的 proposal 真的能夠做 work，它就完美地勝過了以 Sequence Labeling 為基準的 Flat NER 解決方案：因為這個方案同時能夠應用到 Flat 與 Nested 情況下 —— 倒不如說，這是一個理論上的?NER 任務終極解決方案。

當然，通過常識來推斷，這個任務做 work 的概率非常小，因為這樣的設定會帶來包括（但不限于）：時空復雜度極高、分類器訓練十分困難、負樣本極多（大部分的子序列都是沒有意義的?標簽）等等。

當然，我們仍舊可以通過一些人工規則或設定來減弱這些問題，例如：

• 模型訓練困難：給每個類型單獨訓練一個分類器；

• 時空復雜度：假設最長的實體長度為?，全枚舉子序列時只枚舉長度小于?的所有情況；

• 負樣本很多：在執行分類之前，先訓練一個/多個通用的篩選器，或通過人工規則首先篩掉一批負樣本；在訓練過程中對負樣本進行采樣，而非使用全部。

事實上，目前幾乎所有撇掉 Sequence Labeling，另辟蹊徑的解決方案都是在尋找好用的 2-stage 模型，并致力于減弱這些問題：

• 非常典型地，我們可以以現有的模型骨架（Bi-LSTM、ELMo 等）來簡便地搭建一份上面所描述的模型。[4] 使用了 7 個 Bi-LSTM 與 1 個 ELMo 來提取不同 level 的上下文信息，并使用了一個 Self-Attention 來通過上下文來增強每個子序列的表示。

由于這篇 paper 不會在下面詳細講到，我在這里冒昧做個簡單的評價：

盡管是非常典型的上述 proposal 實現模板，這篇 paper 的建模操作總體而言并不算特別 elegant，并且加了一些人工設定，有少部分的操作甚至難以解讀，而作者也沒有專門去解釋一些操作的含義，導致我讀完之后小小的腦袋里充滿著大大的問號。

我傾向于以為是因為這篇 paper 提出的方案除了約束長度為?的全枚舉以外，其他與上面那個比較 naive 的 proposal 比較接近，所以把它做 work 相對會更難。

在文中作者引入了多個 Bi-LSTM 模型以期學到不同層次的信息，就我而言，此舉本質上是引入了更多的參數量與外部信息以解決這個問題。

另外還有一個比較有意思的設定，想與大家分享：在通過 3 個 Bi-LSTM+1 個 ELMo 讓 token 獲得了全局信息之后，作者將 token 的輸出 通過一個全連接網絡映射到了一個?的空間。

然后表示：這個向量的前?個數值，代表了這個 token 前后的?個子序列是一個合理的實體 candidate 的概率，然后這個空間的后?個數值，代表了它前后個子序列不是一個合理的 candidate 的概率，比較這兩個概率，我們就能對這個包含這個 token 的共?個候選實體進行篩選。

這個設定能夠 work 超過了我的常識。我能理解 Encode 以后的 token 表示中確實有蘊含整個句子中上下文信息。

但就此判定，并期許它所表示的正好就是該 token 附近特定區域的某一概率，似乎比直接用該區域的表示來做出這個判定要來得牽強些。希望有閱讀過這篇 paper 的同學與我討論，解答我的疑惑。

• [5] 給出了思路上與?[4] 相似的解決方案。不過相較于全枚舉，[5] 選擇從另一個角度來獲得候選實體：預測兩個 token 之間相連的概率。如果兩個 token 之間相連的概率較大（在文中體現為值趨向于 0），認為它們在當前 level 更傾向于在同一個實體中。隨后迭代更新實體中每個 token 的表示，就能識別多層的嵌套信息。

• [6] 提出了一個假設：在一個實體中，總會存在一個或多個 token 是該實體的錨點（即如果這個 token 出現，則有相當概率該 token 在一個實體之內。作者以The department of [xxx]中的department為例，闡述它很有可能出現在一個類型為 Organization 的實體中）。由此，我們可以將識別嵌套實體的任務轉換為尋找錨點的任務：首先找到錨點并判定它所代表的類別，隨后找到該錨點所在實體的邊界。

• [7] 將尋找實體的任務視為閱讀理解（Machine Reading Comprehension，下稱 MRC）任務，即：查詢句子中是否存在指定問句的答案。在這里問句代表了一個指定類別的查詢（如：Is there any Location in this sentence?），而作為問句的答案，模型將輸出句子中所有對應實體的開始與結束位置。

• [8] 受到構造一棵語句解析樹過程的啟發，將識別嵌套實體視為一個構造解析樹的過程：在每一個時間步中，模型將根據當前狀態來決定是給指定 token 賦予一個標簽，還是給已經賦予標簽的兩段實體打上一個更高層次的標簽（以此實現了標簽的嵌套），抑或是跳過當前處理的 token。這樣的操作比較像一個內部帶著條件語句的 RNN 單元，它能根據當前的情況來以不同的方式處理一個 token：給它打標簽，或者不做處理。

相關Paper選讀

上面的部分主要是闡述了 Flat NER 與 Nested NER 任務形態上的區別，通過 Sequence Labeling 的缺陷來從各個方面推導出一些可行的解決方案。

由于篇幅與時間所限，接下來我將挑選三篇思路上比較有趣的 paper，來具體闡述研究者是究竟是如何解決 Nested NER 這一任務的。

3.1 逐個token的解析：基于狀態轉換（Transition）的方法

[8] 基于狀態轉換的方法在近三年所提出的 Nested NER 解決方案中占據了一席之地。這個方法有些像編譯原理中的有窮自動機，而且十分相似的一點是，它們確實都在對某個輸入進行解析。

如果對自動機有了解，大家知道自動機的下一個狀態依賴于當前狀態與當前的輸入，而如果從玄學的角度來看待，自動機當前的狀態是由從開始到現在所有的狀態轉換以及所有的輸入共同影響達到的，也就是說當前狀態中理應 Encode 了從開始為止所有操作的信息。

但是實際上，當前的狀態只是一個狀態而已，之前的所有操作與信息都隨著時間的流逝進入到歷史的長河中去了。

現在回頭考慮 Nested NER 的問題：如果我們能通過以一個狀態轉換的形式來解析一個句子，從中提取出所有的嵌套實體，我們首先需要解決的就是如何在當前狀態中把之前的信息也放進來，令人高興的是有一個結構天然帶有這樣的性質：即 時間序列 模型。

首先我們來看一個帶有嵌套實體的句子：

受constituency parsing中 shift-reduce 解析方式的啟發，作者設計出了一個解析上述句子的體系。在整個過程中，我們需要維護下面三個結構：

一個棧（Stack），棧頂元素是當前需要處理的元素。我們需要根據上下文與當前的狀態來決定：忽略該元素、給該元素打標簽，或是將該元素與前一個元素進行復合，打上更高層次的標簽。

一個隊列（Buffer）。隊列中是句子中待處理的剩余 token。

一個操作器（Action）。這個操作器本質是一個模型，它將根據目前的系統狀態來決定執行哪一種解析操作。

解析操作共有下面三種：

SHIFT：將隊列頭部的一個 token 彈出，移入棧中。值得注意的是，這并不代表我們跳過了當前 token 的處理，由棧的功能定義可知，這一步的目的實際是要開始處理這個 token 了；

Unary-X：將棧頂的元素彈出，給它打上標簽 [X]，隨后重新壓入棧中；

Reduce-X：彈出兩次棧頂元素，給它們打上標簽 [X]，隨后重新壓入棧中。

從上述操作中容易看到，只有 Reduce 操作是賦予了實體更高層次，也即嵌套的標簽。

假設目前輸入句子：Indonesian leaders visited him ，一個正確的解析操作序列應該如下圖的 Action 列所示：

上圖的操作十分易懂，在此不多解釋了。值得注意的是在句子的末尾需要添加一個結束符 $，當這個符號被移入棧頂時，意味著整個處理過程的結束（實際上我們也可以通過：下一步要執行的操作是 SHIFT，并且隊列為空 這兩個情況的出現來標志處理過程的結束，不過隊列為空不便于對未處理的句子進行表示，因此作者添加了這一符號）。

這個設定其實非常的有意思（至少我看到的時候是這樣認為的），但是直接移植到嵌套 NER 任務時，仍存在一些亟待解決的問題：

上述的? Unary+Reduce 操作最終得到的解析樹中的每個實體只能是一棵二叉樹（可以參照上圖的解析過程來輔助理解為什么一定是一棵二叉樹）；二叉樹意味著一個被識別出來的實體里面只能包含最多兩個 token，然而現實中非常多的實體是由超過兩個 token 所構成的；

如果不停的進行無意義的操作，會顯著加劇棧所占的內存空間，同時得到的結果是不合理的（例如反復連續執行同一個類型的 Unary），需要對操作進行約束；

最后一個問題，同時也是 Deep Learning 大家族靈魂拷問：在完全正確的 Action 操作順序下，我們確實能完成對嵌套實體的識別，但怎樣判斷當前應該執行哪一個 Action 呢？

好消息是，這些問題都很好解決。對于問題 1，我們引入對于每個標簽?都引入一個輔助標簽?，如果有一個類型為 Person 的實體?，我們只需要轉化為解析結果：

就可以了。對于問題 2，我們人工添加規則來約束，禁止反復給一個元素標多個相同標簽等不符合事實的情況出現。

接下來主要講述的是問題 3，也就是論文的核心部分：如何獲得一個盡可能準確地 Action 序列。下面的處理方式堪稱萬物皆可Embedding的實踐典范。

我們的目的是通過當前整體系統的狀態來判斷接下來應該執行的操作，操作將在上面預定義的三種中任選一種，這就允許我們將其視為一個分類任務。如果我們能夠將整個系統進行表示，集成到一個數值向量中，再通過一個 FFN，就能實現這個分類任務了。

正如上面所說，有三個部分共同構成了當前的整個系統，作者分別對它們進行了表示：

• 隊列中保存的是當前還未處理的所有 token，作者使用了一個反向的 LSTM 來學習這個隊列的表示。之所以使用反向（即從隊列尾開始到隊列頭），是由于我們當前下一個待處理 token 是隊列頭的字符，因此所需要的信息自然是從文本尾部到當前文本的信息；

• 棧中保存的是目前已經處理的 token 以及處理結果（即目前為止嵌套實體的識別結果），與隊列的表示方法相似，從棧底到棧頂使用單向 LSTM 來獲得棧頂元素的表示；值得注意的是，由于棧頂的兩個元素可能會被修改（或因為下一個 token 的移入而被改變），作者在此使用了 Stack-LSTM 來避免頻繁修改帶來的時空開銷；

• • 當一個新 token 被移入棧頂時，基于該 token 的表示與 Stack-LSTM 特性更新新的棧頂表示；

  • 當棧頂元素被執行 Unary-X 操作時，我們將類型?的表示集成到當前棧頂元素的表示中去，即?，其中?是新的向量，是棧頂元素當前向量，分別是類型?的權重矩陣與正則項，表示當前執行的是 unary 操作；

  • 當棧頂元素執行Reduce-X操作時，與上面操作相同，更新棧頂元素的表示為?，其中?分別是次棧頂元素與棧頂元素的表示，即二叉樹的左右子節點。

• 操作器之前所做的歷史操作我們也使用一個結構將其保存下來，并使用一個單向 LSTM 來獲得整體表示，方向為從第 1 個 Action 一直到離當前最近的 Action。

獲得隊列的表示?，操作歷史的表示?與當前棧的表示?之后，當前整個系統的向量就可以表示為三者的拼接：

最后我們使用一個 FFN 來判斷在給定?的條件下應當執行哪一個 Action就可以了。模型最后的 Loss 定義為所有訓練數據中的 Action 的損失之和：

其中?意味第?個句子的第?個動作，Loss 的第二項是一個 L2 正則參數。

簡單總結一下，作者相當于將待處理的文本內容、已處理的文本結果，與已經進行的? Action 操作視為一個系統，將其 Embed 到一個向量中，以表征當前的整體狀態，再基于這個狀態使用分類器來判斷下一步執行的操作。

這里的每一步都在 Embed 層面進行。當然，這樣的做法雖然 work，但這種將一切都看成 Embed，然后使用各種模型結構進行交互的方式，放在自動機體系中或許成立，放在其他應用中，是否仍然可行？

即便可行，這種將所有一切元素都視作表示的思路究竟又是否能夠直觀上進行解釋，能否引申出一條截然不同的理解語言之路，這些都是值得進一步探索的。

3.2 基于超圖（Hypergraph）的方法

現在我們重新審視句子：***... that his fellow pilot Dabid William had ...*** 及其嵌套標注結果（其中 L=Last=End=E, U=Unit=Single=S）：

可以看到，像 his 這樣的 token 雖然嵌套在三個實體中，但只會有兩種取值。我們將每個 token 的相同取值合并，能夠得到下圖所示的 Hypergraph：

值得注意的是，我們需要保證每個 token 至少都有一個 O 標簽。這么做的目的是為了能夠有效的建模每個新實體的開頭的概率。如上圖所示，如果一個 token 沒有 O 標簽，我們需要加一個虛空 O 進去。

接下來，我們期望訓練的模型能夠給定一個輸入的 token，輸出它所有可能的標簽。例如：輸入 his 模型應該輸出??以及 （這里沒有直接預測輸出 O，不過我們會在后面提到加入的虛空 O 應該怎么加入到訓練過程中去）。

我們可以使用一個 Decoder 來實現這個過程。

值得注意的是，雖然這里使用了 Decoder，但是這個 Decode r輸出的標簽數量與輸入的 token 數量是一致的，這也是我在第二章節劃分體系時將其分類到多標簽任務體系，而非修改了 Decode 過程體系的原因：在該模型中，使用 Decoder 的原因并不是因為 Decoder 能夠以生成式的方式產生非等量標簽的特性，而是因為 RNN 家族的單元在 Decoder 中能夠傳遞隱層信息以增強當前標簽識別結果的特性。在這樣的理解上，將這個 Decoder 換成一個表達能力相對較差的 CRF 也是成立的，（雖然效果不會那么好但）大概率也能做 work。

作者在文中提到 we have a decoder-style model 而非直接提出 we apply a decoder，或許也是因為這個原因吧

這個 Decoder 使用的是 LSTM Unit，以下的分析假設讀者已經對 LSTM 的內部結構有一定的了解。

首先，假設我們已經獲得了所有標簽的 Embedding 表示，這個表示可以在訓練時初始化，在訓練過程中進行更新。對于標簽?，它所對應的表示為?。

我們采用以小見大的方式，先來考慮假設已經有了上一個時間步 Unit 的隱層輸出?，上一個時間步的模型輸出?，以及當前時間步輸入的 token 表示?，如何基于這些參數來求出當前的隱層輸出?與當前時間步的模型輸出?。

上一個時間步的模型輸出?是一個概率分布，我們將整個分布通過 softmax 映射到 01 區間，隨后將所有概率大于我們預先設定的 hard threshold: 的標簽找出來。以上圖舉例，如果模型得到我們預期的結果，對于當前 token his，模型應該找到兩個符合閾值要求的標簽?與?。注意，由于這里沒有預測出標簽 O，我們手動給它加上 O 的標簽，即模型最終預測得到?、與?；

由于上一個時間步模型預測得到了三個可能的標簽，我們需要考察這三個標簽在當前步分別可能對應哪個標簽。所以我們將當前的?復制三份，每一份都通過 LSTM 單元計算當前的隱層輸出。特別地，對于上一個時間步的可能標簽，當前時間步的隱層結果為：

這樣，對于上一個時間步的每一個預測結果，我們都能得到對應的當前時間步的隱層表示。現在我們有了三個隱層表示，將它求平均：

其中?就是上一個時間步中所有滿足閾值的標簽數量，在當前我們所講的 case 中取值為 3.

獲得當前時間步的輸出?，其中?分別為 FFN 的權重矩陣與正則項。

以上就是使用類似 Decoder 的形式來逐個輸出每個 token 所有可能標簽的形式，如果上面表述比較難以直接理解，也可以通過 paper 中所給的模型結構圖來比較理解。

與我們的討論過程一致，我們在此給出基于上述思路的損失函數的公式描述：

本質上就是一個多分類交叉熵損失函數，就不再一一講述其中符號的含義了。

作者在文中也比較了使用 softmax 與 sparse softmax 的結果，采用后者是因為作者認為在每個時間步中輸出的標簽大部分都比較少，換言之即比較稀疏，因此使用 sparse softmax 會有更好的效果。

后面的實驗中也證明了這一點：使用 sparse softmax 相較于普通的 softmax，能在 ACE2004 與 ACE2005 測試集中得到 5 個點以上的提升，令人震驚 TAT，有興趣的同學可以去原文中詳細閱讀作者的試驗分析過程。

此外，這里對于一些 word embedding 層、multi-layer Bi-LSTM 層也不再進行詳述，因為他們的實現方式大同小異，只在于使用了靜態 GLoVe 還是動態 ELMo、加 Character LSTM 與否，以及使用了 Bi-LSTM 還是 BERT 作為上下文信息學習框架，亦或在頂層是否添加了一個 Attention 的區別。

3.3 基于閱讀理解的方法

Shannon.AI 在去年年中左右提出了將 NER 任務作為 MRC 來做的思路 [7]。這是目前在 ACE04&05、GENIA 與 KBP2017 四個嵌套實體識別數據集中都位于 SOTA 的方法，尤其在后兩個數據集上做到了大幅度的提升。

此外，作者在中英文的 Flat NER 任務上也進行了測試，都得到了 SOTA 的結果。

據筆者所知，MSRA有位同學應該做了更好的結果出來，不過考慮它要投的頂會時間，保守估計在5月份才會掛到Arxiv上，讓我們一起期待吧: )

MRC 任務一般可以被形式化表述為：

給定一段信息(passage)與給定一個問題(question)，模型需要從信息中找到回答這個問題的短語(span)。

從任務理解上來看，這個解決思路似乎與NER是十分相似的：我們只需要將每個標簽?都看做一個問句：這個句子中的?標簽的實體是什么？ 隨后輸入待抽取實體的句子進行詢問，然后將模型輸出的短語作為這個句子中?標簽的實體就好了。

乍一聽這個方法充滿了玄學，但當我們擁有一個 BERT 的時候，這個任務就非常好做了。由于預訓練時的任務設計，BERT 天生就允許往模型中同時輸入兩個不同的句子。我們向 BERT 中以下面的形式輸入問題與信息：

其中 [CLS] 與 [SEP] 分別用于標識一個輸入的開頭與間隔兩個句子。然后靜靜等待模型給我們結果就可以了。

問題是，怎么拿到這個結果，再將這個結果復原回原來的實體結果呢？

作者訓練了三個分類器，分別用于預測模型輸出后的：

• 當前 token 是否為一個實體的開頭位置；

• 當前 token 是否為一個實體的結束位置；

• 前兩個分類器中的兩兩位置是否匹配（如果開頭位置?與結束位置?匹配，我們就認為從?是一個實體。

如果沒有完全理清楚整個處理邏輯，你可能會有疑惑：即便我知道了?是一個實體，但是這個實體類型是什么呢？答案是：這個實體類型就是這個問題的類型，如果問題的類型是：這個句子中 PERSON 的實體是什么，那么抽出來的實體類型就是 PERSON。是不是非常有趣？

如此看來，一個問題的優秀程度直接影響了模型抽取實體的效果，那如何設計問題呢？

首先要明確的一點是，像我們上文一直使用的：這句子中的 [X]實體是什么？ 這種問句是十分不合理的。

想象一下更換不同的 [x] 時，整個句子的其他 token 表示都沒有變，只有 [x] 所在的一個或幾個 token 的表示被改變了，我們怎么能寄希望于模型像找茬一樣能夠分清楚這些問句之間微小的差異，并將其有效應用在文章理解中呢？

作者在 paper 中討論了多種問句的設計方式，有興趣的同學可以自行閱讀原文。作為問句設計的結果，作者最后使用了數據一開始標注時的每個標簽的指南來作為一個問句：我們在人工標注一個數據之前，如果希望能夠標出 Location 標簽，我們首先會對 Location 進行一個定義，如：

Location: Find locations in the text, including non-geographical locations, mountain ranges and bodies of water. (地點：找到文中所有的地點，包括非地理的位置，山脈與水體。)

使用類型標注指南作為定義在結果上會 work，個人覺得是因為指南中會存在許多 "head word"（還記得上面所提到的 department 會有很大概率作為 organization 實體的 head word嗎？），與此同時這些head word基本不會出現在其他標簽的標注指南中。

這些非常 unique 的信息作為問句，能夠讓模型很好地區分當前的問題，從而在句子中找到更加精確的實體。

作為以上任務設計的結果，整個模型的損失函數由：起始位置識別+末尾位置識別+位置匹配三者的交叉熵損失之和決定，即：

跋

以上就是近幾年來 Nested NER 領域的整體研究現狀綜述，在最后想加點我的個人感想。

在第二部分我著重從我理解的角度出發，來分析為什么 Nested NER 不適用于現在普遍應用的 NER 任務的解決方案。

也從我個人的感受出發，給近幾年所有的相關 paper 分了體系，其劃分依據主要是撇開整個故事不談，從模型角度它究竟修改了原來 NER 解決方案中的哪個部分，或者說解決了其中哪個不足。

于是在第三部分，我解讀了三篇我覺得非常有意思的解決方案。他們可能不是結果最好的，但都給我以眼前一亮的感覺：原來這個問題還能這么做。

我覺得從接觸一個領域，到了解該領域的研究現狀，到提出該領域存在的不足，這三個過程是每個研究過程中都不可或缺的，但是最重要的是在此之后針對存在的問題，提出有效的解決方案。

作為全新角度來解決問題的 paper，他們一開始的構思可能比較簡單，但之后也能通過人為增加約束的形式將任務做 work，這是研究中不斷實驗進步的過程。而后面這兩個過程，才是研究者能否做出有獨創性、有價值成果的決定性因素。

畢竟只會前三步的我，只能寫博客，而掌握后兩步的大家，就能發頂會了。

與君共勉。

References

[1] Nested Named Entity Recognition Revisited

[1] Straková, Jana, Milan Straka, and Jan Haji?. "Neural architectures for nested NER through linearization." arXiv preprint arXiv:1908.06926 (2019).

[2] Straková, Jana, Milan Straka, and Jan Haji?. "Neural architectures for nested NER through linearization." arXiv preprint arXiv:1908.06926 (2019).

[3] Shibuya, Takashi, and Eduard Hovy. "Nested Named Entity Recognition via Second-best Sequence Learning and Decoding." arXiv preprint arXiv:1909.02250 (2019).

[4] Xia, Congying, et al. "Multi-Grained Named Entity Recognition." arXiv preprint arXiv:1906.08449 (2019).

[5] Fisher, Joseph, and Andreas Vlachos. "Merge and Label: A novel neural network architecture for nested NER." arXiv preprint arXiv:1907.00464 (2019).

[6] Lin, Hongyu, et al. "Sequence-to-nuggets: Nested entity mention detection via anchor-region networks." arXiv preprint arXiv:1906.03783 (2019).

[7] Li, Xiaoya, et al. "A Unified MRC Framework for Named Entity Recognition." arXiv preprint arXiv:1910.11476 (2019).

[8] Wang, Bailin, et al. "A neural transition-based model for nested mention recognition." arXiv preprint arXiv:1810.01808 (2018).

點擊以下標題查看更多往期內容：?

• 可提速3000倍的全新信息匹配架構
  

• WWW 2020 開源論文 | 異構圖Transformer
  

• 淺談 Knowledge-Injected BERTs
  

• Transformer的七十二變
  

• 基于背景知識的參考感知網絡對話模型
  

• 從 Word2Vec 到 BERT

????

現在，在「知乎」也能找到我們了

進入知乎首頁搜索「PaperWeekly」

點擊「關注」訂閱我們的專欄吧

關于PaperWeekly

PaperWeekly 是一個推薦、解讀、討論、報道人工智能前沿論文成果的學術平臺。如果你研究或從事 AI 領域，歡迎在公眾號后臺點擊「交流群」，小助手將把你帶入 PaperWeekly 的交流群里。

與50位技術專家面對面20年技術見證，附贈技術全景圖

總結

以上是生活随笔為你收集整理的浅谈嵌套命名实体识别（Nested NER）的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。