91欧美超碰AV自拍|国产成年人性爱视频免费看|亚洲 日韩 欧美一厂二区入|人人看人人爽人人操aV|丝袜美腿视频一区二区在线看|人人操人人爽人人爱|婷婷五月天超碰|97色色欧美亚州A√|另类A√无码精品一级av|欧美特级日韩特级

0
  • 聊天消息
  • 系統(tǒng)消息
  • 評論與回復
登錄后你可以
  • 下載海量資料
  • 學習在線課程
  • 觀看技術視頻
  • 寫文章/發(fā)帖/加入社區(qū)
會員中心
創(chuàng)作中心

完善資料讓更多小伙伴認識你,還能領取20積分哦,立即完善>

3天內不再提示

詞匯知識融合可能是NLP任務的永恒話題

深度學習自然語言處理 ? 來源:丁香園大數(shù)據(jù) ? 作者:丁香園大數(shù)據(jù) ? 2021-05-08 11:22 ? 次閱讀
加入交流群
微信小助手二維碼

掃碼添加小助手

加入工程師交流群

得益于BERT的加持,Encoder搭配CRF的結構在中文NER上通常都有不錯的表現(xiàn),而且BERT使用方便,可以迅速微調上線特定服務;在好的基準條件下,我們也能把精力放在更細節(jié)的問題中,本文并不以指標增長為目標,而是從先驗知識融合與嵌套實體問題兩方面討論,希望可以從這兩個方向的工作中獲得解決其他問題的啟發(fā)

融合詞匯知識

Chinese NER Using Lattice LSTM

融合詞匯知識的方法可能適用于NLP問題的每個子方向,也是近幾年中文NER問題的大方向之一;因為中文分詞的限制,加之有BERT的加成,如今基本默認基于字符比基于分詞效果更好,這種情況下,引入詞匯知識對模型學習實體邊界和提升性能都有幫助,Lattice LSTM是這一方向的先行者

相比于char和word級的RNN,Lattice LSTM加入了針對詞匯的cell,用以融合詞匯信息;計算上比char-cell少一個output gate,此外完全一致,可以理解為在傳統(tǒng)LSTM鏈路中插入了一組LSTMCell,具體可以對照原文公式10-15理解(下圖公式11為LSTMCell,公式13為WordLSTMCell):

f8fff604-aeed-11eb-bf61-12bb97331649.png

FLAT: Chinese NER Using Flat-Lattice Transformer

Lattice LSTM驗證了融合詞匯信息提升中文NER任務的可行性,就是有點慢,每句話要加入的詞匯不一樣,無法直接batch并行,此外Lattice LSTM沒法套BERT,現(xiàn)成的BERT不能用太不甘心;于是就有了同時彌補這兩點的FLAT,并且其融合詞匯的實現(xiàn)方式也簡單的多:如圖,F(xiàn)LAT融合詞匯的方式就是拼接,詞匯直接拼在輸入里,此外只需改造Postion Embedding,將原始的位置編碼改為起止位置編碼

不過Postion Embedding的改造還不止于此,為了讓模型學習到詞匯span的交互信息,這里還引入了相對位置編碼:如圖,長度為N的輸入會產(chǎn)生4個N * N的相對位置矩陣,分別由:head-head,head-tail,tail-head,tail-tail產(chǎn)生

f94fcb2a-aeed-11eb-bf61-12bb97331649.png

綜上,基于Transformer的FLAT可batch并行,速度自然優(yōu)于Lattice LSTM,同時又可以套用BERT,在常用中文NER數(shù)據(jù)集上都有非常出色的表現(xiàn);FLAT的顯存占用比較高,但用顯存換來的推理時間減少肯定是值得的

Leverage Lexical Knowledge for Chinese Named Entity Recognition via Collaborative Graph Network

通過詞匯增強模型識別邊界的能力很重要,然而Lattice LSTM在這方面還存在信息損失,受限于構造方式,詞匯表示只能加給最后一個字,這樣有什么問題呢?以本文CGN中提到的“北京機場”為例,想要成功標出“北京機場”而非“北京”,需要模型將“機”識別為“I-LOC”,而非“O”或“B-LOC”,然而Lattice LSTM中的詞匯并不影響“機”的encoding;此外,Lattice LSTM的融合方式說明詞匯只對實體本身有幫助,然而正確識別實體可能也需要臨近詞匯的幫助,例如下圖的“離開”表明“希爾頓”是人名而非酒店

