小白也能搭建深度模型，百度EasyDL的背後你知多少

隨著機器學習，尤其是深度學習在複雜資料上的表現越來越優秀，很多開發者希望能將其應用到自己的服務或產品中。然而即使是使用預訓練模型或開源框架，對於很多不太瞭解機器學習演算法工程的開發者而言還是有非常大的挑戰。此外，若機器學習不是產品的核心技術，額外維護機器學習演算法團隊的成本又非常高。因此，很多時候我們需要一種能快速使用高效能深度學習的方法。

從整體而言，構建我們自己的機器學習應用首先需要收集資料，並執行復雜而繁瑣的資料預處理，隨後如何選擇模型與各種層出不窮的修正結構也非常困難。在訓練中，需要經驗的調參過程與各種技巧也會對模型效能造成影響，更不用說需要根據資料情況選擇與修正最優化方法了。因此即使不考慮工程化問題，將機器學習模型部署到客戶端也有非常大的成本。

其實目前在 GitHub 上有很多優秀的機器學習開源專案，例如各種預訓練深度卷積網路、高度封裝的演算法以及大量開放資料集，不過要想復現以及根據實際情況調整這些專案，開發者還是需要一些 ML 領域知識。此外，很多專案的文件說明與技術支援都有待提高，它們需要開發者一點點除錯與試錯才能正確搭建。更重要的是，將訓練後的模型部署到移動端等平臺會遇到非常多的困難，這主要還是當前流行的深度學習框架並不能完美支援模型部署。

所以對於不太瞭解 ML 的開發者而言，最好將上述這些過程都自動化。例如我們只需要收集少量和任務相關的資料，並直接在平臺上完成標註，然後讓系統幫我們選擇合適模型與 超引數 進行訓練，最後已訓練模型還可以直接部署到雲 API 或打包成安裝包。其實現在也已經有一些平臺能完成這一些過程，例如谷歌的 AutoML 和百度的 EasyDL 等。

EasyDL 主頁：http://ai.baidu.com/easydl/

如下所示為 EasyDL 訓練模型的基本流程，整個過程都是圖形化操作，且如果是上傳已經處理好的資料，那麼強大的遷移學習系統會在幾分鐘內完成模型的訓練。百度 AI 開放平臺文件中心對 EasyDL 的建模過程有詳細的描述，因為這一圖形化的系統非常簡明，所以文件也通俗易懂。

如上所示，EasyDL 將整個服務精煉為四個步驟，並且可以在不需要機器學習背景知識的情況下開發模型。建立模型只需要選擇我們任務所屬的類別，例如影象分類或目標檢測等。訓練模型只是選擇我們建立的任務與資料，再點選訓練就行了，系統會自動搜尋各種模型架構和 超引數 。最後上線模型同樣也只需要確定到底是獲取雲端 API 還是離線 SDK，整個過程不會涉及到複雜的演算法與工程方面問題。

EasyDL 在 2017 年 11 月初上線了定製化影象識別服務，並在業內展開公開測試。在 2018 年 4 月、5 月和 7 月陸續釋出了定製化物體檢測服務、定製化模型裝置端計算和定製化聲音識別等多個定製化能力方向，並形成了從訓練資料到最終定製化服務的一站式端雲一體平臺。目前 EasyDL 的各項定製能力在業內廣泛應用，累計過萬用戶，在包括零售、安防、網際網路內容稽核、工業質檢等等數十個行業都有應用落地，並提升了這些行業的智慧化水平和生產效率。

主要技術手段

EasyDL 的主要優勢在應用案例的累積、簡明的產品設計與操作流程、支援移動端計算與部署等，而支援這些優勢的是 EasyDL 背後各種主要技術手段。例如 AI Workflow 統一大資料工程系統與分散式訓練系統，為 EasyDL 提供穩定的系統和流程支援；採用 PaddlePaddle 作為基本框架，為模型的搭建提供基礎；採用 Auto Model Search 自動搜尋模型 超引數 ，支援獲得更好的訓練效果；採用遷移學習訓練較小的使用者資料集，從而大大加強訓練效率與效果等。

