一、AI的“iPhone”時刻

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

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

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

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

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

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

更好的機器學習是 80% 的數(shù)據(jù)加 20% 的模型，重心應(yīng)該在數(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ù)中存在的關(guān)系，此時就進入了以數(shù)據(jù)為中心的開發(fā)范式。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

大數(shù)據(jù)和數(shù)據(jù)庫領(lǐng)域在這兩年開始慢慢走向 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)上面，我們認為只有技術(shù)的不斷提升，才能夠把資源用得更加緊實，將算力成本節(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)度是面向微服務(wù)的，對于大數(shù)據(jù)會面臨很大挑戰(zhàn)，因為大數(shù)據(jù)的服務(wù)調(diào)度粒度非常小，很多 task 只會存活幾秒到幾十秒，這對于調(diào)度的規(guī)模性以及對調(diào)度的整體壓力會有幾個量級的提升。我們主要需要解決在 K8S 上，怎樣讓這種調(diào)度的能力得到 scale off，我們推出的 Koordinator 開源項目就是要去提高調(diào)度能力，使大數(shù)據(jù)和AI在 K8S 生態(tài)上得到融合。

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

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

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

在AI這個場景里面其實有非常多的特殊性，有很多的情況下是同步計算，而同步計算對于延遲的敏感度非常強，并且AI計算密度大，對于網(wǎng)絡(luò)的要求是非常高的。如果要保證算力，就需要供數(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ù)的管理也是至關(guān)重要的，我們一直在耕耘的就是數(shù)倉的系統(tǒng)，比如數(shù)據(jù)治理、數(shù)據(jù)質(zhì)量等等。要將數(shù)據(jù)系統(tǒng)和AI系統(tǒng)進行關(guān)聯(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)絡(luò)和 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ù)的去重就很關(guān)鍵。正是因為我們把兩套系統(tǒng)很好的有機結(jié)合在一起，很容易在大數(shù)據(jù)平臺進行數(shù)據(jù)的清洗，出來的結(jié)果能夠馬上灌給模型訓練。

前文中主要介紹了大數(shù)據(jù)如何為AI模型訓練提供支撐。另一方面，也可以利用AI技術(shù)來助力數(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ù)查詢、圖表的生成，還有一鍵生成分析報表等等，這就是智能的分析服務(wù)。

四、總結(jié)

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