未來10年,AI開發者面臨的三大“坑”!

語言: CN / TW / HK

本文整理自第四正規化技術日中第四正規化技術總裁、基礎技術負責人鄭曌在主論壇的演講。

大家好,我是鄭曌,很榮幸今天能代表第四正規化,和大家分享第四正規化在決策AI工程技術方向的創新與實踐,以及我們基於此的一些思考。

在去年2021年6月,第四正規化對外正式釋出了開源開放的AI底層技術戰略,經過過去一年的發展,正規化底層技術社群在技術落地、生態合作上都取得了顯著的進展,我們也有幸和各位企業開發者、社群開發者共同見證了第四正規化AI底層技術社群從0到1,從無到有的成長。

目前,第四正規化的底層技術以及商業產品,獲得了社群開發者的廣泛關注和使用。 截止到今天,我們將全部12個底層技術方向社群進行了開源,其中超過40家企業加入社群,覆蓋了網際網路、金融、零售、製造、自然科學等多個行業與領域;我們目前有超過1200名社群使用者參與到使用和貢獻,我們的映象下載和部署累計超過45000次。

底層技術社群的發展,離不開社群開發者和生態合作伙伴對第四正規化的信任和貢獻,在此,我代表第四正規化,向所有參與正規化底層技術社群貢獻和建設的小夥伴們表示感謝,謝謝大家的支援。

同時,我們也歡迎更多的開發者、生態合作伙伴加入到社群,共同協作將 AI落地的門檻和難度降低,為AI開發者提供切實、好用的基礎軟體。

在第四正規化,除了提供領先的演算法模型,我們同樣關注演算法在應用中的規模化落地。從去年開始,第四正規化圍繞AI應用落地的三大核心生產要素:應用、資料和算力,將AIOS產品中的兩大底層核心技術棧進行了開源,一個是機器學習資料庫 OpenMLDB,一個是開源AI作業系統核心 OpenAIOS,幫助開發者解決應用落地過程中遇到的痛點問題。

我們認為,只有當演算法從開發者的膝上型電腦走向生產叢集,模型從探索環境部署至生產環境,應用與真實世界產生符合預期的相互影響,才是真正意義上的落地。

今天如果模型的準確率做得再高再漂亮,但是模型沒法進入到生產,沒法注入到實際業務中,我們仍然只是紙上談兵。

未來十年,企業 AI 開發者面臨的三大沖擊

在2022年,伴隨著更多的AI落地,第四正規化和企業開發者、社群開發者一起將踩過的坑進行了沉澱總結。我們認為,企業AI開發者在未來將面臨的衝擊主要來自 三個方面。

衝擊一

首先是應用價值快速落地的需求。專案週期緊、時間不夠用是今天企業開發者普遍面臨的現狀。究其原因, 一方面 AI的工具棧進入了百花齊放的階段,但是工具鏈的碎片化也同樣給開發者造成了困擾,開發者需要面臨不同工具的技術選型, 面臨不同工具的學習和使用,在這個過程中,開發者還得邁過人工智慧各個環節的陡峭學習曲線;

另一方面,AI工程化的鏈路長、環節多, 開發者在落地過程中需要進行反覆的清洗資料、反覆的生成特徵、反覆的模型調參,每一個環節的失誤都會造成業務效果的折損和專案週期的拉長。

這是第一個衝擊,應用價值快速落地的需求。

衝擊二

第二點是精準可信賴的資料供給。實際上,在15到16年,第四正規化剛剛成立的時候,正規化的小夥伴們發現,使用傳統的資料庫時,會有很多最佳實踐、有很多資料可以參考,我們可以比較直接的從網上看到相關文章,直接拷貝原始碼抄作業和學習,但是當我處理機器學習、處理所遇到的資料問題時,我們卻很難在網上找到指導,整個機器學習資料開發的過程缺乏一個像 Web2.0 時代Spring Boot類似的開發正規化。

最近5~6年,我們看到隨著資料的爆炸式增長,資料開發的工具越來越複雜,一套完整的機器學習資料系統往往需要MySQL、Kafka、Spark、Flink、Hbase/Cassandra/Redis等一系列資料元件的組合和搭建,大部分以網際網路企業為代表的公司開始花費數以月計的時間構建這樣一套系統。

但是花費數個月搭建完成這樣一套系統之後,是否AI資料開發的問題就解決了呢。我們觀察到,絕大部分企業的資料科學家和資料工程師 仍然在花費每個模型上月的週期用以資料開發迭代和排查資料的正確性,資料的時序穿越、線上線下一致性、資料的閉環完整性這些生產問題開始消耗大量的資料開發時間。

