2016年被認為是人工智能的元年，隨著AlphaGo戰(zhàn)勝韓國棋手李世石，人工智能產(chǎn)業(yè)徹底站到了風口上。然而人工智能研發(fā)團隊的核心技術人員通常都是掌握了某些核心算法的科學家，他們對于平臺的架構設計，工程實施并不一定經(jīng)驗豐富。 如何基于核心AI能力搭建出一套可持續(xù)運營又具有業(yè)務成長性的企業(yè)級AI平臺呢？ 筆者以IBM的 Watson為案例，來分析架構設計上需要考慮的方方面面。
IBM的Watson在2011年在美國危險邊緣（Jeopardy）真人秀中以77147分的成績戰(zhàn)勝兩位人類選手贏得100萬美金頭獎而一舉成名。在這個故事背后，IBM解決了那些人工智能領域的問題呢？我們先來看看 Jeopardy這個節(jié)目的競賽規(guī)則。作為美式智力問答節(jié)目，Jeopardy的題目由若干詞條或短句組成，讓競賽者找出這些線索所描述的人或事物，答案需要以提問的形式提供給主持人。 例如題目問“在撲克牌游戲中，五張同一花色順聯(lián)的牌” 。 選手的正確回答是“什么叫同花順”？這就要求參賽選手要有知識的廣度和搶答的反應速度，并且還需要有腦筋急轉彎的聯(lián)想歸納能力。Watson能在不聯(lián)網(wǎng)的情況下，處在人類日常的環(huán)境當中，去理解、搶答、贏得比賽，主要在人工智能3個領域取得突破：
從賽后Watson研發(fā)團隊DeepQA在人工智能領域頂級刊物AI Magazine上的公布論文《Building Watson: An Overview of the DeepQA Project》 (參考1)和維基百科(參考2 ) 上的內(nèi)容， Watson問題分析的工作流程如圖1:
因為國內(nèi)已有介紹DeepQA這篇論文的文章（參考3），筆者就不詳細展開。從上圖看Watson的技術架構可以歸納如下（圖2）：
為了應對挑戰(zhàn)，DeepQA團隊設計了非結構化信息應用程序框架（Unstructured Information Management applications 縮寫 UIMA）。UIMA 對于非結構化文本分析定義了一套記錄分析結果的通用分析數(shù)據(jù)結構Common Analysis Structure(CAS)，使不同的算法可以共享對文本的分析結果。 另外，為了縮短Watson思考的時間，DeepQA團隊設計了UIMA的異步擴展框架（UIMA-AS）用于將分析過程橫向擴展到多臺電腦異步并行處理。UIMA-AS使用JMS（Java Messaging Services）和ActiveMQ處理異步消息傳遞，使答案生成引擎可以方便地部署到多臺服務器上并行處理并匯總分析結果。Watson在參加比賽時，基于UIMA-AS把90臺IBMPower750服務器連接在一起，把思考時間縮短到3-5秒。可以說Watson主要創(chuàng)新并不在于創(chuàng)建某種新的算法，而是通過UIMA能夠同時快速執(zhí)行數(shù)百種成熟的語言分析算法，目前UIMA已經(jīng)開源給Apache軟件基金會，并成為它的頂級項目。
借助Watson在智能問答領域的成功，IBM努力把它作為一個人工智能品牌推向商用。例如安裝在汽上，回答駕駛員有關維修的問題，以及如何提供路況信息和發(fā)出安全警示。當汽車故障出現(xiàn)時，Watson可以告訴駕駛員什么地方出了問題， 是否需要預約去4S點修理。
然而訓練Watson贏得比賽是一回事，選擇怎樣的技術架構把Watson打造成能支持同時服務數(shù)以萬計用戶的AI平臺，就是另一個問題。 以前述的汽車助手為例， 要構建一個企業(yè)級的AI交互問答平臺， 就不得不考慮如下實際問題：
筆者認為用基于PaaS的容器服務(Container As a Service 縮寫 CaaS) + SaaS的架構能很好地解決上述問題。容器服務（CaaS）是一種基于容器的虛擬化形式，其中容器引擎，編排和底層計算資源作為云服務提供給用戶。容器服務平臺技術近兩年已經(jīng)發(fā)展得比較成熟，目前比較流行的實現(xiàn)方式是以Docker為容器化技術，Kubernetes為容器化的應用提供資源調度、部署運行、服務發(fā)現(xiàn)、擴容縮容等整一套功能。利用容器服務平臺封裝、隔離和部署靈活的特性，能很好的解決上述多租戶帶來的問題。結合云計算SaaS層的租戶管理， API管理，計費管理等應用層能力，能很好的解決企業(yè)二次開發(fā)定制化的需求。PaaS平臺對于DevOps的無縫支持以及基礎資源（云存儲、消息隊列、RDS以及鏡像），也使問題3和4的解決變得非常容易。完整的企業(yè)級AI平臺技術架構如下（圖3）：
隨著以Docker和Kubernetes為代表的容器服務技術日益走向成熟，企業(yè)利用PaaS容器化平臺+SaaS的架構搭建自己的業(yè)務平臺已經(jīng)進入了實踐階段， 國內(nèi)已經(jīng)涌現(xiàn)出了一些用私有云的容器服務平臺搭建自身業(yè)務平臺的成功案例。目前公有云服務商Azure、AWS、Google和阿里云等都紛紛基于自己的PaaS平臺推出了類似CaaS的產(chǎn)品。 這種架構設計利用云平臺動態(tài)伸縮的優(yōu)勢降低AI平臺的初始資源投入，同時保證平臺后續(xù)沒有資源方面的瓶頸，是一種可行的AI平臺架構設計解決方案。另一方面，我們也應看到該方案的局限性，對于需要實時使用大量硬件資源（如GPU）的AI應用場景，容器服務化并不能解決全部問題。
本站文章版權歸原作者及原出處所有 。內(nèi)容為作者個人觀點， 并不代表本站贊同其觀點和對其真實性負責，本站只提供參考并不構成任何投資及應用建議。本站是一個個人學習交流的平臺，網(wǎng)站上部分文章為轉載，并不用于任何商業(yè)目的，我們已經(jīng)盡可能的對作者和來源進行了通告，但是能力有限或疏忽，造成漏登，請及時聯(lián)系我們，我們將根據(jù)著作權人的要求，立即更正或者刪除有關內(nèi)容。本站擁有對此聲明的最終解釋權。
