從去年開始，好像就有一只無形的手一直將我與“微服務”、“平臺化”、“中臺化”撮合在一起，給我帶來了很多的困擾和思考與收獲。

故事的開始源于去年的技術雷達峰會，我在會上做了一場關于平臺崛起的主題分享（《The Rise of Platform》），這場分享主要是從技術的層面從Global的視角介紹了平臺化的興起，以及分享從基礎設施到人工智能等各個領域不斷涌現的各類平臺，以及平臺化對于軟件開發人員及企業的影響。

記得當時在做演講彩排的時候，有同事就提到過，在中國提“數字化平臺戰略”可能大家會覺得比較抽象比較遠大空，如果你提“中臺”大家會更熟悉一些。

而這也是我第一次聽到“中臺”這個詞，原來除了我們熟悉的“前臺”和“后臺”外，居然還有個“中臺”這樣一個神奇的存在。

那…… 中臺到底是什么？會不會又是另一個Buzzword呢？這個從名字上看像是從前臺與后臺中間硬擠出來的新斷層，它與前臺和后臺的區別和界限到底在哪兒？什么應該放到中臺，什么又應該放到前臺或是后臺？它的出現到底是為了解決什么問題呢？

從那時開始，一個接一個的問題就不斷的涌出并縈繞在我的腦子里。直到一年多后的今天，隨著參與的幾個平臺化、企業中臺相關的項目已經順利地步上了正軌，終于可以坐下來回顧一下這一年的實踐與思考，再次試圖回答這些問題，并梳理成文，與大家交流探討。

中臺迷思

到處都在喊中臺，到處都是中臺，中臺這個詞在我看來已經被濫用了。

*?在有些人眼里：中臺就是技術平臺，像微服務開發框架、Devops平臺、PaaS平臺，容器云之類的，人們都叫它“技術中臺”。

*?在有些人眼里：中臺就是微服務業務平臺，像最常見的什么用戶中心，訂單中心，各種微服務集散地，人們都叫它“業務中臺”。

*?在有些人眼里：中臺應該是組織的事情，在釋放潛能：平臺型組織的進化路線圖 (豆瓣)中就提出了平臺型組織和組織中臺的概念，這類組織中臺在企業中主要起到投資評估與投后管理的作用，類似于企業內部資源調度中心和內部創新孵化組織，人們叫它“組織中臺”

看完本篇你就會理解，上邊的這幾類“中臺”劃分還是靠譜的，更多我看到的情況是大家為了響應企業的“中臺戰略”，干脆直接將自己系統的“后端”或是“后臺”改個名，就叫“中臺”。

中臺到底是什么？它對于企業的意義到底是什么？當我們談中臺時我們到底在談些什么？

想要尋找到答案，僅僅沉寂在各自“中臺”之中，如同管中窺豹，身入迷陣，是很難想清楚的。不如換個 ?度，從各類的“中臺迷陣”中跳脫出來，嘗試以更高的視角，從企業均衡可持續發展的角度，來思考中臺的價值，來試圖反推它存在的價值。

所以，為了搞明白中臺存在的價值，我們需要回答以下兩個問題：

1. 企業為什么要平臺化？

2. 企業為什么要建中臺？

第一個問題：企業為什么要平臺化？

先給答案，其實很簡單：

因為在當今互聯網時代，?戶才是商業戰場的中心，為了快速響應用戶的需求，借助平臺化的力量可以事半功倍。

不斷快速響應、探索、挖掘、引領?戶的需求，才是企業得以?存和持續發展的關鍵因素。

那些真正尊重用戶，甚?不惜調整?己顛覆?己來響應?戶的企業將在這場以?戶為中心的商業戰爭中得以?存和發展；?反之，那些在過去的成就上故步?封，存在僥幸?理希望?戶會像之前一樣繼續追隨?己的企業則會被用戶淘汰。

很殘酷，但這就是這個時代最基本的的企業?存法則。

