作者｜蔣林泉

編輯｜李忠良

策劃｜AICon 全球人工智能開發與應用大會

其中，面對企業內部 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 業務的特點，我們需要提供銷售和服務。但我們無法為每一家企業都配備專門的銷售人員和服務人員，因此，我們很大一部分銷售工作是通過電話進行的。我們有數千名服務人員和銷售人員需要通過電話為客戶提供服務。

然而這里有一個問題，云計算本身是非常復雜的，如何招聘到足夠多的外呼坐席人員，讓他們既具備相關技能，又熟悉云計算知識，同時還能夠耐心地每天坐在那里打一天的電話，這對我們來說是一個巨大的痛點。因為這樣的團隊招聘和能力培養難度很大，人員流動率非常高，這使得無論是銷售服務還是電話服務的質量，都存在明顯的短板。

第三個案例是合同風險審核

ToB 業務的一大特征，是有大量的政企和大客戶，他們通常不會使用我們的標準合同。這些合同金額巨大，需要進行嚴格的風險審核，涵蓋財稅法、風控、信控等多個方面的風險。過去，要完成這樣的風險審核，我們需要專業的法務、財務等領域的精英人士，他們大多來自國際四大會計師事務所。然而，鑒于我們業務規模龐大，不可能招聘到足夠多的精英來從事這項工作。

第四個案例是員工服務數字人

為什么特別提到這一點？因為在這么大的企業里，HR 系統有一個顯著特征，就是非常分散。比如請假、體檢、福利、在職證明等，各式各樣的流程和服務都散落在不同的系統里。與此同時，各類政策也同樣分散，包括公司內部的福利政策、外部的人才政策等等。員工在需要獲取這些信息或使用這些系統時，會遇到兩個難點：第一，這些服務是低頻使用的；第二，它們分散在不同地方，獲取難度非常大。由于是低頻服務，不可能配備一個龐大的服務團隊來支持，所以 HR 團隊的負擔很重，而員工的服務體驗也不足。

為了解決這一問題，我們將這些低頻、分散的服務全部整合到一個智能體中，通過釘釘平臺打造了一個“云小寶”（數字人），為員工提供統一的智能服務。我們發現，通過引入智能體，折算下來相當于節省或新增了大約 10 名員工在為大家服務。但更重要的是，員工的體驗得到了極大提升。比如，只需要用自然語言輸入，如“下周一請假”“國慶前后兩天請假”或“為父親預約體檢”，系統就能迅速響應并完成操作。

目前，我們有二十幾個場景實現了智能化服務，這里只是挑四個來舉例。這些數字人應用背后有 一個共同邏輯：一是折算拓展了多少人力；二是業務效率提升了多少；三是業務效果提升了多少。我們非常注重這一結構，因為每一個數字人上線落地，都必須衡量其對原來業務是否真正拓展了服務帶寬 ，并且，是否比原來人工操作的效率和效果更好，這是非常關鍵的，與外界所謂的眾多智能體最大的區別就在于此。

這些智能體最終都是在對應的崗位上實際工作的。在我們的 HR 系統中，這些數字人被分配到對應的業務部門，向對應的業務團隊匯報工作，與我們從外部招聘的員工沒有任何區別。所以，它們必須在對應的崗位和業務團隊中發揮超過一定人數的實際任務執行作用，才能真正融入團隊。在我們的釘釘系統以及內部工作系統中，這些數字人與普通員工一樣，擁有工號和頭像。唯一的區別在于，它們的工號以“AI”開頭，如 AI001、AI002，目前我們已經有大概 28 個智能體上線，后續還有更多智能體在排隊等待上線。它們與我們身邊的同事幾乎是一模一樣的。

過去兩年，在帶領團隊推進業務落地的過程中，我也深刻體會到，真正將技術應用于業務并取得成效，沒有那么簡單。特別是真正在業務中產生價值和僅僅做出一個 Demo 之間，是天壤之別。接下來，想和大家進一步分享，我們在這一過程中遇到的困難以及總結出的一些解決方法，希望能對大家有所幫助。

大模型 E2E 落地坑點與解法——RIDE

最近，大家可能聽過紅杉提出的一個概念叫 RaaS，即“結果即服務”。這一概念的核心在于，如果僅僅提供工具和產品，讓企業自行落地是不夠的。所以，我們特別重視真正上線并產生業務結果的項目。我作為 CIO 所帶的團隊，在企業內部為業務部門提供的，就是這種 “以交付結果為導向的服務”。在推進 RaaS 的過程中，我們也總結出了一套方法論，叫 RIDE。

當然，這套我們稱之為 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 的問題，就會不斷遇到暗礁，甚至沒法往前走。但解決了組織的問題后，業務部門會說，好，我們來聯合培養數字員工。那從哪里開始呢？

另外我們剛才講到，要在對應的任務里拓展目標，也就是拓展對應崗位的人力，具體怎么核算呢？

我們的經驗是，首先，有些單任務崗位，比如技術翻譯，我們是按字收費的。那 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 的，我放一個櫻桃上去，你就可以吃櫻桃蛋糕了。但是如果原來的蛋糕坯都沒有，你讓我做一個櫻桃蛋糕，那是做不出來的。

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

再說 Agent 應用模式。大家可以注意這樣一句話：所有的 Agent 應用模式都是始于用戶意圖，終于意圖滿足。如果你不是從用戶意圖出發，最后又不是以是否滿足客戶意圖來作為度量標準去看待你的智能體，那一定會失敗，沒有任何成功的可能性。這是我發現團隊甚至整個業界，最容易出現的問題。因此我們引出了一個方法，這是我在內部做智能體時，一定要去踐行的方法。

