得物客服機器人多輪SOP流程引擎技術實踐

1.業務背景

在得物客服機器人自研早期，傳統一問一答式的FAQ解決方案粒度較粗，在實際的業務場景中，越來越難以滿足用戶的諮詢需求，也沒有差異化的流程解決方案精準的引導使用者解決問題，大量使用者的諮詢仍依賴人工客服解決問題。早期的多輪SOP引擎主要依賴三方平台，三方反應速度比較慢，提供的服務可客製化的能力不足，在流程配置上，效率也比較低。隨著業務的快速發展，提高機器人在複雜場景下的解決能力，降低人工客服的成本，提供靈活的可視化多輪SOP流程配置後台，是非常必要的，至此開啟了自研多輪SOP流程引擎的里程。

2.多輪簡介

在了解業務背景之後，可能很多人對客服場景中的多輪不太了解，這裡結合實際的人機對話來介紹下機器人是如何基於多輪解決用戶問題的。

從上面可以看出，使用者諮詢的過程按照問答的流程一步一步走完，期間並沒有人工客服的介入，在多輪的會話中，客服機器人解決了用戶的問題。那這裡可能會有個疑問，機器人是怎麼知道該問什麼該答什麼的？語意辨識or演算法識別，其實都不是，在配置後台有對應的可視化搭建頁面來配置多輪的流程。

3.前期研究

在明確需求之後，透過什麼樣的技術能力建構機器人多輪SOP流程，是從0到1去實現還是基於開源的框架去實現是當時面臨的主要的選擇問題。從0到1去實現當然是最好的，也是很多技術同學挑戰自我的機會，不過當時面臨的主要問題是流程的搭建涉及Canvas畫布以及圖形編輯，這塊如果沒有專業知識的背景，難度相對會比較大，再加上當時業務的快速發展，亟需自研的多輪產品來做客製化的能力，所以當時選擇了基於開源的框架去實現。在開源框架的研究上，也參考了比較多流程配置的實現，具體如下：

• X-Flowchart-Vue：一個基於vue的流程圖編輯框架，能實現流程圖的搭建，但是沒法滿足業務場景中的自訂節點樣式；
• vue-flowchart-editor：一個基於vue的流程圖編輯框架，提供了幾種節點樣式和簡單的資料配置能力，對於自訂節點需要基於原始碼二次開發；
• Activity：一個比較完整的工作流程解決方案，是整合了前端、後端以及資料模型的一整套的流程引擎，如果使用的話，不僅前端這邊要做二次開發，後端那邊也得部署對應的服務或者對其二次設計和開發，成本比較高，並且Activity使用的前端技術棧比較老舊，在我們現有的系統裡面比較難以集成，所以在目前的業務場景下並不合適；
• Flowable：一個業務流程引擎，開發語言主是Java，如果使用的話，後端需要部署一整套流程引擎服務，前端這邊主要配合修改，成本也比較大，在目前的業務場景下並不合適；
• X6：是AntV 旗下的圖編輯引擎，提供了一系列開箱即用的互動元件和簡單易用的節點客製化能力，方便快速搭建流程圖等圖應用。

每個框架都有自己的優缺點，最後選擇了基於antv-x6圖編輯引擎做二次開發，其主要原因如下：

• 螞蟻的開源資料產品，社群比較活躍；
• 跟技術堆疊無關，可擴展性很好；
• #支援自訂節點，可客製化能力很高；
• 工具元件比較完備，能夠開箱即用

4.技術架構

明確了技術選型之後，接下來就是具體的技術實現了。多輪SOP流程引擎不僅需要前端這塊的設計實現，也離不開後端的設計實現，整體的架構設計如下圖所示：

4.1 前端配置層

前端配置層主要包括多輪SOP視覺化流程建置、上線管理、版本管理及介面管理四個功能模組。

• 多輪SOP視覺化搭建：包含各業務節點的拖曳作業與資料配置，透過不同業務節點的關聯關係產生完整的流程配置；
• 上下線管理：對於搭建好的多輪SOP流程需要做上線和下線的操作，當線上多輪流程出現問題的時候，需要及時下線；
• 版本管理：配置完的多輪SOP流程剛發布的時候，流程節點的回復話術或功能都比較基礎，需要透過線上使用者的流程資料不斷的完善流程能力，每次的變更都需要升級版本，確保線上穩定版本的同時，能對多輪SOP流程不斷的進行調優；
• 介面管理：流程裡面涉及的各業務節點依賴不同業務域的服務，例如訂單需要依賴交易介面、物流需要依賴供應連結口等，在業務流程配置裡面涉及到這類功能，就需要透過介面配置的方式去實現。

4.2 後端服務層

後端服務層核心部分是在流程執行引擎模組，在實際應用場景中，會根據使用者輸入的問題來配對最適合的流程以解決使用者的問題。在執行符合的流程的過程中，執行引擎會先建立流程的上下文，這裡會從redis快取裡面載入上下文信息，根據上下文中記錄的流程執行狀態，確定從哪個節點開始執行，執行完以後進行上下文資訊的更新。當流程執行結束的時候，再做上下文的銷毀操作。

4.3 應用層

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

5.技術挑戰

5.1 資料建模

透過資料建模解決節點與節點之間關聯關係的問題。