?平臺化之所以重要，就是因為它賦予或加強了企業在以用戶為中心的現代商業戰爭中最最最核心的能力：?戶響應力。這種能力可以幫助企業在商戰上先發制?，始終搶得先機。

可以說，在互聯網時代，商業的斗爭就是對于用戶響應力的比拼。

又有點遠大空是不是，我們來看?個經典的例子:

說起中臺，最先想到的應該就屬是阿?的“?中臺，?前臺”戰略。阿??通過多年不懈的努力，在業務的不斷催化滋養下，將?己的技術和業務能力沉淀出一套綜合能力平臺，具備了對于前臺業務變化及創新的快速響應能力。

海爾也早在?年前就已經開始推進平臺化組織的轉型，提出了“平臺?營體?撐?線?營體”的戰略規劃和轉型?標。構建了“訂單合一”、“用戶付薪” 的創客文化，真正將平臺化提?到了組織的?度。

華為在幾年前就提出了“?平臺炮火支撐精兵作戰”的企業戰略，“讓聽得到炮聲的人能呼喚到炮火” 這句話形象的詮釋了大平臺?撐下小前臺的作戰策略。這種極度靈活又威力巨?的戰法，使之可以迅速響應瞬息萬變的戰場，一旦鎖定目標，通過大平臺的炮火群，迅速精準對于戰場進行強大的火?支援。

可?，在互聯?熱火朝天，第四次工業革命的曙光即將到來的今日，企業能否真正做到“以用戶為中心”，并不斷提升自己的用戶響應力來追隨甚至引領用戶的腳步，持續規模化創新，終將決定企業能否在這樣充滿挑戰和機遇的市場上笑到最后，在商業上長久保持創新活力與競爭力。

而平臺化恰好可以助力企業更快更好的做到這些，所以這回答了第一個問題，企業需要平臺化。

第二個問題：企業為什么要建中臺？

好，想明白了第一個問題，為什么需要平臺化。但是平臺化并不是一個新概念，很多企業在這個方向上已經做了多年的努力和積淀。那為什么最近幾年“中臺”這個相對較新的概念又會異軍突起？對于企業來講，傳統的“前臺+后臺”的平臺化架構又為什么不能滿足企業的要求呢?

好，這就引出了我們的第二個問題：企業為什么要建中臺？

來，先定義一下前臺與后臺

因為平臺這個詞過于寬泛了，為了能讓大家理解我在說什么，我先定義一下本篇文章上下文下我所說的前臺和后臺各指什么：

*?前臺：由各類前臺系統組成的前端平臺。每個前臺系統就是一個用戶觸點，即企業的最終用戶直接使用或交互的系統，是企業與最終用戶的交點。例如用戶直接使用的網站，手機App，微信公眾號等都屬于前臺范疇。

*?后臺：由后臺系統組成的后端平臺。每個后臺系統一般管理了企業的一類核心資源（數據+計算），例如財務系統，產品系統，客戶管理系統，倉庫物流管理系統等，這類系統構成了企業的后臺。基礎設施和計算平臺作為企業的核心計算資源，也屬于后臺的一部分。

后臺并不為前臺而生

定義了前臺和后臺，對于第二個問題（企業為什么要建中臺），同樣先給出我的答案：

因為企業后臺往往并不能很好的支撐前臺快速創新響應用戶的需求，后臺更多解決的是企業管理效率問題，而中臺要解決的才是前臺的創新問題

大多數企業已有的后臺，要么前臺根本就用不了，要么不好用，要么變更速度跟不上前臺的節奏。

我們看到的很多企業的后臺系統，在創建之初的目標，并不是主要服務于前臺系統創新，而更多的是為了實現后端資源的電子化管理，解決企業管理的效率問題。這類系統要不就是當年花大價錢外購，需要每年支付大量的服務費，并且版本老舊，定制化困難；要不就是花大價錢自建，年久失修，一身的補丁，同樣變更困難，也是企業所謂的“遺留系統”的重災區。

