本文由B端技術(shù)中心分享，原題“從0到1:嗶哩嗶哩智能客服系統(tǒng)的設(shè)計與實現(xiàn)”，本文有修訂和改動。

1、引言

本文將要分享的是嗶哩嗶哩從0到1自研智能客服IM系統(tǒng)的技術(shù)實踐過程，包括整體架構(gòu)設(shè)計和主要核心功能的技術(shù)實現(xiàn)思路等，希望帶給你啟發(fā)。

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

?

技術(shù)交流：

- 移動端IM開發(fā)入門文章：《新手入門一篇就夠：從零開發(fā)移動端IM》

- 開源IM框架源碼：https://github.com/JackJiang2011/MobileIMSDK（備用地址點此）

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

2、本文作者

• 小雄：嗶哩嗶哩客服業(yè)務(wù)技術(shù)負責人；

• 樂文：嗶哩嗶哩資深開發(fā)工程師；

• 鎮(zhèn)宇：嗶哩嗶哩高級開發(fā)工程師；

• 四百塊：嗶哩嗶哩高級開發(fā)工程師；

• JasonQian：嗶哩嗶哩高級開發(fā)工程師；

• 宇琪：嗶哩嗶哩資深開發(fā)工程師。

3、技術(shù)背景

3.1為什么要做新系統(tǒng)

B站過去的客服系統(tǒng)是通過外部采購獲得的，已經(jīng)使用了幾年。

然而，這個外購的系統(tǒng)存在一系列問題：

• 1）穩(wěn)定性低，缺乏良好的拓展性和伸縮性，經(jīng)常出現(xiàn)bug，難以應(yīng)對突發(fā)的流量高峰；

• 2）與B站產(chǎn)品體系無法打通，難以根據(jù)業(yè)務(wù)需求進行定制化；

• 3）由于系統(tǒng)邏輯老舊，穩(wěn)定性不佳，導(dǎo)致效率低下，已經(jīng)不再能滿足進一步提升客服效率的要求。

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

比如：

• 1）昂貴的價格，特別是在當前降本增效的大背景下，這是一個重要因素；

• 2）更重要的是，該系統(tǒng)仍然無法與內(nèi)部系統(tǒng)進行良好的整合，無法支持業(yè)務(wù)定制化。

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

3.2怎么做新系統(tǒng)

在面對如何打造一個全新的客服系統(tǒng)的挑戰(zhàn)時，我們首先開始了調(diào)研、訪談和體驗。

1）業(yè)內(nèi)調(diào)研

我們訪問了一些在客服系統(tǒng)領(lǐng)域表現(xiàn)優(yōu)秀的知名公司，從業(yè)務(wù)和技術(shù)的角度進行了深入調(diào)研。

總結(jié)下來，目前客服系統(tǒng)比較重視以下三個關(guān)鍵指標：

• 1）智能問答攔截率（也對應(yīng)人工處理率）；

• 2）用戶滿意度；

• 3）平均處理時長：主要指客服人員處理一次會話所需的平均時長。

對于一個客服系統(tǒng)來說，良好的智能問答功能至關(guān)重要：

• 1）提供7*24小時在線服務(wù)，無需排隊等候，確保用戶在任何時間都能夠得到及時響應(yīng)；

• 2）對于用戶頻繁問到的問題，可以快速回答，提高效率，降低成本，從而實現(xiàn)更好的客戶體驗和更高效的資源利用；

• 3）能夠快速解答大部分簡單問題，同時讓復(fù)雜問題有機會被人工高效解決，從而提升整體解決問題的效率和效果。

這些核心的指標為后續(xù)的研發(fā)指明了方向。

2）內(nèi)部訪談和體驗

我們對負責客服流程運營的團隊以及各項功能團隊（質(zhì)檢、輿情、機器人、工單、二線、數(shù)據(jù)等）和一線客服同學(xué)進行了訪談，同時也全面體驗了現(xiàn)有的系統(tǒng)。

特別是從各個團隊的訪談中，我們獲得了許多細節(jié)性的寶貴經(jīng)驗和一系列建議，這對我們?nèi)绾尉唧w做好產(chǎn)品和之后推動系統(tǒng)的落地起到了巨大的作用。這些經(jīng)驗和建議將在工作臺一節(jié)中詳細展示，在這里就不再展開。

3.3新系統(tǒng)落地效果如何

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

