摘要:明確了客服調(diào)度的核心問題,也知道了難點,更看到了目前的現(xiàn)狀后,我們決定打造一款自動智能的客服調(diào)度系統(tǒng)。對于社會化的云客服,我們可以做到,比如排隊數(shù)超過某值時,自動觸發(fā)云客服的應(yīng)急放班。
背景
為什么客服需要調(diào)度?阿里集團客戶體驗事業(yè)群(CCO)目前承接了阿里集團以及生態(tài)體的客戶服務(wù)業(yè)務(wù),我們的客戶通過各個渠道來尋求解決各類問題,每天的進線量巨大,而且經(jīng)常伴隨著突發(fā)性進線,比如天貓代金券出了問題,在幾分鐘內(nèi)就會造成幾千通熱線或在線咨詢。面對種類繁多、海量、突發(fā)的客戶問題,我們的服務(wù)能力往往難以滿足,常常造成用戶排隊,甚至放棄,自然我們產(chǎn)生了對調(diào)度的需求。
客服調(diào)度的核心問題是什么?提升客服資源的利用率和服務(wù)水平,用更少的客服資源獲得更佳的用戶體驗。如果我們招聘大量的客服,也能讓用戶獲得更好的體驗,但是容易造成人力浪費,更多的人手意味著更多的培訓(xùn)成本、管理成本和人力成本。
與機器調(diào)度相比,客服調(diào)度有它的復(fù)雜點:
1)機房增加一臺新物理機,機器虛擬化后就可以快速被使用,而招募一個新客服,得需要長時間的培訓(xùn)才能讓他具備線上服務(wù)能力;
2)客服間差別大,不同客服的業(yè)務(wù)技能有區(qū)別,很難直接讓B技能組的客服處理A技能組的任務(wù),即使是掌握同一技能的客服,他們的服務(wù)能力也有大的差別,而機器差別不大,很多業(yè)務(wù)可以使用相同類型的機器;
3)客服是人,他有權(quán)利選擇上班、小休,他的工作效率、質(zhì)量會隨著他的情緒、體驗、服務(wù)的會員、工作時長等波動,調(diào)度時需要考慮他們的感受,而調(diào)度機器時無需顧忌;
4)突發(fā)場景多,業(yè)務(wù)問題、系統(tǒng)故障等都是無規(guī)律爆發(fā),波動特別大,很難準確的提前排好一天的人力。
現(xiàn)場管理員是否能應(yīng)對如此復(fù)雜的客服調(diào)度?答案是否定的。在沒有調(diào)度系統(tǒng)之前,現(xiàn)場管理員基本靠手工來調(diào)度,隨著體量越來越大,缺陷逐漸暴露:
1)響應(yīng)慢:比如周末線上排隊時,現(xiàn)場管理員可能會收到電話反饋,然后再打開電腦去手工放個臨時班等等,從排隊發(fā)生到調(diào)度生效超過十幾分鐘很正常;
2)不精準:缺乏數(shù)據(jù)指導(dǎo),統(tǒng)籌優(yōu)化能力弱。舉個例子,A技能組排隊時現(xiàn)場管理員想將A技能組的流量切一些到B里,切多少,分給誰,可能都是拍腦袋決定,決策結(jié)果也無法沉淀;
3)手段缺:可用的手段非常少,無非就是手動排班放班、手工切個流,管控下小休、發(fā)個公告等,沒有充分挖掘出客服的能力和潛力。
明確了客服調(diào)度的核心問題,也知道了難點,更看到了目前的現(xiàn)狀后,我們決定打造一款自動、智能的客服調(diào)度系統(tǒng)——XSigma。
1. XSigma大圖
XSigma調(diào)度系統(tǒng)按功能模塊可以分為手、腦、眼幾塊。手就是能提升客服資源利用率、客服服務(wù)水平以及提升客戶滿意度的手段,比如溢出分流、預(yù)約回撥、現(xiàn)場管控、激勵、排班、應(yīng)急放班、培訓(xùn)等。手段這么多,在不同業(yè)務(wù)不同場景下如何抉擇是一個難點,這里需要大腦也就是調(diào)度中心來做決策。決策產(chǎn)生的復(fù)雜調(diào)度邏輯如何能讓現(xiàn)場管理員、業(yè)務(wù)人員和開發(fā)人員更好地理解?我們通過可視化技術(shù)將復(fù)雜的調(diào)度邏輯轉(zhuǎn)化為可以理解的實時圖形界面,即調(diào)度系統(tǒng)的眼睛-調(diào)度大屏。手、腦、眼功能具備后,如何讓他們磨合得越來越好?我們通過仿真演練系統(tǒng)來錘煉。
下面會對圖里的模塊一一介紹。
2. 提前準備:排好班
如果能預(yù)測好需,準備好供,那客服調(diào)度就成功了一半。在我們業(yè)務(wù)中,不同類型的客服排班模式不同。云客服采用的是自主選班模式,管理員只需設(shè)置好每個時間段的選班人數(shù),讓云客服根據(jù)自己的時間來自行選班。而SP(合作伙伴)采用的是排班模式,需要管理員根據(jù)每個時間段的話務(wù)量來安排每一個客服,既要能夠保證每個時間段的接通率達到最大,又要能夠協(xié)調(diào)好客服人員的休息和工作時間,保證每個客服人員的總工時大致相等,這非??简灩芾韱T的統(tǒng)籌能力,當(dāng)客服數(shù)目變多后,人工排班給管理員帶來了巨大挑戰(zhàn)。
不管哪種模式,都需要提前預(yù)測未來兩周的需要服務(wù)量(業(yè)務(wù)上按1~2周的粒度排班),這其實是個標準的時間序列預(yù)測問題。結(jié)合歷史數(shù)據(jù),我們可以按照部門-技能組的粒度預(yù)測出未來2周的服務(wù)量,當(dāng)然,這種離線的預(yù)測只是一種近似,很難精準預(yù)測。
對于合作伙伴公司客服的排班,可以抽象為多約束條件下的優(yōu)化問題,在實際場景中,我們采用了組合優(yōu)化算法。
3. 水平擴容:預(yù)測式應(yīng)急放班
提前排班很難精確預(yù)估服務(wù)量,我們不可能提前知道下周一13點25分會出現(xiàn)個代金券問題導(dǎo)致大量用戶進線咨詢。
對于這種突發(fā)性質(zhì)的流量或者比上班服務(wù)量大的流量,我們能不能像調(diào)度機器一樣,快速水平擴容一批客服來上班。對于社會化的云客服,我們可以做到,比如排隊數(shù)超過某值時,自動觸發(fā)云客服的應(yīng)急放班。通過實踐發(fā)現(xiàn)云客服從選班到上班一般需要十多分鐘時間,如何進一步節(jié)省這十多分鐘的黃金處理時間?將應(yīng)急放班升級為預(yù)測式應(yīng)急放班!提前幾分鐘預(yù)測到即將到來的大流量,提前放班。
這里涉及兩個模型,一個是服務(wù)量實時預(yù)測模型,該模型能根據(jù)實時數(shù)據(jù)如會員的操作行為,會員在小蜜的行為,故障場景,并結(jié)合歷史進線量來綜合預(yù)測某一技能組未來30分鐘每一分鐘的進線量。
有了服務(wù)量預(yù)測數(shù)據(jù)輸入后,應(yīng)急放班模型就可以結(jié)合當(dāng)前服務(wù)會員情況,未來30分鐘客服排班情況、會員消耗速度、溢出關(guān)系等綜合指標,來推斷出是否要觸發(fā)應(yīng)急放班以及放班的服務(wù)量。一旦觸發(fā)應(yīng)急放班后,線下通知模塊會通過電話、短信等手段來通知合適的客服來上班。
與調(diào)度機器不同,我們需要時刻考慮客服感受,為了避免打擾沒有上班意愿的客服,我們讓客服自主設(shè)置是否要接收通知。
4. 負載均衡:溢出、分流
盡管預(yù)測式應(yīng)急放班效果不錯,但目前只針對云客服有效,對于SP類這種非選班類的客服怎么辦?我們發(fā)現(xiàn),線上排隊時,往往是某幾個技能組出現(xiàn)大量排隊場景,比如商家線爆了,消費者線的客服可能處于空閑狀態(tài)。如何解決這種忙閑不均問題?一個直觀的極端想法就將所有的組變成一個大池子組,通過負載均衡分配讓每一個客服都處于繁忙狀態(tài),從而達到效率最大化。而事實上并不是所有的技能組之間都能互相承接,這里既要權(quán)衡業(yè)務(wù),又要線下培訓(xùn)讓客服具備多技能。
XSigma提供了技能組相互分流、溢出的配置功能,只要滿足觸發(fā)條件,就能實時分流溢出,解決了以往靠現(xiàn)場管理員手工改客服技能組的痛苦。
對于一些場景而言,技能組間的溢出粒度有點粗,比如設(shè)置了A技能組排隊可以溢出到B技能組,并不是B技能組的每一個客服都能承接A的業(yè)務(wù),只有進行了培訓(xùn)的客服才能承接,XSigma同樣提供了給客服打技能標簽的功能。
5. 垂直擴容:彈性+1
有些業(yè)務(wù)比較復(fù)雜,很難找到其他技能組進行溢出,我們將注意力轉(zhuǎn)到正在上班的客服上。在線客服可以同時服務(wù)多個會員,如果一個客服最大服務(wù)能力是3,那么他最多同時服務(wù)3個會員,這個值由管理員根據(jù)客服的歷史服務(wù)水平來設(shè)置。
我們發(fā)現(xiàn)盡管很多小二的最大并發(fā)能力是相同的,在他們滿負荷服務(wù)會員時,他們的服務(wù)水平有很大不同,他們的忙閑程度也有非常大的差異,為什么?
● 小二本身水平有差異
如下圖所示,某技能組的客服最大服務(wù)能力都是3,最近一個月這個技能組的客服在同時服務(wù)3個會員場景下的平均響應(yīng)時間分布(平均響應(yīng)時間正比于客服回復(fù)速度),可以看到數(shù)據(jù)呈一個大致正太分布,說明小二服務(wù)水平有差異。
● 場景不同
舉個例子,A和B兩個客服最大服務(wù)能力都是5,同樣都在處理5個會員,但是A的5個會員差不多都到會話結(jié)束尾聲了,B的5個會員都才剛剛開始,這個例子下A和B兩個客服當(dāng)下的忙閑程度明顯不同。
既然小二的服務(wù)水平有差別,實際場景千差萬別,那能不能在技能組排隊時刻讓那些有余力的小二突破最大服務(wù)上限?
XSigma提供了兩種策略來讓小二突破服務(wù)上限。
1)主動+1模式
當(dāng)技能組達到觸發(fā)條件時,XSigma會主動點亮客服工作臺的+1按鈕(如下圖紅框所示),客服可以點擊來主動增加一個會員進線,這種方式相當(dāng)于是將擴容權(quán)利交給客服,因為只有客服自己知道目前忙不忙。
2)強制+1模式
如果某些技能組是強管控類型,可以選擇開啟強制+1模式,XSigma會結(jié)合數(shù)據(jù)自動選擇一些合適的客服來突破服務(wù)能力上限,比如他之前最大服務(wù)能力是5,我們會同時讓他服務(wù)6個會員。
6. 削峰填谷:預(yù)約回撥
對于熱線來說,小二不可能同時接好幾個電話,而且業(yè)務(wù)上可承接的線下客服也少,這時候如果出現(xiàn)大面積排隊怎么辦?
通過數(shù)據(jù)分析發(fā)現(xiàn),很多技能組在一天內(nèi)的繁忙度在波動,有高峰也有低峰,下圖所示展示了某技能組的剩余服務(wù)數(shù),可以看到有兩個繁忙時間段,10~13點,17~21點,這兩個時間段的空閑服務(wù)數(shù)很多時候都是0,而其它時間段相對比較空閑,如果能將這些繁忙時間段的進線量騰挪到非繁忙時間段,這樣就能大大提升客服的人員利用率,也能避免客戶排隊的煩惱。
怎么做呢?通過預(yù)約回撥,將當(dāng)下服務(wù)轉(zhuǎn)變?yōu)槲磥矸?wù)。如下圖所示,主要有兩個模塊構(gòu)成。
1)預(yù)約觸發(fā)器。用戶電話進來后,預(yù)約觸發(fā)器會根據(jù)技能組的繁忙情況,來判定是否要觸發(fā)預(yù)約;
2)回撥觸發(fā)器。采用系統(tǒng)主動外呼模式,一旦發(fā)現(xiàn)技能組繁忙度處于低峰,就會觸發(fā)回撥,只要用戶電話被接通,就會以高優(yōu)先級進入到分配環(huán)節(jié),從而讓客服人員在有效的工作時間內(nèi)都在真正的與客戶通話。
7. 最優(yōu)分配
調(diào)度的目標是:“提升客服資源的利用率和服務(wù)水平,用更少的客服資源獲得更佳的用戶體驗”。前面這些策略的關(guān)注點更多是在提升客服資源利用率上,有沒有什么策略能提升用戶的滿意度?我們從分配這一環(huán)節(jié)入手。
本質(zhì)上我們要解決的是“會員(任務(wù))-客服匹配優(yōu)化”問題。在傳統(tǒng)模式下,分配就是從某技能組的排隊隊列中找到一個等待時間最長的會員,然后再找一個該技能組下最空閑的客服完成匹配。這種公平分配方式考慮維度單一,未能在全局層面上掌握和調(diào)度分配有關(guān)的會員、客服、問題等各類信息。
匹配優(yōu)化問題其實是二部圖匹配問題,如圖所示,在某一時刻,我們可以得到某技能組下未分配的客戶(任務(wù))以及具備剩余服務(wù)能力的客服,如果能知道每個任務(wù)與每個客服之間的匹配概率,那就可以通過穩(wěn)定婚姻算法找到最佳匹配。
如何求得任務(wù)與客服之間的匹配概率?抽象為分類回歸問題,核心在于構(gòu)建大量樣本(x1,x2,x3,…,xn)(y)。針對一通歷史會話任務(wù),y是客戶評分或會話時長(目標可選),而x既包含了客服特征如過去30天的滿意度、平均響應(yīng)時間等等離線指標,以及客服當(dāng)前會話的服務(wù)會員數(shù)、最大會員數(shù)等實時指標,也包含了任務(wù)的特征,如問題類型、等待時間、訂單編號、重復(fù)咨詢次數(shù)等等。樣本有了后,下面就是選擇分類算法進行訓(xùn)練,最終我們采用了CNN。
在迭代過程中發(fā)現(xiàn),模型會將流量更多分配給好的客服,而指標相對較差的客服的流量則變少,為了避免少量客服上班接不到客反彈的情景,我們將公平性的指標引入到模型中。
8. 智能培訓(xùn):大黃機器人
通過最優(yōu)分配來提升滿意度的一個重要原因是將流量更多分給了能力強水平高的客服,而這部分客服的占比不高,為什么?為了應(yīng)對11、12這兩個特殊月份的高流量,業(yè)務(wù)團隊要招募培訓(xùn)大量的云客服。這些新手涌入必然會對滿意度帶來影響,換句話說,如果要想進一步提升滿意度指標,必須提升新手客服的服務(wù)水平。
對于新手,在上崗前提升他們水平的唯一方式就是培訓(xùn),傳統(tǒng)的培訓(xùn)都是通過線下讓云客服看視頻等學(xué)習(xí)資料,然后進行筆試,通過后就直接上崗,帶來的問題是很多新客服對平臺的工具、解決方案都不熟悉就直接服務(wù)會員,會員體感較差。
對比練車場景,我們發(fā)現(xiàn)練車有科目1、科目2、科目3等不同流程,科目1學(xué)習(xí)理論,科目2和科目3實戰(zhàn)模擬,如果我們引入這種實戰(zhàn)模擬就能大大提升新客服的服務(wù)水平。
我們創(chuàng)新的提出了使用機器人(大黃)來培訓(xùn)客服這一全新的客服培訓(xùn)模式(已申請專利)。新客服在培訓(xùn)租戶里,通過點擊大黃頭像,會產(chǎn)生一通非常真實的模擬會話,通過和會員聊天,不斷學(xué)習(xí)平臺工具使用,不斷提升解決客戶問題能力。一旦會話結(jié)束后,大黃機器人會對這通會話進行評價,并會告知應(yīng)該使用某種具體的解決方案來回答用戶問題。
對于新客服,目前必須完成大黃80通會話后才能上崗,整個財年培訓(xùn)客服幾萬人,服務(wù)會話量達到幾百萬輪次。abtest顯示通過大黃試崗的客服不管在滿意度、不滿意、平均響應(yīng)時間、平均服務(wù)時長等各項指標上都有非常明顯提升。
9. 統(tǒng)一的調(diào)度中心
從上面可以看到我們的客服調(diào)度策略多且復(fù)雜,每種策略都起到了一定提升客服資源的利用率和服務(wù)水平的作用?,F(xiàn)在的問題來了,不同場景下這么多策略如何選擇?比如現(xiàn)在技能組A突然排隊100個會員,這個時候是直接溢出到其他技能組,還是觸發(fā)主動+1或觸發(fā)應(yīng)急放班呢?這里需要一個大腦來做決策。
如何讓這個大腦適用于各種復(fù)雜的業(yè)務(wù)場景是難點。我們平臺目前租戶就有幾十個,僅淘系這一個租戶就劃分了幾十個客服部門,每個部門下又細分了一系列技能組,不同部門間業(yè)務(wù)場景不同。在嚴重缺乏歷史數(shù)據(jù)積累情況下,很難直接通過訓(xùn)練一個決策模型來適應(yīng)多種業(yè)務(wù)。于是我們的思路就轉(zhuǎn)換為直接利用現(xiàn)場管理員的專家知識,讓他們將決策邏輯沉淀為一條條的規(guī)則。
目前平臺上已經(jīng)配置了上萬條規(guī)則,每天生效的規(guī)則也有幾千條,這些數(shù)據(jù)的沉淀讓我們可以通過智能優(yōu)化技術(shù)實現(xiàn)真正的智能調(diào)度決策大腦。
10. 調(diào)度監(jiān)控大屏
客服調(diào)度策略繁多、邏輯復(fù)雜,調(diào)度結(jié)果會切實影響整個環(huán)節(jié)參與者的感受,因此我們搭建了XSigma調(diào)度大屏,方便大家理解。在實踐過程中發(fā)現(xiàn)調(diào)度大屏能建立起使用方對調(diào)度系統(tǒng)的信任感,降低開發(fā)人員和管理員發(fā)現(xiàn)、定位并解決系統(tǒng)問題的成本。舉個例子,管理員在XSigma平臺上設(shè)置一些規(guī)則,比如A技能組排隊數(shù)>=1觸發(fā)溢出到B技能組,設(shè)置完后他心里沒底,他也不知道設(shè)置的邏輯是否生效,往往會讓開發(fā)同學(xué)再次確定下有沒有生效,而現(xiàn)在有了可視化調(diào)度大屏,既能觀察到各個技能組的服務(wù)量、剩余服務(wù)量等實時監(jiān)控數(shù)據(jù),也能看到實時調(diào)度各種策略生效的過程,以及每天調(diào)度的實時匯總明細數(shù)據(jù)。
11. 仿真演練
在調(diào)度優(yōu)化場景中,如何評估調(diào)度系統(tǒng)的好壞至關(guān)重要。有沒有一種手段能評估XSigma是否能適應(yīng)各種場景?能提前證明在雙11這種大促期間也能順暢的調(diào)度?能及時發(fā)現(xiàn)調(diào)度過程中出現(xiàn)的問題?這不僅是我們也是業(yè)務(wù)同學(xué)迫切需要知道的。
仔細思考發(fā)現(xiàn),要解決的問題和技術(shù)的全鏈路壓測要解決的問題很相似,我們要做的其實是業(yè)務(wù)上的全鏈路壓測,于是我們搭建了客服調(diào)度的仿真演練系統(tǒng)。
基于大黃機器人,我們已經(jīng)能模擬會員進線,通過定制改造,機器人可以制造各種主題類型的題目,比如雙十一類型場景等。在此基礎(chǔ)上,結(jié)合業(yè)務(wù)同學(xué)的預(yù)估量,可以設(shè)置出各個技能組的進線量。
在雙十一之前,業(yè)務(wù)同學(xué)使用這套演練系統(tǒng)大規(guī)模演練過兩次,由于是基于真實服務(wù)量進行演練,而不是以前的口頭相傳的方式,讓調(diào)度上下游每一個參與的同學(xué)都有壓力感。在演練過程中發(fā)現(xiàn)的一些問題改進后,大大提升了我們應(yīng)對大促突發(fā)流量的信心。
12. 小結(jié)
XSigma智能客服調(diào)度系統(tǒng)采用自動化配置、機器學(xué)習(xí)等技術(shù),將復(fù)雜的調(diào)度問題分層處理,并在日益增長的會員任務(wù)基礎(chǔ)上,不斷精細化調(diào)度模型依賴的狀態(tài)預(yù)估數(shù)值,不斷提高調(diào)度模型的多目標規(guī)劃能力,同時通過大量運用平臺可視化技術(shù),以實時、圖表化的方式將系統(tǒng)運行狀態(tài)呈現(xiàn)出來,最終在客服效率和用戶體驗時間上得到優(yōu)化效果。該系統(tǒng)上線后,相比于往年,服務(wù)不可用時長這一業(yè)務(wù)核心指標直接下降98%。
本文作者:力君
閱讀原文
本文來自云棲社區(qū)合作伙伴“阿里技術(shù)”,如需轉(zhuǎn)載請聯(lián)系原作者。
文章版權(quán)歸作者所有,未經(jīng)允許請勿轉(zhuǎn)載,若此文章存在違規(guī)行為,您可以聯(lián)系管理員刪除。
轉(zhuǎn)載請注明本文地址:http://systransis.cn/yun/19807.html
摘要:今天,我們邀請阿里高級技術(shù)專家力君,為大家分享自動智能的客服調(diào)度系統(tǒng)。明確了客服調(diào)度的核心問題,也知道了難點,更看到了目前的現(xiàn)狀后,我們決定打造一款自動智能的客服調(diào)度系統(tǒng)。 小嘰導(dǎo)讀:提到調(diào)度,大家腦海中可能想起的是調(diào)度阿里云的海量機器資源,而對于阿里集團客戶體驗事業(yè)群(CCO)而言,我們要調(diào)度的不是機器,而是客服資源。今天,我們邀請阿里高級技術(shù)專家力君,為大家分享自動、智能的客服調(diào)度...
摘要:摘要據(jù)了解,借助阿里云,上汽乘用車實現(xiàn)了工程開發(fā)仿真能力升級,仿真計算效率提升了,使工程開發(fā)人員更加專注于產(chǎn)品設(shè)計和性能優(yōu)化,打造出世界級產(chǎn)品的高品質(zhì)。 摘要: 據(jù)了解,借助阿里云,上汽乘用車實現(xiàn)了工程開發(fā)仿真能力升級,仿真計算效率提升了25%,使工程開發(fā)人員更加專注于產(chǎn)品設(shè)計和性能優(yōu)化,打造出世界級產(chǎn)品的高品質(zhì)。今年北京車展上全球首秀的概念車MG X-Motion,其量產(chǎn)車的卓越整車...
摘要:嘉賓介紹張勁太云,阿里巴巴應(yīng)用與基礎(chǔ)運維平臺產(chǎn)品與架構(gòu)部高級開發(fā)工程師,主要負責(zé)測試環(huán)境研發(fā)和效能提升,喜歡開源。 摘要: 測試環(huán)境是研發(fā)/測試同學(xué)最常用的功能,穩(wěn)定性直接影響到研發(fā)效率,那如何提升測試環(huán)境的穩(wěn)定性?阿里巴巴應(yīng)用與基礎(chǔ)運維平臺高級開發(fā)工程師張勁,通過阿里內(nèi)部實踐,總結(jié)了一套測試環(huán)境穩(wěn)定性提升方法,供大家參考。 點此查看原文:http://click.aliyun.com...
摘要:今天的話題分四部分,第一個是小程序音視頻能拿來做什么,第二部分是將其內(nèi)部是怎么做到的第三就是講騰訊視頻云的音視頻技術(shù)的一些技術(shù)細節(jié)第四個是介紹一下微信上做音視頻的應(yīng)用的一些審核問題以及應(yīng)對方案。 本文由云+社區(qū)發(fā)表 作者:常青 騰訊視頻云是做什么的?騰訊視頻云既不做數(shù)據(jù)庫,也不做存儲,也不做網(wǎng)絡(luò),我們只做音視頻服務(wù),也就是直播、點播、視頻通話、這類面向B類客戶的音視頻PAAS業(yè)務(wù)。 今...
摘要:昨天,阿里云又與神州數(shù)碼宣布達成戰(zhàn)略合作。胡曉明坦言,這兩年底層計算能力的爆發(fā)推動了阿里云人工智能技術(shù)的進步?;诖?,阿里云加大了對于人工智能的投入,并于去年開始將人工智能的服務(wù)和能力對外開放?! 」猸h(huán)新網(wǎng)日前公告已與亞馬遜在華子公司達成云服務(wù)運營協(xié)議。這意味著,作為國際巨頭的亞馬遜,正試圖借道本土公司在中國的監(jiān)管環(huán)境下運營公有云業(yè)務(wù)。然而,在阿里云總裁胡曉明看來,因受云計算重資產(chǎn)、重技術(shù)特...
閱讀 2082·2023-04-25 17:48
閱讀 3590·2021-09-22 15:37
閱讀 2943·2021-09-22 15:36
閱讀 6016·2021-09-22 15:06
閱讀 1646·2019-08-30 15:53
閱讀 1438·2019-08-30 15:52
閱讀 720·2019-08-30 13:48
閱讀 1130·2019-08-30 12:44