对AI原生应用做“逆向”后，我找到了大多数大模型厂商注定失败的原因

大家好，我是卖萌酱。

在一整个2023年对大模型风风火火的流星赶月之后，大模型的竞逐已经来到了“下半场”。应接不暇推出一个又一个大模型已为GPT的技术神话祛魅，不得不说，2024年的大模型市场将更加关注大模型的应用和商业价值。

但是，落地说起来轻而易举，真正将“技术”转化成“应用”，乃至超级应用，实际上要走的路比想象中还要艰难。这对大模型厂商将是由一轮全新考验，有实力有耐力的才能跑到最后。

那么大模型的落地究竟难在哪里？卡在哪一个环节？

2023年底，百度创始人、董事长兼CEO李彦宏在行业大会上提出了 “少关注大模型、多卷AI原生应用” 的观点。我们可以洞悉到，从喊出基于大模型对核心业务线进行重构、重塑之后，百度盯上AI原生应用的步伐在提速。一向以技术积淀见长的百度，究竟在大模型向应用发力的阶段，扮演什么角色？

在WAVE SUMMIT+深度学习开发者大会上，现场为开发者演示了一个基于“多工具智能编排”开发模式开发的旅行助手，让我们看到一个集成图文识别、翻译、语音合成、问答多模态功能的AI原生应用被以一种“搭积木”的方式构建出来，而大模型本身却仿佛隐身于一个旅行助手的实际需求背后，我们看到的只是多种不同的工具被以一种极其方便快捷的方式组装到了一起。

从应用到底层，逆向AI 原生应用

那么什么叫AI 原生应用？

应用的本质，是为了方便快捷的让用户解决某项任务。 1984年，乔布斯在Apple Lisa中第一次创建了“图形用户界面”，自此，基于计算机的“任务实现”不再依赖指令代码的复杂逻辑而可以“所见即所得”。2008 年，Apple 再一次推出 App Store，应用APP这一次开始走入大众视野，在APP中，用户任务实现的复杂逻辑被完整的封装在了手机界面中的一个小方块内，需求的实现开始“所触即所得”。

而伴随着AI技术的出现，基于传统软件开发架构的应用开始不再适应AI算法的封装需求，从而势必要拥抱AI。而AI原生应用的概念，就是以AI系统为驱动，基于AI而构建和运行的应用程序，区别于仅仅将APP内的某个功能模块更替为AI模块，AI原生强调着在应用开发的过程之中，AI 应该和代码、数据一样成为一等公民，即无代码、不编程，无 AI、不工作。

而区别于传统APP的点击式交互，AI原生的应用将更加主动的赋予用户个性化的交互体验，不再是传统的开发者发布，用户使用的应用模式，而是变更成为开发者发布，用户使用，应用学习相辅相成的私人定制应用。

如前文的“旅行助手”，目的地不同，关注点不同的用户可以享受应用带来的不同功能，你想去瑞士我想去德国，你关注浪漫我追求省钱，AI原生的应用天然的具备软件层面的大规模定制能力，从而可以支撑自移动互联网时代的移动APP后新一轮的应用变革。

然而，AI原生应用的概念本身恰如Software 2.0 这类宏观建设仅仅是空中楼阁，支撑AI 原生应用的根本在于底层技术的变革。 如果以移动互联网时代编程框架—>操作系统—>应用商店—>APP的路径作为类比，AI 原生应用本身也需要有底层的核心技术与生态社区作为支持。

追溯AI原生应用的生成逻辑，AI原生应用首先需要有大规模的AI 原生应用商店作为社区支撑，用户需要有渠道“看到”并“使用”应用，开发者也需要平台管理发布自己的应用。有了对接用户与开发者的平台，应用的开发者们需要有基础模型平台方便快捷的调用各类大模型的开放接口以赋予AI原生应用所需的各种各样的能力，实现应用的快速开发与上线，而再往下，构建功能不同的基础模型与不同的AI算法交互又需要有一套完整的AI框架作为模型训练微调的支持。

在这整个过程之中，大模型凭借其自身的理解、规划与生成的能力，将成为类似手机操作系统一般的底层基座，而非类似当下这样顶着Chat的标志在场的与终端用户直接互动交流。

类似于IOS或是安卓，大模型在AI原生应用构建，或是用户实际问题解决的过程中扮演的是一个承前启后的功能，而分析一款AI原生应用的关注点，绝不能只落在它用了什么模型这个模型性能几何的片面数据之上，而是要关注这个应用背后的一整套生态支撑逻辑。

从底层到应用，大模型的生态系统

无论在哪个商学院，教授们总会强调 “现代企业的竞争，就是供应链竞争”。 其实类似于大模型落地至行业应用，我们也可以说 “大模型落地的竞争，就是大模型生态的竞争”。

