一、AI的“iPhone”時刻

在過去的一年中，大模型的發(fā)展非常迅速，算力和數(shù)據(jù)的堆疊使模型具備了一些通用的構(gòu)造和回答問題的能力，引領人們進入了一直夢想的人工智能階段。舉個例子，在與大語言模型聊天時，會感覺面對的不是一個生硬的機器人，而是一個有血有肉的人。它為我們開啟了更多的想象空間。原來的人機交互，需要通過鍵盤鼠標，通過一些格式化的方式告訴機器我們的指令。而現(xiàn)在，人們可以通過語言來與計算機交互，機器能夠理解我們的意思，并做出回應。

為了跟上潮流，很多科技公司都開始投身于大模型的研究。2023 是AI的元年，就像曾經(jīng) iPhone 的問世開啟了移動互聯(lián)網(wǎng)的元年，真正的突破是大算力和大數(shù)據(jù)的應用。

從模型結(jié)構(gòu)上來看，Transformer 結(jié)構(gòu)其實已經(jīng)推出很久了。事實上，GPT 模型比 Bert 模型更早一年發(fā)表，但是由于當時算力的限制，GPT 的效果遠遠不如 Bert，所以 Bert 先火起來，被用來做翻譯，效果非常好。但是今年的焦點已變?yōu)?GPT，其背后的原因就是因為有了非常高的算力，因為硬件廠商的努力，以及在封裝和存儲顆粒上的一些進步，使得我們有能力把非常高的算力堆疊在一起，推動對更多數(shù)據(jù)的深入理解，帶來了AI的突破性成果。正是基于底層平臺的強有力支撐，算法同學可以更方便、高效地進行模型的開發(fā)和迭代，推動模型快速演進。

二、模型開發(fā)范式

一般的模型開發(fā)周期如下圖所示：

很多人認為模型訓練是其中最關鍵的一步。但其實在模型訓練之前，有大量的數(shù)據(jù)需要采集、清洗、管理。在這個過程中，可以看到有非常多的步驟需要驗證，比如是不是有臟數(shù)據(jù)，數(shù)據(jù)的統(tǒng)計分布是不是具有代表性。在模型出來之后，還要做模型的測試和驗證，這也是數(shù)據(jù)的驗證，通過數(shù)據(jù)來反饋模型效果如何。

更好的機器學習是 80% 的數(shù)據(jù)加 20% 的模型，重心應該在數(shù)據(jù)這一塊。

這也反映了模型開發(fā)的演進趨勢，原來的模型開發(fā)是以模型為中心，而現(xiàn)在則變?yōu)橐詳?shù)據(jù)為中心。

深度學習出現(xiàn)的初期，以有監(jiān)督學習為主，最重要的是要有標注的數(shù)據(jù)。標注的數(shù)據(jù)分為兩類，一類是訓練數(shù)據(jù)，另一類是驗證數(shù)據(jù)。通過訓練數(shù)據(jù)，讓模型去做訓練，然后再去驗證模型是否能在測試數(shù)據(jù)上給出很好的結(jié)果。標注數(shù)據(jù)成本是非常高的，因為需要人去標注。如果想要提高模型的效果，需要將大量的時間和人力花費在模型結(jié)構(gòu)上面，通過結(jié)構(gòu)的變化提高模型的泛化能力，減少模型的 overfit，這就是以模型為中心的開發(fā)范式。

隨著數(shù)據(jù)和算力的積累，逐漸開始使用無監(jiān)督的學習，通過海量的數(shù)據(jù)，讓模型自主地去發(fā)現(xiàn)這些數(shù)據(jù)中存在的關系，此時就進入了以數(shù)據(jù)為中心的開發(fā)范式。

在以數(shù)據(jù)為中心的開發(fā)模式下，模型結(jié)構(gòu)都是類似的，基本上都是 Transformer 的堆疊，因此更關注的是如何利用數(shù)據(jù)。在用數(shù)據(jù)的過程中會有大量的數(shù)據(jù)清洗和比對，因為需要海量的數(shù)據(jù)，所以會耗費很多時間。如何精細地控制數(shù)據(jù)，決定了模型收斂和迭代的速度。

三、大數(shù)據(jù)AI一體化

1.大數(shù)據(jù)AI全景

阿里云一直強調(diào)AI和大數(shù)據(jù)的融合。因此我們構(gòu)建了一套平臺，它具備非常好的基礎設施，包括通過高帶寬的 GPU 集群提供高性能AI算力，以及 CPU 集群提供高性價比的存儲和數(shù)據(jù)管理能力。在此之上，我們構(gòu)建了大數(shù)據(jù)AI一體化 PaaS 平臺，其中包括大數(shù)據(jù)的平臺、AI 的平臺，以及高算力的平臺和云原生的平臺等等。引擎部分，包括流式計算、大數(shù)據(jù)離線計算 MaxCompute 和 PAI。

