百度智能云李扬：SaaS厂商的大模型应用，该在什么方向投入？

短短两年时间，大模型在 SaaS 领域已呈现蓬勃发展的态势，创新应用层出不穷，然而，在这繁荣景象背后，大模型的技术演进、市场渗透、挑战与机遇等，究竟是怎样一番景象？

短短两年时间，大模型在 SaaS 领域已呈现蓬勃发展的态势，创新应用层出不穷，然而，在这繁荣景象背后，大模型的技术演进、市场渗透、挑战与机遇等，究竟是怎样一番景象？

11 月 16 日，在“2024 中国 SaaS 大会”暨崔牛会 10 周年年会上，百度智能云大模型应用生态合作总监李扬，通过主题分享《大模型的这两年》揭晓了答案。

AI 对 SaaS 的影响，是一个备受关注的话题。至于，SaaS 不加 AI 会不会死？李扬的观点是：不会死。但与具备 AI 能力的竞品相比，无疑会存在明显的短板。他解释，今后，大模型能力会成为 SaaS 的标配，其地位将等同于如今的数据库。未来，无论是在云端还是本地部署，大模型和数据库将成为 SaaS 不可或缺的基础设施。

李扬表示， AI 对 SaaS 行业的颠覆是不可避免的，只是时间早晚的问题。至于是自身率先被颠覆，还是在这场变革中占据主动、颠覆他人，这需要各位 SaaS 厂商的掌舵者们尽早投身于大模型技术的研究与探索之中，在变革中占据先机。

以下是经牛透社整理的分享内容：

AI 技术的融合已成为行业发展的必然趋势。然而，当所有企业都在这条道路上前进时，如何在众多竞争者中脱颖而出，构建差异化优势，如何筑起产品的竞争壁垒，便成了大家当前需要深思的问题。

这两年来，整个行业呈现出一种鲜明的发展态势，总体可归结为四个关键词：快速爆发、极致内卷、应用为王、未来可期。

在这一背景下，大模型厂商与应用伙伴之间的关系发生了显著转变。早期阶段，应用伙伴往往主动向大模型厂商寻求技术支持，以实现大模型技术的快速引入。而现在，大模型厂商则积极寻求与应用伙伴合作，致力于落地更具价值的场景与案例。可以预见，未来将是应用引领大模型技术发展的时期。

SaaS厂商不要盲目跟风做Agent平台

这两年，大模型行业的产品赛道与厂商分工逐渐明朗。回顾去年，国内大模型厂商数量众多，包括基础模型与行业模型，总数超过 200 家。然而，时至今日，能够持续迭代并在市场上保持活跃的厂商已大幅减少。

究其原因，一方面是由于基础模型训练的资金压力，另一方面是支撑基础模型发展的 Scaling Law 出现明显的边际效应递减。因此，百度一直倡导将关注点转向应用层的创新。

在公有云领域，竞争焦点已转向大模型供应商的成本管控能力，几家头部厂商已经将大模型推理成本超前压缩。所以对于 SaaS 伙伴来讲，尽管大模型应用的研发整体成本较高，但在应用发布后的推理服务阶段，成本是相对较低的，这也是大模型公有云服务的优势所在。

在另一个赛道，大模型领域还存在大量私有化项目，特别是今年年初央企大模型讨论会召开以来，所有央企都在着手构建自己的行业大模型。

这些项目规模较大，一般整体建设金额都在千万级以上，涉及算力采购、模型平台搭建及应用开发等多个环节。这一市场主要由模型厂商参与，与 SaaS 厂商关系不大。这是基础模型商业化赛道的行业现状。

在工具平台领域，竞争尤为激烈。当前市场上涌现出众多 Agent 平台，如百度智能云的 AppBuilder、字节的扣子、腾讯的元器等知名平台，另外还有诸如 Dify、Fast-GPT 等众多优秀的开源 Agent 平台产品。

在这种市场格局下，还是有一些 SaaS 厂商也要自研 Agent 平台，个人觉得这个产品方向还是要仔细评估的。

因为许多现有 Agent 平台都具备被集成的能力，SaaS 厂商还是应该聚焦于自身擅长的业务应用，利用好通用 Agent 平台的组件化能力做好集成就行，比如百度智能云的 App Builder 平台就是基于 API-Centric 理念设计的，它的各种组件化能力可以被 SaaS 厂商方便集成调用，让 SaaS 厂商更专注于其业务功能实现而非底层 AI 能力的跟进与迭代。

总之，个人建议 SaaS 厂商在立项大模型平台或 Agent 平台之类的产品研发时一定要找准定位，切勿陷入再次重复造轮子的陷阱，那将大幅增加研发成本并且拖后商业转化周期。

在应用层面，大模型的应用大体可分为两种类型：一是 AI 原生应用，如文小言、AI PPT 这类，这类应用的 AI 生成功能力占比极高，形成了独立的市场赛道；二是在现有 SaaS 产品中融入大模型功能点的应用，就是这两天我们一直在讨论的“+AI”。