然而应用侧的繁荣需要有良好的大模型应用生态，再推进一步构建良好的大模型应用生态，必然需要极其丰厚的AI技术储备积累。 对标前文所述AI框架—>基础模型—>AI商店—>AI原生应用的路径，在WAVE SUMMIT+深度学习开发者大会2023上，正式发布飞桨开源框架2.6版本以及大模型重构的开发工具链，为我们带来了百度称为“AI原生应用开发“三板斧”的大模型落地的“百度方案”。

先从飞桨2.6版本说起，作为一个AI框架，核心功能自然是灵活便捷的开发与高效的训练与推理，百度飞桨集核心的深度学习框架，基础的模型库，开发套件，工具套件以及开发者社区为一身，技术上，百度飞桨做到了集动态图与静态图于一身，打通了从动态图开发、动转静训练，静态图表示与优化，静态执行的全过程，实现了兼顾灵活性与效率的高效训练和推理。资源上，百度也构建了丰富全面的基础模型库，开发套件，工具组件以及助力开发者成长的星河社区，成为国内当下唯一功能完备的开源深度学习平台。

在2.6版本中，飞桨迎来了一系列的升级：

• 在技术底层上，夯实了高扩展性IR的表示体系，为大型模型的极致性能优化提供了技术支撑；

• 在动转静训练中，飞桨应用自适应的图构件技术，实现了百分百成功率的自动由动转静；

• 在并行开发方面，又引入了动静统一的自动并行编程，仅仅通过张量切分就可以轻松的开发并行代码；

• 在大模型库中，对大模型的套件进行了全流程的优化，从预训练到精调、压缩、推理、部署，全环节都进行了极致的优化，以支撑整个大模型的训练与推理；

• 在计算调度中，2.6版本支撑了多Stream的并行算子调度，降低了硬件等待的耗时和运行时的阻塞，并且为方便硬件厂商开发大幅优化了自定义算子和自定义融合策略；

借由飞桨构建的AI框架为技术支撑，向上结合百度智能编程助手Comate AutoWork，构建了直接“面向需求的开发”的新范式。 在一个开发需求提出后，Comate可以自动化的完成从澄清需求到制定计划、生成代码至调试运行的全过程，在演示中一个过去以天为单位的前端功能程序Comate AutoWork在2分钟内完美完成。

在Comate的赋能下，百度构建了一整套的大模型×飞桨低代码开发工具，通过结合文心大模型，PaddleX支持了基于“图形界面”的开发模式，整合了从数据准备到模型部署的完整AI开发流程，实现了AI应用开发效果和效率的大幅提升。

而有了这些“基础工具”作为技术优势，再结合飞桨星河社区背后的开发生态，一个可以直接通过API或SDK调用大模型，再以上文旅行助手应用以插件加多工具智能编排式的低代码或零代码的应用开发方式跃然纸上。而正是来自从底层到上游方方面面每个的技术细节与技术积累，百度才可以支持承载大模型落地的AI原生应用的快速开发，降低应用开发门槛从而催生如移动互联网APP繁荣式的AI原生应用的繁荣。

大模型落地，路在何方？

做大模型，说容易也容易，说难也难。

要说做大模型容易，伴随着大模型开源社区的发展，搭建一个模型的成本在以肉眼可见的速度逐年降低。 但是说做大模型难，如何让大模型本身不再作为客服式的聊天机器人，而具备支撑应用生态的能力，这就必然要求着大模型企业打通类似移动互联网时代从编程框架到操作系统到应用商店到APP应用的全过程。

大模型落地难，难点不在于大模型性能不够榜单分数不高，它的核心与关键在于大模型要落到实地，真正比拼的反而不是我们通常理解的属于大模型技术部分的实验室数据集上，人为定义的任务或是测试基准里来来回回的问答上的性能，而是更加底层的支持大模型应用生态的一整套AI技术套件。无论大模型技术本身沿着何种方向发展，对企业而言自底向上长年累月在领域深耕而积累下的技术优势才是企业真正的护城河。

其实谈起大模型落地路在何方，事实上当下对大模型的落地恰恰卡在了看起来并不“高大上”的技术细节积累与生态环境运营之上。而如果让我们再回看从百度飞桨到文心大模型再到智能交通、自动驾驶等应用，可能我们会惊讶的发现，目前国内，似乎只有百度拥有了支撑起一整套大模型应用生态的技术能力。其实不单是领先的AI技术积累，还有软硬协同一体化的开发链路，这种生态式发展策略，正是大模型落地不可或缺的一环，而在这样一条大模型商业化落地的进路中，百度可能已然捷足先登，快人一步。