移動智能客服系統設計

Ⅰ AI技術如何打造智能客服

由於從事智能客服領域，對智能客服的開發也有比較全面的了解，這里從AI技術的角度介紹一下。

智能客服用到的技術群

智能客服機器人會用到很多人工智慧方面的技術，比如自然語言理解、深度神經網路、知識圖譜、語音識別、語音合成等方面的技術。為了便於您從總體上了解這些技術，以璞媧智能客服用到的技術為例，請參考下面不同角度的技術全景圖。

從客服處理過程理解AI技術

要理解智能客服中的AI技術，我們可以從技術的應用過程來加以理解。比如電話應對過程中，智能客服會用到下面幾種技術。

智能客服中用到的AI技術

上面從客服處理過程的角度介紹了幾種技術范疇，

首先你要知道它一定要具備學習能力，接下來就是各種喂數據了。

可以從以下幾個步驟氏信蔽著手：

（1）確定任務（智能客服）；

（3）任務或問題的明確定義：當做分類任務解決 還是 直接生成回答的問題；針對不同的問題，分別考慮數據收集、收據處理、演算法選型、評估方案與指標設計、實驗設計、上線方案和坦穗運維等問題。

（4）詳細分析好任務和待回答的問題後，就需要准備語料庫（注重數據質量，好的數據質量，勝過最優秀的演算法）；

（5）數據預處理，將文本數據轉換為詞向量（有多種方法，如word2vec等等），考慮輸入數據與標簽殲州數據組織形式，可以參考智能問答相關的開放數據集；

（6）數據分析，主要包括數據量大小的分析、詞向量高維嵌入分析、如果是分類任務還要分析類別的數據平衡性；能想到的統計分析與數據處理方法都可以考慮，目標是數據高質量；值得一提：數據量的大小決定數據處理（如需要數據增廣、類別平衡、數據上或下采樣等）、方法的選擇以及模型訓練的方法（如使用預訓練模型、考慮小樣本學習方法等）；

（8）實驗與結果評估，注重訓練數據與評價數據劃分，科學/嚴謹實驗，科學分析；利用設計指標進行評估並充分分析實驗結果，尋找模型做得不好的樣本案例（badcase）；

（9）badcase分析與解決；

（10）上線前實測，逐步擴大用戶使用范圍；

（11）繼續跟進和改進出現的問題，重復（1）~（10）的環節。

智能客服的主要價值在哪裡？

在企業的經營中，客服是必不可少的角色，在很大程度上，客服是企業與客戶唯一的直接接觸通道，客服的價值在於解決用戶問題，改善用戶體驗，提升企業口碑，營銷促進交易等等，但傳統的客服模式放到如今的互聯網時代，短板立現。成本、效率、溝通方式等都有待提升與改進，由此，智能客服的價值得以凸顯。

直觀來看，智能客服對傳統客服行業的主要價值體現如下：

1、智能客服在處理有明確結論的簡單重復性問題上，展現了極高的工作效率，人工客服可以節省更多時間與精力去處理更為復雜、關鍵的客戶問題，去服務VIP或是個性化需求更強烈的客戶，從而達到提升客戶滿意度的效果。同時企業的人力、管理、運維成本都得到大幅下降。

2、智能客服在本質上是機器，機器沒有生理局限，服務時長遠大於人力，同時它也不存在情緒波動，可以實現百分之百的微笑服務，保持標準的服務質量。特別是在客戶業務規模達到明顯的波峰波谷時，智能客服可以在短期內實現大批量復制解決，以應對業務量的波動，實現彈性運維。

3、智能客服還可以應用在企業的營銷活動中，在傳統的電銷時代，人工外呼作為很多企業的營銷主要手段，耗時長，效果差，一個客服一天所能撥打的電話量有限，而電銷恰巧又是一個需要「廣撒網，多嘗試」的營銷方式。此時，智能客服交互系統中的呼叫中心功能就可以被很好的利用起來，增加呼出頻率，擴大呼叫范圍，提升呼叫中心的價值創造力。

智能客服既有這么多優勢，那它的出現又是否會對傳統的人工客服造成替代性的威脅呢？

其實不然，傳統的客服行業就像是一座金字塔，人工智慧並不是將它推倒重建，而是在思考如何做到機器輔助人工，部分代替人工，擴大金字塔的基層，穩固上層結構。

由此，智能客服的主要價值可以概括為：在滿足企業對客服工作的需求的同時為企業減投增效，幫助企業更好的實現營收。

邏輯推理 知識表示 自動規劃 機器學習 自然語言 感知 行動處理 人類情緒 計算創造 綜合智能

只要用在合適的地方。無論各行各業，機器人代替人工，能夠極大增強企業辦公效率，增加收益，降低用人成本，人工智慧的發展最大的受益者是人類。人類的創意是無限的，但是自身能力也是有局限性的，也需要機器人來輔助人類。所以各有優勢，無所謂誰的業務能力強，都是相互彌補的。這沒法比較。

隨著電話服務熱線的出現，以及企業客戶服務的不斷提高。在移動互聯網時代，客戶通信服務也變得多樣化。除了申請400或95個號碼建立客戶服務系統來改善客戶服務外，企業還通過網路服務、移動應用、公共微信、微博等渠道提供服務。當越來越多的人以這種方式與企業員工接觸時，當人工客戶服務不能及時處理多個用戶和問題時，導致客戶體驗差，再加上企業的僱傭成本不斷增加，智能客戶服務機器人順應時代的到來。目前，智能客戶服務機器人已經成為企業與用戶之間最重要的通信工具。廣泛應用於金融、教育、電子商務等領域。

最近，在微博上，我們總能看到一些客戶服務機器人在本地測試市場上並不想像智能，自動回復單句嚴重，回復內容錯誤，人們想要有人工的客戶服務來與他們溝通。問題是，客戶服務機器人什麼時候才能真正「理解」？編輯曾體驗過騰訊、阿里小米、京東和大銀行的在線客服平台。電子商務服務平台具有響應速度快、識別率高、產品促銷個性化、信息優惠等增值服務的共同特點。但對這句話的理解卻偏低。

在當前的客戶服務中，機器人客戶服務作為手動客戶服務的輔助工具，幫助手動客戶服務解決，解決客戶的諸多問題，降低手動客戶服務的工作壓力，提高工作效率手動客戶服務，大大提高了解決方案的准確性。效力。然而，在與人類的對話中，客戶服務機器人已經成為人類復雜情緒的難點。在接下來的幾年裡，客戶服務機器人不會完全取代人們的工作。深入整合人機的「無人值守客戶服務」是打破這一瓶頸的最佳方式。

所謂智能客服機器人實際上是一個人工智慧信息系統，它可以用自然語言與用戶進行通信。它使用了許多智能人機交互技術，包括自然語言理解和機器學習技術。它能夠以文本或語音的形式識別和理解用戶的問題，通過語義分析了解用戶的意圖，與用戶進行人性化的溝通，為用戶提供信息咨詢等相關服務。

