AI中臺：一種敏捷的智能業務支持方案|宜信技術學院沙龍分享實錄

內容來源：宜信技術學院第1期技術沙龍-線上直播|AI中臺：一種敏捷的智能業務支持方案

主講人介紹：井玉欣 宜信技術研發中心AI應用團隊負責人

本文字數：13479字 閱讀用時：34分鐘

 

導讀：隨着「數據中臺」的提出和成功實踐，各企業紛紛在「大中臺，小前臺」的共識下啓動了本身的中臺化進程，以數據中臺、技術中臺、業務中臺爲表明的一系列技術，極大加強了業務的敏捷性，提升了組織效能。同時隨着智能技術的發展，AI應用在業務研發中的佔比逐漸升高，但AI模型訓練的複雜性致使其開發慢、效率低，嚴重影響了業務的靈活性。

針對這種狀況，可否基於中臺化思想對業務中AI研發工做進行專門支持，提供對智能需求的迅速實現和靈活試錯功能，從而提高企業智能創新能力？AI中臺的構建和實施又該如何進行？

本次直播宜信研發中心AI應用團隊負責人井玉欣博士結合宜信目前實際業務和中臺化戰略在宜信的實施狀況對以上問題進行了探討。如下是本次分享的實錄。

分享大綱：

1、AI中臺的提出

2、AI中臺的目標和定義

3、AI中臺的實施路線

4、實例分析-智能投顧機器人爲例

5、總結

6、Q&A

PPT：https://pan.baidu.com/s/1-nqZMnEogF2DeBS49lkxOA

視頻：https://v.qq.com/x/page/e0856o2su0x.html

分享實錄

1、AI中臺的提出

1.1 中臺戰略的興起

自從中臺戰略被提出並獲得成功實施後，業界反響強烈，國內各家企業紛紛啓動了本身的中臺化進程。尤爲是對於在戰略中處於核心地位的數據中臺建設，各方都有本身的解讀和心得。

但整體來看，業界造成了對中臺戰略的一些共識，即主張「大中臺、小前臺」，經過構建中臺，沉澱共享服務，提升服務重用率，打破「煙囪式」、「項目制」系統之間的集成和協做壁壘，下降前臺業務的試錯成本，賦予業務快速創新能力，最終提高企業的組織效能。

不管是在金融、在線交易、資訊、醫療仍是教育行業，業界對中臺戰略的研討包括企業平常活動中的各個環節，例如業務中臺、技術中臺、移動中臺等等，但在數據時代，企業中的大量業務都運行於大數據之上，數據的響應能力、處理能力決定了業務效率，因此中臺戰略中最主要的、也是實施的起點，仍然是數據中臺。數據中臺實現了組織內數據標準的統一，並打破數據壁壘，構建統一數據實體，對外提供統一的數據服務。經過這三個「統一」實現了組織內的數據資產中心，爲前臺業務提供了自動化、自助化的敏捷數據能力輸出。

自動化的優點是能夠極大節省常規數據操做的成本開銷，而自助化數據管理能夠支持業務用戶根據本身需求自助式地獲取、處理數據，靈活實現業務需求。但這兩個優點相比於傳統「煙囪式」數據系統來講，只是使業務方感受數據服務更加能用、易用而已，想要真正作到好用，甚至讓業務方喜歡用，不管是數據中臺仍是其餘中臺服務，都離不開智能化的能力。

1.2 智能業務需求的中臺化

 

業務的智能化需求來自於兩方面：

• 一方面從數據層面來看，隨着可獲取的數據愈來愈多，咱們對其中有價值信息的辨識、數據關係的發現、數據趨勢的把握都將變得愈來愈困難，只有經過智能化的方法對大數據進行治理，才能提高業務，甚至創新業務。基於大數據探索，發現其中的潛在數據聯繫與趨勢，能夠爲業務優化與創新提供強有力的支持，實現真正的數據驅動業務。所以數據中臺必須具有智能化能力，可以爲業務提供必定的智能數據分析能力。
• 另外一方面，除了基於數據自底向上的智能化驅動之外，還存在自上而下的企業智能化理念驅動。近幾年來，許多智能技術日趨成熟，相應的智能化理念也深刻人心，大量智能化的成功案例使這些技術逐漸被行業主流接受，甚至成爲了實際上的標準解決方案，好比電商須要推薦、金融須要風控，而隨之就要求研發人員可以在數據之上準確快速實現前臺提出的智能化目標。

上圖是一個示例，數據來源於Roland Berger。宜信做爲一家金融科技公司，更多面對的是金融領域的智能業務需求。從圖中能夠看到在金融這一個領域以內就有這麼多環節已經造成了標準化的智能應用，可想而知在今天企業業務的發展過程當中智能化正在扮演一個多麼重要的角色。