總結下來就兩個字“慢”和“貴”，對業務的響應慢，動不動改個小功能就還要花一大筆錢。

有人會說了，你不能拿遺留系統說事兒啊，我們可以新建后臺系統啊，整個2.0問題不就解決了。

但就算是新建的后臺系統，因為其管理的是企業的關鍵核心數據，考慮到企業安全、審計、合規、法律等限制。導致其同樣往往?法被前臺系統直接使用，或是受到各類限制?法快速變化，以?持前臺快速的創新需求。

此時的前臺和后臺就像是兩個不同轉速的?輪，前臺由于要快速響應前端用戶的需求，講究的是快速創新迭代，所以要求轉速越快越好；?后臺由于?對的是相對穩定的后端資源，?且往系統陳舊復雜，甚至還受到法律法規審計等相關合規約束，所以往往是穩定至上，越穩定越好， 轉速也自然是越慢越好。

所以，隨著企業務的不斷發展，這種“前臺+后臺”的?輪速率“匹配失衡”的問題就逐步顯現出來。

隨著企業業務的發展壯大，因為后臺修改的成本和?險較?，所以驅使我們會盡量選擇保持后臺系統的穩定性，但還要響應用戶持續不斷的需求，自然就會將大量的業務邏輯(業務能力)直接塞到了前臺系統中，引入重復的同時還會致使前臺系統不斷膨脹，變得臃腫，形成了一個個?泥球的“煙囪式單體應用”。漸漸拖垮了前臺系統的“?戶響應?”，用戶滿意度降低，企業競爭力也隨之不斷下降。

對于這樣的問題，Gatner在2016年提出的一份《Pace-Layered Application Strategy》報告中，給出了一種解決方案，即按照“步速”將企業的應用系統劃分為三個層次（正好契合前中后臺的三個層次），不同的層次采用完全不同的策略。

而Pace-Layered Application Strategy也為“中臺”產生的必然性，提供了理論上的支撐。

Pace-Layered Application Strategy

在這份報告中Gatner提出，企業構建的系統從Pace-Layered的?度來看可以劃分為三類:?SOR(Systems of record )，SOD(Systems of differentiation)和SOI(Systems of innovation)。

處于不同Pace-Layered的系統因為?的不同，關注點不同，要求不同，變化的“速率”自然也不同，匹配的也需要采用不同的技術架構，管理流程，治理架構甚至投資策略。

?前面章節我們提到的后臺系統，例如CRM、ERP、財務系統等，它們?多都處于SOR的Pace-Layered。這些系統的建設之初往往是以規范處理企業底層資源和企業的核心可追溯單據(例如財務單據，訂單單據)為主要目的。它們的變更周期往往比較?，并且由于法律律審計等其他限制，導致對于它們的變更需要嚴謹的申報審批流程和更高級別的測試部署要求，這就導致了它們往往變化頻率低，變化成本高，變化?險高，變化周期?。無法滿足由用戶驅動的快速變化的前臺系統要求。

我們又要盡力保持后臺(SOR)系統的穩定可靠，?要前臺系統(SOI)能夠?而美，快速迭代。就出現了上文提到的”齒輪匹配失衡“的問題，感覺魚與熊掌不可兼得。

正當陷入僵局的時候，天空中飄來一聲IT諺語：

軟件開發中遇到的所有問題，都可以通過增加?層抽象?得以解決!

?此，?聲驚雷滾過，“中臺”腳踏七彩祥云，承載著SOD(Systems of differentiation)
的前世寄托，橫空出世。

我們先試著給中臺下個定義：

中臺是真正為前臺而生的平臺（可以是技術平臺，業務能力甚至是組織機構），它存在的唯一目的就是更好的服務前臺規模化創新，進而更好的響應服務引領用戶，使企業真正做到自身能力與用戶需求的持續對接。

中臺就像是在前臺與后臺之間添加的?組“變速?輪”，將前臺與后臺的速率進行匹配，是前臺與后臺的橋梁。它為前臺而生，易于前臺使用，將后臺資源順滑流向用戶，響應用戶。