所以第一件事要建立意圖空間。然后，當清楚地知道了意圖空間，就要基于這個意圖空間來準備 知識工程。也就是說，你的知識、文檔是否完備？API 和結構化數據是否具備？能否真正滿足客戶的這些意圖？我認為這是最基礎的必要條件。

再者，有了知識、意圖空間，接下來才能帶著意圖去做評測。因為你既知道用戶的意圖，也掌握了知識，這樣才能真正開展工作。如果意圖不清楚、知識不具備，那其實就是“空轉”。

所以我簡單總結一下兩個模式： 翻譯模式是櫻桃，一定要先找到原來的蛋糕坯在哪里，再把櫻桃放上去。如果蛋糕坯不 ready，只放個櫻桃一定會失敗。而 Agent 模式的關鍵則是：始于用戶意圖，終于意圖滿足。這是一系列完整的邏輯方法。

接下來我們就展開講這個稍微復雜一些的 Agent 模式，看看在業務體系里實現 E2E 落地的一些關鍵要點。

第一件事情，就是對意圖空間的投入進行 ROI 評估。你做一個 Agent，它的 ROI 高不高？這取決于意圖空間的大小。如果工程所需的知識量龐大，意圖也非常多、非常寬，那么所需要的投資就會非常大。意圖空間越大，你為滿足這些意圖所需要的知識、工程和迭代的投入也就越大。

所以有一個非常清晰的結論：第一件事情就是要控制意圖空間的規模。如果不控制規模，會導致失敗，因為后續的投入很難支撐。這里要記住一句話：如何去控制一個智能體的意圖空間？如果這個沒有控制好，或者不清晰，那么 ROI 根本算不出來。而一個算不出 ROI 的項目，成功的可能性將大打折扣。

第二，我們經常講，最近大家肯定也聽說過，在 AI 領域里經常提到一個詞叫 品味。AI 時代里，品味非常重要。那么品味來源于哪里？我自己猜測，要追溯到 1995 年喬布斯（Jobs）的一次采訪。當時記者說：聽說你比較粗暴、比較獨裁，你怎么知道你的決定就是對的呢？喬布斯想了大約 10 秒，回答道：“歸根結底，最后是品味決定的。”這和這一輪 AI 的關鍵問題——評測——高度相關。

但這一輪情況完全不同。大模型的輸入是小作文，輸出也是小作文。在專業領域尤其如此，很難直接度量。這就是為什么要強調品味——因為沒有標準答案。我們都是經歷過高考的。高考作文有沒有標準答案？沒有。開放題，比如寫一篇中心思想總結，有沒有標準答案？也沒有。大模型的評測正是如此。所以，這一輪大模型最關鍵的區別在于：度量數據、評測沒有標準答案。而既然這是沒有標準答案的，就意味著成本最高，也成為落地的瓶頸。如何解決這個瓶頸？只能重投入。

所以這里講的“品味”，其實就是如何做評測的問題。而只有在基于前面那些要素的基礎上，你才能真正開展評測工程。無論是人工評測，還是后續的自動化評測，都高度依賴于前面提到的一些要素。因為它是非標的，是沒有標準答案的東西。那為什么現在編程發展很快？因為數學和編程都有標準答案，可以被編輯器校驗，但是純文本是沒有標準答案的。

在這個過程中有一個非常重要的點叫 E2E 歸因，因為在智能體的過程中會有非常多的環節，在這么多工作流和智能體的編排邏輯中，如果一個意圖沒有被滿足，我們必須要有能力確定這個 Bad case 的問題到底出在哪個環節。每一個 Badcase 都應該歸因到工程里的具體環節，才能對具體的原因進行聚類和改進。

另一個經常被討論的問題：是否需要引入模型訓練？我們的觀點非常明確：必須在白盒方式下使用基模 API，注重評測和數據，并進行 E2E 歸因迭代。只有當數據質量和評測能力具備時，才能引入訓練。原因很簡單，如果數據和評測能力不 ready，投入在訓練上的每一分錢都是浪費。訓練周期長、成本高，如果沒有能力評估訓練結果的好壞，也沒有足夠的數據進行訓練，那么這種投入是不明智的。因此，只有在必須使用訓練，且基模無法解決問題時，我們才會引入預訓練。例如，當實時性要求很高時，我們可能會使用小模型進行訓練以解決實時性問題，這被稱為大小結合。只有在必要時才引入訓練。

在 Agent 模式中，涉及從語音到文字、文字到語音的轉換，以及大量 workflow 和 Agent 調度。最終，客戶向我們提出需求，我們回應能夠滿足其意圖。這是一個綜合的“意圖空間 + 意圖滿足”的過程，中間結合了各種體系，才能構建出真正能夠服務客戶、進行銷售的智能體。

總結與展望：搭乘“大電梯”

最后，我想給大家回顧一下。我們在阿里云內部推進 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，靈駿，存儲，網絡服務，都是我們依賴的企業應用有力支撐武器。而這些能力的成本在不斷下降，功能也在持續拓展。所以，當企業選好了一個強大的技術底座，隨著技術水平的增長和成本的下降，企業的數字化轉型也就能夠搭上一個更好的“電梯”。我自己也認為，阿里云就是這樣一個“大電梯”，企業上云后，這個電梯就能持續為企業實現數字化轉型提供源源不斷的上升動力。

今天我的演講就到這里，感謝大家。

會議推薦

萬字剖析企業內部 AI矛盾，企業大模型落地的RIDE方法論