阿里云CIO蒋林泉首次公开分享：如何借助RIDE框架实现企业级AI大模型落地，避免踩坑。
核心内容：
- 阿里云在不同业务场景的AI大模型落地实践经验
- 解决组织内部AI认知差异和转型挑战的关键方法
- 业务部门与IT部门在AI项目中的协作矛盾与解决方案
AI大模型技术发展迅猛，但要在企业真正落地，坑点和难点不少。本文整理了阿里云智能集团CIO蒋林泉在AICon 2025深圳的分享——“阿里云大模型应用落地实践之路”。这次演讲基于阿里云CIO线在文档、翻译、客服、电销、合同审核、BI、员工服务、研发等场景的数字人项目经验，涵盖了从组织挑战、业务机会识别，到AI产品定义、运营指标设计，再到产品工程落地的系统性思考。
其中，面对企业内部AI认知和能力水平参差不齐的问题，探讨了如何快速实现组织转型，打造适配AI发展的生产关系和文化共识。同时，深入剖析了业务和IT部门在AI项目中普遍存在的预期差矛盾，并分享了协调协作、动员业务专家参与数据准备和评测、统一预期等挑战的解决方法。
以下是演讲实录。
观察与思考
这是我担任阿里云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交流的过程中，这种现象大量存在。企业里会涌现很多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数字人必须有一个目标——在原有具体的业务流程里，接管一个重复且有价值的任务，并能折算出“相当于拓展出多少人力”，这就是唯一的目标。
要真正让数字员工上线、上岗，必须满足两个标准条件：一是数字人执行原来任务的效率一定要比原来提升一定百分比，效率一定要比人高；二是效果上也要比原来提升一定百分比。只有当数字人做到效率高、效果好时，才能“正式上岗”，进入业务部门工作。
接下来是业务机会的识别（Identify）
解决了组织问题后，业务部门会说，好，我们来联合培养数字员工。那从哪里开始？
这一轮AI革命的核心是LLM（large language model）。我们在内部有一个逻辑：所有以language为中心的工作，都将被大模型深刻影响。比如电销、客服、招聘、OKR、文档、翻译、合同审核，还有研发类的C language、Ja va language、SQL language等。所以第一个特征是Language类工作。
第二个特征是被重复执行、规模化执行——因为AI是自动化的，越大规模、越重复的任务，AI越有机会做。第三个特征是，如果本身缺人，甚至有人投诉效率低，那这个地方就是个大机会。这三个特征是我们与业务部门一起识别哪些业务可以着手的关键点。把问题定义清楚了，后面做事才会顺畅。如果解决错了问题，投入就白白浪费了。
另外，在对应任务里拓展目标（对应岗位的人力），具体怎么核算？
经验是：有些单任务岗位，比如技术翻译，是按字收费的。AI翻译一个字多少钱，就可以直接线性替换。一个人一天产能可能是翻译2万字，那就折算成2万字产能等同于一个人。如果是多任务岗位，比如产品经理，一会儿做PRD，一会儿分析工单，一会儿画Demo，一会儿去客户访谈。这种多任务岗位，往往有些任务是重复、繁琐、非高价值的。我们依然可以做出对应的数字人，帮这些关键、复杂、不可替代的岗位，把繁琐任务卸载出来，折算出对应岗位的人力。财务、法务这种高价值多任务岗位，把最繁琐的审核工作卸载出来，让他们聚焦在更高价值的工作上，幸福感也会爆棚。
过了 Identify，下面是 Define
在这个时代做产品和以前有很大不同。前面提到的产品大多有交互、体验，和上一轮移动互联网产品没区别。但AI产品有一个特别关键的点——准确率。当然，还有响应时效性和安全合规等非功能性指标。比如电销过程中和客户实时对话，延迟必须非常低，否则客户会觉得交流效率不高，像机器人说话。实时性和准确性非常关键。如果准确性不够，客户根本无法使用，也不可能真正上岗。所以，准确率是AI项目的第一核心指标，整个项目组都必须盯住它，这也是产品定义中最核心的部分，必须重新Redefine。
此外，运营指标同样至关重要。如果只有产品指标和准确率指标，大概率会掉到坑里。即使在对内的业务项目中，原来移动互联网那些基本功也不能丢，比如：
DAU（每日活跃用户数）；
用户提问数；
渗透率，即目标客户的覆盖率；
留存率（最关键）。
如果同一个客户今天用了，下周还愿意继续用，说明这个AI智能体真正帮他解决了问题。如果只用了一次就不再回来，那前面产品指标再漂亮也没意义——可能定义错了问题。运营指标就是用来兜底的，如果不紧盯这些指标，很容易让产品、工程和算法团队陷入“自嗨”——“我的指标很好”，结果客户根本不用。
举个例子，在阿里云官网的AI助理中，设定了这样的度量方式。左图展示了准确度度量指标，时间线大约覆盖从去年到今年的一年时间。蓝色区域代表表现良好的部分（精准解决了客户咨询问题和任务），黄色区域为中等水平（虽解决了任务但伴有大量无关信息），红色区域是表现差劲的部分（回答与客户问题完全不相关）。中间图展示了DAU和客户问题数，右图是留存率。
目前留存率已相当高（PPT未刷新数字）。从图中清晰看到，随着准确度的持续提升，DAU和留存率也在稳步上升。反之，如果DAU和留存率停滞不前甚至下滑，即使工程和算法团队声称准确率很高，无疑是自欺欺人。
很多工程算法团队成员可能并未意识到这一点。能明确指出这点，是因为在左图准确度指标上，我也曾被多次误导——但并非团队有意为之。如今随便搜索公众号就能看到大量“用这一招准确率能提升到95%”的文章，但这些文章往往有误导性——背后都有一个前提条件，即在某个狭窄小场景下准确率能达到95%，面对海量问题时却难以提升（稍后详细分享）。
Define好了产品和运营指标，才进入执行（Execute）阶段
Execute阶段的关键在于：一定要用产品和业务目标来拉动。因为在牵引拉动的过程中，才能充分动员领域知识专家的参与和评测。如果没有知识专家的深度参与和强大评测能力，大模型应用的上限很难提升。第二，如果项目目标缺乏价值或没有真正痛点，会发现得不到资源的“祝福”——一方面难以获得其他团队配合，另一方面自身团队的价值感也难以维持，直接影响项目推进。
在整个执行逻辑中，金字塔最下面是工程的数据与评测——我把这个放在最大的一块底座，因为这是基石——业务数据、业务API以及评测能力是大模型应用的基础，对这一部分的投入必须充足。在此基础上，才是工程应用算法、预训练、RAG以及微调等。这些媒体热词并非不重要，但只是“必要条件”。观察到大多数产研团队在工程应用与算法部分投入了80%至90%的时间。但想强调的是：这些只是必要条件，仅靠这些无法解决企业E2E落地问题。哪怕在必要条件上再加10倍努力，也无法实现真正E2E落地。必须设法补齐真正实现E2E落地所需的充分条件。如果做不到，项目成功希望渺茫。
在与业务团队沟通和处理复杂问题过程中，总结出几种常见模式：基础设施层面涉及知识和数据构建；中间是编排和调度（工作流编排或智能体自主规划编排，或两者结合）；最上面是对客的产品与运营。
这里重点讲述深蓝色部分的两种模式：第一个是翻译模式，第二个是Agent模式。翻译模式最容易取得成效，相对简单；智能体模式则较复杂。
先谈翻译模式
在公司内部，将所有翻译类模式统称为AI领域的“低垂果实”，相对容易实现。这一轮大模型背后的算法是Transformer，最早是Google为翻译任务开发，在不停做翻译过程中衍生出来。随后BERT等预训练模型也大量应用于翻译。所以，大模型的原理Transformer特别擅长做翻译。
翻译又分为狭义翻译和广义翻译。狭义翻译指中译英、英译中等语言转换。广义翻译涵盖更广泛形式，比如自然语音转文本再转语音，自然语言转SQL语言，自然语言转Ja va语言，甚至让论文用自然语言“翻译”成中学生能听懂的表述。无论是狭义还是广义，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年乔布斯的一次采访。记者问：听说你比较粗暴、比较独裁，你怎么知道你的决定就是对的？乔布斯想了大约10秒，回答：“归根结底，最后是品味决定的。”这和这一轮AI的关键问题——评测——高度相关。
这一轮和上一轮AI革命最大的区别在哪里？上一轮深度学习主要是计算机视觉。那时数据评测怎么做？一张图给猫、狗、交通灯、汽车、人等打圈，数据打标就是这么来的。评测只需看分类对不对（猫有没有错分成狗）。ImageNet就是这样做的，找很多外包团队来标注，适合外包找普通人就能做——猫狗识别不难，专家领域如故障识别、次品检测标注也相对容易。
但这一轮完全不同。大模型输入是小作文，输出也是小作文。在专业领域尤其如此，很难直接度量。这就是为什么强调品味——因为没有标准答案。我们都是经历过高考的，高考作文有没有标准答案？没有。开放题——写一篇中心思想总结——有没有标准答案？也没有。大模型的评测正是如此。所以，这一轮大模型最关键的区别在于：度量数据、评测没有标准答案。既然没有标准答案，就意味着成本最高，也成了落地的瓶颈。如何解决这个瓶颈？只能重投入。
所以这里讲的“品味”，其实就是如何做评测的问题。只有在基于前面要素的基础上，才能真正开展评测工程。无论是人工评测还是后续自动化评测，都高度依赖于前面提到的要素。因为它是非标、没有标准答案的东西。为什么现在编程发展很快？因为数学和编程都有标准答案，可以被编辑器校验，但纯文本没有标准答案。
过程中有一个非常重要的点叫E2E归因。在智能体过程中有非常多环节，在这么多工作流和智能体的编排逻辑中，如果一个意图没有被满足，必须有能力确定Bad case的问题出在哪个环节。每个Bad case都应归因到工程里的具体环节，才能对具体原因进行聚类和改进。
下图是个大概率的经验总结：如果具备度量能力，会发现大部分问题出现在数据层面——非结构化、结构化数据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，分别代表Reorganize、Identify、Define和Execute。特别需要注意的是，在必要条件上再努力也解决不了充分条件的问题。RIDE方法论的核心是提醒大家：只有把落地所需的充分条件补齐，才能真正开展AI企业有效落地的工作。
呼应最开始讲的“电梯”：冰山之上，我带着团队一直做业务数字化转型，能实现是因为冰山之下有强大的阿里云作为底座。无论是通义千问等模型服务的MaaS百炼，还是PAI、ODPS、数据库等PAAS服务，或是底层IaaS如ECS、灵骏、存储、网络服务，都是我们依赖的企业应用有力支撑。这些能力成本在不断下降，功能也在持续拓展。所以，当企业选好了一个强大的技术底座，随着技术水平增长和成本下降，企业数字化转型就能搭上一个更好的“电梯”。阿里云就是这样一个“大电梯”——企业上云后，这个电梯就能持续为企业数字化转型提供源源不断的上升动力。
今天我的演讲就到这里，感谢大家。