從Watson看AI平臺的架構設計

摘要：本文分析IBM Watson在技術架構上所面臨的問題及解決辦法，總結了人工智能平臺在走向產品化需要面對的諸多挑戰。最後提出了以雲計算PaaS容器服務平臺爲基礎，上層使用SaaS的服務架構來搭建企業級AI平臺，是技術上可行也是較經濟的一種解決方案。

前言

2016年被認爲是人工智能的元年，隨着AlphaGo戰勝韓國棋手李世石，人工智能產業徹底站到了風口上。然而人工智能研發團隊的核心技術人員通常都是掌握了某些核心算法的科學家，他們對於平臺的架構設計，工程實施並不一定經驗豐富。 如何基於核心AI能力搭建出一套可持續運營又具有業務成長性的企業級AI平臺呢？ 筆者以IBM的 Watson爲案例，來分析架構設計上需要考慮的方方面面。

Watson解決那些問題？

IBM的Watson在2011年在美國危險邊緣（Jeopardy）真人秀中以77147分的成績戰勝兩位人類選手贏得100萬美金頭獎而一舉成名。在這個故事背後，IBM解決了那些人工智能領域的問題呢？我們先來看看 Jeopardy這個節目的競賽規則。作爲美式智力問答節目，Jeopardy的題目由若干詞條或短句組成，讓競賽者找出這些線索所描述的人或事物，答案需要以提問的形式提供給主持人。 例如題目問“在撲克牌遊戲中，五張同一花色順聯的牌” 。 選手的正確回答是“什麼叫同花順”？這就要求參賽選手要有知識的廣度和搶答的反應速度，並且還需要有腦筋急轉彎的聯想歸納能力。Watson能在不聯網的情況下，處在人類日常的環境當中，去理解、搶答、贏得比賽，主要在人工智能3個領域取得突破：

1. 理解自然語言的能力。雖然在比賽中Watson爲了提高理解的精確度關閉了語音翻譯功能，使用文本作爲輸入方式（遊戲規則允許選手閱讀顯示屏上的問題，所以並不算Watson違規），但它仍然需要準確的解讀人類措辭含糊的提問。
2. 非結構化數據的處理和機器學習能力。接下來Watson要從百科全書般浩繁的文檔中學習儲備知識。
3. 快速運算。在比賽中從知識庫中找到備選項, 通過複雜的判斷邏輯從備選項中選擇正確度最高的答案。要達到超過人腦的推理運算速度，快速準確的用人類語音給出最終答案。

Watson是如何運行的？

從賽後Watson研發團隊DeepQA在人工智能領域頂級刊物AI Magazine上的公佈論文《Building Watson: An Overview of the DeepQA Project》 (參考1)和維基百科(參考2 ) 上的內容， Watson問題分析的工作流程如圖1:

圖1

因爲國內已有介紹DeepQA這篇論文的文章（參考3），筆者就不詳細展開。從上圖看Watson的技術架構可以歸納如下（圖2）：

圖2

• 問題生成模塊：系統嘗試瞭解問題是什麼，並執行初步分析，以確定問題將如何由系統的其餘部分處理。首先分析問題，對問題的類型，回答方式等進行分類，再把問題分解成一系列假設可能的子問題。
• 答案生成引擎： 對於輸入的假設，在答案源進行搜索、過濾掉評分過低的備選答案、根據備選答案搜索證據、最終把備選答案和證據合併彙總到統一的數據模型中。可以說這是Watson最具挑戰的部分，因爲：
  
  • 第一，答案的準確度必須很高，單一分析算法很難達到要求。DeepQA團隊通過漫長的實驗和摸索最終選擇了上百種算法從不同的維度分析備選答案，如類型、時間、空間、流行度、來源可靠度、語義相關度等。每種分析都產生一些特徵和評分，如何融合不同維度的分析結果並給出評分是一個巨大的挑戰。
  • 第二，計算答案的時間很短。人類選手幾秒就能思考出答案並做出搶答動作。而Watson要執行多步計算：把問題分解成N個假設、每個假設又會去查詢N多可能的證據、對N*N的查詢結果進行合併、最後分析出答案。DeepQA團隊承認最初Watson單機計算一個回答需要2個小時。

