阿里云 CIO 蒋林泉：AI 大模型时代，我们如何用 RIDE 实现 RaaS 的首次落地？

AI 大模型技术发展迅猛，但要实现在企业中真正有效的落地，过程中存在很多坑点和难点。本文整理自阿里云智能集团 CIO & aliyun.com 负责人蒋林泉在 AICon 2025 深圳 的分享 “阿里云大模型应用落地实践之路”。本次演讲将基于阿里云 CIO 线在文档、翻译、客服、电销、合同审核、BI、员工服务、研发等不同场景的数字人项目落地经验，分享从组织挑战、业务机会识别，到 AI 产品定义、运营指标设计，再到 AI 产品工程落地的体系化思考。

其中，面对企业内部 AI 认知及能力水位参差不齐的问题，深入探讨如何快速实现组织内部转型，打造匹配 AI 发展的生产关系和文化共识。同时，深入剖析当前业务部门和 IT 部门在 AI 项目中普遍存在预期差的主要矛盾，深度分享对于如何协调与业务部门的协作关系、如何动员业务专家参与数据准备和评测、如何对企业 AI 项目达成一致预期等挑战问题的解决方法。

以下是演讲实录（经 InfoQ 进行不改变原意的编辑整理）。

观察与思考

这是我自担任阿里云 CIO 三年以来，第一次对外发表演讲。此次分享会浓缩我过去三年在阿里云带领团队推进数字化与智能化进程中沉淀的案例与经验。

在担任 CIO 之前，我主要负责阿里云飞天核心系统的产品和研发工作。当时我对外的演讲内容更多围绕飞天和阿里云的产品，角色也更偏向于“乙方”的产研身份。而今天，我以阿里云 CIO 的身份首次对外演讲，更多是站在“应用开发者”的角度，分享如何在企业内部场景中推进数字化和智能化落地的一些实践与体会。

过去两三年，我带领团队致力于推动 AI 大模型在企业各类场景中的落地应用，在这个过程中有很多感触。我想先谈一下在这个阶段里我的一些观察和思考。

在当今时代，我们常常会思考一个问题：一个人或者一个组织发展得这么好，到底是时代的原因，还是自己努力的原因？其实最主要还是时代的原因。我常说，我们能发展到今天，很大程度上是因为我们坐在了一个很好的电梯上。比如搭上了中国这个电梯，中国互联网的电梯，以及我所在的阿里巴巴这个平台的电梯。平台本身发展得很好，我在上面自然也发展得很好。

换句话说，你是在电梯里做俯卧撑，还是在平地上做俯卧撑？两者达到的高度是不一样的。个人努力固然重要，但更重要的是平台。我认为，在这个时代，AI 就是那个最大的电梯。无论是组织还是个人，有没有搭上 AI 这趟电梯，将直接决定在未来能够达到的高度。

根据 ARK INVEST 的一份调研报告预测，到 2030 年，算力性能相较于现在将增长 1000 倍。黄仁勋也曾提出一个观点，说未来 10 年人工智能的算力将提升 100 万倍。100 万倍，这是什么概念？在 AI 时代之前，我们常常讲摩尔定律，技术性能大约每 18 个月翻一番。而在 AI 时代，技术发展的速度被极大地加快了。如果不能及时搭上 AI 这趟高速电梯，那么大概率会落后于时代。因此，我们必须迅速行动起来，快快搭上这个电梯，在上升的电梯里做俯卧撑，不要在原地做俯卧撑。

基于这样的认识，我们发现，无论是企业还是个人，都开始逐渐意识到 AI 的重要性。只是我刚才的表述可能稍显直白。意识到这一点后，许多企业，包括 CEO 和业务部门，开始变得焦虑起来。在我看来，这一轮科技革命与以往的科技革命最大的不同之处在于，在整个信息技术产业中，无论是 PC 互联网还是移动互联网时代，技术在企业中的应用过程是一个渐进的过程，非常循序渐进。那个时候，企业的 CEO 看到业界的炒作、厂商的炒作，都比较冷静，可以慢慢来。

然而，这一次的情况却截然不同。我觉得这是第一次，企业 CEO 和业务部门比 IT 团队、比供应商还“上头”。因此，我们可以说，现在企业内部最大的矛盾，就是业务部门在社交媒体、PR 渠道里看到的 AI，往往呈现出一些“炸裂”、“梦幻”的效果，而 IT 部门，或者说 CIO，在实际生产力上的发展却是不均衡、不充分的。这种矛盾体现得非常突出。

在阿里巴巴集团内部，以及我与业界三十多位 CIO 交流的过程中，我观察到，在企业内部，这种现象大量存在。企业中会涌现出很多 Idea，做出很多 Demo，上了非常多的技术平台，一个团队里，恨不得要搭好几套 Dify 平台，各种智能体平台都在搭建。但是在这些过程中，还是技术主导比较突出，更多是拿着平台去做 Demo，业务方的参与往往比较浅层。这类现象在企业里是比较过剩的，可以说整个企业都充斥着类似的情况。