中臺很像Pace-Layered中的SOD，提供了比前臺（SOI）更強的穩定性，以及?后臺（SOR）更高的靈活性，在穩定與靈活之間尋找到了?種美妙的平衡。

有了“中臺”這?新的Pace-Layered斷層，我們即可以將早已臃腫不堪的前臺系統中的穩定通用業務能力“沉降”到中臺層，為前臺減肥，恢復前臺的響應?；又可以將后臺系統中需要頻繁變化或是需要被前臺直接使用的業務能力“提取”到中臺層，賦予這些業務能力更強的靈活度和更低的變更成本，從而為前臺提供更強大的“能力炮火”支援。

所以，企業在平臺化的過程中，需要建設自己的中臺層（同時包括技術中臺，業務中臺和組織中臺）。

總結

思考并回答了文初提出的兩個關于中臺價值的核心問題，解決了我對于中臺產生的一些困惑，不知道對你有沒有啟發，讓我最后再來總結一下：

1. 以用戶為中心的持續規模化創新，是中臺建設的核心目標。企業的業務響應能?和規模化創新能力，是互聯網時代企業綜合競爭?的核心體現。平臺化包括中臺化只是幫助企業達到這個目標的階段，并不是目標本身。

2. 中臺(?論是技術中臺、業務中臺還是組織中臺)的建設根本上是為了解決企業響應?困境， 彌補創新驅動快速變化的前臺和穩定可靠驅動變化周期相對較慢的后臺之間的?盾，提供?個中間層來適配前臺與后臺的配速問題，沉淀能?，打通并順滑鏈接前臺需求與后臺資源，幫助企業不斷提升用戶響應。

3. 所以，中臺到底是什么根本不重要，如何想方設法持續提高企業對于用戶的響應?才是最重要的。?平臺化或是中臺化，只是恰巧走在了了這條正確的道路上。

---

從數據中臺到AI中臺

企業對數據的利用有三個階段：響應運營，響應業務，創造業務。數據中臺解決的是響應業務的問題，第三階段“創造業務”，則需要AI中臺。

數據中臺的意義

數據中臺對一個企業，起著至關重要的作用。在數據中臺這個稱謂成型之前，各個企業也都在用不同的方式來盡可能地利用數據產生價值。只是在這個過程中，也不得不處理著數據帶來的各種問題，比如各個業務系統經年累月以煙囪架構形式存在而導致的數據孤島、數據隔離、數據不一致等等。因為這些問題實在是過于繁雜，企業開始建立數據團隊，或者數據部分開始繼續數據整頓工作，因此數據倉庫、數據湖、主數據治理等一系列的工作職能應運而生。

本質上，這些工作都是因為業務需要不得不進行的一系列數據治理的動作，對于如何利用數據來發力，并沒有形成一個強有力的底座。有點像“頭痛醫頭、腳痛醫腳”：各個業務系統規范不一致了，于是開展了元數據治理；數據分析的時候數據關聯不上了，于是不得不進行主數據治理。

這樣的數據治理工作在進行了很多年后，數據中臺這個概念逐漸有人提出了，阿里的《企業IT轉型直到：阿里巴巴中臺戰略思想與架構實踐》這本書更是把用中臺戰略把這個概念推向了一個極致。中臺戰略中，人們常說：大中臺，小前臺。在這種模式下，頻繁出現的字眼是：共享。那么，到底共享的是什么？答案便是數據的服務。中臺戰略，并不是搭建一個數據平臺，但是中臺的大部分服務都是圍繞數據而生，更加巧妙的地方是中臺戰略讓數據在數據平臺和業務系統之間形成了一個良性的閉環。于是，數據和業務系統融為了一體。

（圖1 數據中臺所解決的問題）

過去，數據依賴于手工進行，沒有軟件；有了數據中臺，以功能驅動，固定的數據輸入，得到固定的數據輸出，構建出能用的服務變得更快速、更加的標準化，解決了業務側的“能用”問題。但是，如何以固定的輸入，以產生更靈活多變的輸出，提供比如個性化的服務，做到“好用”，數據中臺并沒有給出答案。

