[[192443]]

因為 AlphaGo 的出現，過去的 2016 年可謂是人工智能元年。記得當時我們正在蘇州封閉研發The Platform，工作之余討論到人機對戰的真正意義，并不在于技術上的突破，而在于對人們固有知識的影響，人工智能的應用會如雨后春筍般誕生，以后沒有人工智能的軟件以后你都不好意思開口了。大家都在問，自己的工作與人工智能有什么關系，如何在自己的工作中應用人工智能，如何在軟件中植入人工智能的基因，使用人工智能應該從何處入手，學習人工智能應該從哪里開始，更深層次的問題是人工智能能否代替人類，作為一個程序員，人工智能是否會代替人類寫程序···這里根據我們團隊的實踐介紹一下如何在軟件中應用人工智能。

人工智能(AI)的目標是增強智能(IA)，而不是替代人類

人工智能并不是一個新概念，40年代維納的《控制論——關于在動物和機器中控制和通訊的科學》就是人工智能。但早年的人工智能受限于計算能力，更多在解決模型的計算速度和精度上存在著諸多問題。近年來隨著云計算技術的發展，計算機的計算能力提高了，同時隨著大數據的發展，更復雜的計算問題可以用更多的數據進行修正，人工智能的可用性大大提高。但是我們從目前人工智能應用的情況可以看到，人工智能并不能替代人類，例如在圖像識別、語音識別等方面的突破，僅僅是讓機器更加聰明而已，還遠遠沒有達到人類的程度，作為人類的智能助手更加合適。

理清人工智能、機器學習、深度學習、統計等基本概念之間的關系

把人工智能的方法應用到軟件中，我們先梳理清楚幾個概念之間的關系：

人工智能(Artificial Intelligence)是一個大的概念，是讓機器像人一樣思考甚至超越人類;

機器學習(Mechine Learning)是實現人工智能的一種方法，機器學習最基本的做法，是使用算法來解析數據、從中學習，然后對真實世界中的事件做出決策和預測;

深度學習(Deep learning)又是機器學習的一種實現方式，他是模擬人神經網絡的方式，用更多的層數，更多的神經元，然后給系統輸入海量的數據，來訓練網絡;

統計學是機器學習和神經網絡的一種基礎知識，從傳統分工來看，統計學一般是數學、統計等專業研究的方向，而機器學習是計算機科學的研究方向，但是目前大家的研究成果越來越殊途同歸，有統計學的大師就認為統計實際上一直在從事機器學習的工作。

對于深度學習、統計的專家來說，他們更加關注于模型、算法等等，找到可以普適性解決問題的辦法。而對于我們應用來說，具體的算法實現不需要我們考慮太多，而是找到適合的場景、合適的模型、匹配的算法，所以應用人工智能實際上是一個計算機、統計、知識工程、行業知識的一個交叉應用。在經常涉及到的應用中，我一般在處理結構化、半結構化數據時優先考慮傳統統計學的方法，例如分類、數據相關性、回歸等，而處理非結構化數據時(例如圖像、視頻、文本)優先考慮深度學習的方法，但這些方法也需要有統計學知識。所以，需要補課：線性代數、數理統計、Python，我覺得《機器學習實戰》這書入門不錯，上述幾方面知識都介紹了。

應用人工智能實現增強智能的三個層面

應用人工智能的時候，人們會有一個誤區，總是希望得到一個意想不到的結果，也就是希望探索出新知識。經常有人問我，得到的結果好像沒有什么我不知道的，我說這就對了，因為你是專家，要是計算機得到的結果都是不可知的，你怎么能相信他?例如AlphaGo下的棋，絕大多數都是人類已知的，非常少非常少的情況下，下出一招另類，這已經是一個頂天星的水平了。很多人失望了，這還有啥意思，其實意義很大：

(1)計算機可以讓常人快速獲得以往專家才能具備的知識

