嗶哩嗶哩從0到1自研智能客服IM系統的技術實踐之路

Posted on 2023-11-23 11:53 Jack Jiang 閱讀(92) 評論(0) 編輯收藏

本文由B端技術中心分享，原題“從0到1:嗶哩嗶哩智能客服系統的設計與實現”，本文有修訂和改動。

1、引言

本文將要分享的是嗶哩嗶哩從0到1自研智能客服IM系統的技術實踐過程，包括整體架構設計和主要核心功能的技術實現思路等，希望帶給你啟發。

* 推薦閱讀：《得物從0到1自研客服IM系統的技術實踐之路》。

技術交流：

- 移動端IM開發入門文章：《新手入門一篇就夠：從零開發移動端IM》
- 開源IM框架源碼：https://github.com/JackJiang2011/MobileIMSDK（備用地址點此）

（本文已同步發布于：http://www.52im.net/thread-4517-1-1.html）

2、本文作者

小雄：嗶哩嗶哩客服業務技術負責人；
樂文：嗶哩嗶哩資深開發工程師；
鎮宇：嗶哩嗶哩高級開發工程師；
四百塊：嗶哩嗶哩高級開發工程師；
JasonQian：嗶哩嗶哩高級開發工程師；
宇琪：嗶哩嗶哩資深開發工程師。

3、技術背景

3.1為什么要做新系統

B站過去的客服系統是通過外部采購獲得的，已經使用了幾年。

然而，這個外購的系統存在一系列問題：

1）穩定性低，缺乏良好的拓展性和伸縮性，經常出現bug，難以應對突發的流量高峰；
2）與B站產品體系無法打通，難以根據業務需求進行定制化；
3）由于系統邏輯老舊，穩定性不佳，導致效率低下，已經不再能滿足進一步提升客服效率的要求。

雖然曾考慮過采購新的客服系統，但也面臨一些問題。

比如：

1）昂貴的價格，特別是在當前降本增效的大背景下，這是一個重要因素；
2）更重要的是，該系統仍然無法與內部系統進行良好的整合，無法支持業務定制化。

因此，B站決定開展新客服系統的自研工作。

3.2怎么做新系統

在面對如何打造一個全新的客服系統的挑戰時，我們首先開始了調研、訪談和體驗。

1）業內調研

我們訪問了一些在客服系統領域表現優秀的知名公司，從業務和技術的角度進行了深入調研。

總結下來，目前客服系統比較重視以下三個關鍵指標：

1）智能問答攔截率（也對應人工處理率）；
2）用戶滿意度；
3）平均處理時長：主要指客服人員處理一次會話所需的平均時長。

對于一個客服系統來說，良好的智能問答功能至關重要：

1）提供7*24小時在線服務，無需排隊等候，確保用戶在任何時間都能夠得到及時響應；
2）對于用戶頻繁問到的問題，可以快速回答，提高效率，降低成本，從而實現更好的客戶體驗和更高效的資源利用；
3）能夠快速解答大部分簡單問題，同時讓復雜問題有機會被人工高效解決，從而提升整體解決問題的效率和效果。

這些核心的指標為后續的研發指明了方向。

2）內部訪談和體驗

我們對負責客服流程運營的團隊以及各項功能團隊（質檢、輿情、機器人、工單、二線、數據等）和一線客服同學進行了訪談，同時也全面體驗了現有的系統。

特別是從各個團隊的訪談中，我們獲得了許多細節性的寶貴經驗和一系列建議，這對我們如何具體做好產品和之后推動系統的落地起到了巨大的作用。這些經驗和建議將在工作臺一節中詳細展示，在這里就不再展開。

3.3新系統落地效果如何

在核心指標上，新客服系統都取得了顯著的提升：

1）智能問答攔截率：與原有系統相比，新系統的智能問答攔截率有了巨大的提升，達到了業內先進水平；
2）用戶滿意度：也有顯著的提升，表明用戶對新系統的滿意度較高；
3）平均處理時長：盡管新系統需要適應的過程，但平均處理時長仍有減少，這一點非常不易。

（保密考慮，不暴露具體數字）

此外，新客服系統的落地還提高了客服工作效率，實現了與內部業務系統的無縫對接，優化了客服功能工具，驗證了自主研發的能力。

接下來，我們將從技術角度，整體和分細節方面對新客服系統進行介紹。

4、客服系統整體架構和核心業務流程

4.1概述

客服系統主要功能：