AI Workflow 與 PaddlePaddle

AI Workflow 是百度對機器學習從訓練到上線構建的工作流引擎，它是一個將大資料成熟的工程系統與人工智慧分散式模型訓練相結合的引擎。它覆蓋了從訓練資料的儲存，ETL（抽取、互動轉換和載入）、模型訓練任務的發起、訓練叢集資源排程、訓練狀態監控同步、模型自動部署、服務釋出上線等全部環節，並實現了全自動流程。

總體而言，AI Workflow 的主要流程可以分為四個階段。首先第一階段是對資料進行預處理，例如對影象實現歸一化、大小裁剪與資料增強等。隨後第二階段是模型的訓練，或者說是學習過程，這一階段會基於百度研發的深度學習框架 PaddlePaddle 進行分散式訓練。訓練完模型後，第三階段就需要驗證模型的效果，也就是說使用者可以上傳小規模的測試資料，並對模型的召回率與精度等指標進行驗證。最後第四階段為服務的上線或模型的部署，在這個過程中我們可以將已訓練模型載入到雲端並對外提供服務，也可以打包為一組移動端開發套件，為進一步整合到其它任務中提供介面。

整個 AI Workflow 在系統層面和服務層面同樣也會有一些優化，例如 PaddlePaddle 團隊會對模型的訓練階段做很多優化，包括 GPU 的核心融合和利用 RDMA 優化分散式訓練等。而 EasyDL 團隊這邊也會在服務層面做一些優化，例如在推理階段中，他們需要優化任務排程，並加速模型推理速度。

在 AI Workflow 中，整個訓練和推理階段都是使用 PaddlePaddle 框架，它包含了許多高效能的模型演算法實現, 為最終出色的效果提供了強有力的支撐。雖然 EasyDL 的使用者不需要了解與使用 PaddlePaddle，但其多年的 AI 技術積累以及大量的業務使用驗證，使得框架對於各種任務都非常安全穩定。

此外針對於移動端部署，Paddle-Mobile 設計之初就對嵌入式的效能、體積、能耗、硬體平臺覆蓋等方面做了考慮。而 EasyDL 的端計算版本也是使用該框架設計更緊湊與高效的模型，並將其釋出到移動端。

自動模型搜尋與遷移學習

目前 EasyDL 採用了 Auto Model Search 的演算法，即系統會同時發起多個模型結構和 超引數 不同的訓練，並採用對應演算法進行最終模型的篩選，從而確保更優的模型效果。Auto Model Search 與後文介紹的 AutoDL 在功能上是相近的，但百度的 AutoDL 是一種神經架構搜尋方法，它關注於利用強化學習從頭構建神經網路。

Auto Model Search 是指對於同一方向的定製能力，也就是說它會採用多個經典模型以及不同的 超引數 配置，並分別進行訓練。然後再按一些策略挑選出比較好的結果，並完成模型的上線。其中系統可調的 超引數 包含神經網路型別的選擇，例如對於影象分類可以選擇 Inception、ResNet 或者其他。而對於每一個模型，可選的 超引數 包含批量大小、迭代數量和卷積核大小等。在確定模型架構，並配置完 超引數 後，每一個單獨的模型都會並行的訓練，並按一定策略選擇效果最好的模型。

其實 Auto Model Search 是針對特定使用者資料的，在使用者上傳與他們任務相關的資料後，EasyDL 會抽取多個已訓練深度網路，並採用遷移學習和不同的超參配置精調這些深度網路。如下所示在使用者確定好小型資料集後，EasyDL 可能會選擇 Inception v3/v4 和 ResNet 等，在固定這幾個網路前面層級的權重後，系統會根據使用者資料以及不同的批量大小和學習率訓練網路。