例如有經驗的客戶經理，肯定非常了解客戶的情況，誰是優質客戶，誰需要什么產品等等，不需要計算機。但是通過用戶畫像等人工智能的手段，計算機可以讓經驗不夠豐富的人，也具備了上述經驗，這個做法價值就非常高，畢竟專家是少的;

(2)幫助專家減少重復性的工作

例如醫生在做病理檢測時，絕大多數沒有生病的情況和有典型病理特征的情況，機器都可以提醒醫生，節約醫生的寶貴時間。如此看來，我們就會理解，人工智能不是替代人，而是給人類增加一個智能的助手，是增強智能(IA Intelligence Augmentation)。

計算機作為一個智能助手，可以在不同層面和手段幫助我們，我把他分為機械智能、實現意圖的智能和創造意圖的智能三個方面：

(1)機械智能

我們目前從事的主要工作都是這個，事先設定規則(代碼也是規則)，讓計算機完成大量重復計算，充分利用計算機的計算能力，替代人的手工勞動，這是一個以規則為核心的模式，而這些規則來自于人現有的知識;

(2)實現意圖智能

人知道最終結果是什么，但是并不告訴計算機采用什么樣的規則計算，通過大量數據訓練計算機找到規則，然后再讓計算機完成大量重復計算，計算機究竟找到的規則是什么，有可能人并不一定能理解，其實往往也不需要理解，把計算機當成了黑盒;

(3)創造意圖智能

也就是讓計算機自己找到人并不知道的新知識，這也是我們最向往的場景。

從具體的實現層面看，第一種情況無疑是最多的，我們需要提煉總結規則，用好第一種情況很重要;第二種情況以前相對少一些，但恰恰是目前需要改進的，在第二種情況下我們往往優先用統計學的方法處理結構化、半結構化數據(例如格式化日志)，用深度學習的方法處理非結構化數據，這就需要讓我們的團隊具備人工智能的思維。

實踐人工智能應用需要新思維，不能再用規則理解計算機實現智能的方式

實踐人工智能，需要在在思維上進行調整。我們往往習慣于用制定規則的方式指揮計算機，輸入計算規則和輸出結果都是已知的，也就是我上面說的機械智能方式。但后兩種模式就不是規則方式了，因為規則是計算機找到的，這也就是經常說的數據訓練。

這里我舉一個我們自己實現的例子，讓大家理解一下什么是模型、算法和數據訓練。

先說一個背景，我們在梳理現有企業數據架構的時候，需要建立數據間的關聯，用人進行梳理費工費力，我們就打算用計算機自動完成一部分，然后人工修正，這就是一個增強智能(IA)的例子。這里面就有一個情況，如果數據庫中沒有建立外鍵，如何把這種實際的外鍵關系找出來，我們就用這個例子解釋一下機械智能和實現意圖智能的方法：

(1)用規則的方式查找外鍵關系

首先要定義規則，外鍵關聯的規則包括字段類型一致、長度一致、包含相同數據等等，然后在所有數據中遍歷，進行匹配。這種方式需要有完整的數據，而且是否為外鍵關系的判斷規則往往有些模糊，在沒有得到全量數據時有一定局限性;

(2)用統計學方法查找外鍵關系

首先，我們定義出字段的特征(類似用戶畫像)，字段特征是一個向量，就是一個一維數組，包括表名、字段名、字段類型、注釋、樣例數據最大長度、樣例數據最小長度等等，由于表名、字段名不是數值，我們要把他們變成數值，可以和同一個標準字符串作比較，也就是通過移位的方式把字符串移動成標準字符串，移動次數越少，相似度就越高，這樣就得到了一個真正的一維數組(向量)了。

