自然語言處理中的分詞問題總結
眾所周知,英文是以詞為單位的,詞和詞之間是靠空格隔開,而中文是以字為單位,句子中所有的字連起來才能描述一個意思。把中文的漢字序列切分成有意義的詞,就是中文分詞,有些人也稱為切詞。本文 轉載自明略研究院的技術經理牟小峰老師講授的語言處理中的分詞問題。
如何界定分詞
中文分詞指的是將一個漢字序列切分成一個一個單獨的詞。分詞就是將連續的字序列按照一定的規範重新組合成詞序列的過程;在英文中,單詞之間是以空格作為自然分界符,漢語中詞沒有一個形式上的分界符。 (見百度百科) 正因為缺乏形式上的分界符,導致我們對詞的認定會出現很大的偏差。1996 年 Sproat 等透過對 6 個母語為漢語的人進行調研,讓這 6 人對同一篇中文文字進行人工切分,文字包括 100 個句子,最後統計認同率,見下表:
不僅普通人有詞語認識上的偏差,即使是語言專家,在這個問題上依然有不小的差異,這種差異反映在分詞語料庫上。不同語料庫的資料無法直接拿過來混合訓練。
以前曾經出過分詞規範 (GB13715),以“結合緊密,使用穩定”作為分詞建議,後來發現這個建議彈性太大,不同的人有不同的理解,無法有效實施。
為了統一對詞語的認識,現在主要透過 “分詞規範、詞表、分詞語料庫”來使得詞語切分可計算,例如北大的“詞語切分與詞性標註”規範。基於上述種種工作,可以把詞語切分問題變得可操作和標準化,大家在統一的平臺上進行實驗和比較。
對分詞的訴求是什麼?
從已有工程經驗來看,幾乎不存在通用而且效果非常好的分詞系統,例如:在人民日報上訓練的分詞系統,在二次元的魔幻小說上切分效果不佳。每個領域有其獨特的詞彙表示,這很難透過有限的訓練資料捕捉到所有語言現象。
不用使用場景對分詞的要求差異很大。在搜尋的索引階段,往往會召回所有可能切分結果,對切分準確率要求不高,但對分詞速度有很高的要求,例如某中型搜尋系統,每天 4000 萬篇文章入庫,每秒要處理 500 篇文件,每秒處理的文件位元組數約有 50MB;如果分詞系統太慢的話,需要開大量執行緒才能處理這些文件。
在問答系統中,需要對文字實現較為深入的理解,對分詞和實體識別的準確性要求很高。
不用的使用場景,對分詞提出了不同的要求,不需要片面地追求高準確率。
別家系統的準確率怎麼這麼高?
在分詞系統研發中,最容易產生誤解的就是比較系統準確率。系統準確率與訓練資料非常相關,脫離資料而談論準確率無異於 “刷流氓”。2003 年 863 分詞評測中就出現了 98% 的準確率,2007 年 Sighan 評測中最高準確率是 97%,在最近某司組織的評測中,最高準確率下降到了 94%。所有不同資料下的評測結果都不能直接比較高低。
現在吹噓分詞準確率的公司和單位越來越少了。
分詞穩定性很重要
分詞穩定性是指分詞系統的輸出在不同上下文下都比較穩定,不會出現明顯被上下文影響的情況。例如,在下面句子中, “黃代恆”有時識別為人名,第二次出現未識別出來:
實戰 分享 三 黃代恆 /nr 與 軌道 交通 : 軟硬 結合 到 人機 結合 黃代恆 “ 在 不同 的 客戶 場景 下 , 我們 用 三 種 技術 實現 軌道 交通 的 資料 洞察
一般純統計分詞系統的穩定性比不上基於詞典實現的分詞系統。在搜尋中,分詞穩定性非常重要,否則極容易出現查詢不到的情況。
已有分詞系統小結
分詞大概是投入人力非常大的 NLP 方向,幾乎每一家“有追求”的公司都有員工實施過類似的任務,而且反覆迭代更新;在 NLP 研究界,這個問題從上個世紀 80 年代就已經開始探索,一直到 ACL 2017 仍然有這方面的論文 (有 4 篇叢神經網路角度探索分詞的文章)。
如此多的人力投入到分詞理論研發和工程研發中,產生了一批各有特色的分詞系統。下面僅僅就本人接觸到的系統作說明 (排名無先後),比較“古老”的系統不在此羅列:
IK 系統
該系統採用 JAVA 開發,實現邏輯不復雜,由於對 Lucene 和 ES 支援較好,因而得到了比較普遍的使用。該系統可以實現英文單詞、中文單詞的切分,OOV 識別能力不強。該系統有幾種使用模式,分別對應不同的使用場景,如索引、查詢等。
IK 有些功能比較貼心,比如熱更新使用者詞典,支援使用者自定義詞典非常方面,對搜尋工程師比較友好。
IK 的程式碼實現上最佳化不夠好,甚至能發現 BUG。我們發現的 BUG 會導致 ES 中長 Query 無法實現精準匹配。
對於中小企業的內部應用來說,使用 IK 足夠了。在商業系統上使用的話,要非常慎重,參與最佳化的人員太少了。
Jieba 系統
Jieba 大概是最好用的基於 Python 實現的分詞系統了,2-3 行程式碼就可以實現分詞呼叫和詞性標註,速度還不錯。基於 HMM 模型實現,可以實現一定程度的未登入詞識別。
Jieba 有精確模式、全模式、搜尋模式三種。全模式是找到所有可能詞語;搜尋模式是在精確模式的基礎上對長詞進行切分,提高召回率。
支援繁體分詞;支援自定義詞典;支援並行分詞,方便實現加速。
在分詞速度上,精確模式能達到 400KB/ 秒,全模式下能達到 1.5MB/ 秒。
Jieba 除了 Python 版本外,還有多種語言實現的版本,包括 C++, JAVA, Golang 等。
Java 版本的 Jieba 功能上受限,僅面向搜尋使用。明略 SCOPA 產品中使用了 Java 版本的 Jieba 作為分片語件,替換了 IK。
Hanlp 平臺
Hanlp 是一個功能非常全面的 NLP 平臺,它的分詞介面借鑑了 Ansj 的設計,形式上和命名上都非常像。
Hanlp 有“簡約版”和“加強版”,簡約版的模型引數較小,分詞能力還可以;加強版在模型引數上擴大了若干倍,分詞能力進一步提升。
Hanlp 支援基於 HMM 模型的分詞、支援索引分詞、繁體分詞、簡單匹配分詞(極速模式)、基於 CRF 模型的分詞、N- 最短路徑分詞等。實現了不少經典分詞方法。
Hanlp 的部分模組做了重要最佳化,比如雙陣列,匹配速度很快,可以直接拿過來使用。
Hanlp 做了不少重現經典演算法的工作,可以去 GitHub 上看一下!
ICTCLAS 系統
ICTCLAS 大概是“最知名”的分詞系統了,從參加 2003 年中文分詞評測,一直延續到了現在。現在已經是商業系統了 (改名 NLPIR),需要 License 才能執行。
從未登入詞識別準確率上說, ICTCLAS 已經明顯落後於基於 CRF 的分詞系統了。
儘管如此,它的優點仍然比較明顯:很少出現 “錯得離譜”的切分結果,這在基於 CRF 模型的分詞系統上不少見,尤其是遷移到其它領域時;模型和庫不大,啟動快;基於 C++ 實現,能夠很快遷移到其它語言。
從分詞穩定性上來說, ICTCLAS 值得信賴,從分詞準確率、分詞速度等方面來考量,有不少分詞系統超過了它;NLPIR 的原始碼已經不再開放,這讓使用者很糾結。
交大分詞
所謂 “交大分詞”,是指上交大趙海老師個人主頁上的分詞系統。該系統在 2007 年 Sighan 評測中拿到了多項第一。
該系統基於 CRF 模型構建,在模型特徵提取上做了大量工作,分詞準確率比較高。目前可用版本支援簡體、繁體分詞,也支援不同分詞標準。該系統被常常用來比較分詞準確率。
該系統的問題是不開源,只有 Windows 上的可執行檔案,C++ 原始碼需要向作者申請。雖然該系統不開源,但作者的一系列論文基本上揭示了其原理,複製起來並不難。
從工程角度來考慮,該系統只適合做 DEMO 元件,不適合大規模工業化使用。
Stanford 分詞
Stanford 分詞系統的優點是準確率高,未登入詞識別能力比較強;缺點非常明顯,模型很大,約 300MB-400MB,啟動非常慢,大概需要 10 秒 -20 秒。在所有分詞系統中,沒有比 Stanford 啟動更慢的系統,分詞速度也不快。程式碼最佳化的空間比較大。
Stanford 系統支援自定義訓練,只要使用者提供訓練資料,該系統可以訓練新的模型引數。
Stanford 分詞系統只是驗證作者論文的一種手段,為了非常微小的分詞準確率提升,導致了模型引數膨脹。
在 Demo 環境下可以使用 Stanford 系統,在大規模資料環境下不適合使用該系統。
GPWS 系統
GPWS 是北京語言大學語言資訊處理研究所研發的分詞系統,2001 年對外發布。該分詞系統是 2000 年後唯一一個基於大規模規則 + 統計的分詞系統(僅限個人所知),在 2004 年非常低的硬體配置下,分詞速度也能達到 3MB-5MB/ 秒,對系統資源的消耗很低。後來授權給了新浪、微軟等公司使用,被應用在了資訊檢索中。
GPWS 可以實現中文人名、外國人名、日本人名的識別,其它分詞系統幾乎都沒有做到這個程度;對通用領域的文字切分效果較好,支援自定義詞典;很少出現切分“離譜”的情況。該系統適合大規模資料處理的場景。
上述所有系統幾乎都依賴於訓練資料,而 GPWS 沒有這方面的問題。GPWS 依賴於高質量分詞詞典和歧義切分機制,採用基於可信度的人名識別方法,不依賴於公開的訓練資料。
GPWS 最大的問題在於很難複製,程式碼沒有公開;在分詞準確率上,GPWS 已經比不上字本位的分詞系統;但從分詞穩定性上,GPWS 仍然非常出色,比純統計分詞系統明顯要好。
分詞的難點在哪裡?
歧義
歧義問題與詞長非常相關,詞語越短,發生歧義的可能性越大,詞語越長,發生歧義的可能性越低,很少出現成語與其他詞發生歧義的情況。歧義問題在分詞中不是罪嚴重的問題,僅佔分詞錯誤數的 10% 左右。歧義分類包括:
交集型歧義
abc -> 可以切分為 ab c 和 a bc,佔所有歧義總量的 95%,也就是說歧義問題主要是指交集型歧義
例如:
研究生命的起源 | 研究生 命 的起源
這種環境下 工作 | 這種環境 下工 作
化妝 和 服裝 | 化妝 和服 裝
這群 山裡的娃娃 |這 群山 裡的娃娃
進書店 跟 進超市一樣 | 進書店 跟進 超市一樣
組合型歧義
abc ->可以切分為 abc 和 a bc 或 abc。
組合型歧義一般要透過前後鄰接搭配的可能性大小來判斷。
他從 馬上 下來 | 他從 馬 上 下來
這個門 把手 壞了 | 這個門 把 手 壞了
基於馬爾科夫模型計算鄰接搭配可以消除絕大部分歧義。
透過計算詞語搭配的機率估計句子的機率,選擇機率最大的結果即可。
分詞錯誤的主要來源
未登入詞 - 不在詞典中的詞,該問題在文字中出現頻度遠遠高於歧義。
未登入詞的型別包括:人名、地名、機構名、公司名、數字、日期、專業術語、新詞、產品名等。一般把人名、地名、機構名、公司名叫命名實體,例如:
盧靖姍一夜爆紅 (人名)
在東四十條站臺見面 (地點)
銀聯的小兄弟網聯成立了 (機構名)
公元 2017 年 8 月 24 日發生一件大事(日期)
中國外匯儲備達到三點 94 萬億美元(數字)
在明略軟體做大資料處理 (公司名)
基於暗網資料買牛股 (專業術語)
招行釋出了朝朝盈一號的理財產品(產品名)
讓你見識什麼叫凍齡 (新詞)
不同型別的命名實體還可以細分,比如人名可以分為中文人名、藏族人名、維族人名、日本人名、歐美人名等。
地名可以分為典型地名和非典型地名,典型地名如國、省、市、縣、鄉、村等;非典型地名還包括路、居委會、大廈商場、門牌單元、圖書館、門面等。理論上,只要是有經緯度座標的實體,都可以納入地名識別範疇。在實際工作中,這方面的識別需求非常強烈,比如在公安領域的線索或案情資訊,往往涉及到這種非典型地名。
機構和公司的型別也多種多樣,除了行政機構外,還有各種社團、 NGO 組織、基金會、校友會等等;公司名涉及到公司全稱和公司簡稱的識別,例如:
明略軟體系統科技有限公司(全稱)
明略軟體(簡稱)
明略資料(簡稱)
全稱識別相對容易一點,簡稱識別非常困難,比如:小米、滴滴、凡客、 OFO 等。
機構公司名與地名之間存在很大的交集。理論上,一個機構或公司往往會有辦公地點,有時也會用機構公司名來稱呼該地點,這樣的話機構公司名也就有了地點屬性。例如:
小明在明略軟體上班(公司名)
把球踢進了明略軟體的門前(看做公司名還是地點?)
在實際工作中,命名實體的關注程度最高,因為這些實體往往是知識圖譜的節點。其它未登入詞中,專業術語的提取會對文字分類和文字理解有重要幫助。
分詞中的語料問題
基於統計模型的分詞系統,在分詞結果上出現差異的一個原因是對語料的預處理差異導致。相當多的分詞系統沒有對訓練資料進行一致性校驗,認為訓練資料是無差錯的。在實際調查時發現,訓練資料包含了不少標註不一致的情況。例如人民日報中的例子:
自認倒黴 | 自 認 倒黴
倒黴 鬼 | 倒黴鬼
除了切分一致性外,詞性標註的不一致性更嚴重一些,如: “自認倒黴”有時標註為 l、有時標註為 lv;“難能可貴”有時標註為 i、有時標註為 iv。
分詞語料的選擇範圍有限,主要包括北大人民日報標註語料、微軟標註語料、社科院標註語料、 CTB 語料、OntoNotes 語料、城市大學繁體語料、中研院繁體語料等。一般選擇一種資料即可,資料需要購買。
分詞語料之間在詞語顆粒度上有一定差異,一般不混用進行訓練,例如:
承租人、承租者 (北大) | 承租 商 (微軟)
高 清晰度 彩電 (北大) | 高畫質晰度電視 (微軟)
分詞的理論解決方案
分詞的理論解決方案是採用統計模型,基於切分語料進行訓練。該方案在學術界和工程界都很常見,也是學術界的研究熱點。方案的差異主要是模型和特徵工程不一樣。模型差異非常常見,比如隱馬爾科夫模型、最大熵模型、條件隨機場模型、結構感知機模型、 RNN 模型 等。
特徵提取
特徵提取的第一步是選擇單元:基於字還是基於詞。從實踐來看,基於字的模型對未登入詞識別能力較強,但基於詞的模型很少會出現切分 “離譜”的情況。採用什麼顆粒度單元,取決於具體任務。
特徵工程會對最終分詞結果產生很大影響。字本位分詞的常見分詞特徵是:
Unigram 是單字特徵模板,當前字的前一個字、當前字、後一個字。Bigram 是鄰接字組合特徵模板,包括前一個字與當前字、當前字與後一個字的組合。Jump 是把前一個字與後一個字組合。
其它特徵主要是關於字的屬性,如是否數字、標點、字母等。這些特徵都是形式上的特徵,沒有歧義。
每一個特徵例項在 CRF 模型中有一個權重。由於特徵越多,模型引數越大,在實際工程應用中資源消耗越大,因此在實際任務中會有一定取捨。
理論解決方案的問題
訓練資料規模有限
北大人民日報的原始語料的詞語數為 2800 萬;CTB9.0 詞語數為 200 萬;國家語委資料為 5000 萬字。
標註語料是一個非常消耗人力的事情。北大 1998 年人民日報的標註共持續了 3 年時間才完成。CTB1.0 的標註持續了約 2 年時間。
領域遷移性不佳
其他領域實施時,分詞準確率下降很快。由於標註語料的詞語使用無法覆蓋實際語言現象,因此基於標註語料訓練的分詞系統在差異較大的領域會出現準確率降低的情況,例如基於北大語料訓練的分詞系統在微博上的切分準確率就不是很高。
模型越來越大,速度越來越慢
早期使用 HMM 模型訓練分詞系統,在北大資料上訓練大概需要 1-2 分鐘,記憶體消耗很小。現在使用 CRF 模型訓練大概需要 3 天左右,記憶體大概需要十幾 G。CRF 模型在訓練分詞系統時,其引數數量跟特徵數量直接相關,訓練資料越多,特徵數量越大,模型也就越來越大。導致系統呼叫存在困難,執行速度下降。
如何工程解決?
能用規則解決的,就不要靠模型了
針對文字中有規律的部分,可以利用規則或者正規表示式來識別,例如數字、標點、時間、日期、重疊式等,如笑一笑。
擴大訓練語料
擴大訓練語料的一種辦法是購買更多語料;另外一種辦法是利用其它分詞系統來切分資料,對資料進行清洗,形成新資料。
這些不同的分詞系統依賴的訓練資料儘量不要相同,例如 Stanford 系統是基於 CTB 語料,LTP 系統是基於人民日報,這兩個系統的切分結果就可以考慮混用。在混用前,要進行一定程度的預處理,比如保持切分一致性。
明略的分詞系統透過使用多款不同分詞系統的分詞結果,擴大訓練資料,在人名識別上大幅度提高了召回率。
增加詞表
增加詞表是提高切分準確率 “立竿見影”的辦法。在自然語言處理中,只要是封閉集合的詞語或實體,可以考慮利用詞表來切分,例如成語。該方法簡單有效。
在明略分詞資料中,整合了全國所有的地名、公交站名、路名等,精確到村和居委會,對國內地名識別上有很高的準確度。對機構名和公司名,整合了經常出現的國內行政機構、上市企業等名字。
在 Bosen 系統的演示中,對公司名識別準確率非常高,例如:“明略資料、明略軟體”這種公司簡稱也能識別出來,即使沒有上下文也能識別。這應該跟其後臺的公司名資料有關。
最大匹配 + 大詞表
從諸多實踐來看,最大匹配分詞策略 + 大詞表的方法非常有效。在《中文分詞十年回顧》中作者提到了最大匹配和大詞表的效果:
Ftop 行表示沒有未登入詞的情況下,僅使用最大匹配達到的 F 值(準確率 + 召回率)。
實用的分詞系統,都帶有大量通用詞表和領域詞表。
收集整理領域詞表,對遷移分詞系統至關重要。這對統計分詞系統比較困難。
結合深度學習?
ACL 2017 年有 3 篇跟分詞相關的文章,都是深度學習 (神經網路) 和分詞結合的內容。分別是:
Neural Word Segmentation with Rich Pretraining
Adversarial Multi-Criteria Learning for Chinese Word Segmentation
Fast and Accurate Neural Word Segmentation for Chinese
從明略的實踐來看,深度學習應用到分詞任務中的優點在於:模型非常小。在約 200MB 的語料上訓練得到的模型只有 5MB。分詞準確率接近歷史上最佳評測結果,但是分詞速度太慢。
從最新文獻來看,利用神經網路來做分詞,訓練效率和執行效率都比較低,慢得無法忍受,不適合工程上部署,也不適合做 Demo。
在《 Fast and Accurate …… for Chinese》中提供了執行速度對比,測試資料為 170k 左右,2015 和 2016 年的 6 項分詞結果中,切分測試資料的時間從 28 秒到 125 秒。在傳統方法上,比如基於 CRF 分詞,執行時間大概只要 1 秒。
根據個人經驗,神經網路在 NLP 上的成功應用的領域往往是準確率不高或者執行效率很低的場合,例如問答系統、機器翻譯、句法分析。在準確率比較高或者執行效率不錯的場景下,利用深度學習會得不償失。
來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/31524777/viewspace-2217608/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- 自然語言處理:分詞方法自然語言處理分詞
- 自然語言處理之jieba分詞自然語言處理Jieba分詞
- NLP自然語言處理中的hanlp分詞例項自然語言處理HanLP分詞
- NPL---自然語言處理單詞界定問題自然語言處理
- Pyhanlp自然語言處理中的新詞識別HanLP自然語言處理
- Hanlp自然語言處理中的詞典格式說明HanLP自然語言處理
- 自然語言處理工具中的中文分詞器介紹自然語言處理中文分詞
- Python 自然語言處理(基於jieba分詞和NLTK)Python自然語言處理Jieba分詞
- 自然語言處理NLP(6)——詞法分析自然語言處理詞法分析
- 自然語言處理之序列標註問題自然語言處理
- Python自然語言處理實戰(3):中文分詞技術Python自然語言處理中文分詞
- 自然語言處理工具pyhanlp分詞與詞性標註自然語言處理HanLP分詞詞性標註
- 入門自然語言處理必看:圖解詞向量自然語言處理圖解
- 自然語言處理(NLP)自然語言處理
- 詞!自然語言處理之詞全解和Python實戰!自然語言處理Python
- 自然語言處理中的語言模型預訓練方法自然語言處理模型
- 中文自然語言處理工具集:分詞,相似度匹配自然語言處理分詞
- 如何解決90%的自然語言處理問題:分步指南奉上自然語言處理
- 自然語言處理(NLP)系列(一)——自然語言理解(NLU)自然語言處理
- 自然語言處理(NLP)概述自然語言處理
- 自然語言處理NLP(四)自然語言處理
- Python自然語言處理Python自然語言處理
- 自然語言處理工具HanLP-N最短路徑分詞自然語言處理HanLP分詞
- 【NPL】如何解決90%的自然語言處理問題:分步指南奉上自然語言處理
- 自然語言處理中的遷移學習(下)自然語言處理遷移學習
- 自然語言處理中的遷移學習(上)自然語言處理遷移學習
- 精通Python自然語言處理 4 :詞性標註--單詞識別Python自然語言處理詞性標註
- NLP自然語言處理中英文分詞工具集錦與基本使用介紹自然語言處理分詞
- Python自然語言處理 1 語言處理與PythonPython自然語言處理
- Python 自然語言處理(NLP)工具庫彙總Python自然語言處理
- 自然語言處理的最佳實踐自然語言處理
- HanLP 自然語言處理 for nodejsHanLP自然語言處理NodeJS
- [譯] 自然語言處理真是有趣!自然語言處理
- 自然語言處理與分析(one)自然語言處理
- 《Python自然語言處理實戰》連結表Python自然語言處理
- 05.序列模型 W2.自然語言處理與詞嵌入模型自然語言處理
- Python自然語言處理 6 學習分類文字Python自然語言處理
- 深度學習浪潮中的自然語言處理技術深度學習自然語言處理