与此同时，我们也观察到，真正深入到业务本身去做价值识别，或者去正确地定义产品，以及如何开展知识工程（注意，这里我们不再仅仅是传统的软件工程，而是知识工程），还有我们所谓的业务专家知识动员，这些方面却是严重不足的。这也是我在企业中普遍观察到的现象。

因此，我们认为，如果要在企业里真正用好 AI，并且产生实际的业务结果，那就必须要做非常大的投入。在这个领域，我们也做了很多探索和实践。

阿里云大模型应用实践落地全景

接下来，我想向大家展示阿里云内部企业 AI 大模型业务落地的全景图。在这张图中，我们可以看到一个个“数字人”，这些数字人无论是在我们的官方网站、CRM（客户关系管理系统）、业务支撑系统，还是在内容管理系统、人事管理系统中，都已经广泛地落地应用，并且在原来的业务中发挥了真实的效果。

在整个过程中，其实我们已经落地了大约 28 个数字人项目，我从中挑几个有代表性的例子来分享，让大家更有体感。

第一个案例是翻译

大家都知道，翻译是大模型非常擅长的事情。但在阿里云，我们遇到过很大的挑战。阿里云作为一家公共云服务提供商，为客户提供服务时，文档的作用至关重要（大家都知道 ToB 的服务非常依赖文档）。阿里云拥有 300 多个产品，十几万篇文档，涉及上亿文字。这其中，我们有一个非常大的痛点在于“出海”。我们要出海到日本、美国、欧洲、印尼，还有土耳其，而我们的开发者要高度依赖我们的文档来操作云计算服务。

问题在于，我们缺乏既懂本地语言又懂云计算的人才。技术类的翻译必须同时具备这两方面的能力，即使我们有足够的资金，也很难招聘到这样的人才。在过去，我们只能选择“忍”，仅翻译了英文文档，以及部分日文文档，其他语言的翻译工作基本停滞不前。这导致我们的海外开发者反馈不佳。

在这一轮 AI 技术突破之前，我们尝试过用传统 NLP 来做翻译，但效果根本不行。到了 ChatGPT 3.5 的时候，我们发现自然语言处理技术仍然无法满足我们的需求。到了 ChatGPT 4 版本，我们再次尝试，发现翻译质量终于能和那些既懂技术又懂本地语言的专业译者打平。

而且，我们当时计算了一下成本，每篇文档的翻译成本仅为当初专业技术翻译团队的 1/200（时间在一年多以前）。从那时起，我们开始大量使用大模型进行翻译工作。到现在，我们已经完成了印尼语的全部翻译工作。这意味着我们解决了原本靠资金也无法解决的组织问题。

如果用专业的评分来看，过去，我们用专业的懂本地语言和懂技术的翻译团队来翻译，评分大约为 4.12 分（满分 5 分），现在，我们用 AI 来翻译，评分能够达到 4.6 分。在海外市场，我们发现海外网站的用户体验以及 NPS（净推荐值）都得到了显著提升。因此，这不仅仅是一个成本问题，更是通过 AI 解决了过去无法解决的难题。

第二个案例是智能外呼

阿里云拥有数百万家企业客户，由于 ToB 业务的特点，我们需要提供销售和服务。但我们无法为每一家企业都配备专门的销售人员和服务人员，因此，我们很大一部分销售工作是通过电话进行的。我们有数千名服务人员和销售人员需要通过电话为客户提供服务。

然而这里有一个问题，云计算本身是非常复杂的，如何招聘到足够多的外呼坐席人员，让他们既具备相关技能，又熟悉云计算知识，同时还能够耐心地每天坐在那里打一天的电话，这对我们来说是一个巨大的痛点。因为这样的团队招聘和能力培养难度很大，人员流动率非常高，这使得无论是销售服务还是电话服务的质量，都存在明显的短板。

因此，我们尝试通过 AI 的方式直接引入智能外呼。当然，我们在前期已经有一定的知识积累，包括语音、多模态等方面的经验。如今，我们已经投入使用智能外呼来做电话销售和客服，它所具备的服务能力，如果折算出来，相当于数百名人工座席的服务带宽。

第三个案例是合同风险审核

ToB 业务的一大特征，是有大量的政企和大客户，他们通常不会使用我们的标准合同。这些合同金额巨大，需要进行严格的风险审核，涵盖财税法、风控、信控等多个方面的风险。过去，要完成这样的风险审核，我们需要专业的法务、财务等领域的精英人士，他们大多来自国际四大会计师事务所。然而，鉴于我们业务规模庞大，不可能招聘到足够多的精英来从事这项工作。