而一份資料是不是正確的資料,他是不是生產可用,這份資料是否造成了業務效果的下降,這些問題充斥在資料開發的日常工作中,客戶經常會和我們感慨說:有的時候比沒有資料更可怕的是不知道資料到底哪裡開發錯了。

實際上 IT 層面的技術封裝和抽象,無法全面的解決資料正確可信賴的問題,我們仍然重度依賴於人與人的溝通、校驗、對齊,而這種隱性溝通成本,事實上成為了企業數字化轉型過程中最大的成本支出。

這是第二點,精準可信賴的資料供給。

衝擊三

第三個衝擊來自算力,模型的表達能力越來越強是一個不可逆的趨勢。隨著模型的結構更大、更寬、更深,這些大模型、寬模型、深模型所消耗的算力也成指數級的上升趨勢。

今天我們看到,業界有大量的技術和產品在優化複雜模型的訓練效能。然而,在AI應用的流程中,模型訓練只是整個鏈路中的一個環節,模型訓練在很多場景中,甚至只佔到不到AI應用生命週期的1%,線上推理系統、資料處理、業務系統都會涉及到大量的算力佔用。

在實際開發過程中,很多企業開發者會遇到一個困境,一方面AI晶片、AI硬體、AI伺服器不夠用,另一方面,站在IT的視角,算力的資源利用率又非常低,我們無法做出合理的判斷,到底應該採購更多算力還是優化當前的系統。

這是第三個衝擊,來自算力的衝擊。

面臨衝擊的應對路徑

總結來說,企業AI開發者,今天需要面臨來自應用、資料、算力等多方面的挑戰,我們認為,如何在這樣一個高複雜度的環境下進行敏捷的應用開發,這將會是未來區分企業AI開發者能力高低的關鍵。

那麼,在高複雜環境下進行敏捷的AI應用開發,企業AI開發者的應對路徑是什麼。我們認為需要著眼於 兩個方面

新方法

首先是新的方法,在應用快速落地的需求下,企業開發者應該儘可能專注在定義業務優化目標,在此基礎上充分利用軟體和基礎設施持續迭代,找到達成目標的最優解。

相比基於流程的傳統軟體工程體系,這種價值目標驅動的模式,強調小步快跑、持續提升,而不是按照傳統軟體專案的模式定目標、定計劃、開發、上線、驗收、結項。

新工具

當然,新的方法也需要搭配新的工具鏈配合落地。雖然有時候工具鏈的演進會比方法論走的更加靠前,但是決大多數時候,工具的革新都趕不上思想方法上的跨越。

所以說,一個稱手的工具,對企業AI開發者來說十分關鍵,就好比雷神托爾有了雷神之錘、鋼鐵俠有了鋼鐵盔甲,才變成真正的超級英雄。

新工具——好工具?

那麼,什麼樣的AI基礎軟體算是稱手的工具?

我們回到開始提到的三個挑戰和衝擊。

首先在應用側,面對應用價值快速落地的需求, 第四正規化的主張是,一個稱手的工具,應當讓開發者聚焦最具價值的業務問題定義,讓工具完成重複性工作,為開發者遮蔽掉繁冗的系統細節。

在資料側,我們主張捕捉真實世界準確、及時的反饋,通過工具和軟體保障資料在線上線下、系統內外部持續一致;

在算力端,我們主張充分的理解應用負載,面向每一個應用環節進行鍼對性的優化,將負載分配和排程到合適的算力設施上,最大化資源利用率。

第四正規化的創新和探索

基於此,最近一年,第四正規化也在思考AI工具的創新,我們能不能構建一個 可以讓開發者專注業務價值的工具鏈,能不能有一個 All in One 開箱即用、低學習門檻,易用易維護的工具,來解放大家的生產力。這些思考,也是第四正規化進行新的AI工具創新和探索的最原始動機。

那第四正規化探索了一些什麼樣的工具鏈,來應對新的工具鏈需求呢?

應對快速落地需求的重磅工具

首先應對應用價值快速落地的需求,第四正規化的解法:

北極星實驗平臺+AutoML自動機器學習

北極星平臺為開發者提供了快速進行創新和迭代的最佳工程實踐,能夠協助開發者聚焦最具價值的業務問題定義,支撐快速、穩健的價值迭代。

通過高效科學分流演算法,開發者可以降低一次驗證一種方案的高試錯成本,有能力並行進行海量的實驗;

通過挑戰區與冠軍區的機制,開發者可以確保上線效果的穩定可控,對抗業務波動的不穩定;

通過多環境綜合驗證,開發者可以使用到業務模擬沙箱, 以晶片設計驗證級別的模擬環境, 在構建實驗的過程中逐步修正我們的智慧系統,從而提早預知實驗的缺陷和效果;

