一文讀懂智慧客服:發展歷程、系統搭建、市場推廣
在人工智慧領域,智慧客服是比較容易落地,且技術比較成熟的一項應用實踐。本文以智慧客服為物件,梳理了它的發展歷程、系統搭建、市場推廣。enjoy~
2018 I/O開發者大會上,谷歌演示了對話機器人Duplex。
Duplex完成了兩項任務:
- 第一項任務,預定理髮服務;
- 第二項任務,一個預定就餐的電話接待。
實際上,Duplex扮演的就是智慧客服的角色。
在人工智慧領域,智慧客服應該是比較容易落地,而且技術比較成熟,這是因為客服領域的場景路徑具有相對明確的特徵,決定了基於全量資料進行高併發需求處理的人工智慧在客服領域將大有可為。
目前,基於大資料、雲端計算和深度學習等領先的人工智慧技術,智慧客服已經可以實現自主問答、業務辦理、故障診斷等一系列複雜操作,實現客服行業中大部分的應答需求,快速高效的解決使用者問題。
據2018年5月釋出的《中國智慧客服行業研究報告》統計,中國大約有500萬全職客服,以年平均工資6萬計算,再加上硬體裝置和基礎設施,整體規模約4000億元。
如此巨大的市場,當然會使得眾多企業對於智慧客服趨之若鶩。但是為什麼到現在還沒有一家獨角獸公司出現?
雖說這是人工智慧中最容易落地、技術相對成熟的專案,但相關企業如果想開發和構建一套人工智慧客服系統,到底要投入多大的成本?
一家企業是自己搭建一套智慧客服系統,還是找到一家合適的智慧客服平臺廠商,站在“巨人”的肩膀上,利用它們賦予的能力,搭建自己的智
能客服解決方案。
今天我們好好聊聊。
一、客服系統的發展歷程
中國客服軟體市場大致經歷了三個發展階段:傳統呼叫中心軟體、PC網頁線上客服+傳統客服軟體、雲客服+客服機器人的智慧客服階段。
- 2000年以前,網際網路尚未普及,客服主要以電話溝通為主。
- 2000-2010年間,得益於計算機技術、計算機電話整合技術(CTI)、網路技術、多媒體機技術以及CRM、BI、ERP、OA等企業資訊化應用的整合,客服系統跳出單一的電話溝通出現了網頁線上客服等多種客服渠道。
- 而過去近十年,移動網際網路、雲端計算、大資料和AI技術的發展又將傳統呼叫中心和客服軟體帶入了SaaS和智慧化時代。一方面全新的SaaS模式使得企業搭建客服中心的成本大大降低,SaaS模式逐漸普及,早期提供呼叫中心硬體裝置的廠商已經延伸到中下游,為外企、國企等大型客戶提供本地客服中心解決方案。
從當前客服產業鏈構成情況來看,上游基礎設施環節已經發展成熟,少數巨頭壟斷市場。未來,他們會繼續向下遊延伸,構建企業服務生態。
中游客服產品提供商中,雲客服廠商經過幾年競爭,頭部幾家已脫穎而出,但仍未長出巨頭,競爭依然激烈。產品功能更加豐富,應用場景也從客服延伸到了銷售、營銷等多個環節,另一方面,客服機器人通過輔助人工,以及回答簡單重複性問題,大大提高了人工客服的工作效率。同時,AI也在從各個環節上變革著企業客服的互動方式,加速線上線下客服的智慧化升級。
二、智慧客服系統搭建
智慧客服系統主要基於自然語言處理、大規模機器學習、深度學習技術,使用海量資料建立對話模型,結合多輪對話與實時反饋自主學習,精準識別使用者意圖,支援文字、語音、圖片等富媒體互動,可實現語義解析和多形式的對話。
任務對話服務:
定製化服務,通過與使用者的多輪互動,實現快遞查詢、訂餐、醫生預診等服務類功能。
業務諮詢服務:
通過QA知識庫,快速回複使用者問題諮詢服務。解決常見問題的解答。
2. 智慧客服系統的技術構架
(1)基於知識庫回答的智慧客服系統
基於知識庫回答的智慧客服系統,
使用的檢索或者分類模型來實現的。
檢索式回答的流程是:
- 首先對使用者的輸入問題做處理,如分詞、抽取關鍵詞、同義詞擴充套件、計算句子向量等;
- 然後基於處理結果在知識庫中做檢索匹配,例如利用BM25、TF-IDF或者向量相似度等匹配出一個問題集合,這類似推薦系統中的召回過程;
- 由於我們是一個問答系統,最終是直接返回給使用者一個答案,因此需要從問題集合中挑出最相似的那個問題,這裡會對問題集合做重排序,例如利用規則、機器學習或者深度學習模型做排序,每個問題會被打上一個分值,最終挑選出top1,將這個問題對應的答案返回給使用者,這就完成了一次對話流程。
在實際應用中,我們還會設定閾值來保證回答的準確性,若最終每個問題的得分低於閾值,會將頭部的幾個問題以列表的形式返回給使用者,終端使用者可以選擇他想問的問題,進而得到具體的答案。
(2)基於槽位填充的多輪對話系統
搭建基於槽位的對話系統是一個相對專業而複雜的過程,通常分三個主要的階段。首先是需求分析,然後是使用平臺搭建 BOT,最後是持續優化。
瞭解該系統我們先熟悉一下幾個名詞的釋義:
1)意圖
意圖是指使用者在語音互動中發出的主要請求或動作。
意圖示例:
- 肯定意圖:是;對的;正確;Ok;
- 否定意圖:不是;不對;錯了;NO;
- 取消意圖:退出;停止;關閉;結束;
2)技能
技能是滿足使用者特定需求的一個應用。例如使用者說“查詢我的洗髮水快遞到哪裡了”時,會進入快遞查詢的技能。
3)問答型技能
通過Q(使用者問法)和A(機器人回答)的配置,可以實現簡單的使用者與機器人的對話。
任務型技能:在問答型技能的基礎上,增加槽位、API(介面)呼叫等高階功能,可以通過配置,來實現使用者查詢資訊、問題搜尋或者其他功能。
4)詞典
某個關鍵詞可能變化的內容,例如時間詞典,位置詞典。
語義槽:語義槽是使用者說法中包含的關鍵詞,它可以幫助系統準確識別意圖,例如星座語義槽包含12星座的名稱。語義槽和詞典一般會同時使用,語義槽通常用來指代詞典。一個語義槽可以同時繫結多個詞典,一個詞典也可以與不同的語義槽相關聯。
5)追問
當使用者問法中沒有提供該語義槽值時,機器人要對其自動發起追問。
例如使用者問:天氣怎麼樣?我們無法獲取到查詢天氣的地點的語義槽值,就需要機器人追問,您想獲取哪裡的天氣資訊?,追問話術一般設定多條,隨機追問。
在國內開放的bot系統中,百度UNIT和微信的對話開放平臺就是應用的該技術框架。
一個自然語言對話系統,理解的核心任務是對意圖的解析和對詞槽的識別。
例如:訂明天早上8點北京到石家莊的火車,在這個例子中,對於使用者表達的一句話, 它的意圖是要訂火車票,其中涉及的詞槽包括出發地、目的地、時間。當這個時間有多趟車次的時候,就需要進行追問使用者,是要訂哪一個。
以百度UNIT平臺為例,搭建一個買票智慧回覆的流程。
- 需求分析:訂火車票需要知道時間、出發地、目的地
- 新建一個BOT,命名為:火車票
- 新建對話意圖:命名訂票
- 新增詞槽:出發時間、選擇系統詞槽詞典,選擇然後選擇系統詞典 sys_time(時間),出發地詞槽、目的地詞槽,這兩個都可以選擇系統詞典,這些都是必填項。
- 設定詞槽與意圖關聯屬性,這裡火車票的出發時間是訂票裡必須的關鍵資訊,所以選擇必填。澄清話術就是當使用者表達訂票需求的語句裡缺少出發時間時 bot 主動讓使用者澄清的話術。還可以設定讓使用者澄清多少輪後放棄要求澄清,預設是 3 次。
- 設定 BOT 迴應,BOT 迴應就是當 BOT 識別出使用者的意圖和所有必填詞槽值時給使用者的反饋。對於訂票回覆一般對接API介面,實現自動生成方式。
當然,這只是火車票中的一個場景,在火車票這個場景中還有退票、改簽、查詢等功能。這些都是需要我們在需求梳理中要確定的。
3. 如何評判一個智慧客服系統的好壞
(1)基於人工標註的評價
基於問答知識庫來回答的系統,回答能力受限於知識庫的豐富程度,也就是說知識庫對使用者問題的覆蓋率,覆蓋率越高,準確性越高。
因此並非能回答使用者的所有問題,系統最佳的狀態是將能回答的全部回答準確,不能回答的全部拒識,即拒絕回答。
因此這裡的評價指標包括有問題解決率、拒識率、召回率和準確率等,我們的目標是讓系統的有結果率無限接近資料的真實有結果率,召回率和準確率儘量高。
- 召回率 = 機器人能回答的問題數 / 問題總數
- 準確率 = 機器人正確回答的問題數 / 問題總數
- 問題解決率 = 機器人成功解決的問題數 / 問題總數
- 拒識率=機器人未回答問題數/使用者問題數
通過從每日的全量資料集中抽樣出一個小資料集,保證小資料集的資料分佈儘量符合全量資料集,然後由標註團隊對資料集做標註,標註出每個問題的實際答案,一般標註完成後還有質檢的環節,以保證標註結果儘量準確,這樣便生成了每日資料的標準評測集。
基於該標準評測集我們會去評價系統的好壞,並且每次做新模型迭代時都會使用標準評測集去評價新模型,只有新模型達到某個指標才可以上線。
(2)基於使用者反饋的評價
人工評價能夠評價智慧客服系統的準確率,但是答案是否合理,能否為使用者解決問題,需要使用者去反饋評價,整個智慧客服系統的最終目標是幫助使用者解決問題。
我們會在產品上設計智慧客服和線上客服的評價功能,例如會讓使用者評價智慧客服的每個答案或者某次會話,在和人工客服聊天完畢會傳送評價卡片給使用者去評價滿意度,如下圖所示。
最終我們會統計參評比例、滿意度等指標,這些指標能夠真正反應智慧客服系統的好壞。實際中往往使用者參評比例低,我們會使用各種方法去刺激使用者評價。
三、智慧客服遇到的那些問題
1. 做通用智慧客服系統還是垂直行業智慧客服系統
智慧客服系統的都是2B的,通用型智慧客服系統意味著市場更大,使用者更多。而垂直領域的客服系統使用者就少的多了。
以保險行業為例,全國保險公司一共一百多家。而且做垂直領域的智慧客服系統,AI團隊必須充分理解行業。瞭解業務需求,瞭解業務流程還需要跨部門溝通。
做垂直領域的智慧客服系統,往往會陷入一兩個大專案,不斷滿足使用者的個性化需求上。最終系統很“定製”,同時市場也很小。做幾個專案之後就會碰到透明的天花板。
然而做通用型智慧客服系統最然市場很大,但是和做垂直領域的智慧客服系統的團隊相比,沒有了優勢,技術優勢現階段各家差距不大,小公司可以給使用者定製化,但是通用化系統不可以,最終變成市場很大,但是被一個個一句突起的做垂直領域的智慧客服系統小公司蠶食了。
那怎麼辦呢?
網際網路剛開始的時候,入口網站率先突起,能夠服務大多數人的需求,接下來,微信公號可以訂閱,每個人的閱讀內容都不一樣了,這就是一種定製版的資訊平臺。從使用者角度來說,定製化是演進方向,最終通用型客服會被垂直行業智慧客服所取代。
2. 做SAAS服務還是私有化部署
傳統行業銀行、保險、證券、房地產等大企業往往有很強的客服需求,對引入智慧客服系統的意願很強,但同時其對自身資料安全性的要求也很高,因此只會同意本地化部署的解決方案。
這類大客戶做本地化部署解決方案,就只能採用專案制的商業模式,做一個專案收一次費用。好處是一個專案就能收到幾十至上百萬元的收入,創業初期就能有盈利;壞處是私有化部署客戶需要定製化需求比較多,會佔用大量人力成本而且難以規模化複製,長久來看增長空間有限。
那怎麼辦呢?
單從資料安全形度來講,會隨著技術發展來解決,移動支付剛開始的時候大家還很害怕,繫結自己銀行卡會不會被盜。會不會有黑客黑進我的支付寶。現在來看是杞人憂天了。有足夠的投入才會有足夠的資金支撐技術開發,SAAS服務服務的使用者更多,技術漏洞更容易被找出來,系統的安全性會進化的更快。私有化部署不是一個好的選擇。
3. 服務大客戶還是中小客戶
創業之初選擇目標客戶時所有智慧客服創業公司都需要面臨一個選擇:究竟是主攻大企業客戶,還是一開始切入中小企業市場?
主切中小企業客戶則可以用標準化的SaaS產品來滿足其需求,不僅模式輕佔用人力成本低可實現規模化複製,而且能通過每年續費的方式獲得持續的收入,還能不斷得到資料迴圈反饋建立起技術壁壘。
但缺點是前期獲客難度大,需要做大量市場教育工作,並且中小企業的死亡率高,整體的續費率難以保障,創業初期很難實現盈利。
但是主攻大客戶的話,一些定製化需求難以滿足,而且大客戶流程比較長,一般具有長期服務的服務商,對產品成熟性要求比較高,創業公司很難打進去。定位於服務幾個大客戶,對於創業公司風險比較大。
那怎麼辦?
做垂直領域的SAAS系統,就需要有更多的使用者使用,才能更快的迭代系統,只有一兩個大客戶,很難提出建設性的改進建議,所以說做中小客戶,儘快的找到第一批使用者,把系統跑起來然後不斷優化迭代。
3. 智慧客服銷售難點
大家都在說傳統客服行業有很多痛點,智慧客服可以很好地解決這些痛點。例如:
(1)人工成本高
人口紅利消失,用人單位的用人成本會越來越高。
這個是真實需求嗎?首先客服並不是一個企業的核心部門,大多企業對於客服部門並不是很重視。在中小企業,客服人員並不太多,真正能節省的人力成本並不高,所以企業的替換的動力並不大。在大企業中,人力成本的確是一個大的成本支出部門,但是也正基於此,大企業有足夠的支出來自己做智慧客服系統。因為他們的投入產出比是合適的。就像是滴滴這類擁有大客服部門的企業,更傾向於自己來做。
(2)決策悖論
智慧客服系統要解決的就是人類客服做的事情,當替換掉他們的工作後,就意味著部門裁員。
這樣當然對於企業來說是節流的好辦法,但對於客服部門領導來說就不那麼好,部門人說減少就意味著自己在企業中的權重降低。
雖然長遠來看這是大勢所趨,但現如今銷售過程中基本是還是從上到下的銷售過程,而不是部門提出的迫切需求,並且有部門人員持續跟進。
總結
太陽底下沒有新鮮事,大公司應用底層技術框架,搭建自己的智慧客服系統。也許會是一個趨勢,既能夠保證資料的安全性,也能夠控制成本。對於一些SAAS智慧客服系統來說,當技術形不成寡頭優勢,產品推廣和服務能力就會變得尤為重要。
智慧客服公司有壁壘嗎?什麼才是智慧客服公司的壁壘呢?
客服系統的使用習慣,和資料的積累,以及知識庫的完善,是智慧客服系統的行業壁壘,使用者切換智慧客服系統的成本太高,也就懶得替換。
所以儘快擴充自己使用者,這就是智慧客服公司的壁壘。只做智慧客服未來的業務增長會非常有限,找到自己的第二增長曲線,是決定智慧客服公司走多遠的關鍵。
http://www.woshipm.com/ai/2840619.html
來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/29829936/viewspace-2656552/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- 一文讀懂智慧城市發展趨勢
- 一文讀懂資料平臺的發展歷史
- 一文讀懂支付系統
- 一文讀懂教育直播系統開發模式模式
- 開發線上客服系統新的宣傳推廣站【微客客服】
- 一文讀懂“付費DLC”發展史
- 一文讀懂資料庫發展史資料庫
- 客服系統_線上客服系統_網站客服系統_智慧客服系統網站
- 從0到1開發搭建智慧線上客服系統
- 一文讀懂資料平臺建設的演進歷程
- 一文讀懂mysql許可權系統MySql
- 一文讀懂資料庫70年發展史資料庫
- 一文讀懂 Serverless 的起源、發展和落地實踐Server
- HTTP - 發展歷程HTTP
- 客服系統的三個發展階段
- iOS歷史(iOS系統發展歷史)iOS
- 一文讀懂鴻蒙系統與安卓系統的區別鴻蒙安卓
- 智慧客服預見未來&智慧客服趨勢發展白皮書
- GfK:線上教育推動帶屏智慧音響市場快速發展
- AI智慧體服務平臺-智慧客服系統-獨立部署搭建AI智慧體
- HTTP版本發展歷程HTTP
- Java 的發展歷程Java
- 智慧線上客服系統
- HarmonyOS系統的發展歷史
- 豈止於大,一文讀懂大資料及其在推薦系統的應用大資料
- 一文讀懂搭建線上教育平臺流程
- 一文讀懂5G專網發展現狀與挑戰
- 深度學習發展歷程深度學習
- 華為的發展歷程
- 一文讀懂mavenMaven
- 一文讀懂ServletServlet
- 一文讀懂資料中心計算市場CPU、DPU和GPU的區別GPU
- 一文讀懂雲上DevOps能力體系dev
- 一文帶你看遍深度學習發展的成就歷程(一)深度學習
- 乾貨分享 | 一文讀懂DNS原理及解析過程DNS
- 讀懂智慧對話系統(1)任務導向型對話系統
- javascript模組化發展歷程JavaScript
- 前端模組化發展歷程 (-)前端