因此，我们在合同风险审核方面遇到了巨大瓶颈，审核时间过长，最长甚至可达 5 个月，平均也需要两周到一个月。这极大地拖累了业务效率，包括服务大客户的效率。为了解决这一问题，我们培养了一大批“数字人”，包括财务数字人、信控数字人和法务数字人。并且，把这些数字人送到合同撰写端，让他们在销售和客户沟通、合同拟定的瞬间，就能够实时识别潜在风险并提示谈判方案，而不是等到审核端后才发现问题，再回过头去处理。这样极大提升了合同风险管理的效率。

第四个案例是员工服务数字人

为什么特别提到这一点？因为在这么大的企业里，HR 系统有一个显著特征，就是非常分散。比如请假、体检、福利、在职证明等，各式各样的流程和服务都散落在不同的系统里。与此同时，各类政策也同样分散，包括公司内部的福利政策、外部的人才政策等等。员工在需要获取这些信息或使用这些系统时，会遇到两个难点：第一，这些服务是低频使用的；第二，它们分散在不同地方，获取难度非常大。由于是低频服务，不可能配备一个庞大的服务团队来支持，所以 HR 团队的负担很重，而员工的服务体验也不足。

为了解决这一问题，我们将这些低频、分散的服务全部整合到一个智能体中，通过钉钉平台打造了一个“云小宝”（数字人），为员工提供统一的智能服务。我们发现，通过引入智能体，折算下来相当于节省或新增了大约 10 名员工在为大家服务。但更重要的是，员工的体验得到了极大提升。比如，只需要用自然语言输入，如“下周一请假”“国庆前后两天请假”或“为父亲预约体检”，系统就能迅速响应并完成操作。

目前，我们有二十几个场景实现了智能化服务，这里只是挑四个来举例。这些数字人应用背后有 一个共同逻辑：一是折算拓展了多少人力；二是业务效率提升了多少；三是业务效果提升了多少。 我们非常注重这一结构，因为每一个数字人上线落地，都必须衡量其对原来业务是否真正拓展了服务带宽 ，并且，是否比原来人工操作的效率和效果更好，这是非常关键的，与外界所谓的众多智能体最大的区别就在于此。

这些智能体最终都是在对应的岗位上实际工作的。在我们的 HR 系统中，这些数字人被分配到对应的业务部门，向对应的业务团队汇报工作，与我们从外部招聘的员工没有任何区别。所以，它们必须在对应的岗位和业务团队中发挥超过一定人数的实际任务执行作用，才能真正融入团队。在我们的钉钉系统以及内部工作系统中，这些数字人与普通员工一样，拥有工号和头像。唯一的区别在于，它们的工号以“AI”开头，如 AI001、AI002，目前我们已经有大概 28 个智能体上线，后续还有更多智能体在排队等待上线。它们与我们身边的同事几乎是一模一样的。

过去两年，在带领团队推进业务落地的过程中，我也深刻体会到，真正将技术应用于业务并取得成效，没有那么简单。特别是真正在业务中产生价值和仅仅做出一个 Demo 之间，是天壤之别。接下来，想和大家进一步分享，我们在这一过程中遇到的困难以及总结出的一些解决方法，希望能对大家有所帮助。

大模型 E2E 落地坑点与解法——RIDE

最近，大家可能听过红杉提出的一个概念叫 RaaS，即“结果即服务”。这一概念的核心在于，如果仅仅提供工具和产品，让企业自行落地是不够的。所以，我们特别重视真正上线并产生业务结果的项目。我作为 CIO 所带的团队，在企业内部为业务部门提供的，就是这种 “以交付结果为导向的服务”。在推进 RaaS 的过程中，我们也总结出了一套方法论，叫 RIDE。

RIDE 包括四个关键步骤：Reorganize（重组组织与生产关系）、Identify（识别业务痛点与 AI 机会）、Define（定义指标与运营体系）、和 Execute（推进数据建设与工程落地）。

首先是 Reorganize。在 AI 时代，新的生产力下，原来的生产关系是非常不适应新生产力的发展，这种不适应会在每个毛孔里面表现出来，然后阻碍 AI 的发展和落地，所以要求我们要重新调整生产关系。第二，是 Identify。也就是我们需要精准地识别出企业中哪些问题适合用 AI 来解决，这要求我们首先明确问题的定义，然后结合 AI 的能力和业务需求，确定哪些问题可以通过 AI 得到有效的解决。然后是 Define。在明确了问题和 AI 的能力之后，我们需要精准地定义产品及其运营指标，进行准确的指标跟踪。最后才是 Execute。执行阶段是一个金字塔结构，上面是业务目标，下面是工程数据和评测，中间是工程应用算法。

当然，这套我们称之为 RIDE 的方法论，并非在做 AI 转型的第一天就有了，而是在二十多个智能体真正有效落地业务的过程中，我们发现，如果不遵循方法论中的这些步骤，项目很可能会失败。遵循这些步骤，虽然不能保证 100% 的成功，但至少可以提高成功的概率。这是一套用两年时间、用血泪经验总结出来的方法。

我们首先从 Reorganize 开始讲。

