哈囉一站式AI平臺在多端智慧的探索

　　近年來隨著大資料時代的到來和計算能力的提升，人工智慧在各個領域都取得了顯著的進展。原先在雲端進行特徵的儲存與處理、模型的訓練、線上推理，在客戶端進行資料的展示的架構展現出越來越多的缺點和侷限性。本文將結合端智慧的優勢，結合哈囉一站式AI平臺的現狀，講述一站式AI平臺如何支援多端智慧（服務端、flink端、移動端）。

　　雲端推理模式

　　具體流程　　

圖1-1 雲端推理模式流程圖

　　首先雲端會將客戶端上報的的離線特徵和線上特徵資料進行儲存

　　雲端將離線特徵資料餵給模型進行模型訓練

　　模型在雲端訓練完畢後進行模型上線或者模型更新

　　客戶端觸發線上推理請求呼叫雲端進行線上預測

　　雲端線上推理結合特徵資料和模型檔案進行預測

　　雲端返回排序結果和資料在客戶端展示

　　問題

　　頻寬和延遲問題：所有客戶端使用者的請求都要先到雲端進行推理後，才能在客戶端進行展示，網路傳輸存在一定耗時；若推理所需特徵較大（如圖片，影片等），會導致延遲很高，以及網路頻寬壓力非常大

　　資料安全：使用者的資料都需要透過網路傳輸上傳到雲端，存在洩漏風險

　　資料隱私：部分資料為使用者隱私資料，無法儲存在雲端

　　成本問題：所有的線上推理都在雲端，則雲端需要部署大量伺服器提供線上推理能力，成本巨大

　　中心化問題：所有的線上推理都需要走雲端介面，若網路異常或者雲端服務異常，則會導致推理能力失效

　　端智慧模式

　　端智慧技術是指將計算、儲存和推理從中心化的雲端轉移到網路邊緣裝置（如智慧手機、物聯網裝置等）的技術。

　　具體流程　　

圖1-2 端智慧推理模式流程圖

　　首先雲端會將客戶端上報的的離線特徵和線上特徵資料進行儲存

　　雲端將原有的離線特徵資料和新上報的離線特徵資料餵給模型進行模型訓練

　　模型在雲端訓練完畢後的模型進行模型上線或者模型更新

　　客戶端定時觸發模型版本更新，雲端識別到客戶端模板版本過舊會告訴客戶端需要更新模型

　　客戶端定時觸發雲端特徵查詢，會將雲端查詢的資料和歷史資料儲存起來

　　客戶端結合特徵資料和模型檔案進行線上推理

　　客戶端進行排序和結果展示

　　端智慧優勢

　　客戶端的線上推理依賴的特徵和模型都在本地執行，無網路頻寬和延遲問題

　　資料本地化儲存，無資料安全和隱私問題

　　線上推理本地化，雲端故障或者網路故障不會導致無法線上推理

　　線上推理本地化，雲端無需提供服務，可降低成本

　　哈囉一站式AI平臺當前現狀

　　整體架構　　

圖2-1 一站式AI平臺架構圖

　　一站式AI平臺從劃分來說劃分為訓練平臺、模型平臺、特徵平臺、決策平臺

　　訓練平臺

　　提供離線上模型的訓練、模型開發環境資源管控、模型訓練資源管控、離線模型推理、離線模型管理、分散式訓練、分散式預測

　　模型平臺

　　提供tf1/tf2、pmml、python、python-gpu四類線上模型的模型管理、模型資源管控、線上推理能力

　　特徵平臺

　　提供離線上特徵儲存、實時特徵計算、特徵關聯、特徵加工、特徵選擇、特徵清洗、特徵查詢等能力

　　決策平臺

　　基於DAG流程編排能力，提供了串聯groovy指令碼、多模型，多特徵的流程編排，統一對外提供線上推理能力

　　整體流程　　

圖2-2 AI平臺簡易流程圖

　　如圖2-2所示，表示了簡易的一站式AI平臺的流程圖。

　　1. 特徵建立和變更

　　線上特徵儲存：使用者在AI平臺先建立特徵，將離線特徵轉為線上特徵儲存起來

　　線上特徵新增和變更：特徵和特徵儲存的關係會透過AI平臺的配置變更，同步給線上特徵服務FeatureService

　　2. 模型訓練和建立，以及模型版本管理

　　模型訓練：使用者在AI平臺透過遠端任務觸發模型的訓練，訓練完成後產生模型檔案，生成本地檔案或者上傳到oss

　　新增模型：使用者在AI平臺透過新增模型模組將本地模型檔案或者oss模型檔案和模型繫結

　　模型變更：使用者可透過離線訓練方式手動在AI平臺更新模型，也可以透過定時任務訓練模型後觸發自動模型更新

　　3. 線上推理

　　使用者在決策平臺先繫結模型和特徵的關係以及groovy規則的關係，生成決策

　　業務服務呼叫決策服務，經過groovy規則、灰度、特徵查詢、特徵預處理後傳給模型進行線上推理

　　決策服務將推理結果返回給業務系統

　　移動端智慧