我們再看 AutoML 自動機器學習系統, AutoML主要負責自動進行資料工程和演算法工程,幫助開發者進行自動化的AI全流程,他相當於是一個機器人,我們用機器人去代替人建模,減少開發者在冗長流程中的重複勞動。

第四正規化在 AutoML 的方向上,除了業界領先的演算法效果,我們在工程上的目標是做到極致的 TCO 和效能。通過第四正規化的軟硬一體技術,我們不僅將 AutoML 的 TCO 算力成本降低至 Google 的 1/10。在過去的一年時間裡, 我們在自動跨表特徵增強、自動深度稀疏神經網路等方向進行了細緻的工程優化,以 FeatureZero 和 AutoDSN 為代表的工具元件,幫助我們在效能上獲得了超過 10 倍的提升,在記憶體消耗上獲得了超過 70%的節省。在下午的技術分論壇中,我們的架構師也會為大家帶來工程優化的展開介紹。

應對資料挑戰的重磅工具

解決完應用價值快速落地的需求,我們再看看資料的供給。我們的工程目標是通過完善的資料系統,去捕捉真實世界準確、及時的反饋,同時確保資料在線上線下、系統內外部的一致,最終做到開發者可以放心、省心的使用系統開發出來的資料和模型。

這件事情聽上去非常重要,但為什麼長久以來一直沒被解決。我們看到,隨著資料側的技術演進,資料系統記錄行為、反饋資料的能力越來越強,機器參與人機協同的決策也從不可能變成了可能。

以資料庫系統的演進為例,早期的 DBMS 系統,它的設計目標是如何去把資料和資訊記對記全,進入到網際網路時代,來自感測器的資料越來越多,資料量級越來越大,再到今天,像 HTAP和雲原生等技術的成熟,讓資料系統有能力提供更大量級的處理能力

儘管如此,資料質量仍然制約了最終AI的業務效果,實際落地過程中,資料工程師今天仍然有超過90%的精力花在資料的建設上。雖然機器學習技術的突破讓機器有能力幫助人實現絕對理性和瞬時高效的推理判斷,但是不管是事務型資料庫、分析型資料庫還是傳統數倉,面向機器學習都無法保障正確的資料供給。

資料的第二個挑戰是時效性。今天我們經常會看到依賴於大資料框架的離線批量機器學習系統,通常來說,這些離線批量任務會通過 cron job 處理 小時級別甚至是天級別延遲的資料。

事實上,這樣的系統設計會遇到非常多的問題,比如 cron job執行間隙的新使用者冷啟動問題, 比如無法刻畫長尾使用者和長尾物料的個性化特徵,比如 session 內的行為意圖特徵無法刻畫, 比如長時間執行的離線資料任務很難 debug,這些問題,背後除了對資料開發效率的影響,更重要的,是因為資料的不新鮮導致模型效果的折損。

因此,第四正規化認為,資料時效性的好壞,將直接影響模型效果的好壞。

資料工具的第三個挑戰,是資料線上線下不一致造成的隱性溝通和決策成本。

這個資料不一致是出現在,當我們在做線下演算法探索的時候,我們寫的程式碼,往往需要在上線的時候,把這部分資料開發的邏輯再開發一遍,從大資料和數倉系統的ETL程式碼轉換成線上業務系統的實時計算程式碼,我們看到,目前機器學習上線難,有 90%以上的問題和 bug,源自於這兩段程式碼不一致。而這會觸發兩個開發角色不停的比對程式碼,不同的校驗結果,以確保資料的一致。

而使用過期的資料,使用不一致的資料,最後造成的災難性後果,就是因為人可能出錯的地方太多,導致我們不知道資料是否真的出問題了,以及資料在哪個環節出問題了。

那我們是怎麼解決這個問題的呢?我們提出了一個統一的資料開發系統:

開源機器學習資料庫 OpenMLDB

通過統一的一致性執行計劃生成器,使用標準易學習的 SQL,去統一線上和線下資料計算的執行邏輯。做到線下探索的特徵可以一鍵上線投產。

因此,很多企業開發者也把 OpenMLDB 叫做 Feature Store Plus, 一個擁有資料計算、處理、上線能力 且 線上線下一致的 特徵平臺。

在過去的一年時間裡,OpenMLDB 與 DataOps、ModelOps 和 ProductionOps 層眾多開源技術元件形成了完整的 AI 應用全流程生態,在今天下午的技術分享中, OpenMLDB 團隊,也將為大家展示如何在開源機器學習平臺上,通過 OpenMLDB 構建一個完整的 AI 應用。OpenMLDB 的社群合作伙伴和社群企業使用者也將為大家分享他們的實踐。