这两种路径均被视为大模型应用的可行方向，但我个人更关注后者，其原因是，尽管当前在营销、客服等领域已有不少成功落地的应用案例，但在更广泛的业务场景中，大模型+在 SaaS 应用的爆发时代还没有到来，“+AI”应用前景依然广阔。

值得注意的是，当前还有不少大模型应用场景普遍存在“浅、泛、浮”的现象，即应用深度不足、场景泛化但缺乏针对性、以及浮于表面缺乏业务基础。因此，我们 SaaS 厂商后面真正需要深入思考的，是如何构建真正的门槛与壁垒，以提升大模型应用的价值。

目前，相对落地的应用场景都更贴近于大模型的原生能力，并且这些场景也较早地被客户所采纳。尽管如此，仍有大量客户不愿为之买单，不想付费。其实，从我们监测的大模型调用量来看，企业服务类的调用量确实不高。这背后的主要问题在于，目前所开发的应用场景尚未真正展现出其业务价值。业务价值未能体现，主要归咎于两方面的原因：

一方面，应用场景对于原有应用的功能效果提升不显著。为了应对这一问题，我们需要积极寻求方法来提升这些应用的实际效果。

另一方面，所开发的应用场景可能缺乏实际意义，或者没有市场需求，导致客户缺乏为之付费的动力。在这种情况下，我们需要勇于创新，不断探索新的应用场景。

所以，提升应用价值的方案无非两条：优化当前大模型产品应用效果以及突破高价值的大模型应用业务场景。

大模型产品优化：效果、性能与成本的三角平衡

这个话题就又来到了我们熟悉的“不可能三角”，但实际上大模型应用确实要综合考虑效果、性能和成本的综合最优，这是任何一个大模型应用产品成熟后都无法回避的问题。

起初，当然是效果优先，SaaS 厂商会用最强的模型去完成产品验证。但当产品发布并且推广后，随着用户的增加和 Tokens 调用的攀升，大家就会同时关注到性能和成本问题。毕竟参数量的差异量级与成本的差异量级相比，大参数量模型的成本是小参数量模型的十倍百倍，小参数量模型也能够在经过 SFT 之后，在特定任务场景保障效果的前提下提供更优的性能表现。

今天由于时间关系，我们主要说一下模型评估、工程优化和数据飞轮建设这三个话题：

大模型产品效果优化首先要做的就是测试与评估。较为自然的一种方式是选取若干原型客户，在实际应用场景中进行原型产品测试，并让用户对模型的表现进行描述和评判。大模型产品效果的评估不同于传统SaaS软件产品，具有较强的主观性，其核心在于输出的内容究竟能否满足客户的实际需求。

从根本上来说，大模型评估主要依赖专家评估法，也就是凭借特定的专业判断来解决。但是，大模型的全部应用场景都采用专家评估的方式是不现实的，不仅成本高昂，而且也没有那么多专家资源，因此，我们也可以引入自动化评估方法来辅助评估。

这里简单分享一下百度智能云产研团队归纳的《大模型产品评估测试白皮书》，是基于智能云内部产品的评测工作总结的一套方法论。这里面会分层次分领域的给出不同大模型产品的评估建议，包括基础模型、行业/领域模型等等。

大家可以看一下这个面向金融行业的“智金”平台（智金是百度智能云面向金融行业场景发布的大模型智能体产品，可以提供资产智评、合规智判、交易智查、财务智顾等业务场景的智能体服务）的效果评估流程，已经基本自动化了。

简单概括就是将大模型输出的内容“切片评估”之后再“汇总得分”，从而快速实现一个测试内容的对标评估，找到差异部分之后可以进入下一阶段的优化与对齐流程。

评估后如果效果不尽如人意，那么第一个需要考虑的就是工程框架问题。产品的 COT 是否完备，RAG 的准召率是否达标，API 调用是否稳定，等等。说起大模型应用开发框架大家可能第一个想到的是 LangChain、LlamaIndex 等老牌开源框架，不过，当前大模型开发平台/框架的产品生态已经是非常丰富了，既有大厂的闭源产品，也有优秀的开源产品可以选择。

因此，建议各位 SaaS 厂商在考虑自研大模型产品时多去利用成熟的平台能力，以百度智能云千帆 AppBuilder 为例，它不但提供了多种产品集成形态选择，还提供了大量的 AI 能力组件，而且背靠百度智能云的算力服务，可以实现从研发环境到生产环境的平滑迁移。

大模型产品优化的第二个也是最重要的思路，就是一定要构建自身领域的数据飞轮。从逻辑上讲，真正有竞争壁垒的大模型产品到最后肯定依赖于 SaaS 厂商自身的数据积累和业务 Know-How，承载这些竞争壁垒的应该就是基于这些数据训练出来的“领域/场景模型”了，将用户反馈的数据高效回流、标注、对齐从而不断迭代模型能力的过程我们称之为“数据飞轮”。