　　整體流程　　

圖3-1 AI平臺移動端智慧方案簡易流程圖

　　如圖3-1所示，表示了移動端智慧方案簡易流程圖，和2-1對比差異點如下。

　　1. 模型模組

　　模型版本管理：原先模型版本管理是在一站式AI平臺完成，業務呼叫方只需要給出決策id就能知道可執行的模型，而端智慧後，前端需要配合進行模型管理

　　模型檔案分發：原先模型檔案產生後，會將模型檔案分發到雲端的模型服務ModelService，端智慧後需要將模型檔案分發到每個使用者的移動端

　　模型執行環境：原先模型的執行環境是在ModelService整合的，現在模型線上推理在移動端，需要在移動端支援模型的執行環境

　　2. 特徵模組

　　特徵的儲存原先只在雲端，端智慧後端上會儲存資料

　　線上推理不再依賴雲端資料，而是依賴本地特徵資料（端智慧後移動端會定時拉取雲端特徵到本地）

　　3. 決策模組

　　原先決策是作為服務給業務方呼叫，端智慧後需要打成sdk包給移動端呼叫

　　決策服務原先只給後端服務呼叫，端智慧後需要支援移動端請求訪問

　　挑戰和方案

　　1. 端上版本更新挑戰

　　在端上執行模型會依賴特徵資料、特徵預處理邏輯、模型檔案、groovy規則，依賴庫會有依賴關係，如果部分是實時分發更新，部分是依賴移動端發版，則可能會導致不一致，且依賴移動版發版時間。

　　方案

　　將可以動態釋出的模型檔案、特徵預處理檔案，groovy規則，依賴庫打包成一個演算法包，支援動態更新和統一版本管理

　　2. 模型檔案分發挑戰

　　從ModelService轉為移動端，數量大大增加。ModelService為雲端系統pod數，基本是幾百，移動端是使用者收集app，則會在千萬級別。

　　方案

　　雲端透過使用者手動或者自動訓練完模型後更新的oss，使用者開啟App後定時check演算法包是否存在更新，若存在更新，則從使用者最近的CDN節點拉取演算法包到app

　　3. 包大小挑戰

　　由於端上資源有限，因此對新增的決策sdk包和模型檔案大小以及計算資源會有一定限制。

　　方案

　　決策：對決策做最大化的瘦身，只保留一站式決策可執行的最小版本能力（如：groovy規則、特徵預處理）

　　模型：控制模型的引數量級、拆分部署；基於MNN框架對模型進行壓縮

　　4. 適配挑戰

　　移動端由於每個使用者的裝置都不一樣，會有不同的適配成本。

　　方案

　　目前一期僅支援在基於MNN在安卓裝置進行，IOS相容方案仍在探索中

　　5. 模型執行挑戰

　　模型檔案需要在端上執行，端側得支援可執行模型檔案的環境。

　　方案　　

圖3-4 基於MNN的執行結構圖

　　基於淘寶MNN開源引擎，在端側適配模型可執行的環境

　　flink端智慧

　　整體流程　　

圖4-1 AI平臺flink端智慧方案簡易流程圖

　　如圖4-1所示，表示了flink端智慧方案簡易流程圖，和2-1對比差異點如下。

　　1. 觸發邏輯

　　原先雲端的模型觸發都是基於soa介面方式觸發，改為flink端後，線上推理都是基於訊息觸發

　　2. 模型模組

　　模型執行環境：原先模型的執行環境是在ModelService整合的，現在模型線上推理在flink，需要在flink端支援模型的執行

　　模型更新互動變化：原先模型的載入都是ModelService中監聽模型新增或者修改，現在模型的新增和更新需要在flink端監聽apollo配置變化，在flink端替換新模型

　　3. 特徵模組

　　特徵儲存介質變化：特徵的儲存原先只在雲端的線上儲存中，flink端智慧後需要將特徵存在在本地磁碟或者記憶體中

　　特徵更新互動變化：原先特徵的新增或者修改都是在FeatureService監聽特徵的變化，將特徵和儲存的關係維護在特徵服務中，現在需要在flink端監聽特徵變化，且需要將特徵直接拉取到flink本地磁碟或者記憶體中

　　4. 決策模組

　　原先決策是作為服務給業務方呼叫，端智慧後需要打成sdk包給flink端呼叫

　　挑戰和方案

　　1. 模型呼叫本地化

　　模型呼叫由SOA方式改為本地呼叫。

　　方案　　

圖4-2 模型呼叫本地化

　　flink會接入決策SDK，並透過tf for java將模型載入到本地，提供模型線上推理能力。模型更新後由AI管理平臺更新apollo配置資訊，flink端透過監聽apollo方式進行模型更新。

　　2. 特徵本地化

　　透過將線上資料預載入到記憶體或者本地磁碟，進行特徵的加工處理和本地呼叫。

　　RocksDB方案　　

圖4-3 RocksDB方案

　　a. 特徵變更

　　特徵分發系統會監聽hive表特徵變更，在特徵分發系統將特徵資料轉成SST檔案