爲了應對挑戰，DeepQA團隊設計了非結構化信息應用程序框架（Unstructured Information Management applications 縮寫 UIMA）。UIMA 對於非結構化文本分析定義了一套記錄分析結果的通用分析數據結構Common Analysis Structure(CAS)，使不同的算法可以共享對文本的分析結果。 另外，爲了縮短Watson思考的時間，DeepQA團隊設計了UIMA的異步擴展框架（UIMA-AS）用於將分析過程橫向擴展到多臺電腦異步並行處理。UIMA-AS使用JMS（Java Messaging Services）和ActiveMQ處理異步消息傳遞，使答案生成引擎可以方便地部署到多臺服務器上並行處理並彙總分析結果。Watson在參加比賽時，基於UIMA-AS把90臺IBMPower750服務器連接在一起，把思考時間縮短到3-5秒。可以說Watson主要創新並不在於創建某種新的算法，而是通過UIMA能夠同時快速執行數百種成熟的語言分析算法，目前UIMA已經開源給Apache軟件基金會，併成爲它的頂級項目。

• 答案決策模塊。將對備選答案生成的成千上萬的成績保存在CAS數據結構中，彙總得到最終成績和自信度。DeepQA團隊使用Jeopardy以往比賽的題庫和模擬題庫訓練出一系列的中間模型，統計出不同成績和自信度的答案在題庫中的正確率。 Watson使用中間模型統計出的正確率，篩選出最有可能的備選答案。
• 遊戲策略模塊。依據Jeopardy遊戲的規則，結合場上各個選手的比分，問題的難易度來爲Watson制定最優的搶答策略。DeepQA團隊通過歷史比賽和模擬比賽的數據，針對不同的問題和場景，訓練出一系列的中間模型，統計出在某種情況下采取何種策略最有利。
• 學習&訓練模塊。DeepQA的工程師將近20T的各類文檔，來源包括百科全書，詞典，敘詞表，新聞文章和文學作品等，存儲在Hadoop的HDFS中。利用Hadoop的MapReduce引擎並行分析這些非結構化、半結構化和結構化的文檔，分析結果以UIMA的數據結構存儲在數據庫中作爲答案庫和證據庫供Watson比賽時查詢和檢索。

Watson平臺化的技術挑戰在哪兒？

藉助Watson在智能問答領域的成功，IBM努力把它作爲一個人工智能品牌推向商用。例如安裝在汽上，回答駕駛員有關維修的問題，以及如何提供路況信息和發出安全警示。當汽車故障出現時，Watson可以告訴駕駛員什麼地方出了問題， 是否需要預約去4S點修理。

然而訓練Watson贏得比賽是一回事，選擇怎樣的技術架構把Watson打造成能支持同時服務數以萬計用戶的AI平臺，就是另一個問題。 以前述的汽車助手爲例， 要構建一個企業級的AI交互問答平臺， 就不得不考慮如下實際問題：

1. 多租戶帶來的資源隔離。 對於企業用戶而言，爲了數據的安全性和平臺的穩定性均要求對其數據，資源進行隔離不和其它使用者混用。
2. 企業的需求不一，並且使用的服務不同，如何滿足其定製化。
3. 由於是新應用，企業客戶更希望AI平臺的計算能力能隨着業務量的增長動態提升，讓花的每一分錢都用到實處。
4. 海量的數據存儲需求。 大量人機對話產生的語音數據， 需要有廉價安全的存儲方式來保存。

什麼樣的技術架構能解決這些問題？

筆者認爲用基於PaaS的容器服務(Container As a Service 縮寫 CaaS) + SaaS的架構能很好地解決上述問題。容器服務（CaaS）是一種基於容器的虛擬化形式，其中容器引擎，編排和底層計算資源作爲雲服務提供給用戶。容器服務平臺技術近兩年已經發展得比較成熟，目前比較流行的實現方式是以Docker爲容器化技術，Kubernetes爲容器化的應用提供資源調度、部署運行、服務發現、擴容縮容等整一套功能。利用容器服務平臺封裝、隔離和部署靈活的特性，能很好的解決上述多租戶帶來的問題。結合雲計算SaaS層的租戶管理， API管理，計費管理等應用層能力，能很好的解決企業二次開發定製化的需求。PaaS平臺對於DevOps的無縫支持以及基礎資源（雲存儲、消息隊列、RDS以及鏡像），也使問題3和4的解決變得非常容易。完整的企業級AI平臺技術架構如下（圖3）：