在建立了數據中臺架構之后，我們逐步認識到，原來數據的價值并不只是個運營出個參考的分析報表，做一系列的預算。數據中臺為大型企業數據利用最大化提供了一個初始的參照方向。當我們發現，深度學習、機器學習等等一系列技術開始在這個平臺下施展拳腳的時候，我們可能已經清晰地認識到：中臺并不是數據分析利用的終點。

企業利用數據的三個發展階段

如果回顧數據分析的歷程，可以歸納發現數據利用大概有如下三個階段：

• 響應運營

• 響應業務

• 創造業務

（圖2 企業對數據的利用，有三個發展階段）

第一階段：響應運營

響應運營是數據分析最直接也是最原始的訴求。沒有誰不不會關心自己的用戶留存率，沒有誰不關心自己的營收額；出現了故障、如何分析定位，如何預測預防，運用數據分析自然不過。但是在運營分析過程中，也發現了另外一系列的問題，比如各個業務系統的數據存儲格式、存儲介質都不相同，在進行基本的運營分析的時候，無法流暢的進行。此時，不得不進行一系列的數據治理。常見的主數據、元數據治理就是發生在這個階段，只是數據倉庫將主數據和元數據治理進行了規范化。

第二階段：響應業務

數據分析停留在運營階段的時候，對企業來講最大的感受就是投入產出比不對稱。這個問題在大數據爆發的時間點上，更為凸顯。例如在今天的業務場景下，傳統的數據倉庫已經解決不了海量數據、異構數據等一系列問題，而大行其道的大數據分析技術，硬件要求高、學習門檻高。要實施一個大數據平臺，成立一個大數據團隊，這是一個不小的成本開銷，更何況現在有不少數據分析團隊要借助機器學習等手段，來對數據做分析來響應運營，這導致基礎設施成本、整體門檻進一步提高。

于是像數據中臺這樣的思想就被提了出來：既然數據是從業務系統產生的，那么是否業務系統也需要數據分析結果呢？對于數據平臺來說，數據平臺本身提供兩大能力：數據存儲和數據計算的能力。那么業務系統的數據存儲和數據計算能力是否可以剝離到數據平臺，僅僅讓業務系統很輕量的維護自己的業務流程操作？所以利用中臺剝離了復雜的業務環境，再配合微服務等技術，一下子讓人感受到了“數據服務的共享”。

而對業務場景來說，很多時候是需要數據服務的，例如用戶的基本信息管理、用戶的行為數據分析，這些數據不但可以暴露給業務系統使用，甚至可以直接丟給終端用戶自行使用。類似這種契合點，讓數據平臺變成了一個服務，提供給業務系統。而對數據服務的使用者來說，在消費數據的同時也在繼續產生數據，這樣在數據平臺和業務系統之間就構成了一個良性的閉環。

第三階段：創造業務

業務不會總停滯不前，因為人的生活會改變，想要的體驗會改變。過去，大家到視頻平臺看視頻，利用通用的數據服務，不同的用戶看到的視頻推薦都是一樣的；很快，我們就會發現根據用戶的偏好，推薦個性化的視頻幾乎是必不可少的體驗要求。然后，我們就開始思考：數據是否可以變成個性化服務提供給終端用戶？這是一個非常簡單、常見的例子。當這樣的個性化數據服務越來越多之后，各種服務不斷組合，就會創造出很多可能性，進而提供創新的個性化體驗和新的業務模式，這就是數據服務用于創造業務的階段。

雖然有了數據中臺，但是當有大規模的、基于智能算法的數據服務需要落地實現時，依然會碰到以下挑戰。

• 如何對規模化的智能服務進行管理：當只是零星三兩個智能服務的時候，通過手動人工管理等方式，不會有太大的問題；然則，當智能服務成千上萬的時候，如何管理、如何構建、如何高效維護，就會成為很大的麻煩。