1）C端入口：進入客服的入口；
2）智能問答：通過機器人與用戶進行會話，解決用戶的問題；
3）客服坐席調度：給用戶選擇合適的客服人員同時兼顧客服人員的工作平衡；
4）客服工作臺：為客服人員提供便捷的工作界面和工具；
5）知識庫：匯集各類常見問題和解決方案，供客服使用；
6）IM聊天基礎能力：負責構建用戶和客服之間的聊天，進行對話操作（發送文字、圖片、視頻）等；
7）客服工單：用于跟蹤和解決用戶提出的問題和需求；
8）權限管理：確保客服系統數據和功能的安全性；

還有一些其他的功能如：質檢系統，輿情系統，客服工時系統，監控系統等等。

4.2總體功能架構

在上述描述中，我們可以認識到客服系統具有一定的復雜性。

為了幫助大家從宏觀上理解客服系統，以下列出了整體功能的架構圖：

4.3核心流程

同時，為了幫助大家進一步了解，這里列出了客服系統的核心流程。

5、核心功能設計和實現1：用戶入口

首先簡單看一下嗶哩嗶哩客服的用戶入口。

當用戶進入聊天框，首先會進入智能問答環節，如果智能問答無法幫助用戶解決問題，用戶可以選擇進一步聯系人工客服來解決問題。

6、核心功能設計和實現2：智能問答

6.1概述

在客服的業務場景中，智能問答是一個非常重要的需求。

它具備了人工不可比擬的優勢：

1）提供7*24小時的在線服務；
2）高峰時期無需排隊等候；
3）用戶頻繁問到的問題，可以快速回答；
4）大部分簡單問題得以快速自助解決。

從而從整體上提高效率，降低成本，實現更好的客戶體驗和更高效的資源利用。

下面，我們將簡要介紹嗶哩嗶哩客服系統的智能問答。

6.2智能問答系統概覽

目前，嗶哩嗶哩客服系統在執行智能問答任務時，會根據匹配度的不同提供兩種回答方式。

分別是：

1）當匹配度較高時，系統會直接給出答案；
2）當匹配度只是中等時，系統則會提供一個“您想咨詢的問題可能是”的列表。

這個策略的目的是為了提供更準確、更有用的回答，以幫助用戶更快地找到他們需要的信息。

6.3機器人問答技術調研

機器人問答技術在實現上主要分為兩種類型：檢索式和生成式。

1）檢索式：檢索式模型通常利用神經網絡技術，將大量的預訓練語料數據輸入到模型中進行訓練。在完成訓練后，模型能夠對新的輸入進行分類、匹配和回答問題。這種方案的實現主要依賴于大規模的預訓練數據和高效的檢索算法。

2）生成式：另一種類型的是生成式模型，它主要采用深度學習技術以及最新的大語言模型，通過學習大量數據來生成文本。這種方案通常使用循環神經網絡（RNN）或變換器（Transformer）等結構，能夠處理序列數據并生成新的序列。與檢索式模型不同，生成式模型在訓練過程中會直接生成目標文本，而不是通過檢索匹配。

總的來說，檢索式和生成式兩種模型各有特點，各有優勢，在機器人問答系統中都有應用。具體選擇哪種模型，往往需要根據具體的應用場景和需求來決定。

方案對比：

在電商客服場景下，回答用戶問題的準確性至關重要，寧可選擇不回答也不能夠回答錯誤。相比之下，生成式答案會受到多種因素的影響，導致結果不可控。而檢索式答案來源于知識庫，可以提供更加準確的問題解答。雖然檢索式在處理一些長尾問題或者冷門領域的問題時表現不佳，但是可以通過人工干預來豐富知識庫進行優化。綜合考慮到這些因素，最終選擇了檢索式實現。

6.4向量搜索和基于Faiss實現的智能問答

1）向量搜索基本原理：

給定一個向量集合：

和一個待查詢的向量：

從 N 個向量里面找到距離 X 某種距離（比如 L2 距離）最近的 K個向量。

其應用包括：

1）從語料庫里面找到距離某個語句最相近的一句話；
2）從圖片庫里面找到距離某張圖片最類似的一張圖片；
3）還能查找別的，比如視頻、音頻、動圖、基因序列、搜索條目等。

這些東西（圖片、詞語、句子、視頻等）都可以用向量表示出來，如下圖：

這個事情看起來很簡單，但是當我們的數據庫變得特別大時，這件事情就變得比較困難了。因此這里就專門來研究如何做這樣的向量搜索。