f9587568-aeed-11eb-bf61-12bb97331649.png

復雜的字詞關系無法通過RNN結構表示,選擇Graph更為靈活,本文通過融合三種圖結構學習復雜關系,利用GAN提取特征,獲得倍數(shù)于Lattice LSTM的速度提升

f97d6e5e-aeed-11eb-bf61-12bb97331649.png

如圖所示,在LSTM編碼輸入文本并傳入詞匯表示后,模型會經(jīng)過三種策略的構圖層:

Word-Character Containing graph(C-graph):負責學習自匹配特征和詞匯邊界信息

Word-Character Transition graph(T-graph):負責構造字詞相互之間的上下文鄰接關系

Word-Character Lattice graph(L-graph):負責捕捉自匹配特征和隱含的詞匯鄰接關系

圖表示完成后,通過Fusion層的線性結構融合特征,再傳給CRF做標簽decoding即可;雖然流程上比FLAT復雜一些,但一方面其非batch并行版的速度更快(不知道算不算建圖的時間),另外文中提供的各種詞匯融合思路也值得學習借鑒,從詞匯邊界和覆蓋本身考慮,上下文語義貢獻的作用,已經(jīng)圖結構帶來的額外特征或許可以作為特定任務的預訓練過程拆解使用

嵌套實體問題

嵌套實體在標注應用場景下很少被顧及,一方面?zhèn)鹘y(tǒng)序列標注模型也只能選擇一個,另外標注數(shù)據(jù)時我們就只根據(jù)語義選擇其中一個;但嵌套實體本身是存在的,比如醫(yī)療場景下的疾病詞常由身體部位和其他詞構成,即便不作為NER任務本身看待,讓模型能學習標識嵌套實體,對實際場景中的其他任務也大有益處

Pyramid: A Layered Model for Nested Named Entity Recognition

通過多層結構抽取嵌套實體是一種容易理解的模型,2007年就有工作通過堆疊傳統(tǒng)NER層處理嵌套問題,不過之前的工作都無法處理嵌套實體重疊的情況,并且往往容易在錯誤的層級生成嵌套實體(即實體本身存在,但不該在當前層識別到,否則會影響后續(xù)層的識別,從而破壞整體模型效果);本文針對這兩個問題提出的金字塔結構

f9b2aa9c-aeed-11eb-bf61-12bb97331649.png

金字塔結構的思想如圖所示,最底層為最小的文本單元,每一層負責長度為L的實體的識別,通過CNN向上聚合,模型不會遺漏重疊實體span,同時由于L的限制,該結構不會在錯誤的層生成不對應的實體;作者還認為高層span的信息對底層也有幫助,所以還設計了逆向金字塔結構,具體實現(xiàn)如下

f9c4a1ac-aeed-11eb-bf61-12bb97331649.png

在經(jīng)過LSTM編碼后,自底向上的Decoding層為每一層預測對應標簽,因為按長度區(qū)分,所以理論上只需要預測“B-”,但這樣模型就必須堆疊N層才能覆蓋全部span,不然就無法預測長度超過l的實體,所以作者設計了補救措施,在最高層同時預測“B-”和“I-”

f9e3f002-aeed-11eb-bf61-12bb97331649.png

Pyramid表現(xiàn)了處理嵌套問題的重要方向,即構造和編碼潛在實體span,下面的工作也都遵循這一點設計實現(xiàn)各種模型結構

A Unified MRC Framework for Named Entity Recognition

本文徹底放棄了序列標注模型,用閱讀理解的方法處理嵌套實體,即預測起止位置和實體分類;由起止位置標識的實體當然允許覆蓋,自然就解決了嵌套問題;熟悉MRC的同學很快就會發(fā)現(xiàn),通常的MRC只有一個答案span,然而一句話中可能存在多個實體span,怎么表示多個實體?因此本文修改了MRC的結構,首先起止位置預測:

fa12bd10-aeed-11eb-bf61-12bb97331649.png

預測P_end也是同樣的結構,這里類似序列標注,表示每個char為起止位置的概率分布,這樣就產(chǎn)生了a個起始位置和b個終止位置,理論上存在 a * b 個實體span;而后還需要一個模塊計算a * b個匹配中有多少個真的是實體,即:

fa1d9668-aeed-11eb-bf61-12bb97331649.png

到此便解決了預測起止位置識別實體的問題,下面需要對每個實體span分類;通常的做法都是設計分類器,區(qū)別僅在于傳入分類器的表示,本文的分類則十分新穎,也十分MRC,即:給輸入文本拼接一個指向特定實體的問題,在這個問題下找出的span都屬于這一類

本文思路新穎,實現(xiàn)簡單且可套用BERT等不同Encoder,在傳統(tǒng)NER和Nested-NER數(shù)據(jù)集上都有sota或接近的水準;唯一的遺憾是不適合多實體類別的應用服務,因為針對K個類別都要單獨設計問題,所以相當于在預測時把每個問題都問一遍,時間開銷或顯存開銷擴大K倍是無法避免的

TPLinker: Single-stage Joint Extraction of Entities and Relations Through Token Pair Linking

本文是實體關系聯(lián)合抽取的工作,雖然思路上基本遵循實體識別-》關系分類的流程,但實現(xiàn)上于尋常工作有巨大差別;雖然并不是中文數(shù)據(jù)集上的工作,但在嵌套實體的處理思路上,本文與尋常工作也有巨大差別,很有借鑒意義;這里首先介紹對普通實體,頭實體,尾實體的標識方法:

fa34180c-aeed-11eb-bf61-12bb97331649.png

如圖所示,既然存在嵌套實體,那么不妨假設任意兩個char都可能構成實體,這樣就形成左圖的N * N矩陣,模型通過二分類即可標識出存在的實體;不過文本是單向的,所以實體的start一定在end前面,這樣就有了右圖,即矩陣包括主對角線的下三角矩陣可以忽略,這樣矩陣flat后的長度就從N * N減少到 (N + 1) * N / 2;因為是實體關系聯(lián)合抽取,所以分別用三種顏色標識,紫色標記普通實體,紅色標記同一關系下的頭實體,藍色標記尾實體,代碼實現(xiàn)上對應三種分類器;另外由于一對實體可能存在多種關系,所以需要為每種關系準備一個分類器,如下圖

fa46be6c-aeed-11eb-bf61-12bb97331649.png

筆者認為TPlinker處理嵌套問題的思路與MRC頗有幾分相似,矩陣中每個元素都是一個span,既然存在嵌套,我們就不得不假設任意兩個char都可能構成實體;此外,雖然最終要在 (N + 1) * N / 2長的序列上預測實體,但顯存占用之類的問題并沒有那么明顯,因為這個平方級的序列是在Encoder輸出后拼成的,我們還可以通過設置一些約束進一步減少長度;不過要注意,這個長序列的預測可能非常稀疏(一句話里的實體很少,按長度平方后0占比更大)

Span-based Joint Entity and Relation Extraction with Transformer Pre-training

本文同樣是實體關系聯(lián)合抽取,處理嵌套問題的思路與TPlinker類似,窮舉出全部的潛在實體,然后用分類器識別;如下圖所示

fa797f78-aeed-11eb-bf61-12bb97331649.png

與TPlinker類似,在輸入文本經(jīng)過BERT后,sequence_output被用來構造潛在實體,理論上所有的ngram都是潛在實體,所以這里需要拼出全部ngram再通過span分類器識別實體,過濾非實體;文中提到一個小trick,給span classifier傳入的向量表示除了sequence_output[span]和[CLS]外,還包含一個width embeddings向量,因為某些長度的span不大可能的實體,希望模型可以學到這一點;那么對于TPlinker和spERT,我們也都可以通過長度約束減少span的個數(shù),手工降低模型的計算開銷;最后關系分類的做法很直觀,融合各路語義向量表示,通過sigmoid生成對應K個關系的1維向量,每個維度通過閾值判定是否存在該類關系

總的來說,Pyramid、MRC、TPLinker、spERT處理嵌套問題的出發(fā)點基本一致,從傳統(tǒng)的token級標注轉變?yōu)閷撛趯嶓wspan的標注;實現(xiàn)上各有特點,Pyramid設計了分層結構,TPlinker的矩陣構造非常靈性,不過平方級長度的序列太過稀疏;spERT雖然理論上也有平方級數(shù)量的span,但真實訓練可以通過負采樣降低訓練壓力;MRC做分類的想法很是獨特,不過對于多類別場景可能計算壓力過大,或許可以分離entity識別和分類,避免多次BERT計算的開銷

