1.業(yè)務(wù)背景

在得物客服機(jī)器人自研早期，傳統(tǒng)一問一答式的FAQ解決方案粒度較粗，在實(shí)際的業(yè)務(wù)場景中，越來越難以滿足用戶的咨詢需求，也沒有差異化的流程解決方案精準(zhǔn)的引導(dǎo)用戶解決問題，大量用戶的咨詢依然依賴人工客服解決問題。早期的多輪SOP引擎主要依賴于三方平臺，三方響應(yīng)速度比較慢，提供的服務(wù)可定制化的能力不足，在流程配置上，效率也比較低。隨著業(yè)務(wù)的快速發(fā)展，提高機(jī)器人在復(fù)雜場景下的解決能力，降低人工客服的成本，提供靈活的可視化多輪SOP流程配置后臺，是非常有必要的，至此開啟了自研多輪SOP流程引擎的里程。

2.多輪簡介

在了解業(yè)務(wù)背景之后，可能很多人對客服場景中的多輪不太了解，這里結(jié)合實(shí)際的人機(jī)對話來介紹下機(jī)器人是如何基于多輪解決用戶問題的。

從上面可以看出，用戶咨詢的過程按照問答的流程一步一步走完，期間并沒有人工客服的介入，在多輪的會話中，客服機(jī)器人解決了用戶的問題。那這里可能會有個(gè)疑問，機(jī)器人是怎么知道該問什么該答什么的？語義識別or算法識別，其實(shí)都不是，在配置后臺有對應(yīng)的可視化搭建頁面來配置多輪的流程。

3.前期調(diào)研

在明確需求之后，通過什么樣的技術(shù)能力搭建機(jī)器人多輪SOP流程，是從0到1去實(shí)現(xiàn)還是基于開源的框架去實(shí)現(xiàn)是當(dāng)時(shí)面臨的主要的選擇問題。從0到1去實(shí)現(xiàn)當(dāng)然是最好的，也是很多技術(shù)同學(xué)挑戰(zhàn)自我的機(jī)會，不過當(dāng)時(shí)面臨的主要問題是流程的搭建涉及Canvas畫布以及圖形編輯，這塊如果沒有專業(yè)知識的背景，難度相對會比較大，再加上當(dāng)時(shí)業(yè)務(wù)的快速發(fā)展，亟需自研的多輪產(chǎn)品來做定制化的能力，所以當(dāng)時(shí)選擇了基于開源的框架去實(shí)現(xiàn)。在對開源框架的調(diào)研上，也參考了比較多流程配置的實(shí)現(xiàn)，具體如下：

• X-Flowchart-Vue：一個(gè)基于vue的流程圖編輯框架，能實(shí)現(xiàn)流程圖的搭建，但是沒法滿足業(yè)務(wù)場景中的自定義節(jié)點(diǎn)樣式；
• vue-flowchart-editor：一個(gè)基于vue的流程圖編輯框架，提供了幾種節(jié)點(diǎn)樣式和簡單的數(shù)據(jù)配置能力，對于自定義節(jié)點(diǎn)需要基于源碼二次開發(fā)；
• Activity：一個(gè)比較完整的工作流程解決方案，是集成了前端、后端以及數(shù)據(jù)模型的一整套的流程引擎，如果使用的話，不僅前端這邊要做二次開發(fā)，后端那邊也得部署對應(yīng)的服務(wù)或者對其二次設(shè)計(jì)和開發(fā)，成本比較高，并且Activity使用的前端技術(shù)棧比較老舊，在我們現(xiàn)有的系統(tǒng)里面比較難以集成，所以在當(dāng)前的業(yè)務(wù)場景下并不合適；
• Flowable：一個(gè)業(yè)務(wù)流程引擎，開發(fā)語言主是Java，如果用的話，后端需要部署一整套流程引擎服務(wù)，前端這邊主要配合修改，成本也比較大，在當(dāng)前的業(yè)務(wù)場景下并不合適；
• X6：是 AntV 旗下的圖編輯引擎，提供了一系列開箱即用的交互組件和簡單易用的節(jié)點(diǎn)定制能力，方便快速搭建流程圖等圖應(yīng)用。

每個(gè)框架都有自己的優(yōu)缺點(diǎn)，最后選擇了基于antv-x6圖編輯引擎做二次開發(fā)，其主要原因如下：

