面向平臺的智慧客服系統之實踐演進之路

一直以來，面向運營使用的活動平臺，在運營使用過程中會偶發出現一些疑難問題，比如運營對某個元件功能的使用有疑問，或者線上的活動表現不符合預期，運營期望產研協助排查。面對這些場景，活動平臺維護了一個千人以上的產研運“救火群”，運營有問題會在群裡提問，當週研發值班會負責關注群裡的問題，並作出響應回答，同時為了瞭解每週問題情況，值班需要手動記錄每週問題excel。

雖然這種做法在很大程度上包攬解決了大部分的運營問題，但這種模式仍舊有一些問題：

1. 問題及解決方案得不到自動沉澱，如果想沉澱faq，依賴值班手動進行記錄，耗時耗力。

2. 問題解答要求值班同學對問題所涉領域有足夠了解，才能找到具體對接同學定位問題。

3. 群訊息內容繁雜，訊息有時容易吞沒，依賴值班同學“爬樓有道”。

可見，依賴人工干預和手動記錄，不僅耗費大量時間和人力，而且容易出錯和遺漏，基於此，一個可智慧對話、可針對性一鍵拉群、支援FAQ沉澱的智慧客服系統誕生了。本文就將帶你一起了解下面向平臺的智慧客服系統的落地實踐之心路歷程。

作為一個智慧客服系統，現在的我長這樣：

我主要包括以下幾部分構成：

1. 對話介面

2. 會話狀態機

3. 資料來源模型

4. 統計彙總後臺

5. 接入配置

• 對話介面

想要收集運營問題，提供給運營的對話介面不可少。經過對運營使用習慣調研，大部分運營更願意使用企微原生功能實現對話，而跳轉到第三方網頁或者在活動後臺開啟對話視窗的形式，運營都不願意接受，這也不難理解，畢竟企微是大家日常溝通的集散地。企微目前支援服務號/應用號兩種不同的可提供對話頁面的形式，由於受限於服務號的“無訊息回撥”，“人工座席與智慧服務不能共存”等問題，最終我們選擇了應用號作為人工客服的主要對話入口。

^{（對話介面）}

透過在應用號上繫結回撥介面的形式，我們可以將使用者在應用號上的所有操作（包括主動的對話訊息）都利用回撥介面進行接收，解密後對使用者的提問訊息進行理解及二次處理。特別想指出，在測試環境進行除錯時，遇到微信無法訪問UAT域名的問題，解決這個問題，我們架了一層代理，開啟callback-api服務介面，將外網請求直接轉發到uat環境域名上。並且在整個流程中都會帶有部門flag(小紅旗)，實現了不同部門間的流程和資料的隔離。

^{（訊息接收&解析）}

• 會話狀態機

後端維護了一整套會話管理體系，會話狀態由會話開啟、進行中(轉人工、未轉人工)、已結束組成，每次會話在運營嚮應用號發訊息時開啟，在聊天過程中，應用號與後端服務進行互動，透過不同型別的訊息事件，觸發開啟會話、自動收集會話資訊、會話識別、會話FAQ匹配、回覆使用者答案等流程，維護會話狀態，並對使用者一鍵拉群、結束會話等請求進行響應。同時，會話狀態機維護一個狀態的延時訊息佇列，在使用者長時間無響應時進行主動二次確認，並保留對會話自動關閉的機制。

^{（狀態流轉）}

其中在會話保持進行中的狀態時，使用者可以根據需要，進行一鍵轉人工服務，目前我們會維護活動平臺的值班資訊，在使用者請求轉人工後我們會一鍵拉群，拉齊提問使用者及本週研發和產品值班同學，在群裡對問題進行閉環解決。

• 資料來源模型

這裡所說的資料來源模型，主要是指在識別使用者訊息內容後，針對訊息內容，進行合理回覆的底層資料來源選型模型，目前本套智慧客服回覆支援兩種模型，一種是基於ES搜尋的，另一種是基於類似ChatGPT的專業領域學習模型，使用OpenAI API對使用者的問題進行向量分析並回答。

^{（智慧回答流程圖）}

基於ES搜尋的資料來源模型，我們採用Elasticsearch內建的分詞器(Tokenizer)和過濾器(Token Filter)對使用者問題進行拆分識別，並匹配FAQ庫中匹配度最高的答案，給予返回。

另一種基於自然語言處理和機器學習的問答處理模型，其特點就是問題回答更自然、更人性化，它可以對使用者問題進行預處理，對原始答案進行加工。但是其缺點在我們的智慧客服專案中也體現的比較明顯，在我們FAQ庫、對話資訊收集不足夠豐富的情況下，模型訓練的準確性並不高，甚至模型會有“自由發揮”空間，這對於我們聽話的運營來說實屬災難，可想，運營跟著智慧客服一頓操作，最後發現原來這都是智慧客服的YY時，大概運營心中會有一萬隻羊駝經過吧。

基於此，我們調整了模型思路，基於已有資訊進行相似度模型訓練，我們在這裡引入simbert模型，其最大的優勢在於在特定專業學習領域裡，準確率比其他模型都高，自然我們也不會放棄“ChatGPT”，只不過它更多的是在訓練資料足夠的情況下，對問題進行極限兜底。