EasyDL 大量採用了遷移學習技術，各種基礎模型會在百度大規模資料集上進行預訓練，並將從中學習到的知識（Knowledge）運用到使用者提交的小規模訓練資料集上，從而實現出色的模型效果和快速的模型訓練。遷移學習的主幹是非常大的網路，而一般我們每一類只需要使用 20 到 100 多張影象就能完成對後面層級的訓練，且 EasyDL 也會採用Early Stopping等正則化手段降低模型過擬合的風險。

影象的遷移學習可能比較好處理，但 EasyDL 的聲音分類並不需要太關注序列上的長期依賴關係，因此它也能使用遷移學習。聲音分類的遷移主要會採用 MFCC 或加上快速傅立葉變換將音訊的時域資料轉換為頻域的圖，然後再利用與計算機視覺相類似的遷移方法傳遞與音訊相關的知識。而以後在處理語音識別等存在長期依賴性的資料時，主體模型可能會繼續用到其它遷移知識的技術。

此外對於影象方面的遷移學習，如果使用者需要區分非常精細的圖片或執行細粒度識別任務，那麼一般遷移學習主要會獲取影象的全域性資訊，它很難抽取精細特徵。EasyDL 其實也能處理這些細粒度識別任務，但遷移效果很大程度上會受到使用者資料的影響。因此訓練集圖片需要和實際場景要識別的圖片環境一致，且對於細粒度識別這種具有很多相似影象的任務，使用者需要增加更多的訓練影象。

最後，為了提升模型遷移效果，EasyDL 會做一些特別的資料增強操作，即增加一些影象以加強模型的遷移效果。例如假定使用者希望系統能識別兩個類別，併為這兩個類別提供了特定的資料，那麼系統會自動增加其它一些資料，並作為第三個類別。在訓練中，系統不僅需要識別使用者的資料，同時還需要識別自動新增的資料為第三類別。

神經架構搜尋

EasyDL 即將引入百度領先的 AutoDL 技術，這是一種 AutoML 的技術，它實現了深度學習網路結構的自動搜尋和設計。百度的 AutoDL 是工業界中的一個專案，因此它主要由三部分組成，首先第一部分是從頭開始搜尋神經網路架構，即神經架構搜尋。第二部分是神經網路的自動適配，也就是說根據不同的任務目標與需要進行適配，比如說目標是部署模型到移動端，那麼系統就需要考慮正確率、引數量和計算量等條件來適配網路。第三部分是設計網路的遷移能力，AutoDL 希望搜尋出具有強大遷移能力的一般性神經網路架構。實際上架構搜尋與遷移能力是存在相對關係的，系統花大量計算資源希望搜尋到針對特定資料有強大能力的架構，而可遷移性又希望系統找到的架構能推廣到其它更多的資料。

在架構搜尋策略上，目前比較流行的有進化策略、強化學習和基於梯度的連續空間搜尋方法。而百度的 AutoDL 主要是基於強化學習，其核心思路是希望能搜尋到儘可能廣的空間。為了將神經架構搜尋構造為強化學習問題，神經架構的生成可以視為智慧體對動作的選擇，動作空間也就相當於搜尋空間。智慧體獲得的獎勵會根據已訓練架構在驗證資料上的效能評估而定義。

不同的 RL 方法在表示智慧體的策略和如何優化它們存在差異：Zoph 等研究者使用迴圈神經網路（RNN）策略對一個字串進行序列取樣，該字串反過來對神經架構進行編碼。Baker 等人利用 Q-learning 訓練策略，該策略依次選擇層的型別和對應的 超引數 。這些研究，包括谷歌大腦早期提出來的 NASNet，它們都引入了非常強的先驗知識。