2）Faiss簡介：

Faiss（Facebook AI Similarity Search）是 Facebook AI 開發的用于高效相似性搜索和向量聚類的庫。

Faiss 總體使用過程可以分為三步：

1）構建訓練數據（以矩陣形式表達）；
2）挑選合適的 Index （Faiss 的核心部件），將訓練數據 add 進 Index 中；
3）Search，也就是搜索，得到最后結果。

詳細解釋，即為：首先根據原始向量構建一個索引文件，再根據索引文件進行查詢。初次查詢前需要進行train和add過程，后續若要進行索引的添加可以再次使用add添加索引。

如下圖所示：

3）基于Faiss實現的智能問答：

在實現檢索式的過程中，主要任務是找到與用戶提問語句最相似的問法，從而獲取對應的答案。

這個過程包括以下步驟：

1）數據準備：建立知識庫，包含標準問、相似問以及對應的答案。每個標準問有多個相似問，并對應唯一的答案：
2）文本向量化：使用BERT模型將問題和相似問轉化為向量表示。BERT模型采用預訓練方式，能夠將輸入的文本轉化為對應的向量表示。公司已有基于社區數據訓練的bert-embedding服務，體驗效果滿足需求，因此使用該服務進行文本向量化；
3）相似度計算：使用Faiss庫進行相似度計算。Faiss庫是一種針對聚類和相似性搜索的工具，為稠密向量提供高效相似度搜索和聚類，支持十億級別向量的搜索，是目前最為成熟的近似近鄰搜索庫；
4）搜索匹配：將用戶問題向量傳入Faiss庫中，使用相似度計算方法對問題進行匹配，找到最相似的TopN問題向量(或者說相似問)；
5）答案選取：根據相似度結果高低，直接給出問題對應的答案或者“您想咨詢的問題可能是”列表。如果相似度很低，則會轉接人工。

基于Faiss的智能問答如下圖所示：

4）Faiss索引選擇實踐：

Faiss提供的索引很多，需要根據數據集的大小和機器的性能來選取合適的索引。

基于準確查找：

僅有IndexFlatL2索引可以提供確切的結果，但是性能上會比較差，僅適用數據量比較少的情況，通常為其他索引準確度提供基準。

基于內存限制：

1）由于所有的Faiss索引都將向量存儲在內存中，如果內存是限制因素，那么就需要將準確度和性能進行折衷：
2）不關心內存則使用"HNSWx"，通過"efSearch"參數平衡準確度和性能，該參數越大越準確，同時性能越差；
3）有一點關心內存則使用"..,Flat"，"..."的含義是聚類，聚類后，"Flat"的含義是不壓縮，存儲大小與原始數據集相同，通過"nprobe"參數平衡準確度和性能；
4）很關心內存則使用"PCARx,...,SQ8"，PCARx指將維度降x，SQ8指將每8bit向量壓縮到1bit；
5）非常關心內存則使用"OPQx_y,...,PQx"，PQx使用輸出x-byte的量化器壓縮向量。x通常<= 64，對于較大的代碼，SQ通常是準確和快速的。OPQ是向量的線性轉換，使它們更容易壓縮。

基于數據集限制：

1）如果低于1M個向量： "...,IVFx,..."，直接倒排索引，x范圍在 4*sqrt(N)~16*sqrt(N)之間，N是數據集大小，x是k-means聚類后的數量；
2）如果1M - 10M："...,IVF65536_HNSW32,..."，結合IVF和HNSW，用HNSW進行聚類；
3）如果10M - 100M： "...,IVF262144_HNSW32,..."；
4）如果100M - 1B： "...,IVF1048576_HNSW32,..."。

由于我們數據集在10M以內，最終選取了"IVF{IVFK}_HNSW32,Flat"，如果小于10M，IVFK根據依據4*sqrt(N)~16*sqrt(N)動態算，如果大于10M，則IVFK為65536。

部分代碼如下：

iflen(x) < 1000000:
ivfK = findIVFK(len(x))
else:
ivfK = 65536
factory_str = f'IVF{ivfK}_HNSW32,Flat'

def findIVFK(N: int):
    sqrtN = math.sqrt(N)
    print(sqrtN, 4 * sqrtN, 16 * sqrtN)
    i = 2
    while True:
        i *= 2
        if4 * sqrtN <= i <= 16 * sqrtN and N // 256 <= i <= N // 30:
            returni
        ifi > 4096:
            return512