同時，為了保證訓練資料的補給，我們也打通了一條離線資料補給流，對話介面收集到的FAQ及對話資訊會透過離線任務同步給訓練模型，讓訓練模型不斷“精進自我”，提高回答的準確率。

目前智慧客服支援兩種資料模型的開關控制，隨時隨地隨意切換。

• 統計彙總後臺

為了方便對所有會話資料進行管理、review、統計，我們提供了一套視覺化的管理後臺，這個後臺的特色有幾點：

一是lowcode，使用我司LEGO系統，在後端同學一頓拖拖拽拽，稍微改動後，一整套可克隆的後臺就生成了；

二是後臺系統提供了會話詳情檢視功能，方便對使用者問題進行review；

三是可以在後臺對每一條會話進行備註及狀態流轉；

四是可以對會話直接一鍵上傳FAQ，FAQ資料將供給給ES及語言訓練模型，真正實現全流程的閉環及可持續發展。

後臺使用這一套技術方案最大的優點在於，不廢前端人力，同時一鍵克隆功能真的很香。

• 接入配置

事實上，在做完這套智慧客服系統之後，整個系統設計受到了很多兄弟團隊的青睞，比如日常也要處理使用者問題的前端基建團隊，資料庫DBA團隊，看來大家對於日常FAQ收集、使用者問題解答等工作都在尋求更加低成本、可持續的解決方案。所以我們在Q2對整套系統進行了開放化開發，開放後我們支援多團隊應用號接入，所有團隊擁有同樣的會話狀態機管理、底層資料來源的靈活選擇，並實現了各團隊資料隔離，可一鍵克隆後臺管理頁面等功能。

目前在接入流程上，主要有如下幾步：

1. 提供配置資訊；比如：企微應用號AppSecret等基本資訊，這主要是為了方便使用企微提供的API介面實現訊息解析與回覆，同時需要提供一鍵拉群的值班資訊、問題收集模板配置等。

2. 回撥介面繫結；如果接入團隊想要使用應用號作為對話介面，則需要將統一的回撥介面繫結在企微應用上，方便對對話進行收集、解析、回覆。當然，我們的介面，也提供給有定製化對話視窗開發的團隊，方便對websocket等形式的對話介面進行開發。

3. 一鍵克隆後臺管理頁面；對後臺管理介面進行克隆並稍加修改，便能滿足團隊大部分訴求。

至此，稍加除錯，其他團隊就可以方便的接入智慧客服，完成一系列日常問題處理的閉環工作，包括智慧會話管理、問題FAQ收集、語言模型訓練等。

自系統上線以來，歷經幾次迭代，從支援單部門到開放至多部門，底層資料來源從ES迭代到ChatGPT，智慧客服已經成功實踐在以下應用中：

^{（應用中）} 

^{（已接入）}

使用以來，活動平臺姬共解決約1000例運營線上問題，日均解決運營5例諮詢問題，ChatGPT上線一個月後，問題智慧解決率提高接近7%。

對智慧客服現在的應用趨勢及使用反饋進行分析，我們也暢想了下未來發展：

1. 更加開放，可以利用企微應用號的回撥能力開發智慧客服系統，但同時也提供SDK服務，將能力提供給所有有需要的公司內部團隊使用，不限於幫助團隊靈活的進行對話介面的定製化開發。

2. 接入平臺化，現在要接入整個智慧客服系統，需要人工對接，後續把對接流程線上平臺化，增加一些稽核機制，就可以方便的實現服務一鍵接入。

3. 對轉人工進行最佳化，如果團隊使用企微應用號形式進行接入，那麼就一定會受限於企微的既有功能，在使用者轉人工後，需要單獨拉群間接實現搖人，整個對話無法在應用號內實現閉環解決，跳出帶來的一是使用者體驗，二是拉群太多增加了管理成本。這一部分我們考慮“花錢”解決，比方說能否以公司身份出面向企微提需，提供更加靈活的功能。

對智慧客服的整體技術實現，並沒有做花裡胡哨的“過度設計”，簡簡單單的微服務領域驅動模型，利用介面抽象其基本能力，提供對話接收、訊息解析、問題回答、列表展示等能力，底層表結構維護了支援長期發展的分表會話表、對話記錄表、FAQ表，便實現了整套智慧客服會話系統，而系統的會話流轉透過同步與非同步相結合的方式，將使用者介面功能與會話流轉進行了解藕，保證每個系統的單一職責。同時系統以介面維度作為輸出單元，入口簡單，接入方便。利用這個專案真正的實踐了一把MVA（最小可行架構），設計之初就限制新功能的範圍，儘量解耦和簡化系統元件，在保留功能和資料的完整性、可擴充套件性的同時，讓程式碼簡潔、功能明瞭。可謂由簡入奢易、由奢入簡難，什麼才是真正好的架構，這趟智慧客服專案之旅，讓我真正思考了一番工程師之道。

最後感謝大家耐心的讀到了這裡，希望你能有所收穫，哪怕一點點，哈哈。