在傳統(tǒng)軟件開發(fā)中，我們需要對程序的行為進行硬編碼，而在NLP機器學習模型開發(fā)中，我們將大量內容留給機器去學習數(shù)據(jù)，開發(fā)流程上有著本質的不同，如下圖所示：

許多傳統(tǒng)軟件工程工具可用于開發(fā)和服務于機器學習任務，但是由于機器學習的特殊性，也往往需要自己的工具。比如：Git通過逐行比較差異來進行版本控制，適用于大多數(shù)軟件開發(fā)，但是不適合對數(shù)據(jù)集或模型檢查點進行版本控制。在2012年隨著深度學習的興起，機器學習工具棧種類和數(shù)量爆炸式增長，包括All-in-one(一站式機器學習平臺)：Polyaxon、MLFlow等，Modeling&Training(模型開發(fā)、訓練)：PyTorch、Colab、JAX等，Serving(發(fā)布、監(jiān)控、A/B Test)：Seldon、Datatron等。下圖表明MLOps每種類型的工具數(shù)目：

對機器學習工具棧進行細化包括：標注、監(jiān)控、版本管理、實驗追蹤、CI/CD等，詳細內容不再贅述，詳情參照下圖：

可以看到機器學習工具棧種類和數(shù)量目前是極其繁多的，有些是面向OSS的，有些是商業(yè)收費的。下圖主要舉例在不同種類的工具棧上的產品：

三、NLP模型開發(fā)平臺構建

1.  AI訓練模型的基本流程簡介

（1）分析業(yè)務需求：在正式啟動訓練模型之前，需要有效分析和拆解業(yè)務需求，明確模型類型如何選擇。

（2）采集、收集、預處理數(shù)據(jù)：盡可能采集與真實業(yè)務場景一致的數(shù)據(jù)，并覆蓋可能有的各種數(shù)據(jù)情況。

（3）標注數(shù)據(jù) ：按照規(guī)則定義進行數(shù)據(jù)標簽處理。如果是一些分類標簽，可以在線下直接標注；如果是一些實體標注、關系標注就需要對應一套在線標注工具進行高效處理。

（4）訓練模型：訓練模型階段可以將已有標注好的數(shù)據(jù)基于已經確定的初步模型類型，選擇算法進行訓練。

（5）效果評估：訓練后的模型在正式集成之前，需要評估模型效果是否可用。需要詳細的模型評估報告，以及在線可視化上傳數(shù)據(jù)進行模型效果評估，并且在灰度環(huán)境進行業(yè)務驗證。

（6）模型部署：當確認模型效果可用后，可以將模型部署至生產環(huán)境中。同時要支持多版本管理、AutoScale等功能。

2.  整體架構  

（1）分布式存儲包括NFS、HDFS、CEPH。HDFS是存儲原始數(shù)據(jù)以及樣本特征，NFS是存儲訓練后的模型文件，CEPH是K8S集群的文件分布式存儲系統(tǒng)。

（2）底層計算資源分為CPU集群和GPU集群，高性能CPU集群主要用于部署和訓練傳統(tǒng)的機器學習模型，GPU集群則用來部署和訓練深度(遷移)學習模型。

（3）資源不同，計算的選型也有差別。機器學習訓練使用 Alink 做計算，通過 Yarn 來調度計算資源；深度學習訓練使用 K8S 做調度，支持主流的 Pytorch、Tensorflow、PaddlePaddle、H2o等深度學習框架，目前只是做到單機訓練，而模型的部署都是借助K8S進行統(tǒng)一發(fā)布和管理。

模塊對外提供數(shù)據(jù)標注、模型訓練、模型評估、模型管理、模型部署、模型預測等功能，同時平臺還抽象出分類、NER、評估、預測等組件。

3.  平臺構建實踐

平臺上層提供了一套標準的可視化操作界面，供業(yè)務運營人員使用，平臺底層提供全生命周期的模型管理，支持上層應用擴展。     

上文主要介紹NLP模型開發(fā)平臺構建的基本流程和整體架構 ，本章節(jié)會對技術選型與實踐進行展開。

（1）容器管理調度平臺選型