不管是哪方面的需求，都會碰到一個問題：智能業務需求各類各樣、各不相同，一個需求下來，研發團隊須要針對性開展數據分析處理、模型的構建訓練等，過程複雜繁複，效率不高，從而拖長了需求響應時間，下降了業務敏捷程度，拉高了試錯成本。這與在中臺戰略背景下，業務前臺但願可以專一於業務邏輯、靈活應對變化產生了矛盾，並且隨着智能化應用的普遍開展，這個矛盾也愈來愈廣泛。

究其緣由，一方面是因爲智能化的大規模興起才短短几年，智能應用研發還處在比較原始的階段，缺少完整的生命週期管理理論和相應的管理框架工具；另外一方面則反映了咱們的中臺能力沒有徹底覆蓋到前臺業務研發中笨重、重複、低效的環節。

那麼，咱們天然而然會想到，咱們可否對現有數據中臺進行進一步智能化躍遷，解決上述問題呢？若是能，數據中臺能夠或者應該提供什麼樣的數據智能化能力？若是不能，中臺戰略又應該如何敏捷支持智能化業務需求？

1.3 從數據中臺到AI中臺

咱們先來看看數據中臺的智能化支持能力，試分析以下問題：數據中臺能經過通用的智能數據模型充分支持當前業務背景下多樣的智能需求嗎？答案是比較困難，緣由在於業務智能化過程的複雜性。

一般的機器學習任務包括了迴歸、分類、標註、聚類、推薦等等，每一個算法模型的實現又包括了數據預處理、特徵分析、建模、訓練、部署等多個環節，實際中的應用更是有可能包括多個模型。

而數據中臺以數據爲核心，其智能化能力若想支持到以上全部環節，工做量絕對不小，而且會偏離數據中臺的原有目標，所以讓數據中臺承擔所有的智能化業務支持是不合適的。

詳細來講，咱們能夠從目前人工智能（AI）所涵蓋的內容進行分析。廣義上人工智能指利用科學方法和技術，研製可以模仿、延伸、擴展人類智能的機器系統，涉及了計算機科學、數學、哲學、心理學等多門學科；而從計算機科學的角度狹義來看，人工智能特指能夠接受和處理外部數據，並可以作出類人化分析、決策的計算機系統，涵蓋了數據挖掘、機器學習、深度學習、強化學習等多個子領域。如無特殊說明，本文所述人工智能皆指後者。

這幾類任務中，機器學習、深度學習、強化學習的目標、實施過程比較類似，所以一般直接統稱爲機器學習任務，本文也採起這種概略性說法。而數據挖掘任務則與機器學習任務相關又不太相同，他們之間的區別給不少人帶來過困擾。

實際上，按照《數據挖掘與預測分析》書中的定義，「數據挖掘是從大型數據集中發現有用的模式和趨勢的過程」，這其中包括了數據預處理、數據探索、數據降維、數據統計、關聯分析、離羣分析等子任務，這些是機器學習工做開展的基礎。

而另外一方面，數據挖掘還包含了以後的數據聚類、數據預測、數據分類的一些內容，這些正是機器學習所研究的部份內容；因爲機器學習的蓬勃發展和優異性能表現，通常此部分的工做也更多交由機器學習來完成。

總之，二者都是人工智能的重要研究方向，也是企業大數據智能化過程當中的重要環節，彼此相互聯繫，但側重點存在不一樣：數據挖掘更側重於「洞察」，而機器學習更側重於「學習」和「預測」。

從上述分析能夠看出，當前業務背景下，從事「洞察」任務的數據挖掘工做將重心放在了數據上，通常不須要人工輔助便可自動化完成；此外因爲不涉及數據預測、分類等任務，數據挖掘一般採用比較固定的分析算法和模型，因此該部分工做徹底能夠作到自動化、自助化，集成到數據中臺內，做爲固定的智能數據模型服務提供給業務用戶。

另外一方面，從事「學習」和「預測」任務的機器學習工做相對而言更加複雜：

• 機器學習的實施過程一般是高度計算密集型的；
• 所採用算法和模型結構有可能相同，但都須要根據業務數據進行個性化參數訓練；
• 訓練階段一般通過屢次迭代；
• 除部分非監督學習外，實施環節一般須要人工標註環節的參與；
• 線上模型的運行性能須要監控，須要根據數據演進進行更新。

瞭解了人工智能領域分類後，咱們來試圖回答一下前面提出的問題。若是數據中臺願意支持業務所提出的智能化需求，那麼咱們要怎麼對數據中臺進行躍遷？或者說數據中臺要怎麼躍遷本身的能力來支持這些需求呢？