在落地第一年，我发现了一个问题：无论是业务团队还是我们自己的团队，对大模型的能力边界、发展程度、具体原理等基本概念的理解都存在差异，甚至在我自己的团队，产品经理、算法、工程团队内部都无法拉齐概念认知。

为了解决这一问题，我们发起了一个行动，叫 “书同文、车同轨”。 我们要求全员参加 AI 大模型的认证培训。其最主要的原因，就是要解决大家在基本功和认知逻辑上的差异。我称之为 “AI 时代的通识教育”，相当于要在团队里重新走一遍“高中的教育”。这一培训分为两类：ACA（面向非技术人员）和 ACP（面向技术人员），因为我们不仅需要技术人员之间能够对齐话语，也希望非技术人员和技术人员对齐话语。

这种通识教育对于团队的协作至关重要，首先在我们 CIO 线内部已经完成了全员的认证，后面，我们的业务方，也就是我们的财务、人力、销售、中后台等都在做全员认证。目前，整个阿里巴巴集团都在用这个方法来做 AI 转型的基础教育，重新建立大家的基础认知。不然就会出现这种情况：大家都在谈论同一个概念，但其实理解的内容和现实完全不一样。如果没有做过深入工作，很难体会到那种无力感。但一旦通过通识教育统一了认知，沟通效率就会显著提升。

在这样的基础上，我们又设计了两个比赛。一个是产研提效比赛，一个是业务提效比赛。和其他大赛最大的不一样，我们的比赛是真正以 E2E 为衡量标准的。 比如产研比赛，要看的是，原来 E2E 同样粒度的一个需求，需要多少人月，而现在能减少到多少人月。而不是看代码采用率，因为代码采用率很容易“灌水”，而且它往往只能补全那些最容易写的代码，最难的代码可不容易补全。

在业务 E2E 方面，我们的比赛就是要真正进入业务场景，帮助业务去拓展，而且效果和效率都要超过原来。所以，这两件事非常重要，第一，是做“书同文，车同轨”的通识教育，因为 AI 时代的知识在不断发生巨变，每个月都在变，现实的实践知识和原来的基础知识都有大量的不同；第二，是“以赛促练”，整个组织通过正确目标下的比赛，大家会发现短板，发现相互之间可以学习的地方，就能够激发组织不断地去创新、去提效。

再说说我们的数字员工。

我们的这些数字人最后都是汇报给业务部门的，这是非常关键的安排。这不仅关乎形式，更重要的是心理。我们不能让业务部门觉得，AI 技术会威胁到他们的工作，而是要让他们明白，AI 技术是来帮助提效的。如果这个关系没处理好，就会遇到无数的暗礁。

所以，我们把自己定位为数字人供应商，业务部门是 AI 先进组织，业务部门可以雇佣我们的数字员工，并与我们一起联合培养。 这样，业务部门会更愿意接受 AI 技术，减少阻力。所以这是第一点，我们把自己退到一个外包供应商的位置上。第二点，我们还发现，AI 数字员工是不能扛责任的，也不能给它打“3.25”（低绩效）。这意味着，数字员工在系统里执行任务出了问题，谁来承担的问题。我们将 AI 数字员工汇报到业务部门，属于业务部门的人（让他们放心），并一起参与 AI 员工的培养过程，同时数字员工也会受到正式员工的监督，来承担相应业务领域的责任。

另外，我们经常听到一句话：ToC 还好，但 ToB 的大模型有幻觉，做不到 100% 正确。但实践经验告诉我们，其实人也有幻觉，而且人的幻觉还很大。如果认真地看，在很多任务里人其实也是不靠谱的，也经常会失败，只是企业没发现而已。

所以我们强调的一点是：如果 AI 项目和业务部门真正达成了共识，并且通过培养逐步磨合，就必须认真回头来看，AI 的要求标准到底是什么。如果要求 100% 正确，其实就是把 AI 拿来和“神”比。但如果是和原来人做事的效果和准确率去对比，那就是和“人”比。所以，追求比人做得更好、更准，才是真正有意义的对标。那怎么避免和“神”比呢？回到前面说的，解决生产关系的问题，处理好内部业务的逻辑、目标和关系，这样才能真正实现 AI 和人比，而不是和“神”比。

在整个 Reorganize 的过程中，我们还发现，要把数字人汇报到业务部门，对 HR 部门来说，这就等同一个正式员工。注意，我们是真的把他当作正式员工来看待的，用他能否产出真正的业务结果来度量。所以我们在内部与 CPO（HR 负责人）沟通时，讨论过：怎么去度量 AI 数字人是否真的发挥了一个正式员工的效果？我们最后确定了一个方向：AI 数字人必须有一个目标，就是在原有具体的业务流程里，接管一个重复且有价值的任务，并且能够折算出“相当于拓展出多少人力”，这就是唯一的目标。