其次，我們拿出一部分已知關系的表和字段，作為訓練樣本，逐一計算兩個字段之間的相關系數(相關系數的計算方法是現成的，我這里就不介紹了，一上公式我就暈，Python的發行版Anaconda里面就有，用了這個就體會到 Python 是最好的語言了)，相關系數高的說明特征類似，認定為外鍵關系。這時候人工判斷一下，如果結果不錯，那這個模型就是正確的，如果結果不好就換一種相關系數計算方法，或者改變數據特征，或者對數據特征進行加工，總之，外鍵特征作為一個客觀存在，一定能夠找到符合的特征，這就是數據訓練。通過數據訓練，找到合適的字段特征(模型)和計算方法(算法)，也可以交給計算機做處理了，把所有的外鍵找出來。

你看，這里沒有定義規則，處理方法是通過數據訓練的方式，讓計算機自己找出來的，我不需要知道相關系數這玩意到底是什么意思，這就是上面說的，計算機是一個黑盒。

需要說明的事，在上述例子中，我簡化了不少動作，實際上最開始還找出來很多不是外鍵關系的字段，例如 createTime，我們還要把這種噪音字段的特征訓練出來，剔除噪音。

這個示例說明了應用人工智能時不同的兩種思維模式，簡單的說不能再用創造規則的方式指揮計算機，而是訓練計算機自己找出規律。

上面我們分析了人工智能相應的基本概念，人工智能的幾種模式以及應用人工智能時需要的思維突破，下面我們從軟件架構發展和面臨的挑戰，看看應用人工智能時的切入點在哪里，哪里更容易爆發出人工智能的火花。

應對軟件架構分而治之帶來集成的挑戰，探索智能的連接

什么是軟件架構，在InfoQ出版的《聊聊架構》中講的很清楚(感謝老王，總結非常到位)，軟件架構就是

(1)根據問題確定系統邊界;

(2)按一定原則進行切分;

(3)建立不同模塊間的溝通機制;

(4)整體性交付軟件功能。

可見，架構的關鍵是分而治之的哲學，但切分是為了軟件研發、運維方便，軟件的目標是整體交付，分與合存在這矛盾，這一矛盾是由集成解決的，但是集成往往是復雜的，大家在架構方面的分享，也以如何切分居多，如何集成相對較少。

集成工作的復雜度影響了復雜度系統的研發

Unix的實踐無疑對軟件架構有著巨大的影響，做一個事情，做到最好，一直是 Unix 風格所倡導的，但“在理想世界中，Unix程序員只愿意手工打造小巧完美的軟件寶石，每個都那么小巧、那么優雅、那么完美。然而顯示中很不幸的是，太多復雜問題需要復雜的解決方案。僅僅十行的程序，再優雅也無法控制噴氣式客機。那兒有太多的裝備、太多的通路和界面，太多不同的處理機，太多不同操作人員定義的子系統，他們甚至連基本的約定都無法統一。即使能夠成功地將航空系統所有的個體軟件部分做的優雅，但拼裝結果很可能是一堆龐大、復雜、糟糕的代碼···噴氣客機的復雜是必然的。

過去有個尖銳的觀點，不能為簡單性而犧牲功能，因為飛機必須要能飛。正是這個事實，航空控制系統并不會產生關于復雜度的圣戰—-Unix程序員往往敬而遠之(摘自《Unix編程藝術》)。

不幸的是，我們面臨的往往是復雜性的系統，片面理解Unix風格分而治之往往帶來更大的集成難度。為了降低集成的難度，我們往往采用巨石型的系統架構，用一個大一統的方式設計系統，僅僅在系統內部進行模塊的拆分，用codebase和規范進行約束，走上了和Unix風格背道而馳的道路。當性能和可維護性壓力到來后，這樣的系統又不得不進行拆分：我過去常常看到，當軟件系統達到 100 萬行代碼規模時，人們會覺得維護困難，產生了強烈的拆分念頭;當達到 300 萬行代碼規模時，人們往往再也按耐不住拆分的欲望;當達到 500 萬行代碼規模時，再保守的組織也會作出拆分的決定。

軟件架構中復雜的集成工作需要利用人工智能方式簡化下來