從上圖能夠看出，數據中臺自己具有以數據爲核心、算法固定、有必定的自動性等特徵，咱們徹底能夠在數據中臺裏利用其流式計算能力、批量計算能力、數據可視化技術等來爲相應的業務需求提供支持。

這些還都是數據中臺自己就已經具有的功能。若是還要用數據中臺來作機器學習部分的AI項目支持，還須要具有哪些能力呢？如上圖所示，一圈一圈地往外擴展。首先須要複雜的特徵工程支持能力、模型訓練能力；其次須要數據標註能力、模型部署能力、性能監控能力。

每一項能力都須要耗費大量的人力物力和時間來進行開發，並且由內而外的能力擴展與數據自己的相關性是由強至弱的，也就是說隨着能力層次的不斷擴充，數據中臺逐漸偏離了其「以數據爲核心」的宗旨，並且也會使得數據中臺變得臃腫複雜，在對接前臺業務需求的時候，也可能會帶來更多複雜性的問題。所以數據中臺能夠必定程度上支持智能化業務需求，但若是想單靠數據中臺來支持全部智能化業務需求顯然不是最佳選擇。

那麼咱們要怎麼作呢？將AI中臺與數據中臺進行分離。

如上圖，咱們將數據中臺外面套着的幾層能力抽象剝離出來，整合造成一個獨立的中臺層，依託數據中臺進行必定的協做，共同應對前臺的智能化業務需求。數據中臺主要集成數據挖掘、數據洞察智能算法和模型；新的中臺主要承擔複雜的學習預測類智能需求研發。這一中臺咱們稱之爲「AI中臺」。

上圖是AI中臺與數據中臺分離的結構化圖表，自上而下分別是業務前臺、AI中臺和數據中臺，還有底層一些相關的計算存儲資源。

• 數據中臺提供基本能力，包括數據標準化、數據實體化、數據服務統一化等；還支持部分數據處理的智能需求，包括智能數據模型、關聯分析、主成分分析、異常點分析等。數據中臺主要承擔數據探索的職責。
• AI中臺提供模型設計訓練、模型/算法庫、複用標註管理、監控服務等一系列相關AI緊耦合的能力支持。AI中臺從事的是學習預測的任務。
• 業務前臺則是包括了各類須要中臺提供敏捷性支持的需求，好比業務智能需求、用戶細分需求、個性推薦需求等。

值得注意的是，上圖所示結構只是一個示例，中臺主要面向業務，是爲了更敏捷地響應業務需求，所以中臺體系應該針對業務來設置，好比有一些前臺業務不須要AI中臺能夠直接落到數據中臺來進行處理。

至此咱們已經回答了前文的問題，單純依賴數據中臺來支持業務智能化需求的敏捷實施是不夠的，但咱們能夠在其基礎之上構建專門的AI中臺來提供這一能力。中臺化戰略中不能單獨依賴數據中臺來實現中臺化轉型，阿里的共享服務中心也是包括了業務、技術、數據等多個層面的內容，各企業應該按照本身的業務結構與流程，合理抽象構思本身的中臺服務模型並加以實施。

2、AI中臺的目標與定義

前文經過對智能化業務需求和數據中臺的分析解釋了建設AI中臺的背景和緣由，但AI中臺的目標到底是什麼？其基本要求和能力有哪些？接下來咱們將對此進行詳細討論。

2.1 AI任務劃分與敏捷需求

AI中臺須要靈活地支持各種AI任務，解決各種任務敏捷化過程當中的需求與痛點。當前，企業智能化需求各不相同，致使相應的AI任務也種類繁多。

對AI任務類型有許多種劃分方法，例如經典地按任務目標可分爲迴歸、分類、聚類、標註等等。

這裏咱們採用另外一種劃分方式，認爲全部的AI任務均可以劃分紅爲兩類：

• 一種是針對某個業務領域內特定類型數據，提供對此類數據的基礎AI學習、預測、分析能力的「橫向」任務，例如計算機視覺、天然語言處理任務等；
• 另外一種則是面向業務具體需求的、相對特殊化與個性化的「縱向」任務，例如金融領域的智能風控、電商領域的產品推薦以及比較常見的用戶畫像構建等。

就這兩類AI任務來講，不管哪類任務均可以獨立對外服務，也能夠混合起來相互之間集成、組合，造成AI解決方案來支持更復雜的業務場景。咱們構建智能化業務應用的核心就是將智能化需求分解、映射爲具體的AI任務並一一實現，最後再進行合理地編排組合，實現任務目標。

但另外一方面，在兩類任務的實施過程當中，其敏捷化需求存在着不一樣，對AI中臺應該提供的服務需求也不一樣。相對而言，橫向任務的敏捷化比較容易實現。