但要 真正让数字员工上线、上岗，必须满足两个标准条件： 一是数字人执行原来任务的效率，一定要比原来提升一定百分比，效率一定要比人高；二是效果上也要比原来提升一定百分比。只有当数字人做到效率高、效果好时，才能“正式上岗”，进入业务部门工作。

刚才讲的是 Reorganize。如果不解决 Reorganize 的问题，就会不断遇到暗礁，甚至没法往前走。但解决了组织的问题后，业务部门会说，好，我们来联合培养数字员工。那从哪里开始呢？

所以第一件事就是业务机会的识别（Identify）。

这轮 AI 革命的核心其实是 LLM（large language model），所以，我们在内部有一个逻辑：所有以 language 为中心的工作，都将被大模型深刻影响。比如电销、客服、招聘、OKR、文档、翻译、合同审核，还有研发类的 C language、Java language、SQL language 等，这轮以 language 为中心的工作受影响最大。所以第一个特征是 Language 类 工作。

第二个特征是被重复执行、规模化执行。因为 AI 是自动化的，越大规模、越重复的任务，AI 越有机会去做。第三个特征是，如果本身缺人，甚至有人投诉效率低，那这个地方就是个大的机会。所以这三个特征是我们与业务部门一起来 Identify，识别哪些业务是可以着手的。这也是我们在内部形成共识后，如何去识别机会、定义机会的关键点。因为把问题定义清楚了，后面做事才会顺畅。如果解决错了问题，那投入就白白浪费了。

另外我们刚才讲到，要在对应的任务里拓展目标，也就是拓展对应岗位的人力，具体怎么核算呢？

我们的经验是，首先，有些单任务岗位，比如技术翻译，我们是按字收费的。那 AI 翻译一个字多少钱，就可以直接线性替换了。一个人一天的产能可能是翻译 2 万字，那我们就差不多折算成 2 万字的产能等同于一个人。如果是多任务岗位，比如产品经理，他一会儿做 PRD，一会儿分析工单，一会儿画 Demo，一会儿又去客户那里访谈。这种多任务岗位，我们发现往往有些任务是重复的、繁琐的，也不是高价值的。那我们依然可以做出对应的数字人，帮这些关键的、复杂的、不可替代的岗位，把繁琐的任务卸载出来，折算出对应岗位的人力。我们从中发现，像财务、法务这种高价值的多任务岗位，你会发现，把他们最繁琐的审核工作卸载出来，可以聚焦在更高价值的工作上，他们的幸福感也会爆棚。

过了 Identify 这一步，下面就是 Define。

在这个时代和以前做产品有很大不同。我们前面提到的一些产品大多都类似，比如都有交互、体验。在这个流程里，其实和上一轮移动互联网的产品没有区别。但 AI 产品有一个特别关键的点，那就是准确率。 当然，除了准确率之外，还有响应时效性和安全合规等非功能性指标。比如在电销过程中，和客户实时对话，延迟必须非常低，不然客户会觉得交流效率不高，像机器人说话一样。因此，实时性和准确性非常关键。如果准确性不够好，客户根本无法使用，也根本不可能真正上岗。所以，准确率是 AI 项目的第一核心指标，整个项目组都必须盯住它，这也是产品定义中最核心的部分，必须重新去 Redefine。

此外，运营指标同样至关重要。如果只有产品指标和准确率指标，那大概率会掉到坑里。即使是在对内的业务项目里，原来移动互联网那些基本功也不能丢，比如：

• DAU（每日活跃用户数）；

• 用户提问数；

• 渗透率，即目标客户的覆盖率；

• 留存率（最关键）。

如果同一个客户今天用了，下周还愿意继续用，说明这个 AI 智能体真正帮他解决了问题。如果客户只用了一次就不再回来，那么无论前面产品指标再漂亮都没有意义，那可能就是定义错了问题。运营指标就是用来兜底的，如果不紧盯这些指标，很容易让产品、工程和算法团队陷入“自嗨”。什么叫自嗨？就是他们说“我的指标很好”，结果客户根本不用。

举个例子，在阿里云官网的 AI 助理中，我们就设定了这样的度量方式。左图展示了准确度的度量指标，时间线大约覆盖从去年到今年的一年时间。蓝色区域代表表现良好的部分（精准解决了客户的咨询问题和任务），黄色区域为中等水平（虽解决了任务，但伴有大量无关信息），红色区域则是表现差劲的部分（回答与客户问题完全不相关）。中间图展示了 DAU 和客户问题数，右图则是留存率。

目前，我们的留存率实际上已经达到了一个相当高的水平（PPT 并未刷新数字）。从图中可以清晰地看到，随着准确度的持续提升，DAU 和留存率也在稳步上升。反之，如果 DAU 和留存率始终停滞不前甚至下滑，即使你的工程和算法团队声称准确率很高，那无疑是自欺欺人的。