• 1）智能問答攔截率：與原有系統(tǒng)相比，新系統(tǒng)的智能問答攔截率有了巨大的提升，達到了業(yè)內(nèi)先進水平；

• 2）用戶滿意度：也有顯著的提升，表明用戶對新系統(tǒng)的滿意度較高；

• 3）平均處理時長：盡管新系統(tǒng)需要適應(yīng)的過程，但平均處理時長仍有減少，這一點非常不易。

（保密考慮，不暴露具體數(shù)字）

此外，新客服系統(tǒng)的落地還提高了客服工作效率，實現(xiàn)了與內(nèi)部業(yè)務(wù)系統(tǒng)的無縫對接，優(yōu)化了客服功能工具，驗證了自主研發(fā)的能力。

接下來，我們將從技術(shù)角度，整體和分細節(jié)方面對新客服系統(tǒng)進行介紹。

4、客服系統(tǒng)整體架構(gòu)和核心業(yè)務(wù)流程

4.1概述

客服系統(tǒng)主要功能：

• 1）C端入口：進入客服的入口；

• 2）智能問答：通過機器人與用戶進行會話，解決用戶的問題；

• 3）客服坐席調(diào)度：給用戶選擇合適的客服人員同時兼顧客服人員的工作平衡；

• 4）客服工作臺：為客服人員提供便捷的工作界面和工具；

• 5）知識庫：匯集各類常見問題和解決方案，供客服使用；

• 6）IM聊天基礎(chǔ)能力：負責構(gòu)建用戶和客服之間的聊天，進行對話操作（發(fā)送文字、圖片、視頻）等；

• 7）客服工單：用于跟蹤和解決用戶提出的問題和需求；

• 8）權(quán)限管理：確?？头到y(tǒng)數(shù)據(jù)和功能的安全性；

還有一些其他的功能如：質(zhì)檢系統(tǒng)，輿情系統(tǒng)，客服工時系統(tǒng)，監(jiān)控系統(tǒng)等等。

4.2總體功能架構(gòu)

在上述描述中，我們可以認識到客服系統(tǒng)具有一定的復(fù)雜性。

為了幫助大家從宏觀上理解客服系統(tǒng)，以下列出了整體功能的架構(gòu)圖：

4.3核心流程

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

5、核心功能設(shè)計和實現(xiàn)1：用戶入口

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

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

6、核心功能設(shè)計和實現(xiàn)2：智能問答

6.1概述

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

它具備了人工不可比擬的優(yōu)勢：

• 1）提供7*24小時的在線服務(wù)；

• 2）高峰時期無需排隊等候；

• 3）用戶頻繁問到的問題，可以快速回答；

• 4）大部分簡單問題得以快速自助解決。

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

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

6.2智能問答系統(tǒng)概覽

目前，嗶哩嗶哩客服系統(tǒng)在執(zhí)行智能問答任務(wù)時，會根據(jù)匹配度的不同提供兩種回答方式。

分別是：

• 1）當匹配度較高時，系統(tǒng)會直接給出答案；

• 2）當匹配度只是中等時，系統(tǒng)則會提供一個“您想咨詢的問題可能是”的列表。

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

6.3機器人問答技術(shù)調(diào)研

機器人問答技術(shù)在實現(xiàn)上主要分為兩種類型：檢索式和生成式。

1）檢索式：檢索式模型通常利用神經(jīng)網(wǎng)絡(luò)技術(shù)，將大量的預(yù)訓(xùn)練語料數(shù)據(jù)輸入到模型中進行訓(xùn)練。在完成訓(xùn)練后，模型能夠?qū)π碌妮斎脒M行分類、匹配和回答問題。這種方案的實現(xiàn)主要依賴于大規(guī)模的預(yù)訓(xùn)練數(shù)據(jù)和高效的檢索算法。

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

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

方案對比：

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

6.4向量搜索和基于Faiss實現(xiàn)的智能問答

1）向量搜索基本原理：

給定一個向量集合：

和一個待查詢的向量：

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

其應(yīng)用包括：

• 1）從語料庫里面找到距離某個語句最相近的一句話；

• 2）從圖片庫里面找到距離某張圖片最類似的一張圖片；

• 3）還能查找別的，比如視頻、音頻、動圖、基因序列、搜索條目等。

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

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

2）Faiss簡介：

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

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

• 1）構(gòu)建訓(xùn)練數(shù)據(jù)（以矩陣形式表達）；