對於橫向任務，除部分場景外，不少時候其自己並不直接解決業務需求，常做爲基礎模型對數據進行初步加工，再由一些縱向任務來對接需求。這也給算法實施團隊充足的時間對橫向任務模型進行充分的雕琢，對其敏捷性進行完善。

因爲業務領域內數據的通用性，咱們徹底能夠預訓練出一套經常使用的業務領域專用橫向AI模型，例如金融業務領域內的通用天然語言理解模型等。這樣咱們只需維護、更新這套模型，該領域內的全部智能化相關需求均可以隨時地複用該模型庫，從而節省大量的任務訓練時間。

再進一步，咱們甚至能夠預先訓練一個全領域的橫向AI模型庫，這樣即便咱們進入到一個全新的業務領域，基於這個預訓練庫，也能迅速地打造出領域內通用橫向模型，例如計算機視覺領域的ImageNet項目、天然語言處理領域Google推出的BERT技術等都是如此。

所以，橫向的基礎性AI任務自己可以經過提高模型的通用性、可複用性來敏捷支撐智能化業務需求，一個基本的AI共享服務平臺（或者說咱們但願構建的AI中臺）應該爲其提供一個方便的可複用解決方案設計與自動展開結構，完善的模型庫、算法庫管理系統，以及穩定的模型運行環境等。

對於縱向任務來講，狀況就變得比較複雜。縱向任務需求普遍，多爲定製化開發，數據多種多樣，很難像橫向任務那樣經過構建通用化模型來響應需求；項目的開發須要專門的人工標註，模型須要反覆地訓練與調優，這些無一不須要大量時間與精力，最終致使項目大多數時間成本均花費在這些環節之上，形成AI應用項目研發緩慢。

更爲重要的是，實際中前臺面對業務的瞬息萬變，對智能化應用的最大要求不必定是性能的最優化提高，而是快速研發、迅速上線、當即產生效果，在很多狀況下甚至能夠對性能進行必定的容忍，顯然大多數縱向任務的開發速度是沒法知足這一需求的，這就產生了前臺業務快速推動與後臺研發緩慢的激烈矛盾。AI服務若是要中臺化，那麼咱們的AI中臺必須可以解決縱向任務研發緩慢這一最大痛點。

縱向任務的這一痛點關鍵在於其研發過程的複雜性：

• 在目前大多數縱向任務項目中，因爲需求的不一樣，算法團隊每次都會依次經歷數據獲取、處理、分析、建模、標註，模型訓練、調優、驗證、部署、監控、更新等一系列環節；
• 而每一個環節內還有本身的複雜性，如數據接入管理、特徵工程的開展、標註過程的人工介入、訓練調優的反覆迭代等；
• 此外，整個環節還有衆多角色的介入，如數據分析師、算法工程師、標註工程師、業務分析師等，對角色的管理一樣複雜。

因此針對這類複雜任務問題的研究重點就在於其全生命週期的科學化管理，以及研發流程和每一個環節的優化。經過對研發過程當中各環節的拆分，咱們可以在必定程度上優化任務編排順序，清楚定位各環節參與角色，經過任務並行與角色協做縮短期開銷；而對於每一個環節或局部環節的深刻探討，能夠抽象出自動化操做和可複用的流程，進一步提升業務響應速度。

此外，無論橫向任務仍是縱向任務，二者對AI中臺都有一些共同的基本需求。

首先，智能模型對數據的統一訪問需求。智能模型在訓練階段須要必定量的訓練數據，上線以後須要對接生產數據，之後的監控、更新還須要更多數據，但在實際中每一個項目的數據來源通常都各不相同，這就致使研發人員每次都要根據項目狀況人工去申請、獲取、清洗、預處理數據，十分影響效率。若是可以對接統一的數據服務平臺甚至數據中臺，那麼這一過程將節省下大量時間與精力。

其次，智能模型須要穩定的模型部署、運行平臺，還有相應的模型監控系統來時刻追蹤模型的性能表現。固然，便捷的模型更新機制也應具有，便於咱們根據須要不斷更新、升級模型。

再次，智能模型在開發過程當中，須要一系列的運算、存儲等資源。在大多數企業實體中，不少項目都是項目組本身提供運算資源訓練模型，上線時再申請生產資源對環境進行配置、對項目進行部署。這種各自爲政的資源管理模式不可避免地會形成資源使用的不協調與浪費，須要一套可靠的資源管理系統對計算資源進行集中管控，並提供彈性化的計算資源調度能力。

綜上，咱們能夠基於前文對兩類AI任務的分析，對AI中臺究竟要作什麼，應具有什麼能力進行一下總結。

2.2 AI中臺的目標與能力