總結

詞匯知識融合可能是NLP任務的永恒話題,利用詞匯知識增強NER模型的想法也非常自然,Lattice LSTM及其后續(xù)工作展開了一個很好的方向,引入詞匯關聯(lián)結構提升模型也許在其他任務上也有很大收益;嵌套實體問題在當前的實際應用場景也許重視度還不夠,但問題本身切實存在,這方面的工作往往在潛在實體span的識別上有獨特的創(chuàng)新點,通過拆解和重組傳統(tǒng)的序列分類和標注模塊,引入MRC機制等思路,為我們解決復雜NLP問題帶來新的思路

原文標題:中文NER碎碎念—聊聊詞匯增強與實體嵌套

文章出處:【微信公眾號:深度學習自然語言處理】歡迎添加關注!文章轉載請注明出處。

責任編輯:haq

聲明:本文內容及配圖由入駐作者撰寫或者入駐合作網(wǎng)站授權轉載。文章觀點僅代表作者本人,不代表電子發(fā)燒友網(wǎng)立場。文章及其配圖僅供工程師學習之用,如有內容侵權或者其他違規(guī)問題,請聯(lián)系本站處理。 舉報投訴
  • 深度學習
    +關注

    關注

    73

    文章

    5598

    瀏覽量

    124396
  • nlp
    nlp
    +關注

    關注

    1

    文章

    491

    瀏覽量

    23280

原文標題:中文NER碎碎念—聊聊詞匯增強與實體嵌套

文章出處:【微信號:zenRRan,微信公眾號:深度學習自然語言處理】歡迎添加關注!文章轉載請注明出處。

收藏 人收藏
加入交流群
微信小助手二維碼

掃碼添加小助手

