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

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中臺產生的背景、能力以及定義，本節將重點介紹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中臺的最終目標，要 想實現這一目標，還需要一個比較漫長的探索和實踐過程。

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

六、 Q & A

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

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

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

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

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

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

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

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

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