1.1 中臺戰略的興起

自從中臺戰略被提出并得到成功實施后，業界反響強烈，國內各家企業紛紛啟動了自己的中臺化進程。尤其是對于在戰略中處于核心地位的數據中臺建設，各方都有自己的解讀和心得。

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

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

自動化的優勢是可以極大節省常規數據操作的成本開銷，而自助化數據管理可以支持業務用戶根據自己需求自助式地獲取、處理數據，靈活實現業務需求。但這兩個優勢相比于傳統“煙囪式”數據系統來說，只是使業務方感覺數據服務更加能用、易用而已，想要真正做到好用，甚至讓業務方喜歡用，無論是數據中臺還是其他中臺服務，都離不開智能化的能力。

1.2 智能業務需求的中臺化

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

• 一方面從數據層面來看，隨著可獲取的數據越來越多，我們對其中有價值信息的辨識、數據關系的發現、數據趨勢的把握都將變得越來越困難，只有通過智能化的方法對大數據進行治理，才能提升業務，甚至創新業務。基于大數據探索，發現其中的潛在數據聯系與趨勢，可以為業務優化與創新提供強有力的支持，實現真正的數據驅動業務。因此數據中臺必須具備智能化能力，能夠為業務提供一定的智能數據分析能力。

• 另一方面，除了基于數據自底向上的智能化驅動以外，還存在自上而下的企業智能化理念驅動。近幾年來，許多智能技術日趨成熟，相應的智能化理念也深入人心，大量智能化的成功案例使這些技術逐漸被行業主流接受，甚至成為了實際上的標準解決方案，比如電商需要推薦、金融需要風控，而隨之就要求研發人員能夠在數據之上準確快速實現前臺提出的智能化目標。

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

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

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

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

1.3 從數據中臺到AI中臺

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

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

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

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

這幾類任務中，機器學習、深度學習、強化學習的目標、實施過程比較相似，因此通常直接統稱為機器學習任務，本文也采取這種概略性說法。而數據挖掘任務則與機器學習任務相關又不太相同，他們之間的區別給很多人帶來過困擾。

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

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

總之，兩者都是人工智能的重要研究方向，也是企業大數據智能化過程中的重要環節，彼此相互聯系，但側重點存在不同：數據挖掘更側重于“洞察”，而機器學習更側重于“學習”和“預測”。

從上述分析可以看出，當前業務背景下，從事“洞察”任務的數據挖掘工作將重心放在了數據上，一般不需要人工輔助即可自動化完成；此外由于不涉及數據預測、分類等任務，數據挖掘通常采用比較固定的分析算法和模型，所以該部分工作完全可以做到自動化、自助化，集成到數據中臺內，作為固定的智能數據模型服務提供給業務用戶。

另一方面，從事“學習”和“預測”任務的機器學習工作相對而言更加復雜：

• 機器學習的實施過程通常是高度計算密集型的；

• 所采用算法和模型結構有可能相同，但都需要根據業務數據進行個性化參數訓練；

• 訓練階段通常經過多次迭代；

• 除部分非監督學習外，實施環節通常需要人工標注環節的參與；

• 線上模型的運行性能需要監控，需要根據數據演進進行更新。

了解了人工智能領域分類后，我們來試圖回答一下前面提出的問題。如果數據中臺愿意支持業務所提出的智能化需求，那么我們要怎么對數據中臺進行躍遷？或者說數據中臺要怎么躍遷自己的能力來支持這些需求呢？

從上圖可以看出，數據中臺本身具備以數據為核心、算法固定、有一定的自動性等特征，我們完全可以在數據中臺里利用其流式計算能力、批量計算能力、數據可視化技術等來為相應的業務需求提供支持。

這些還都是數據中臺本身就已經具備的功能。如果還要用數據中臺來做機器學習部分的AI項目支持，還需要具備哪些能力呢？如上圖所示，一圈一圈地往外擴展。首先需要復雜的特征工程支持能力、模型訓練能力；其次需要數據標注能力、模型部署能力、性能監控能力。

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

