從0到1搭建AI中台

来源:https://www.cnblogs.com/shuzhiwuyu/archive/2019/04/08/10670957.html
-Advertisement-
Play Games

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


 

文章發佈於公號【數智物語】 (ID:decision_engine),關註公號不錯過每一篇乾貨。

 

 

 

轉自 | 宜信技術學院

作者 | 井玉欣  

 

 

導讀:隨著“數據中台”的提出和成功實踐,各企業紛紛在“大中台,小前臺”的共識下啟動了自己的中台化進程,以數據中台、技術中台、業務中台為代表的一系列技術,極大增強了業務的敏捷性,提高了組織效能。同時隨著智能技術的發展,AI應用在業務研發中的占比逐漸升高,但AI模型訓練的複雜性導致其開發慢、效率低,嚴重影響了業務的靈活性。

 

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

 

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

 

分享大綱:

一、AI中台的提出

二、AI中台的目標和定義

三、AI中台的實施路線

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

五、總結

六、Q&A

 

 

01AI中台的提出

 

1.1 中台戰略的興起

 

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

 

 

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

 

 

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

 

 

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

 

1.2 智能業務需求的中台化

 

 

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

 

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

 

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

 

 

上圖是一個示例,數據來源於Roland Berger。從圖中可以看到在金融這一個領域之內就有這麼多環節已經形成了標準化的智能應用,可想而知在今天企業業務的發展過程中智能化正在扮演一個多麼重要的角色。

 

 

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

 

 

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

 

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

 

1.3 從數據中台到AI中台

 

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

 

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

 

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

 

1.3.1 從狹義人工智慧的兩個領域說起

 

 

詳細來說,我們可以從目前人工智慧(AI)所涵蓋的內容進行分析。廣義上人工智慧指利用科學方法和技術,研製能夠模仿、延伸、擴展人類智能的機器系統,涉及了電腦科學、數學、哲學、心理學等多門學科;

 

而從電腦科學的角度狹義來看,人工智慧特指可以接受和處理外部數據,並能夠做出類人化分析、決策的電腦系統,涵蓋了數據挖掘、機器學習、深度學習、強化學習等多個子領域。如無特殊說明,本文所述人工智慧皆指後者。

 

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

 

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

 

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

 

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

 

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

 

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

 

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

所採用演算法和模型結構有可能相同,但都需要根據業務數據進行個性化參數訓練;

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

除部分非監督學習外,實施環節通常需要人工標註環節的參與;

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

 

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

 

1.3.2 數據中台能否支持所有的AI需求

 

 

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

 

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

 

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

 

那麼我們要怎麼做呢?將AI中台與數據中台進行分離。

 

1.3.3 AI中台與數據中台的分離

 

 

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

 

1.3.4 AI中台與數據中台的分離結構圖

 

 

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

 

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

 

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

 

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

 

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

 

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

 

02AI中台的目標與定義

 

前文通過對智能化業務需求和數據中台的分析解釋了建設AI中台的背景和原因,但AI中台的目標究竟是什麼?其基本要求和能力有哪些?接下來我們將對此進行詳細討論。

 

2.1 AI任務劃分與敏捷需求

 

2.1.1 AI項目的敏捷化需求:兩類不同任務

 

 

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

 

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

 

這裡我們採用另一種劃分方式,認為所有的AI任務都可以劃分成為兩類:

 

一種是針對某個業務領域內特定類型數據,提供對此類數據的基礎AI學習、預測、分析能力的“橫向”任務,例如電腦視覺、自然語言處理任務等;

 

另一種則是面向業務具體需求的、相對特殊化與個性化的“縱向”任務,例如金融領域的智能風控、電商領域的產品推薦以及比較常見的用戶畫像構建等。

 

就這兩類AI任務來說,無論哪類任務都可以獨立對外服務,也可以混合起來相互之間集成、組合,形成AI解決方案來支持更複雜的業務場景。我們構建智能化業務應用的核心就是將智能化需求分解、映射為具體的AI任務並一一實現,最後再進行合理地編排組合,實現任務目標。

 

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

 

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

 

 

由於業務領域內數據的通用性,我們完全可以預訓練出一套常用的業務領域專用橫向AI模型,例如金融業務領域內的通用自然語言理解模型等。這樣我們只需維護、更新這套模型,該領域內的所有智能化相關需求都可以隨時地復用該模型庫,從而節省大量的任務訓練時間。

 

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

 