• 螞蟻的開源數(shù)據(jù)產(chǎn)品，社區(qū)比較活躍；
• 跟技術(shù)棧無關(guān)，可擴(kuò)展性很好；
• 支持自定義節(jié)點(diǎn)，可定制化能力很高；
• 工具組件比較完備，能夠開箱即用

4.技術(shù)架構(gòu)

明確了技術(shù)選型之后，接下來就是具體的技術(shù)實(shí)現(xiàn)了。多輪SOP流程引擎不僅需要前端這塊的設(shè)計(jì)實(shí)現(xiàn)，也離不開后端的設(shè)計(jì)實(shí)現(xiàn)，整體的架構(gòu)設(shè)計(jì)如下圖所示：

4.1 前端配置層

前端配置層主要包括多輪SOP可視化流程搭建、上下線管理、版本管理和接口管理四個(gè)功能模塊。

• 多輪SOP可視化搭建：包含各業(yè)務(wù)節(jié)點(diǎn)的拖拽操作和數(shù)據(jù)配置，通過不同業(yè)務(wù)節(jié)點(diǎn)的關(guān)聯(lián)關(guān)系生成完整的流程配置；
• 上下線管理：對于搭建好的多輪SOP流程需要做上線和下線的操作，當(dāng)線上多輪流程出現(xiàn)問題的時(shí)候，需要及時(shí)下線；
• 版本管理：配置完的多輪SOP流程剛發(fā)布的時(shí)候，流程節(jié)點(diǎn)的回復(fù)話術(shù)或者功能都比較基礎(chǔ)，需要通過線上用戶的流程數(shù)據(jù)不斷的完善流程能力，每次的變更都需要升級版本，確保線上穩(wěn)定版本的同時(shí)，能對多輪SOP流程不斷的進(jìn)行調(diào)優(yōu)；
• 接口管理：流程里面涉及的各業(yè)務(wù)節(jié)點(diǎn)依賴不同業(yè)務(wù)域的服務(wù)，比如訂單需要依賴交易接口、物流需要依賴供應(yīng)鏈接口等，在業(yè)務(wù)流程配置里面涉及到這類功能，就需要通過接口配置的方式去實(shí)現(xiàn)。

4.2 后端服務(wù)層

后端服務(wù)層核心部分是在流程執(zhí)行引擎模塊，在實(shí)際應(yīng)用場景中，會根據(jù)用戶輸入的問題來匹配最合適的流程以解決用戶的問題。在執(zhí)行匹配到的流程的過程中，執(zhí)行引擎會先創(chuàng)建流程的上下文，這里會從redis緩存里面加載上下文信息，根據(jù)上下文中記錄的流程執(zhí)行狀態(tài)，確定從哪個(gè)節(jié)點(diǎn)開始執(zhí)行，執(zhí)行完以后進(jìn)行上下文信息的更新。當(dāng)流程執(zhí)行結(jié)束的時(shí)候，再做上下文的銷毀操作。

4.3 應(yīng)用層

應(yīng)用層主要是多輪SOP流程具體的使用場景，目前主要包括得物客服機(jī)器人和坐席輔助SOP兩個(gè)使用場景。

5.技術(shù)挑戰(zhàn)

5.1 數(shù)據(jù)建模

通過數(shù)據(jù)建模解決節(jié)點(diǎn)與節(jié)點(diǎn)之間關(guān)聯(lián)關(guān)系的問題。

在多輪SOP流程可視化搭建過程中，畫布節(jié)點(diǎn)的創(chuàng)建和連接是最復(fù)雜的，有些多輪場景的節(jié)點(diǎn)超過100個(gè)，節(jié)點(diǎn)之間的關(guān)系在畫布上的體現(xiàn)就非常重要。目前業(yè)務(wù)自定義的節(jié)點(diǎn)有4類，如下：

每個(gè)節(jié)點(diǎn)都有自己的業(yè)務(wù)屬性，這里主要通過數(shù)據(jù)建模的思想把每個(gè)節(jié)點(diǎn)的業(yè)務(wù)屬性以及關(guān)聯(lián)關(guān)系屬性做了抽象，其思路如下：

X6提供的原始數(shù)據(jù)類型相對比較簡單，只有id、html、data、shape等這些基本屬性字段，在實(shí)際的業(yè)務(wù)場景中需要基于原始的屬性字段去做擴(kuò)展，X6提供的data屬性就能很好的滿足自定義業(yè)務(wù)數(shù)據(jù)的需求。分析四類業(yè)務(wù)節(jié)點(diǎn)之后，每個(gè)業(yè)務(wù)節(jié)點(diǎn)可以抽象通用的數(shù)據(jù)模型，其主要字段的含義如下：

