本系列博客主要分享了微軟 Azure 的團隊使用 IntelAnalytics Zoo在 Azure 的平臺上為客戶支持服務平臺添加 AI 模塊的一些實踐。本篇博客是此系列中的第一篇。在本篇中，我們將介紹為客服平臺添加“文本分類”模塊的大致流程及實踐經驗。

背景

在如今商業高度發達的社會，客戶支持服務平臺已被廣泛使用在售前和售后為客戶提供技術或業務支持，例如銀行的電話客服，淘寶京東等電商的在線客服等等。傳統的客戶支持服務平臺僅僅是一個簡單的溝通工具，實際的服務和問題解答都是靠大量的人工客服和客戶直接交互。后來隨著機器智能和自動化技術的提升，越來越多的商家開始為客服系統添加智能模塊，節省人力，提升顧客的交互體驗。

我們有一個試驗中的智能客服平臺。它主要基于在線的文字對話，客戶在對話界面中提出問題，平臺從支持文檔和預先存儲的常用答案中搜尋答案回復客戶。如果客戶覺得答案給的不合適，可以主動尋求轉人工幫助，后臺的支持人員會在線和客戶對話，提供幫助。基礎的客服系統問答給用戶自動提供的答案主要來自于預先編輯好的對話流和基于 Information-retrieval 的文檔搜索、索引和權重計算。在陸陸續續有了一些真實的問答交互之后，我們希望改進初版的系統，利用機器學習和人工智能實現基于不斷累積的真實數據的自動學習和進化。一方面，利用自然語言意圖識別和 QA 問答相關技術來提高結果的準確性；另一方面，利用對話內容和其他客戶特征進一步提升效率和用戶體驗——例如對對話進行情感分析，對包含負面情緒的客戶進行特殊處理；根據對話內容進行分類，為轉接人工對應團隊提高服務效率；根據用戶畫像選擇更相關的問題答案。

作為初步嘗試，我們在原有的系統中添加了兩個新的智能模塊（使用 IntelAnalytics Zoo實現）：文本分類模塊，和 QA 排序模塊。文本分類模塊的作用是對對話的服務類型進行分類，以使得轉接對應人工團隊的時候更加高效，這個模塊以后經過一些簡單的修改還可用于情感分析。QA 排序模塊則用來對現在搜索引擎得到的答案進行再排序。

目前我們已經做了一些實驗，效果還不錯，后續的實驗和部署還在進行中。在這個系列博客里，我們會逐步把我們在搭建這個客服平臺的流程和經驗分享出來，供大家參考借鑒。

在本篇博客中，我們主要介紹基于Analytics Zoo 0.2.0 版本為客服平臺添加“文本分類”模塊的大致流程及實踐經驗。

為什么采用 Analytics Zoo

Analytics Zoo是 Intel 開發的一個開源大數據分析 +AI 平臺。項目包含 Scala 和 Python 兩套 API，提供了一系列方便實用的封裝和工具（包括 Pipeline API 以及更 high-level 的 API，預定義的模型，在公共數據集上預訓練的模型，以及參考的實用案例等等），使用戶能更容易地使用 Spark 和 Intel BigDL（Intel 開源的一個基于 Spark 的分布式深度學習框架）進行深度學習應用的開發。

客服平臺的對話數據量會隨著系統投入使用逐漸變得龐大，將數據存放在 Hadoop 集群上可以滿足集中管理、分享和可擴展性的需要。而使用Analytics Zoo讀取和處理存放在 Hadoop/Spark 集群上的數據是非常方便的事情。Analytics Zoo在標準的 Spark 集群上面使用 Scala API 訓練和預測并不需要對云有特殊的改動或配置，還有很多預定義的模型可以開箱即用。在預測的時候，可以使用Analytics Zoo提供的 POJO 風格的 service API（本地運行無需 Spark 集群）來做低延遲的預測。如果是對吞吐量要求較高的話，則建議使用Analytics Zoo提供的標準 prediction API（可以運行在 Spark 集群上）。這兩套 API 都可以很方便地被添加到基于 java 的 service 中。

文本分類概述

文本分類是一種常見自然語言處理任務，主要的目的是將輸入的文字片段分配到一個或者多個類別中。例如，垃圾郵件分類就是把郵件的內容片段分配到是否垃圾郵件的類別中。而我們這里的應用場景則是將一段對話歸類到一種服務類別中。

訓練一個文本分類模型的過程一般包括幾個步驟：采集和準備訓練數據集和驗證數據的文本集，數據清洗和預處理預處理，在訓練數據集上訓練模型，在驗證數據集上評估的指標，如果驗證集上的指標不夠好，則繼續優化模型（包括添加新數據，調整參數，算法等）。

Analytics Zoo提供了一系列預定義好的文

本分類模型（如 CNN, LSTM 和 GRU）。我們直接選擇了其中基于 CNN 的分類模型作為基礎進行開發（以下訓練過程中使用的 API 均以 python API 為例）。

在上面的接口定義中，class_num 是指該文本分類問題包含類的數量，token_length 是指每個詞對應詞向量的大小，sequence_length 是指每個文本所包含的詞的數目，encoder 是指對輸入的詞向量序列的編碼器（可以是 cnn, lstm 或者 gru），encoder_output_dim 是指編碼器的輸出維度。這個模型接收的輸入的是一段文字的詞向量的序列，輸出是一個類別標簽數字。

如果對這個模型內部包含的具體神經網絡結構感興趣，可以查看這段源代碼（https://github.com/intel-analytics/analytics-zoo/blob/branch-0.2/pyzoo/zoo/models/textclassification/text_classifier.py#L58-L72）。

數據采集和預處理

訓練數據中的每一條記錄包含兩個字段：對話歷史和對應的服務類別標簽。我們采集了幾千條這樣的記錄，并用半自動和人工的方法進行了類標簽的標注。拿到原始訓練數據以后，首先對對話文本進行了清洗，去掉文本中無意義的 tag 和亂碼，并轉化成每一條記錄都是（text, label）的 text RDD。然后我們對 text RDD 做了預處理，生成文本分類模型可以接收的輸入。要注意，數據清洗和預處理的部分，對于訓練數據和對將來應用預測中的新數據都要一致。

清洗之后的 text RDD 記錄示例 （每條記錄都是一對對話文本和類標）

清洗過程這里不再贅述，下面主要介紹預處理主要包含的常用步驟：

1. 中文分詞 （Tokenization）

和英文不同，中文文本由連續的字序列組成，每句話的詞與詞之間沒有特定的分隔符，需要通過語義和詞典進行分詞。我們采用的是jieba對原始文本內容進行分詞。經過分詞之后，原文本被轉化成了一個由詞構成的數組。

2. 去掉停用詞 （Stopwords Removal）

停用詞是在文本檢索過程中出現頻率很高但又不涉及具體內容的單詞，這些詞的存在通常對于文本分類的幫助不大。可以選擇使用中文常用的停用詞表（比如“只要”、“無論”等）或者用戶自己指定停用詞，將這些詞從分詞的結果中去除。

3. 統一長度（Sequence Aligning）

不同的文本通常會有不同的長度，但對于一個深度學習模型而言，則需要統一規格的輸入，因此我們要把文本對應的詞數組轉換成相同的長度。對于給定的長度 sequence_length（比如 500），如果文本包含的詞數目大于該長度，可以選擇從文本開頭或者從結尾截取該文本中該長度數量的詞。如果文本的詞數目不足該長度，則可以在原本的詞之前或之后加上虛擬的詞來補足（比如“##”）。

4. 轉換為詞向量 （Word2Vec）

處理到目前為止每個文本轉換成的仍然是詞的數組，但要放入模型進行訓練，需要的是數值的輸入，因此我們需要把每個詞轉化為相同維度的詞向量。我們采用的是 Facebook 開源的詞向量工具 FastText （https://github.com/facebookresearch/fastText），FastText 提供預先訓練好的中文詞向量，每個詞對應一個 300 維的空間向量。在詞向量的空間中，任意兩個向量的之間的距離能體現對應的兩個詞之間的語義聯系，兩個語義上很相似或者有很強關聯的詞對應的詞向量會有很近的距離。對于不在預先訓練好的 FastText 中的詞，我們用一個 300 維的零向量來代替。

5. 轉換為 Sample

經過以上的處理之后，每個文本轉換為形狀是（sequence_length, 300）的多維向量。對于文本所屬的類別，我們則轉換為整數來表示。把多維向量作為 feature，類別作為 label，每條文本數據生成一個 BigDL Sample （https://bigdl-project.github.io/0.6.0/#APIGuide/Data/#sample）。最終整個數據集轉化成 Sample RDD 用于模型基于 Spark 的分布式訓練。

sample_rdd=vectors_rdd.map(lambdavectors,label:to_sample(vectors,label))

模型訓練，測試，評估和優化

在準備好 RDD 格式的訓練集（train_rdd）和驗證集（val_rdd），并按照例子實例化好一個模型（text_classifier）之后，我們創建一個 BigDL Optimizer 對模型進行分布式訓練。這是一個類別用整數表示的多分類問題，損失函數我們選擇的是稀疏分類交叉熵損失 （Sparse Categorical Cross Entropy）。

在創建 Optimizer 的時候可以指定讓模型在訓練集上進行多少次迭代訓練（epochs），每次訓練使用的批大小（batch_size），采用的優化方法以及它的學習率（learning rate） 等參數。

可以在訓練的過程中，在驗證集上輸出指定的性能指標 （比如 Top1 accuracy） ，這樣能了解到模型在訓練的過程中是否已經過擬合。同時 BigDL 也支持在訓練過程中階段性保存快照可用于之后恢復訓練。更詳細的 Optimizer 的參數和使用方法請參考文檔（Analytics-zoo 同時支持 BigDL 0.5 和 0.6 版本，Python pip install 默認同時安裝的是 BigDL 0.6 版本）：https://bigdl-project.github.io/0.6.0/#ProgrammingGuide/optimization/

如果不選擇在訓練的過程中驗證，也可以在訓練完成后，用訓練好的模型對驗證數據進行預測并檢查準確率。要保證驗證集也經過了和訓練集同樣的預處理過程。模型會返回對應的概率分布或者所預測的分類編號。

如果驗證集上結果不好，就要對模型進行優化，這個過程基本是重復調參/調數據/訓練/測試驗證的過程，直到準確率可以滿足實用要求。我們這個模型一開始幾次的準確率是不夠好的，我們之后對學習率進行了調整，并添加了新的訓練數據，增加了停用詞詞典，后來準確率有了大幅提升 。

以上的訓練過程在單機上和集群上都可以運行。

如何操作可以參考文檔：https://analytics-zoo.github.io/0.2.0/#PythonUserGuide/run/

另外，Analytics Zoo提供了完整的文本分類的指南和實例供用戶參考：

https://analytics-zoo.github.io/0.2.0/#ProgrammingGuide/text-classification/。

https://github.com/intel-analytics/analytics-zoo/tree/branch-0.2/pyzoo/zoo/examples/textclassification。

將模型預測部分與 service 集成

拿到訓練好的模型之后，接下來要做的就是把新輸入的文本經過同樣的預處理之后喂給模型，然后模型會輸出一個分類的標簽。由于我們的微服務是用 Java 實現的，考慮到效率，我們沒有直接用 python 代碼進行預測，而是用Analytics Zoo提供的 POJO 風格的 Java Inference API （用法和接口參考文檔https://analytics-zoo.github.io/0.2.0/#ProgrammingGuide/inference/）實現了預測部分的代碼（Java API 可以直接 load python code 訓練好的模型來做預測），示意如下。另外 Analytics Zoo 也提供了文本分類的完整的 web service 示例可參考：https://github.com/intel-analytics/analytics-zoo/tree/master/apps/web-service-sample

模型的持續更新和發布

數據是隨著時間不斷累積的，因此在實際使用中經常會定期使用全量或增量數據重新訓練模型，并把模型更新到預測服務中。要實現這一點，只需定期運行訓練程序得到新的模型，然后利用上面示例過的 model.load API 重新加載更新過的新模型就可以了。另外，我們的 service 用基于 Kubernetes 的方案進行持續更新和集成。Analytics Zoo也提供了 docker 的 image （https://github.com/intel-analytics/analytics-zoo/tree/branch-0.2/docker） 供下載安裝。

結語

相信大家看了以上的介紹，已經對如何使用文本分類，以及如何將類似模塊添加到自己的應用中有了大致的了解。我們將在這個系列后續的博客中介紹其他方面的內容和實踐進展。

如果需要更多信息，請訪問 Analytics Zoo 在 Github 上的項目地址（https://github.com/intel-analytics/analytics-zoo） ，并且可以從 Market place 上面下載使用已經準備好的預裝 Analytics Zoo 和 BigDL 的鏡像（https://market.azure.cn/zh-cn/marketplace/apps/intel.bigdlstandard）。