AI中臺致力於解決目前企業智能應用研發過程當中存在的響應緩慢、效率低下問題，包括但不限於：

• 「煙囪式」開發，項目成本高、不易集成，過程重複，缺少能力沉澱；
• 研發環節繁多，缺乏優化、協同、自動化輔助，業務響應緩慢；
• 模型研發缺少標準指導，服務接口混亂，難以維護管理；
• 缺乏統一的數據訪問渠道，數據獲取難、標準不一致，重複的數據預處理與特徵工程；
• 缺乏統一的模型運行、監控平臺，以及更新、維護機制；
• 基礎資源分散管理，未獲得充分利用，形成浪費。

以上問題廣泛存在，能夠說如今的許多算法研發團隊更像是算法外包團隊，根據不一樣業務部門的需求各自構建陣地，逐步攻克目標，過程重複、效率有限。而AI中臺則努力提供一個強大的AI能力支持中心，根據業務須要快速提供火力支援，迅速達成目的。因此，AI中臺應具有的能力包括：

• 多層次可複用。對於算法、模型的標準化研發指導，以及可複用服務封裝能力；
• 服務統一化。統一的服務接口規範，支持服務的動態編排組合；
• 流程角色優化。研發流程拆分優化，清晰的研發角色定義，支持任務並行與角色協做，構建AI產品研發流水線；
• 自動化迭代。具有研發環節內部、環節之間的自動化迭代、流轉功能；
• 對接數據平臺。數據中臺或其餘基礎數據服務對接，迅速接入標準化數據，乃至預處理數據；
• 運行監控。提供統一的模型運行環境和監控能力，以及模型更新機制；
• 資源管控。統一資源管理，包括計算資源、存儲資源等，支持資源彈性調度。

結合上述能力，咱們針對AI中臺給出一個探討性的定義：

AI中臺是一套完整的智能模型全生命週期管理平臺和服務配置體系，基於數據平臺服務，經過對智能服務的共享複用、對智能服務研發相關角色進行管理，以及研發流程的標準化、自動化，對前臺業務提供個性化智能服務的迅速構建能力支持。

3、AI中臺的實施路線

前文咱們介紹了AI中臺產生的背景、能力以及定義，本節將重點介紹AI中臺的實施路線。

3.1 AI中臺的主要成分

上圖展現的是AI產品研發的生命週期，業務需求進來，要通過業務理解、模型學習、數據處理和運行監控四個大的步驟。

這四個步驟加上中臺管理構成了AI中臺主要成分：

• 業務理解，根據業務需求設計實施方案，服務編排，通用方案模板管理；
• 數據處理，包括數據獲取和數據準備與分析；
• 模型學習包括特徵工程、模型訓練和模型評估，以及可複用模型庫、算法庫管理；
• 運行監控包括模型自動部署運行、性能監控和對外服務接口管理。
• 此外，爲了便於對AI中臺進行角色、權限統一控制和資源管控，咱們還設置了中臺管理模塊。

3.2 從平臺到中臺的構建

構建數據中臺時咱們通常會採用從平臺到中臺演進的策略，AI中臺的構建也是如此。

從平臺到中臺的躍遷過程當中須要參考常見的機器學習平臺，包括訓練平臺，部署/運行平臺、監控平臺、標註平臺、建模平臺、數據處理平臺等。

咱們能夠根據現有平臺完成AI中臺的構建。建模平臺具有業務建模、服務/模型建模的功能，可用於業務理解和模型學習的環節；訓練平臺具有模型自動化訓練優化評估功能，可用於模型學習環節；數據處理環節須要進行數據分析、樣本分析，能夠用到數據處理平臺和標註平臺；而部署/運行平臺和監控平臺可爲運行監控環節提供支持。因而可知，咱們可以根據現有平臺完成AI中臺的構建。

上圖是AI中臺的能力圖譜。

• 不論企業仍是AI訓練團隊，最先都是從基礎設施出發，包括數據接入、高性能計算資源、運行環境資源等；
• 而後在保障穩定的基礎之上得到訓練工具，包括模型訓練追蹤能力、算法框架支持能力等，實現過程的自動化；
• 有了訓練工具的支撐，咱們能夠把經常使用的業務和環節進行聚攏和集中配置，造成AI平臺，包括模型/服務結構可配置化、模型算法可複用化等，造成標準化的AI研發過程；
• AI中臺其實是對現有能力進行整合串聯，實現生命週期的管理，包括服務編排共享能力、方案可複用能力、全流程管理能力等，在標準之上實現提效，達到高效的目的。

 

上圖將AI中臺能力分別與成分、平臺進行映射，而且以顏色進行區分與對應。