7、核心功能設計和實現3：客服坐席調度

7.1什么是客服坐席調度

客服坐席調度主要涉及為用戶提供選擇人工客服的一系列調度策略和邏輯。

通過這些策略和邏輯，用戶可以快速地聯系到合適的人工客服來處理他們的問題，從而獲得更及時和有效的幫助。

調度策略可以包括根據用戶的信息、問題類型、服務需求等因素來分配客服坐席，以及根據坐席的服務質量和服務水平來進行評估和調整。

通過合理的調度策略和邏輯，可以提高用戶滿意度和解決效率，從而提升整個客戶服務的品質和用戶體驗。

大致可以通過以下流程圖說明：

坐席調度策略在客戶服務中扮演著關鍵角色。

以下是可以看到的幾種常見策略及其優勢。

1）均衡分配策略：這種策略將用戶請求平均分配給各個坐席，從而平衡工作負荷，提高整體服務效率。它的優點在于保證了所有坐席的工作量公平分配，防止了某些坐席過度勞累，也防止了某些坐席空閑的情況。

2）熟客優先策略：根據用戶的歷史服務記錄和需求，將用戶優先分配給曾經提供過優質服務的坐席。這種策略的優點在于提高了用戶的服務體驗，因為熟客通常能夠得到更快速、更準確的服務。

3）上次服務優先策略：將用戶分配給上一次為其提供服務的坐席，以提高用戶滿意度和連續服務效率。這種策略的優點在于可以維持用戶對特定坐席的信任，有利于提供持續、一致的服務。

4）指定分配策略：根據特定條件或需求，將用戶請求分配給指定的坐席。這種策略的優點在于可以滿足某些特殊需求，或者處理復雜問題。

在進行了深入研究后，我們發現均衡分配策略是業內使用最廣泛和最常用的策略，也被廣泛應用于各種客戶服務系統。

這是因為均衡分配策略可以確保所有坐席的工作量公平分配，防止過度勞累，防止坐席空閑，從而提高整體服務效率。

同時，我們也發現，熟客優先策略、上次服務優先策略和指定分配策略都有其特定的適用場景，可以在需要的時候作為均衡分配策略的補充。

因此，我們的選擇是采用均衡分配策略作為基礎的坐席調度策略，同時根據特定情況靈活運用其他策略。

7.2均衡分配

在介紹均衡分配前，有幾個名詞需要提前解釋一下。

1）飽和度：客服可以服務的最大用戶數，在客服被邀請進入系統時會被設置。

2）均衡分配：本系統會在不超過飽和度的情況下，客服均衡獲取用戶分配。

7.3如何實現均衡分配

以下是我們客服系統中均衡分配的實現邏輯。

注意：分配是以技能組為單位進行分配。假設一個技能組有兩個客服，A客服的飽和度為5，B客服的飽和度為10。

具體是：

1）如果A客服當前服務的用戶數少于B客服當前服務的用戶數，并且都低于各自的飽和度，那么如果有用戶進線，系統會優先分配給A客服；
2）如果A客服和B客服當前服務的用戶數相等，并且都低于各自的飽和度，那么如果有用戶進線，系統會隨機均衡分配給A或B客服；
3）如果A客服已經達到了自己的飽和度，那么如果有用戶進線，A客服將不會被分配到該用戶進線，該用戶將被分配給還沒有達到飽和度的客服，并根據上述1和2的原則進行分配；
4）如果A客服和B客服都已經達到了各自的飽和度，那么系統將進入排隊狀態。

7.4排隊

這里可以用Redis的Zset數據結構，可以方便的根據用戶排隊時間進行先后次序排隊。

具體是：

1）ZADD：用于添加元素，Key使用技能組id，每個技能組id關聯一個有序集，有序集Member是用戶id，Score是用戶進入排隊的時間戳，這里可以用于添加排隊的用戶；
2）ZRANK：返回有序集中成員的排名，可用于展示當前排名；
3）ZREM：移除有序集中的一個或多個成員，可用于退出排隊；
4）ZRANGE：返回有序集中指定區間內的成員，可用于客服工作臺會話邀請場景；
5）ZPOPMIN：返回最低得分的成員，也就是最早排隊的成員，可以用于自動進線場景；
6）ZCOUNT：返回計算有序集合中指定分數區間的成員數量，可用于計算排隊長度；
7）ZSCORE：返回有序集中，成員的分數值，可用于查看用戶排隊時間。