回顧一下解決集成問題的歷史，我們會發現較早的集成架構模式來自于 Unix，就是眾說周知的管道(Pipe)模式。Pipe模式將數據傳遞到一個任務序列中，管道扮演者流水線的角色，數據在這里被處理然后傳遞到下一個步驟。

管道模式作為一種最基本的方式，理論上可以解決所有集成問題，但涉及到具體問題時，就需要針對不同情況做應對，針對各種復雜的情況，可以總結出更多的模式，《企業集成模式》(EIP)一書中圍繞消息集成，總結出若干集成模式，可謂是消息集成的集大成式總結。但EIP的集成模式主要針對系統間后臺服務的集成，SOA架構提出了以Portal(前端集成)、BPM(流程集成)、ESB(服務集成)、DI(數據集成)以及事件/消息集成的多層面集成體系，更加系統性的為集成工作提供指導。SOA的集成方式需要一系列的集成基礎設施支持，屬于一種中心化的集成方式，我們可以稱之為MiddleBox的方式，在微服務架構提出后，我們會采用把集成邏輯與業務功能部署在一起的去中心化集成方式，可以稱之為MiddlePipe的模式。

集成方式一路演進下來，主要是集成的手段上不斷翻新，多種框架和基礎設施越來越多的解決了非功能需求，例如 ESB 可以解決路由、安全、流控等問題，一定程度上減少了集成的工作量。但集成的業務復雜度還存在很多，這里我列舉幾個常見的問題：

(1)數據的查找問題

針對業務需求，需要使用已存在的數據和服務，但在企業環境中，系統、服務、數據眾多(想象一下具有10多萬服務、10多萬數據標準的情況)，想找到試用的服務和數據，不是一件容易的事情，一般我們都要依賴專家在這方面的知識，通過總體設計指定了數據的流向，這依賴于專家的能力，專家的能力也是慢慢積累起來的。我們需要幫助業務更快速的找到數據和服務，幫助專家快速實現積累，減少重復勞動。

(2)數據的適配問題

通過服務方式進行集成，原子服務往往需要大量的輸入參數。舉個例子，調用一個發短信的接口，不僅僅是收信人電話號碼和短信內容，還要包括很多業務含義的參數，例如發信人的姓名、組織、發信的系統、發信的原因、發信時和客戶接觸的渠道(客服渠道、網點渠道、網銀渠道、自助終端等等)、發信時關聯的產品，這些信息是可以用來計算成本、控制次數、避免重復騷擾客戶;用戶名、密碼、驗證碼、發送時間等這是用作安全驗證的;優先級、發送渠道等是用來做流量控制的;流水號、全局業務ID、請求ID、請求時間等等是用來做監控的。上述信息來自與每次發短信的上下文，在實際開發期間就要做很多的賦值、轉換工作，將上下文的信息傳遞給服務，這種轉換就像下圖那樣，典型的面多了加水，水多了加面。我們需要根據當前上下文和服務的特征，自動的進行一些適配，避免人工的重復性勞動。

[[192444]] 

(3)系統的聯動問題

當一個業務事件產生時，有很多相關聯的系統都會需要作出關聯性反映，例如一個航班延誤，就會涉及機票的改簽、酒店的改期、接車服務的改期、會議安排的變更、日程計劃的變更。一般我們會設計一個事件中心，為各個系統開發出監聽的程序，當事件到來時判斷上下文信息，決定產生的動作。如果事先沒有設定的規則，就無法產生聯動，我們期待更加自動化的建立這種聯動關系，讓計算機智能的產生動作而不僅僅通過人為設置。

類似問題還有很多，我們期待能夠更加智能的集成。

需要集成的部分不只是軟件本身，軟件過程也是一個復雜的集成/協作工作