因此,橫向的基礎性AI任務本身能夠通過提升模型的通用性、可復用性來敏捷支撐智能化業務需求,一個基本的AI共用服務平臺(或者說我們希望構建的AI中台)應該為其提供一個方便的可復用解決方案設計與自動展開結構,完善的模型庫、演算法庫管理系統,以及穩定的模型運行環境等。

 

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

 

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

 

 

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

 

在目前大多數縱向任務項目中,由於需求的不同,演算法團隊每次都會依次經曆數據獲取、處理、分析、建模、標註,模型訓練、調優、驗證、部署、監控、更新等一系列環節;

 

而每個環節內還有自己的複雜性,如數據接入管理、特征工程的開展、標註過程的人工介入、訓練調優的反覆迭代等;

 

此外,整個環節還有眾多角色的介入,如數據分析師、演算法工程師、標註工程師、業務分析師等,對角色的管理同樣複雜。

 

所以針對這類複雜任務問題的研究重點就在於其全生命周期的科學化管理,以及研發流程和每個環節的優化。通過對研發過程中各環節的拆分,我們能夠在一定程度上優化任務編排順序,清楚定位各環節參與角色,通過任務並行與角色協作縮短時間開銷;而對於每個環節或局部環節的深入探討,可以抽象出自動化操作和可復用的流程,進一步提高業務響應速度。

 

2.1.2 兩種任務的敏捷需求

 

 

此外,不管橫向任務還是縱向任務,兩者對AI中台都有一些共同的基本需求。

 

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

 

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

 

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

 

綜上,我們可以基於前文對兩類AI任務的分析,對AI中台究竟要做什麼,應具備什麼能力進行一下總結。

 

2.2 AI中台的目標與能力

 

2.2.1 歸納:AI中台應解決的痛點

 

 

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

 

“煙囪式”開發,項目成本高、不易集成,過程重覆,缺乏能力沉澱;

研發環節繁多,缺少優化、協同、自動化輔助,業務響應緩慢;

模型研發缺乏標準指導,服務介面混亂,難以維護管理;

缺少統一的數據訪問渠道,數據獲取難、標準不一致,重覆的數據預處理與特征工程;

缺少統一的模型運行、監控平臺,以及更新、維護機制;

基礎資源分散管理,未得到充分利用,造成浪費。

 

 

以上問題普遍存在,可以說現在的許多演算法研發團隊更像是演算法外包團隊,根據不同業務部門的需求各自構建陣地,逐步攻剋目標,過程重覆、效率有限。而AI中台則努力提供一個強大的AI能力支持中心,根據業務需要快速提供火力支援,迅速達成目的。所以,AI中台應具備的能力包括:

 

多層次可復用。對於演算法、模型的標準化研髮指導,以及可復用服務封裝能力;

服務統一化。統一的服務介面規範,支持服務的動態編排組合;

流程角色優化。研發流程拆分優化,清晰的研發角色定義,支持任務並行與角色協作,構建AI產品研發流水線;

自動化迭代。具備研發環節內部、環節之間的自動化迭代、流轉功能;

對接數據平臺。數據中台或其他基礎數據服務對接,迅速接入標準化數據,乃至預處理數據;

運行監控。提供統一的模型運行環境和監控能力,以及模型更新機制;

資源管控。統一資源管理,包括計算資源、存儲資源等,支持資源彈性調度。

 

結合上述能力,我們針對AI中台給出一個探討性的定義:

 

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

 

03AI中台的實施路線

 

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

 

3.1 AI中台的主要成分

 

3.1.1 AI產品研發生命周期

 

 

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

 

3.1.2 AI中台主要成分

 

 

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

 

業務理解,根據業務需求設計實施方案,服務編排,通用方案模板管理;

數據處理,包括數據獲取和數據準備與分析;

模型學習,包括特征工程、模型訓練和模型評估,以及可復用模型庫、演算法庫管理;

運行監控,包括模型自動部署運行、性能監控和對外服務介面管理。

此外,為了便於對AI中台進行角色、許可權統一控制和資源管控,我們還設置了中台管理模塊。

 

3.2 從平臺到中台的構建

 