主流的容器管理調度平臺有三個，分別是Docker Swarm、Mesos Marathon和Kubernetes。但是同時具備調度、親和/反親和、健康檢查、容錯、可擴展、服務發(fā)現(xiàn)、滾動升級等諸多特性，非Kubernetes莫屬。同時基于OSS的機器學習工具棧大多也都是基于Kubernetes而進行的上層開發(fā)和應用，像我們熟知的Kubeflow等。另一方面深度學習領域通常是用GPU來做計算的，而Kubernetes對GPU卡的調度和資源分配有很好的支持和擴展。比如現(xiàn)在集群有多種類型的GPU卡，可以對GPU節(jié)點打上label，啟動任務配置nodeSelector實現(xiàn)卡類型的精準分配。最終我們選擇用 K8S 作為平臺的容器管理系統(tǒng)。

（2）GPU資源調度管理

目前較新版本的docker是支持 NVIDIA GPU的runtime，而不再考慮舊版的nvidia-docker或者nvidia-docker2。其實在runtime基礎上，是可以直接使用GPU來執(zhí)行深度學習任務的，但是卻無法限定GPU資源以及異構設備的支持。這里主要給出兩種解決方案：

a. Device Plugin

為了能夠在Kubernetes中管理和調度GPU， Nvidia提供了Nvidia GPU的Device Plugin。主要功能如下:

· 支持ListAndWatch 接口，上報節(jié)點上的GPU數(shù)量。

· 支持Allocate接口，支持分配GPU的行為。

但是這種機制導致GPU卡都是獨享的。特別是在推理階段，利用率是很低的。這也是我們采用第二種方式的主要原因。

b. GPU Sharing

GPU Device Plugin可以實現(xiàn)更好的隔離，確保每個應用程序的GPU使用率不受其他應用程序的影響。它非常適合深度學習模型訓練場景，但是如果場景是模型開發(fā)和模型推斷，會造成資源浪費。所以要允許用戶表達共享資源的請求，并保證在計劃級別不會超額訂購GPU。我們這里嘗試Aliyun在GPU Sharing上的開源實現(xiàn)，如下圖所示： 

在配置文件中，限定顯存大小，這里的單位是GiB：

執(zhí)行如下命令：

在11GiB的顯卡上，GPU分配狀況如下：

（3）網關選型

在使用Kubernetes的Service時，一個必須要面對和解決問題是：如何從外部（kubernetes 集群之外），訪問到Kuberentes里創(chuàng)建的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做推理設備時，可能會出現(xiàn)超時的情況，這里依據(jù)不同的場景對該值進行微調，以滿足使用。同時可以從Route Table中查看相應的URL。

（4）可視化

這里的可視化是指在進行模型訓練過程中，需要對模型性能進行評測和調優(yōu)。這里率先融入Tensorboard，隨后也將百度的VisualDl融入進去。在訓練過程中啟動一個單獨的容器，暴露出接口供開發(fā)者查閱和分析。

（5）模型部署

在第二章節(jié)中，介紹了不同功能的機器學習工具棧。在模型部署中我們使用Seldon Core來作為CD工具，同時Seldon Core也被Kubeflow深度集成。Seldon 是一個可在Kubernetes上大規(guī)模部署機器學習模型的開源平臺，將ML模型（Tensorflow，Pytorch，H2o等）或語言包裝器（Python，Java等）轉換為生產 REST / GRPC 等微服務。

下面是推理鏡像的構建過程，其中MyModel.py是預測文件：       

其中部分 deployments 描述文件如下：

四、平臺應用和成效

NLP模型開發(fā)平臺的構建極大地降低模型學習門檻，使業(yè)務人員不僅可以參與規(guī)則的制定，也可以參與到數(shù)據(jù)標注、服務發(fā)布、效果評估等多個階段。同時使數(shù)據(jù)科學家和機器學習工程師能更加專注于模型本身的算法和性能，極大地提高工作效率、簡化工作流程。下面舉例借助平臺在數(shù)據(jù)相關度、標簽處理等方面的成效。

1.  相關度