值得注意的是，這裏咱們只列出了部分中臺能力，根據中臺對業務的支持須要還可能會包含其餘能力，須要咱們去建設；此外，平臺對中臺的支持也是有限的，缺少的功能或不全面的功能都要咱們去豐富。

3.3 AI中臺的流程及架構

上圖從前臺業務需求出發，根據AI中臺的五個成分列出AI中臺建設所需的主要功能組件。

• 業務理解部分包括方案模板管理、方案設計、服務編排、服務共享等；
• 數據處理部分包括數據展現、數據訪問、數據分析、數據標註等；
• 模型學習部分包括服務設計、特徵處理、模型訓練、模型追蹤、模型庫、算法庫等；
• 運行監控部分包括具體的產品封裝、自動部署、性能監控、訪問接口管理、模型更新和發佈測試等；
• 中臺管理部分包括角色權限、資源管理、租戶管理和流程控制等。

將前文所述的功能構件映射到AI項目生命週期中得出上圖所示的整體運轉流程。

• 從業務需求開始，對業務進行理解，包括方案模板參考、方案設計、服務編排、服務共享等，若是須要複用其餘服務，能夠在這裏進行訪問配置；
• 數據處理部分的工做經過數據中臺來完成，數據中臺向上提供數據參考、向下提供模型訓練及監控的支持；
• 模型訓練部分造成比較複雜的循環，由於其自己就是一個自動化迭代的過程；
• 封裝部分涉及到監控和對外提供訪問接口等功能；
• 中臺管理在底部提供構建支持。

下文將對各部分運轉流程進行詳細拆解。

業務理解中心

業務理解中心的運轉流程如上圖所示：

• 業務需求進來以後，先從數據處理中心獲取數據分析和參考，採集數據樣本提供可視化支持；
• 而後進行方案選擇：是否具有可複用的方案模板？「是」即直接複用方案，只需改變數據；「否」即進行方案設計。
• 接下來是分解方案到各個服務中，並對服務進行合理有效的編排。此處還需考慮哪些服務可供複用；
• 最後輸出三個方面的內容：向數據處理中心輸出數據獲取要求；向運行監控中心輸出產品封裝指導；向模型學習中心輸出模型訓練任務。

業務理解中心運轉流程主要涉及三個角色：

• 業務分析師，分析相關方案設計、服務編排；
• 數據分析師，提供數據建議、方案設計建議；
• 算法工程師，考慮服務編排、服務之間的數據接口等。

數據處理中心

數據處理中心的運轉流程如上圖所示：

• 從業務處理中心獲取數據要求規範，經過數據訪問對接數據中臺；
• 基於數據中臺向上提供數據分析功能、數據展現及功能可視化；
• 經過數據展現得到參考，對數據進行標註；
• 操做數據訪問，返回到數據中臺，對數據進行從新加工。
• 最後對對外輸出三個方面的內容：向業務理解中心輸出數據分析參考；向模型學習中心輸出模型訓練數據；向運行監控中心輸出生產數據。

數據處理中心運轉流程主要涉及四個角色：

• 數據分析師，要求對其中主要環節都有涉獵；
• 業務分析師和算法工程師主要關注數據展現；
• 標註工程師，主要參與數據標註環節。

模型學習中心

模型學習中心是算法工程師的主要陣地，該部分的運轉流程如上圖所示：

• 接收來自業務理解中心的模型服務任務、數據處理中心的訓練數據、運行監控中心的性能矯正信息，進行服務設計。服務設計時要考慮須要多少個模型？模型之間如何串聯？算法庫和模型庫中是否有可供複用的算法與模型？
• 服務流程設計完成後進行特徵處理；
• 將特徵輸入模型進行編碼和訓練；
• 將模型訓練結果輸入模型追蹤的功能組件進行模型評估；
• 通過迭代得到最優訓練模型輸出到運行監控中心，同時輸出數據操做到數據處理中心。

運行監控中心

運行監控中心是與業務用戶直接相關的一環，由運維人員進行模型更新和性能監控。該部分的運轉流程如上圖所示：

• 接收數據處理中心提供的生產數據，經過訪問接口處理輸出，寫回到數據處理中心；
• 接收模型學習中心的已訓練模型服務、業務理解中心的產品封裝指導，對產品服務進行串聯封裝、部署、發佈、測試；（若是要封裝的產品是對已有產品的更新，則先經過模型更新機制對現有模型進行合理啓停更新操做以後再部署發佈測試。）
• 向上將交互數據提供給訪問接口，並對訪問接口進行配置；向下提供性能指標給性能監控，若是發現問題及時報警，並反饋到模型學習中心進行從新訓練。

AI中臺層級架構