在服務層，有大模型應用平臺百煉和開源模型社區(qū) ModelScope。阿里一直在積極推動模型社區(qū)的共享，希望以 Model as a service 的理念去激發(fā)更多有AI需求的用戶，能夠利用這些模型的基礎能力，快速組建AI應用。

2.為什么需要將大數(shù)據(jù)和AI結(jié)合

下面通過兩個案例，來解釋為什么需要大數(shù)據(jù)與AI的聯(lián)動。

案例 1：知識庫檢索增強的大模型問答系統(tǒng)

在大模型問答系統(tǒng)中，首先要用到基礎模型，然后把目標的文檔進行 embedding 化，并將 embedding 化的結(jié)果存在向量數(shù)據(jù)庫中。文檔的數(shù)量可能會非常大，因此 embedding 化時需要批處理的能力。本身基礎模型的推理服務也是很耗資源的，當然這也取決于用多大的基礎模型，以及如何并行化。產(chǎn)生的所有 embedding 灌入到向量數(shù)據(jù)庫中，在查詢時，query 也要經(jīng)過向量化，然后通過向量檢索，把可能跟這個問答有關的知識從向量數(shù)據(jù)庫里面提取出來。這需要非常好的推理服務的性能。

提取出向量后，需要把向量所代表的文檔作為 context，再去約束這個大模型，在此基礎上做出問答，這樣回答的效果就會遠遠好于自己搜索方式得到的結(jié)果，并且是以人的自然語言的方式來回答的。

在上述過程中，既需要有離線的分布式大數(shù)據(jù)平臺去快速產(chǎn)生 embedding，又需要有對大模型訓練和服務的AI平臺，將整個流程連起來，才能構(gòu)成一個大模型問答系統(tǒng)。

案例 2：智能推薦系統(tǒng)

另一個例子就是個性化推薦，這個模型往往需要很高的時效性，因為每個人的興趣和個性都會發(fā)生變化，要捕獲這些變化，需要用流式計算的系統(tǒng)對 APP 內(nèi)獲取到的數(shù)據(jù)進行分析，然后通過提取的特征，不停地讓模型 online learning，每當有新的數(shù)據(jù)進來時，模型就會更新，隨后通過新的模型去服務客戶。因此，在這個場景中，需要有流式計算的能力，還需要有模型服務和訓練的能力。

3.如何將大數(shù)據(jù)與AI結(jié)合

通過以上案例可以看到AI與大數(shù)據(jù)相結(jié)合已成為必然的發(fā)展趨勢。在此理念基礎之上，首先需要有一個工作空間，能夠?qū)⒋髷?shù)據(jù)平臺和AI平臺納入一起管理，這就是AI工作空間誕生的原因。

在這個AI工作空間里面，支持 Flink 的集群、離線計算集群 MaxCompute，也能夠支持AI的平臺，還支持容器服務計算平臺等等。

將大數(shù)據(jù)與AI統(tǒng)一管起來只是第一步，更重要的是以工作流的方式將它們連起來?？梢酝ㄟ^多種方式建立工作流，如 SDK 的方式、圖形化的方式、GUI 的方式、寫 SPEC 的方式等等。工作流中的節(jié)點可以是大數(shù)據(jù)處理的節(jié)點，也可以是AI處理的節(jié)點，這樣就能夠很好地將復雜的流程連接起來。

要進一步提高效率、降低成本，就需要 Severless 云原生服務。上圖中詳細描述了什么是 Severless。云原生，從 share nothing（非云化方式），到 share everything（非常云化的方式），之間有很多不同的層次。層次越高，資源的共享程度越高，單位計算的成本就會越低，但是對于系統(tǒng)的壓力也會越大。

大數(shù)據(jù)和數(shù)據(jù)庫領域在這兩年開始慢慢走向 Serverless，也是基于成本的考慮。原先，即便是在云上使用的 Server，如云上的數(shù)據(jù)庫，也是以實例化的形式存在。這些實例的背后有資源的影子，比如這個實例是多少 CPU、多少 Core。慢慢地逐漸轉(zhuǎn)變?yōu)?Serverless，第一個層次是單租計算，指的是在云上起一個 cluster，然后在里面布大數(shù)據(jù)或者數(shù)據(jù)庫的平臺。但這個 cluster 是單租的，也就是和其他人共享物理機，物理機虛擬化出一個虛擬機，用于做大數(shù)據(jù)的平臺，這種叫做單租計算、單租存儲、單租管控。用戶得到的是云上彈性的 ECS 機器，但是大數(shù)據(jù)管理、運維的方案需要自己來做。EMR 就是這方面一個經(jīng)典的方案。

