武道至尊帝临小说,最好看的小说排行,玄幻小说完本

企業級AI平臺是個什么鬼？智能企業為什么需要他

首席數字官
2019-04-04
來源:

文 | 周陽
來源 | 凱哥講故事系列

一直在尋找一個東西，一個可以把AI算法工程師的能力真正發揮出來的東西，作為算法工程師，一直以來感覺自己就是個廢物，尤其是在Thoughtworks這種并不以算法和AI見長的技術公司，偶爾折騰個模型，頂多只是炫技的表演，當同事問我怎么把這個東西用在項目上，也只能尷尬的笑笑，實在抱歉，因為沒有針對性的數據做訓練，這個模型的精度可能無法滿足實際上線的標準。算法可以被開發出來，但是卻無法在實際生產中產生價值，遺憾之余不勝唏噓，巧婦難為無米之炊，也許到最后優秀如我般的算法工程師只能離職另謀他就。

我們需要一個AI平臺

所以，類似于Thoughtworks這種具有核心業務的企業們需要一個AI平臺。

AI平臺就是幫助企業基于現有資源充分、高效利用AI技術達到企業發展愿景的生產工具，重點在生產工具。湊近些會看到這個生產工具有多個輸入：人才、數據、軟硬件資源，而輸出是針對業務場景的一個個或一組組的模型包，這些模型包對于企業現有的業務流程進行了或大或小的重構和變更，有的甚至顛覆了既有領域，更有甚者開拓了新的領域。

這個生產工具類似于計算機/操作系統 - AI資源（算法，AI硬件，數據）/AI平臺，這只是從技術發展上進行的一次簡單的類比，簡言之，想充分利用AI資源（人才、軟硬件資源、數據）來搞事情，搞好事情，AI平臺是絕佳的選擇。

所以，到底什么樣的AI平臺才是具有核心業務價值的企業真正需要的呢？作為優秀的算法工程師，我們有必要告訴老板除了漲薪以外怎么才能構建一個真正的AI平臺來讓你一展所長。

AI平臺的組成

所以，AI平臺的構建首先是要滿足算法工程師的日常工作需要。通常一個算法工程師的日常工作主要是模型構建、模型優化，這兩者之間沒有本質區別，可以細化為以下流程：

算法工程師根據自己設定的檢索條件獲取數據，并組裝訓練、測試和驗證數據集；
算法工程師根據模型的需要對數據進行預處理；
算法工程師對于模型設定合適的超參數；
算法工程師申請GPU/CPU資源進行模型訓練，查看模型的收斂效果；
算法工程師根據模型收斂情況和模型精度等指標判斷模型優化是否成功；
根據模型優化結果決定模型是否發布上線；
模型優化達到上線指標，模型發布生產環境，正式上線。

結合算法工程師的日常工作，不難發現AI平臺至少具備以下四個部分：

數據準備

對于算法工程師而言，數據準備是非常重要，卻希望盡可能少花費精力的工作。這里很容易讓人困惑，“希望盡可能少的花費精力”和“非常重要”怎么看都是矛盾的，其實不然，數據準備其實是給模型訓練準備輸入數據，這些數據的質量直接關系到訓練產出模型的實際精度、實際效果，模型優化中很重要的手段之一就是調整模型訓練的數據集，由此可見，數據準備對于模型而言真的非常重要，那為什么算法工程師通常希望盡可能少的花費精力呢？其實是現有的數據準備過程異常復雜導致的。

想想看，現階段算法工程師在進行模型訓練前是怎么進行數據準備的：

首先，啟動一個類似于Workbench一樣的數據庫管理工具；
鏈接正確的數據庫，手動翻查目標自動在那個表里；
找到之后，基于Sql做一些簡單的篩查；
... ...

額，忘記了，這是結構化數據，如果是圖片或者長文本數據，數據量巨大的情況下呢 …… ，很不幸，算法工程師已卒。優化或者創建一個模型，竟然需要付出“生命”的代價來準備數據，萬里長征僅僅是準備糧草就已經花費了兩年時間，內戰都結束了

所以，提供高效的數據準備功能是AI平臺必須具備的能力。至于實施方式，可以參看下圖：

圖中，藍色圓圈標識一種數據處理程序，內涵可簡單可復雜，其中：

Clean：數據清洗，這是數據挖掘里的一個概念，一般包括預處理、處理缺失數據、處理格式或內容錯誤的數據、處理邏輯錯誤的數據、去除不必要的數據和關聯性驗證；
Meta：基礎元數據抽取，例如數據類型、創建日期、創建人等；
Tag：數據打標簽，對數據進行粗力度等描述，例如場景（晴天、上海、樹蔭）、文本語言等；
Annotation：數據標注，這和AI領域強關聯，NLP領域是對文本做實體標注、計算機視覺領域則是對圖片進行實體標注，當然基于不同的應用場景，標注本身又包含多種形式，例如圖像標注中的目標框選、語義分割、3D/2.5D標注等。