在過去幾十年中，已經實現(xiàn)了各種自動信息檢索系統(tǒng)。文檔的有效表示是能夠檢索文檔的核心，像矢量空間模型和概率模型都依賴于TF、IDF、文檔長度等特征因素。將文檔從文本轉換為數(shù)字或基于矢量的表示形式，排序功能就需要根據(jù)特定的查詢的相關性對文檔進行排序。其中Okapi BM25是IR中最著名和使用最廣泛的排序算法。傳統(tǒng)信息檢索方法沒有考慮語義信息等諸多因素。而隨后的Bert在GLUE中IR相關的基準測試達到最優(yōu)，其中一部分原因是因為其大量的訓練數(shù)據(jù)。此外基于Transformer神經網絡架構促進了輸入中各個token之間的深層關系，從而使模型可以更好地了解輸入中存在的關系。在真正應用中，需要考慮查詢意圖、查詢改寫、同義詞擴展等諸多技巧。下面將闡述在提高檢索相關度方面的嘗試和方案的演進，以及NLP模型開發(fā)平臺在這方面的成效和應用。

（1）基于查詢意圖的傳統(tǒng)信息檢索

輿情中的搜索往往是詞或短語，在缺少外部知識的情況下，搜索意圖往往無法得知。在使用Okapi BM25傳統(tǒng)的信息檢索方式，只能得到查詢關鍵詞與文檔相關，而并不符合搜索意圖。在當時的架構下，主要是基于Elasticsearch的全文檢索，以便考慮能否使用ES得出一個比較通用的處理框架。Elasticsearch是基于Luence的架構。很多要素都是一脈相承的，例如文檔和字段的概念、相關性的模型、各種模式的查詢等。流程如下圖所示：

這里的意圖擴展庫其實是對查詢關鍵詞進行擴展，例如，關鍵詞為”真功夫”，如果你的搜索意圖指的是餐飲品牌”真功夫”，那么可以擴展一系列行業(yè)相關詞：餐飲、門店、優(yōu)惠券等。聯(lián)合Query一起查詢，這里的意圖擴展庫（擴展相關詞）只是貢獻權重得分，而不作為檢索過濾條件，使用ES中should語句即可實現(xiàn)。這種機制在一定程度上緩解了數(shù)據(jù)相關度問題，特別是在垂直領域中，效果甚佳。而一旦涉及跨領域、搜索意圖寬泛，就顯得無能為力。

（2）基于Bert分類模型應用

在以上的實現(xiàn)機制中，都是無監(jiān)督排序算法的典范，這樣的排序算法并不是最優(yōu)的。在極度簡化的情況下，如果標簽定義為，某個文檔針對某個關鍵字是否相關，也就是二分標簽，訓練排序算法的問題就轉換成了二分分類（Binary Classification）的問題。這樣，任何現(xiàn)成的二分分類器，幾乎都可以在不加更改的情況下直接用于訓練排序算法，比如經典的”對數(shù)幾率”分類器或者支持向量機都是很好的選擇。這類算法稱之為”單點法排序學習”（Pointwise Learning to Rank）。這種機制與我們的應用場景十分吻合，只不過將Query上升為話題維度。而像DSSM等經典的文本匹配算法解決的是查詢串與文檔的匹配程度，查詢串往往是句子，而不是詞語。因此我們將相關度問題轉化為二分分類問題，召回階段使用Elastcsearch索引庫檢索，排序階段使用分類器對召回的文檔進行判定。

在這種機制下，為客戶提供了個性化服務。在NLP模型開發(fā)平臺的助力下，進行一站式處理，并且可以實現(xiàn)版本的迭代優(yōu)化。

2.  離線標簽

在一些定制化場景下，需要對離線數(shù)據(jù)進行標簽化處理。這是一個費時費力的過程，并且之前的勞動無法為后續(xù)的工作賦能。我們通過標注模塊對已有數(shù)據(jù)進行整合，并且對新標簽的樣本數(shù)據(jù)進行標注，從而快速為業(yè)務賦能，解放生產力。

以及在實體識別的場景下，可以直接在標注模塊進行標注：

五、平臺展望

1. 標注功能完善

在文本分類、NER等基礎標注任務的基礎上，還需要增加關系標注、seq2seq等主流任務的支持，以及任務分配、多人協(xié)作等特性。

2. 豐富算法模塊

在滿足基礎需求下，還需要增加文本匹配等算法模塊，滿足更加廣泛的應用場景。

3. 打造Piplines流水線式NLP模型開發(fā)平臺

模型訓練以及模型評估目前是耦合的，不利于組件模塊復用，所以要按照細粒度的模塊進行獨立拆分，再按照 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/

xiesc