基于多機器人協調的客戶服務系統

沈云輝，賴燕梅，何 娟

（1.廣東工業大學機電工程學院，廣州 510000；2.首都師范大學文學院北京100089；3.中山大學管理學院，廣州 510000）

0 引言

云是一個資源池，它包含大量虛擬資源(硬件、開發平臺和I/O服務)，用戶可以對這些資源進行配置。這個資源池的調用通常基于準時、收費模式管理，它最顯著的特性是軟件即服務(SaaS)[1]。本文中機器人采用“機器人+云計算”模式，機器人的操作系統和數據庫部署在云端，它可以調用API來實現語音識別、人臉識別和語義識別。機器人的發展日新月異，人類不僅希望單個機器人能夠獨立完成高復雜度的任務，也希望機器人能夠合作完成任務。多機器人協調在智能農業、搜救、運輸等領域得到了廣泛地應用[2]。此外，云機器人和自動化研究[3]為多機器人協調在客戶服務中的應用提供了現實的可能性。

本文將重點關注商業客戶服務，重點介紹多機器人協作對客戶服務的貢獻。在商業交易過程中，商場服務機器人充當購物助手，這些機器人可以利用云服務技術實現信息的共享。機器人還可以收集顧客的信息，判斷他們對商品的喜好，然后給顧客及時有效的建議。該技術將有助于為客戶提供個性化服務。同時，多機器人協作的應用也為傳統商店的轉型以及傳統商店的體驗與電子商務功能相結合提供了一些可能性[4]。

機器人的協同通常分為合作協同和競爭協同。合作協同是建立在分工的基礎上的，通過對任務的分工，將群體機器人分為若干個子群。根據協同方式進一步細化為合作協作和競爭協同[5]。競爭協同則是通過允許多個機器人擁有同一個任務或目標，建立承包機制。

隨著近年許多研究者將研究重點轉移到如何使多機器人更好地進行協調的研究上，多機器人系統和多移動機器人系統(MRSs)的研究在規模和重要性上都有很大的提高[6]。而當許多機器人一起工作，通信往往受到網絡的限制，杰弗里·霍林格[7]和桑吉夫·辛格證明即時協調的滾動規劃可以包含周期性約束，從而使與需要連續連接的算法相比有了顯著的改進，并為機器人提供一個實現更好地實時信息交換的基礎。近年來，在機器人的發展中，關于機器人的協同控制實驗，曹永康等[8]人通過結合理論在多輪式移動機器人平臺上進行應用分布式協作控制策略，探索分布式共識算法的有效性，同時避免了集中式協同控制方案易受通信范圍和帶寬限制以及對團隊領導或集中站的干擾，不能擴展到團隊中的所有機器人的弊端[8]。在最新的研究中，關于如何將多機器人彼此協同共識控制問題上，傅勤等[9]將Lyapunov泛函方法應用于具有分布參數模型的多智能體系統，并在適當的Sobole空間上解決這種多智能體系統的共識控制問題，進一步為機器人的協同工作方向打下基礎。

本文所涉及的客戶服務是人工智能客戶服務。人工智能客戶服務是指機器人通過語音與客戶進行溝通，記住客戶的記錄，通過語義分析了解用戶的意圖，與用戶進行友好的溝通，為客戶提供必要的客戶信息和其他相關服務所需的信息。人工智能客服是針對客戶需求的創新服務。

1 系統架構

基于多機器人協作方法的客戶服務系統框架如圖1所示。包括組織層、客戶端層、應用層、公有云服務層和私有云服務層、場景分類層和交互信息共享層。

圖1 多機器人協同系統結構圖

組織層包括企業、商店和酒店，以及為公眾提供服務的醫院和政府機構。客戶端層是組織層的客戶。應用場景分類層的功能是通過客戶端與機器人之間的對話記錄來區分對話場景。組織(機器人所有者)可以根據所屬行業為機器人選擇場景。例如，商店選擇的交互場景是購物，酒店選擇的交互場景是酒店。當對話場景確定后，機器人的交互狀態將切換到相應的場景狀態模式，提高語義識別程度，優化交互體驗。應用層主要描述了那些機器人的協同方法。考慮到場景的分類，機器人會根據場景的知識庫與客戶進行溝通。機器人通過與其他機器人共享云數據庫，保存客戶的信息，包括客戶的人臉或聲紋，以及每次與客戶交互的交互狀態。例如，如果一個人與機器人A進行了交流，然后這個人遇到了機器人B。當機器人B在另一個地方識別到這個人的人臉或者聲音信息時，機器人B會首先識別出這個人。機器人B會下載他與機器人A通信時生成的數據。在分析他和其他機器人的交互信息的基礎上與他展開對話。