可能還存在其他的數據處理環節，但是就數據準備而言，這四個環節是必不可少的，至于理由，可以從數據準備最后提供的功能來了解，參看上圖中的綠色方塊：檢索、組裝和下載。

檢索

數據檢索的拆解參看下圖：

除了結構化數據，半/非結構化數據都是基于全文檢索來實現的，如此這般，最核心的問題就轉變為如何為半/非結構化數據構建合適的索引，從而方便的提供給用戶進行數據檢索和檢索結果的排序。

而構建索引也恰恰是數據準備中最為困難和復雜的一個環節。之前講到的數據處理環節Meta、Annotation、Tag都屬于構建索引的范疇，不過，針對的數據類型、用途有區分，流程上也存在先后順序，參看下圖：

注：Annotation產生的索引信息，也可以稱之為標注結果，這個環節起初是人手工標注，隨著模型精度的提升，后續必然會演變為模型自動標注，這在后續的AI平臺的演進和未來這一節會深入描述。

當各種維度的索引信息被構建之后，檢索到目標數據將變得不再困難，目前，已經存在多種較為成熟的搜索技術框架可以幫助實現數據檢索和排序的功能，不再贅述。

組裝

數據組裝，就是在檢索功能之后，可以基于多次檢索結果來構建目標數據集，這個場景實在常見，想想看，我期望構建一個可以分辨貓和狗的分類器，于是通過檢索功能，分三次檢索，分別得到了有貓、有狗以及同時有貓和狗的圖片，當然，也許你會說，設置一個稍微復雜一些的檢索條件，可以一次檢索來獲取相同的結果，沒錯，但是并不是每個人都熟悉這么復雜的檢索語法，換言之，如果只想獲取第一次檢索的前10張圖片、第二次檢索的前30張圖片以及第三次檢索的所有圖片，換算成一次檢索的檢索條件，其復雜度呈指數級上升。聯想到之前數據準備的糟糕體驗，沒有數據組裝功能的數據準備實在不能說有大的改善。

對于檢索結果的組裝并不僅僅是數據的簡單組合，它內涵很豐富：

預覽：在檢索出結果以后，可以進行對象/記錄粒度的數據預覽，例如查看圖片以及標注以后的圖片、一封郵件的文本以及實體標注后的郵件內容等；更先進一些，在數據組裝成數據集之后，也可以對數據集中的數據進行同樣粒度的預覽。
去重：多次檢索的數據難免會有重復的數據出現，組裝數據集的過程中需要進行去重處理。
關聯：對于同一個目標數據的標注結果，需要進行合并或者關聯，只有這樣才能保證數據的完整性和準確性，同時減少冗余。
指標：用于衡量數據集質量，例如統計一個圖片標注數據集中所有的標注對象數量，可以以直方圖的形式展示；也可以基于一些算法或標準查看數據集中數據的分布情況。
分布：用于衡量數據集質量的高級功能，例如基于詞向量查看一個文本數據集中文本或句子的聚類情況；對于時序類數據集基于指標展示時序分布圖等。

數據組裝的這些功能，看似和大數據平臺的BI有些類似，但是有本質區別，大數據的BI是給業務人員看的，目標是輔助決策，數據組裝里的指標和分布是給算法工程師看的，目標是模型優化，看似差不多，實則大不同。

下載

數據組裝成數據集之后，就可以進行數據預處理，然后提供給模型進行訓練了，那數據下載是必要的環節嗎？很容易想到冰山理論，看到的只是漏出海面的冰山一角，背后其實存在著及其復雜的工作，數據下載就是隱藏在背后的一個尤為重要的功能。

數據檢索、數據組裝對于數據的操作基本都可以在內存中完成，但是組裝后的數據提供給模型進行訓練卻不能再循此例，為什么？因為性能。

所以，組裝后的數據集一定要下載到一個特定的存儲介質，可以極大化的減少模型訓練過程中數據加載的時間，這或許不是模型訓練必須的，但是對于規模化、工業化的AI平臺而言，這是必須的。

至于技術上使用什么樣的存儲介質，取決于模型訓練中對于計算資源的調度方式，就目前大熱的Kubeflow而言，使用專門針對Docker進行過I/O優化的技術方案是首選。

模型訓練

