Zi 字媒體

一、我們的現狀與期望首先，我們作為一個移動平台產品，必須解決的是讓工程師更加容易的開展工作，「知識工作者智能化」是我們探索的方向，讓移動開發工程師先用起AI，也是我們的期望。 針對我們的移動開發工程師，我們的主要的工作概括說有三件事： 了解需求拿到UI設計研發 我們期望的是，基於機器學習（ML）的移動平台，最終能夠：讓初級開發人員具備專家80%的能力讓AI輔助移動App的研發工作。 對於AI，BAT有著不同的看法，馬雲的數據論，李彥宏的技術論，以及馬化騰的場景論，我個人馬化騰的論調跟我們不謀而合，我們認為切入點很重要。 我們的切入點是：從設計稿（或者App 截圖）到App 前端代碼，這也是我今天分享的方向。 二、我們的初級探索與建議為了，我們在實踐的前期，進行了一些探索並總結了一些建議，希望能夠給大家一些啟發。 正如大家所知道的基於機器學習工程話的過程，需要數據、演算法、算力以及工程話的配合，是一個不小的工程，我們的初步想法，是否借力SaaS的服務能力，於是我們進行了公有雲服務的嘗試。 我們找了一張狗狗的圖，實際的效果非常的贊。 準確識別狗，並且能夠識別到品種；（潛台詞：能夠識別不同設計就好了）有「鼻子」有眼的，看上去很美，（潛台詞：能夠識別設計里的UI控制項就夠了）於是，我們抱有很大期望的用設計稿作為嘗試，效果大致如下： 實際上效果如上圖，無法準確的認知這是一個設計圖，更不用說是什麼類型的UI以及UI內有哪些控制項，於是我們嘗試了另外一家。 實際上效果，依舊無法使用。經過公有雲不成功的嘗試我們總結了一下的結論： 於是，我們進行了私有雲的建設，使用了已有的模型。 普遍的目標檢測都是無嵌套結構的認知而App 的UI是一個結構化數據，存在嵌套關係、層級關係上圖中的目標檢測對於生成代碼沒有任何幫助三、智能開發系統的自建之路於是我們走向了智能開發系統的自建之路 在前期的初級探索中，我們已經非常明確的知道：訓練的方向，決定了結果。而我們的方式是： 專註：訓練一個只懂移動UI的程序員學習移動App UI 的設計稿或者截圖不學習Web UI 或者GUI的設計稿堅決不學習常規事物  上面的原則主要的目標是為了訓練的專註性，我們調戲一把。 同樣的這隻狗，在公有雲的服務中都能夠準確的認知，而我們的系統把它當成了歡迎頁（0.72）而不是狗。來看一小段視頻：視頻說明： 右二窗口：是設計稿或者截圖（支持：jpg、PNG等常見格式）左上窗口：以命令行式的方式觸發智能開發系統左下窗口：普元移動平台的IDE，生成的代碼會自動同步到IDE中。右一窗口：手機實時投屏，生成的代碼運行的效果將會在這裡呈現 大致效果已經看到了，我們如何針對這個系統進行自建的呢？既然為工程師服務，我們先回頭看一下，工程師一般是如何工作的吧。 拿到設計，先判斷一下是個什麼類型界面大概由幾部分組成，什麼都有哪些控制項編寫代碼微調代碼，調試，根據與設計圖的差距進行調整針對第一步，我們可以採用分類的方式，確定界面類型。 這裡主要採用的演算法是CNN+softmax大致的效果如下： 在分類上我們的一些工作主要有以下的內容： 遷移學習 CNN（Inception V3 or VGG 16）：模型微調，應用到我們的數據集上分類器的選擇：Softmax更適合，放棄Logistic數據集：數據集的積累，並考慮結構的依賴，大量引入灰度圖片應用：採用原色及灰度兩種，二者取其高低概率：引入人工干預，每個使用者都是監督者閉環：數據集及分類的積累 其中遷移學習重要採用的是基於已有的CNN網路，微調數據模型，應用到我們的數據集上，我們嘗試過Inception V3 和 VGG 16，效果都還不錯。具體的工作如下： 選用CNN模型，前面各層的參數都不變，而只訓練最後一層。將自己的訓練集中的每張圖像輸入到CNN網路中，得到2048個維度的向量特徵。利用這些特徵來訓練softmax的多分類器 關於數據集的準備，必須為是基於移動的UI或者設計，這樣才能保證訓練后的方向和效果。 這裡通過移動平台在各個項目組的實施，收集到各類移動界面圖片，我們利用這些圖片作為移動的數據集。 在數據集的訓練中，我們發現，針對在很多分類下，色彩可能是一種干擾，而有些分類下，色彩卻對特徵值影響很大，所以我們採用了同源灰圖訓練，以提高正確率。 通過上圖，可以看出，結合同源灰圖，這個UI的識別率從0.748上升到0.911。究其原因，對於有些UI的分類，結構比色彩更重要。 為此，在應用過程中，在使用者上傳了一張設計圖的時候，我們將會處理成一張原圖、一張灰圖，進行分類，並選取較高概率的使用。 當然並不是所有的，我們都會有高命中，在無法準確判斷分類的時候，我們會讓「每一個使用者都成為機器學習的監督者」，讓使用者自行選擇適合的分類，如下圖所示： 比如有的個人設置的UI，系統會在List 和Setting 兩個分類上糾結不止，那就讓使用者協助我們做個選擇，這樣我們就將數據加入到數據集上，讓系統能夠更加準確的進行。我們稱之為閉環。 閉環更為重要的是，當我們能夠發現分類的不足，讓用戶自行創建分類。對於設計稿中的UI控制項，其自身特點是嵌套的，為此我們採用多級目標檢測的方式，確定其UI類型以及層次關係。 主要的演算法採用的是Faster-RCNN，除了效果外，採用Faster-RCNN的原因是算力問題，這個演算法在RCNN里，算是比較高效的了。 以下為監測效果：可以看出通過訓練后的目標檢測，已經能夠相對較為準確的識別。 左圖是微信里的AED分佈（推廣一下，這個對於急救非常重要，建議大家都可以了解一下）的截圖 。右圖是採用了一個設計圖 。在上圖中不僅僅包括目標檢測后的常規結果，我們還將坐標輸出，這為後續代碼生成時候的布局非常重要。 在目標檢測上我們做了以下的一些工作。 多級Faster-RCNN，避免單一的Faster-RCNN導致目標檢測結果疊加閥門（0.8）控制退出，組件優先。加大數據集的積累，避免天窗效果（傳統的目標檢測沒有這個問題）。參數的調整：eg. ANCHOR_SCALES（無須太小） 、BATCH_SIZE（與數據集數量匹配，不易過大過小）、RPN_NMS_THRSH（模型訓練越好，越可以提高，但不易過高）等等 這裡需要說明一下什麼叫做天窗效果，就是說，在整個設計圖中我們有一部分的UI區域，沒有識別出來。我們採用的方式是通過其他識別出來的區域，計算出相關區域的位置及大小，留好相關的空間，具體可以參照視頻中第三個例子。 在代碼生成部分，我們採用了基於DSL語言，生成的方式，主要考慮的因素有一下三點，第四點是一個小tips。 我們先看一下，原生語言的代碼複雜度吧。 為了實現這個設計圖，如果採用未經封裝的原生代碼，大概需要幾百行代碼，你可以自己看一下右圖最右側的滾動狀態就知道。 所以，我們採用了我們普元移動平台的DSL層進行生成，實際上大概一兩屏的代碼就可以了。具體可以參見視頻中的第二個例子。 這裡要補充一點，在之前關於移動前端技術的分享中有人為我為什麼一定要用DSL層，我說了一些原因，但因為這個分享還沒有做，所以沒有提及這一點。 那在看一下，天窗的處理吧，我們採用了佔位的方式。 左圖是生成的代碼，右圖是生成代碼運行后的效果，對於未識別的區域，我們採用了佔位，並加以提示：」對不起，我暫時不認識「，讓使用系統的工程師能夠直觀的了解到，哪些部分AI沒有幫助到他，他需要自行完善。 針對生成的代碼並結合運行的效果，我們採用強化學習（RL）的方式對於代碼進行微調。 主要的工作為：Actons 只針對component屬性調整，不對代碼結構調整評分系統依賴原有輸入（設計稿或者截圖）Environment採用生成代碼后的運行截屏結合區域性評分（結合Faster-RCNN過程的切圖）暫時只針對位置、字體大小等 這一部分，由於時間原因，就不再展開了。說了這麼多，讓我們一起看一下，這個系統的總體結構吧。 當一張設計圖被傳入系統的時候，首先基於CNN+Softmax的分類系統會將其分類處理（框架層代碼在這一層次生成）。 對於設計稿中沒有多級層次的設計，會直接進入Faster-RCNN進行一次目標檢測，識別對應的Basic Component，結合之前的代碼，生成新的代碼片段。對於複雜的設計，會進入多次Faster-RCNN進行下一層次的目標檢測，直至可以進行代碼生成。 當生成代碼后，系統會自動編譯代碼，並將代碼Run起來，這時候就可以進行截圖，進行強化學習，對代碼進行微調。 上述就是這個系統的主要的技術分享，這個系統也不斷在完善中，我們後續也會繼續完善。 四、未完待續首先，對於文字的處理，可以看到，我們並沒有直接生成，而是採用了「文字」來代替，主要的原因是文字的處理，屬於另外一個範疇的人工智慧，我們主要的思路是直接對接成熟的OCR或者雲服務，不會自己去做的。 關於圖片和icon的處理，可以看到，我們採用的是默認的圖片，而非設計稿中的圖片，這一點，我們會繼續進行。 方案大致是：一種是設計師提供設計圖，並有小的切圖，這個處理比較簡單。另外一種是無原圖或者需要對接圖庫的（圖庫規模不大的情況下），擬採用CNN+Softmax做一次分類，每一張圖片一張分類 。同時，我認為AI將會繼續賦能移動，在AI結合移動，我們也在其他的方向進行了實踐： 智能化的CUI（Conversational UI）智能推薦及輔助決策 由於時間和篇幅的原因，可能會沒有講明白，歡迎從事相關研究的同仁，添加作者微信一起探討。郝振明普元移動產品線總負責人，十多年 IT 從業經驗，一直專註於企業信息化的工作，近五年間一直從事企業移動信息化、移動互聯網化的諮詢、產品工作，曾主持參與了 Primeton Mobile 產品研發、聯通集團、廣東農信、諾亞財富、中信重工、索菲亞等公司的移動信息化工作。近兩年來，致力於基於 React Native 工程化能力的提升、降低實施難度，以及智能化移動平台的產品研發，在移動開發智能化的路上不斷進行探索。關於EAWorld