在當前人工智慧迅猛發展的浪潮中，福山北明信息技術公司負責人表示，優秀的客戶服務依靠人工實能和海量數據來深化客戶服務場景的應用，不斷優化、創新和完善。描述了「可定製」的智能客戶服務，它能夠准確地適應業務需求並繼續學習，並幫助、適應和回答大量的常見問題。它大大提高了人類的效率。它可以廣泛應用於網站、應用程序、電話客戶服務甚至離線窗口。目前，優秀的客戶服務已成為深圳平安公司的合作夥伴。在智能客戶服務領域實現了戰略合作。全面啟動人機對話培訓平台，為企業構建基於ai的智能客戶服務解決方案。

2018年9月，發布了4.0.0正式版本的優秀客戶服務，添加了群集和企業知識管理系統，使用群集解決方案支持多點部署方案，添加了企業知識管理系統組件，並擁有專業知識管理系統。和新的移動智能推薦。深入挖掘各種需求場景，人們對機器人的滿意度並不低於人工。

佛山市貝米信息技術有限公司（www.youkefu.cn）成立於2017年3月，是一支年輕而充滿活力的團隊。公司的主要「優質客戶服務」是一個全渠道的綜合客戶服務系統，集成了多個客戶服務渠道，以幫助各個行業。各種規模的企業建立了客戶服務體系。通過郵件，簡訊，電話語音，webim在線客服，微信，微博，h5頁面，app界面等各種渠道的客戶服務請求和對話，集成在管理平台上，統一響應和支持客戶服務。

當你打 10086 的電話，語音提示如下：

歡迎致電中國移動，

全心全意為您服務，

普通話服務請安 1，

For English service press pound key

...

我這個手機號用了 5 年了吧，打10086這個電話不下 50 次了，你還不知道我是不是說普通話？

以上只是舉了一個最常見的例子。

隨著智能技術的發展，越來越多的客服咨詢都開始交由對話機器人解決。

就在最近，冠狀病毒疫情爆發，大量民眾通過手機或電腦咨詢政府以了解最新的疫情信息和防控措施。在這特殊情況下，原本的人工客服是無法承接這么多咨詢的，而客服客服就尤為重要。

簡單來所，智能客服系統 主要基於自然語言處理、大規模機器學習、深度學習技術，使用海量數據建立對話模型，結合多輪對話與實時反饋自主學習，精準識別用戶意圖，支持文字、語音、圖片等富媒體交互，可實現語義解析和多形式的對話。

但是每個行業有自己的業務特點和知識范圍，每個呼叫中心公司都應該根據自己的業務，逐步解決最基本的問題。

比如10086，一次次重復問你說普通話還是英語。

智能服務是一個過程，不是結果。

隨著AI人工智慧賦能客戶服務。智能客服系統應運而生。

智能客服在提升企業服務質量和工作效率，降低企業管理和運營成本，提高企業的核心競爭力方面有著重要作用。

比如，我們利用AI技術能夠同時實現 智能語音導航、智能話務員、智能工單管理、智能數據分析、智能語音質檢、智能外呼 等功能。

並且能夠與用戶原有的呼叫中心系統有效對接，具有簡單操作易上手、功能齊備、實用性強的特點。

如果企業想實現客戶服務精細化運營管理，可以考慮試用哦~

一、智能機器人的能力
人工智慧客服系統的核心能力主要體現在智能機器人上，企業在選擇機器人前，需要了解機器人有哪些功能或能力，可以幫助企業做選擇參考。智能客服機器人通常包含以下幾項關鍵能力。

（一）自然語言識別能力

機器人擁有自然語言識別能力，可以幫助機器人更好的理解人類語言。舉個例子來說：人類對於一個問題會有多種不同的方式，機器人需要理解問題中的關鍵點，從而找到對應的問題。這是考察機器人性能時較為重要的指標。

（二）知識庫和自主學習

知識庫相當於機器人的大腦，企業需要在使用初期為機器人建設一套知識庫。這就相當於給新員工一個產品介紹或業務資料。在對接客戶時機器人會從已有的知識庫中搜索問題的答案。在不斷接受問題和解決問題的過程中，智能客服系統機器人會完善知識庫，將處理的問題積累下來，就形成了自我學習能力。通過這種方式可以方便以後更好的解決客戶問題。

（三）其他能力

有些智能客服機器人會有一些擴展能力，能通過網路/API介面找到一些其他資源，比如：查詢快遞、查詢天氣等等。具體來說：電商客服也許可以在與來客交談時，幫助客戶查詢快遞情況，這類需要由機器人就能完成了，並且速度和准確度都可以保證，無需額外的人力來處理這類問題。

二、人機對話有溫度

智能客服機器人不僅能替代人工客服的工作，在撥通用戶電話後，還可以像真人一樣與用戶進行溝通交流。而這些需要大量的人工智慧技術支出，比如自然語言處理、語音識別等多個領域。

Ⅱ 低調的王——「小能科技」客服系統產品分析報告

——「在智能客服領域，我就是王」

作者自述

我在一家公司做ToB產業電商平汪蘆清台。因為同在ToB行業，因此對小能科技產生了很大興趣。本文試圖用逆向工程的推理方式，理嘩畢性分析解構一下此公司的產品設計，以對比學習。

產品背景介紹

小能科技，這家做在線客服的創業公司，估值已達10億元，服務客戶包括海爾商城、唯品會、樂蜂網等2000多家企業。 企業標簽是 CRM、SAAS。

前言 —— ToB產品、SAAS產品體驗的困境

縱觀整個產品網站文章，對ToB產品的分析體驗文章是最少的，甚至有些行業是看不到的。

因為自己也研究產業電商，很多時候都必須和ToB、SAAS打交道。此時必然會遇到如下的困境：此類產品的用戶注冊門檻一般較高，且一般不提供免費試用——如果是互聯網形態的產品，連盜版都找不到。而我們一般沒有合作的情況下，無法以正當理由拿到對方的試用版賬號。

因此這里不會出現太多的根據《用戶體驗的要素》分層之淺層內容（如界面設計、導航設計、信息設計等），而是聚焦於從網站展示業務、網站場景頁面（頁面和對應的說明宣傳文字，此時，宣傳文字內容即為該頁面對應的場景）截圖、行業針對性分析，通過這些內容提取出 目標用戶、主要使用場景、用戶目標與產品訴求等產品關鍵性信息，並加以分析這部分內容。

時間分野：本文的背景在2017年，把2017年之前出現的公司、產品等都視為傳統公司、產品

分析框架引用：http://www.woshipm.com/evaluating/583453.html

Key Words：ToB，SAAS，客服系統，競品分析，產品體驗，用戶行為分析

============================================================================

正文：

用戶需求還原：

說明：教我ToB設計的人說過，ToB不要只考慮業務、工作流等等，還要看到在系統的背後，是哪些操作員在真實使用這個系統，這些操作員的畫像同樣很重要。（Use Case圖只能體現角色和系統之間的觸點，並不能很好地體現出人性，這就需要產品經理在ToB設計的時候注意特定的用戶（功能的操作員）與人性。）

