自然語言處理在電信客戶名稱匹配的應用探討

陳慶良

【摘要】? ? ?隨著業(yè)務的不斷拓展，中國電信提出企業(yè)轉(zhuǎn)型3.0，借助大數(shù)據(jù)及AI技術(shù)實現(xiàn)企業(yè)的智慧化運營。本文探討了自然語言處理在電信客戶名稱匹配的應用場景，在比對近幾年出現(xiàn)的文本匹配算法后，采用Albert_small算法實現(xiàn)了客戶名稱的精確匹配模型。通過現(xiàn)網(wǎng)數(shù)據(jù)分析結(jié)果表明，該算法具備較高的準確率及推斷速度。最后，本文將算法封裝成API服務，發(fā)布在OpenPai的AI測試平臺，單張P40顯卡壓測的效果可達到每秒213次的并發(fā)請求，具備線上運行的條件。

【關(guān)鍵詞】? ? 自然語言處理? ? 文本匹配? ? 預訓練語言模型? ? OpenPai

引言：

隨著移動電話、寬帶、ITV等市場空間的飽和，客戶對電信的服務質(zhì)量要求不斷提高。為了提升企業(yè)競爭力，電信集團在2017年就提出企業(yè)轉(zhuǎn)型3.0：網(wǎng)絡智能化、業(yè)務生態(tài)化、運營智慧化。通過大數(shù)據(jù)及AI的應用，實現(xiàn)精確管理、精準營銷、精細服務和精益網(wǎng)運的“四精”工作。

精確管理的重點工作之一是如何準確管理及服務全網(wǎng)的客戶。其中政企客戶名稱歸并是一個很典型的痛點，比如中國電信股份有限公司北京分公司、中國電信北京分公司等，這些客戶名稱在系統(tǒng)都存在，客戶經(jīng)理要如何快速準確地服務客戶？理想的情況是根據(jù)統(tǒng)一社會信用代碼對應的標準名稱進行歸并，但只根據(jù)中文名稱，需要找到更好的方式準確匹配。這些都是AI可以發(fā)力的地方。

一、相關(guān)工作

針對上面分析的痛點，本文在調(diào)研當前自然語言處理的各種算法基礎(chǔ)上，擬采用基于深度學習的短文本匹配算法用于自動匹配客戶名稱，以提高業(yè)務部門的日常工作效率，提升客戶服務感知。主要貢獻如下：

1.比對了MVLSTM、BIMPM、ESIM、DRCN、基于Bert各種變體的文本匹配算法在客戶名稱匹配場景的效果，最終選擇Albert_small算法，測試集上準確率可達99.1%;

2.采用開源的OpenPai搭建了一套AI一體化測試平臺，將文本匹配算法封裝成API服務，單張P40卡可實現(xiàn)每秒并發(fā)213次，同時允許動態(tài)擴縮容，具備線上運行的條件。

本文的建模算法來源于互聯(lián)網(wǎng)開源的代碼，本著開源的精神，本文的程序也都在Gitee上開源[1]，數(shù)據(jù)由于保密關(guān)系，無法提供。

二、問題定義

圖1? ? 客戶名稱文本匹配流程圖

客戶名稱匹配的業(yè)務場景是，客戶經(jīng)理給出客戶的名稱，要求能返回系統(tǒng)里最相似的標準客戶名稱。比如“上海志尚人力資源有限公司”和“上海志尚勞務派遣服務有限公司”是同一家公司，但與“上海磊實勞務派遣有限公司”不是同一家公司。

該場景可通過文本匹配（或稱文本相似度）的算法來建模。文本匹配也是自然語言處理中一個重要的基礎(chǔ)問題，可應用于大量的NLP任務中，如信息檢索、問答系統(tǒng)、機器翻譯等，這些任務在很大程度上都可以抽象為文本匹配問題。由于客戶的名稱一般不超過32個字，因此該場景屬于短文本-短文本匹配算法。匹配的過程一般分為召回及排序兩大階段，流程圖見圖1。召回階段是個粗排的過程，目的是從大量的候選語料中挑選比較相似的候選集，該候選集可以返回較多的案例，保證最終結(jié)果的召回率。排序的階段是個精排的過程，采用更精確的匹配度算法，從上面的候選集中挑選最匹配的N條記錄，重點保證精確率。

三、問題建模及實驗評估

根據(jù)上述的設計流程圖，召回的階段我們主要采用TF-IDF的算法來計算相似度，由于電信的客戶名稱庫數(shù)量巨大，召回階段只需從大量的名稱中返回前50左右的候選集，因此我們主要采用SparkSQL讀取結(jié)構(gòu)化數(shù)據(jù)，用Spark MLLib實現(xiàn)TF-IDF的相似度匹配。本文重點描述精排階段文本匹配算法的建模過程。