分而治之的軟件需要通過集成方式整體交付，軟件的生產過程也是一個多人、多組織協作的過程，也需要集成。把軟件看成是一個產品，產品就有策劃、研發、運營和退出各個階段，每個階段可能由不同的人或組織完成。軟件的研發階段就是一個一個項目的實施過程，包括立項、執行和完工。這樣的過程組織起來，就是一條軟件生產的流水線。從早期瀑布式的軟件研發，到后來敏捷研發過程、CMM，到目前風頭正勁的DevOps，都是在解決軟件生產流水線不同階段的協作問題，敏捷針對軟件定義、設計、構建(開發)階段的協作，持續集成是構建(開發)與測試階段的協作，持續交付是從定義階段到部署(交付)階段的協作。

協作中面臨的問題，就是集成的問題，我們可以想到很多，這里也舉幾個例子：

(1)需求、設計與構建(開發)的溝通問題：我們需要把需求/設計的知識圖譜化、條目化，自動與開發工作做一定程度的適配，減少需求/設計到代碼的轉換工作;

(2)構建(開發)與測試的溝通問題：我們需要根據服務和數據特性以及積累的歷史數據，自動產生測試用例和測試方法;

(3)運營的溝通問題：我們需要通過應用畫像、資源畫像等方式，服務與物理資源之間建立連接，快速定位問題，進行容量預測，實現更智能的運維。

在軟件架構中應用人工智能的目標：通過增強智能方式實現軟件系統與軟件工程的智能連接

應對復雜集成的挑戰，我們可以引入人工智能的思路，將人與軟件之間、物體與軟件之間、軟件與軟件之間、軟件生產線各環節之間通過知識使能的方式集成起來，在傳統完全依賴規則進行集成的方式基礎上，采用新的集成方法：以上下文信息為輸入，利用專家已有的知識，通過數據訓練和強化學習的方式，讓計算機能夠理解集成的意圖，成為我們的智能助手，幫助我們實現智能的連接，進而可以讓計算機探索新的連接知識。這里，我把連接也分為三個層面：機械連接、基于知識連接、創造知識連接。

從智能連接入手探索在軟件架構中應用人工智能

從何處入手，探索人工智能在軟件中的應用，是大家最關注的話題，這里我把普元在探索人工智能初期經歷的幾個案例，給大家做一個介紹。普元董事長劉亞東博士早年就從事神經網絡的研究，他指出在目前并行計算等技術充分發展的今天，算法已經不是人工智能的瓶頸，應用人工智能需要有兩個突破：

(1)找到人工智能應用的切入點

(2)團隊具備人工智能應用的思維

所以我們在應用人工智能的時候，不是成立一個專門的小組做研究，而是百花齊放的方式。了解普元的朋友會知道，普元的研發分為云計算&SOA、大數據、移動、工程效率與技術平臺、產品支持中心幾個團隊，我們讓每個團隊從數據+連接方向上入手，各自探索人工智能在領域上的應用場景，通過找到切入點和初步實踐，逐步建立團隊的人工智能思維。其中云計算&SOA團隊的方向是通過服務畫像方式解決微服務的智能運維與智能匹配，大數據團隊的方向是通過知識圖譜實現數據自服務，移動團隊的方向是UI的智能化開發，工程效率與技術平臺團隊的方向是深度學習在流程與智能制造的應用。由于篇幅有限，這里我只把普元大數據團隊和移動團隊所做的工作做一個介紹。

案例一：基于知識圖譜，實現數據的自服務能力

先簡單介紹一下背景：大家經常會聽到有人問我們有哪些數據，這些數據在哪里，如何獲取數據的問題，能否建立一個平臺，讓我們象百度搜索一樣，根據我們的知識(業務術語)找到相關的數據，提交申請，得到數據，這就是一個獲取數據的自助服務。

以往數據在哪里往往通過人工梳理完成，我們希望能夠自動化一些，為專家提供一個智能的助手，這里的工作分為三部分：

(1)建立知識圖譜