構建數據中台時我們一般會採用從平臺到中台演進的策略,AI中台的構建也是如此。

 

3.2.1 常見機器學習相關平臺

 

 

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

 

3.2.2 從平臺到中台

 

 

我們可以根據現有平臺完成AI中台的構建。

 

建模平臺具備業務建模、服務/模型建模的功能,可用於業務理解和模型學習的環節;

 

訓練平臺具備模型自動化訓練優化評估功能,可用於模型學習環節;

 

數據處理環節需要進行數據分析、樣本分析,可以用到數據處理平臺和標註平臺;

 

而部署/運行平臺和監控平臺可為運行監控環節提供支持。由此可見,我們能夠根據現有平臺完成AI中台的構建。

 

3.2.3 AI中台能力層次

 

 

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

 

不論企業還是AI訓練團隊,最早都是從基礎設施出發,包括數據接入、高性能計算資源、運行環境資源等;

 

然後在保障穩定的基礎之上獲得訓練工具,包括模型訓練追蹤能力、演算法框架支持能力等,實現過程的自動化;

 

有了訓練工具的支撐,我們可以把常用的業務和環節進行聚攏和集中配置,形成AI平臺,包括模型/服務結構可配置化、模型演算法可復用化等,形成標準化的AI研發過程;

 

AI中台實際上是對現有能力進行整合串聯,實現生命周期的管理,包括服務編排共用能力、方案可復用能力、全流程管理能力等,在標準之上實現提效,達到高效的目的。

 

3.2.4 AI中台能力與成分映射,平臺映射

 

 

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

 

值得註意的是,這裡我們只列出了部分中台能力,根據中台對業務的支持需要還可能會包含其他能力,需要我們去建設;此外,平臺對中台的支持也是有限的,缺乏的功能或不全面的功能都要我們去豐富。

 

3.3 AI中台的流程及架構

 

3.3.1 AI中台主要功能組件

 

 

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

 

業務理解部分包括方案模板管理、方案設計、服務編排、服務共用等;

數據處理部分包括數據展示、數據訪問、數據分析、數據標註等;

模型學習部分包括服務設計、特征處理、模型訓練、模型追蹤、模型庫、演算法庫等;

運行監控部分包括具體的產品封裝、自動部署、性能監控、訪問介面管理、模型更新和發佈測試等;

中台管理部分包括角色許可權、資源管理、租戶管理和流程式控制制等。

 

3.3.2 總體運轉流程

 

 

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

 

從業務需求開始,對業務進行理解,包括方案模板參考、方案設計、服務編排、服務共用等,如果需要復用其他服務,可以在這裡進行訪問配置;

數據處理部分的工作通過數據中台來完成,數據中台向上提供數據參考、向下提供模型訓練及監控的支持;

模型訓練部分形成比較複雜的迴圈,因為其本身就是一個自動化迭代的過程;

封裝部分涉及到監控和對外提供訪問介面等功能;

中台管理在底部提供構建支持。

 

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

 

3.3.3 業務理解中心:

 

 

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

 

業務需求進來之後,先從數據處理中心獲取數據分析和參考,採集數據樣本提供可視化支持;

然後進行方案選擇:是否具備可復用的方案模板?“是”即直接復用方案,只需改變數據;“否”即進行方案設計。

接下來是分解方案到各個服務中,並對服務進行合理有效的編排。此處還需考慮哪些服務可供復用;

最後輸出三個方面的內容:向數據處理中心輸出數據獲取要求;向運行監控中心輸出產品封裝指導;向模型學習中心輸出模型訓練任務。

 

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

 

業務分析師,分析相關方案設計、服務編排;

數據分析師,提供數據建議、方案設計建議;

演算法工程師,考慮服務編排、服務之間的數據介面等。

 

3.3.4 數據處理中心:

 

 

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

 

從業務處理中心獲取數據要求規範,通過數據訪問對接數據中台;

基於數據中台向上提供數據分析功能、數據展示及功能可視化;

通過數據展示獲得參考,對數據進行標註;

操作數據訪問,返回到數據中台,對數據進行重新加工。

最後對對外輸出三個方面的內容:向業務理解中心輸出數據分析參考;向模型學習中心輸出模型訓練數據;向運行監控中心輸出生產數據。

 

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

 

數據分析師,要求對其中主要環節都有涉獵;