設想如下的情景：

S1-1 我公司的客服老妹，電腦上開了N個qq、旺旺、京東等客服軟體，嘀嘀嘀的音效響個不停。

S1-2 當她離開工位後，這些客戶只能暫時被晾在這里，造成了客服系統體驗下降。

S1-3 老妹手機上開了N個qq、旺旺、京東等客服App，整個手機快要被擠爆了。

S1-4 老妹因為回答VIP問題不及時，被老闆扣錢。

S1-5 老妹接到客戶對訂單的反饋時，就會生成一個工作流 —— 跟蹤問題，並按照標准流程做出處理，最後反饋給客戶。

S1-6 老闆需要衡量和管理老妹的工作質量。

以上就是提到客服系統時，我們首先憶起的傳統客服系統。

----------------------------

根據小能科技的介紹，他們把產品目錄分為在線客服、機器人和呼叫中心三部分。

根據我對電商系統的理解，可以合並呼叫中心這一獨立產品到客服系統（分為語音接入和文字接入——印象中現在有語音接入的電商比較少，傳統行業轉型的企業可能多一些語音客服）。而機器人從功能上可歸類為篩選客戶模塊的一部分。因此，我們可以歸納出如下的用戶需求：

S2-1 系統按照分級處理思想，把客戶按照設定好的規則在人工座席接待前困前排隊。

S2-2 系統需要提供非人工的客服，將一部分無需人工處理的客戶分流。

S2-3 知識詞典，自動咨詢的一部分。

S2-4 機器人問答系統：裝一下逼，而不是單純的知識詞典——突出高科技屬性（投資人喜歡看到這個，屬於獵奇需求）。

S2-5 企業可以選擇是否使用語音客服，如果使用則提供一個成套的互聯網電話呼叫系統。

-----------------------------

特別的，有一部分內容，我認為是超用戶預期的功能，這部分場景真是產品經理腦洞大開的產物，也是創業公司賴以生存的用戶壁壘所在。 根據最近對GrowingIO的增長黑客研究，「獲客渠道」，在做渠道轉化率分析時，是最價值的信息。

另外，一般而言，用戶交互數據+用戶訂單數據合在一起就是在系統邊界內可以被感知到的用戶行為數據。根據小能科技的功能介紹，小能科技也把這部分內容和客服系統相結合了。（其實更像是把用戶與客服溝通數據加入進用戶行為數據中去，使得這個數據更加精準了。）

小能科技在描述中說，他們可以追蹤到用戶對購物車的操作，那麼這應該使用了埋點/無埋點技術。具體使用了哪種技術有待觀察。

歸納出需求如下：

S3-1 可以按照渠道歸納用戶信息。

S3-2 把用戶訂單信息結合進客服系統。（或者把用戶與客服溝通數據結合進用戶行為分析系統）

S3-3 使用埋點/無埋點的方式，獲取用戶交互數據。

S3-4 一個UI靚麗的分析系統

------------------------------

另外、有一些企業級的基本需求需要被考慮其中

S4-1 企業級賬戶管理體系：管理員——分許可權——最低許可權，一套金字塔體系。

因此可以總結出小能科技的用戶需求為：

============================================================================

產品市場現狀

目前企業級服務市場熱度相當高,不過企業服務市場有個問題，無法爆發增長，沒法看到一條長陽線用戶直沖一個億的奇跡。話說回來，因為客單價高，行業體量大，有可能企業只有一百個客戶，但年GMV做到10個億。

-------------------

根據場景S1-1，企業凡是在多平台開店的，都需要這種把多個平台的客服介面聚合在一起的系統，我們可以稱之為「客服聚合系統」。

根據小能科技官網的展示，他們在如下幾個方面都有客戶：平台電商、垂直電商、跨境電商、在線教育、互聯網金融、醫療衛生、O2O、汽車、在線旅遊。

以上客戶可以分為如下兩類：店鋪類與小型電商平台。

店鋪類：企業在各大型平台上有店鋪存在，需要聚合各來源客服信息，統一處理。

小型電商平台：都是小型的電商平台，可能自己的開發能力有限，直接接入小能科技客服系統自用。

---------------------

因為沒有公開的數據，那麼我根據互聯網公司盈利模式，推測所有的符合客戶氣質的收費方式是：

1、按咨詢量收費（和GrowingIO按照日活用戶數收取費用類似的套路）。

2、分檔次收固定年費、比較傳統的方式 —— 針對傳統企業比較合適。

============================================================================

產品核心策略分析

我們從小能科技的宣傳語開始分析：

「小能客服打通Web網站、移動網站、微信、APP、電話、表單、郵件等等，無論顧客來自於哪個渠道， 都可以在小能客服後台統一接待。」

小能客服的基礎是一個客服聚合系統，這一點和別家沒有什麼不同。

繼續看下去，可以發現一個最大的亮點是：把用戶行為分析系統結合進客服系統，從用戶分析角度重構客服系統。這點和做積分系統的匯積分有點像，匯積分是把用戶行為分析系統整合進積分聯盟系統，從用戶分析角度出發重構積分系統。具體而言，就像是一個結合了GrowingIO的 客服系統/積分系統/whatever系統。

同時我們看到小能科技經過這么長時間，一定基於用戶DNA（比如手機號等）能整理識別出大量的用戶行為數據。同時，在新聞報道中也印證了這一點「小能的企業客戶規模已經超過2000家，囊括了3億多用戶的相關數據，相對於同行擁有明顯的競爭優勢。」「憑借大數據，在最近一次，投資方給出了10億的估值。」—— 這就是所謂借所有接入方的注冊用戶數據為己用。

另外，我們還看到了客服機器人的身影。

但我認為機器人並不是核心策略，這要從用戶角度闡述。用戶可能會調戲一下機器人，但大多數時候，用戶都是帶著目標進場景的，和機器人聊天並不是用戶主要使用路徑，（除非機器人能滿足用戶的目標，比如AI代替客服來處理客戶的訂單或投訴問題。）——獵奇是允許的，但不是剛需。

總之，梳理以上核心策略，可以畫出如下的圖：

在我們安排開發計劃的時候，MVP功能一定是先聚合，後加入分析系統。最後再去公關機器人；或者我們機器人就不做了——投入高，而滿足用戶需求不明確。

============================================================================

產品結構分析

根據小能科技官網圖片，以及對需求的挖掘，應該有如下主要的產品結構：

1、客服聚合系統

多平台客服API接入、用戶分級排隊系統{多渠道來客共同排隊；區分售前（咨詢）與售後（產生工單）}、分級規則池（用戶識別與行為信息介入觸點）、呼叫中心、人工座席、工單系統、用戶行為數據傳入分析系統

2、用戶行為數據分析

交互數據（購物車）、訂單數據、用戶客服反饋數據、增量用戶行為大數據系統

3、用戶行為大數據