那么我們要怎么做呢？將AI中臺與數據中臺進行分離。

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

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

• 數據中臺提供基本能力，包括數據標準化、數據實體化、數據服務統一化等；還支持部分數據處理的智能需求，包括智能數據模型、關聯分析、主成分分析、異常點分析等。數據中臺主要承擔數據探索的職責。

• AI中臺提供模型設計訓練、模型/算法庫、復用標注管理、監控服務等一系列相關AI緊耦合的能力支持。AI中臺從事的是學習預測的任務。

• 業務前臺則是包括了各種需要中臺提供敏捷性支持的需求，比如業務智能需求、用戶細分需求、個性推薦需求等。

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

至此我們已經回答了前文的問題，單純依賴數據中臺來支持業務智能化需求的敏捷實施是不夠的，但我們可以在其基礎之上構建專門的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中臺是一套完整的智能模型全生命周期管理平臺和服務配置體系，基于數據平臺服務，通過對智能服務的共享復用、對智能服務研發相關角色進行管理，以及研發流程的標準化、自動化，對前臺業務提供個性化智能服務的迅速構建能力支持。

前文我們介紹了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中臺處于數據模型服務與業務解決方案之間，向上連接業務向下溝通數據，每一個層級都有其可復用的機制。

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

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

4.1 智能投顧機器人

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

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

• 智能交互，比如聊天機器人；

• 客戶畫像，對于已有客戶積累的公司來說這部分數據已經具備；

• 篩選產品池，從現有理財產品池中篩選表現最優的產品，目前我們的理財產品池可以實現定時批量處理，自動化篩選出每個時期表現較好的精選產品；

• 風險分析，作為一個金融領域的智能應用，風險分析尤為重要，用戶能承受什么樣的風險、基于該風險值能取得怎么樣的回報等都要有合理的分析；

• 資產配比，宜信目前有很多類型的資產，如基金、股票、房產等，還會進行全球化的資產配比，這就需要科學、理性、量化的分析，納入風險因子進行綜合考量，實現資產配比；

• 投資產品推薦，參考用戶畫像里的個人信息、風險分析、資產配比等，為用戶推薦最優化收益產品。

了解了智能投顧機器人的特征之后，我們結合AI中臺的運轉流程具體來看該案例的實施。

4.2 案例實施

業務理解

在業務理解環節，首先需要考慮業務方案是什么樣的？是否可復用？假設有可復用的方案，直接接入數據即可；如果沒有可復用的方案，則需要設計新的方案。

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

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

可復用的服務、需新建的服務明確之后，各個團隊可以并行開發，角色配置也是如此，如此很快便可進入下一階段，提高了開發的效率。

模型學習

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

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

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

運行監控

運行監控主要對服務和方案進行封裝、測試、發布，包括接口配置。可以單個服務測試，也可以整個方案一起進行測試。

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

數據處理

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

上圖右側展示的是宜信已經開源的工具，包括DBus、Wormhole、Moonbox、Davinci，可以幫助大家更好地構建數據中臺。

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

• AI中臺的構建可以復用現有的技術、能力和平臺，是一種敏捷的智能業務支持方案；

• AI中臺是數據/業務智能化發展的產物，以自動化模型代替人工流轉，降低資源和人員成本；

• AI平臺的能力建設基于數據平臺/中臺，面向前臺業務需求，提升響應業務需求的能力。

• 通過AI中臺沉淀技術、共享服務、優化流程、整合資源、降低成本、提升效率是我們構建AI中臺的最終目標，要想實現這一目標，還需要一個比較漫長的探索和實踐過程。

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

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

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

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

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

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

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

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

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

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

【本文是51CTO專欄機構宜信技術學院的原創文章，微信公眾號“宜信技術學院( id: CE_TECH)”】

戳這里，看該作者更多好文