加入工程師交流群

    評論

    相關推薦
    熱點推薦

    自然語言處理NLP的概念和工作原理

    自然語言處理 (NLP) 是人工智能 (AI) 的一個分支,它會教計算機如何理解口頭和書面形式的人類語言。自然語言處理將計算語言學與機器學習和深度學習相結合來處理語音和文本數(shù)據(jù),這些數(shù)據(jù)也可以與其他類型的數(shù)據(jù)一起用于開發(fā)智能工程系統(tǒng)。
    的頭像 發(fā)表于 01-29 14:01 ?361次閱讀
    自然語言處理<b class='flag-5'>NLP</b>的概念和工作原理

    合同郵件?企業(yè)鏈接?可能是木馬的最佳偽裝

    行業(yè)資訊
    江蘇易安聯(lián)
    發(fā)布于 :2026年01月22日 11:27:18

    IEEE 802.11af 與空白頻譜無線技術的話題

    IEEE 802.11af 與空白頻譜無線技術的話題
    的頭像 發(fā)表于 12-14 15:12 ?1566次閱讀

    Unix的相關知識

    有無關的信息干擾。 (3)盡可能早地將設計和編譯的軟件投入試用,對拙劣的代碼別猶豫,扔掉重寫。 (4)優(yōu)先使用工具而不是拙劣的幫助來減輕編程任務的負擔,工欲善其事,必先利其器。 2 編碼原則 Unix
    發(fā)表于 12-10 07:13

    RK3576驅動高端顯控系統(tǒng)升級:多屏拼控與AI視覺融合解決方案

    下達任務指令,副屏監(jiān)測 AI 分析結果,大屏實時展示各區(qū)域畫面與運行狀態(tài),真正實現(xiàn) “一屏決策,多屏聯(lián)動”。 八路攝像頭輸入:實現(xiàn)多源視頻融合與 AI 識別RK3576 原生支持八路攝像頭輸入
    發(fā)表于 11-21 17:51

    FreeRTOS任務調度及優(yōu)先級問題

    ,對于通信的時序要求比較嚴格,F(xiàn)reeRTOS這種輪轉機制會不會導致一些通訊被打斷(比如通信的數(shù)據(jù)并不完整,數(shù)據(jù)發(fā)送到一半因為任務調度就被打斷了?) 這可能只是我的一些不切實際的猜想,因為芯片通信一般
    發(fā)表于 11-06 02:18

    電機驅動emc整改:總不過關?可能是接地方式錯了

    電機驅動emc整改:總不過關?可能是接地方式錯了|深圳南柯電子
    的頭像 發(fā)表于 10-14 15:44 ?699次閱讀

    國巨電容出現(xiàn)漏液現(xiàn)象,可能是哪些原因導致的?

    國巨電容出現(xiàn)漏液現(xiàn)象,可能是由密封結構失效、電化學腐蝕、機械損傷、材料老化、環(huán)境應力以及制造缺陷等多種因素導致的,以下是對這些原因的詳細分析: 密封結構失效 焊接不良 :國巨電容的金屬外殼與密封蓋
    的頭像 發(fā)表于 09-29 14:21 ?609次閱讀
    國巨電容出現(xiàn)漏液現(xiàn)象,<b class='flag-5'>可能是</b>哪些原因導致的?

    Task任務:LuatOS實現(xiàn)“任務級并發(fā)”的核心引擎

    Task任務通過其強大的并發(fā)處理能力,使LuatOS能夠在單線程環(huán)境中模擬多線程執(zhí)行,通過協(xié)程的掛起與恢復機制,實現(xiàn)任務級的并行操作,顯著提升系統(tǒng)效能。 sys核心庫是LuatOS運行框架庫,也是
    的頭像 發(fā)表于 08-28 13:49 ?508次閱讀
    Task<b class='flag-5'>任務</b>:LuatOS實現(xiàn)“<b class='flag-5'>任務</b>級并發(fā)”的核心引擎

    七百多頁電機中英文詞匯收藏分享

    本書共收錄了50000余詞條,除重點涵蓋了發(fā)電機和電動機產(chǎn)品從設計、工藝、生產(chǎn)制造、試驗到安裝運行等方面的專業(yè)技術詞匯外,還兼收了一些近年新涌現(xiàn)出來的新能源、新技術方面的詞匯。此外,為滿足讀者翻譯
    發(fā)表于 07-17 14:23

    軟通動力攜手華為云推出AI知識引擎與數(shù)據(jù)工程融合創(chuàng)新解決方案

    在華為開發(fā)者大會2025中,軟通動力攜手華為云以華為云昇騰AI、盤古大模型、ModelArts等為技術底座,全新升級數(shù)據(jù)治理基線解決方案,正式發(fā)布AI知識引擎與數(shù)據(jù)工程融合創(chuàng)新解決方案(包括軟通動力
    的頭像 發(fā)表于 06-28 17:07 ?1604次閱讀

    攜手共塑物料搬運未來,永恒力與EP設備達成戰(zhàn)略合作

    ·永恒力攜手EP設備共同推動并擴展全球工業(yè)電氣化進程?!?b class='flag-5'>永恒力將以“AntOnbyJungheinrich”為名設立全新中端科技品牌?!ねㄟ^戰(zhàn)略合作,雙方將實現(xiàn)“為每一位客戶提供真正適合的叉車”目標
    的頭像 發(fā)表于 05-13 16:40 ?746次閱讀
    攜手共塑物料搬運未來,<b class='flag-5'>永恒</b>力與EP設備達成戰(zhàn)略合作

    ADMT4000參照示例讀取圈數(shù)數(shù)據(jù)正常,但是斷電后再次上電重新讀取,發(fā)現(xiàn)讀數(shù)返回為0,請問可能是啥原因???

    ADMT4000參照示例讀取圈數(shù)數(shù)據(jù)正常,但是斷電后再次上電重新讀取,發(fā)現(xiàn)讀數(shù)返回為0,請問可能是啥原因??? 謝謝
    發(fā)表于 04-16 06:47

    使用AD芯片對正弦波采樣,得到這樣的結果,可能是哪里出現(xiàn)問題?

    使用AD芯片對正弦波采樣,得到這樣的結果,可能是哪里出現(xiàn)問題?
    發(fā)表于 04-03 18:51

    用touchgfx生成了代碼,也能編譯成功,但下載之后無法顯示圖像,可能是什么原因?

    我用touchgfx生成了代碼,也能編譯成功,但下載之后無法顯示圖像,可能是什么原因?
    發(fā)表于 03-07 06:39