用戶識別、渠道識別、傳遞歷史數據到用戶行為分析系統{交互數據（其他平台）、訂單數據（其他平台）、用戶客服反饋數據（其他平台）}

4、客服機器人

知識庫、互動問答、自學習、訓練

5、企業級管理系統

客服中心管理系統{ 客服KPI管理、數據指標展示}，用戶行為數據展示

腦圖如下：

============================================================================

用戶使用評價

從小能科技公司發展軌跡中分析，既然客戶在增加，投資人在投入。這就說明用戶評價不錯。

不過因為處於ToB市場，所以小能科技的知名度不行，網路指數也未有收錄。

============================================================================

思考與總結

目前用戶增長黑客非常非常火。給我們的啟發也非常非常大。各種SAAS都可以結合用戶行為數據分析，看看能否做出與眾不同的產品？成為下一個獨角獸。

-----------------------------

另外，可以思考目前客服機器人的幾個問題

1、你在JD購物的時候JIMI可以幫你處理訂單退款嗎？

2、微軟小冰為什麼只火了一段時間就退潮？

這說明目前客服機器人並實用，無法滿足帶目標用戶進入客服場景下的需求。不過隨著AI技術的發展，希望有一天，AI客服可以完全替代人工座席 —— 如果小能科技能做到，那麼客服行業同階無敵。

Ⅲ 關於實現在線客服系統需要哪些技術

一個在線客服系統在技術上應該有一下幾個基本的方向：

1. 通信協議（http、websocket等）

2. 集群部署（沒有集群怕是服務的客戶量會很少而且升級一會很麻煩）

3. 大數據相關技術（在線客服記錄的基礎數據有訪客的瀏覽數據、對話數據、客戶信息等等數據量是比較大的，了解大數據相關的數據應該是必備的）

4. 智能學習-機器學習（一個好的在線客服系統應該需要提供智能客服幫助人工客戶解決問題）

可以通過專業的在線客服對外提供的API了解到很多他們用的技術棧和開發思路。比如：一洽客服開放API

Ⅳ AI技術如何打造智能客服

AI技術已經廣泛應用於客服領域，打造了更加智能化、高效率的智能客服系統，以下是實現的技術和流程：

1. 自然語言處理：智能客服系統需要能夠識別並理解自然語言表述的問題，更加高效地解決客戶的問題。自然語言處理技術包括語音識別、語音合成功能、文本語義分析等等。

2. 機器學習：機器學習是智能客服系統實現強大的自動回答、自我學習的關鍵技術。通過分析歷史數據和用戶反饋，機器學習可以自動調整不同情況下的處理方法，提供更精準和快速的服務。

3. 多通道交互：智能客服系統具有多通道交互支持，包括語音、文字、圖像等不同形式的輸入和輸出方式，提供更多可能性來吸引和服務用戶。

4. 失敗補救流程：當智能客服系統無法理解用戶的問題或無法解決用戶的問題時，需要智能地為用戶找到其他解決方案或將用戶轉交給人工客服，保證用戶的滿意度。

5. 聯合處理：當智能客服系統檢測需要介入人工客服時，需要及時將用戶的及時數據和聊天記錄轉交給人工客服處理。同時，處理系統也需要將人工客服轉交的結果自動反拿蠢指饋回智能客服系統，以提高處理效率和服務質量。

6. 維護持續更新：智能客服系統需要不斷更新和完善其聊天庫、知識庫和處理流程，以保持服務的可靠性和高效率。

需要注意的是，在實現智能客服系統之前，需要先考慮制定一個完善的開發計劃和用戶體驗計劃，確保系統的可持續發展和服務體驗。拓展上面提到的幾點，以下是智能客服系統的更多實現技術和流程：

7. 對話管理：聊天機器人也需要能夠實現多種對話和流程管理，這需要更加高效的涉及到自動問答的句法分析、語義分析和關鍵詞提取，以及新奇的、符合多樣化用戶場景和習慣的語料建設。

8. 又稱智能匹配和推薦：對於產品和服務的方案及其數據的眾多並存，AI技術在智能客服系統中也需要能夠庫存維護、演算法優化和用戶需求匹配。

9. 自助服務：人工客服系統因為建立成本、運營成本、人員素質等原因等條件下，還需要通過自助服務來減輕壓力，提高對等消配流量的處理，增加用戶滿意度。智能客服工程可以融合搜索引擎技術、隨時帶來常識庫等多種技術來提高搜索匹配度，從而有效檢索和檔差供應智能方案。

10. 賬號集成和術語掛接：智能客服應用系統需要在賬號集成和知識庫共享上做好規劃和實踐；對語料庫進行分詞、掛接，對相似問答進行統一掛接，避免巨量的人工干預，提高使用效率。

總之，智能客服系統的實現技術和流程是多樣化的，在不斷深化的時代背景下，也在不斷欣欣向榮。

Ⅳ 智能客服系統應該具備哪些功能想要接入一個。

智能客服系統,需要具有意圖識別、多輪會話、上下文理解、知識庫智能學習等多項前沿技術

1 意圖識別:基於前沿神經網路技術，在億萬級數據集上訓練得到的意圖識別模型 能夠自動抽取用戶問句中的時間、地點、人名等關鍵性信息，自動識森橘別同一意思的不同問法，正確理解用戶的意圖

如果想要接入自己的微信公眾號,官網,app,小程序等等都是沒問題的

Ⅵ 智能客服結構-v1.0

前言 ：這篇文章僅對客服機器人這種偏任務導向型機器人架構的探究，文章中部分是已經得到驗證的經驗，部分是經歷了行業無數競品的對比中針對面臨的問題重構出的產品結構。我一直堅持「對話機器人的對話結構是搏搭一個產品策略」的觀點，所以這篇文章更偏向於針對電商（筆者是電商垂直行業）智能客服對話機器人（文中簡稱智能客服）中的用戶現象的產品策略問題，蠢如有不足之處歡迎各位產品與技術大佬們指導。

一、目錄概述

內容主要分為整體結構與常見問題兩個角度的探究。因用戶在智能客服中的表現的多樣性，故不窮舉贅述，在每個解決方案與架構設置原因中針對單獨問題一一探究。

二、智能客服主要解決的問題

客服主要解決用戶Q（query）→A（answer）問題，好的資深客服對業務邏輯結構更了解，不僅能基於用戶未完全形容時推斷用戶情況、根據用戶情況給予更多的業務解決方案，更能在對話中判斷用戶的傾向性（情感、期望值等）。

那智能客服如何像客服一樣解決問題呢。下面引入三個概念

圖1 用戶問法，業務邏輯結構，業務解決方案關系圖

名詞解釋：

[if !supportLists]Ø  [endif] 業務邏輯結構（因筆者對知識圖譜理解太淺，固用此名字代替） ：面向用戶的業務類型，多呈現樹狀結構，如售後，售後-退貨，售後-退貨-運費等的二叉樹結構；某個子業務的判斷條件，如常見電商的退貨條件為七天。

