<acronym id="cr5pu"></acronym>
  • <kbd id="cr5pu"><font id="cr5pu"></font></kbd>
  • <li id="cr5pu"><output id="cr5pu"></output></li>
    <del id="cr5pu"><li id="cr5pu"></li></del><center id="cr5pu"></center>
    <output id="cr5pu"><kbd id="cr5pu"></kbd></output>
  • <rp id="cr5pu"></rp>
    <var id="cr5pu"></var>
  • <nav id="cr5pu"></nav>
  • Jack Jiang

    我的最新工程MobileIMSDK:http://git.oschina.net/jackjiang/MobileIMSDK
    posts - 409, comments - 13, trackbacks - 0, articles - 0

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

    1、引言

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

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

     
     
    技術交流:

    (本文已同步發布于: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)權限管理:確??头到y數據和功能的安全性;

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

    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:返回有序集中,成員的分數值,可用于查看用戶排隊時間。

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

    7.5自動進線和會話邀請

    當用戶進入排隊后,有兩種方式可以獲得人工服務:自動進線和會話邀請。

    具體是:

    • 1)自動進線:系統會持續掃描未達到飽和度的客服,如果發現有客服尚未達到飽和度,會自動將隊列中的用戶分配給該客服;
    • 2)會話邀請:客服人員可以根據自身能力,即使已經超過飽和度,仍然可以邀請排隊中的用戶進入會話??梢砸淮涡匝堃粋€或多個用戶進入會話。

    8、 核心功能設計和實現4:客服工作臺

    8.1工作臺常見功能

    工作臺是客服人員與用戶會話的主戰場,其功能非常多。

    大致有以下一些:

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

    (限于篇幅,這里也不列舉過多)

    8.3工作臺技術難點

    1)多位用戶同時聊天,快速切換,卡頓問題的解決:

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

    具體是:

    1)定時更新緩存:WebWorker在后臺定時獲取并更新當前會話信息到緩存中;

    2)緩存預渲染:在客服切換會話時,直接渲染本地內存中緩存的內容,確保第一時間看到消息;

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

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

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

    2)工作臺消息種類繁多難題解決:

    工作臺消息種類較多,且消息本身會與業務產生關聯,如果不合理抽離組件,會影響業務的擴展。

    如上圖所示:多個消息類型對應多個功能卡片,每個功能卡片會組裝多個基礎組件,如文本消息 = 純文本框 + 信息面板,以此確保了業務快速擴展能力和基礎組件的復用能力。

    9、 核心功能設計和實現5:權限管理

    1)RBAC模型:

    迄今為止,最普及的權限設計模型是RBAC模型,即基于角色的訪問控制(Role-Based Access Control)。

    因此,本次客服系統也參考了RBAC模型:

    • 1)RBAC就是用戶通過角色與權限進行關聯;
    • 2)簡單地說,一個用戶擁有若干角色,每一個角色擁有若干權限;
    • 3)這樣,就構造成“用戶-角色-權限”的授權模型;
    • 4)在這種模型中,用戶與角色之間,角色與權限之間,一般者是多對多的關系。

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

    RBAC模型示意圖如下:

    目前客服只要求一個用戶可以有多個角色,一個角色只有一個權限。

    如下所示:

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

    3)權限管理界面:

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

    10、規劃和展望

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

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

    情緒撫慰:

    意圖識別:

    自我決策:

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

    除了智能問答領域,目前大型語言模型還可以應用于智能話術場景,或者在一些偏向咨詢的場景中試用。

    此外,業內也有在偏向咨詢的電商售前場景和互聯網教育咨詢場景中使用大型語言模型的案例。

    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中收發聊天消息背后的技術邏輯和思考實現

    [5] 得物基于Electron開發客服IM桌面端的技術實踐

    [6] 瓜子IM智能客服系統的數據架構設計(整理自現場演講,有配套PPT)

    [7] 得物從0到1自研客服IM系統的技術實踐之路

    [8] 瓜子IM智能客服系統的數據架構設計(PPT) [附件下載]

    [9] 從零到卓越:京東客服即時通訊系統的技術架構演進歷程


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



    作者:Jack Jiang (點擊作者姓名進入Github)
    出處:http://www.52im.net/space-uid-1.html
    交流:歡迎加入即時通訊開發交流群 215891622
    討論:http://www.52im.net/
    Jack Jiang同時是【原創Java Swing外觀工程BeautyEye】【輕量級移動端即時通訊框架MobileIMSDK】的作者,可前往下載交流。
    本博文 歡迎轉載,轉載請注明出處(也可前往 我的52im.net 找到我)。


    只有注冊用戶登錄后才能發表評論。


    網站導航:
     
    Jack Jiang的 Mail: jb2011@163.com, 聯系QQ: 413980957, 微信: hellojackjiang
    久久一级片
    <acronym id="cr5pu"></acronym>
  • <kbd id="cr5pu"><font id="cr5pu"></font></kbd>
  • <li id="cr5pu"><output id="cr5pu"></output></li>
    <del id="cr5pu"><li id="cr5pu"></li></del><center id="cr5pu"></center>
    <output id="cr5pu"><kbd id="cr5pu"></kbd></output>
  • <rp id="cr5pu"></rp>
    <var id="cr5pu"></var>
  • <nav id="cr5pu"></nav>