AI中臺的層級架構如上圖，AI中臺處於數據模型服務與業務解決方案之間，向上鏈接業務向下溝通數據，每個層級都有其可複用的機制。

中間部分從上而下分紅業務理解、模型學習、數據處理三大板塊；右側的運行監控對產品和模型進行統一封裝、對外統一的訪問接口等；左側是貫穿於整個流程始終的平臺管理，包括角色權限、租戶管理、流程控制、資源管理等。

4、實例分析-智能投顧機器人

上文對中臺實施路線進行了較爲詳細的介紹，本節將結合宜信內部智能投顧機器人的實踐案例分析AI中臺如何解決實際業務中的智能化需求。（因爲智能投顧機器人是一個比較大的解決方案，此處作了適當抽象和縮減。）

4.1 智能投顧機器人

智能投顧是經過人工智能算法，在線提供自動化的資產組合配置建議和財富的管理服務。例如宜信旗下的智能理財產品：投米RA，就是經過智能化的方式幫助用戶作科學的資產配置，從而實現財富管理方式的升級。

智能投顧機器人涉及的AI服務及數據：

• 智能交互，好比聊天機器人；
• 客戶畫像，對於已有客戶積累的公司來講這部分數據已經具有；
• 篩選產品池，從現有理財產品池中篩選表現最優的產品，目前咱們的理財產品池能夠實現定時批量處理，自動化篩選出每一個時期表現較好的精選產品；
• 風險分析，做爲一個金融領域的智能應用，風險分析尤其重要，用戶能承受什麼樣的風險、基於該風險值能取得怎麼樣的回報等都要有合理的分析；
• 資產配比，宜信目前有不少類型的資產，如基金、股票、房產等，還會進行全球化的資產配比，這就須要科學、理性、量化的分析，歸入風險因子進行綜合考量，實現資產配比；
• 投資產品推薦，參考用戶畫像裏的我的信息、風險分析、資產配比等，爲用戶推薦最優化收益產品。

瞭解了智能投顧機器人的特徵以後，咱們結合AI中臺的運轉流程具體來看該案例的實施。

4.2 案例實施

業務理解

在業務理解環節，首先須要考慮業務方案是什麼樣的？是否可複用？假設有可複用的方案，直接接入數據便可；若是沒有可複用的方案，則須要設計新的方案。

如上圖右側的設計導圖所示，須要考慮數據接口配置和數據源/角色配置。好比方案的數據接口有哪些？涉及到哪些服務？如何返回？每一個結構裏相關的角色有哪些？等等。

最重要的是考慮哪些服務是可複用的？假設公司內部已經有了一個聊天機器人，那麼這裏徹底能夠用它來接待客戶，承擔智能聊天的功能；此外財富產品畫像服務也已經有了，直接把篩選產品詞這部分產生的數據源接入進來便可；而資產配比服務，咱們可能有相關的線下模型，而且已經將它進行服務化封裝。以上這些服務均可複用，風險分析服務及後續投資產品推薦服務須要新建。

可複用的服務、需新建的服務明確以後，各個團隊能夠並行開發，角色配置也是如此，如此很快即可進入下一階段，提升了開發的效率。

模型學習

延續上一階段的實踐，對風險分析服務進行實際模型設計與訓練。

從方案設計獲取模型服務job，設計服務流程，它的輸入是一個篩選後的用戶畫像，如上圖右側的結構所示，設計了兩個比較簡單的模型：一個是風險承受能力測評模型，這個模型之上還複用了一個已有的特徵篩選模型，配合將用戶畫像裏適合模型的有用特徵提取出來並輸入到模型中；另外一個是流動性需求模型，評估資產需求，這裏加了一個Python的代碼片斷對用戶畫像的數據進行加工再輸入模型中。底下還新建了一個模型，對數據進行合併和輸出。

該模型可進行自動訓練、可視化追蹤。模型編排肯定後，任務自動發送給工程師，能夠在終端上經過交互式編程界面進行開發，以後對代碼進行上傳，在託管服務器能夠將代碼直接發佈到訓練集羣上，自動進行訓練，以後將訓練結果推送到追蹤服務器上，獲取相關數據進行模型調優反覆迭代，同時追蹤服務器會記錄每一次指標及模型，可選擇最優的模型發佈給監控中心。

運行監控

運行監控主要對服務和方案進行封裝、測試、發佈，包括接口配置。能夠單個服務測試，也能夠整個方案一塊兒進行測試。

服務上線以後，經過提供可視化支持以及相關統計報表對整個性能進行合理監控，如上圖所示，一旦發現報警，可回到模型學習中心，進行從新訓練。

數據處理