实际上，很多工程算法团队成员可能并未意识到这一点。我之所以能明确指出这一点，是因为在左图的准确度指标上，我也曾经多次被误导，但这也并非团队有意为之。在如今的信息环境中，随便搜索公众号就能发现大量类似“用这一招你的准确率能提升到 95%”的文章，但这些文章往往存在误导性。它背后都有一个前提条件，即在某个狭窄的小场景下，准确率能够达到 95%，然而在面对海量问题时，这一指标却难以提升（这一点稍后会详细分享）。

定义好了产品和运营指标（Define），往下走才是执行（Exectute）阶段。

Exectute 阶段的关键在于：一定要用产品和业务目标来拉动。因为在牵引拉动的过程中，才能充分动员领域知识专家的参与和评测。 如果没有知识专家的深度参与和强大的评测能力，大模型的应用上限是很难提升的，这是第一点。第二，如果项目目标缺乏价值，或者没有真正的痛点，那么会发现得不到资源的“祝福”。也就是说，一方面难以获得其他团队的配合，另一方面自身团队的价值感也难以维持，这将直接影响项目的推进。

在整个执行逻辑中，金字塔最下面是工程的数据与评测，我把这个放成最大的一块底座，因为这是基石——业务数据、业务 API 以及评测能力是大模型应用的基础，对这一部分的投入必须充足。在这一基础上，才是工程应用算法、预训练（Pre-training）、RAG 以及微调等等，这些在媒体报道里面出现的技术热词，并非不重要，但这些只是 “必要条件”。我观察到，大多数产研团队在这部分（工程 - 应用与算法）投入了 80% 至 90% 的时间。但我想强调的是：这些只是必要条件，仅靠这些无法解决企业 E2E 落地的问题。哪怕你在必要条件上投入再多，再加 10 倍的努力，也无法实现真正的 E2E 落地。因此，必须设法补齐真正实现 E2E 落地所需的充分条件。 如果无法做到这一点，项目成功的希望将十分渺茫。

在与业务团队沟通以及处理各种复杂问题的过程中，我们总结出了几种常见的模式： 首先是基础设施层面，涉及知识和数据的构建；中间是编排和调度，无论是大家熟悉的工作流编排，还是智能体自主规划编排，或是两者的结合；最上面是对客的产品与运营。

这里，我重点讲述深蓝色部分的两种模式：第一个是翻译模式，第二个是 Agent 模式，我认为主要分为这两种典型的应用模式。其中，翻译模式最容易取得成效，因为它相对简单；而智能体模式则较为复杂。

先谈谈翻译模式。 在公司内部，我们将所有翻译类模式统称为 AI 领域的“低垂果实”，这类模式相对容易实现。这一轮的大型语言模型背后的算法是 Transformer。Transformer 最早是 Google 为了翻译任务而开发，在不停做翻译的过程中衍生出了 Transformer 算法。随后，预训练模型如 BERT 也大量应用于翻译领域。所以，大模型的原理 Transformer 特别擅长做翻译。

翻译又可以分为狭义翻译和广义翻译。狭义翻译指的是中译英、英译中等语言之间的转换。而广义翻译则涵盖更广泛的形式，比如：自然语音转成文本，再转成语音；自然语言转成 SQL 语言；自然语言转成 Java 语言；甚至让一篇论文用自然语言“翻译”成中学生能听懂的表述，这些都属于广义翻译范畴。无论是狭义翻译还是广义翻译，Transformer 都特别擅长，因此这是最容易出结果的地方。

但这里有一个坑： 虽然（图中）左边的翻译能力已经具备，但如果右边原有的系统还没准备好（not ready），就会出现问题。

以 Chat BI 来说，为什么 Chat BI 在企业里没什么成功的案例呢？其实很大一部分原因在于，Chat BI 的逻辑无外乎就是：用自然语言翻译成 SQL，然后在后台的数据库或大数据系统里执行，再把执行结果取出来，再翻译成自然语言返回给人。它的实质，就是自然语言 → SQL → 执行结果 → 自然语言，这本质上还是一种翻译。

但我们会发现一个很有意思的问题：很多企业说要上 Chat BI，但如果原本数据库和里面的业务逻辑、数据口径积累不足，甚至连人都写不出对应的 SQL 来，那自然语言也一样翻译不出来。因为后台本身没有可执行的基础。所以我认为，企业里绝大部分在 Chat BI 上踩的坑，都来自于一开始就想做一个过于“宽”的东西。但是做了这个翻译之后，如果原来的系统 API 没准备好，数据没准备好，甚至连原来的人都无法执行这些操作，那自然语言翻译也没法落地。这就是最大的误区。

因此我们在内部的逻辑是：要先****Identify 原系统具备哪些能力。比如，如果你原来的 ODPS、数据库和数据中台本身已经有 BI 和运营，能够在某个领域里不断取数、用 SQL 分析数据，而且业务场景也很丰富，那么，那些高频的 SQL 语句才是真正值得作为翻译目标的部分，而不是盲目地去做一个 Chat BI。