模型訓練可以理解為一個AI模型的集成開發環境——IDE。這個IDE提供一個資源包下載平臺，算法工程師可以基于自己擅長的AI框架和語言來開發自己的算法，或者干脆從代碼庫里拉取一份現成的算法代碼略做修改，算法、數據都有了，接下來只要倒數3、2、1，點擊“start”或者“submit”，一個模型訓練的任務就開始運行啦。對于用戶視角，到此就結束了，然而對于AI平臺而言，模型訓練的工作才剛剛開始。

微軟在2018年公布了自己的AI平臺OpenPAI，并心思巧妙的將之集成到Visual Studio2017，你看，還真給做成了一個IDE。

那么AI平臺到底是如何進行模型訓練的？參看下圖：

上圖可知，模型訓練核心是由兩個pipeline構成：模型pipeline和數據pipeline：

數據pipeline

有別于數據準備階段的數據處理環節，這里的預處理和模型、領域強關聯，參看下圖：

注：針對不同領域或數據的預處理可能羅列的不夠全面，歡迎補充。

不同領域或數據的預處理有各自的特點，但是目標是相同的（其實，也有統一的名稱：特征提取），就是將數據轉換為模型算法可以接受的輸入格式，對于深度神經網絡算法而言，多數情況都會轉換為張量格式。

有別于數據準備階段的數據處理的第二個不同點是數據集預處理往往會涉及到復雜的算法，且數據量巨大，對于企業級的AI平臺，借助于類似GPU這樣的算力資源來進行處理是必然的，而技術上更先進的策略還會引入分布式計算，這是另一個話題。

模型pipeline

runtime階段

模型pipeline準確的描述應該是模型訓練pipeline，首先是runtime環節，這是IDE的精髓所在，查看下圖：

從這個角度去看微軟把OpenPAI集成到VisualStudio實在是水到渠成的決定，不過對于企業自己的AI平臺，Jupyter系列的技術方案也許更靠譜一些。

runtime環節其實只是代碼開發階段，模型訓練實際運行是在training階段正式開始。

training階段

training階段的工作就類似于冰山理論中海平面以下的內容，參看下圖：

資源調度目前已經有了比較成熟的開源解決方案K8s（Kubernetes），尤其是針對存儲和GPU資源的調度，K8s都提供了較為成熟的解決方案。

注：K8s并不保證兼容所有廠商和型號的GPU，也不保證兼容所有的FS，對于不同FS的I/O性能目前也沒有官方的評測，具體的技術細節需要企業在實施過程中自行調研，這里不做展開。

模型驗證

模型驗證包含兩個階段：上線前的validation和上線后的A/B測試：

上線前的validation

這個環節通常包含在模型訓練的階段，在模型開發的過程中基于test/validation數據集調用所使用的AI框架提供的validation接口來編排，在模型訓練的過程中，也會迭代計算validation的結果來展示模型的訓練情況。

方法大體有兩種：

留一驗證：這個比較簡單，就是從任務提供的數據中隨機采樣一定比例作為訓練集，剩下的留作驗證集。通常這個比例為4:1，也就是80%作為訓練，20%作為模型驗證。也有很多是會是3:1等等。這有一個問題，那就是隨機采樣驗證集存在不確定性。驗證集合不是測試集，這是不同的兩個概念。
交叉驗證：其實就是多次留一驗證的過程。不過每次使用的驗證集之間是互斥的，并且保證每一條可用數據都被模型驗證過。例如所謂的5折交叉驗證，就是將所有可用數據隨機分為5分，每次迭代用其中一組數據作為驗證集，其他四組作為訓練集。相比留一驗證，交叉驗證更加可靠、穩定，因為所有數據都被訓練和驗證過。

所以，驗證的形式和數據pipeline中的拆分環節有很大關系，設計的時候要考慮到這種靈活性。

上線后的A/B測試

A/B測試必然和實際的生產環境和業務場景相關聯，原因很好理解，因為評價A和B兩種方案的指標和業務場景強相關，例如一家金融機構有一個對貸款人做信用評級的模型，輸入貸款人的相關信息，該模型可以計算出當前貸款人是否有能力償還貸款或者違約的風險概率。那么A/B測試的評價指標就是違約率，違約率低的方案自然是好的方案。

那么對于企業的AI平臺而言，結合自身業務構建業務端的A/B測試是必然的，參看下圖：

注：“生產環境帶標簽數據集”，這意味著這個數據集絕對是生產環境新產生的數據集，有別于模型訓練中使用的測試集、驗證集和訓練集合，其次結合A/B測試的技術手段可知，metric Index是基于統計規律計算而來的評價指標，所以需要具備足夠大的樣本空間（參考大數定律），也就是“生產環境帶標簽數據集”需要數據量足夠。