　　特徵分發系統會將SST檔案上傳到oss，並將配置變更通知apollo配置中心

　　flink端監聽apollo配置變更，將sst檔案拉到本地磁碟

　　b. 特徵查詢

　　flink端執行線上推理會從RocksDB查詢本地磁碟的資料

　　記憶體儲存的方案　　

圖4-4 記憶體方案

　　透過flink hive connector的改造，將hive的離線資料，透過Partitioned的方式，讓每個taskmanager只載入部分所需的維表資料。

　　記憶體儲存的最佳化挑戰

　　a. Partition分割槽如何做？

　　基於使用者id對資料進行預設分割槽

　　b. 記憶體如何最佳化？　　

圖4-5 自研序列號方案

　　基於團隊自研的fast_bytes序列化方案，可以將記憶體資料降低為之前的三分之一

　　應用端智慧

　　應用端智慧即在業務應用服務中，直接儲存特徵資料，執行模型進行線上推理。

　　整體流程　　

圖5-1 業務應用端智慧方案簡易流程圖

　　如圖5-1所示，表示了應用端智慧方案簡易流程圖，和2-1對比差異點如下。

　　1. 模型模組

　　模型執行環境：原先模型的執行環境是在ModelService整合的，現在模型線上推理在業務應用，需要在業務應用支援模型的執行

　　模型更新互動變化：原先模型的載入都是ModelService中監聽模型新增或者修改，現在模型的新增和更新需要在業務應用監聽apollo配置變化，在業務應用替換新模型

　　2. 特徵模組

　　特徵儲存介質變化：特徵的儲存原先只在雲端的線上儲存中，業務應用智慧後需要將特徵存在在本地磁碟

　　特徵更新互動變化：原先特徵的新增或者修改都是在FeatureService監聽特徵的變化，將特徵和儲存的關係維護在特徵服務中，現在需要在業務應用監聽特徵變化，且需要將特徵直接拉取到業務應用本地磁碟或者記憶體中

　　3. 決策模組

　　原先決策是作為服務給業務方呼叫，端智慧後需要打成sdk包給業務應用本地執行線上推理

　　挑戰和方案

　　1. SDK設計　　

圖5-2 決策sdk設計圖

　　如圖5-2所示，展示了決策sdk的整體設計。

　　模型服務將模型的載入，監聽模型變更，優雅預熱等邏輯打包成模型sdk

　　特徵服務將特徵的載入，監聽特徵變更等邏輯打包成特徵sdk

　　決策線上服務將ABTest，流程編排，計算邏輯，特徵預處理邏輯以及模型sdk，特徵sdk邏輯打包為決策sdk，給業務應用呼叫

　　2. 模型型別相容挑戰

　　當前的業務應用如為java應用，則在執行時，只支援tf和pmml模型，python和python-gpu模型無法支援。

　　方案

　　目前短期解決方案為將部分python模型轉為tf或者pmml模型打入業務應用進行執行，長期來說AI平臺會探索為各類模型提供一個統一的執行環境，或者可支援的轉換工具支援各類模型在同一環境中執行

　　3. 模型本地化

　　模型呼叫由SOA方式改為本地呼叫。

　　模型執行方案　　

圖5-3 模型呼叫本地化

　　業務應用會接入決策SDK，並透過tf for java將模型載入到本地，提供模型線上推理能力。模型更新後由AI管理平臺更新apollo配置資訊，業務應用透過監聽apollo方式進行模型更新。

　　模型生命週期管理方案

　　新增或者修改模型上傳到oss，通知apollo配置變更，應用服務監聽配置變更，呼叫jni的tf介面載入模型到記憶體。在新老模型預熱完畢後呼叫api介面解除安裝模型。

　　模型更新方案

　　a. 新老模型如何同步執行？

　　建立兩個模型物件進行管理，支援同模型新老版本同時執行。

　　b. 新老版本更新的如何優雅預熱？

　　基於模型歷史一小時的rt均值，以及當前最近20次請求rt是否小於該均值進行判斷是否預熱成功。如果預熱成功則新老模型切換。

　　4. 特徵本地化挑戰

　　本地化特徵存在特徵資料過大，導致業務應用啟動過慢，無法快速擴容等問題。

　　方案

　　將特徵載入從單執行緒轉為多執行緒載入，並最大限度用上ESSD盤或NAS盤的IO上限

　　5. 線上特徵挑戰

　　線上特徵如果業務應用直接呼叫，會存在連線池無法管控，呼叫量無法管控，線上儲存壓力過大導致互相影響等問題。

　　方案　　

圖5-4 線上特徵管理圖

　　透過AI平臺統一的連線池管理，核心業務線上儲存隔離以及限流機制避免線上儲存的壓力過大，互相影響問題。

　　目前一站式AI平臺已經能夠支援在多端進行線上推理能力，但是很多細節點需要持續最佳化。後續一站式AI會基於當前問題對各端智慧方案進行持續最佳化，也會基於業界主流的AI平臺架構和方案，持續對AutoML、AutoFE、模型Fass化部署、分散式訓練和預測進行持續的建設和演進工作。