慢慢地會從單租存儲走向共享存儲，也就是數(shù)據(jù)湖的方案。數(shù)據(jù)在一個更加共享的大數(shù)據(jù)系統(tǒng)里面，計算是動態(tài)拉起一個集群，算完了之后這個 cluster 就消亡了，但數(shù)據(jù)不會消亡，因為數(shù)據(jù)是在一個 reliable 的 remote 的存儲端，這就是共享存儲。典型的就是數(shù)據(jù)湖 DLF 以及 serverless EMR 的方案。

最極致的是 Share Everything，大家如果去用 BigQuery 或者阿里云的 MaxCompute，看到的會是一個平臺，一些虛擬化的 project 的管理，用戶提供一個 query，平臺根據(jù) query 來計費計量。

這樣可以帶來非常多的好處。比如在大數(shù)據(jù)計算中有很多節(jié)點，并不需要有用戶的代碼，因為這些節(jié)點其實是一些 build-in 的 operator，比如 join、aggregator，這些確定性的結(jié)果并不需要用一個比較重的 Sandbox，因為它們是確定性的算子，是經(jīng)過嚴格的測試檢驗的，沒有任何惡意代碼或隨意的 UDF 代碼，因此可以讓其去掉虛擬化這些 overhead。

UDF 帶來的好處是靈活性，使我們能夠有能力去處理豐富的數(shù)據(jù)，在數(shù)據(jù)量大的時候有很好的擴展性。但 UDF 會帶來的一個挑戰(zhàn)就是需要有安全性，需要做隔離。

無論是 Google 的 BigQuery 還是 MaxComputer，都是走在 share everything 的架構(gòu)上面，我們認為只有技術的不斷提升，才能夠把資源用得更加緊實，將算力成本節(jié)省下來，從而讓更多企業(yè)能夠消費得起這些數(shù)據(jù)，推動數(shù)據(jù)在模型訓練上面的使用。

正是因為有 share everything，我們不僅可以將大數(shù)據(jù)和AI通過工作空間統(tǒng)一管理起來，通過 PAI-flow 連起來，更能夠以 share everything 的方式進行統(tǒng)一調(diào)度。這樣企業(yè) AI+大數(shù)據(jù)的研發(fā)成本會進一步下降。

在這一點上，有很多工作要做。K8S 本身的調(diào)度是面向微服務的，對于大數(shù)據(jù)會面臨很大挑戰(zhàn)，因為大數(shù)據(jù)的服務調(diào)度粒度非常小，很多 task 只會存活幾秒到幾十秒，這對于調(diào)度的規(guī)模性以及對調(diào)度的整體壓力會有幾個量級的提升。我們主要需要解決在 K8S 上，怎樣讓這種調(diào)度的能力得到 scale off，我們推出的 Koordinator 開源項目就是要去提高調(diào)度能力，使大數(shù)據(jù)和AI在 K8S 生態(tài)上得到融合。

另一項重要的工作就是多租安全隔離。如何在 K8S 的服務層、控制層做多租，如何在網(wǎng)絡上去做 over lake 多租，使得在一個 K8S 之上服務多種用戶，各用戶的數(shù)據(jù)和資源能夠得到有效的隔離。

阿里推出了一個容器服務叫做 ACS，也就是通過前面介紹的兩個技術把所有資源通過容器化的方式暴露出來，使得用戶在大數(shù)據(jù)平臺和AI平臺上面能夠無縫地使用。它是一種多租的方式，并且能夠支撐住大數(shù)據(jù)的需求。大數(shù)據(jù)在調(diào)度上面的需求是比在微服務和AI上面都高幾個量級的，必須要做好。在這個基礎上面，通過 ACS 產(chǎn)品，可以幫助客戶很好地去管理其資源。

企業(yè)面臨很多需求，需要把資源管得更精細。比如企業(yè)中分各個部門、子團隊，在做大模型的時候，會把資源拆成很多方向，每個團隊去做發(fā)散性的創(chuàng)新，看看這個基模型到底在什么場景下能夠得到很好的應用。但是在某一個時刻，希望集中力量辦大事，把所有的算力及資源集中起來去訓練下一個迭代的基模型。為了解決這一問題，我們引入了多級 quota 管理，也就是在更高需求的任務到來時，可以有一個更高的層次，把下面所有的子 quota 合并集中起來。

在AI這個場景里面其實有非常多的特殊性，有很多的情況下是同步計算，而同步計算對于延遲的敏感度非常強，并且AI計算密度大，對于網(wǎng)絡的要求是非常高的。如果要保證算力，就需要供數(shù)，需要交換梯度（gradient）這些信息，并且在模型并行的時候，交換的東西會更多。在這些情況下，為了保證通訊沒有短板，就需要做基于拓撲感知的調(diào)度。

舉一個例子，在模型訓練的 All Reduce 環(huán)節(jié)中，如果進行隨機調(diào)度，cross port 的交換機連接會非常多，而如果精細控制順序，那么 cross 交換機的連接就會很干凈，這樣延遲就能夠得到很好的保證，因為不會在上層的交換機里面發(fā)生沖突。