至于“生產環境帶標簽數據集”，恰恰和之前的“數據準備”對接上了，想想看，如果以數據的產生時間作為檢索條件，這樣的數據集在目前這樣的AI平臺上是不難獲取的。

模型發布

模型訓練pipeline，目的是為了產出模型文件——可以抽象的理解為一個確定了參數的公式，當然，不同AI框架下產出的模型文件格式各異，這種標準不統一的問題已然在AI領域引起了充分重視，包括Google、微軟等大廠都已經開源了自己的模型文件統一格式，雖然目前還沒有那種格式可以全部支持所有熱門的AI框架，不過也只是時間問題。企業在構建自己的AI平臺時，需要根據自己的算法工程師常用的AI框架來決定選用哪一種格式，不求全覆蓋，但求有價值。

注：對于通用模型文件格式，Google有TenserRT、微軟有ONNX，由于目前對于此類技術的研究會同時涉及到AI框架和GPU芯片等硬件層，所以每種格式都會有特定的限制條件，構建AI平臺時一定調研清楚再做選擇。

除了通用的模型文件格式，另一個需要關注的點是模型發布的形式，當然，通用的搞法是通過啟動一個應用服務來發布，應用服務接收外部request觸發加載模型文件生成response返回，然而，這里的服務采用的協議根據不同的業務場景有區別。

對于企業AI平臺而言，基于http協議來發布加載模型的應用服務是必然的，因為有一個場景在企業AI平臺上是始終會出現的——基于模型的Pre-annotation，這是AI平臺演進的必然趨勢，在AI平臺的演進和未來這一節會深入講解。

AI平臺的通用架構

在通觀AI平臺的組成之后，AI平臺的通用架構呼之欲出：

AI平臺的演進和未來

AI平臺目前也僅僅處于行業高速發展的起始段，或許現在大張旗鼓的探討AI平臺的未來為時過早，但是結合目前企業級AI平臺已然成型的實踐經驗對于AI平臺的演進和未來也能窺探一二。

在文章伊始，AI平臺被定義為一種生產工具，一種基于現有資源充分、高效利用AI技術達到企業發展愿景的生產工具。可想而知，在未來的發展進程上，生產工具的發展必然和企業自身的發展越發緊密，這種關系的進化可以通過下圖有個大概的了解：

第一階段：AI平臺

注：預標注就是Pre-annotation。

上圖是AI平臺第一階段的演化，這種演化是基于功能的，簡言之，對于AI平臺以及業務系統中的各個環節，例如Annotation、生產流水線中的質檢等，之前是基于人工或者粗放式邏輯來完成，后續會基于AI平臺產出的AI模型來處理，更進一步，有一些業務線將完全基于AI模型方案實現自動化，例如Annotation，隨著模型精度的提升，不久的將來，這些模型將完全取代人工標注是可以預知的。

第二階段：中臺發動機

當AI平臺和業務越發緊密，基于AI平臺能力的演進，更多的新業務、新場景、新能力被構建出來，此時，從業務的發展的角度而言，軟件服務的個性化、高度定制化必然會因AI技術的發展而成為新的趨勢，這一點很好理解，業務系統的每個終端用戶都是不一樣的，隨著個性化數據的累積，這種個性化必然會基于AI平臺產出的模型體現在業務系統提供給終端用戶的軟件服務上。

從更高的視角來審視這種趨勢，AI平臺發展到一定程度必然變成構建企業中臺的核心發動機，隨著業務的高度精細化、個性化、智能化，企業對于AI平臺也必然會提出新的需求和挑戰，這些挑戰無論是技術上的還是業務上的，都將是推動AI產業化進程的重要動力，讓我們拭目以待！

總結

全文洋洋灑灑幾千字，基于AI平臺的實踐經驗梳理了AI平臺的定位、核心組成、通用架構以及AI平臺的演進和未來：

AI平臺的定位：AI平臺被定義為一種生產工具，一種基于現有資源充分、高效利用AI技術達到企業發展愿景的生產工具。
AI平臺的核心組成：包括四個大模塊——數據準備、模型訓練、模型驗證和模型發布。
AI平臺的通用架構：層級架構，包括四個層級：借口層、APIs、Core Services、Platform Services。
AI平臺的演進和未來：體現在兩個層面，第一個層面是AI平臺自己的演化：模型文件到模型解決方案；第二個層面是模型對于業務系統的改進，分三個階段：替換業務環節演化到替換整體方案，最后到衍生出新的業務場景。最終聯想到業務系統未來會向中臺的方向演進，給出了企業中臺中AI平臺的價值和定位。