亚洲乱码国产乱码精品精大量,中文字幕亚洲精品乱码,中文字幕无码人妻少妇免费视频

在早期，主要是圍繞和重復(fù)這三個(gè)模塊來支持業(yè)務(wù)。在業(yè)務(wù)規(guī)模小時(shí)，人工方式保證了工作的靈活與創(chuàng)新突破，但是隨著業(yè)務(wù)模式的成熟與增長(zhǎng)，逐漸凸顯出人工方式的局限性，主要體現(xiàn)在如下幾個(gè)方面：

（1）NLP模型開發(fā)任務(wù)的增多，無疑增加開發(fā)人員的維護(hù)工作，尤其是在算法迭代更新、模型版本管理等方面，將是災(zāi)難性質(zhì)的。

（2）業(yè)務(wù)人員是核心業(yè)務(wù)的把控者，但是由于模型學(xué)習(xí)門檻相對(duì)較高，使其參與度大大降低。

而NLP模型開發(fā)平臺(tái)的構(gòu)建不僅能解決以上問題，也更將聚焦算法工程師模型開發(fā)和基準(zhǔn)驗(yàn)證，使分工更加明確、全民參與。集數(shù)據(jù)管理、模型全生命周期管理、計(jì)算資源和存儲(chǔ)資源統(tǒng)一管理等特性，力求達(dá)到以下目標(biāo)：

（1）復(fù)用性：通用算法集成、算法管理、避免重復(fù)造輪子。從腳本開發(fā)到可視化操作，專注于算法效果提升和模塊復(fù)用。

（2）易用性：即便是運(yùn)營(業(yè)務(wù))人員，也可以定制私有業(yè)務(wù)模型，真正實(shí)現(xiàn)業(yè)務(wù)賦能。依據(jù)自己的個(gè)性化訴求可進(jìn)行數(shù)據(jù)標(biāo)注、模型訓(xùn)練、效果評(píng)估、模型發(fā)布等操作。

（3）擴(kuò)展性：算力資源可擴(kuò)展、模型算法框架(TF、Pytorch、H2o)可擴(kuò)展、語言(Java、Python、R)可擴(kuò)展。

二、NLP模型開發(fā)工具棧回顧

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

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

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

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

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

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

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

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

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

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

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

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

2. 整體架構(gòu)

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

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

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

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

3. 平臺(tái)構(gòu)建實(shí)踐

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

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

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

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

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

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

a. Device Plugin

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

· 支持ListAndWatch 接口，上報(bào)節(jié)點(diǎn)上的GPU數(shù)量。

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

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

b. GPU Sharing

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

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

執(zhí)行如下命令：

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

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

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

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

（4）可視化

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

（5）模型部署

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

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

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

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

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

1. 相關(guān)度

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

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

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

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

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

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

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

2. 離線標(biāo)簽

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