注 ：為什麼將判斷條件放在業務邏輯結構中，後續會講到的用戶問法中會將某一判斷條件作為意圖放在會話中。如「我要退貨」的處理方式需要判斷用戶訂單是否超過七天，用戶的延伸問法「我的訂單剛買兩天，想退貨」，此問題在理解中屬於重難點解決問題。

[if !supportLists]Ø  [endif] 業務解決方案 ：通常針對於某一業務會延伸出多樣化的子業務，如：「我要退貨」「退貨用什麼快遞」「退貨的運費誰承擔」，通常對於一問題會有至少1+的解決方案（公司能提供的解決方案多少問題根據公司能力決定不在此討論）。

[if !supportLists]Ø  [endif] 用戶問法 ：自然語言中的現象結合某一子業務產生的問法類型不用，如：「定義類——什麼是七天無理由退貨」「滿足類——我的訂單支持七天無理由退貨嗎」等。

解決智能客服問題應答用戶問題主要解決 兩個問題 ：

1.解決用戶問法在業務邏輯結構（知識圖譜）中的位置問題。

2.解決用戶問法+業務邏輯結構=用戶解決方案問題。

三、

針對於上面我們提到的智能客服主要解決的問題，筆者提供兩種 解題思路 ：

[if !supportLists]1.    [endif]分類業務類型，將業務類型中的問題用QA的方式維護，對用戶問題中的子串（去無用詞「嗎」「好的」等）用檢索重排序的方法分別在增加的Q中和A中進行篩選，最終篩選出閾值最高的一條Q或者A，以此條答案為回復用戶問題的答案。當然，中間有不少穩定準確率與召回率的兜底方案，可根據實際情況調控。此方法的好處在於穩定，不過更像解決搜索帶銀啟問題而不是解決對話機器人問題。

2.第二種方案是本篇主要講的方案，引用三角獸科技CEO 王卓然博士《任務驅動多輪對話評測標准【人機對話評測系列之一】》中的圖為例。（文末會有此篇文章的鏈接）

圖2: 任務驅動的多輪對話系統的一個經典框圖

主要把智能客服對話結構為三部分：意圖理解NLU（用戶目的分類和Spoken Language Understanding）、對話狀態（Dialogue State）、應答（System Action）。圖中ASR（語音識別）、NLG（答案生成）、TTS（文語）模塊因並非提升智能客服主要的體驗問題，並且筆者未深入研究，故此篇文章不深入探討，後續了解後會針對這些問題單獨講述。

三、智能客服與業務結合基礎

3.1 把業務教給智能客服

上文中提到，要解決用戶問題，必須讓對話系統模擬業務的真實狀況，所以梳理業務邏輯結構非常重要。

拆分業務邏輯主要為三點原則：

[if !supportLists]²  [endif]用戶通常有哪些目的（能提供的業務有哪些）

[if !supportLists]²  [endif]這些目的之間有沒有關聯性（不包含會話中易出現的關聯性）

[if !supportLists]²  [endif]哪些信息（條件）是實現目的的必要因素

待探究問題：有沒有清晰的拆解規則同時滿足NLU的准確性與業務的完整性？此規則能否通用？

拆分完業務邏輯結構，更重要的是把業務邏輯結構教給智能客服。基於拆分的三點原則，我們要教給智能客服的為兩點：

[if !supportLists]²  [endif]有哪些意圖（intent）或分類—自然語言理解的分類問題。

[if !supportLists]²  [endif]哪些是實現意圖的必要條件—結構化識別與多輪對話問題。

3.2 理解用戶在對話中的目的

在對話系統中，自然語言中的query會呈現結構化的語義表示，這個結構化的語義通常被稱作dialogue act由 communicative function 和 slot-value pairs 組成，其中 communicative function 表示 query 的類型（如：陳述需求，詢問屬性，否定，選擇疑問，等等）而每個 slot-value pair 則表達一個限制條件（constraint），也可理解為用戶目標的一個組成單元。

例如「我的訂單到上海了嗎」對應的dialogue act可以表示為inform（entity=訂單or物流，location=上海）。這里的inform就是communicative function，表示詢問查詢，「entity=訂單or物流「和「location=上海」是限制條件（slot-value pair）

四、智能客服架構

3.3 意圖識別NLU

此處的意圖識別NLU，單指 對用戶標准問法(用戶一句話把問題描述清楚)的理解與分類 和對話系統中的 口語處理問題 。

由於用戶在對話系統中輸入時更偏向與口語化的表述，所以在對話系統的意圖識別板塊，我們更關注口語處理，其中包含了對非嚴謹語法（即用戶問題可能產生的語法錯誤糾錯與錯別字接錯）和識別中如何保持准確的魯棒問題。

為什麼一定要將用戶語義（dialogue act）作 結構化識別 ，主要是解決用戶將條件加在會話中陳述的導致容易造成智能客服理解混淆問題（例如上文提到的我收貨兩天了能不能退貨）。

當然，我們也可根據業務場景不同才用不同的識別策略。

Google 的dialogflow 在識別上有的三種策略：

[if !supportLists]²  [endif]trait策略：整句理解，比如意圖、情感等，通過分析整個用戶問句來得到實體值

[if !supportLists]²  [endif]free-text策略：用來抽取用戶問句中的子串，這些子串通常不會包含在預定義的實體值詞典中

[if !supportLists]²  [endif]keywords策略：用於處理需要抽取的實體值可枚舉的情況，我們為實體准備好一個預定義的實體值詞典，該實體的抽取就通過使用實體值詞典做匹配來完成

網路UNIT 也同時區分了利用詞槽與槽組的識別與特徵詞的識別。

採取哪種識別策略，主要還是根據業務的可行性與最終達到的效果進行確定 ，當然亦可組合使用，我們可以根據詞槽來判斷用戶詢問的業務之間的關聯性，可根據用戶整句識別判斷用戶的情感偏向，也可在業務子串可窮舉並且關聯性小的情況下使用關鍵詞策略提高識別的准確性。

但是在用戶與機器完成的單輪對話中，依然存在一定的難點，此問題在後面詳細討論。

結論： 上文中提到的意圖識別或SLU問題，大家應該可以注意到，其本身都是典型的結構化分類問題，雖然所用的模型千差萬別，其中對於處理過擬合、欠擬合的方法也褒貶不一，但是無非就是准確率、召回率等問題。

3.4 對話狀態

對話系統中存在的現象決定了對話狀態跟蹤（Dialogue State Tracking）存在的必然性。

大家可以注意到，上文中提到的分類問題屬於標准情況下的處理方式，但用戶在對話系統中的表現擁有不確定性，所以在這里給對話系統引入了一個在不確定性環境下決策的問題（planning under uncertainty），雖然最終的決策是由下面要介紹的對話策略完成的，但是對話狀態需要為後面的決策提供依據，也就是如何刻畫這個不確定性的問題。

在智能客服對話中存在以下現象：