例如 NASNet 規定了網路實際上有多少單元，這些單元的搭建方式也是手動設計的，系統只需要自動設計單元的具體結構。而設計具體的單元結構也會存在一些先驗知識，例如限制單元必須是兩個操作輸出一個結果等。AutoDL 主要的方向是希望搜尋任何有向無環圖結構，這樣模型的表達能力和搜尋空間就遠遠大於之前的方法。此外由於降低了搜尋的先驗知識，因此計算力會變得非常大，這也就對強化學習的取樣效率有非常高的要求。

三階段的層級架構表徵，組成有向無環圖。

除了神經架構搜尋，模型的適配也是非常重要的方向。AutoDL 會將很多目標新增到強化學習的反饋值，例如我們考慮一些多工學習，模型會有一套衡量引數量、計算量與正確率的方法，並最終反饋到強化學習，從而修正搜尋方向。

AutoDL 採用的是一種 Hierarchical RL，它同樣也是基於 on policy。因為 AutoDL 的搜尋空間非常大，系統需要一些結構性的探索，因此搜尋空間的探索才回更有效率一些。NASNet 之前第一個版本是基於策略梯度（PG），第二版本是基於近端策略優化（PPO），雖然它們的抽樣效率比較低，但它們確實展示了強化學習在這一方面的能力。所以總體而言，AutoDL 主要還是沿著 NASNet 所開闢的方法，並利用其它技術與技巧提高取樣效率。

模型部署與裝置端計算

目前 EasyDL 有兩種釋出服務的方式，即生成線上 API 和離線 SDK。從應用場景來說，線上 API 能讓開發者更方便地與業務系統整合，因為線上 API 畢竟是 HTTP 層面的介面。而離線 SDK 有更低的呼叫延遲，對網際網路的依賴性也沒有那麼強，它可以利用本地計算資源實現更安全與穩定的計算。而從技術實現來看，線上 API 是雲端計算的形式，離線 SDK 是端計算的形式，它們主要的差別在於是不是需要對效能與能耗做權衡。

目前可以實現在 Android、iOS 等系統的 GPU、NPU 等晶片上對定製模型預測階段計算的加速。

線上 API 的能耗主要出現在服務端，系統不需要做太多的量化或者模型剪枝等優化，模型也不需要做特定的壓縮。此外，線上 API 對於晶片端的優化也只需要考慮各種雲端 GPU 來做一系列的推理加速。但是移動端的話選擇非常豐富，例如可以是針對高通系列的晶片、也可以針對神經網路NPU 或者針對可插拔的IntelMovidius 加速卡進行優化。因此離線 SDK 的技術實現相對而言要難一些。

一般對於機器學習開發者而言，在雲端訓練一個模型，並部署為一個服務已經比較成熟。但將模型遷移到裝置端仍然會面臨很多困難，開發者需要考慮硬體相容、能耗與效能等非常具體的問題。EasyDL 在釋出離線 SDK 的過程中就已經自動做了很多工程優化，包括對輕量模型的選擇和對計算階段的量化等。其中選擇輕量架構可以大幅度降低模型大小，量化可以大量降低包體大小，它們都能加速應用在記憶體中的載入。

總的而言對於裝置端計算加速，首先 EasyDL 會選擇 MobileNet 和 ShuffleNet 等輕量級的模型，例如在目標檢測中，系統可能會使用 MobileNet 代替 SSD 中的主幹網路，因而獲得更高能效比。第二點是系統會通過模型剪枝將不太重要的網路引數去掉，例如去掉 CNN 中權重小於某個閾值的連線或直接去掉不太重要的卷積核。第三點會採用量化操作加速推理階段的計算，其主要思想是降低卷積運算中數值的精度，從而降低整體的計算量與引數儲存空間。

裝置端加速第四點會採用很多指令集，包括 ARM 和 Neon 等，其中 Neon 是一種單指令多資料的指令集，系統可以通過一條指令加速多條資料，這些都是硬體層面的加速。最後裝置端還能從計算單元的角度進行加速，例如 GPU 和 NPU 等。

相關資料