前面幾個部分都跟數據處理相關，數據處理的部分直接交給數據中臺來完成，AI中臺只提供數據中臺的訪問接口，主要操做包括：經過數據中臺的可視化工具觀察數據，利用數據中臺數據模型預處理數據，標註平臺開展各模型數據標註。其最終目標是支持模型訓練過程當中訪問數據中臺綁定訓練數據，好比文件、數據庫以及其餘數據存儲系統。

上圖右側展現的是宜信已經開源的工具，包括DBus、Wormhole、Moonbox、Davinci，能夠幫助你們更好地構建數據中臺。

5、總結

以上部分介紹了AI中臺產生的背景、目標、定義、實施路線。

• AI中臺的構建能夠複用現有的技術、能力和平臺，是一種敏捷的智能業務支持方案；
• AI中臺是數據/業務智能化發展的產物，以自動化模型代替人工流轉，下降資源和人員成本；
• AI平臺的能力建設基於數據平臺/中臺，面向前臺業務需求，提高響應業務需求的能力。
• 經過AI中臺沉澱技術、共享服務、優化流程、整合資源、下降成本、提高效率是咱們構建AI中臺的最終目標，要想實現這一目標，還須要一個比較漫長的探索和實踐過程。

從平臺到中臺，面向業務一步步實現躍遷，這是一個按部就班的過程，不可一蹴而就。企業實施落地中臺化戰略，最重要的是從本身的業務實際、具體的研發條件出發，以共享服務、整合資源、下降成本、提高效率爲目標，創建符合業務需求的中臺體系和方法論。

6、Q & A

Q1: AI中臺要從哪些維度來評估需求的重要程度？業務需求多種多樣，如何設計可複用的AI模型？

A: 評估需求的部分不該交由AI中臺來完成，在業務前臺將需求提交過來時應該與業務分析專家、需求分析專家進行合理的討論肯定項目的優先級，評定的維度主要從業務的重要性、影響客戶的範圍、時間緊迫性等維度出發綜合評估，通常在專門的需求分析系統中完成。

AI模型的可複用設計問題實在太泛化了，主要從業務中自行體會，對於有經驗的架構師能夠比較容易地識別出不一樣粒度下的複用方案設計。這裏簡單從不一樣層次討論一下。算法級沒必要多說，而模型級別主要考慮單個模型的功能粒度，通常來講咱們不建議一個模型過於複雜，過於複雜的功能咱們一般會採用多個模型分別實現各功能，再在服務設計中經過模型編排來實現；模型的通用性須要定義好模型的數據接口，以及模型結構，考慮模型重訓練和增量訓練的機制，便於複用時進行模型適應；此外模型的功能通用性一樣須要關注。服務級別的複用相對比較容易識別，是比較固定和獨立的場景服務，例如聊天機器人、客戶風控等等，通常須要複用的服務基本不須要過多的重訓練和調整，相對固定，直接調用或簡單配置後調用便可，服務的複用設計相似於SOA過程當中web服務的設計，增長考慮服務的可配置性。方案級別的複用比較少，由於解決方案已是一套相對固定的產品了，咱們主張的複用也更相似於一種模板和指導架構，中間的服務模型填充由用戶本身實現，因此方案級別的複用設計能夠直接從重要的產品抽象。

Q2: 這些平臺都已經落地了嗎？對業務提高的效果是怎樣的呢？

A: 已經部分落地，不斷完善中，研發速度快了，工程師省事了，效率高了，對業務輸出的智能化產品也多了:)

Q3: 請問大家這邊AI中臺是否對外輸出，是否支持本地化部署？

A: AI中臺在發育成熟後會考慮將部分能力以工具的形式對外發布，本地化部署固然在咱們的考慮以內。

Q4: 前臺和中臺是否會出現分工不明確的問題，怎麼才能更好的解決？

A: 映射到咱們的研發流程裏，前臺和中臺的劃分仍是很明確的，前臺在肯定研發計劃時，將只負責前臺業務邏輯的設計和交互管理，對於其他的數據功能、AI功能會直接推送到技術中臺、數據中臺、AI中臺等中臺模塊獲取支持；而前臺和中臺的劃分在組織架構層面獲得了更加清晰的劃分，業務團隊的不一樣反映了工做性質的不一樣，二者惟一可能出現交叉的人員角色就是業務分析專家了，可能來自於前臺團隊，但其權限也是有限的，角色分工徹底經過中臺管理進行配置，各個環節所能映射的角色是不一樣的，因此不會出現前臺業務人員介入算法工做的狀況，也能夠管理技術人員參與業務分析的程度。總而言之，前臺和中臺的劃分是企業中臺化戰略的一個重要環節，不光要從業務流程上梳理，還要對組織架構、人員職責進行統一的調整。

【以上爲井玉欣博士分享的所有內容】