所以很关键的是要分成两个部分 ：一部分是翻译，一部分是原来系统的语言处理能力。我习惯这么来形容：原来的系统就是“蛋糕坯”，大模型翻译就是上面的“樱桃”。如果你现有的蛋糕坯是 ready 的，我放一个樱桃上去，你就可以吃樱桃蛋糕了。但是如果原来的蛋糕坯都没有，你让我做一个樱桃蛋糕，那是做不出来的。

所以，这里非常关键的一点就是：你要能够识别出原来的蛋糕坯是不是 ready ，然后在上面放上你的樱桃，而不是直接拿一个樱桃就装作是樱桃蛋糕。这个地方往往就是个误区。

翻译模式是低垂的果实，容易做，但里面其实有非常多的坑。

再说 Agent 应用模式。大家可以注意这样一句话：所有的 Agent 应用模式都是始于用户意图，终于意图满足。如果你不是从用户意图出发，最后又不是以是否满足客户意图来作为度量标准去看待你的智能体，那一定会失败，没有任何成功的可能性。这是我发现团队甚至整个业界，最容易出现的问题。因此我们引出了一个方法，这是我在内部做智能体时，一定要去践行的方法。

第一件事情，要找到这个领域的“意图空间”。 当一个客户在智能体里和你交互时，他一定是带着意图的。那么这些意图都有哪些？比如客服场景里，客户会提出各种咨询问题，这些问题本质上就是一个空间、集合。所以，第一步就是要搞清楚这个集合的 边界和完整性。如果你不知道它的完整性，就无法去度量。只有在建立了完整的意图空间之后，才能继续往下做。

所以第一件事要建立意图空间。然后，当清楚地知道了意图空间，就要基于这个意图空间来准备 知识工程。也就是说，你的知识、文档是否完备？API 和结构化数据是否具备？能否真正满足客户的这些意图？我认为这是最基础的必要条件。

再者，有了知识、意图空间，接下来才能带着意图去做评测。 因为你既知道用户的意图，也掌握了知识，这样才能真正开展工作。如果意图不清楚、知识不具备，那其实就是“空转”。

我们的经验是：在客服场景里构建意图空间，从原来就在满足意图的领域出发，从 工单 里去分析和构建意图空间。有了意图空间之后，就可以对意图进行分类。分类完成后，再根据不同类别去检查和补全知识，做好知识工程。这样，当 意图空间 和 知识空间 都建立好了，才有可能开展评测，也才知道如何去度量你的 Agent。只有具备了度量能力，才有可能进一步做工程和算法迭代，这个是原理决定的。这也是我们在内部做智能体的一个必修课。

所以我简单总结一下两个模式： 翻译模式是樱桃，一定要先找到原来的蛋糕坯在哪里，再把樱桃放上去。如果蛋糕坯不 ready，只放个樱桃一定会失败。而 Agent 模式的关键则是：始于用户意图，终于意图满足。 这是一系列完整的逻辑方法。

接下来我们就展开讲这个稍微复杂一些的 Agent 模式，看看在业务体系里实现 E2E 落地的一些关键要点。

第一件事情，就是对意图空间的投入进行 ROI 评估。你做一个 Agent，它的 ROI 高不高？这取决于意图空间的大小。如果工程所需的知识量庞大，意图也非常多、非常宽，那么所需要的投资就会非常大。意图空间越大，你为满足这些意图所需要的知识、工程和迭代的投入也就越大。

所以有一个非常清晰的结论：第一件事情就是要控制意图空间的规模。如果不控制规模，会导致失败，因为后续的投入很难支撑。这里要记住一句话：如何去控制一个智能体的意图空间？如果这个没有控制好，或者不清晰，那么 ROI 根本算不出来。而一个算不出 ROI 的项目，成功的可能性将大打折扣。

第二， 我们经常讲，最近大家肯定也听说过，在 AI 领域里经常提到一个词叫 品味。AI 时代里，品味非常重要。 那么品味来源于哪里？我自己猜测，要追溯到 1995 年乔布斯（Jobs）的一次采访。当时记者说：听说你比较粗暴、比较独裁，你怎么知道你的决定就是对的呢？乔布斯想了大约 10 秒，回答道：“归根结底，最后是品味决定的。”这和这一轮 AI 的关键问题——评测——高度相关。

这一轮和上一轮 AI 革命最大的区别在哪里？ 上一轮深度学习主要是计算机视觉。那时候的数据评测怎么做？一张图给猫、狗、交通灯、汽车、人等等打圈，数据打标就是这么来的。所以评测时，只需要看分类对不对（猫有没有被错分成狗？对了就好）。ImageNet 就是这样做的，李飞飞当年找了很多外包团队来做标注，这种标注工作很适合外包，找普通人就能做。原因很简单，猫狗识别不难，就算是一些专家领域，比如故障识别、次品检测，标注也相对容易。