[if !supportLists]ü  [endif]不考慮上文中提到的口語處理，在用戶問法中，存在 閑聊 與 業務 兩種形態的對話，其中閑聊為業務的輔助構成部分。

[if !supportLists]ü  [endif]業務問題中，存在 意圖清晰 與 意圖模糊 的問法

[if !supportLists]ü  [endif]用戶意圖清晰的情況下，我們需要根據業務需要讓用戶補充必要條件，或通過用戶補充讓問題更精確。如：天氣問題中，用戶詢問「北京明天天氣」「北京明天八點天氣」，都可給出答案，不同的在於答案的精準程度。

基於以上三種現象，首先我們需要知道用戶在 當前對話 中 處於什麼狀態， 其次是根據當店對話狀態我們給出用戶 最終答案 需要什麼 對話策略。

3.4.1 對話狀態跟蹤

對話狀態跟蹤，簡單來說就是根據對話來確定用戶 當前或最終的目標 到底是什麼，此處不僅包括封閉域對話中的 任務驅動式多輪對話， 還包括區分閑聊、問答、任務四類問題，根據業務情況劃分意圖模糊與意圖清晰之間的界限。

[if !supportLists]Ø  [endif]在區分閑聊、問答、任務類問題中，大概可分為三點

[if !supportLists]1.    [endif] 為什麼要區分閑聊 ：閑聊是一種不局限於話題的開放域聊天（開放域機器人如微軟小冰），即在用戶的問題 沒有明確的信息 或 服務需求時 系統做出的回應。

開放域聊天在智能客服中的作用有兩點：第一點為拉近距離、順滑對話過程、建立信任等；第二點為挖掘用戶情緒引導用戶服務請求。

[if !supportLists]2.    [endif] 是否需要區分問答、任務類 ：以智能客服行業典範阿里小蜜來說，是區分了問答類和任務類問題的，但是為什麼區分政策和任務類問題以筆者的經驗來說僅是根據解決方案的不同，但在用戶query無法提現。

如：「是否支持七天無理由退貨」的兩層含義：一層為公司政策是否支持，一層是用戶詢問購買的商品是否支持。前者是以搜索較優方案的政策類解答問題，後者是以任務式判斷的方式解答問題更為准確。

所以，在QA問答系統和task flow驅動式系統上，個人認為電商類問題更趨向於用task flow解決問題並將QA融入其中。當然，此問題還需要根據客服解決問題的形態具體情況具體分析。

[if !supportLists]Ø  [endif]意圖清晰與意圖模糊問題

如何定義意圖清晰與意圖模糊問題，拋開自然語言中的口語處理不講，我認為它 更偏向 於一個 業務問題 。

對於用戶來說，用戶對智能客服的目標（user goal）是可以確定的，用戶目的的表示形式是一組限制條件（slot-value

pairs）的排列組合。換句話說，理解用戶真正的目的（user goal），需要機器理解上文中說到的業務邏輯結構（知識圖譜）中每一枝乾的關系（或歸屬於某一枝幹）。

也就是說，當用戶當前的會話表述中某一組限制條件的排列組合 對應多個枝幹 時，為 意圖模糊問題 。當 對應一條枝幹 時，為 意圖清晰問題。

對於 意圖模糊問題 的解決方式，大可以用檢索式反問的形式來引導用戶，即詢問用戶 可能想問的問題是什麼 。對於 意圖清晰問題 ，但無法給出明確答案時，為一個 任務驅動式的多輪對話問題 （後文多輪對話展開討論），即電商問題中常見的需要用戶補充訂單號或某些意圖。

[if !supportLists]Ø  [endif]當進行了前面的口語處理，閑聊與業務區分，區分意圖模糊與清晰問題後，我們已經可以理解了用戶的目的，即用戶問的問題屬於業務邏輯結構（知識圖譜）中的哪一枝幹，接下來在解決用戶服務請求的過程中，最後需要處理的就是 補充用戶目的所需的判斷條件或槽位 （如「查物流」我們需要知道用戶的訂單號）和 判斷用戶的目的改變 （如「查物流」轉變為「幾天能到」問題） 。

以上問題為智能客服對話狀態跟蹤中常見的需要解決的問題，但是任務驅動式多輪對話中問題現象不僅於此，在下文的多輪對話問題中再詳細闡述。

3.4.2 對話策略

理解了用戶在對話中的行為，我們來討論一下關於對話狀態中使用的對話策略問題。

對話策略是根據上面介紹的置信狀態來決策的過程。對話策略的輸出是一個系統動作（system action）。和用戶的 dialogue act 類似，系統動作也是一個由communicative function 和 slot-value

pairs 組成的語義表示，表明系統要執行的動作的類型和操作參數。「每次決策的目標不是當前動作的對與錯，而是當前動作的選擇會使未來收益的預期（expected long-term reward）最大化」

根據上文中的講述，此問題也可分為三種類型。

[if !supportLists]Ø  [endif]基於開放域機器人的閑聊來建立信任、引導操作、增加對話流暢度問題，此問題筆者並沒有深入研究，但就經驗來講，可實現的策略包含用戶發起咨詢時的預判用戶問題與引導用戶操作。

[if !supportLists]Ø  [endif]區分用戶意圖模糊與意圖清晰的策略，在意圖模糊中，個人更偏向於用檢索+重排序的方式定位用戶問題在訓練語料或業務邏輯結構，進而產生用戶可能咨詢的問題，也就是在對話中反問用戶，但一方面用戶會因為機器人猜的不準確而對智能客服的信任感降低，另一方面推測的准確性和人一樣，更依賴於知識的覆蓋率與准確率。所以，讓智能客服像資深客服一樣能「猜」的更准，還是一個需要實際驗證的問題。

[if !supportLists]Ø  [endif]任務驅動式多輪對話中的補充用戶槽位與目的轉變的槽位繼承問題本身更偏向於根據業務去優化的問題。

補充用戶槽位的問題很好理解，如「查物流」需要詢問「您要咨詢的訂單號是？」，進而能得到很好地解決。

目的轉變後的槽位繼承問題還是需要根據業務情況做詳細調整，如上文提到智能客服在「查物流」中獲取了用戶訂單號，那麼用戶問「多久能送到」時，意圖轉變後訂單號依舊需要繼承。當然此問題中會因用戶有澄清式問法而改變，如用戶增加「我要咨詢其他訂單」的問法後，即清除對話狀態中的「訂單」。以上只是舉了兩個簡單的例子，但一個業務中可能包含多個槽位或一整個槽位組（槽位之間存在平行、依賴關系），針對於業務情況不同，對話策略還需要精細化運營。

3.5 應答-最終答案

在經歷了教會智能客服理解用戶問題的漫長過程後，我們終於來到了討論給予用戶的解決方案部分。

普遍的來講，解決方案可以有文本、圖文、視頻、API集成等多種的樣式，但實際最終用戶的query只會得到唯一的answer，這個唯一的answer的樣式及豐富程度，不僅僅取決於我們業務不同需要給予用戶不同的解決方案，同時也依賴於對話狀態中還可以記錄完成對話任務所需的其他額外信息，例如用戶當前詢問的屬性（requested slots），用戶的交互方式（communication

