瑞幸咖啡 x 阿里云合作共创：AI 推荐让瑞幸咖啡“更懂你
在新零售不断演进的今天，用户走进瑞幸，要的不只是咖啡，更是一种“被真正理解”的体验——口味、习惯、场景，甚至那一刻的心情。作为国内领先的连锁咖啡品牌，瑞幸咖啡正从数字化迈入智能化新阶段，以人工智能技术驱动“人、货、场”核心业务平台的智能化重构，构建面向未来的智慧商业决策体系。为此，瑞幸与阿里云深度共创，基于阿里云人工智能平台PAI，共同打造了一套真正“以用户为中心”的端到端智能推荐系统。它不再依赖静态规则，而是通过理解用户的偏好和需求，为用户提供贴心的咖啡选择建议——无论是清晨提神的美式，还是周末慵懒的生椰拿铁，当你唤醒AI Lucky，“为你而选”的新品、优惠与搭配，就会送到你眼前，让每一次选择都更轻松、更安心。过去依赖人工规则的推荐方式，难以动态响应用户变化；如今，借助双方联合打磨的数据链路、算法模型与运营机制，瑞幸不仅实现了推荐精准度的跃升，也让用户获得更流畅、更贴心的服务体验。这次合作，是瑞幸AI能力体系进化的重要一步，更是与阿里云“一起设计、一起验证、一起交付、一起沉淀”的技术共创典范——不是单方面交付产品，而是共同构建面向未来的智能零售能力。从规则驱动到 AI 驱动：赋能增长新范式截至2025年第三季度，瑞幸咖啡已建立起覆盖全国超2.9万家门店的庞大网络。随着用户规模持续扩大，瑞幸咖啡也在不断探索新技术增加对于客户的理解，为客户提供更加灵活的服务，促进增长的发展。为探索AI赋能增长新范式，瑞幸致力于构建一套具备高精度、可迭代、可扩展能力的AI推荐系统。经过多轮技术评估与方案论证，瑞幸最终与阿里云大数据AI平台合作共创，采用MaxCompute+DataWorks+Flink+Hologres+PAI技术架构，以PAI-Rec作为其新一代推荐引擎，依托其强大的大数据、算法能力与全链路服务支持，开启提升用户推荐体验的智能化升级。与客户共创，助力客户能力沉淀此次合作不仅是技术产品的落地，更是一次深度的“技术共创”实践。阿里云技术团队与瑞幸技术团队紧密协作，全程参与需求分析、POC验证、系统上线与效果优化。在项目推进过程中，阿里云技术团队与瑞幸团队高效协同，高质量完成多组对比实验，并组织多次技术交流，协助瑞幸系统性地沉淀了数据处理规范、特征工程方法、模型调优策略及测试体系，为其后续自主迭代与业务扩展打下坚实基础。展望未来：AI 驱动“更懂你的咖啡”本次合作不仅为瑞幸带来了显著的业务升级，也为阿里云人工智能平台PAI在零售行业树立了标杆案例。“本次与阿里云合作的AI智能推荐场景，提供的不仅是一个工具、一个解决方案，更是一次双方共创合作经验的落地。”瑞幸技术负责人表示，“从POC到全量上线，阿里云团队展现了极强的技术实力与服务意识。我们相信，AI将成为瑞幸持续领跑行业的重要引擎。”一杯咖啡的背后，是海量数据的流转与AI模型的精准计算。随着推荐系统的持续优化，瑞幸咖啡的运营模式实现“更智能、更个性、更高效”。未来，双方还将探索大模型在用户意图理解、生成式推荐、跨场景联动等方向的创新应用，进一步释放AI在消费场景中的潜力。瑞幸咖啡 x 阿里云大数据AI平台的合作，不仅是一次技术升级，更是AI赋能实体经济的生动实践。在智能化浪潮中，AI将成为您的专属咖啡助手——从海量风味中，AI推荐为您探索意想不到的惊喜之选，让咖啡更懂你。阿里云 AI 推荐方案：打造端到端智能推荐引擎下面将重点介绍阿里云AI推荐方案在该场景中的技术亮点与应用优势。阿里云AI推荐方案是面向企业级场景的全托管推荐算法服务平台，深度融合阿里巴巴在电商、本地生活等高并发、高实时性场景下的推荐实践经验，提供从数据处理、特征工程、模型训练、测试验证到在线服务的一站式解决方案。在本次合作中，阿里云为瑞幸咖啡量身打造了覆盖“数据 → 模型 → 服务 → 迭代”的完整推荐链路：端到端系统搭建：基于全托管架构的阿里云大数据AI平台，搭建实时推荐全链路，快速构建从数据采集、实时特征计算、深度学习模型训练到在线推理的全流程系统，实现毫秒级响应的AI推荐服务。精准转化率提升：通过引入深度CTR/CVR预估模型、多目标优化（MMOE）及序列建模（如DIEN），显著提升推荐内容的相关性与转化效率。经测试验证，最终转化率较原有规则系统提升明显。全托管运维，释放技术负担：依托人工智能平台PAI的自动化运维与弹性伸缩能力，瑞幸团队得以从繁重的系统维护中解放，聚焦核心业务创新，大幅降低AI落地门槛。阿里云智能推荐系统解决方案阿里云为企业开发者提供全链路深度定制的推荐系统解决方案。方案涵盖了离线处理、在线服务、实时数据流和工程架构等多个维度，包括召回、排序、过滤和重排等功能模块，提供多种数据诊断分析、推荐结果调试和引擎发布管理等工具，通过A/B testing服务和实验报表平台提升推荐系统的迭代效率。搭建一套智能推荐系统，主要分为四个步骤：数据准备、离线训练、在线服务以及算法迭代。1. 数据准备基础埋点与采集：首先需完成用户行为数据的埋点采集，包括曝光、点击、加购、收藏及下单等核心行为。 基础表构建：进行数据ETL，产出三张核心基础表：用户表（包含属性及偏好标签）、物品表（包含类目、价格等属性）及行为表（记录用户与物品的交互时间及类型）。 数据智能诊断：对原始数据进行潜在问题分析，评估特征的可用性与覆盖率，确保模型训练的质量。2. 离线训练算法定制开发：对召回（如Etrec协同过滤）、粗排、精排（如DBMTL多目标训练）等算法的深度定制。 特征与样本准备：通过离线调度任务，完成特征抽取与正负样本构造。统一管理离线特征，确保离在线特征的一致性。 模型训练与调优：模型训练，并利用AutoML进行自动调参，提升模型性能。3. 在线服务推荐引擎部署：部署召回和排序模型，处理在线推理请求。特征实时读取：在线推理时，推荐引擎高性能存储中读取用户和物品特征，并传递给PAI-EAS打分。联调与测试：上线前进行全链路联调，验证特征一致性，并观察推荐结果是否符合预期业务逻辑。4. 算法迭代AB实验监控：通过配置AB实验报表实时观察AB实验效果。在实验结束后，进行数据诊断任务以深入分析实验表现。闭环优化：根据实验结果调整特征和样本，或者调整模型架构后重新训练。特征自动挖掘：引入 AutoFE（自动特征工程） 技术，利用算法自动挖掘新特征，进一步提升推荐的精准度。搭建一套智能推荐系统方案，主要依赖的云产品，包括：PAI-Rec、PAI、FeatureStore、MaxCompute+Dataworks等。PAI-Rec使用EasyRec训练召回和排序模型，使用PAI-Rec引擎搭建推荐系统；通过 DataWorks 编辑和调度特征工程、样本和模型训练的代码；使用特征数据库FeatureDB存储用户特征、i2i相关物品和向量库；使用PAI-EAS 提供可弹性扩缩容的打分服务。具体说明如下：人工智能平台PAI：面向开发者和企业的机器学习/深度学习工程平台，提供包含数据标注、模型构建、模型训练、模型部署、推理优化在内的AI开发全链路服务。EasyRec算法框架：内置业界先进的深度学习模型，支持多种Tensorflow版本（>=1.12, <=2.4, PAI-TF)和 PyTorch 版本，覆盖了推荐全链路的需求，包括召回、粗排、排序、重排、多目标和冷启动等。开发者可基于EasyRec算法框架加速迭代推荐全链路需求。大数据开发治理平台DataWorks/云原生大数据计算服务MaxCompute:基于云原生的大数据服务，可搭配使用，针对推荐系统中特征处理、样本生成、画像管理、模型调度、数据更新等环节，提供了易用的开发工具和稳定的数据环境。特征平台管理工具FeatureStore：用于存储和管理离线和在线服务中的特征数据，确保了从离线到在线的特征统一与高效复用。同时，整合了阿里云上DataHub、Flink、Hologres和Tablestore等产品，并且自研了搜索推荐专用的特征数据库FeatureDB，提供特征管理功能。这套“MaxCompute+DataWorks+Flink+Hologres+PAI”深度融合的技术架构，是面向零售、金融、出行等多行业场景的通用型智能数据中台范本。无论是构建AI驱动的推荐系统，还是实现全域数据资产的价值释放，阿里云Data+AI系列产品都能为企业提供从“数据到智能”的全栈赋能。未来已来，智能不止于推荐。让每一次交互更懂用户，让每一份数据创造价值——阿里云大数据与AI产品组合，助力企业驶入智能化快车道。
为什么程序员不自己开发一个小程序赚钱
大家好，我是凌览。个人网站：blog.code24.top去水印下载鸭：nologo.code24.top如果本文能给你提供启发或帮助，欢迎动动小手指，一键三连（点赞、评论、转发），给我一些支持和鼓励谢谢。刷到一个挺扎心的话题：程序员为什么不自己做产品赚钱。身边还真有不少人问过类似的话："你天天写代码这么厉害，怎么不自己搞个App、做个小程序？随便弄弄不就发财了？"每次听到这种问题，我都不知道该从哪儿开始解释。最近在 X 乎上看到同行的回答，看完只能说：太真实了。理想很丰满、现实很骨感首先，假装我们是程序员，某天深夜加班回家，瘫在沙发上刷手机，突然一个念头炸开——"我去，这个功能市面上根本没有！我要是做一个，肯定爆火！”。脑子里的画面瞬间清晰：产品上线、用户疯涨、投资人排队、财务自由...，满脑子都是"老子不干了，要创业"。说干就干，流程走起来：第一步：注册账号结果发现邮箱早就被自己多年前注册过，还冻结了。解冻、换邮箱，折腾一圈。第二步：想名字绞尽脑汁想了个好名字，一搜，已被占用。再想想想，终于通过。第三步：开发前端后端一把抓，不会前端？没事，Ai结伴编程一把梭。uniapp启动，一套代码多端运行，微信、QQ、抖音、快手平台全都要上。第四步：买服务器，阿里云一核两G，一年600块，付款的时候手还没抖。第五步：搞域名，随便挑一个，一年30块，便宜。第六步：备案到这里，噩梦开始了。拍照、填表、等审核，来来回回折腾。好不容易过了，提交小程序审核——"该项目类型个人不支持，需要企业认证。"卒。亏损-630元。但程序员嘛，头铁。不信邪，继续：第七步：注册公司个体户要经营场所，干脆直接注册公司。准备材料、开对公账户、刻公章，又是一顿操作。第八步：重新认证企业认证要的材料堆成山，干脆重新注册个小程序。又是想名字（原来的还要等两天才能释放）、填资料、承诺书、盖章...终于，小程序上线了。上线只是开始，赚钱才是难题。每天努力宣传、引流，结果广告收益长这样：昨日收入0.65元。对，你没看错，六毛五。折线图上的曲线在0.3元到1.8元之间反复横跳，月收入6.72元。服务器钱还没赚回来，先赔进去几百块。什么会这样？个人开发者不能收费，只能通过挂广告，而广告收入低到离谱。激励广告单价居然只有4.29元/千次展示，Banner广告更惨，几块钱千次展示。算笔账：日访问量要达到2万，才能日入500。2万UV什么概念？很多小公司的官网一天都没这么多人。推广难，小程序是个封闭生态，你不能诱导分享，否则直接封号。只能从其他平台往微信导流，但用户路径一长，流失率奇高。要开通流量主还得先引流500人，这第一道门槛就卡死不少人。审核机制让人头大，页面上文字一多，就说你涉及"内容资讯"，不给过。个人开发者经营类目受限，动不动就踩红线。不是技术问题，是商业问题程序员不做小程序赚钱，不是因为不会写代码，而是因为写代码只是万里长征第一步。做一个能赚钱的小程序，需要：产品能力：做什么？解决谁的什么问题？凭什么用你的？运营能力：流量从哪来？怎么留存？怎么变现？商业资质：公司、对公账户、各种许可证，合规成本不低；时间和精力：白天上班，晚上搞副业，服务器半夜挂了还得爬起来修。而大多数程序员，只是喜欢写代码而已。让他们去搞流量、谈商务、处理工商税务，比写一万行代码还痛苦。更扎心的是，就算你愿意干这些，小程序的红利期也早过了。2017年刚出来那会儿，确实有人靠简单工具类小程序赚到第一桶金。现在？各大平台库存量几百万个，用户注意力被某音、被红书切得稀碎，新入局者基本就是炮灰。成功案例网上经常能看到"做小程序月入过万"的帖子，但仔细看会发现，要么是卖课的，要么是有特殊资源的（比如手里有公众号矩阵导流），要么是早期入局者吃到了红利。对于普通程序员来说，接个外包项目，按时薪算可能比折腾三个月小程序赚得还多，还省心。技术只是工具，商业才是战场。会拿锤子的不一定会盖房子，会写代码的不一定能做出赚钱的产品。这不是技术问题，这是两个完全不同的赛道。最后所以，开发一个小程序到底能不能赚钱？能，但跟你关系不大。要么你有现成的流量池，比如几十万粉丝的公众号、抖音号，小程序只是变现工具；要么你有特殊资源，比如独家数据、行业资质；再要么你踩中了某个极小概率的风口，比如当年疫情期间的健康码周边工具。否则，个人开发者大概率是炮灰。写代码是确定性的事，输入逻辑输出结果；做生意是概率性的事，投入不一定有回报。 大多数人适合前者，却误以为自己能驾驭后者。你呢？有没有过"做个产品改变世界"的冲动？最后成了吗？
腾讯云这两天全量上了 passkey 登录，刚才试了一下，登录后竟然还要微信扫码校验，太逆天了。阿里云都上了不知道多久了，而且也不需要二次校验，之前的 200M 服务器也是摸着阿里云过河，抄都不会抄真是连一根毛都比不过
【体现撒娇稚嫩的萝莉女声，音调偏高且起伏明显，营造出黏人、做作又刻意卖萌的听觉效果】Qwen3-TTS
【体现撒娇稚嫩的萝莉女声，音调偏高且起伏明显，营造出黏人、做作又刻意卖萌的听觉效果】还得是阿里📌 转载信息来源： https://linux.do/t/topic/1507026原作者： Yuanjia转载时间： 2026/1/24 06:45:54
阿里云可观测联合 Datadog 发布 OpenTelemetry Go 自动插桩工具
作者：杨易（青风）在云原生可观测性领域，OpenTelemetry 已经成为事实上的标准。相比于 Java 拥有成熟的字节码增强技术，Go 语言作为静态编译型语言，长期以来缺乏一种成熟、低侵入的自动插桩方案。目前的现有方案主要有：eBPF：功能强大但主要偏向系统调用层面，对应用层上下文（如 HTTP Header 传播）的处理较为复杂。手动埋点：代码改动大，维护成本高，不仅要改业务代码，还得改依赖库的调用方式，显式地在各个关键节点添加 Trace 和 Metrics 逻辑。为此，阿里云可观测团队和程序语言团队探索了 Go 编译时插桩解决方案，并将其核心能力捐赠给 OpenTelemetry 社区，形成了 opentelemetry-go-compile-instrumentation [ 1] 项目。在和 Datadog、Quesma 等公司的共同努力下，我们发布了首个预览版本 v0.1.0 [ 2] 。工作原理自动插桩工具的核心在于利用 Go 编译器的 -toolexec 参数。-toolexec 会拦截 Go 编译命令，替换成我们的插桩工具。这样，在代码被编译之前，我们就有机会对它进行分析和修改。整个过程可以概括为两个阶段：1. 依赖分析在编译开始前，工具会分析应用的构建流程（go build -n），识别出项目中使用的第三方库如 net/http, grpc, redis 等。然后，它会自动生成一个文件otel.runtime.go，将对应的 Hook 代码（监测逻辑，后面用 Hook 代码表示）引入到构建依赖中。2. 代码注入当编译器处理目标函数时，工具利用 -toolexec 拦截编译，然后修改该目标函数的代码，在函数入口插入一段蹦床代码（Trampoline Code），蹦床代码会跳转到预先写好的 Hook 函数中。进入函数前（Before）：Hook 记录开始时间，提取上下文信息（如 HTTP Headers），启动 Span。函数执行：执行原有的业务逻辑。退出函数后（After）：Hook 捕获返回值或 Panic，结束 Span，记录耗时。这种方式的优点是零运行时开销（除了必要的监测逻辑执行时间），因为插桩是直接编译进二进制文件的，不需要像 eBPF 那样在内核态和用户态之间切换，也不需要像 Java Agent 那样在启动时加载。HTTP 插桩示例让我们通过一个简单的 HTTP 例子来看看它是如何使用的。package main import ... func main() { http.HandleFunc("/greet", func(w http.ResponseWriter, r *http.Request) { w.Write([ ]byte("Hello, OpenTelemetry!")) }) log.Fatal(http.ListenAndServe(":8080", nil)) }手动插桩需要手动引入 OpenTelemetry SDK，手动创建 Tracer，在 Handler 里手动 Start 和 End Span。package main import ... func initTracer() func(context.Context) error { /* ...几十行初始化代码... */ } func main() { // 1. 初始化 Tracer shutdown := initTracer() defer shutdown(context.Background()) // 2. 包装 Handler handler := http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) { // 3. 手动提取 Context，开始 Span tracer := otel.Tracer("demo-server") ctx, span := tracer.Start(r.Context(), "GET /greet") // 4. 确保结束 Span defer span.End() // 5. 可能还需要手动记录属性 span.SetAttributes(attribute.String("http.method", "GET")) w.Write([]byte("Hello, OpenTelemetry!")) }) // 6. ListenAndServe 也可能需要包装... log.Fatal(http.ListenAndServe(":8080", handler)) }对于成百上千个接口的微服务，这种改造成本是灾难性的。自动插桩下载工具：到 Release 页面 [ 2] 下载编译应用：./otel-linux-amd64 go build -o myapp配置运行：export OTEL_EXPORTER_OTLP_ENDPOINT="http://localhost:4317" export OTEL_SERVICE_NAME="my-app" ./myapp编译器会默默地将 HTTP 请求的监测逻辑“织入”到应用二进制文件中。配置好 OpenTelemetry 的导出端点（如 Jaeger 或控制台），运行生成的 server。访问 /greet 接口时， Tracing 数据已经自动生成并上报了，包含了请求路径、耗时、状态码等信息。从商业化到开源我们在深度实践 eBPF 技术的过程中，虽然认可其强大，但也发现它难以完美处理应用层上下文。更重要的是，我们不断听到用户反馈，大家对繁琐的手动埋点和高昂的维护成本感到困扰。为了解决这个痛点，我们开始探索 Go 编译时自动插桩方案，将其上线至阿里云可观测 ARMS 产品 [ 3] ，在这片最严苛的“试验田”里不断迭代，逐步演化成一套成熟的解决方案，不仅能实现零代码修改的链路追踪，还扩展支持了丰富的指标统计、Runtime 监控乃至持续剖析等高级功能，甚至还可以通过自定义扩展的功能完成对企业内部 sdk 的埋点 [ 4] 。调用链分析持续剖析这套方案在电商、短剧、AI 视频、汽车等众多领域客户处得到了成功验证。在看到它为用户带来巨大价值、并验证了其稳定性和可行性后，我们决定将其核心能力贡献给 OpenTelemetry 社区，希望它能成为一个普惠的技术。同时，我们与可观测领域的顶尖厂商 Datadog 协作，共同推进，最终促成了这个官方项目 [ 1] 的诞生。目前项目处于活跃开发阶段，欢迎大家试用、反馈并参与贡献，共同构建更美好的云原生可观测生态。相关链接：[1] OpenTelemetry Go 编译插桩项目https://github.com/open-telemetry/opentelemetry-go-compile-instrumentation[2] Release 链接https://github.com/open-telemetry/opentelemetry-go-compile-instrumentation/releases/tag/v0.1.0[3] 阿里云 ARMS Go Agent 商业版https://help.aliyun.com/zh/arms/application-monitoring/user-g...[4] 自定义扩展https://help.aliyun.com/zh/arms/application-monitoring/use-ca...
作者：望宸每个时代基础设施的变革，都始于对“混乱”的优雅重组。19 世纪，钢铁把不可控的垂直空间变成工程秩序，城市才得以向上生长；20 世纪，电网将分散的能源重新编排，工业生产才不再被河流左右。而如今的 IT 领域，我们正面临一场新的秩序重建，即如何让海量、碎片化、动态变化的观测数据，不再是噪音，而成为可理解、可推理、可优化智能体行为的燃料？要回答这个问题，我们先简单回溯下：IT 系统的可观测体系是如何走到今天的？IT 系统中可观测体系的发展最初，企业面向单一数据类型构建监控体系，CPU 使用率、内存占用、磁盘 I/O……一个个孤立的指标就像烽火台，只能通过局部视角告诉我们“什么地方出了问题”。但随着微服务、容器技术的普及，系统复杂度呈指数级增长。企业开始意识到：单点指标无法解释全局。于是开始对孤立的数据进行抽象，抽象出 Metrics（指标）、Traces（链路追踪）和 Logs（日志），并进行关联分析：Metrics： IT 系统是否有问题；Traces： 哪里出了问题；Logs： 问题是由什么原因导致的。发展至今，成为观测体系的三大数据支柱。但从海量、异构、动态变化的数据中准确推理并定位问题，本质上是一个极其困难的逆向工程。数据只是现象，而现象与本质之间往往存在巨大的认知鸿沟 [ 1] 。Metrics、Traces 和 Logs 这看似完整的三角，实则仍停留在现象观测层面，是 L1 级智能体的典型工作流，人工设计流程节点、人工配置触发、人工调用 API，再把指标、链路、日志喂给 AI，期望它自己找出因果，结果往往是幻觉式归因：把时间上的巧合当作逻辑上的因果。为什么？因为在 AI 面前，缺少对系统本质的建模。在 AI 时代，加剧了这种模式的挑战。一是 LLM 驱动的应用带来了上下文的碎片化。运维工程师每天要在不同的控制台之间切换，手动拼凑“发生了什么”。这就像在信息高速公路上骑自行车，工具很先进，但认知方式仍是人力驱动。二是相比由工程师写的代码定义的传统 IT 系统，AI 带来了更多的不确定性，指数级提升了原始数据自动化关联的难度，给准确推理并定位问题的挑战添了堵。总结起来，原本的认知鸿沟，被进一步分化成三层新的鸿沟 [ 2] ：数据鸿沟：原始数据混杂、碎片化、噪声多，99% 以上可能是无效信息，难以从中有效提取信号。模型鸿沟：AI 模型存在“黑盒”特性，推理过程难以解释；还可能出现“幻觉”，生成看似合理但不符合事实的结果。工程鸿沟：每天数 PB 级的数据采集、清洗、存储、计算，对性能、成本、安全性提出极高要求。数据到建模让一个没见过电路图的人，从一堆电压表读数中定位并恢复故障服务器，是不现实的。当前市面上大多数的 AI 运维助手，本质上仍是 L1 级智能体：它们被封装在一个封闭的对话框里，被动响应用户提问，背后是一连串预设的 if-else 规则或简单 RAG 检索。它们没有对系统结构的内生理解，无法主动推理依赖路径，更谈不上安全执行修复操作。而要迈向 L2 甚至 L3 级智能体，即能自主感知、规划、行动并持续学习的数字员工，就必须为其构建一个结构化的运行时上下文，不然只能靠人的经验来排查、定位和解决问题。这个上下文是经过建模、带有语义、支持查询与推理的图谱。有了这张图，智能体就能避免在数据海洋中盲目打捞，而是在一个有路标、有规则、有边界的城市中穿行。因此，出路不在更多的数据，而在更好的建模。先为 IT 系统建立一张认知地图。这张图要包含实体（主机、服务、数据库）、关系（调用、依赖、部署）、行为（日志事件、性能指标）以及它们之间的语义约束。只有在这张图上，智能体才能像经验丰富的老运维一样，快速定位故障并恢复生产。UModel 正是这张图的建模语言。我们需要从“数据驱动”转向“建模驱动”，从面向现象的观测，转向面向本质的建模，构建一个统一的上下文图谱，这正是 UModel 的使命。什么是 UModelUModel（Universal Observability Model）是基于图模型的可观测数据建模方法。又是图模型，又是建模，一听就很学术。通俗易懂的讲，就是用“画图”的方式，把一堆随机事件之间的概率关系理清楚，让复杂变简单，让模糊变清晰。因此，UModel 旨在通过标准化的数据建模方式，实现可观测数据的统一表示、数据建模与具体存储的解耦，从而实现智能分析。有了 UModel，智能体才能像经验丰富的老运维那样快速定位故障并恢复生产，成为可能。UModel 可以看成是阿里云可观测体系的数据建模基础。总的来讲，UModel 的核心思想，是为可观测领域打造一个认知操作系统，是一套标准化的数据建模方法，旨在弥合前文所述的三重鸿沟，为 AIOps 提供可解释、可扩展、可自动化的基础。接下来，我们从 UModel 的构成和使用方式来看看它是如何把零散、杂乱的可观测数据，画成一张结构清晰、智能体能理解的图。UModel 的构成和使用方式企业习惯于将系统中的每个组件，例如应用、容器、中间件、网关、数据库，视为独立的实体进行监控和管理，并为它们配置仪表盘，设置告警，追踪性能表现。传统的监控和查询工具，无论是基于 SQL 还是 SPL，其核心都是处理二维的、表格化的数据。它们擅长回答关于个体的问题（这个 Pod 的 CPU 使用率是多少？），但在回答关于关系的问题时却显得力不从心。当面对“这个服务的故障会影响哪些下游业务？”或“要访问到核心数据库，需要经过哪些中间服务？”这类问题时，传统工具往往需要复杂的 JOIN 操作、多步查询，甚至需要工程师结合线下架构图进行人脑拼凑。这种方式不仅效率低下，而且在关系复杂、层级深的情况下几乎无法完成。我们拥有了所有“点”的数据，却失去了一张看清“线”的地图 [ 3] 。因此，UModel 将要解决以下四个关键问题：1. 重新定义系统里有什么通过 Entity 来统一定义所有可观测实体的实例，包括容器实例、服务实例等，例如服务实例 "order-service"、Pod 实例 "web-pod-001"。2. 对实例进行建模通过 EntitySet 建立实体集，并进行实体建模。将系统组件抽象为 EntitySet，一个 EntitySet 可对应多个 Entity：基础设施实体：主机、容器、网络设备、存储系统；应用层实体：微服务、API 接口、数据库实例、消息队列；业务实体：用户会话、业务流程、交易订单；运维实体：部署环境、代码仓库、运维人员。除了进行实体建模，还需要进行：数据集建模：将日志、指标、链路追踪、事件和性能剖析等多种可观测数据类型抽象为 TelemetryDataSet，由此衍生出 LogSet、TraceSet、EventSet、ProfileSet、MetricSet 等更具体的观测数据集。存储建模：Storage 是 UModel 中数据集底层存储的抽象，定义了数据的实际存储位置和访问方式。通过存储建模，UModel 能够统一对接多种存储后端，为用户提供一致的数据访问体验。3. 对这些实体&实体集进行建联通过 Link，连接不同的数据集：EntitySetLink 定义 EntitySet 实体间的关系（如服务 A 调用服务 B）；DataLink 定义 EntitySet 与 DataSet 之间的关联（如某 Pod 产生哪些日志）；StorageLink 定义 DataSet 与 Storage 之间的关联。在此基础之上，自动生成实体拓扑图和数据关系图。4. 图查询图查询可以认为是发挥 UModel 这一可观测基建的关键能力。因为系统的真实形态本就是一张图，那么对它的查询和分析，也应该使用最符合其本质的方式——图查询。为了实现这一点，我们在 UModel 体系的核心构建了 EntityStore。它采用了创新的双存储架构，同时维护了 entity 日志库（存储实体的详细属性）和 topo 日志库（存储实体间的拓扑关系）。这相当于我们为整个可观测系统建立了一个实时更新的、可查询的数字孪生图谱 [ 3] 。基于这个图谱，我们提供了从易到难、层层递进的三种图查询能力，以满足不同用户的需求：graph-match： 为最常见的路径查询场景设计，语法直观，让用户能像描述一句话一样（“A 经过 B 调用了 C”）来快速查找特定链路。graph-call： 封装了最高频的图算法（如邻居查找、直接关系查询），通过函数式接口提供，用户只需关心意图（“找 A 的 3 跳邻居”）而无需关心实现细节。Cypher： 引入业界标准的图查询语言，提供最完整、最强大的图查询能力，支持任意复杂的模式匹配、多级跳跃、聚合分析，是处理复杂图问题的终极武器。这一整套解决方案，旨在将强大的图分析能力，以一种低门槛、产品化的方式，让智能体实现自主发现、定位故障，并恢复生产成为可能。过去，运维靠人脑串联孤立的数据和几十个工具；未来，UModel 希望能作为可观测的基础设施，支撑智能体在统一上下文图谱中工作。当可观测数据被建模为可理解、可行动的上下文图谱，AIOps 才真正拥有了落地的土壤。相关阅读：[1] UModel 数据治理：运维世界模型构建实践[2] 从数据孤岛到智能洞察：构建面向未来的 Operation intelligence 体系[2] 打通可观测性的“任督二脉”：实体与关系的终极融合
很久之前就听说了 iflow，刚出来的时候还是限时免费，火了一段时间，今天再进去看，发现变成永久免费了，不过这玩意不会跟阿里云盘的永久不限速同出一辙吧
云原生为基，AI为翼：回望阿里云云原生的2025年
阿里云 CIO 全面深度解析：企业 AI 大模型落地实践「 RIDE 方法论」
据麦肯锡发布的《The state of AI in 2025》全球调研报告揭示，88% 的企业已在至少一个业务职能中常规使用 AI（如 IT、营销、知识管理），但 62% 仍处于实验或试点阶段，仅有少量实现企业级的规模化部署。我们可以理解为，当下企业的 AI 落地正呈现“高采用、低价值”的典型特征，多数企业卡在试点到规模化之间。麦肯锡《The state of AI in 2025》报告AI 应用进入深水区，竞争的核心已经转向规模化的落地能力，而非技术本身。这也指向一个重要问题：当下的 CIO 群体，想真正实践 AI 大模型在企业的有效落地，实现规模化价值，要化解过程中的诸多坑点与难点。本文整理自阿里云智能集团副总裁、 CIO 蒋林泉在 AICon 2025 年 8 月所分享的 “阿里云大模型应用落地实践之路”，并完整呈现他对企业 AI 落地的经典方法论“RIDE”和数字人案例。文中，通过规模化上线的 28 个数字人的成功实践经验，分享从组织共识挑战、业务机会识别，到 AI 指标衡量，再到产品工程落地的体系化思考，以蒋林泉的第一视角，解析企业 AI 真实落地的系统路径。第一视角观察这是我自担任阿里云 CIO 三年以来，第一次对外发表演讲。此次分享浓缩我过去三年在阿里云带领团队推进数字化与智能化进程中沉淀的案例与经验。在担任 CIO 之前，我主要负责阿里云飞天核心系统的产品和研发工作，当时对外的演讲内容更多围绕飞天和阿里云的产品，角色也更偏向于“乙方”的产研身份。而今天，以阿里云 CIO 的身份首次对外演讲，更多是站在“应用开发者”的角度，分享如何在企业内部场景中推进数字化和智能化落地的一些实践与体会。阿里云智能集团副总裁、 CIO 蒋林泉过去两三年，我带领团队致力于推动 AI 大模型在企业各类场景中的落地应用，在这个过程中有很多感触。想先谈一下，在这个阶段里的一些观察和思考。在当今时代，我们常常会思考一个问题：一个人或者一个组织发展得这么好，到底是时代的原因，还是自己努力的原因？其实最主要还是时代的原因。我们能够发展到今天，很大程度上是因为坐在了一个很好的“电梯”。比如搭上了中国这个电梯，中国互联网的电梯，以及我所在的阿里巴巴这个平台的电梯。平台本身发展得很好，在上面自然也发展得很好。换句话说，在电梯里做俯卧撑，还是在平地上做俯卧撑？两者达到的高度是不一样的。个人努力固然重要，但更重要的是平台。我认为，在这个时代，AI 就是那个最大的电梯。无论是组织还是个人，有没有搭上 AI 这趟电梯，将直接决定在未来能够达到的高度。ARK INVEST 报告根据 ARK INVEST 以往的一份调研报告预测，到 2030 年，算力性能相较于现在将增长 1000 倍。这是什么概念？在 AI 时代之前，我们常常讲摩尔定律，技术性能大约每 18 个月翻一番。而在 AI 时代，技术发展的速度被极大地加快了。如果不能及时搭上 AI 这趟高速电梯，大概率会落后于时代。基于这样的认识，我们发现，无论是企业还是个人，都开始逐渐意识到 AI 的重要性。意识到这一点后，许多企业，包括 CEO 和业务部门，开始变得焦虑起来。这就涉及到，这一轮科技革命与以往的科技革命最大的不同之处。在整个信息技术产业中，无论是 PC 互联网还是移动互联网时代，技术在企业中的应用过程是一个渐进的过程，非常循序渐进。那个时候，企业的 CEO 看到业界的炒作、厂商的炒作，都比较冷静，可以慢慢来。然而，这一次的情况却截然不同。我觉得这是第一次，企业 CEO 和业务部门比 IT 团队、比供应商还“上头”。因此，我们可以说，现在企业内部最大的矛盾，就是业务部门在社交媒体、PR 渠道里看到的 AI，往往呈现出一些“炸裂”、“梦幻”的效果，而 IT 部门或者说 CIO，在实际生产力上的发展却是不均衡、不充分的。这种矛盾体现得非常突出。在阿里巴巴集团内部，以及我与业界几十位 CIO 交流的过程中，观察到，在企业内部，这种现象大量存在。企业中会涌现出很多 Idea，做出很多 Demo，上线很多技术平台，一个团队里，恨不得要搭好几套 Dify 平台，各种智能体平台都在搭建。但是，在这些过程中，还是技术主导比较突出，更多是拿着平台去做 Demo，业务方的参与往往比较浅层。这类现象在企业里是比较过剩的，可以说整个企业都充斥着类似的情况。与此同时，我在企业中普遍观察到，很多方面的投入都严重不足：是否真正深入到业务本身去做价值识别，或去正确地定义产品，以及如何开展知识工程（注意，这里我们不再仅仅是传统的软件工程，而是知识工程），还有我们强调的业务专家知识动员。因此，我们认为，如果要在企业里真正用好 AI，并且产生实际的业务结果，就要做非常大的投入。恰好，在这个领域，我们做了很多探索和实践。阿里云企业大模型应用实践落地接下来，想向大家展示阿里云内部企业 AI 大模型业务落地的全景图。在这张图中，我们可以看到很多“数字人”，无论是在阿里云的官方网站、CRM（客户关系管理系统）、业务支撑系统，还是在内容管理系统、人事管理系统中，这些数字人都已经广泛地落地应用，并在原来的业务中发挥真实的效果。在过程中，我们已经落地了大约 28 个数字人项目，从中挑几个有代表性的例子来分享，让大家更有体感。AI 翻译数字人大家都知道，翻译是大模型非常擅长的事情。但在阿里云，我们遇到过很大的挑战。作为一家公共云服务提供商，为客户提供服务时，文档的作用至关重要（ ToB 的服务非常依赖文档）。阿里云拥有 300 多个产品，十几万篇文档，涉及上亿文字。其中有一个非常大的痛点在于“出海”，我们要出海到日本、美国、欧洲、印尼，还有土耳其，而我们的开发者要高度依赖文档，来操作云计算服务。问题在于，我们缺乏既懂本地语言，又懂云计算的人才，技术类的翻译必须同时具备这两方面的能力。但即使有足够的资金，也很难招聘到这样的人才。过去，我们只能选择“忍”，仅翻译了英文文档，以及部分日文文档，而其他语言的翻译工作基本停滞不前，这也导致海外开发者的反馈不佳。在这一轮 AI 技术突破之前，我们尝试过用传统 NLP 来做翻译，但效果根本不行。到了 ChatGPT 3.5 版本，我们发现自然语言处理技术，仍然无法满足我们的需求。而到了 ChatGPT 4 版本，我们再次尝试发现，翻译质量终于能和那些“既懂技术又懂本地语言”的专业译者打平。而且，当时也做了计算（时间在一年多前），每篇文档的翻译成本，仅为当初专业技术翻译团队的 1/200。从那时起，我们开始大量使用大模型进行翻译工作，到现在，我们已经完成了印尼语的全部翻译工作。这意味着，解决了原本靠资金也无法解决的组织问题。如果用专业的评分来看，过去，用懂本地语言、懂技术的专业翻译团队来翻译，评分大约为 4.12 分（满分 5 分）。现在，我们用 AI 来翻译，评分能够达到 4.68 分。在海外市场，我们发现海外网站的用户体验以及 NPS（净推荐值）都得到了显著提升。因此，这不仅仅是一个成本问题，更是通过 AI 解决了过去无法解决的难题。技术文档验证数字人刚才提到，阿里云有十几万篇文档，覆盖三百多个产品。其中，有一半是操作指南和解决方案，客户需要完全依照这些文档进行操作。这里一个很大的问题是：传统 IT 产品可能是半年或一年一个版本，文档和产品可以同步开发。但我们是互联网模式的 IT 系统，我们的情况是，线上功能不停迭代，功能的迭代和我们文档的一致性，就要实时保证。原来，也是依赖外包团队进行文档验证和测试，由于“带宽”限制，只能解决中文文档的验证问题。每六个月会把所有文档“跑”一遍，去验证它们和线上功能是否一致，经常会发现有很多版本不一致的问题。但这个过程本身就有很大问题：首先一轮验证就需要六个月时间，当第一个月验证并修复好的内容，到第六个月，验证可能又变得不一致了。原来，我们一直没能把这个问题解决，导致客户经常会遇到功能与文档不符而操作不下去的问题，这就要求我们提供最新内容。现在我们是怎么做的呢？用 AI 来模拟这个过程：它会左边打开技术文档，右边操作浏览器里同步打开阿里云网站，然后严格按照文档里的步骤进行操作。过程中，AI 一旦卡住或无法继续，就大概率意味着文档和实际功能不匹配。虽然少数情况是云产品控制台本身的问题，但绝大部分的确是文档与功能不一致。当 AI 发现不一致时，它会立刻把不一致的“单拎”出来，并自动创建一个 Aone 需求单。我们后续还有一个“文档修复数字人”，它会“接手”这个 Aone 需求单，分析实际情况与文档描述的差异，并做修复。然后，它会把这个修复好的文档，给到我们 technical writer 做确认，确认后就能上线了。这之后，过去需要六个月才能完成一轮的验证工作，现在只要一个星期。同时，我们现在也把这套验证机制应用到日文、英文以及其他语种上，确保国际站的功能和文档也能保持一致。过去靠人工验证时，一致率到底是多少？验证质量好不好？覆盖度够不够？这些其实都是一个“unknown”的状态。而现在，一切都变得清晰、可量化了。网站 AI 助理数字人第三个案例是网站 AI 助理。阿里云有几百万客户，那我们的自服务模式是怎样的呢？我们来看一组数字：每天大约 97% 的客户访问阿里云，都是通过自助操作，只有 3% 的客户会选择“提工单”。而在这 3%的客户中，百分之七八十的任务也还是由自己解决的，只有极少数最终会变成需要人工介入的工单。所以，我们的客户绝大部分是自服务的。但即便如此，由于我们的客户基数太大，这“漏”进来的一小部分工单，依然需要我们服务团队投入大量人力去处理。在这些工单里，有一半都属于“咨询工单”。什么是咨询工单呢？就是客户遇到问题直接提问，我们的小二在后台查文档、翻知识库（Knowledge Base），找到答案再回复给他。这类工单纯粹是信息问答，不涉及操作。这类工单主要有几个问题：第一是一半的工单服务成本很高，第二是个时效问题。我们统计过，过去一个咨询工单的平均关闭时间，绝大部分要到 5 个小时左右。也就是说，一个客户平均想要解决这种咨询问题，需要花费大量时间才能解决。网站 AI 助理上线后，大量的咨询问题已经由 AI 直接回答了，而平均响应时间是 10 秒左右。目前，我们正在和服务团队合作，与服务团队共同承担全年工单降量，我们一起努力，希望通过 AI 在网站自服务的深入应用和渗透来实质拓展服务带宽，更重要的是，能够一起提升阿里云的客户服务体验。智能电销辅助数字人刚才讲的是服务，探讨了如何帮助客户解决咨询工单和自助诊断的问题，把服务体验提升了。现在来看另一个场景：销售。阿里云要服务上百万的企业，无法对每一家企业都用直销的方式去覆盖。因此，我们有很大一块业务是面向中小企业（SMB），通过电话销售来帮助我们客户实现售前咨询，以及售前购买的问题。电话销售小二的日常工作，主要分为话前、话中、话后三个环节。话前： 小二需要做计划，规划当天要打哪些电话、了解客户的商机、准备话术，并排好优先级。需要这样一个准备过程，才能保证一天的工作有序高效；话中： 就是与客户的实际沟通；话后： 需要复盘，记录通话小结，整理哪些需要 follow-up，哪些需要申请折扣。需要处理的问题都要记下来，这样才能闭环到后续的业务处理，形成一个完整闭环。现在，我们在这三个环节都提供了 AI 数字人。● 在“话前”，由 AI 来完成通话计划，包括怎么打，话术是什么。过去小二自己排计划要花半个多小时，现在一上班，计划就已经生成好了，可以直接开工。● 在“话中”，我们提供了一个智能辅助提醒。当小二与客户通话时，系统会根据对话内容，在工作台右侧实时提醒他如何回答，比如客户在说他想要这个，建议你这么回答。目前已经在辅助小二去解答客户非常复杂的一些云计算咨询问题。目前话中提示小二的采纳率已经达到了 50%。● 在“话后”，像通话复盘、撰写小记、follow up，包括后续的通话质检，这些工作都交给了一个自动化的 AI 数字人来完成。通过这种方式，我们的小二可以从繁杂的事务性工作中解放出来，集中精力在真正的销售沟通上，大幅拓宽了我们销售的服务带宽。同时，AI 的智能计划、实时辅助和后续复盘，也极大地提升了我们服务客户的质量。智能质检数字人AI 应用到电话质检之前，这几乎是一个原理上无解的事情。原来我们大规模的外呼电话作业过程，是非常难被知晓的。比如中间过程是否按照公司的作业规范进行？与客户的沟通是否足够礼貌？更有时候，有的外呼人员可能会把客户引导到私下公司去联系、去成交。但原来，我们是很难去做这个电话质检的，因为这是语音作业，很难管理。而现在，我们用 AI 把所有的电话语音全部智能化，从而识别里面所有的这些问题，再通过统一的质检标准，就能够得到一个规模化的质检。于是，这个 AI 质检能够大规模地提升我们的服务质量与效率，覆盖全量业务场景，关键还能控制我们的业务风险（避免产生额外的风险）。可以说，这件事我们原来几乎是无法搞定的，因为原来是靠抽样，也就是人工抽样去听那些电话录音，如果抽样抽到了问题，再去一个个处罚，但效率是非常非常低的。它的抽样完整性、抽样覆盖度都几乎是没法被使用的（覆盖度仅有 2%），不同质检员的判断差异也很大，对人力的消耗也很厉害。所以，现在通过 AI 质检数字人，能够让覆盖度提升到 100%，质检的准确率也远高从前，带来的最终效果是非常好的，这使得整个服务质量能够规模化地提升上去。智能外呼数字人刚才我们讲到 AI 如何辅助做事，这里则是一个能直接进行智能外呼的数字人。众所了解，云计算本身是非常复杂的，如何招聘到足够多的外呼坐席人员，让他们既具备相关技能，又熟悉云计算知识，同时还能够耐心地每天坐在工位打一天的电话，这对我们来说是一个巨大的痛点。因为招聘和能力培养难度很大，人员流动率非常高，这使得无论是销售服务，还是电话服务的质量，都存在明显的短板。本质来看，这是一个短线影响业务增长，长线影响服务满意度与企业品牌塑造的问题。我们在前期已经有一定的知识积累，包括语音、多模态等方面的经验，因此，我们通过 AI 的方式直接引入智能外呼。它直接上场，与我们的客户沟通，挖掘销售商机，交付给服务团队去做主动的服务。目前，在潜在客户的线索清洗、免费试用、转生产、以及产品即将到期的续费提醒等主动外呼场景中，这个数字人已经上线运行了。目前，我们还在开发场景包括产品到期的主动关怀、NPS 调研等，上线后，预计可以拓展出“能交付结果的”上百个 HC 的服务带宽。数字 AI 客服的外呼，还有些不一样的特征。首先，它可以灵活、快速地按需扩容，而且，它的声音可以做得更甜美，也可以做得更有情商。更重要的是，在技术的不断加持下，这个 AI 小二解决问题的能力，可能已经超过了原来人类员工的平均水平，而且还在不停地提升。目前，我们的智能外呼数字人可以像“金牌销售”一样工作，非常接近真人体验。未来会有更多的想象空间，让它能够更好地服务阿里云客户，提升我们的服务质量。直销辅助数字人分享了很多电销案例，这里谈谈“直销”场景。在阿里云的直销业务中，我们面临着一个核心挑战：销售如何变得更加专业和高效，促进公司业绩增长？在实际工作中，我们的销售团队遇到了两大业务痛点。第一个痛点：云计算销售要求高、招聘难、培养成本高。云计算销售不仅需要具备良好的客户拓展能力，还需要深入理解云计算技术与行业应用场景。复合型人才稀缺，招聘难度大、周期长，新人从入门到胜任，需要经历数月的培训与实战积累，培养成本居高不下。第二个痛点：销售运营专业服务带宽不足。销售运营、数据 BI、财务、法务等运营中台的服务带宽，无法充分支撑前线销售需求，难以及时响应每一位销售人员的专业支持诉求。为了解决这些问题，我们将整个销售流程分为“拜访前”和“拜访后”两个关键环节，在每个环节都提供 AI 数字人的全方位支持。核心围绕销售作业的有效性展开，让直销过程实现“在线化”，全面提升销售过程的辅助效率。拜访前：销售“一键”获取客户“谈参”，了解客户用云信息、技术类型、解决方案、竞对情况等全面画像。过去，销售自己从各渠道去查询要花 1 个多小时，现在，10 分钟就能查询到，而且信息质量更优、内容更全面，有效促进了与客户 key person 的高质量拜访。拜访后：我们提供 AI 对拜访过程的全方位复盘，包括商机要点是什么，客户对阿里云品牌表现出的情感倾向是什么，建议后续怎么推进客户成单。通过 AI 软硬结合的优势，我们让直销的销售过程实现“在线化”，高质量拜访小记达到 100%全面覆盖，新销售也能通过高质量在线信息资产快速学习，上手周期缩短 50%，大幅降低新人培养成本。这种方式，相当于拓展数百位专业销售运营为销售团队“贴身辅助”，销售人员得以从繁琐的流程性工作中解放出来，能够更专业、更高效地服务客户，大幅提升了销售有效性，有力促进了公司业绩增长。合同风险审核数字人ToB 业务的一大特征，是有大量的政企和大客户，他们通常不会使用我们的标准合同。这些合同金额巨大，需要进行严格的风险审核，涵盖财税法、风控、信控等多个方面的风险。过去，要完成这样的风险审核，我们需要专业的法务、财务等领域的精英人士，他们大多来自国际四大会计师事务所。然而，鉴于我们业务规模庞大，不可能招聘到足够多的精英来从事这项工作。因此，我们在合同风险审核方面遇到了巨大瓶颈，审核时间过长，最长甚至可达 5 个月，平均也需要两周到一个月。这极大地拖累了业务效率，包括服务大客户的效率。为了解决这一问题，我们培养了一大批“数字人”，包括财务数字人、信控数字人和法务数字人。并且，把这些数字人送到合同撰写端，让他们在销售和客户沟通、合同拟定的瞬间，就能够实时识别潜在风险并提示谈判方案，而不是等到审核端后才发现问题，再回过头去处理。在合同审核端，我们通过审核标准数字化、专家经验数字化，用统一的标准执行，极大提升了准确率。而 AI 也正是实现知识工作线下流程线上化的体现。通过 AI 技术，我们不断拓展中后台的服务带宽，解决商业拓展流程中的效率瓶颈。后续，我们也期望它在风险拦截上的能力，能够持续提升。员工服务数字人为什么特别提到员工服务数字人？因为大型企业里，HR 系统有一个显著特征，就是非常分散。比如请假、体检、福利、在职证明等，各式各样的流程和服务都散落在不同的系统里。与此同时，各类政策也同样分散，包括公司内部的福利政策、外部的人才政策等等。员工在需要获取这些信息或使用这些系统时，会遇到两个难点：第一，这些服务是低频使用的；第二，它们分散在不同地方，获取难度非常大。由于是低频服务，无法配备一个庞大的服务团队来支持，所以 HR 团队的负担很重，而员工的服务体验也不足。为了解决这一问题，我们将这些低频、分散的服务全部整合到一个智能体中，通过钉钉平台打造了一个“云小宝”（数字人），为员工提供统一的智能服务。我们发现，通过引入智能体，折算下来相当于节省或新增了几十名员工在为大家服务。更重要的是，员工的体验得到了极大提升，比如，我们服务员工的响应时长已经从平均 7.2 分钟缩减到 5 秒。再比如，员工只需要用自然语言输入，如“下周一请假”、“国庆前后两天请假”或“为父亲预约体检”，系统就能迅速响应并完成操作。面试智能辅助数字人还有一个场景，我们聊聊招聘。首先，我们对外招聘，核心是描述我们需要什么样的人。从这个角度出发，前置是 OKR，我们通过 AI 分析每个部门日常在做什么，目标是什么，根据日常目标和事情，去看清楚招聘的 JD（职位描述）是不是合理。再者，从 JD 开始，根据岗位要求，再结合当前的候选人简历信息，在面试的时候就会生成面试计划。面试时，结合岗位要求，面试官应该问哪些问题？根据最佳实践，怎么去考察候选人？这些专业问题在面试前，已经帮面试官提供好。面试中，通过对话过程，发现应该追问哪些问题，以及面试后，怎么总结面试过程中候选人是不是 qualified 这个岗位。通过 AI，我们可以更结构化、体系化地来做这件事，使得面试过程管理，面试质量，以及对面试人评价的客观性，都得到很大的提升。这也彻底改变了原来仅仅通过电话形式的面试，因为它的过程是一个黑盒逻辑，而“黑盒”最大的问题是无法提升过程的质量，包括保持长期的、闭环的有效性。对一家公司来说，招聘是件非常严肃的事情，我们经常讲，如果招错一个人，会导致后面的事情是非常糟糕的。所以本质上来讲，面试智能辅助数字人，提升了我们整个组织在招聘进人方面的有效性。这不只是效率问题，而是能够规模化促使我们在面试过程中的专业性、面试评价的专业性得到质的提升。28 个数字人全面上岗，真正产生业务价值目前，我们有二十几个场景实现了数字人的智能化服务，这里只是挑选了 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 时代的通识教育我们首先从 Reorganize 开始讲。在落地第一年，我发现了一个问题：无论是业务团队还是我们自己的团队，对大模型的能力边界、发展程度、具体原理等基本概念的理解都存在差异，甚至在我自己的团队，产品经理、算法、工程团队内部都无法拉齐概念认知。为了解决这一问题，我们发起了一个行动，叫 “书同文、车同轨”。 我们要求全员参加 AI 大模型的认证培训。最主要的原因，是要解决大家在基本功和认知逻辑上的差异。我称之为 “AI 时代的通识教育”，相当于要在团队里重新走一遍“高中的教育”。这一培训分为两类：大模型 ACA 认证（面向非技术人员）、 大模型 ACP 认证（面向技术人员），因为我们不仅需要技术人员之间能够对齐话语，也希望非技术人员和技术人员对齐话语。这种通识教育对于团队的协作至关重要，首先在我们 CIO 线内部已经完成了全员的认证，后面，我们的业务方，也就是我们的财务、人力、销售、中后台等都在做 全员认证。目前，整个阿里巴巴集团都在用这个方法来做 AI 转型的基础教育，重新建立大家的基础认知。不然就会出现这种情况：大家都在谈论同一个概念，但其实理解的内容和现实完全不同。如果没有做过深入工作，很难体会到那种无力感，一旦通过通识教育统一认知，沟通效率就会显著提升。阿里云大模型 ACA 认证：https://edu.aliyun.com/certification/aca13?spm=a2cwt.28380597.J_1564692210.17.28813487dUqGKW阿里云大模型 ACP 认证：https://edu.aliyun.com/certification/acp26?spm=a2cwt.28380597.J_1564692210.18.28813487dUqGKW「企业免费体验」大模型认证：https://edu.aliyun.com/learning/topic/llm-free-trial这样的基础上，又设计了两个比赛。一个是产研提效比赛，一个是业务提效比赛。和其他大赛最大的不一样，我们的比赛是真正以 E2E 为衡量标准的。 比如产研比赛，我们要看的，是原来 E2E 同样粒度的一个需求，需要多少“人月”完成，而现在能减少到多少人月。而不是看代码采用率，因为代码采用率很容易“灌水”，而且它往往只能补全那些最容易写的代码，最难的代码可不容易补全。在业务 E2E 方面，我们的比赛就是要真正进入业务场景，帮助业务去拓展，而且效果和效率都要超过原来。所以，这两件事非常重要，第一，是做“书同文，车同轨”的通识教育，因为 AI 时代的知识在不断发生巨变，每个月都在变，现实的实践知识和原来的基础知识都有大量的不同；第二，是“以赛促练”，整个组织通过正确目标下的比赛，大家会发现短板，发现相互之间可以学习的地方，就能够激发组织不断地去创新、去提效。数字员工 ：业务方与 IT 方 联合培养再说说我们的数字员工。有一个非常关键的安排：我们的这些数字人最后都是汇报给业务部门的。这不仅关乎形式，更重要的是心理。我们不能让业务部门觉得，AI 技术会威胁到他们的工作，而是要让他们明白，AI 技术是来帮助提效的。如果这个关系没处理好，就会遇到无数的暗礁。所以，我们把自己定位为数字人供应商，业务部门是 AI 先进组织，业务部门可以雇佣我们的数字员工，并与我们一起联合培养。 这样，业务部门会更愿意接受 AI 技术，减少阻力。所以这是第一点，我们把自己退到一个外包供应商的位置上。第二点，我们还发现，AI 数字员工是不能扛责任的，也不能给它打“3.25”（低绩效）。这意味着，数字员工在系统里执行任务出了问题，谁来承担的问题。我们将 AI 数字员工汇报到业务部门，属于业务部门的人（让他们放心），并一起参与 AI 员工的培养过程，同时数字员工也会受到正式员工的监督，来承担相应业务领域的责任。定标准 ：AI 要与人比，不与“神”比另外，我们经常听到一句话：ToC 还好，但 ToB 的大模型有幻觉，做不到 100% 正确。但实践经验告诉我们，其实人也有幻觉，而且人的幻觉还很大。如果认真看，在很多任务里，人其实也是不靠谱的，也经常会失败，只是企业没发现而已。我们强调的一点是：如果 AI 项目和业务部门真正达成了共识，并且通过培养逐步磨合，就必须认真回头来看，AI 的要求标准到底是什么？如果要求 100% 正确，其实就是把 AI 拿来和“神”比。但如果是和原来人做事的效果和准确率去对比，那就是和“人”比。所以，追求比人做得更好、更准，才是真正有意义的对标。那怎么避免和“神”比呢？回到前面所说，解决生产关系的问题，处理好内部业务的逻辑、目标和关系，这样才能真正实现 AI 和人比，而不是和“神”比。在整个 Reorganize 的过程中，我们还发现，要把数字人汇报到业务部门，对 HR 部门来说，这就等同一个“正式员工”。注意，我们是真的把它当作正式员工来看待的，用它能否产出真正的业务结果来度量。所以我们在内部与 CPO（HR 负责人）沟通时，讨论过：怎么去度量 AI 数字人是否真的发挥了一个正式员工的效果？最后，我们确定了一个方向：AI 数字人必须有一个目标，就是在原有具体的业务流程里，接管一个重复且有价值的任务，并且能够折算出“相当于拓展出多少人力”，这就是唯一的目标。但要 真正让数字员工上线、上岗，必须满足两个标准条件： 一是数字人执行原来任务的效率，一定要比原来提升一定百分比，一定要比原来执行任务的人效率高；二是数字人执行任务的效果，同样，也要比原来提升一定百分比。只有当数字人做到效率高、效果好时，才能“正式上岗”，进入业务部门工作。Identify ｜识别业务痛点与 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，一会儿又去客户那里访谈。这种多任务岗位，我们发现往往有些任务是重复的、繁琐的，也不是高价值的。为了提效，非常适合将这些低价值任务，拆分成一个个“单任务岗位”，如工单分析岗位、产品原型设计岗位等，让数字员工去做。这样，原岗位上的人就从繁琐工作中卸载出来，可以聚焦在更高价值的主线工作上，他们的幸福感也会爆棚。在换算方面，最终也都是”以单任务岗位为核心进行 HC 换算”，逻辑清晰明了。这种方式原先主要是由外包承接，但受制于外包员工管理难度大、成本构成多、招聘周期长、稳定性低、用工风险高、能力上限低（薪资因素）等诸多原因，多方面都受到约束，无法大面积展开。当我们有了数字员工之后，自然解锁了这些约束， 这件事就变得更加切实可行。 Define ｜AI 的产品度量与运营度量准确率是 AI 产品核心过了 Identify 这一步，下面就是 Define。这个时代和以前做产品有很大不同。我们前面提到的一些产品大多都类似，比如都有交互、体验。在这个流程里，其实和上一轮移动互联网的产品没有区别。但 AI 产品有一个特别关键的点，就是“准确率”。 当然，除了准确率之外，还有响应时效性和安全合规等非功能性指标，比如在电销过程中，和客户实时对话，延迟必须非常低，不然客户会觉得交流效率不高，像机器人说话一样。因此，实时性和准确性非常关键。如果准确性不够好，客户根本无法使用，也根本不可能真正上岗。所以，准确率是 AI 项目的第一核心指标，整个项目组都必须盯住它，这也是产品定义中最核心的部分，必须重新去 Redefine。运营与产品指标「协同度量」，才不掉坑此外，运营指标同样至关重要。如果只有产品指标和准确率指标，那大概率会掉到“坑里”。即使是在对内的业务项目里，原来移动互联网那些基本功也不能丢，比如：DAU（每日活跃用户数）；用户提问数；渗透率，即目标客户的覆盖率；留存率（最关键）。如果同一个客户今天用了，下周还愿意继续用，说明这个 AI 智能体真正帮他解决了问题。如果客户只用了一次就不再回来，那么无论前面的产品指标再漂亮，都没有意义，那可能就是定义错了问题。运营指标就是用来兜底的，如果不紧盯这些指标，很容易让产品、工程和算法团队陷入“自嗨”。什么叫自嗨？就是他们说“我的指标很好”，结果客户根本不用。举个例子，在阿里云官网的 AI 助理中，我们就设定了这样的度量方式。如下图所示，左图展示了准确度的度量指标，时间线大约覆盖从去年到今年的一年时间。蓝色区域代表表现良好的部分（精准解决了客户的咨询问题和任务），黄色区域为中等水平（虽解决了任务，但伴有大量无关信息），红色区域则是表现差劲的部分（回答与客户问题完全不相关）。中间图展示了 DAU 和客户问题数，右图则是留存率。目前，我们的留存率实际上已经达到了一个相当高的水平（PPT 中并未刷新数字）。从图中可以清晰看到，随着准确度的持续提升，DAU 和留存率也在稳步上升。但是反之，如果 DAU 和留存率始终停滞不前甚至下滑，即使你的工程和算法团队声称准确率很高，那无疑是自欺欺人的。实际上，很多工程算法团队成员，可能并未意识到上述这一点。之所以能明确指出，是因为在左图的准确度指标上，我也曾经被多次误导，但这也并非团队有意为之。在如今的信息环境中，随便搜索公众号就能发现大量类似“用这一招，你的准确率能提升到 95%”的文章，但这些文章往往存在误导性，它背后都有一个前提条件，即在某个狭窄的小场景下，准确率能够达到 95%，然而在面对海量问题时，这一指标却难以提升（这一点稍后会详细分享）。Execute ｜推进数据建设与工程落地掌握「产品研发工程金字塔」定义好了产品和运营指标（Define），往下走才是执行（Exectute）阶段。Exectute 阶段的关键在于：一定要用产品和业务目标来拉动。因为在牵引拉动的过程中，才能充分动员领域知识专家的参与和评测。 如果没有知识专家的深度参与和强大的评测能力，大模型的应用上限是很难提升的，这是第一点。第二，如果项目目标缺乏价值，或者没有真正的痛点，那么会发现得不到资源的“祝福”。也就是说，一方面难以获得其他团队的配合，另一方面自身团队的价值感也难以维持，这将直接影响项目的推进。在整个执行逻辑中，金字塔最下面是工程的数据与评测，我把这个放成最大的一块底座，因为这是基石——业务数据、业务 API 以及评测能力是大模型应用的基础，对这一部分的投入必须充足。在这一基础上，才是工程应用算法、预训练（Pre-training）、RAG 以及微调等等，这些在媒体报道里面出现的技术热词，并非不重要，但这些只是 “必要条件”。我观察到，大多数产研团队在这部分（工程 - 应用与算法）投入了 80% 至 90% 的时间。但想强调的是：这些只是必要条件，仅靠这些无法解决企业 E2E 落地的问题。哪怕你在必要条件上投入再多，再加 10 倍的努力，也无法实现真正的 E2E 落地。因此，必须设法补齐真正实现 E2E 落地所需的充分条件。 如果无法做到这一点，项目成功的希望将十分渺茫。常见的 LLM AI 应用范式：翻译、Agent在与业务团队沟通以及处理各种复杂问题的过程中，我们总结出了几种常见的模式： 首先是基础设施层面，涉及知识和数据的构建；中间是编排和调度，无论是大家熟悉的工作流编排，还是智能体自主规划编排，或是两者的结合；最上面是对客的产品与运营。这里，重点讲述图中深蓝色部分的两种模式：第一个是翻译模式，第二个是 Agent 模式，我认为主要分为这两种典型的应用模式。其中，翻译模式最容易取得成效，因为它相对简单；而智能体模式则较为复杂。翻译模式：关键在“蛋糕坯”先谈谈翻译模式。 在公司内部，我们将所有翻译类模式统称为 AI 领域的“低垂果实”，这类模式相对容易实现。这一轮的大型语言模型背后的算法是 Transformer。Transformer 最早是 Google 为了翻译任务而开发，在不停做翻译的过程中衍生出了 Transformer 算法。随后，预训练模型如 BERT 也大量应用于翻译领域。所以，大模型的原理 Transformer 特别擅长做翻译。翻译又可以分为狭义翻译和广义翻译。狭义翻译指的是中译英、英译中等语言之间的转换。而广义翻译则涵盖更广泛的形式，比如：自然语音转成文本，再转成语音；自然语言转成 SQL 语言；自然语言转成 Java 语言；甚至让一篇论文用自然语言“翻译”成中学生能听懂的表述，这些都属于广义翻译范畴。无论是狭义翻译还是广义翻译，Transformer 都特别擅长，因此这是最容易出结果的地方。但这里有一个坑： 虽然（图中）左边的翻译能力已经具备，但如果右边原有的系统还没准备好（not ready），就会出现问题。以 Chat BI 来说，为什么 Chat BI 在企业里没什么成功的案例呢？其实很大一部分原因在于，Chat BI 的逻辑无外乎就是：用自然语言翻译成 SQL，然后在后台的数据库或大数据系统里执行，再把执行结果取出来，再翻译成自然语言返回给人。Chat BI 的实质，就是自然语言 → SQL → 执行结果 → 自然语言，这本质上还是一种翻译。但我们会发现一个很有意思的问题：很多企业说要上 Chat BI，但如果原本数据库和里面的业务逻辑、数据口径积累不足，甚至连人都写不出对应的 SQL 来，那自然语言也一样翻译不出来。因为后台本身没有可执行的基础。所以我认为，企业里绝大部分在 Chat BI 上踩的坑，都来自于一开始就想做一个过于“宽”的东西。但是做了这个翻译之后，如果原来的系统 API 没准备好，数据没准备好，甚至连原来的人都无法执行这些操作，那自然语言翻译也没法落地。这就是最大的误区。因此我们在内部的逻辑是：要先 Identify 原系统具备哪些能力。比如，如果你原来的 ODPS、数据库和数据中台本身已经有 BI 和运营，能够在某个领域里不断取数、用 SQL 分析数据，而且业务场景也很丰富，那么，那些高频的 SQL 语句才是真正值得作为翻译目标的部分，而不是盲目地去做一个 Chat BI。所以很关键的是要分成两个部分 ：一部分是翻译，一部分是原来系统的语言处理能力。我习惯这么来形容：原来的系统就是“蛋糕坯”，大模型翻译就是上面的“樱桃”。如果你现有的蛋糕坯是 ready 的，我放一个樱桃上去，你就可以吃樱桃蛋糕了。但是如果原来的蛋糕坯都没有，你让我做一个樱桃蛋糕，是做不出来的。这里非常重要的一点是：要能够识别出原来的蛋糕坯是不是 ready ，然后在上面放上你的樱桃，而不是直接拿一个樱桃就装作是樱桃蛋糕。这个地方往往就是个误区。翻译模式是“低垂的果实”，容易做，但里面其实有非常多的坑。Agent 模式：关键在意图与知识空间再说 Agent 应用模式。大家可以注意这样一句话：所有的 Agent 应用模式都是始于用户意图，终于意图满足。如果你不是从用户意图出发，最后又不是以是否满足客户意图来作为度量标准，去看待你的智能体，那一定会失败，没有任何成功的可能性。这是我发现团队，甚至整个业界，最容易出现的问题。因此我们引出了一个方法，这是我在内部做智能体时，一定要去践行的方法。第一件事情，要找到这个领域的“意图空间”。 当一个客户在智能体里和你交互时，他一定是带着意图的。那么这些意图都有哪些？比如客服场景里，客户会提出各种咨询问题，这些问题本质上就是一个空间、集合。所以，第一步就是要搞清楚这个集合的 边界和完整性。如果你不知道它的完整性，就无法去度量。只有在建立了完整的意图空间之后，才能继续往下做。于是，第一件事要建立意图空间。然后，当清楚地知道了意图空间，就要基于这个意图空间来准备 知识工程。也就是说，你的知识、文档是否完备？API 和结构化数据是否具备？能否真正满足客户的这些意图？我认为这是最基础的必要条件。再者，有了知识、意图空间，接下来才能带着意图去做评测。 因为既知道用户的意图，也掌握了知识，这样才能真正开展工作。如果意图不清楚、知识不具备，其实就是“空转”。我们的经验是：在客服场景里构建意图空间，从原来就在满足意图的领域出发，从 工单 里去分析和构建意图空间。有了意图空间之后，就可以对意图进行分类。分类完成后，再根据不同类别去检查和补全知识，做好知识工程。这样，当 意图空间 和 知识空间 都建立好了，才有可能开展评测，也才知道如何去度量你的 Agent。只有具备了度量能力，才有可能进一步做工程和算法迭代，这个是原理决定的。这也是我们在内部做智能体的一个必修课。这里，简单总结一下两个模式： 翻译模式是樱桃，一定要先找到原来的蛋糕坯在哪里，再把樱桃放上去。如果蛋糕坯不 ready，只放个樱桃一定会失败。而 Agent 模式的关键则是：始于用户意图，终于意图满足。 这是一系列完整的逻辑方法。Agent 落地要点：意图空间、品味 &评测接下来，我们就展开讲这个稍微复杂一些的 Agent 模式，看看在业务体系里实现 E2E 落地的一些关键要点。第一，对意图空间的投入进行 ROI 评估。做一个 Agent，它的 ROI 高不高？这取决于意图空间的大小。如果工程所需的知识量庞大，意图也非常多、非常宽，那么所需要的投资就会非常大。意图空间越大，为满足这些意图所需要的知识、工程和迭代的投入也就越大。所以有一个非常清晰的结论：第一件事情，就是要控制意图空间的规模。如果不控制规模，会导致失败，因为后续的投入很难支撑。这里要记住一句话：如何去控制一个智能体的意图空间？如果没有控制好，或者不清晰，那么 ROI 根本算不出来。而一个算不出 ROI 的项目，成功的可能性将大打折扣。第二， 我们经常讲，最近大家肯定也听说过，在 AI 领域里经常提到一个词叫“品味”。AI 时代里，品味非常重要。 那么品味来源于哪里？我自己猜测，要追溯到 1995 年乔布斯（Jobs）的一次采访。当时记者说：听说你比较粗暴、独裁，你怎么知道你的决定就是对的？乔布斯想了大约 10 秒，回答道：“归根结底，最后是品味决定的。”品味和这一轮 AI 的关键问题——评测——高度相关。这一轮和上一轮 AI 革命最大的区别在哪里？ 上一轮深度学习主要是计算机视觉。那时候的数据评测怎么做？一张图给猫、狗、交通灯、汽车、人等等打圈，数据打标就是这么来的。所以评测时，只需要看分类对不对（猫有没有被错分成狗？对了就好）。ImageNet 就是这样做的，李飞飞当年找了很多外包团队来做标注，这种标注工作很适合外包，找普通人就能做。原因很简单，猫狗识别不难，就算是一些专家领域，比如故障识别、次品检测，标注也相对容易。但这一轮情况完全不同。大模型的输入是小作文，输出也是小作文。在专业领域尤其如此，很难直接度量。这就是为什么要强调品味——因为没有标准答案。我们都是经历过高考的。高考作文有没有标准答案？没有。开放题，比如写一篇中心思想总结，有没有标准答案？也没有。大模型的评测正是如此。所以，这一轮大模型最关键的区别在于：度量数据、评测没有标准答案。既然这是没有标准答案的，意味着成本最高，也就成为落地的瓶颈。 如何解决这个瓶颈？只能重投入。Agent 落地要点：如何做好「评测」 当然，这里讲的“品味”，就是如何做评测的问题。 我们怎么去评测？评测是一件非常重的事情，这包括业务效果的评测能力，也包括评测本身的工程化。具体来说，在人工评测中，我们如何去解决分类的标准问题？什么是“好”，什么是“中”，什么是“差”？如何能够确保，评测对真实业务意图的覆盖度是足够的？如果覆盖度足够好，标准也足够清晰，我们又如何通过工程化的方式，对系统的迭代和变动进行自动化评测？由于人工评测和度量，很多时候就像写一篇小作文，它是非标的，是没有标准答案的东西。相反，为什么现在编程发展很快？因为数学和编程都有标准答案，可以被编辑器校验，但是纯文本是没有标准答案的。所以，评测这项工作非常耗时，也很容易成为整个项目的瓶颈，是需要极大加强的。如果不去加强，那么整个项目的基石就可能动摇。在评测的过程中有一个非常重要的点，叫 E2E 归因。因为在智能体的过程中会有非常多的环节，在这么多工作流和智能体的编排逻辑中，如果一个意图没有被满足，我们必须要有能力确定这个 Bad case 的问题到底出在哪个环节。当每一个 Badcase 都应该归因到工程里的具体环节，才能对具体的原因进行聚类和改进。如果从产品宏观功能体系来看，体系的最底层，必须要有两样东西：第一，是业务评测；第二，是全链路的归因分析能力。我把这两项放在最底层，就是因为它们太重要了。下图这是个大概率的经验总结，也就是说，如果具备度量能力，会发现 大部分问题都出现在数据层面，出现在非结构化、结构化数据 API。如果基本能力不具备，这就是智能体失败的主要原因。部分问题可能出现在知识预处理、意图识别、上下文检索，以及后续的意图识别总结等环节。数据极为重要，但没有评测也就谈不上数据。引出一个经常被讨论的问题：是否需要引入模型训练？我们的观点非常明确：必须在白盒方式下使用基模 API，注重评测和数据，并进行 E2E 归因迭代。只有当数据质量和评测能力具备时，才能引入训练。原因很简单，如果数据和评测能力不 Ready，投入在训练上的每一分钱都是浪费。如果数据不够好，那就是“garbage in, garbage out”。这些问题，都不是训练本身能够帮助解决的。而且，训练的周期长、成本高、迭代速度慢，如果没有能力评估训练结果的好坏，也没有足够的数据进行训练，这种投入是不明智的。因此，只有在必须使用训练，且基模无法解决问题时，我们才会引入预训练。写在最后：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、灵骏、存储、网络服务，都是我们依赖的企业应用的有力支撑武器。而且，这些能力的成本在不断下降，功能也在持续拓展。所以，当企业选择了一个强大的技术底座，随着技术水平的增长和成本的下降，企业的数字化转型也就能够搭上一部更好的“电梯”。我自己认为，阿里云就是这样一部“大电梯”，企业上云后，这部电梯持续为企业实现数字化转型，提供源源不断的上升动力。