人進行數據搜索是通過業務術語(知識)來搜索的，而知識之間是有相互聯系的，例如水果和西紅柿是上下位關系(后者是前者的具體體現)，搜索是除了要列出直接結果，還需要顯示一些關聯的知識，這就要建立知識圖譜。簡單說知識圖譜就是概念、屬性以及概念之間的關聯關系， 這個關系可以手工建立，我們通過對政策、法規、需求、數據庫comments、界面等多種來源，采用自然語言處理等方法，可以建立起部分的知識圖譜，輔助專家的工作;

(2)梳理技術元數據

整理各個系統內部數據，以及數據之間的關系，形成數據地圖。這里的難度是數據之間的關系，例如數據的血緣關系、影響度關系、關聯關系、主數據關系等，這里我們采用字段特征的相關性、數據處理邏輯的詞法/語法分析等手段，配合強化學習來完成，前面列舉的查找外鍵示例，就是一部分;

(3)建立知識圖譜與技術元數據之間的關系

這里就要通過分析界面/服務與代碼之間的關聯，建立起映射關系。最終效果就是，使用數據搜索，錄入希望查找的業務術語，得到相關結果，查看樣例數據，如果是需要的數據，提交使用申請，如果不是，繼續根據相關知識進行數據探索。提供數據自服務能力，就是在應用的設計師、數據科學家或者業務分析師與數據之間建立起連接，我們的團隊就是從連接的思路出發，找到了人工智能的切入點。

實際上，數據自服務包含有找、獲、用等眾多環節，我這里說的是找的環節如何實現，這種找的方法，也不可能100%準確，還需要專家進行調整，以及通過強化學習等手段不斷修正，可以看出，應用人工智能也是一個漸進完善的過程。

案例二：通過深度學習，實現移動UI的智能化開發

移動UI的智能化開發，是我們移動團隊應用人工智能的第一個嘗試，現在看來，就是在UI設計師與開發工程師之間建立連接。大家會發現，設計師的設計在變成代碼實現時總會有偏差，即使一個像素的差異，也會影響界面的效果，以往我們采取不同業務模板的方式，建立一些規范對設計和開發做約束，后來移動團隊覺得，可以用深度學習的方式做一些嘗試，尋找不同的界面設計效果，首先通過數據標簽方式確定頁面的風格，再通過圖像片段的方式學習和識別設計稿中的組件，最終經過多次的處理，變成一個樹狀的結構，把這個樹狀結構與代碼進行映射，就產生了和設計圖一致的代碼。

這個案例中，基于圖片的神經網絡學習是一個關鍵技術，但是如果單純使用這個技術，計算量會無法承受，所以我們將處理過程分成了幾個階段，每個階段進行分類，每個階段都可以配合強化學習的方式，由人工指定策略，指導計算機的學習，提高了工程化的能力(類似做法在深藍對陣卡斯帕羅夫的時候就有應用，有一位特級大師會指導深藍當前的策略，例如進攻還是防守，具體招數由深藍決定)。

上述兩個案例中，我們首先在各個領域中找到可能的切入點，針對不同場景使用了不同的方案，并不是都采用了深度學習/神經網絡的方法。我們沒有首先從Tensorflow等框架學起，而是在結構化、半結構化優先使用統計方法，非結構化數據再使用深度學習，而是用業務驅動的方式逐步推進，有效的避免了“深度泛濫”。

總結

未來的軟件必將是人工智能的軟件，但人工智能是通過技術手段實現智能增強，幫助普通人迅速具備部分專家的技能，幫助專家減少重復性的勞動，探索新的知識，而不是取代人。應用人工智能，應該在數據+連接的模式下，從智能集成入手，探索人工智能在軟件中的應用。而這種探索，既包括傳統利用規則實現的機械智能，也包括利用統計學和深度學習方法支撐的實現意圖智能，還有創造意圖/尋找新知識的探索，而統計學方法往往用在結構化數據和半結構化的數據中，深度學習往往要利用非結構化數據。

總之，人工智能是計算機科學、統計學、知識工程、領域知識的一個交叉學科，不能僅僅站在某個角度去理解和嘗試，正所謂“君子不器”。