本文整理自第四範式技術日中第四範式技術總裁、基礎技術負責人鄭曌在主論壇的演講。
大家好，我是鄭曌，很榮幸今天能代表第四範式，和大家分享第四範式在決策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的問題，希望和各位開發者能有更多的交流、探讨和更加緊密的合作。