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

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

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

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

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

1. AI訓(xùn)練模型的基本流程簡介

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

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

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

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

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

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

2. 整體架構(gòu)

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

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

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

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

3. 平臺構(gòu)建實踐

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

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

（1）容器管理調(diào)度平臺選型

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

（2）GPU資源調(diào)度管理

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

a. Device Plugin

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

• 支持ListAndWatch 接口，上報節(jié)點上的GPU數(shù)量。
• 支持Allocate接口，支持分配GPU的行為。

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

b. GPU Sharing

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

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

執(zhí)行如下命令：

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

（3）網(wǎng)關(guān)選型

在使用Kubernetes的Service時，一個必須要面對和解決問題是：如何從外部（kubernetes 集群之外），訪問到Kuberentes里創(chuàng)建的Service？這里最常用的一種方式就是NodePort。它允許你使用任何一臺宿主機IP進行訪問。這種方式需要事先指明nodePort或者隨機生成nodePort，對接口資源較難管理。而使用像Kong、Nginx、HAProxy等主流網(wǎng)關(guān)所面臨的問題是：不是自服務(wù)的、不是Kubernetes原生的、為Api管理而設(shè)計，而非微服務(wù)。Istio 是微服務(wù)的服務(wù)網(wǎng)格，旨在將應(yīng)用層（L7）的可觀察性、路由和彈性加入到從服務(wù)到服務(wù)的流量中。而模型部署需要與Kubernetes深度融合，也不需要進行服務(wù)間的調(diào)用，最后選用Ambassador作為最后網(wǎng)關(guān)選型。Ambassador作為一個較新推出的開源微服務(wù)網(wǎng)關(guān)產(chǎn)品，與kubernetes結(jié)合得相當(dāng)好，基于annotation或CRD的配置方式與K8S渾然一體，真正做到了kubernetes native。下面給出一個實際中的一個例子：

其中 timeout_ms 默認(rèn)值為3000，在使用Cpu做推理設(shè)備時，可能會出現(xiàn)超時的情況，這里依據(jù)不同的場景對該值進行微調(diào)，以滿足使用。同時可以從Route Table中查看相應(yīng)的URL。

（4）可視化

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

（5）模型部署

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

下面是推理鏡像的構(gòu)建過程，其中MyModel.py是預(yù)測文件：

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

四、平臺應(yīng)用和成效

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

1. 相關(guān)度

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

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

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

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

（2）基于Bert分類模型應(yīng)用

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

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

2. 離線標(biāo)簽

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

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

五、平臺展望

1. 標(biāo)注功能完善

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

2. 豐富算法模塊

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

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

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

總結(jié)

以上是生活随笔為你收集整理的百分点认知智能实验室：NLP模型开发平台在舆情分析中的设计和实践（下）的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。