• nodeName：節(jié)點(diǎn)的名稱
• nodeType：節(jié)點(diǎn)的類型，這里有四種節(jié)點(diǎn)類型：填槽節(jié)點(diǎn)、跳轉(zhuǎn)節(jié)點(diǎn)、回復(fù)節(jié)點(diǎn)和判斷節(jié)點(diǎn)
• fromNodeId：來源節(jié)點(diǎn)的ID
• nextNodeId：指向節(jié)點(diǎn)的ID
• fromEdgeIdList：來源邊ID的列表
• nextEdgeIdList：指向邊ID的列表
• bizData：不同業(yè)務(wù)節(jié)點(diǎn)的業(yè)務(wù)屬性信息

這里bizData作為業(yè)務(wù)節(jié)點(diǎn)的通用數(shù)據(jù)模型，用于存放不同業(yè)務(wù)節(jié)點(diǎn)屬性數(shù)據(jù)，比如填槽節(jié)點(diǎn)有slot和abnorma等業(yè)務(wù)屬性，回復(fù)節(jié)點(diǎn)有contentSort和content等業(yè)務(wù)屬性。通過對業(yè)務(wù)節(jié)點(diǎn)的數(shù)據(jù)模型抽象，就可以表示不同節(jié)點(diǎn)之間的關(guān)聯(lián)關(guān)系，如下圖所示：

• 判斷節(jié)點(diǎn)可以通過nextEdgeIdList屬性關(guān)聯(lián)填槽節(jié)點(diǎn)和跳轉(zhuǎn)節(jié)點(diǎn)；
• 判斷節(jié)點(diǎn)可以通過fromNodeId屬性關(guān)聯(lián)轉(zhuǎn)人工回復(fù)節(jié)點(diǎn)；
• 轉(zhuǎn)人工回復(fù)節(jié)點(diǎn)可以通過nextNodeId關(guān)聯(lián)兜底回復(fù)節(jié)點(diǎn)；
• 兜底回復(fù)節(jié)點(diǎn)可以通過fromEdgeIdList關(guān)聯(lián)轉(zhuǎn)人工回復(fù)節(jié)點(diǎn)。

不同的節(jié)點(diǎn)關(guān)聯(lián)關(guān)系通過語義化屬性表示之后，再基于X6提供的addNode/addEdge方法實(shí)現(xiàn)節(jié)點(diǎn)和邊的連接，這樣無論畫布中有多少個(gè)節(jié)點(diǎn)，節(jié)點(diǎn)之間的關(guān)聯(lián)關(guān)系都非常的清晰。

5.2 RXJS

通過RXJS事件訂閱和單向數(shù)據(jù)流解決不同功能模塊數(shù)據(jù)流向的問題

在多輪SOP可視化搭建后臺，有三個(gè)不同的功能區(qū)：工具欄、畫布區(qū)和數(shù)據(jù)配置區(qū)，每個(gè)區(qū)域的操作都會涉及到節(jié)點(diǎn)數(shù)據(jù)的變更，如果沒有清晰的數(shù)據(jù)流，將會導(dǎo)致數(shù)據(jù)變更混亂，保存的時(shí)候潛在數(shù)據(jù)錯(cuò)亂的風(fēng)險(xiǎn)。這里我們采用了RXJS事件訂閱以及單向數(shù)據(jù)流的設(shè)計(jì)模式，具體實(shí)現(xiàn)如下圖所示：

• 操作欄的節(jié)點(diǎn)操作會觸發(fā)事件，比如刪除節(jié)點(diǎn)操作；
• 在畫布區(qū)選中需要?jiǎng)h除的節(jié)點(diǎn)，觸發(fā)節(jié)點(diǎn)數(shù)據(jù)刪除事件；
• 數(shù)據(jù)表單配置區(qū)接收節(jié)點(diǎn)數(shù)據(jù)刪除事件的數(shù)據(jù)，刪除對應(yīng)的節(jié)點(diǎn)數(shù)據(jù)并同步到數(shù)據(jù)內(nèi)存緩存；
• 最后提交流程的時(shí)候，將內(nèi)存中的數(shù)據(jù)傳給服務(wù)端數(shù)據(jù)庫。

整個(gè)過程，從節(jié)點(diǎn)數(shù)據(jù)流向表單數(shù)據(jù)再流向緩存數(shù)據(jù)，整個(gè)流向是單向的，不管在哪個(gè)模塊觸發(fā)最終的流向都是數(shù)據(jù)內(nèi)存緩存。

