一、AI的“iPhone”時刻

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

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

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

二、模型開發范式

一般的模型開發周期如下圖所示：

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

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

這也反映了模型開發的演進趨勢，原來的模型開發是以模型為中心，而現在則變為以數據為中心。

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

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

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

三、大數據AI一體化

1.大數據AI全景

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

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

2.為什么需要將大數據和AI結合

下面通過兩個案例，來解釋為什么需要大數據與AI的聯動。

案例 1：知識庫檢索增強的大模型問答系統

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

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

在上述過程中，既需要有離線的分布式大數據平臺去快速產生 embedding，又需要有對大模型訓練和服務的AI平臺，將整個流程連起來，才能構成一個大模型問答系統。

案例 2：智能推薦系統

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

3.如何將大數據與AI結合

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

四、總結

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