基于人工智能場景的移動平臺工程化
本文主要是將我們在2017年相關的實踐做個總覽式的分享，希望能夠給各位一定的啟發。
一、人工智能的核心是工程化，場景是工程化的關鍵
首先總結一下，我們在做人工智能與移動互聯結合的時候，最重要的目標是：人工智能工程化。
做GPU的英偉達、提供開源的基礎框架TensorFlow的Google、研究各種算法的科學家，與我們分處人工智能產業鏈的不同環節，而我們的目標是尋找合適人工智能的場景，結合行業的一些經驗，形成工程化的解決方案。
人工智能(AI)賦能企業移動信息化建設，其本質上就是人工智能在企業移動信息化過程中工程化落地。
支撐人工智能工程化的過程需要依賴與數據、技術、場景的三者結合，并結合軟件工程化的思想將其融合。而這三者之中，場景是關鍵。
人工智能與數據并非一定強相關
這里提到的是“數據”，而不是大家經常提到的“大數據”，主要原因是“大數據”三個字很容易讓更多的技術團隊束縛思想讓自己無法從事于人工智能的工程化中。
甚至早期的人工智能都被某些技術社區劃歸到了大數據頻道，當然去年他們也剝離出來了，我認為人工智能跟大數據沒有必然直接的關系。
后面我們的場景中，并沒有強調大數據，而且從數據的角度可以通過主動學習(Active Learning)的方式來部分解決。
特別是當去年AlphaGo Zero 出現后，讓我也重新審視了我對人工智能的理解，數據到底是否還有原有的大家理解的價值。
AlphaGo Zero 在完全脫離人類經驗的情況下，一盤棋譜也沒有學習，完全超越以人類經驗為基礎的AlphaGo，同時創造了很多人類棋手原來未曾想到的棋局。以至與著名的棋手柯潔有意無意中都在模仿AlphaGo Zero的經驗來應對人類棋手。簡單點說，人類正在向機器學習。
AlphaGo Zero的出現，對于人工智能界，我認為***的觸動是證明了零數據的強化學習的巨大可能性和未來的空間。
我認為，未來的人工智能，技術(模型)的價值遠超數據(已有經驗)的價值必將成為共識。
技術提升加速AI實踐
這就回到了技術，技術離不開軟件、硬件、算法的迅速發展，技術上的提升，讓人工智能(AI)加速落地。技術上，主要圍繞在框架、算法、算力幾個維度去組建。
在后續的場景中，我們主要采用的是基于Google TensorFlow的平臺上，一些成熟算法或者模型上的應用，基于我們的算力和性價比，我們也會做出些取舍，比如用Faster-RCNN代替RCNN等。
客戶需要的是智能化應用場景
在企業進行移動信息化/移動互聯的建設中，都需要經過建設期、運維期、運營期等一系列階段，從用戶角度看，本質上需要的是一個個的智能化的應用Intelligent Apps(參見Gartner： Top 10 Strategic Technology Trends for 2018)。
對于工程化的落地，我們認為場景更重要，我們到底需要什么樣的智能化，支持我們做什么事情。
基于上述的思考我們抽取了幾個場景采用機器學習的方式進行了工程化實踐。
二、三類場景化實踐
場景一：移動智能開發平臺，讓工程師快速具備專家80%的開發能力
這部分工作在工程化過程中，我們分兩部分進行實踐：
- 訓練階段
- 應用階段
如下圖所示：
- 探索：主要是確認了場景后，結合框架、模型以及自有算力，尋求各種模型進行研究和實踐。在這個場景中，我們最終選擇了基于CNN的分類算法以及基于Faser-RCNN的目標檢測算法。考慮到數據的標簽工作量的問題，我們采用了遷移學習的方式。
- 訓練：根據探索確定的方向，構造標簽化的數據。在這個場景中，我們采用分類的標簽化工作和目標檢測的標簽化的工作。
- 推測：采用訓練后的結果，進行推測以驗證模型的效果。
關于為什么采用上述工具大家可瀏覽我上一篇文章《使用TensorFlow搭建智能開發系統，自動生成App UI代碼》。上述過程中是一個不斷調整不斷循環的工程，最終我們會選取一個模型。用于人工智能服務化(AIaas)和產品化的工程。
這個工程中主要采用的軟件工程的方式進行，需要考慮的是AIaas的工程中并發對算力的要求，我們采用的是AIaas之前增加了隊列和調度，這里就不贅述。
最終我們的大概的模型結構如下：
如上圖，CNN(VGG)、Softmax、Faster-RCNN等都是基于Google TensorFlow的搭建的，并且主要的工作圍繞在基于GPU架構下進行。
Basic Component、Complex Component、DSL Generator、DSL Code、Compiler、Runtime等部分，是主要基于傳統的CPU架構下的軟件思路整合。
通過AIaaS化，我們將基于TensorFlow的智能服務隱藏在基于Java 的SaaS服務之后，最終，開發工程師可以通過IDE的方式進行訪問，同時讓我們更新模型對于最終用戶無法感知，最終以“智能代碼助手”的試圖(view)在IDE中進行體現。
場景二：智能的連接和呈現，以智能化的CUI方式為最終用戶提供會話式交互體現。
CUI是移動端最近比較看重的體驗方式，相對于傳統的CUI，以純語音、文字的交互，已經演變成語音、文字、事件、連接、視頻等多種體驗方式。在這個范疇里，我還是比較認可百度DuerOS的負責人說的，有三個方面的工作：聽清、聽懂、滿足，并且對三方面有自身的理解：
- 聽清：將在各種場景下的語音，結合上下文的情況，轉換成文字。
- 聽懂：理解文字在特定領域的意義，這里要強調特定領域。我們遇到的一個客戶經常提到“寄遞”，在該業務領域，這個詞語背后代表著一系列安全與法規相關的問題。
- 滿足：為最終用戶提供強交互能力的體驗。
針對企業市場，“滿足”的解決方案沒有任何一個公有服務的方式能夠很好做支撐的，原因比較簡單，企業中大量“滿足”最終是通過自身私有的服務得以提供，而這部分必須采用私有部署的解決方案才能做到，也正是我們需要關注的重點。
關于聽清的解決方案，我們非常認可現有很多解決方案，都很成熟，包括baidu，最終我們默認的方案中優先選擇了訊飛 。
而我們在工程化中，主要圍繞著“滿足”展開，主要尋求以下兩方面的的解決方案支撐：
- 如何能夠調用到最合理的服務。
- 如何能夠提供給最終用戶最友好的交互體驗。
為此，我們基于關鍵字、語義等信息與后端Service的調用關系訓練模型，支撐智能連接。
同時，我們對服務調用的反饋結果以及移動端UI模型庫信息進行訓練，以提供智能顯示。
UI模型庫采用完全動態的方式，以支持各種復雜場景的支撐，從而達到高擴展性的發展。
在小小的手機屏幕下，容不下越來越多功能的時候，讓低頻的功能更方便的被使用，除了即用即走的二維碼入口的小程序外，CUI應該是一種非O2O更好的選擇之一。
場景三：智能推薦和輔助決策，讓用戶在適當的時間、地點，做“正確”的事情
從業務場景角度看，推薦、輔助等模型在技術維度和互聯網公司的“猜你喜歡”等并沒有太多差異性，需要說明一點的是，在做企業市場的時候，我們建議的方式，不是基于用戶，而是基于組織機構(比如崗位)去進行分析。原因很簡單，如果基于用戶習慣，會導致一個喜歡遲到的人，總是在遲到的時間點推薦其打卡，這顯然既不符合用戶的個人訴求，也不符合企業的利益。
為了支撐上述的場景，移動平臺需要的是能夠提供統一的數據收集能力。
采用統一前端技術，讓自動埋點的越來越容易，更方便用戶行為數據的收集。
同時采用統一中臺的方式，更加方便進行收集。
四、總結
在移動互聯時代，越來越多的App正在智能化，越來越多的場景正在發生，這是一個大的趨勢，但并不是所有的場景對移動應用本身沖擊都很大。很多AI場景對于移動平臺僅僅是一個SDK的問題，比如類似于生物識別(人臉識別)，此外，蘋果/Andriod 也都提供了基于手機端的AI技術支撐，因此，作為移動應用業者，需要重點考慮的是，如何將人工智能結合具體的場景，進行工程化實踐，讓AI迅速發揮業務價值。
關于作者：郝振明，現任普元信息移動集成產品部負責人，十多年IT從業經驗，一直專注于企業信息化的工作，近五年間一直從事企業移動信息化、移動互聯網化的咨詢、產品工作，曾主持參與了Primeton Mobile產品研發、聯通集團、廣東農信、諾亞財富、中信重工、索菲亞等公司的移動信息化工作。在移動平臺、微信解決方案、微信小程序、AI與移動的結合以及移動云方案等領域有豐富的經驗和獨到的認識。