构建数据飞轮的过程中由于存在很多需要资源投入的作业节点，比如标注、对齐的环节，有些 SaaS 厂商也是由于这些节点的资源投入较多，在构建数据飞轮上一直存在卡点。

这里介绍一下百度建议的数据飞轮构建方法，就是基于百度智能云千帆 ModelBuilder 平台实现数据流程的闭环以及对齐训练的自动化。

以面试总结这个场景为例，我们基于业务需求规划了 4 轮自动化的训练流程，基于知识蒸馏的方法，使用一个大参数模型作为 teacher 模型，同时引入一个小参数模型作为 student 模型。通过不断迭代和优化语料库，实现模型的自动与升级，这是整个流程的基本框架。

在训练流程中，语料筛选至关重要。为了提升训练效果并降低成本，我们引入了“语义熵”的概念，在筛选语料时优先考虑语义差异性较大的数据。这种方法不仅提高了训练效率，还显著降低了成本。

还是面试总结这个场景，分别以文心 4 和文心 speed 做为 teacher 模型和 student 模型，文心 4 是我们效果最好的万亿参数的模型，而文心 speed 则是一个拥有 200 亿参数的高性能模型。

基于上文的机制经过四轮的训练，文心 speed 的表现效果便能超越文心4。

大模型应用场景创新的建议方向

关于大模型应用场景的创新，真正的路径最终肯定是由大模型应用伙伴探索出来的，在此，分享几个探索方向的思路：

首先，深入挖掘企业的核心应用场景。企业的战略、研发、生产、供应、销售和服务等各个环节，都是值得探索的领域。特别是战略、计划和研发这些相对较为复杂的领域，大模型技术能否在其中发挥独特的作用，或者能否与传统模型相结合，创造出新的解决方案，这是值得深入思考和探索的。

举例来说，随着大模型进化到 System2，意味着可以尝试更多低频、复杂的计算场景。比如企业经营中的各类计划场景，能否依赖基于强化学习深度推理的大模型实现业务建模？然后再灵活的调用其他统筹决策工具，比如求解器之类的产品，最终实现整体计划的规划与发布，这是个值得探讨的高价值场景。

其次，随着大模型的普及，图形用户界面（GUI）到语言用户界面（LUI）的应用转化已成为一个不可忽视的趋势。最近 Claude 发布的一些场景应用中，大模型已经可以控制 PC 用户在采购系统中自行录入订单添加大量表单，这是与传统 RPA 完全不同原理的实现方式，这种变化给我们带来了新的启示。

此外，之前展示过的利用大模型自动操控手机的演示，也为我们提供了基于大模型实现从计算机自动化应用（Computer Use）、智能终端手机自动化应用（Mobile Use）拓展到系统自动化应用（System Use）的新思路。

第三，多智能体协作的概念也为我们提供了场景创新的新视角。单个智能体可以完成一个小任务，而多个智能体协作则可以完成更为复杂、需要协同的工作任务。

以企业物料采购流程为例，它的很多环节可以通过既定规则或者自动化沟通方式来实现。这里所涉及的主要是企业内部智能体的运作情况。

而从产业链的视角来看，当企业外部的供应商也引入销售智能体来响应企业内部采购智能体的需求时，整个产业链便能够实现有效衔接与协同运作，这便是多智能体协作在实际场景中的生动体现。对于 SCRM 这类供应链平台厂商而言，多智能体协作模式很值得尝试。

SaaS不加AI不会“死”

关于 AI 对 SaaS 的影响，这是一个备受关注的话题。虽然 AI 能否颠覆 SaaS 取决于人们的认知角度，但不可否认的是，AI 必将给 SaaS带来显著的变化。

首先，AI 正朝着类人化的方向发展，未来它将成为我们的同事，与我们进行自然语言沟通协作。其次，即使 AI 成为了“同事”，现有的人类同事也不会被淘汰。相反，他们将转变为 AI 的“教练”，负责维护和优化 AI 的业务逻辑、业务数据以及数据飞轮等核心要素。最后，随着 AI 技术的不断发展，整个业务流程都将逐步走向 AI 化。无论处于何种应用场景之中，AI 都将为人们提供全面的支持和解决方案。

至于，SaaS 不加 AI 会不会死？我的观点是：不会死。但与具备 AI 能力的竞品相比，无疑会存在明显的短板。今后，大模型能力会成为 SaaS 的标配，其地位将等同于如今的数据库。未来，无论是在云端还是本地部署，大模型和数据库将成为 SaaS 不可或缺的基础设施。

我认为， AI 对 SaaS 行业的颠覆是不可避免的，只是时间早晚的问题。至于是自身率先被颠覆，还是在这场变革中占据主动、颠覆他人，这需要各位 SaaS 厂商的掌舵者们尽早投身于大模型技术的研究与探索之中，在变革中占据先机。

说明：文章为牛透社原创，未经允许谢绝转载。