但这一轮情况完全不同。大模型的输入是小作文，输出也是小作文。在专业领域尤其如此，很难直接度量。这就是为什么要强调品味——因为没有标准答案。我们都是经历过高考的。高考作文有没有标准答案？没有。开放题，比如写一篇中心思想总结，有没有标准答案？也没有。大模型的评测正是如此。所以，这一轮大模型最关键的区别在于：度量数据、评测没有标准答案。而既然这是没有标准答案的，就意味着成本最高，也成为落地的瓶颈。 如何解决这个瓶颈？只能重投入。

所以这里讲的“品味”，其实就是如何做评测的问题。 而只有在基于前面那些要素的基础上，你才能真正开展评测工程。无论是人工评测，还是后续的自动化评测，都高度依赖于前面提到的一些要素。因为它是非标的，是没有标准答案的东西。那为什么现在编程发展很快？因为数学和编程都有标准答案，可以被编辑器校验，但是纯文本是没有标准答案的。

在这个过程中有一个非常重要的点叫 E2E 归因，因为在智能体的过程中会有非常多的环节，在这么多工作流和智能体的编排逻辑中，如果一个意图没有被满足，我们必须要有能力确定这个 Bad case 的问题到底出在哪个环节。每一个 Badcase 都应该归因到工程里的具体环节，才能对具体的原因进行聚类和改进。

下图这是个大概率的经验总结，也就是说，如果你具备度量能力，会发现 大部分问题都出现在数据层面，出现在非结构化、结构化数据 API。如果基本能力不具备，这就是智能体失败的主要原因。部分问题可能出现在知识预处理、意图识别、上下文检索以及后续的意图识别总结等环节。数据极为重要，但没有评测也就谈不上数据。

另一个经常被讨论的问题：是否需要引入模型训练？我们的观点非常明确：必须在白盒方式下使用基模 API，注重评测和数据，并进行 E2E 归因迭代。只有当数据质量和评测能力具备时，才能引入训练。 原因很简单，如果数据和评测能力不 ready，投入在训练上的每一分钱都是浪费。训练周期长、成本高，如果没有能力评估训练结果的好坏，也没有足够的数据进行训练，那么这种投入是不明智的。因此，只有在必须使用训练，且基模无法解决问题时，我们才会引入预训练。例如，当实时性要求很高时，我们可能会使用小模型进行训练以解决实时性问题，这被称为大小结合。只有在必要时才引入训练。

在 Agent 模式中，涉及从语音到文字、文字到语音的转换，以及大量 workflow 和 Agent 调度。最终，客户向我们提出需求，我们回应能够满足其意图。这是一个综合的“意图空间 + 意图满足”的过程，中间结合了各种体系，才能构建出真正能够服务客户、进行销售的智能体。

这与 Chat BI 类似，Chat BI 本质上也是 Agent 模式。除了将自然语言翻译成 SQL 之外，SQL 执行完后，结果需要用自然语言翻译回去。但关键在于底层的数据中台，以及原有的数据治理是否完善。如果原有系统（蛋糕坯）不够完善，就无法实现良好的 ChatBI 效果。ChatBI 本身只是一种技术手段，最终一定要识别出，对应领域是否已经有成熟的数据体系和成熟的数据分析，只有在此基础上再加上 AI，才能产生魔法般的效果。

总结与展望：搭乘“大电梯”

最后，我想给大家回顾一下。我们在阿里云内部推进 AI 转型，本质上是需要为业务提供 Result as a Service（RaaS）。我们可能是当前时点为数不多的，能够真正大规模实现 E2E 落地，给业务交付结果的实践团队。 而我们实现 Result as a Service 的方法叫 RIDE，RIDE 分别代表 Reorganize、Identify、Define 和 Execute。需要特别注意的是，在必要条件上再努力，也解决不了充分条件的问题，所以这个 RIDE 方法论的核心是在提醒大家，只有把落地所需要的充分条件补齐，才能真正开展 AI 企业有效落地的工作。

呼应最开始讲的“电梯”，我想讲的是，冰山之上，我带着团队一直在做业务的数字化转型，之所以能够实现，是因为冰山之下，有我们强大的阿里云作为底座。无论是我们涵盖通义千问在内各种模型服务的 MaaS 百炼，还是 PAI，ODPS，数据库等 PAAS 服务、或是底层 IaaS 比如 ECS，灵骏，存储，网络服务，都是我们依赖的企业应用有力支撑武器。而这些能力的成本在不断下降，功能也在持续拓展。所以，当企业选好了一个强大的技术底座，随着技术水平的增长和成本的下降，企业的数字化转型也就能够搭上一个更好的“电梯”。我自己也认为，阿里云就是这样一个“大电梯”，企业上云后，这个电梯就能持续为企业实现数字化转型提供源源不断的上升动力。

今天我的演讲就到这里，感谢大家。

会议推荐

10 月 23 - 25 日，QCon 上海站即将召开，现在 8 折优惠最后 3 天，单张门票立省 1360 元，详情可联系票务经理 18514549229 咨询。