• 2）挑選合適的 Index （Faiss 的核心部件），將訓(xùn)練數(shù)據(jù) add 進 Index 中；

• 3）Search，也就是搜索，得到最后結(jié)果。

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

如下圖所示：

3）基于Faiss實現(xiàn)的智能問答：

在實現(xiàn)檢索式的過程中，主要任務(wù)是找到與用戶提問語句最相似的問法，從而獲取對應(yīng)的答案。

這個過程包括以下步驟：

• 1）數(shù)據(jù)準備：建立知識庫，包含標準問、相似問以及對應(yīng)的答案。每個標準問有多個相似問，并對應(yīng)唯一的答案：

• 2）文本向量化：使用BERT模型將問題和相似問轉(zhuǎn)化為向量表示。BERT模型采用預(yù)訓(xùn)練方式，能夠?qū)⑤斎氲奈谋巨D(zhuǎn)化為對應(yīng)的向量表示。公司已有基于社區(qū)數(shù)據(jù)訓(xùn)練的bert-embedding服務(wù)，體驗效果滿足需求，因此使用該服務(wù)進行文本向量化；

• 3）相似度計算：使用Faiss庫進行相似度計算。Faiss庫是一種針對聚類和相似性搜索的工具，為稠密向量提供高效相似度搜索和聚類，支持十億級別向量的搜索，是目前最為成熟的近似近鄰搜索庫；

• 4）搜索匹配：將用戶問題向量傳入Faiss庫中，使用相似度計算方法對問題進行匹配，找到最相似的TopN問題向量(或者說相似問)；

• 5）答案選取：根據(jù)相似度結(jié)果高低，直接給出問題對應(yīng)的答案或者“您想咨詢的問題可能是”列表。如果相似度很低，則會轉(zhuǎn)接人工。

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

4）Faiss索引選擇實踐：

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

基于準確查找：

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

基于內(nèi)存限制：

• 1）由于所有的Faiss索引都將向量存儲在內(nèi)存中，如果內(nèi)存是限制因素，那么就需要將準確度和性能進行折衷：

• 2）不關(guān)心內(nèi)存則使用"HNSWx"，通過"efSearch"參數(shù)平衡準確度和性能，該參數(shù)越大越準確，同時性能越差；

• 3）有一點關(guān)心內(nèi)存則使用"..,Flat"，"..."的含義是聚類，聚類后，"Flat"的含義是不壓縮，存儲大小與原始數(shù)據(jù)集相同，通過"nprobe"參數(shù)平衡準確度和性能；

• 4）很關(guān)心內(nèi)存則使用"PCARx,...,SQ8"，PCARx指將維度降x，SQ8指將每8bit向量壓縮到1bit；

• 5）非常關(guān)心內(nèi)存則使用"OPQx_y,...,PQx"，PQx使用輸出x-byte的量化器壓縮向量。x通常<= 64，對于較大的代碼，SQ通常是準確和快速的。OPQ是向量的線性轉(zhuǎn)換，使它們更容易壓縮。

基于數(shù)據(jù)集限制：

• 1）如果低于1M個向量： "...,IVFx,..."，直接倒排索引，x范圍在 4*sqrt(N)~16*sqrt(N)之間，N是數(shù)據(jù)集大小，x是k-means聚類后的數(shù)量；

• 2）如果1M - 10M："...,IVF65536_HNSW32,..."，結(jié)合IVF和HNSW，用HNSW進行聚類；

• 3）如果10M - 100M： "...,IVF262144_HNSW32,..."；

• 4）如果100M - 1B： "...,IVF1048576_HNSW32,..."。

由于我們數(shù)據(jù)集在10M以內(nèi)，最終選取了"IVF{IVFK}_HNSW32,Flat"，如果小于10M，IVFK根據(jù)依據(jù)4*sqrt(N)~16*sqrt(N)動態(tài)算，如果大于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、核心功能設(shè)計和實現(xiàn)3：客服坐席調(diào)度

7.1什么是客服坐席調(diào)度

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

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

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

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

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

坐席調(diào)度策略在客戶服務(wù)中扮演著關(guān)鍵角色。

以下是可以看到的幾種常見策略及其優(yōu)勢。

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

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

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

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

在進行了深入研究后，我們發(fā)現(xiàn)均衡分配策略是業(yè)內(nèi)使用最廣泛和最常用的策略，也被廣泛應(yīng)用于各種客戶服務(wù)系統(tǒng)。

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