文本匹配的算法，傳統(tǒng)的方法有BoW、TF-IDF、Jaccord、SimHash等算法，基于深度學習的算法有MVLSTM[2]、BIMPM[3]、ESIM[4]、DRCN[5]等。近年來，隨著預訓練語言模型的盛行，各項BERT模型也被應用到文本匹配中。

本文重點比對了基于深度學習的各項算法在客戶名稱精確匹配中的效果。訓練的數(shù)據(jù)從CRM的客戶名稱庫中提取，正樣本取了同一個社會信用代碼，但客戶名稱又不完全一致的客戶，再由人工作標記，判斷確實是同一家客戶的記錄。負樣本取不同社會信用代碼的客戶名稱，同時限定這兩個客戶名稱的關(guān)鍵詞余弦相似度比較大，目的是為了讓模型能盡量學出比簡單統(tǒng)計關(guān)鍵詞計算相似度更優(yōu)的方法。最終選取的樣本格式為：

客戶名稱1，客戶名稱2，是否匹配（1匹配，0不匹配）;

訓練集、驗證集、測試集的正負樣本分布為1：2.5。

模型測試的效果見表1，最大字長統(tǒng)一設為32。

從表1可得出結(jié)論：

1.原生的bert_base效果最好，但是推斷1.6萬條數(shù)據(jù)需16秒，模型參數(shù)也較大;

2. rbt3和albert_small在測試集上的準確率都能達到99.1%，僅比bert_base少0.07%，但是在測試集的推斷時間只需要6秒，模型參數(shù)也少很多。其中albert_small的性價比最高，模型大小只有19Mb。

因此，綜合考慮準確率及推斷的效率，本文選擇albert_small作為客戶名稱精準匹配的模型。

四、案例評測

為了更好地評估生產(chǎn)環(huán)境的部署情況，本文采用微軟開源的OpenPai搭建了一套AI測試平臺，并在該平臺上模擬了生產(chǎn)的發(fā)布及壓測情況。

OpenPai[6]是微軟在2018年開源的人工智能集群管理平臺，支持多種深度學習、機器學習及大數(shù)據(jù)任務，可提供大規(guī)模GPU集群調(diào)度、集群監(jiān)控、任務監(jiān)控、分布式存儲等功能。

詳細的代碼請參照文獻[1]。在測試環(huán)境里，本文為容器分配了一張P40顯卡，采用jmeter[7]軟件對API服務進行壓力測試，壓測的結(jié)果表明：

1. 32核CPU單張P40卡最高每秒可處理213次的并發(fā)量，吞吐量可達415條/秒，而顯存只占用不到5Gb;

2.從運行的日志看，瓶頸主要在web端的并發(fā)及CPU的處理部分;

3. API服務已經(jīng)封裝成docker鏡像，只要資源夠，可動態(tài)擴縮容。

五、結(jié)束語

本文探討了將自然語言處理技術(shù)引入電信客戶名稱匹配的工作場景。在綜合考慮算法準確度及推斷性能的基礎(chǔ)上，采用albert_small算法作為客戶名稱精準匹配的基礎(chǔ)算法。最后，本文為了模擬生產(chǎn)環(huán)境的運行效果，采用微軟開源的OpenPai搭建了一套小型AI平臺，同時用MMS框架將文本匹配算法封裝成API并打包成docker鏡像，在單張P40顯卡上可達到213次/秒的并發(fā)，滿足生產(chǎn)上線的需求。后續(xù)可以嘗試通過數(shù)據(jù)增強等方式提高模型的泛化能力。

在AI一體化平臺方面，本文也只搭建了一套模擬環(huán)境，實際生產(chǎn)還有很多資源調(diào)度、流程自動化的工作需要進一步完善。

參? 考? 文? 獻

[1] https：//gitee.com/yiyeshucql/nlp.git.

[2] Shengxian Wan， Yanyan Lan， Jiafeng Guo， Jun Xu， Liang Pang， Xueqi Cheng， “A Deep Architecture for Semantic Matching with Multiple Positional Sentence Representations”， arXiv preprint arXiv：1511.08277v1， 2015.

[3] Zhiguo Wang， Wael Hamza， Radu Florian， “Bilateral Multi-Perspective Matching for Natural Language Sentences”， arXiv preprint arXiv：1702.03814v3， 2017.

[4] Qian Chen， Xiaodan Zhu， Zhenhua Ling， Si Wei， Hui Jiang， Diana Inkpen， “Enhanced LSTM for Natural Language Inference”， arXiv preprint arXiv：1609.06038v3， 2017.

[5] Seonhoon Kim， Inho Kang， Nojun Kwak， “Semantic Sentence Matching with Densely-connected Recurrent and Co-attentive Information”， arXiv preprint arXiv：1805.11360v2， 2018.

[6] https：//github.com/Microsoft/pai

[7] https：//jmeter.apache.org/