替代機器學習平臺，AI中臺纔是大勢所趨
本文由 「AI前線」原創（ID：ai-front），原文鏈接：替代機器學習平臺，AI中臺纔是大勢所趨
作者 | 井玉欣
編輯 | Natalie轉載自公眾號「宜信技術學院」，原標題為《AI中臺：一種敏捷的智能業務支持方案》
AI 前線導讀：隨著「數據中臺」的提出和成功實踐，各企業紛紛在「大中臺，小前臺」的共識下啟動了自己的中臺化進程，以數據中臺、技術中臺、業務中臺為代表的一系列技術，極大增強了業務的敏捷性，提高了組織效能。同時隨著智能技術的發展，AI 應用在業務研發中的佔比逐漸升高，但 AI 模型訓練的複雜性導致其開發慢、效率低，嚴重影響了業務的靈活性。
針對這種情況，能否基於中臺化思想對業務中 AI 研發工作進行專門支持，提供對智能需求的迅速實現和靈活試錯功能，從而提升企業智能創新能力？AI 中臺的構建和實施又該如何進行？更多優質內容請關注微信公眾號「AI 前線」（ID：ai-front）
文章大綱：
- AI 中臺的提出
- AI 中臺的目標和定義
- AI 中臺的實施路線
- 實例分析 - 智能投顧機器人為例
- 總結
- Q&A
以下為直播視頻，可點擊回放，時長 1h25m02S，建議在 WiFi 環境下觀看
AI中臺：一種敏捷的智能業務支持方案|宜信技術沙龍第1期_騰訊視頻
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 實例分析 - 智能投顧機器人
上文對中臺實施路線進行了較為詳細的介紹，本節將結合宜信內部智能投顧機器人（投米RA）的實踐案例分析 AI 中臺如何解決實際業務中的智能化需求。（由於智能投顧機器人是一個比較大的解決方案，此處做了適當抽象和縮減。）
4.1 智能投顧機器人投米RA
智能投顧是通過人工智慧演算法，在線提供自動化的資產組合配置建議和財富的管理服務。
智能投顧機器人投米RA涉及的 AI 服務及數據：
- 智能交互，比如聊天機器人；
- 客戶畫像，對於已有客戶積累的公司來說這部分數據已經具備；
- 篩選產品池，從現有理財產品池中篩選表現最優的產品；
- 風險分析，作為一個金融領域的智能應用，風險分析尤為重要，用戶能承受什麼樣的風險、基於該風險值能取得怎麼樣的回報等都要有合理的分析；
- 資產配比，宜信目前有很多類型的資產，如基金、股票、房產等，還會進行全球化的資產配比，這就需要科學、理性、量化的分析，納入風險因子進行綜合考量，實現資產配比；
- 投資產品推薦，參考用戶畫像裏的個人信息、風險分析、資產配比等，為用戶推薦最優化收益產品。
瞭解了智能投顧機器人投米RA的特徵之後，我們結合 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 中臺等中臺模塊獲取支持；而前臺和中臺的劃分在組織架構層面得到了更加清晰的劃分，業務團隊的不同反映了工作性質的不同。
兩者唯一可能出現交叉的人員角色就是業務分析專家了，可能來自於前臺團隊，但其許可權也是有限的，角色分工完全通過中臺管理進行配置，各個環節所能映射的角色是不同的，所以不會出現前臺業務人員介入演算法工作的情況，也可以管理技術人員參與業務分析的程度。總而言之，前臺和中臺的劃分是企業中臺化戰略的一個重要環節，不光要從業務流程上梳理，還要對組織架構、人員職責進行統一的調整。
本文彩蛋
在 AI 前線 後臺回復關鍵詞：AI 中臺，獲取井玉欣博士本次關於 AI 中臺分享的完整版 PPT。
註：請在公眾號對話框回復關鍵詞，留言區回復收不到鏈接哦~
今日薦文
點擊下方圖片即可閱讀
Python 2 將死，你準備好了嗎？
如果你喜歡這篇文章，或希望看到更多類似優質報道，記得給我留言和點贊哦！╰(￣ω￣ｏ)
推薦閱讀：