業務分析師和演算法工程師主要關註數據展示;

標註工程師,主要參與數據標註環節。

 

3.3.5 模型學習中心:

 

 

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

 

接收來自業務理解中心的模型服務任務、數據處理中心的訓練數據、運行監控中心的性能矯正信息,進行服務設計。服務設計時要考慮需要多少個模型?模型之間如何串聯?演算法庫和模型庫中是否有可供復用的演算法與模型?

服務流程設計完成後進行特征處理;

將特征輸入模型進行編碼和訓練;

將模型訓練結果輸入模型追蹤的功能組件進行模型評估;

經過迭代獲得最優訓練模型輸出到運行監控中心,同時輸出數據操作到數據處理中心。

 

3.3.6 運行監控中心:

 

 

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

 

接收數據處理中心提供的生產數據,通過訪問介面處理輸出,寫回到數據處理中心;

接收模型學習中心的已訓練模型服務、業務理解中心的產品封裝指導,對產品服務進行串聯封裝、部署、發佈、測試;(如果要封裝的產品是對已有產品的更新,則先通過模型更新機制對現有模型進行合理啟停更新操作之後再部署發佈測試。)

向上將交互數據提供給訪問介面,並對訪問介面進行配置;向下提供性能指標給性能監控,如果發現問題及時報警,並反饋到模型學習中心進行重新訓練。

 

3.3.7 AI中台層級架構:

 

 

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

 

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

 

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

 

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

 

4.1 智能投顧機器人

 

 

智能投顧是通過人工智慧演算法,線上提供自動化的資產組合配置建議和財富的管理服務。

 

 

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

 

智能交互,比如聊天機器人;

客戶畫像,對於已有客戶積累的公司來說這部分數據已經具備;

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

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

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

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

 

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

 

4.2 案例實施

 

4.2.1 業務理解

 

 

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

 

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

 

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

 

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

 

4.2.2 模型學習

 

 

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

 

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

 

 

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

 

4.2.3 運行監控

 

 

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

 

 

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

 

4.2.4 數據處理

 

 

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

 

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

 

05總結

 

 

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

 

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

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

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

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

 

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

 

推薦閱讀:

鏈接圖片.png

 


您的分享是我們最大的動力!

-Advertisement-
Play Games
更多相關文章
  • DNS服務 DNS:Domain Name Service //協議 實現:BIND(Berkeley Internet Name Domain) 監聽埠: UDP:53 TCP:53 名稱解析:將一種格式的信息轉化為另外一種格式,以某關鍵字為標準查找某一資料庫的過程passwd <--> nss ...
  • 驅動問題,名為“Insyde Airplane Mode HID Mini-Driver”的驅動,這個驅動是專門用來快捷管理飛行模式的。 卸載完成後重啟,無限開關飛行模式問題得到解決! ...
  • 用戶進程的記憶體頁分為兩種: file backed pages(文件背景頁) anonymous pages(匿名頁) 比如進程的代碼段、映射的文件都是file backed,而進程的堆、棧都是不與文件相對應的、就屬於匿名頁。 file backed pages在記憶體不足的時候可以直接寫回對應的硬碟 ...
  • 問題描述:在升級Exchange 2013 CU22檢查群集節點狀態的過程中發現群集組處於失敗狀態,具體報錯信息如下:警告:資料庫可用性組”***”見證處於失敗狀態。資料庫可用性組要求見證伺服器保持仲裁。請使用 set-DatabaseAvailabilityGroup cmdlet重新創建此見證服... ...
  • 在之前寫過一篇博客"關係資料庫如何快速查詢表的記錄數",裡面介紹了使用sp_spaceused查看表的記錄數是否正確的問題,具體如下: 關於問題3:有多個索引的表,是否記錄數會存在不一致的情況? 答案:個人測試以及統計來看,暫時發現多個索引的情況下,sys.partitions中的rows記錄數都是... ...
  • windows系統無法改成 lower_case_table_names=0, 因為windows預設是1,就算改也只能改成2,以下截自 MySQL 8.0 Reference Manual 然後,當我們按照網上方法把 my.ini中的lower_case_table_names強行改成2之後,會發 ...
  • 相信大家在很多實際業務中(特別是後臺系統)會使用到各種篩選條件來篩選結果集 首先添加測試數據 1.有使用EXEC來避免全表掃描 或者條件少的情況下 2.使用IS NULL來實現 第一種方案,不會破壞索引,但冗餘的代碼看起來讓人難受 第二種方案,會導致全表掃描(破壞索引) 以上是網上查閱的資料,方案二 ...
  • 每一個資料庫都有自己的數據類型。同樣子redis為我們提供了五種類型的數據——字元串、哈希、列表、集合、有序集合。我們知道關係型數據的數據存放型式是一張二維表。用行和列來表示數據之間的關係。redis是一個nosql資料庫當然不可能在用什麼二維表的形式來表示了。他所有的數據都是以key=value的 ...