method），和用戶或系統的歷史對話動作（dialogue history）等等。

以觀察阿里小蜜的經驗來講，小蜜從原來的圖文答案部分轉向了API繼承的方式，但依然沒有感知出針對於用戶畫像給予不同的答案（可能是我不怎麼咨詢客服的原因）。

所以以上的內容就不在這里展開，我會在後面《智能客服服務提升》中討論。

四、結論

能從頭看到這里，我相信不是對智能客服本身有一定了解忽略了一大部分抽象內容，就是根本不需要看前文就能理解結構的大佬。

個人認為，智能客服的架構本身只有三部分意圖識別及SLU問題對業務進行的分類問題，用戶在對話中的表現轉化為標准問法的對話狀態（DST）問題，與歸屬完問題後提供給用戶最終的解答方案問題。完成這三部，大概在產品架構上能實現智能客服從0到1的方案。

當然構建三部分時應該遵循幾點原則：

[if !supportLists]1.     [endif]保持訓練語料的一致性，用戶問題是否直接分類、意圖模糊或需要用戶補充統一由對話狀態模塊判斷。

[if !supportLists]2.     [endif]業務的拆解盡可能細致，因為業務邏輯結構（知識圖譜）決定了結構化識別的准確性與對話狀態的判斷准確率。

[if !supportLists]3.     [endif]識別策略和對話策略中盡可能增加兜底方案保證准確率與召回率，結構化識別並不是萬能的，有時我們也需要加入檢索的方式保證用戶問題會產生一個相對准確的解決方案。

以上為智能客服架構時的一些思路，至於每部分中提到的具體問題，會在後續《智能客服的服務提升中》探討。

Ⅶ 智能客服系統有哪些功能

相較傳統客服，智能客服系統通過一系列強大功能，有效的提高了客服的效率。

一、多渠道客戶接入
擁有多個獲客渠道的企業可以將其客戶咨詢接入客服軟體，客服人員只需要登錄客服軟體一個平台即可回復所有渠道的咨詢消息。
支指團持接入渠道：網頁、對話納逗備鏈接/二維碼、公眾號、小程序洞毀、App等等

二、多客戶端回復
通過將渠道接入客服軟體後，原本只能在網頁回復的客戶咨詢可以通過客服系統手機App客戶端進行回復，更加便捷。
支持回復客戶端：手機App、小程序、電腦桌面客戶端、網頁

三、智能客服機器人
客服人員可以將接待中遇到的基礎、常見問題設置為機器人自動回答，且客服人員還可以根據情況在每個渠道設置不同的智能機器人，有效減少人工客服打字回復量，在咨詢量大時效果更為明顯。
支持功能：關鍵詞匹配回答、智能菜單、條件轉人工、顧客輸入引導

四、客戶自動分配機制
可以根據客戶的來源渠道來分配對應的客服組，支持多客服協同工作對話自動平均分配以實現資源利用最大化。還可以配置出各種自定義分配邏輯靈活且強大的分配功能能夠滿足你所有的需求

五、對話輔助
根據客服實際情況設計的效率提升功能，使人工客服回復更高效。
客服工具：快捷回復、顧客輸入預知、同步客戶資料、顧客標簽

六、客服團隊管理
傳統客服使用的通訊軟體無法對客服人員的工作數據進行統計，管理人員很難對客服團隊的工作情況有深入的了解。客服軟體通過將客服人員的工作數據化，使管理者以直觀的工作數據做支撐，深入了解客服團隊工作情況，以便優化提升。

統計數據：接待量、響應時長、客戶評價、有沒有遺漏咨詢、登錄時長等數據
多維度統計：客服團隊整體的接待量、對話率、回復的消息數等精確到小時的數據

Ⅷ 智能客服對話場景設計方法

一. 智能客服中場景的定義及分類

用戶解決某一個問題，需要與機器人進行多次對話才可以解決的問題，就是智能客服中的對話場景。一般它分為單場景對話和多場景對話。

1.單場景對話

定義：用戶與機器人只進行一個主題的對話，如「查天氣」

  例1  場景【 查天氣】

        用戶：明天天氣怎麼樣

        Bot ： 零下10度，可以多穿一些毀鉛哦。

        用戶：那上海呢？

        Bot ：:零下1度哦。

2.多場景對話

定義：用戶與機器人聯系進行了多個主題的對話，如「查詢訂單+退貨」。

例2  場景 【查詢訂單+退貨】

          用戶：看一下我買的東西到哪了

          Bot：  向用戶發出訂單列表

          用戶： 嗯，看一下第二個

          Bot：  發出訂單詳情

      用戶：還沒發貨啊，幫我退了吧。 ——從用戶的這句話開始，對話的場景就從「查詢訂單狀態」」變成了「退貨」，退貨與查詢訂單是兩個不同的主題，他們既可以獨立存在，也可以合二為一。

            .

二.場景設計

設計一個對話場景，主要包含兩個方面：起始條件整理、流程整理。

小知識：假設「查一下明天上海的天氣」是用戶說的第一句話，那麼它就是一個場景中的起始條件，而在這句話是由兩個要素詞構成的「明天」，「上海」，這兩個要素詞分別代表了時間和地點。由此可以推論出這個起始條件的主要結構是時間+地點。

1.起始條件整理

在對話場景中用戶與機器人第一次交互時，所說的話為起始條件。而一個對話場景有多個起始條件，不同的起始條件會讓機器人與用戶的對話的流程出現不同的走向。所以場景設計的第一個步，我們陵耐需要將對話場景中不同的起始條件全部整理出來。

例3 場景 【查天氣】

條件舉例

例4 場景【請假】

條件舉例

2.對話流程

整理好全部的起始條件後，就可以根據去撰寫每一個條件下的流程。具體可以看下面的例子。

例5  場景【請假】   

      起始條件：僅包含請假

      U：明天請假

      A:請到哪天呢？

      U:後天

      A:請告訴我工號

      U:001

      A:您的請假申請已經提交了。

例6

    對話起始條件：僅包含請假天數。

    U：請三天假

    A:請問您是哪一天開始請假？

    U:後天。

    A:請到什麼時候呢？

    U:周五。

    A:請告訴我您的工號

    U:001

    A:您的請假申請已經提交了。

通過例5和例6我們可以看到起始條件的不同，會導致對話的流程也不同。所以整纖汪好理出全部的起始條件事關重要。不過對話流程整理好之後，場景設計的部分就高於段落了。接下來就需要進行意圖的整理。

三.對話意圖的設計

這一部分主要介紹意圖的分類、如何拆解場景中的對話意圖、對話意圖知識的設計及優化。

1.意圖的定義與分類