同時，我們也發(fā)現(xiàn)，熟客優(yōu)先策略、上次服務(wù)優(yōu)先策略和指定分配策略都有其特定的適用場景，可以在需要的時候作為均衡分配策略的補充。

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

7.2均衡分配

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

1）飽和度：客服可以服務(wù)的最大用戶數(shù)，在客服被邀請進入系統(tǒng)時會被設(shè)置。

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

7.3如何實現(xiàn)均衡分配

以下是我們客服系統(tǒng)中均衡分配的實現(xiàn)邏輯。

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

具體是：

• 1）如果A客服當前服務(wù)的用戶數(shù)少于B客服當前服務(wù)的用戶數(shù)，并且都低于各自的飽和度，那么如果有用戶進線，系統(tǒng)會優(yōu)先分配給A客服；

• 2）如果A客服和B客服當前服務(wù)的用戶數(shù)相等，并且都低于各自的飽和度，那么如果有用戶進線，系統(tǒng)會隨機均衡分配給A或B客服；

• 3）如果A客服已經(jīng)達到了自己的飽和度，那么如果有用戶進線，A客服將不會被分配到該用戶進線，該用戶將被分配給還沒有達到飽和度的客服，并根據(jù)上述1和2的原則進行分配；

• 4）如果A客服和B客服都已經(jīng)達到了各自的飽和度，那么系統(tǒng)將進入排隊狀態(tài)。

7.4排隊

這里可以用Redis的Zset數(shù)據(jù)結(jié)構(gòu)，可以方便的根據(jù)用戶排隊時間進行先后次序排隊。

具體是：

• 1）ZADD：用于添加元素，Key使用技能組id，每個技能組id關(guān)聯(lián)一個有序集，有序集Member是用戶id，Score是用戶進入排隊的時間戳，這里可以用于添加排隊的用戶；

• 2）ZRANK：返回有序集中成員的排名，可用于展示當前排名；

• 3）ZREM：移除有序集中的一個或多個成員，可用于退出排隊；

• 4）ZRANGE：返回有序集中指定區(qū)間內(nèi)的成員，可用于客服工作臺會話邀請場景；

• 5）ZPOPMIN：返回最低得分的成員，也就是最早排隊的成員，可以用于自動進線場景；

• 6）ZCOUNT：返回計算有序集合中指定分數(shù)區(qū)間的成員數(shù)量，可用于計算排隊長度；

• 7）ZSCORE：返回有序集中，成員的分數(shù)值，可用于查看用戶排隊時間。

以上命令基本可以滿足排隊場景各項操作。

7.5自動進線和會話邀請

當用戶進入排隊后，有兩種方式可以獲得人工服務(wù)：自動進線和會話邀請。

具體是：

• 1）自動進線：系統(tǒng)會持續(xù)掃描未達到飽和度的客服，如果發(fā)現(xiàn)有客服尚未達到飽和度，會自動將隊列中的用戶分配給該客服；

• 2）會話邀請：客服人員可以根據(jù)自身能力，即使已經(jīng)超過飽和度，仍然可以邀請排隊中的用戶進入會話?？梢砸淮涡匝堃粋€或多個用戶進入會話。

8、 核心功能設(shè)計和實現(xiàn)4：客服工作臺

8.1工作臺常見功能

工作臺是客服人員與用戶會話的主戰(zhàn)場，其功能非常多。

大致有以下一些：

8.2部分亮點和智能化功能示意

（限于篇幅，這里也不列舉過多）

8.3工作臺技術(shù)難點

1）多位用戶同時聊天，快速切換，卡頓問題的解決：

為了確?？头诳焖偾袚Q時能夠第一時間看到消息，可以采用以下方式在會話切換時進行緩存更新渲染。

具體是：

1）定時更新緩存：WebWorker在后臺定時獲取并更新當前會話信息到緩存中；

2）緩存預(yù)渲染：在客服切換會話時，直接渲染本地內(nèi)存中緩存的內(nèi)容，確保第一時間看到消息；

3）同步機制：在客服切換會話時，立刻發(fā)出接口請求，將最新的會話信息實時更新到緩存中，以確保緩存與實際會話信息的一致性。

通過以上方式，可以確?？头诳焖偾袚Q會話時能夠第一時間看到消息，提高服務(wù)效率。

