第四范式技术 稿

本文整理自第四范式技术日中第四范式技术总裁、基础技术负责人郑曌在主论坛的演讲。

大家好，我是郑曌，很荣幸今天能代表第四范式，和大家分享第四范式在决策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应用，在高复杂环境中迈向决策智能时代。

谢谢大家！