經(jīng)過這些優(yōu)化，性能可以得到大幅地提升。怎樣把這些拓撲感知的調(diào)度下沉到整個平臺的管理器上，也是AI加大數(shù)據(jù)平臺管理需要去考慮的一個問題。

前面介紹的是資源和平臺上的管理，數(shù)據(jù)的管理也是至關重要的，我們一直在耕耘的就是數(shù)倉的系統(tǒng)，比如數(shù)據(jù)治理、數(shù)據(jù)質(zhì)量等等。要將數(shù)據(jù)系統(tǒng)和AI系統(tǒng)進行關聯(lián)，需要數(shù)倉提供一個AI友好的數(shù)據(jù)鏈路。比如在AI開發(fā)過程中用的是 Python 的生態(tài)，數(shù)據(jù)這邊怎么通過一個 Python 的 SDK 去使用這個平臺。Python 最流行的庫就是類似于 pandas 這樣的 data frame 數(shù)據(jù)結(jié)構(gòu)，我們可以把大數(shù)據(jù)引擎的 client 端包裝成 pandas 的接口，這樣所有熟悉 Python 的AI開發(fā)工作者就能夠很好地去使用它背后的數(shù)據(jù)平臺。這也是我們今年在 MaxCompute 上推出的 MaxFrame 框架的理念。

數(shù)據(jù)處理系統(tǒng)在很多情況下對成本的敏感度較高，有時候會用更高密的存儲系統(tǒng)來存數(shù)倉的系統(tǒng)，但是為了不浪費這個系統(tǒng)，又會在上面布很多 GPU，這個高密的集群對于網(wǎng)絡和 GPU 都是非?？量痰?，這兩個系統(tǒng)很可能是存算分離的。我們的數(shù)據(jù)系統(tǒng)可能是偏治理、偏管理，而計算系統(tǒng)偏計算，可能是一個 remote 的連接方式，雖然都在一個 K8S 的管理下，但為了讓計算的時候不會等數(shù)據(jù)，我們做了數(shù)據(jù)集加速 DataSetAcc，其實就是一個 data cache，無縫地和遠程存儲節(jié)點的數(shù)據(jù)進行連接，幫助算法工程師在背后把數(shù)據(jù)拉到本地的內(nèi)存或者 SSD 上面，以供計算使用。

通過上述方式，使得AI和大數(shù)據(jù)的平臺能夠有機結(jié)合在一起，這樣我們才能去做一些創(chuàng)新。例如，在支持很多通義系列的模型訓練時，有很多數(shù)據(jù)是需要清洗的，因為互聯(lián)網(wǎng)數(shù)據(jù)有很多重復，如何通過大數(shù)據(jù)系統(tǒng)去做數(shù)據(jù)的去重就很關鍵。正是因為我們把兩套系統(tǒng)很好的有機結(jié)合在一起，很容易在大數(shù)據(jù)平臺進行數(shù)據(jù)的清洗，出來的結(jié)果能夠馬上灌給模型訓練。

前文中主要介紹了大數(shù)據(jù)如何為AI模型訓練提供支撐。另一方面，也可以利用AI技術來助力數(shù)據(jù)洞察，走向 BI +AI的數(shù)據(jù)處理模式。

在數(shù)據(jù)處理環(huán)節(jié)，可以幫助數(shù)據(jù)分析師更簡單地去構(gòu)建分析，原來可能要寫 SQL，學習如何用工具與數(shù)據(jù)系統(tǒng)進行交互。但AI時代，改變了人機交互的方式，可以通過自然語言的方式跟數(shù)據(jù)系統(tǒng)進行交互。例如 Copilot 編程助手，可以輔助生成 SQL，幫助完成數(shù)據(jù)開發(fā)環(huán)節(jié)中的各個步驟，從而大幅提升開發(fā)效率。

另外，還可以通過AI的方式來做數(shù)據(jù)洞察。比如一份數(shù)據(jù)，unique key 有多少，適合用什么樣的方式去做 visualization，都可以利用AI來獲得。AI 可以從各個角度去觀察數(shù)據(jù)、理解數(shù)據(jù)，實現(xiàn)自動的數(shù)據(jù)探查、智能的數(shù)據(jù)查詢、圖表的生成，還有一鍵生成分析報表等等，這就是智能的分析服務。

四、總結(jié)

在大數(shù)據(jù)和AI的推動下，近年來出現(xiàn)了一些非常令人欣喜的科技進展。要想在這一潮流中立于不敗之地，就要做好大數(shù)據(jù)和AI的聯(lián)動，只有兩者相輔相乘，才能實現(xiàn)更好的AI迭代加速和數(shù)據(jù)理解。