意圖是指用戶的目的，如用戶說「我想聽音樂」，那麼聽音樂就是用戶最終的一個目的，我們只要給他播放一段音樂就可以了。在智能客服的使用情況中，意圖一般分為兩大類：問答意圖和對話意圖。問答意圖是指一問一答，如用戶問「退款時效」，退款時效這個問題，每個商家都有一個固定的答案。這就是一個問答意圖。

但在對話場景中，用戶都會與機器人多次交互，每一次交互用戶都會表達自己的目的，這個目的其實就是我們所說的對話意圖。 請看例子

例 7 場景【查快遞】

在網上買完商品時，我們會查買的商品的派送情況，圖中的用戶說「我的快遞到哪了」。「我的快遞到哪了」這句話就是一個對話意圖，用戶說它的目的就是查詢快遞派送的進度。

2.對話意圖的拆解

一個對話場景中一般都包含多個對話意圖。基本上，用戶和機器人的每一次互動就是一個單獨的對話意圖。我們可以把例7圖里的對話流程寫下來 看一下

例8  場景【查快遞】

起始條件：多個商品訂單

U:我的快遞到哪裡

A:訂單列表

U:選擇一個訂單

A:顯示訂單派送情況

在這個場景中，用戶表達了一個目的就是「查詢訂單狀態」，所以機器人會向用戶推出訂單列表，確定用戶詢問的是哪個訂單。這就是一個對話意圖。接著用戶確定了具體查看的訂單後，機器人需要把確定好的這個訂單的物流信息發給用戶，這也是一個對話意圖。

所以上面的場景中包含了兩個對話意圖。到這針對於這個場景的對話意圖的拆解，就結束了。

3.對話意圖知識的設計

拆解好場景中所包含的對話意圖後，我們需要設計意圖。還是用場景請假來舉例

例  場景【請假】

      起始條件：僅知道開始時間

      U：明天請假

      A:請到哪天呢？

      U:後天

      A:請告訴我工號

      U:001

      A:您的請假申請已經提交了。

對話有三輪，所以這個流程里有三個對話意圖。我們先來看第一個對話意圖的對話內容。

U：明天請假

A:請到哪天呢？

明天請假，在這句話里明天是一個要素詞，它代表了請假開始的時間。所以這個意圖=請假開始的時間， 它的構成成分就是具體的時間/日期 ，如今天、明天、12月30日等等，而一般的對話系統中會把時間類的詞語都內置進去，所以這里就不在進行窮舉了。

這個對話中只含有了一個要素詞，但根 據起始條件的不同 ， 對話意圖中包含的要素詞的數量都是不一樣的 ，具體的可以參考每一個起始條件的流程去設定。

4.對話意圖的知識優化

對於同一句話，每一個人的表達方式都是不一樣的。為了使機器人能更准確的解讀用戶所表達的意思，做好知識的優化是一件必要的事情。優化步驟包括：寫出所有句子——拆解組合——歸納同義詞。

例： 快遞到哪了

         物流到哪了

         東西到哪了

這幾個句子表達的意思都是「查物流」，可它們的用詞並不完全相同，通過拆解，我們可以得到以下結論：這條知識=快遞的同義詞+到哪了的同義詞

例：  查快遞

          查一下快遞

          快遞查詢

          查一下商品物流

這組句子表達的意思也是「查物流」，它們的用詞並不完全相同，通過拆解，我們可以得到以下結論：這條知識=查的同義詞+快遞的同義詞。

分析完上面兩個例子，可以很明顯的看到這兩組的組合都只有兩個片語，而其中有一個片語是相同的，所以可以將這兩組組合進行合並：快遞的同義詞+查/到哪了的同義詞。

四. 意圖知識的線上管理

1.機器人的分配

將所有問答意圖及對話意圖設計和優化一遍之後，就要將這些准備好的知識導入到機器人的線上平台進行操作。一般的客戶在平台上只需要建立一個機器人，同時綁定多個知識庫，就可以達到效果了。

但像一些客流量大電商客戶，他們會根據整個的業務場景去創建機器人，如售前機器人、售中機器人、售後機器人。這樣做有一個好處，就是當客戶有問道一些機器人無法回答的問題，可以直接轉人工到相關類別的坐席。

還有一些客戶，會復雜一些。他們是一個大的企業，在他們的內部有很多的部門，每個部門都在使用同一個後台。

例  A企業下有人力、財務、行政、生產、項目等部門，他們使用同一個企業賬號登錄一個後台。每個部門都會建立知識庫，但是如果都綁定在一個機器人上就會出現一些問題。

如果非要使用同一個企業賬號，在這種情況下建議，每個部門可以在後台各自都建立一個機器人，並將自己部門的機器人只綁定部門相關的知識庫即可。（最好可以有許可權設置）不過最好每一個部門都使用獨立的企業ID，各自登錄各自的後台，不會造成干擾。

2.對機器人進行評價及調整

經過了一段時間的運營，我們需要知道機器人的效果到底是怎麼樣的？一般來說，只要去將機器人的對話日誌導出，進行分析即可。

1）日誌分析的內容

一般分析日誌會分析以下內容

總交互次數、交互完成總量、未識別意圖量及佔比、識別錯誤意圖量及佔比、無效意圖及佔比

問答意圖總量及佔比、對話意圖總量及佔比、對話意圖與問答意圖在總量中的佔比

高頻問答意圖及佔比、高頻對話意圖及佔比、對話場景完成量及佔比。

2）調整機器人

分析結束後，會根據得到的具體的結果對機器人的意圖和知識進行調整和優化。

需要注意的問題

未識別問題很多的情況，有幾種可能

①用戶說的話，在知識庫中不存在相似的問法，所以只要添加即可。

②用戶說的話，在知識庫中有類似的問法，那麼就需要人工去排查是否是其它知識造成的錯誤，還是技術原因等等......

Ⅸ 智能客服系統架構是怎麼樣的呢

請點擊輸入圖片

AI+智能客服體系中，並不是真正意義上完全取代傳統客服，而是將人工智慧賦能在客服領域上，體系中增設智能源嘩在線服務機器人，通過智能知識學習與大數據提供智能坐席知識庫、智能人機協作等舉措，打造智能客服體系。在實用性上，毫無疑問鄭裂棚夠擊中企業優化服務過喊則程中的痛點：一方面，針對高頻次、高重復率的提問和海量客戶，高性能的智能客服機器人能夠提高工作效率，極大地降低人工成本。另一方面，如何為客戶輸出全面的高質量服務，更好地提升用戶在消費升級當中的體驗？智能客服似乎更能滿足當下消費者們對於客戶服務的移動性、即時性和社交性以及多渠道化的需求。

一個優秀的智能客服機器人，要在長期的交互過程中不斷學習和自我完善，達成對接收到的語句進行更精準的語義分析，能夠通過上下文關聯、場景管理、個性化推理等過程對自然語言進行准確理解，同時更需要積累龐大的知識庫，特別是在相關專業知識方面進行長期學習。而幾度經歷轉型和挑戰的小i機器人，在智能客服這一領域，終於擁有了更大的話語權。