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

大家好，我是鄭曌，很榮幸今天能代表第四范式，和大家分享第四范式在決策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應用，在高復雜環境中邁向決策智能時代。