在 AI 衝擊下，我好似要回校園攻研究所一般
這一個大家努力學習 AI 的跳躍式學習年代，如果我們不把曾經在學校學習 的統計演算方法論，好好再磨練一下，似乎就會被淹沒在 AI 人工智慧洪流下， 無法著力一般。於是大家開始努力學習起 Python 程式語言，並且好好將統計相關的演算法複習一下，甚至投入更多的時間重新學習起。
最後的目標可能是，老闆交代的一個《臉部辨識系統》或者是《大數據推測預防系統》，又或者是個以前不敢想像的創意延伸與預測系統等等。
所以現在只要談到 AI 架構的學習，往往不外是：
資料分析技術
了解線性代數基本觀念
了解卷積神經網路基本概念
了解TensorFlow(API)基本架構
...
這年代，如我們沒有將一些 AI 演算方法論熟悉個幾個，似乎就難進入 AI 人工智慧相關系統的開發了。於是，幾乎現在所有著重在各領域的開發工程師，將自己從應用開發領域中重新拉回到核心基礎領域的研究。
我有點感觸，心理飄起一句 OS...「無疑是將涉足在人間行走的實踐者，重新要求閉關回到深山林內的修行者(實驗室)，這一閉關是否又是三年。」，唉了一 聲，時不我予也。
這歲月還真是一把殺豬刀，腦力也都退化到無法面對演算法與統計方法論時的無奈與現實。於是，AI 與我無緣，我與 AI 無緣，不如歸去吧。
李開復說...「AI 已過發明期，進入應用期，五年後全面普及」
創新工場董事長李開復在天下文化舉辦的一場演講提及:
「AI 電網，就是在雲端上用 cloud 架 AI，今天你用 google cloud、亞馬遜AWS、阿里雲，上面都有 AI 的功能，這意謂著使用 AI 的成本，正快速下降，這就是剛才我所舉例的，五個禮拜就可以訓練一批不懂 AI 的小朋友，做出成品。 這一一都告訴我們 AI 普及的日子應該很快就會到了，那到底會有多快呢？」。
《這論調讓我們這種應用工程師，又燃起一點點對 AI 實踐的夢想了 。》
現今企業猛然要求經理人員得去接受 AI 經理人班訓練，洗一洗觀念。並且 送出開發工程師進行 AI 受訓，重新學習一套新的程式語言與一堆演算法配合演 算法的 API 模組，進行建模訓練與測試。
但也相對地必須面對一個一個接踵而來的實際上 AI 系統的交付需求。
必須面對部門以往不敢貿然提出的決策與預測系統，直接跳Tone到AI需求的提列與開發。所以，老闆開始對工程師學習 AI 認知上是，只要受完 AI 基礎訓 練，就必須要能完成這樣的應用系統架構需求。
圖一 : AI 雲端服務架構
基於每一個 AI 模組一般只處理一件事，所以，相對地在建模與訓練過程中， 則不再開發時間考量內，但也是往往最花費時間與成本的一個環節。更甚者，我如何收集到訓練的資料或者圖片等資訊，來進行建模訓練。尤其牽涉到外在環境資料來源這一個部分。
如果建立一個 AI 開發團隊，對我們來說，是一種學習與建置過程中需要投 入更多時間與成本的，那麼，尋求AI網路服務(Web Service平台)是否是一個更能將產品快速上線的一個捷徑? 因此，我們是否可以將工程師再行分工。
《也許，我們需要借力使力，並且在分工的架構下，進行開發。整合出您的AI 產品。》
如果我們需要建構一個人臉辨識系統，一個月就要上線?
您可以使用 Google 機器學習的 AutoML 服務，亦可以使用 Amazon AI Service，不然還可以使用 Microsoft Cognitive Services(認知服務)，進行人臉辨識。
或者您可以使用 CHT IoT 智慧聯網 (中華電信智慧聯網平台) 提供的智慧服務進行您的人臉辨識系統開發。
借助雲端服務時，也許不需自己建模與訓練，也無須自己進行測試，只要您有應用系統開發介接API的能力，或者您具有開發Open API的能力。應該能夠幫企業建置一套因應各種前端人機介面的雲端服務，進行 AI 人臉辨識整合系統開發。
筆者提出一套簡易構思(實際上想偷懶快速完成工作)，我善且使用 CHT IoT智慧聯網平台的人臉辨識 AI 服務平台，延伸自己規劃的雲端界接服務架構，讓前端系統快速整合，進行人機介面的人臉辨識專案延伸與應用。架構圖如下:
圖二 使用 AI Web Service 與自訂 WEB Service 進行人機介面系統開發
AI Service 為專一服務而訓練而設計。但在介接前端應用系統的彈性與整合上，不會是完善的。甚至有些AI Service並不會整合您內部延伸的資料庫進行訓練資料來源。透過大廠或者自己訓練的AI Service環境，目的在縮短這些基礎演算與機器深度學習的時間，方便進行建模資料(訓練資料)的傳遞訓練與測試。其餘的就是身為應用工程師的責任了。應用工程師的責任就是:
《將實驗室的 AI 帶出來變成服務，並且開發單位介接 AI 服務與資料來源 Web Service，讓系統運行變成可行。》
自訂介接三方的服務架構，在實現多方人機介面的 AI 系統上變成更為重要。 如圖三，為筆者開發的 RESTful Service 定位(人臉辨識系統)。
圖三 人臉辨識系統中介服務撰寫架
至於程式碼，您可以使用 Java 或者 C#或者您熟悉的任何程式語言均可，因為採用 Open API 架構撰寫，非關程式語言的侷促性。如圖四，為筆者撰寫一個 REST Service 進行前端系統上傳相片資料，並解 送至雲端 AI 服務進行人臉辨識的原生碼。
圖四 介接前端系統與後端 AI Service 的 REST Service 開發
在註冊人臉相片時的註冊服務功能上，同時將相片文字資料儲存於資料庫中。因此在人臉辨識的服務過程中，另有一個通道必須整合到資料庫資源的存取作業。 讓經由 AI 人臉辨識回饋的 Label 整合到資料庫紀錄的查詢流程上。 如圖五，為服務程序中整合資料庫存取的部分程式碼。
圖五 人臉辨識回應的 Label 進行相對資料庫紀錄存取
實際範例展示，您可以點閱筆者放置在網路上的影片。
圖六 AI 人臉辨識前端介面整合服務展示
我想短時間透過 AI 演算法進行機器深度學習與實現服務與系統
有時，我們總得自己準備好訓練資料，並且透過一定客製化程式流程，配合 相關的演算法，訓練一個AI模組，並且快速轉換成WEB Service直接提供前端 人機介面服務。
也就是說，您需這樣的發展模式:
收集資料並且分析產生訓練資料與測試資料的DataSet
指定特定的演算法進行訓練與機器深度學習
完成模組之後，封裝成自訂的 Web Service
撰寫人機介面與資料庫與 AI Web Service 服務
前端人機介面系統開發
換句話說，如果您已經準備或者收集好訓練與測試資料，您需要短時間內完成實驗，建置服務與前端人機系統開發整合。這時候您即可借力使力，使用如Google AutoML 或者是Azure Machine Learning。可以透過視覺化工具，採用視覺化拖曳建立起您的機器學習，並且餵上訓練資料與測試資料，之後包裝成一個Web Service。
如圖七，所呈列的機器學習與建模流程，均可以在 Azure ML Studio 圖形化
工具直覺方式完成設計。
圖七 機器學習與建模流程
圖片來源:Free Machine learning diagram
筆者採用 Azure 提供的 AutoMobile 銷售資料，設計配合線性迴歸演算法，訓練汽車價格預測AI 服務。其中決定百分之 75 資料為訓練資料，百分之 25 為測試資料。
圖八 採用流程圖設計方式，進行機器學習訓練與建模 Workflow
訓練完成之後，接下來產生 Web Service 與進行發佈。這些過程都可直 接透過視覺化工具與操作過程中，一鍵完成。
如圖九，完成佈署的 Web Service。
圖九 布置完成的 AI Service 監控台
在應用上，筆者覺得需要再進行一個中介的REST Service架構，用來整合前端各類型系統界接的方便性。所以自行開發一個服務進行這一個 AI Service 的界接，同時整合更人性的資訊模組。
圖十 自訂 Web Service 界接人機介面與資料與 AI Service
完成中介服務設計之後，採用 Postman 工具進行單元測試，測試自訂服務整合佈署完成的 AI Service，進行汽車架構預估推測運行。
執行結果如圖 十一 所示一般。
因為Microsoft Azure ML在訓練時，產生的傳遞資料格式非常具有彈 性，所以大量使用Map集合方進行傳遞，因此即使佈署成Web Service之 後，仍無法因應我們在建模過程中，順利提供資料集架構對應敘述完整的JSON傳輸格式。因此，筆者認為這就是程式設計師加以發揮補強的空間。
圖十一 採用 Postman 測試自訂服務整合 AI Service 推測價格結果
如果您是應用工程師，您認為 AI 與你的關係如何?
在程式設計技術本位上，絕對是有應用工程師在 AI 領域上站上一個角 色與價值的，如果您也是一個資料庫管理師，那更是要發揮您的資料遷移商業服務技術，提供出事實資料(Fact Data)的價值，提供 AI 訓練中的資料來源(Data Model)。而這些訓練不外是針對資料事實來進行某些目標的訓練。
緊接著，您可以在初步了解相關的演算方法論目的之後，直接透過環境、服務，以及 API 等架構，完成您的機器學習訓練與建模。
最後可以在整合您已經完全熟悉的 Web Service 架構下，擴充整合資料庫或者資料資源的 AI 界接服務。透過您自行開發的服務讓 AI 整合在企 業資源與豐富的人機介面下，更能順暢地完成整合應用與系統的實現。
而這樣的整合開發工作，就非你莫屬了。帶出 AI 走出實驗，跨入服務佈署與系統整合的完整大道上。
Comments