• 沒有良好的工程實踐來保證質量和流暢性：對于常規的應用軟件開發我們有TDD、自動化測試、CI/CD等成熟的工程實踐做保障；但是在智能服務這一塊，無論是編程開發、還是服務構建，都沒有成熟的工程實踐，也沒有良好的基礎設施支撐，非常依賴于構建這個服務的數據工程師的個人能力，導致在實施過程中，問題難以復現，難于定位。

• 數據安全、治理和數據量不充分：數據中臺的價值點，在于提供了數據的計算和存儲的能力，但是在智能服務構建下，光有計算和存儲還不夠。治理到什么程度的數據，才能較好的支撐服務的構建？個性化的服務與數據安全沖突的時候，如何抉擇？數據量不足導致算法模型泛化能力太差，怎么辦？

（圖3 創造業務階段，數據中臺面臨的挑戰）

從數據中臺到AI中臺

什么是AI中臺？

數據中臺本身還是圍繞數據服務來進行的，而非圍繞智能服務來進行的。未來的操作系統，一定會越來越個性化，甚至每一個人看到的登錄界面都不一樣，系統可以根據對應的終端用戶自行呈現符合該用戶習慣的系統界面。那么對于這樣的場景和服務，我們需要怎樣的平臺？整個軟件開發架構和流程是否也都會相應重造？

回到創造業務的需求。以簡單的銷售業務為例，數據中臺提供的服務本質如下圖所示：

（圖4 軟件平臺的業務模式）

這是目前最常見的軟件平臺的運作方式，開發人員開發出了對應的軟件服務后，提供給終端用戶使用，雖然會有銷售售賣該服務。這種方式，好比是拿著一個錘子找釘子，而不是給釘子快速制作一把合適的錘子再去售賣。

能不能這樣：將整個軟件組裝出來的服務，包裝成個性化的產品一樣去售賣，提供量身定做的服務？那么整個運營模式就變成：平臺提供了一種快速構建智能服務的過程，服務售賣者利用這個平臺，自己動手構建出服務，拿出去售賣，類似一個提供“智能業務服務的PaaS”。

（圖5 引入AI中臺的軟件平臺業務模式）

如果嘗試給AI中臺下個定義：

AI中臺是一個用來構建大規模智能服務的基礎設施，對企業需要的算法模型提供了分步構建和全生命周期管理的服務，讓企業可以將自己的業務不斷下沉為一個個算法模型，以達到復用、組合創新、規模化構建智能服務的目的。

借助一個平臺，將軟件的服務個性化的創造，這將是未來的發展趨勢。在麥肯錫的分析報告中，我們可以看到，各個企業或者行業，都在第三個階段做了不同的探索和努力。

從數據中臺演進到AI中臺

從AI中臺落地實施的方式來看，AI中臺可以是數據中臺的進一步延伸，從數據中臺一步一步演進過去。

首先，從基礎設施角度，可以將數據中臺智能化

所謂的智能化，是指將在數據中臺進行的一系列的數據服務構建操作進行智能化實現，讓數據的接入、存儲、分析展現、訓練、到構建管道（pipeline）都更加自動化。例如，對于通用的CI/CD來說，測試不過則會構建失敗，那對于AI中臺下，就要考慮一個推薦模型構建失敗的條件是什么？答案可能是“本次模型的準確率低于上一次構建的準確率”的時候，CI應該被構建失敗。在實踐中，這可能是CI構建過程的維度之一，還會有很多其他指標和維度。我們就需要在現有的數據平臺的CI中，實現并自動化這些指標和維度，使之更加智能化。

其次，對于中臺使用者來說，將煙囪式模型構建過程改造為可復用的模型構建過程

目前基于數據中臺的一個智能服務模型開發來說，流程如下：

（圖6 煙囪式模型構建過程）