一周排行
    -Advertisement-
    Play Games
  • 移動開發(一):使用.NET MAUI開發第一個安卓APP 對於工作多年的C#程式員來說,近來想嘗試開發一款安卓APP,考慮了很久最終選擇使用.NET MAUI這個微軟官方的框架來嘗試體驗開發安卓APP,畢竟是使用Visual Studio開發工具,使用起來也比較的順手,結合微軟官方的教程進行了安卓 ...
  • 前言 QuestPDF 是一個開源 .NET 庫,用於生成 PDF 文檔。使用了C# Fluent API方式可簡化開發、減少錯誤並提高工作效率。利用它可以輕鬆生成 PDF 報告、發票、導出文件等。 項目介紹 QuestPDF 是一個革命性的開源 .NET 庫,它徹底改變了我們生成 PDF 文檔的方 ...
  • 項目地址 項目後端地址: https://github.com/ZyPLJ/ZYTteeHole 項目前端頁面地址: ZyPLJ/TreeHoleVue (github.com) https://github.com/ZyPLJ/TreeHoleVue 目前項目測試訪問地址: http://tree ...
  • 話不多說,直接開乾 一.下載 1.官方鏈接下載: https://www.microsoft.com/zh-cn/sql-server/sql-server-downloads 2.在下載目錄中找到下麵這個小的安裝包 SQL2022-SSEI-Dev.exe,運行開始下載SQL server; 二. ...
  • 前言 隨著物聯網(IoT)技術的迅猛發展,MQTT(消息隊列遙測傳輸)協議憑藉其輕量級和高效性,已成為眾多物聯網應用的首選通信標準。 MQTTnet 作為一個高性能的 .NET 開源庫,為 .NET 平臺上的 MQTT 客戶端與伺服器開發提供了強大的支持。 本文將全面介紹 MQTTnet 的核心功能 ...
  • Serilog支持多種接收器用於日誌存儲,增強器用於添加屬性,LogContext管理動態屬性,支持多種輸出格式包括純文本、JSON及ExpressionTemplate。還提供了自定義格式化選項,適用於不同需求。 ...
  • 目錄簡介獲取 HTML 文檔解析 HTML 文檔測試參考文章 簡介 動態內容網站使用 JavaScript 腳本動態檢索和渲染數據,爬取信息時需要模擬瀏覽器行為,否則獲取到的源碼基本是空的。 本文使用的爬取步驟如下: 使用 Selenium 獲取渲染後的 HTML 文檔 使用 HtmlAgility ...
  • 1.前言 什麼是熱更新 游戲或者軟體更新時,無需重新下載客戶端進行安裝,而是在應用程式啟動的情況下,在內部進行資源或者代碼更新 Unity目前常用熱更新解決方案 HybridCLR,Xlua,ILRuntime等 Unity目前常用資源管理解決方案 AssetBundles,Addressable, ...
  • 本文章主要是在C# ASP.NET Core Web API框架實現向手機發送驗證碼簡訊功能。這裡我選擇是一個互億無線簡訊驗證碼平臺,其實像阿裡雲,騰訊雲上面也可以。 首先我們先去 互億無線 https://www.ihuyi.com/api/sms.html 去註冊一個賬號 註冊完成賬號後,它會送 ...
  • 通過以下方式可以高效,並保證數據同步的可靠性 1.API設計 使用RESTful設計,確保API端點明確,並使用適當的HTTP方法(如POST用於創建,PUT用於更新)。 設計清晰的請求和響應模型,以確保客戶端能夠理解預期格式。 2.數據驗證 在伺服器端進行嚴格的數據驗證,確保接收到的數據符合預期格 ...