為了清晰描述數據在機器人之間的傳遞和狀態的繼承，本文提出的框架數據流程如圖2所示。圖中，顧客A分別與2個不同的機器人交流如何到達酒店。客戶A首先與機器人B溝通。機器人B收到客戶的問題，通過步驟B1和B2得到答案。最后，機器人B給出了客戶A的答案，同時通過步驟D1和D2保存客戶的口語對話狀態和數據。一段時間后，客戶A遇到了機器人C，機器人C獲得機器人B的口語對話狀態以及在識別到客戶A身份ID后從云服務獲得客戶數據。機器人C立即知道客戶要去酒店，即使客戶沒有告訴機器人C去酒店，機器人C會直接告訴客戶怎么去酒店。這樣縮短了客戶端A獲取目標信息的交互時間。交互信息共享機制是一種機器人與商家之間管理信息的一種機制。特別地，他為每個組織(商家)提供1個帳戶和密碼來管理他們的數據。組織(商家)可以直接管理他們的信息是公開的還是只對他們自己開放。同時，為了保證客戶信息的安全和隱私，未經客戶允許，客戶的信息不會被保存。當機器人保存客戶的面部數據時，他會嘗試獲得客戶的許可，然后保存數據。公共云服務層一般是指Microsoft Azure、Amazon Web services等云服務，均包括很多API。通過調用這些API來獲取人臉識別、語音識別等其它功能。云機器人不僅可以降低成本，還可以優化資源分配。私有云服務是存儲和管理商家和客戶的信息，通過機器人合作系統的配合為客戶提供個性化的服務。當用戶與機器人交互時，獲得用戶的許可后，將信息保存到云端，包括用戶的身份ID、聊天記錄、購物信息、位置等。同時，如果商家需要，還可以將商店中出售的商品、折扣促銷信息、組織位置等信息保存在私有云中。在與客戶溝通時，機器人可以根據客戶的歷史購買記錄推薦相關產品或配件產品。如果機器人屬于同一個商業圈(聯盟)，他們可以提出互補或相關的產品建議。

圖2 多機器人協同框架工作流程圖

2 對話狀態跟蹤器

多機器人協作是一項應用于機器人路徑規劃、搜索等其他領域的成熟技術。本文展示了多機器人協作在服務機器人中的應用。正如語音交互機器人是基于云服務的，也是云機器人的一種。他們的系統和數據庫是共享的，因此機器人協作是會話狀態的連接和繼承。可以使用對話狀態跟蹤技術。早期口語對話系統使用提前制定的規則[10]，這種技術的優點是，它不依賴于大量的數據來實現，只提供規則就可以不斷改善，但它依賴于大量的人力且應用范圍是非常狹窄的。隨后，在對話狀態跟蹤中使用生成模型[11]，通過對收集到的對話行為和潛在意圖進行統計分析，可以得到上下文。與生成模型不同，對話狀態跟蹤的判別模型通過時間遞歸神經網絡（RNN）中的長短期記憶(LSTM)選擇性地保留交互語料庫，提高了識別的準確性[12]。

首先，對固定場景建立特殊的場景模型。場景模型包含場景的獨有特征，這些特征設置成像插槽一樣。例如，機票購買的場景模型:對話狀態列出并編碼購票時間、購票號碼、購票數量、購票地點，當客戶查詢購票信息時，機器人通過自動語音識別(ASR)識別購票信息，然后通過使用自然語言工具包(NLTK)(一種自然語言預處理方案)進行預處理生成的文本。機器人會根據設定的條件積極引導交互的詢問問題，像插槽一樣去填充場景模型所需的信息。因為機器人使用云操作系統，當客戶端I與機器人A通信并離開時，交互不會消失，而是掛起(保存)并綁定到客戶的ID。所以當客戶I再次和機器人對話時，即使不是機器人A，假設是機器人B，那么機器人B就可以讀取上次客戶I和機器人A的數據并繼續對話。

3 個性化數據庫架構

本文提出的框架涉及到私有云中的許多不同信息，包括來自組織者例如商場、酒店、銀行等和用戶的信息。在隱私安全越來越受到重視的時代，如何做好個性化服務和信息安全是一個巨大的考驗。本文所述的系統將根據對應用戶的信息分別管理和存儲在每個組織者知識庫中，每個組織都有自己唯一的賬號和密碼管理，與此同時，系統都有自己的客戶(組織者)操作終端，移動電話應用操作終端，可以隨時上傳和更新數據。這個知識庫的架構如圖3所示。圖中，以酒店及商場的個性化知識構建為例，有3種方法可以為數據源構建知識庫。第1種方式是組織者使用終端(APP、Web)編輯和上傳私有數據；第2種方法是從公有云服務導入通用數據。這2種方法可以準確的添加大量的數據，但是也有不足之處。第1種缺乏效率，第2種缺乏時效性。第3種是收集大量機器人和客戶的交互數據，包括分詞后詞向量表達和詞性標注，然后利用深度神經網絡(DNN)對數據進行訓練和處理，最后將分析結果上傳到云端。知識庫中存儲的數據主要基于服務數據，商戶的信息是否可以被其他商戶訪問由信息提供者決定，從而保證商戶信息隱私，提高客戶服務水平。

圖3 構建知識庫的工作流程

4 結束語

本文提出了一種基于多機器人協作方式的個性化客戶服務系統，該系統有效地管理和使用了機器人信息、組織信息和客戶信息，同時保護了客戶和企業信息的隱私。在為客戶提供個性化服務和個性化推薦的同時，也為企業節約了人力資源成本。同時，個性化知識庫添加數據的方式有3種，為組織開展大數據分析提供有針對性的、實時的高數據源，為了解客戶和升級服務奠定了基礎。對話狀態跟蹤技術將機器人協作的方法應用于語音交互服務領域，使客戶體驗到不間斷的交互環境。這種互動將完全與最后的互動相聯系，在一定程度上消除了顧客與機器人之間機械的和不協調的互動感。雖然機器人的語音識別正確率仍然不高，而且只是暫時支持在會場等嘈雜場所進行單人對話。在未來，我們將嘗試設計機器人與多個交互對象交互，這樣機器人就可以同時與一群人交互。