在多輪SOP流程視覺化搭建過程中，畫布節點的創建與連結是最複雜的，有些多輪場景的節點超過100個，節點之間的關係在畫布上的體現就非常重要。目前業務自訂的節點有4個類，如下：

#每個節點都有自己的業務屬性，這裡主要透過資料建模的想法把每個節點的業務屬性以及關聯關係屬性做了抽象，其想法如下：

X6提供的原始資料類型相對比較簡單，只有id、html、data、shape等這些基本屬性字段，在實際的業務場景中需要基於原始的屬性字段去做擴展，X6提供的data屬性就能很好的滿足自訂業務資料的需求。分析四類業務節點之後，每個業務節點可以抽象化通用的資料模型，其主要欄位的意義如下：

• nodeName：節點的名稱
• nodeType：節點的類型，這裡有四種節點類型：填槽節點、跳轉節點、回覆節點和判斷節點
• fromNodeId：來源節點的ID
• nextNodeId：指向節點的ID
• fromEdgeIdList：來源邊ID的清單
• nextEdgeIdList：指向邊ID的清單
• bizData：不同業務節點的業務屬性資訊

##這裡bizData作為業務節點的通用資料模型，用來存放不同業務節點屬性數據，例如填槽節點有slot和abnorma等業務屬性，回復節點有contentSort和content等業務屬性。透過業務節點的資料模型抽象，就可以表示不同節點之間的關聯關係，如下圖所示：

• 判斷節點可以透過nextEdgeIdList屬性關聯填槽節點和跳轉節點；
• 判斷節點可以透過fromNodeId屬性關聯轉人工回覆節點；
• 轉人工回覆節點可以透過nextNodeId關聯兜底回應節點；
• 兜底回應節點可以透過fromEdgeIdList關聯轉人工回應節點。

不同的節點關聯關係透過語意化屬性表示之後，再基於X6提供的addNode/addEdge方法實現節點和邊的連接，這樣無論畫布中有多少個節點，節點之間的關聯關係都非常的明確。

5.2 RXJS

透過RXJS事件訂閱和單向資料流解決不同功能模組資料流向的問題

在多輪SOP可視化搭建後台，有三個不同的功能區：工具列、畫布區和資料配置區，每個區域的操作都會涉及到節點資料的變更，如果沒有明確的資料流，將會導致資料變更混亂，保存的時候潛在資料錯亂的風險。這裡我們採用了RXJS事件訂閱以及單向資料流的設計模式，具體實作如下圖所示：

• 操作列的節點操作會觸發事件，例如刪除節點操作；
• 在畫布區選取需要刪除的節點，觸發節點資料刪除事件；
• 資料表單配置區接收節點資料刪除事件的數據，刪除對應的節點資料並同步到資料記憶體快取；
• 最後提交流程的時候，將記憶體中的資料傳給服務端資料庫。

整個過程，從節點資料流向表單資料再流向快取數據，整個流向是單向的，不管在哪個模組觸發最終的流向都是資料記憶體快取。

對於資料流，目前有許多開源的框架可以使用，像是redux、vuex、dva等等，這裡為什麼要採用RXJS？主要是因為RXJS比較輕量，同時跟技術棧無關，後續可擴展性更好。

5.3 流程編排

透過流程編排技術解決複雜多輪流程搭建的問題

截止到上半年，線上的多輪已經將近200個，有些複雜的流程包含100多個節點，對於100多個節點的複雜流程如果是一個節點一個節點去配置的話，那配置效率是極度低的，那我們是怎麼實現複雜流程快速搭建的呢？這裡用到了流程編排技術。

流程編排是指透過拖曳視覺化業務元件來編排業務流程，然後由流程引擎來執行這個流程。其標準化的協議是BPMN協議，BPMN協議包含了流程編排裡面的各種圖標、元件的含義和使用規範。在實際的應用情境中，我們並沒有完全使用BPMN協議，而是遵循了BPMN協議，做了自訂的元件元件。對於複雜的流程，我們透過不同的子流程進行編排，其想法如下：

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

從上圖可以清楚的看到，取消訂單多輪流程包含了判斷使用者身分子流程、判斷使用者訴求子流程、取消訂單子流程這三個子流程，其中每個子流程又是一個獨立完整的流程。這樣透過三個子流程的編排，就可以建構出取消訂單複雜的多輪流程。

以上三點是在自研過程中遇到的主要的技術挑戰，其實在做的過程中，還有很多的難點，比如上百個節點如何做到渲染秒開、複雜的邏輯（複製、剪下）如何編排、複雜的判斷節點如何做到一鍵展開與折疊等等，這裡就不一一闡述了。

6.業務成效

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

7.總結

客服機器人多輪SOP流程引擎從立項到發布，整個週期差不多一個月左右的時間，從無到有的過程，是各投入方一起努力的結果。目前多輪流程引擎除了服務上述兩個場景之外，也在工單業務、質檢業務探索使用場景，同時也在持續豐富坐席輔助場景，為一線客服提供標準化的服務流程，提升一線客服的解決率。在功能上，我們也會持續完善流程引擎的能力，支援更多業務場景的使用，將流程引擎的能力不斷完善，打造成為業界的標竿。

以上是得物客服機器人多輪SOP流程引擎技術實踐的詳細內容。更多資訊請關注PHP中文網其他相關文章！