圖3

1. SaaS應用平臺作爲和用戶的交互界面，負責將AI平臺的能力和用戶對接。根據AI平臺的業務特點，自研發用戶管理，計費管理，以及對用戶資源的管理模塊，研發基於OAUTH, RESTful的 OpenAPI平臺。
2. SaaS平臺還要對AI平臺的研發和日常監控進行支撐。 搭建AI平臺的運營監控和代碼管理系統。
3. PaaS提供平臺基礎資源。提供RDS，既存放AI平臺共享的知識庫和訓練模型，也存放租戶自定義的數據內容；提供雲存儲，放置各類結構化和非結構化的文檔資源，人機對話產生的巨大存儲需求也有很好的解決方案；提供消息隊列，用於支撐類似於UIMA-AS橫向擴容時並行計算的消息傳遞；提供鏡像管理（包含虛機的基礎鏡像管理和容器服務的容器鏡像管理），用於存儲各AI子系統模塊最新的Docker鏡像。
4. PaaS自身支持DevOps。負責平臺的代碼和軟件更新， 通過DevOps推送到PaaS平臺的鏡像倉庫中，交由容器服務平臺自動進行升級和回滾。
5. 基於PaaS的容器服務平臺，在部署編排模塊的管理下，從PaaS的鏡像中獲取相關容器鏡像，爲每個租戶部署一套完整的AI生產環境。容器調度模塊結合PaaS平臺的基礎監控，根據租戶的資源運行情況，對運行實例進行動態調整。配置管理模塊統一管理各租戶內部子系統的配置。網絡管理用於協調租戶內部和外部雲平臺之間的網絡路由和流量分配。
6. 學習和訓練環境也部署在容器服務平臺。 因爲AI的訓練和學習時間不固定，沒有必要佔用大量資源。在需要時申請，完成計算後釋放，能有效得節省計算資源的使用。
7. 對於每個租戶，通過容器服務平臺創建完整的Watson系統。容器化的問題生成，答案生成引擎，和答案決策模塊可在容器服務平臺裏動態伸縮，達到資源的合理利用。

總結

隨着以Docker和Kubernetes爲代表的容器服務技術日益走向成熟，企業利用PaaS容器化平臺+SaaS的架構搭建自己的業務平臺已經進入了實踐階段， 國內已經涌現出了一些用私有云的容器服務平臺搭建自身業務平臺的成功案例（參考4）。目前公有云服務商Azure、AWS、Google和阿里雲等都紛紛基於自己的PaaS平臺推出了類似CaaS的產品。 這種架構設計利用雲平臺動態伸縮的優勢降低AI平臺的初始資源投入，同時保證平臺後續沒有資源方面的瓶頸，是一種可行的AI平臺架構設計解決方案。另一方面，我們也應看到該方案的侷限性，對於需要實時使用大量硬件資源（如GPU）的AI應用場景，容器服務化並不能解決全部問題。

參考資料：

1. 《Building Watson: An Overview of the DeepQA Project》, 作者DeepQA， https://www.aaai.org/Magazine/Watson/watson.php
2. 《Wiki百科 Watson (computer)》 詞條, 作者 wiki百科， https://en.wikipedia.org/wiki/Watson_(computer)
3. 《Watson的獨特“思考”》， 作者 Baiyuzhong，《程序員》雜誌2012年9期, http://history.programmer.com.cn/13468/
4. 《基於容器技術的平臺化SaaS軟件設計與實踐》，作者 周悅秋，CNUTCon 2016，http://www.infoq.com/cn/presentations/saas-platform-software-based-on-container-technology

作者介紹：李禕，曾擔任惠普雲部門（Cloud BU）解決方案架構師，卓望信息技術公司負責移動旗下網站www.139.com 、shop.10086.cn、pim.10086.cn系統架構，源訊（Atos Origin）開源軟件專家全程參與2008奧運IT集成項目。現就職於奧博傑天技術有限公司擔任解決方案架構師，公司卓越技術委員會（TEC）成員。關注PaaS應用，雲遷移等雲計算領域的新技術和新產品應用。