對于數(shù)據(jù)流，目前有很多開源的框架可以使用，比如redux、vuex、dva等等，這里為什么采用RXJS？主要是因?yàn)镽XJS比較輕量，同時(shí)跟技術(shù)棧無關(guān)，后續(xù)可擴(kuò)展性更好。

5.3 流程編排

通過流程編排技術(shù)解決復(fù)雜多輪流程搭建的問題

截止到上半年，線上的多輪已經(jīng)將近200個(gè)，有些復(fù)雜的流程包含100多個(gè)節(jié)點(diǎn)，對于100多個(gè)節(jié)點(diǎn)的復(fù)雜流程如果是一個(gè)節(jié)點(diǎn)一個(gè)節(jié)點(diǎn)去配置的話，那配置效率是極其低下的，那我們是怎么實(shí)現(xiàn)復(fù)雜流程快速搭建的呢？這里用到了流程編排技術(shù)。

流程編排是指通過拖拽可視化業(yè)務(wù)組件來編排業(yè)務(wù)流程，然后由流程引擎來執(zhí)行這個(gè)流程。其標(biāo)準(zhǔn)化的協(xié)議是BPMN協(xié)議，BPMN協(xié)議包含了流程編排里面的各種圖標(biāo)、元件的含義和使用規(guī)范。在實(shí)際的應(yīng)用場景中，我們并沒有完全使用BPMN協(xié)議，而是遵循了BPMN協(xié)議，做了自定義的元件組件。對于復(fù)雜的流程，我們通過不同的子流程進(jìn)行編排，其思路如下：

這里通過取消訂單多輪流程舉例，其流程拆分如下：

從上圖可以清楚的看到，取消訂單多輪流程包含了判斷用戶身份子流程、判斷用戶訴求子流程、取消訂單子流程這三個(gè)子流程，其中每個(gè)子流程又是一個(gè)獨(dú)立完整的流程。這樣通過三個(gè)子流程的編排，就可以搭建取消訂單復(fù)雜的多輪流程。

以上三點(diǎn)是在自研過程中遇到的主要的技術(shù)挑戰(zhàn)，其實(shí)在做的過程中，還有很多的難點(diǎn)，比如上百個(gè)節(jié)點(diǎn)如何做到渲染秒開、復(fù)雜的邏輯（復(fù)制、剪切）如何編排、復(fù)雜的判斷節(jié)點(diǎn)如何做到一鍵展開和折疊等等，這里就不一一闡述了。

6.業(yè)務(wù)成效

客服多輪SOP流程引擎的自研，完全取代了三方服務(wù)，不僅節(jié)省了每年至少幾十萬的外采服務(wù)成本，并且在業(yè)務(wù)上取得了不錯(cuò)的成效，做到了靈活定制，快速支撐業(yè)務(wù)的發(fā)展。自上線之后，主要覆蓋得物客服機(jī)器人和坐席輔助機(jī)器人兩個(gè)業(yè)務(wù)場景，其中得物機(jī)器人多輪SOP流程有上百個(gè)，坐席輔助機(jī)器人多輪SOP流程有幾十個(gè)，在很大程度上提升了客服的解決率，減少了轉(zhuǎn)人工成本。上線之后，以今年其中一個(gè)月份的數(shù)據(jù)為例，客服機(jī)器人的解決率有比較明顯的提升，其中SOP的解決率相對于FAQ的解決率提升了15%多，SOP接待數(shù)是FAQ接待數(shù)的2倍多，在很大程度上節(jié)省了轉(zhuǎn)人工成本。

7.總結(jié)

客服機(jī)器人多輪SOP流程引擎從立項(xiàng)到發(fā)布，整個(gè)周期差不多一個(gè)月左右的時(shí)間，從無到有的過程，是各投入方一起努力的結(jié)果。目前多輪流程引擎除了服務(wù)于上述兩個(gè)場景之外，也在工單業(yè)務(wù)、質(zhì)檢業(yè)務(wù)探索使用場景，同時(shí)也在持續(xù)豐富坐席輔助場景，為一線客服提供標(biāo)準(zhǔn)化的服務(wù)流程，提升一線客服的解決率。在功能上，我們也會持續(xù)完善流程引擎的能力，支持更多業(yè)務(wù)場景的使用，將流程引擎的能力不斷完善，打造成為業(yè)界的標(biāo)桿。