DOM會隨消息數(shù)量線性增長，從而導(dǎo)致瀏覽器卡頓甚至崩潰，如果每次都動態(tài)拉取數(shù)據(jù)，會對服務(wù)端造成壓力，通過維護緩存數(shù)據(jù)+虛擬列表+虛擬滾動的方式來渲染消息信息，保證系統(tǒng)可以在瀏覽器中長時間運行流暢。

2）工作臺消息種類繁多難題解決：

工作臺消息種類較多，且消息本身會與業(yè)務(wù)產(chǎn)生關(guān)聯(lián)，如果不合理抽離組件，會影響業(yè)務(wù)的擴展。

如上圖所示：多個消息類型對應(yīng)多個功能卡片，每個功能卡片會組裝多個基礎(chǔ)組件，如文本消息 = 純文本框 + 信息面板，以此確保了業(yè)務(wù)快速擴展能力和基礎(chǔ)組件的復(fù)用能力。

9、 核心功能設(shè)計和實現(xiàn)5：權(quán)限管理

1）RBAC模型：

迄今為止，最普及的權(quán)限設(shè)計模型是RBAC模型，即基于角色的訪問控制（Role-Based Access Control）。

因此，本次客服系統(tǒng)也參考了RBAC模型：

• 1）RBAC就是用戶通過角色與權(quán)限進行關(guān)聯(lián)；

• 2）簡單地說，一個用戶擁有若干角色，每一個角色擁有若干權(quán)限；

• 3）這樣，就構(gòu)造成“用戶-角色-權(quán)限”的授權(quán)模型；

• 4）在這種模型中，用戶與角色之間，角色與權(quán)限之間，一般者是多對多的關(guān)系。

這種授權(quán)模型提供了了一種靈活的授權(quán)方式，可以方便地實現(xiàn)用戶之間的授權(quán)和訪問控制，同時也簡化了權(quán)限管理流程，提高了管理效率。

RBAC模型示意圖如下：

目前客服只要求一個用戶可以有多個角色，一個角色只有一個權(quán)限。

如下所示：

RBAC模型目前完全可以支撐當前的客服的權(quán)限管理。

3）權(quán)限管理界面：

在管理員頁面上，可以方便的進行技能組（角色）分配，如下所示。

10、規(guī)劃和展望

當前備受關(guān)注的大語言模型我們也進行了探索。我們與公司AI部門合作，將客服與用戶的真實聊天記錄以及知識庫作為訓(xùn)練數(shù)據(jù)，給大模型進行訓(xùn)練，并且進行了測試。

總體上，我們學(xué)到了客服的回答風格，使回答更為流暢自然，與檢索式問答相比，這種方式更容易讓客戶在心理上接受，并能夠做出一些決策。

情緒撫慰：

意圖識別：

自我決策：

當然，我們也遇到了強制回答和回答無法解決問題的情況。要解決問題，需要根據(jù)客戶的具體問題和訂單狀態(tài)來回答。不過，大型語言模型是未來的趨勢，值得我們進一步探索。

除了智能問答領(lǐng)域，目前大型語言模型還可以應(yīng)用于智能話術(shù)場景，或者在一些偏向咨詢的場景中試用。

此外，業(yè)內(nèi)也有在偏向咨詢的電商售前場景和互聯(lián)網(wǎng)教育咨詢場景中使用大型語言模型的案例。

11、 參考資料

[1]?https://www.pinecone.io/learn/series/faiss/vector-indexes/

[2]?https://towardsdatascience.com/s ... in-nlp-acc0777e234c

[3]?https://www.pinecone.io/learn/series/faiss/faiss-tutorial/

[4]?得物自研客服IM中收發(fā)聊天消息背后的技術(shù)邏輯和思考實現(xiàn)

[5]?得物基于Electron開發(fā)客服IM桌面端的技術(shù)實踐

[6]?瓜子IM智能客服系統(tǒng)的數(shù)據(jù)架構(gòu)設(shè)計（整理自現(xiàn)場演講，有配套PPT）

[7]?得物從0到1自研客服IM系統(tǒng)的技術(shù)實踐之路

[8]?瓜子IM智能客服系統(tǒng)的數(shù)據(jù)架構(gòu)設(shè)計(PPT) [附件下載]

[9]?從零到卓越：京東客服即時通訊系統(tǒng)的技術(shù)架構(gòu)演進歷程

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