隨着“數據中台”的提出和成功實踐，各企業紛紛在“大中台，小前台”的共識下啟動了自己的中台化進程，以數據中台、技術中台、業務中台為代表的一系列技術，極大增強了業務的敏捷性，提高了組織效能。同時隨着智能技術的發展，AI應用在業務研發中的占比逐漸升高，但AI模型訓練的復雜性導致其開發慢、效率低，嚴重影響了業務的靈活性。
1
AI中台的提出
1.1 中台戰略的興起
自從中台戰略被提出並得到成功實施后，業界反響強烈，國內各家企業紛紛啟動了自己的中台化進程。尤其是對於在戰略中處於核心地位的數據中台建設，各方都有自己的解讀和心得。
但總體來看，業界形成了對中台戰略的一些共識，即主張“大中台、小前台”，通過構建中台，沉淀共享服務，提高服務重用率，打破“煙囪式”、“項目制”系統之間的集成和協作壁壘，降低前台業務的試錯成本，賦予業務快速創新能力，最終提升企業的組織效能。
無論是在金融、在線交易、資訊、醫療還是教育行業，業界對中台戰略的研討包括企業日常活動中的各個環節，例如業務中台、技術中台、移動中台等等，但在數據時代，企業中的大量業務都運行於大數據之上，數據的響應能力、處理能力決定了業務效率，所以中台戰略中最主要的、也是實施的起點，仍然是數據中台。數據中台實現了組織內數據標准的統一，並打破數據壁壘，構建統一數據實體，對外提供統一的數據服務。通過這三個“統一”實現了組織內的數據資產中心，為前台業務提供了自動化、自助化的敏捷數據能力輸出。
自動化的優勢是可以極大節省常規數據操作的成本開銷，而自助化數據管理可以支持業務用戶根據自己需求自助式地獲取、處理數據，靈活實現業務需求。但這兩個優勢相比於傳統“煙囪式”數據系統來說，只是使業務方感覺數據服務更加能用、易用而已，想要真正做到好用，甚至讓業務方喜歡用，無論是數據中台還是其他中台服務，都離不開智能化的能力。
1.2 智能業務需求的中台化
從圖中可以看到在金融這一個領域之內就有這么多環節已經形成了標准化的智能應用，可想而知在今天企業業務的發展過程中智能化正在扮演一個多么重要的角色。
無論是哪方面的需求，都會碰到一個問題：智能業務需求各種各樣、各不相同，一個需求下來，研發團隊需要針對性開展數據分析處理、模型的構建訓練等，過程復雜繁復，效率不高，從而拖長了需求響應時間，降低了業務敏捷程度，拉高了試錯成本。這與在中台戰略背景下，業務前台希望能夠專注於業務邏輯、靈活應對變化產生了矛盾，而且隨着智能化應用的廣泛開展，這個矛盾也越來越普遍。
如上圖，我們將數據中台外面套着的幾層能力抽象剝離出來，整合形成一個獨立的中台層，依托數據中台進行一定的協作，共同應對前台的智能化業務需求。數據中台主要集成數據挖掘、數據洞察智能算法和模型；新的中台主要承擔復雜的學習預測類智能需求研發。這一中台我們稱之為“AI中台”。
2
AI中台的目標與定義
前文通過對智能化業務需求和數據中台的分析解釋了建設AI中台的背景和原因，但AI中台的目標究竟是什么？其基本要求和能力有哪些？接下來我們將對此進行詳細討論。
2.1 AI任務划分與敏捷需求
2.2 AI中台的目標與能力
結合上述能力，我們針對AI中台給出一個探討性的定義：
AI中台是一套完整的智能模型全生命周期管理平台和服務配置體系，基於數據平台服務，通過對智能服務的共享復用、對智能服務研發相關角色進行管理，以及研發流程的標准化、自動化，對前台業務提供個性化智能服務的迅速構建能力支持。
3
AI中台的實施路線
前文我們介紹了AI中台產生的背景、能力以及定義，本節將重點介紹AI中台的實施路線。
3.1 AI中台的主要成分
上圖展示的是AI產品研發的生命周期，業務需求進來，要經過業務理解、模型學習、數據處理和運行監控四個大的步驟。
3.2 從平台到中台的構建
構建數據中台時我們一般會采用從平台到中台演進的策略，AI中台的構建也是如此。
從平台到中台的躍遷過程中需要參考常見的機器學習平台，包括訓練平台，部署/運行平台、監控平台、標注平台、建模平台、數據處理平台等。
我們可以根據現有平台完成AI中台的構建。建模平台具備業務建模、服務/模型建模的功能，可用於業務理解和模型學習的環節；訓練平台具備模型自動化訓練優化評估功能，可用於模型學習環節；數據處理環節需要進行數據分析、樣本分析，可以用到數據處理平台和標注平台；而部署/運行平台和監控平台可為運行監控環節提供支持。由此可見，我們能夠根據現有平台完成AI中台的構建。
上圖將AI中台能力分別與成分、平台進行映射，並且以顏色進行區分與對應。
值得注意的是，這里我們只列出了部分中台能力，根據中台對業務的支持需要還可能會包含其他能力，需要我們去建設；此外，平台對中台的支持也是有限的，缺乏的功能或不全面的功能都要我們去豐富。
3.3 AI中台的流程及架構
下文將對各部分運轉流程進行詳細拆解。
業務理解中心
數據處理中心
模型學習中心
運行監控中心
AI中台層級架構
AI中台的層級架構如上圖，AI中台處於數據模型服務與業務解決方案之間，向上連接業務向下溝通數據，每一個層級都有其可復用的機制。
中間部分從上而下分成業務理解、模型學習、數據處理三大板塊；右側的運行監控對產品和模型進行統一封裝、對外統一的訪問接口等；左側是貫穿於整個流程始終的平台管理，包括角色權限、租戶管理、流程控制、資源管理等。
4
實例分析-智能投顧機器人
上文對中台實施路線進行了較為詳細的介紹，本節將結合宜信內部智能投顧機器人的實踐案例分析AI中台如何解決實際業務中的智能化需求。（由於智能投顧機器人是一個比較大的解決方案，此處做了適當抽象和縮減。）
4.1 智能投顧機器人
智能投顧是通過人工智能算法，在線提供自動化的資產組合配置建議和財富的管理服務。例如宜信旗下的智能理財產品：投米RA，就是通過智能化的方式幫助用戶做科學的資產配置，從而實現財富管理方式的升級。
4.2 案例實施
業務理解
在業務理解環節，首先需要考慮業務方案是什么樣的？是否可復用？假設有可復用的方案，直接接入數據即可；如果沒有可復用的方案，則需要設計新的方案。
如上圖右側的設計導圖所示，需要考慮數據接口配置和數據源/角色配置。比如方案的數據接口有哪些？涉及到哪些服務？如何返回？每個結構里相關的角色有哪些？等等。
最重要的是考慮哪些服務是可復用的？假設公司內部已經有了一個聊天機器人，那么這里完全可以用它來接待客戶，承擔智能聊天的功能；此外財富產品畫像服務也已經有了，直接把篩選產品詞這部分產生的數據源接入進來即可；而資產配比服務，我們可能有相關的線下模型，並且已經將它進行服務化封裝。以上這些服務都可復用，風險分析服務及后續投資產品推薦服務需要新建。
可復用的服務、需新建的服務明確之后，各個團隊可以並行開發，角色配置也是如此，如此很快便可進入下一階段，提高了開發的效率。
模型學習
延續上一階段的實踐，對風險分析服務進行實際模型設計與訓練。
從方案設計獲取模型服務job，設計服務流程，它的輸入是一個篩選后的用戶畫像，如上圖右側的結構所示，設計了兩個比較簡單的模型：一個是風險承受能力測評模型，這個模型之上還復用了一個已有的特征篩選模型，配合將用戶畫像里適合模型的有用特征提取出來並輸入到模型中；另一個是流動性需求模型，評估資產需求，這里加了一個Python的代碼片段對用戶畫像的數據進行加工再輸入模型中。底下還新建了一個模型，對數據進行合並和輸出。
該模型可進行自動訓練、可視化追蹤。模型編排確定后，任務自動發送給工程師，可以在終端上通過交互式編程界面進行開發，之后對代碼進行上傳，在托管服務器可以將代碼直接發布到訓練集群上，自動進行訓練，之后將訓練結果推送到追蹤服務器上，獲取相關數據進行模型調優反復迭代，同時追蹤服務器會記錄每一次指標及模型，可選擇最優的模型發布給監控中心。
運行監控
運行監控主要對服務和方案進行封裝、測試、發布，包括接口配置。可以單個服務測試，也可以整個方案一起進行測試。
服務上線之后，通過提供可視化支持以及相關統計報表對整個性能進行合理監控，如上圖所示，一旦發現報警，可回到模型學習中心，進行重新訓練。
數據處理
前面幾個部分都跟數據處理相關，數據處理的部分直接交給數據中台來完成，AI中台只提供數據中台的訪問接口，主要操作包括：通過數據中台的可視化工具觀察數據，利用數據中台數據模型預處理數據，標注平台開展各模型數據標注。其最終目標是支持模型訓練過程中訪問數據中台綁定訓練數據，比如文件、數據庫以及其他數據存儲系統。
上圖右側展示的是宜信已經開源的工具，包括DBus、Wormhole、Moonbox、Davinci，可以幫助大家更好地構建數據中台。
5
總結
6
Q & A
Q1: AI中台要從哪些維度來評估需求的重要程度？業務需求多種多樣，如何設計可復用的AI模型？
A: 評估需求的部分不應交由AI中台來完成，在業務前台將需求提交過來時應該與業務分析專家、需求分析專家進行合理的討論確定項目的優先級，評定的維度主要從業務的重要性、影響客戶的范圍、時間緊迫性等維度出發綜合評估，一般在專門的需求分析系統中完成。
AI模型的可復用設計問題實在太泛化了，主要從業務中自行體會，對於有經驗的架構師可以比較容易地識別出不同粒度下的復用方案設計。這里簡單從不同層次討論一下。算法級不必多說，而模型級別主要考慮單個模型的功能粒度，一般來說我們不建議一個模型過於復雜，過於復雜的功能我們通常會采用多個模型分別實現各功能，再在服務設計中通過模型編排來實現；模型的通用性需要定義好模型的數據接口，以及模型結構，考慮模型重訓練和增量訓練的機制，便於復用時進行模型適應；此外模型的功能通用性同樣需要關注。服務級別的復用相對比較容易識別，是比較固定和獨立的場景服務，例如聊天機器人、客戶風控等等，一般需要復用的服務基本不需要過多的重訓練和調整，相對固定，直接調用或簡單配置后調用即可，服務的復用設計類似於SOA過程中web服務的設計，增加考慮服務的可配置性。方案級別的復用比較少，因為解決方案已經是一套相對固定的產品了，我們主張的復用也更類似於一種模板和指導架構，中間的服務模型填充由用戶自己實現，所以方案級別的復用設計可以直接從重要的產品抽象。
Q2: 這些平台都已經落地了嗎？對業務提升的效果是怎樣的呢？
A: 已經部分落地，不斷完善中，研發速度快了，工程師省事了，效率高了，對業務輸出的智能化產品也多了:)
Q3: 請問你們這邊AI中台是否對外輸出，是否支持本地化部署？
A: AI中台在發育成熟后會考慮將部分能力以工具的形式對外發布，本地化部署當然在我們的考慮之內。
Q4: 前台和中台是否會出現分工不明確的問題，怎么才能更好的解決？
A: 映射到我們的研發流程里，前台和中台的划分還是很明確的，前台在確定研發計划時，將只負責前台業務邏輯的設計和交互管理，對於其余的數據功能、AI功能會直接推送到技術中台、數據中台、AI中台等中台模塊獲取支持；而前台和中台的划分在組織架構層面得到了更加清晰的划分，業務團隊的不同反映了工作性質的不同，兩者唯一可能出現交叉的人員角色就是業務分析專家了，可能來自於前台團隊，但其權限也是有限的，角色分工完全通過中台管理進行配置，各個環節所能映射的角色是不同的，所以不會出現前台業務人員介入算法工作的情況，也可以管理技術人員參與業務分析的程度。總而言之，前台和中台的划分是企業中台化戰略的一個重要環節，不光要從業務流程上梳理，還要對組織架構、人員職責進行統一的調整。
互聯互通社區
互聯互通社區專注於IT互聯網交流與學習，關注公眾號：互聯互通社區，每日獲取最新報告並附帶專題內容輔助學習。方案打造與宣講、架構設計與執行、技術攻堅與培訓、數據中台等技術咨詢與服務合作請+微信：hulianhutongshequ