這基本類似于一個橫向的煙囪架構，導致目前對一個基于算法模型產生的服務進行拆分的時候，都不是特別地順暢。如果大部分業務場景依舊以流程為主還好，如果新業務需要引入多的智能服務，那么一系列的問題就會暴露出來：

• 借助于現有數據平臺手工進行數據操作

• 煙囪架構開發，對人員能力要求高

• 環節無法有效拆分，響應周期慢

• 智能場景規模化，管理復雜

• 訓練，部署，發布依賴于手工部署缺乏有效的流水線

• 和數據平臺孤立，缺乏統一的數據服務接口

• 基礎設施隔離，無法動態進行資源的分配和管理

AI中臺需要具備構建智能服務的能力，就要求我們對服務構建的過程進行如下拆分：

（圖7 可復用的模型構建過程）

首先需要從基礎設施層面進行集成。常規的數據中臺依賴于大量的CPU和內存，相反，機器學習模型對GPU的依賴反而更高，但是又不能脫離數據中臺，因為它依舊需要利用數據中臺的存儲和計算能力來處理大量的數據。所以如何通過一個接口、一個調度器、一個管道pipeline來集成整個工作流，就成了需要考量的事情了。

AI中臺至少應該分為以下幾個層級：

• 基礎設施：對CPU做虛擬化的技術已經相對成熟，但是智能服務依賴的更多的是GPU，那么GPU如何做虛擬化，算法模型訓練和數據是否需要共同使用相同的機器，還是集群相互隔離，都是需要在一開始設計好的。

• 資源管理：一切都是資源，無論是網絡、內存，還是數據、服務，都是資源。對于模型構建者，關注的只是算法本身，如果該構建者需要數據，那這樣的數據就是一個資源而已，無論資源是以環境變量的方式提供、還是以服務的方式提供，構建者本身并不需要關心。此時，必須一個資源管理系統，對數據服務進行統一管理。

• 中臺和模型：中臺有數據的計算和存儲能力外，還應該具備算模型的能力，這里的模型指的是一些業界通用的、或者企業級通用算法模型。它可能是一個算法、可能是一個別人已訓練好的模型，可以使用遷移學習的方式去使用。對于中臺來說，它都是一個數據集的體現，不應該和一個表，一個文件有特別的區分。

• 流水線：流水是構建規模化智能服務非常重要的一個環節，工作如其名，讓我們構建智能服務的時候，可以像流水線工作一樣，達到這樣的效果，則需要對整個任務進行非常詳細的分解。

• 智能應用層：智能應用層直接面向終端，怎么利用元數據等功能，組合各自不同模型提供的服務，構建出組合效應的創新服務。

（圖8 AI中臺的架構層次）

在數據中臺的基礎上，擴展對GPU級別資源的管理和整合能力，調度層提供統一的任務、服務、智能CI/CD等服務，來實現AI中臺。這樣以來，就可以達到：

• 和數據平臺結合，利用數據平臺的能力作為數據支撐，最大化的發揮數據平臺的價值

• 拆分服務構建環節，智能服務開發流程化，快速響應業務需求

• 利用元數據管理方式，提供統一的標準格式，場景可以多人協同配合開發

• 基礎設施共享化，模型的訓練和發布與數據平臺有效綁定，服務的構建自動化

• 統一的元數據管理系統，模型的全生命周期可管理

• 通用AI能力平臺化，降低人員要求，提升協作效率

也即，利用算、模型、框架，動態、快速地組裝服務，創造出新的個性化體驗和新的業務新的業務模式，解決“好用”的問題。

結語

數據中臺提供的是存儲和計算的能力，基于不同的業務場景，構建出了用來支撐不同業務的數據服務，依托于強大的計算力，可以快速縮短獲得結果的周期。而AI中臺則是將算法模型融入進來構建為服務，讓構建算法模型服務，更加快速高效，以更加面向業務。但無論是數據中臺還是AI中臺，都是一層基礎設施，做好基礎設施只是第一步，如何讓它的價值最大化，還要依托于AI中臺不斷結合業務來持續優化，做到“持續智能”。