今年1月,通過收集客戶和社群的反饋,我們在 OpenMLDB 的基礎之上,構建了一個 從T+1 批量資料系統向 實時資料系統 切換的最佳工程實踐 Profile Engine。通過 Profile Engine,我們能夠在兼顧批量計算與實時計算的前提下,保證批量、流式計算邏輯和結果的一致。

那 OpenMLDB 到今天已經開源一年時間了,到今天為止,OpenMLDB 已經發布了 6 個版本, 這個過程中,OpenMLDB 落地了包括網際網路風控、推薦系統、使用者標籤系統、AIOps、AIoT 裝置預警等機器學習場景。

我們也歡迎對 OpenMLDB 感興趣的開發者小夥伴,能夠加入我們的社群,和我們一起共同建設機器學習資料開發的最佳體驗。

應對算力成本高的重磅工具

說完了應用和資料,接下來我們看下如何破解算力成本的挑戰,在解決這個問題的過程中,第四正規化的工程思路是通過對軟體負載的深度理解,從軟體應用負載的全流程出發充分利用AI異構算力,在具體的落地過程中,第四正規化的工程團隊,會面向機器學習落地的每個環節, 從計算、儲存、通訊、排程等幾個維度分別排查系統的算力瓶頸在充分理解各環節瓶頸之後,我們再進行頭痛醫頭腳痛醫腳的工程優化,將瓶頸逐個擊破。

今年,第四正規化也進一步升級了軟硬一體優化的技術,除了面向機器學習任務負載,我們重點進行了全流程資料處理的算力優化和改進,通過 ReCA 第二代  可重配硬體加速架構,我們能更靈活的在加速卡上拓展資料任務的負載優化。

目前,第二代 ReCA 加速卡可以在零業務程式碼修改的情況下,實現訊息佇列、Spark離線大資料計算框架、Redis 、Elastic Search 等眾多資料元件進行算力優化。

在 ReCA 的加持下,機器學習整體的機器時有了大幅的節省,以一個端到端的推薦場景為例, ReCA 相比 Tensorflow + GPU 的方案做到了高達 6 倍的機器時節省。建模時間也從 2 周縮短至 2 天。

此外,除了標準卡外,ReCA 也提供了 Made In China 版本,為開發者提供MIC國產算力的選型,為國產AI伺服器提供軟體定義的算力優化方案

應對GPU呼叫問題的重磅工具

除了第四正規化自研的加速卡外,面向 GPU ,第四正規化同樣從軟體負載出發最大化使用和排程GPU資源,今年,我們也正式對外發布了OpenAIOS 雲原生vGPU 解決方案,幫助我們的開發者實現視訊記憶體的超售,通過自動將記憶體置換成視訊記憶體的機制,讓GPU支援數量更多、規模更大的GPU任務。在今天下午的技術分享中,我們也將為大家演示,如何在一臺GPU伺服器上,同時執行20個 Resnet 。我們也歡迎感興趣的開發者小夥伴們加入vgpu社群,和我們共同交流、探討。

那今天演講的最後,我想借機會總結一下第四正規化對AI工程技術的觀點和設計理念,我們認為,決策AI的本質,是軟體系統和真實世界進行符合預期的相互影響。在這個過程中, 我們需要持續的關注 演算法、資料 和算力三個維度。

在演算法端 ,我們重點投入的方向是,穩定可驗證的決策與反饋動作、快速的實驗與試錯、真實世界細緻入微的表達;

在資料端 ,我們的工程設計理念是,持續的提升捕捉真實世界及時新鮮變化的能力,保障資料線上線下的一致性,構建行為-反饋的資料閉環。

在算力端 ,我們將持續堅持軟體定義算力的長期主義,面向應用負載的全流程進行鍼對性優化,同時堅持提供穩定、可靠的國產化替代方案。

第四正規化的工程技術元件也是圍繞上述演算法、資料、算力方向的工程理念進行的探索和打造。

我們今天非常的榮幸,非常的高興,能與各位企業開發者一起探討AI的問題,希望和各位開發者能有更多的交流、探討和更加緊密的合作。

未來,第四正規化也會堅持圍繞這三個AI核心要素打造開發者喜愛的、稱手的工具鏈,和企業開發者小夥伴們一起,減少AI落地過程中的踩坑,更高效更快速的落地AI應用,在高複雜環境中邁向決策智慧時代。

謝謝大家!

寫在最後

如果想進一步瞭解 OpenMLDB 或者參與社群技術交流,可以通過以下渠道獲得相關資訊和互動~

Github: https://github.com/4paradigm/OpenMLDB

官網: https://openmldb.ai/

Email: [email protected]

OpenMLDB 微信交流群: