編者按
NLP模型開發平臺是以快速打造智慧業務為核心目標，無需機器學習專業知識，模型建立-資料上傳-資料標註(智慧標註、資料擴充)-模型訓練-模型釋出-模型校驗全流程視覺化便捷操作，短時間內即可獲得高精度NLP模型，真正為業務賦能。
在北京百分點資訊科技有限公司的NLP模型開發平臺釋出後，輿情分析業務中上線了超過200個個性化定製實時預測模型，依靠強大的資源排程和計算平臺，每天都會有數十個模型在進行迭代更新和最佳化，真正實現全流程的資料和模型的閉環。本文主要介紹NLP模型開發平臺的架構和實現細節，以及輿情業務中的應用，希望能為大家提供一些參考。
一、背景介紹
本文中重點介紹NLP模型開發平臺在百分點輿情洞察系統(MediaForce)中的設計和實踐。MediaForce是一款面向政企客戶，提供資訊監測、智慧分析等多功能的一款SaaS產品。從2014年發展至今，客戶標準化的建立以及資料資產的積累，為開展自動化和智慧化打下了堅實基礎。對內要提高生產和運營效率，縮短行為結果的反饋時間；對外要提供個性化服務，提高客戶親密度。輿情資訊是透過關鍵詞檢索來獲取對應的相關資料， 在基於BM25、TF-IDF等傳統資訊檢索機制下，只是考慮關鍵詞和文件的匹配程度，忽略了文件主題、查詢理解、搜尋意圖等因素，致使召回文件與客戶訴求相差較大。另一方面，在客戶定製化場景下，需要人工對客戶資料進行標籤處理，這是一個極其費時費力的過程。
在一個NLP模型開發任務中，一般包括如下三個大模組：
在早期，主要是圍繞和重複這三個模組來支援業務。在業務規模小時，人工方式保證了工作的靈活與創新突破，但是隨著業務模式的成熟與增長，逐漸凸顯出人工方式的侷限性，主要體現在如下幾個方面：
（1）NLP模型開發任務的增多，無疑增加開發人員的維護工作，尤其是在演算法迭代更新、模型版本管理等方面，將是災難性質的。
（2）業務人員是核心業務的把控者，但是由於模型學習門檻相對較高，使其參與度大大降低。
而NLP模型開發平臺的構建不僅能解決以上問題，也更將聚焦演算法工程師模型開發和基準驗證，使分工更加明確、全民參與。集資料管理、模型全生命週期管理、計算資源和儲存資源統一管理等特性，力求達到以下目標：
（1）複用性：通用演算法整合、演算法管理、避免重複造輪子。從指令碼開發到視覺化操作，專注於演算法效果提升和模組複用。
（2）易用性：即便是運營(業務)人員，也可以定製私有業務模型，真正實現業務賦能。依據自己的個性化訴求可進行資料標註、模型訓練、效果評估、模型釋出等操作。
（3）擴充套件性：算力資源可擴充套件、模型演算法框架(TF、Pytorch、H2o)可擴充套件、語言(Java、Python、R)可擴充套件。
二、NLP模型開發工具棧回顧
在傳統軟體開發中，我們需要對程式的行為進行硬編碼，而在NLP機器學習模型開發中，我們將大量內容留給機器去學習資料，開發流程上有著本質的不同，如下圖所示：
許多傳統軟體工程工具可用於開發和服務於機器學習任務，但是由於機器學習的特殊性，也往往需要自己的工具。比如：Git透過逐行比較差異來進行版本控制，適用於大多數軟體開發，但是不適合對資料集或模型檢查點進行版本控制。在2012年隨著深度學習的興起，機器學習工具棧種類和數量爆炸式增長，包括All-in-one(一站式機器學習平臺)：Polyaxon、MLFlow等，Modeling&Training(模型開發、訓練)：PyTorch、Colab、JAX等，Serving(釋出、監控、A/B Test)：Seldon、Datatron等。下圖表明MLOps每種型別的工具數目：
對機器學習工具棧進行細化包括：標註、監控、版本管理、實驗追蹤、CI/CD等，詳細內容不再贅述，詳情參照下圖：
可以看到機器學習工具棧種類和數量目前是極其繁多的，有些是面向OSS的，有些是商業收費的。下圖主要舉例在不同種類的工具棧上的產品：
三、NLP模型開發平臺構建
1. AI訓練模型的基本流程簡介
（1）分析業務需求：在正式啟動訓練模型之前，需要有效分析和拆解業務需求，明確模型型別如何選擇。
（2）採集、收集、預處理資料：儘可能採集與真實業務場景一致的資料，並覆蓋可能有的各種資料情況。
（3）標註資料 ：按照規則定義進行資料標籤處理。如果是一些分類標籤，可以線上下直接標註；如果是一些實體標註、關係標註就需要對應一套線上標註工具進行高效處理。
（4）訓練模型：訓練模型階段可以將已有標註好的資料基於已經確定的初步模型型別，選擇演算法進行訓練。
（5）效果評估：訓練後的模型在正式整合之前，需要評估模型效果是否可用。需要詳細的模型評估報告，以及線上視覺化上傳資料進行模型效果評估，並且在灰度環境進行業務驗證。
（6）模型部署：當確認模型效果可用後，可以將模型部署至生產環境中。同時要支援多版本管理、AutoScale等功能。
2. 整體架構
（1）分散式儲存包括NFS、HDFS、CEPH。HDFS是儲存原始資料以及樣本特徵，NFS是儲存訓練後的模型檔案，CEPH是K8S叢集的檔案分散式儲存系統。
（2）底層計算資源分為CPU叢集和GPU叢集，高效能CPU叢集主要用於部署和訓練傳統的機器學習模型，GPU叢集則用來部署和訓練深度(遷移)學習模型。
（3）資源不同，計算的選型也有差別。機器學習訓練使用 Alink 做計算，透過 Yarn 來排程計算資源；深度學習訓練使用 K8S 做排程，支援主流的 Pytorch、Tensorflow、PaddlePaddle、H2o等深度學習框架，目前只是做到單機訓練，而模型的部署都是藉助K8S進行統一發布和管理。
模組對外提供資料標註、模型訓練、模型評估、模型管理、模型部署、模型預測等功能，同時平臺還抽象出分類、NER、評估、預測等元件。
3. 平臺構建實踐
平臺上層提供了一套標準的視覺化操作介面，供業務運營人員使用，平臺底層提供全生命週期的模型管理，支援上層應用擴充套件。
上文主要介紹NLP模型開發平臺構建的基本流程和整體架構 ，本章節會對技術選型與實踐進行展開。
（1）容器管理排程平臺選型
主流的容器管理排程平臺有三個，分別是Docker Swarm、Mesos Marathon和Kubernetes。但是同時具備排程、親和/反親和、健康檢查、容錯、可擴充套件、服務發現、滾動升級等諸多特性，非Kubernetes莫屬。同時基於OSS的機器學習工具棧大多也都是基於Kubernetes而進行的上層開發和應用，像我們熟知的Kubeflow等。另一方面深度學習領域通常是用GPU來做計算的，而Kubernetes對GPU卡的排程和資源分配有很好的支援和擴充套件。比如現在叢集有多種型別的GPU卡，可以對GPU節點打上label，啟動任務配置nodeSelector實現卡型別的精準分配。最終我們選擇用 K8S 作為平臺的容器管理系統。
（2）GPU資源排程管理
目前較新版本的docker是支援 NVIDIA GPU的runtime，而不再考慮舊版的nvidia-docker或者nvidia-docker2。其實在runtime基礎上，是可以直接使用GPU來執行深度學習任務的，但是卻無法限定GPU資源以及異構裝置的支援。這裡主要給出兩種解決方案：
a. Device Plugin
為了能夠在Kubernetes中管理和排程GPU， Nvidia提供了Nvidia GPU的Device Plugin。主要功能如下:
- 支援ListAndWatch 介面，上報節點上的GPU數量。
- 支援Allocate介面，支援分配GPU的行為。
但是這種機制導致GPU卡都是獨享的。特別是在推理階段，利用率是很低的。這也是我們採用第二種方式的主要原因。
b. GPU Sharing
GPU Device Plugin可以實現更好的隔離，確保每個應用程式的GPU使用率不受其他應用程式的影響。它非常適合深度學習模型訓練場景，但是如果場景是模型開發和模型推斷，會造成資源浪費。所以要允許使用者表達共享資源的請求，並保證在計劃級別不會超額訂購GPU。我們這裡嘗試Aliyun在GPU Sharing上的開源實現，如下圖所示：
在配置檔案中，限定視訊記憶體大小，這裡的單位是GiB：
執行如下命令：
在11GiB的顯示卡上，GPU分配狀況如下：
（3）閘道器選型
在使用Kubernetes的Service時，一個必須要面對和解決問題是：如何從外部（kubernetes 叢集之外），訪問到Kuberentes裡建立的Service？這裡最常用的一種方式就是NodePort。它允許你使用任何一臺宿主機IP進行訪問。這種方式需要事先指明nodePort或者隨機生成nodePort，對介面資源較難管理。而使用像Kong、Nginx、HAProxy等主流閘道器所面臨的問題是：不是自服務的、不是Kubernetes原生的、為Api管理而設計，而非微服務。Istio 是微服務的服務網格，旨在將應用層（L7）的可觀察性、路由和彈性加入到從服務到服務的流量中。而模型部署需要與Kubernetes深度融合，也不需要進行服務間的呼叫，最後選用Ambassador作為最後閘道器選型。Ambassador作為一個較新推出的開源微服務閘道器產品，與kubernetes結合得相當好，基於annotation或CRD的配置方式與K8S渾然一體，真正做到了kubernetes native。下面給出一個實際中的一個例子：
其中 timeout_ms 預設值為3000，在使用Cpu做推理裝置時，可能會出現超時的情況，這裡依據不同的場景對該值進行微調，以滿足使用。同時可以從Route Table中檢視相應的URL。
（4）視覺化
這裡的視覺化是指在進行模型訓練過程中，需要對模型效能進行評測和調優。這裡率先融入Tensorboard，隨後也將百度的VisualDl融入進去。在訓練過程中啟動一個單獨的容器，暴露出介面供開發者查閱和分析。
（5）模型部署
在第二章節中，介紹了不同功能的機器學習工具棧。在模型部署中我們使用Seldon Core來作為CD工具，同時Seldon Core也被Kubeflow深度整合。Seldon 是一個可在Kubernetes上大規模部署機器學習模型的開源平臺，將ML模型（Tensorflow，Pytorch，H2o等）或語言包裝器（Python，Java等）轉換為生產 REST / GRPC 等微服務。
下面是推理映象的構建過程，其中MyModel.py是預測檔案：
其中部分 deployments 描述檔案如下：
四、平臺應用和成效
NLP模型開發平臺的構建極大地降低模型學習門檻，使業務人員不僅可以參與規則的制定，也可以參與到資料標註、服務釋出、效果評估等多個階段。同時使資料科學家和機器學習工程師能更加專注於模型本身的演算法和效能，極大地提高工作效率、簡化工作流程。下面舉例藉助平臺在資料相關度、標籤處理等方面的成效。
1. 相關度
在過去幾十年中，已經實現了各種自動資訊檢索系統。文件的有效表示是能夠檢索文件的核心，像向量空間模型和機率模型都依賴於TF、IDF、文件長度等特徵因素。將文件從文字轉換為數字或基於向量的表示形式，排序功能就需要根據特定的查詢的相關性對文件進行排序。其中Okapi BM25是IR中最著名和使用最廣泛的排序演算法。傳統資訊檢索方法沒有考慮語義資訊等諸多因素。而隨後的Bert在GLUE中IR相關的基準測試達到最優，其中一部分原因是因為其大量的訓練資料。此外基於Transformer神經網路架構促進了輸入中各個token之間的深層關係，從而使模型可以更好地瞭解輸入中存在的關係。在真正應用中，需要考慮查詢意圖、查詢改寫、同義詞擴充套件等諸多技巧。下面將闡述在提高檢索相關度方面的嘗試和方案的演進，以及NLP模型開發平臺在這方面的成效和應用。
（1）基於查詢意圖的傳統資訊檢索
輿情中的搜尋往往是詞或短語，在缺少外部知識的情況下，搜尋意圖往往無法得知。在使用Okapi BM25傳統的資訊檢索方式，只能得到查詢關鍵詞與文件相關，而並不符合搜尋意圖。在當時的架構下，主要是基於Elasticsearch的全文檢索，以便考慮能否使用ES得出一個比較通用的處理框架。Elasticsearch是基於Luence的架構。很多要素都是一脈相承的，例如文件和欄位的概念、相關性的模型、各種模式的查詢等。流程如下圖所示：
這裡的意圖擴充套件庫其實是對查詢關鍵詞進行擴充套件，例如，關鍵詞為"真功夫"，如果你的搜尋意圖指的是餐飲品牌“真功夫”，那麼可以擴充套件一系列行業相關詞：餐飲、門店、優惠券等。聯合Query一起查詢，這裡的意圖擴充套件庫（擴充套件相關詞）只是貢獻權重得分，而不作為檢索過濾條件，使用ES中should語句即可實現。這種機制在一定程度上緩解了資料相關度問題，特別是在垂直領域中，效果甚佳。而一旦涉及跨領域、搜尋意圖寬泛，就顯得無能為力。
（2）基於Bert分類模型應用
在以上的實現機制中，都是無監督排序演算法的典範，這樣的排序演算法並不是最優的。在極度簡化的情況下，如果標籤定義為，某個文件針對某個關鍵字是否相關，也就是二分標籤，訓練排序演算法的問題就轉換成了二分分類（Binary Classification）的問題。這樣，任何現成的二分分類器，幾乎都可以在不加更改的情況下直接用於訓練排序演算法，比如經典的“對數機率”分類器或者支援向量機都是很好的選擇。這類演算法稱之為“單點法排序學習”（Pointwise Learning to Rank）。這種機制與我們的應用場景十分吻合，只不過將Query上升為話題維度。而像DSSM等經典的文字匹配演算法解決的是查詢串與文件的匹配程度，查詢串往往是句子，而不是詞語。因此我們將相關度問題轉化為二分分類問題，召回階段使用Elastcsearch索引庫檢索，排序階段使用分類器對召回的文件進行判定。
在這種機制下，為客戶提供了個性化服務。在NLP模型開發平臺的助力下，進行一站式處理，並且可以實現版本的迭代最佳化。
2. 離線標籤
在一些定製化場景下，需要對離線資料進行標籤化處理。這是一個費時費力的過程，並且之前的勞動無法為後續的工作賦能。我們透過標註模組對已有資料進行整合，並且對新標籤的樣本資料進行標註，從而快速為業務賦能，解放生產力。
以及在實體識別的場景下，可以直接在標註模組進行標註：
五、平臺展望
1. 標註功能完善
在文字分類、NER等基礎標註任務的基礎上，還需要增加關係標註、seq2seq等主流任務的支援，以及任務分配、多人協作等特性。
2. 豐富演算法模組
在滿足基礎需求下，還需要增加文字匹配等演算法模組，滿足更加廣泛的應用場景。
3. 打造Piplines流水線式NLP模型開發平臺
模型訓練以及模型評估目前是耦合的，不利於元件模組複用，所以要按照細粒度的模組進行獨立拆分，再按照 Pipline方式自由組合，來達到最大利用率。
參考資料：
[1]https://huyenchip.com/2020/06/22/mlops.html
[2]https://github.com/AliyunContainerService/gpushare-scheduler-extender
[3]https://docs.seldon.io/projects/seldon-core/en/latest/