從0到10Wqps,大廠的智能客服平臺,如何實現架構演進?

文章很長,且持續更新,建議收藏起來,慢慢讀!瘋狂創客圈總目錄 博客園版 爲您奉上珍貴的學習資源 :

免費贈送 :《尼恩Java面試寶典》 持續更新+ 史上最全 + 面試必備 2000頁+ 面試必備 + 大廠必備 +漲薪必備
免費贈送 :《尼恩技術聖經+高併發系列PDF》 ,幫你 實現技術自由,完成職業升級, 薪酬猛漲!加尼恩免費領
免費贈送 經典圖書:《Java高併發核心編程(卷1)加強版》 面試必備 + 大廠必備 +漲薪必備 加尼恩免費領
免費贈送 經典圖書:《Java高併發核心編程(卷2)加強版》 面試必備 + 大廠必備 +漲薪必備 加尼恩免費領
免費贈送 經典圖書:《Java高併發核心編程(卷3)加強版》 面試必備 + 大廠必備 +漲薪必備 加尼恩免費領

免費贈送 資源寶庫: Java 必備 百度網盤資源大合集 價值>10000元 加尼恩領取


從0到10Wqps,大廠的智能客服平臺,如何實現架構演進?

尼恩特別說明: 尼恩的文章,都會在 《技術自由圈》 公號 發佈, 並且維護最新版本。 如果發現圖片 不可見, 請去 《技術自由圈》 公號 查找

尼恩:LLM大模型學習聖經PDF的起源

在40歲老架構師 尼恩的讀者交流羣(50+)中,經常性的指導小夥伴們改造簡歷。

經過尼恩的改造之後,很多小夥伴拿到了一線互聯網企業如得物、阿里、滴滴、極兔、有贊、希音、百度、網易、美團的面試機會,拿到了大廠機會。

然而,其中一個成功案例,是一個9年經驗 網易的小夥伴,拿到了一個年薪近80W的大模型架構offer

逆漲50%,那是在去年2023年的 5月。

不到1年,小夥伴也在團隊站穩了腳跟,成爲了名副其實的大模型架構師。目前,他管理了10人左右的團隊,一個2-3人的python算法小分隊,一個3-4人Java應用開發小分隊,一個2-3人實施運維小分隊。

並且他們的產品也收到了豐厚的經濟回報, 他們的AIGC大模型產品,好像已經實施了不下10家的大中型企業客戶。

既然AI+大模型工程架構 前途無量,那麼,從2024的4月份開始,尼恩開始寫 《LLM大模型學習聖經》,幫助大家穿透大模型,穿透AI,走向大模型工程架構之路。

注意 是AI工程架構師,不是AI算法架構師,不要搞偏了。

img

大模型的應用場景

大模型在各個領域都有廣泛的應用,特別是在以下幾個方面:

  1. 自然語言處理(NLP):大模型在自然語言理解、語言生成、機器翻譯等任務中表現出色。例如,BERT、GPT等模型在文本理解和生成方面取得了顯著的進展。
  2. 計算機視覺(CV):在圖像分類、目標檢測、圖像生成等領域,大模型也取得了巨大的成功。例如,ResNet、YOLO、GAN等模型在圖像處理方面取得了顯著的成果。
  3. 推薦系統:大模型在個性化推薦、廣告點擊率預估、智能客服等方面發揮着重要作用。例如,YouTube的DNN模型在視頻推薦中發揮着重要作用。
  4. 生物醫藥:在藥物發現、分子結構預測、疾病診斷等方面,大模型也有廣泛的應用。例如,使用大模型對蛋白質進行預測,有助於加速新藥的研發。
  5. 金融領域:在風險管理、交易預測、信用評分等方面,大模型可以提供更精準的預測和決策支持。例如,使用大模型對金融數據進行分析,可以幫助金融機構提高風險管理能力。

總的來說,大模型在各個領域都有重要的應用,可以幫助解決複雜的問題,提高系統的性能和效率。

此文,尼恩站在巨人的肩膀上,爲大家梳理幾個 智能客服 的線上案例, 研究和分析大模型在 智能客服 領域的使用現狀。

後面的文章, 尼恩持續爲大家 梳理和總結 大模型應用場景, 並且收入 《LLM大模型學習聖經》 系列PDF。

尼恩的 《LLM大模型學習聖經》 系列PDF,已經發布了第一卷:

《LLM大模型學習聖經:從0到1喫透Transformer技術底座》

這個是一個基礎理論篇、核心篇。

另外好戲剛剛開始, 後面會有實戰篇,架構篇等等出來。

在尼恩的架構師哲學中,開宗明義:架構和語言無關,架構的思想和模式,本就是想通的。

架構思想和體系,本身和語言無關,和業務也關係不大,都是通的。

所以,尼恩用自己的架構內功,以及20年時間積累的架構洪荒之力,通過《LLM大模型學習聖經》,給大家做一下系統化、體系化的LLM梳理,使得大家內力猛增,成爲大模型架構師,然後實現”offer直提”, 逆天改命。

尼恩 《LLM大模型學習聖經》PDF 系列文檔,會延續尼恩的一貫風格,會持續迭代,持續升級。

這個文檔將成爲大家 學習大模型的殺手鐗, 此文當最新PDF版本,可以來《技術自由圈》公號獲取。

3個 AI(包括小模型 + 大模型)智能客服平臺

言歸正傳,接下來,我們梳理 AI(包括小模型 + 大模型)在 智能客服平臺 領域的應用

這裏從小到大,涉及了3個平臺

  • 案例1:B站小型的運營智能客服平臺架構
  • 案例2:1Wqps+ 高併發B站智能客服系統的設計與實現
  • 案例3:10Wqps 美團智能客服核心技術與實踐

接下來,一個一個來

案例1:B站小型的運營智能客服平臺架構

40歲老架構師尼恩提示:這是一個小型的案例, 應用場景是 解決 運營的智能知識庫的問題。

原文: https://juejin.cn/post/7324384155231223862

作者: 林晶昱

B站小型的運營智能客服平臺的業務場景

一直以來,B站的活動平臺一直是運營部門的重要工具。在運營過程中,偶爾會遇到一些疑難問題。

  • 例如,運營人員可能對某個組件功能的使用產生疑問。

  • 或者,線上活動的表現與預期不符。

在這些情況下,運營部門期望產品研發團隊能夠協助排查問題。老的活動平臺的線上問題排查流程,大致如下:

  • 建立一個千人以上的產研運“救火羣”。

  • 當運營遇到問題時,他們會在羣裏提出問題。

  • 研發關注羣裏的問題,並及時給予響應和解答。

  • 研發需要手動記錄每週問題的excel表格。

“拉大羣” 的做法依賴人工干預和手動記錄 , 很古老,很普遍, 但是這個有很多弊端:

  • 缺乏沉底的弊端:問題及解決方案沒法自動沉澱,想要把FAQ記錄下來,得靠值班同學費盡心思地手動記錄,這不光耗時還超級耗力。

  • 對值班人員能力要求過高的弊端:要解答問題,值班同學得對問題所涉領域有足夠的瞭解,要不然就是啞巴喫黃連,有苦說不出啊。

  • 效率低下的弊端:羣消息內容太繁雜了,有時候消息會被其他信息吞沒,這可得靠值班同學像蜘蛛俠一樣靈活,才能捕捉到問題的“蛛絲馬跡”啊。

怎麼辦?

需要一個可智能對話、可針對性一鍵拉羣、支持FAQ沉澱的智能客服系統。

這就是 B站小型的運營智能客服平臺。

B站小型的運營智能客服平臺架構

B站小型的運營智能客服平臺的整體架構如下:

圖片

包括以下幾部分構成:

  1. 對話界面
  2. 會話狀態機
  3. 數據源模型
  4. 統計彙總後臺
  5. 接入配置

對話界面

運營人員,更願意、更習慣使用企微原生功能實現對話,排斥 跳轉到第三方網頁或者在活動後臺開啓對話窗口的形式。

企微目前支持兩種對話形式:

  • 服務號提供對話頁面的形式
  • 應用號提供對話頁面的形式

由於受限於服務號的“無消息回調”,“人工座席與智能服務不能共存”等問題,最終B站小型的運營智能客服平臺選擇了應用號作爲人工客服的主要對話入口。

一個 人工客服的對話的例子如下:

圖片

整個的對話流程如下, 每一個對話都會帶有部門flag(小紅旗),實現了不同部門間的流程和數據的隔離。

圖片

圖中的代理是怎麼回事呢?

在測試環境進行調試時,微信無法訪問UAT環境內部域名,解決這個問題,團隊架了一層代理,開啓callback-api服務接口,將外網請求直接轉發到uat環境域名上。

會話狀態機

後端維護了一整套會話管理體系,

會話狀態主要如下:

  • 會話開啓
  • 對話中
  • 處理中
  • 已結束

狀態流轉如下圖:

圖片

會話狀態機維護一個狀態的延時消息隊列。 延時隊列 在用戶長時間無響應時,主動二次確認,並保留對會話自動關閉的機制。

每次會話在運營嚮應用號發消息時開啓。在聊天過程中,應用號與後端服務進行交互,執行一系列操作:

1 通過不同類型的消息事件觸發開啓會話。

2 自動收集會話信息。

3 進行會話識別。

4 進行會話FAQ匹配。

5 回覆用戶答案。

同時,應用號維護會話狀態,並對用戶的一鍵拉羣、結束會話等請求進行響應

數據源模型

數據源模型,主要是針對消息內容,進行合理回覆的底層數據源選型模型,目前本套智能客服回覆支持兩種模型,

  • 一種是搜索模式的數據源,比如基於ES搜索的,

  • 一種是生成模式的數據源,比如 類似ChatGPT的專業領域學習模型。

圖片

搜索模式的數據源

搜索模式的數據源 使用基於ES搜索的數據源模型, 採用Elasticsearch內置的分詞器(Tokenizer)和過濾器(Token Filter)對用戶問題進行拆分識別,並匹配FAQ庫中匹配度最高的答案,給予返回。

生成模式的數據源:

生成模式的數據源使用 NLP 自然語言處理和機器學習的問答處理模型, 對用戶問題進行預處理,對原始答案進行語料加工,回答的時候 根據上下文場景生成答案。

生成模式的數據源其特點就是問題回答更自然、更人性化。

生成模式的缺點在我們的智能客服項目中也體現的比較明顯,在FAQ庫、對話信息收集不足夠豐富的情況下,模型訓練的準確性並不高,甚至模型會有“自由發揮”空間,也就是所謂的大模型幻覺,如果按照甚至會導致運營的錯誤行爲。

解決大模型幻覺的一個策略是使用小模型、專業模型,在這裏引入simbert模型,其最大的優勢在於在特定專業學習領域裏,準確率比其他模型都高,

解決大模型環境的另一個策略,保證訓練數據的補給,我們也打通了一條離線數據補給流,對話界面收集到的FAQ及對話信息會通過離線任務同步給訓練模型,讓訓練模型不斷“精進自我”,提高回答的準確率。

BERT(Bidirectional Encoder Representations from Transformers)是一種基於 Transformer 結構的預訓練模型,由谷歌提出。BERT 通過大規模的無標籤文本語料進行預訓練,學習文本的語義表示。與傳統的單向語言模型不同,BERT 使用了雙向的 Transformer 結構,能夠同時考慮文本中的上下文信息,從而更好地捕捉文本的語義。BERT 在預訓練之後,可以通過微調(fine-tuning)的方式適應各種下游任務,如文本分類、命名實體識別、問答等。由於其出色的表現和通用性,BERT 在自然語言處理領域得到了廣泛的應用和認可。

SimBERT 是百度提出的一種基於 Transformer 結構的預訓練模型,它是在 BERT 模型的基礎上進行了改進和優化。SimBERT 的主要目標是提高文本相似度任務的性能,尤其是在中文文本相似度任務上的表現。SimBERT 在預訓練階段採用了大規模的文本語料進行自監督學習,然後通過微調或下游任務 fine-tuning 來適應特定的文本相似度任務。通過在大規模語料上的預訓練,SimBERT 能夠學習到豐富的語義表示,從而在相似度任務中取得優異的性能。

搜索模式的數據源和生成模式的數據源的切換

目前智能客服支持兩種數據模型的開關控制,隨時隨地隨意切換。

會話管理和統計彙總後臺

提供了一套可視化的管理後臺,完成對所有會話進行管理、review、統計、 。

會話管理界面:

圖片

圖片

會話詳情界面;

圖片

會話備註及狀態流轉;

圖片

直接一鍵上傳FAQ,

圖片

FAQ數據將供給給ES及語言訓練模型,真正實現全流程的閉環及可持續發展。

成果與展望

自系統上線以來,歷經幾次迭代,從支持單部門到開放至多部門,底層數據源從ES迭代到ChatGPT,智能客服已經成功實踐在以下應用中:

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

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

  1. 更加開放,可以利用企微應用號的回調能力開發智能客服系統,但同時也提供SDK服務,將能力提供給所有有需要的公司內部團隊使用,不限於幫助團隊靈活的進行對話界面的定製化開發。
  2. 接入平臺化,現在要接入整個智能客服系統,需要人工對接,後續把對接流程線上平臺化,增加一些審覈機制,就可以方便的實現服務一鍵接入。
  3. 對轉人工進行優化,如果團隊使用企微應用號形式進行接入,那麼就一定會受限於企微的既有功能,在用戶轉人工後,需要單獨拉羣間接實現搖人,整個對話無法在應用號內實現閉環解決,跳出帶來的一是用戶體驗,二是拉羣太多增加了管理成本。這一部分我們考慮“花錢”解決,比方說能否以公司身份出面向企微提需,提供更加靈活的功能。

案例2:1Wqps+ 高併發B站智能客服系統的設計與實現

40歲老架構師尼恩提示:這是一箇中型的案例, 應用場景是 解決 大量用戶客服的問題。

截至2022年,嗶哩嗶哩(Bilibili)是中國頗具影響力的在線視頻平臺之一,用戶量一直在穩步增長。根據官方公佈的數據,截至2021年底,B站的註冊用戶數量已超過5億,其中活躍用戶規模也持續擴大,達到了2.5億。

這一數字反映了B站在視頻分享、彈幕互動、二次創作等方面的持續吸引力,以及其在年輕人羣體中的廣泛普及程度。

值得注意的是,隨着在線視頻行業的快速發展和用戶需求的不斷變化,B站的用戶量也在不斷增長和優化。

尼恩提示,按照尼恩3高架構理論,5億億用戶, 吞吐量峯值1Wqps+ , 沒有任何問題的

B站智能客服系統的背景

B站昔日所用之客服系統,是外購而得,已用有數載。

然則,此外購之系統,卻存諸多弊病:

  • 穩定性乏善可陳,無法妥善延展與擴充,常見諸bug,難以迎擊瞬息萬變的客流高峯。
  • 與B站產品體系無法溝通,不易根據業務需求進行量身定製。
  • 因系統之邏輯陳舊,穩定性不佳,致效率低下,無法滿足提升客服效率之要求。

縱然曾思量採購新客服系統,但亦面臨一系列問題:

  • 昂貴之價格,尤其是在當前提倡降本增效之大環境下,爲一重要考量。
  • 更爲關鍵者,此係統仍不能與內部系統完美融合,無法支持業務之個性化定製。

因是,B站決意自力更生,啓動新客服系統之自研工程。

從0到1,打造一個全新的B站客服系統

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

業內調研

我們踏訪了一些客服系統領域中馳名有聲的企業,從業務和技術的雙重視角進行了深入探究。總結歸納,目前客服系統着重關注以下三大關鍵指標,讓我們逐一剖析:

  • 智能問答攔截率(也對應人工處理率):一款出色的客服系統,良好的智能問答功能至關重要:
  • 實現7*24小時不間斷在線服務,無需等待排隊,確保用戶隨時獲得迅速回應。
  • 快速應對用戶常問問題,提升效率,節省成本,達到更優用戶體驗和更高資源利用效率。
  • 能夠快速解答大部分簡單問題,同時爲複雜問題留有人工處理的空間,以提高整體問題解決效率和效果。
  • 用戶滿意度
  • 平均處理時長:主要指客服人員處理一次會話所需的平均時長

這些要緊的指標,爲未來的研發指引了明晰的方向。

內部訪談和體驗

首先,我們對運營團隊/各項功能團隊(質檢、輿情、機器人、工單、二線、數據等)進行了詳細的訪談,旨在深入瞭解他們的工作情況和需求。

其次,與各個團隊的交流中,我們深入探討了各團隊的具體工作內容和挑戰,收集了許多珍貴的經驗和建議,這對我們如何具體做好產品和之後推動系統的落地起到了巨大的作用。

最後,通過對現有系統的全面體驗,我們進一步瞭解了系統的運行情況和存在的問題,爲後續產品的優化和系統的落地提供了重要參考。

B站客服系統整體架構和核心業務流程

客服系統主要功能:

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

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

B站客服系統用戶入口

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

圖片

當用戶進入聊天框,首先會經過智能問答環節。

這個環節,就像是大門前的門衛一樣,站在用戶與問題之間,守護着信息的流通。

如果智能問答不能滿足用戶的需求,用戶還可以選擇進一步與人工客服交流,就像是在猶豫着是否要推開大門,踏入未知的領域一樣。

B站客服總體功能架構

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

圖片

B站客服總體功能架構主要包括以下幾個方面:

  1. 智能機器人客服:利用自然語言處理(NLP)和機器學習技術,實現對用戶提出的常見問題進行自動回答。這個系統就像是一位聰明的管家,能夠快速、準確地解答用戶的疑問,提高客服效率。
  2. 坐席調度系統:爲用戶提供人工客服服務,當智能問答無法解決問題時,用戶可以選擇與真人客服進行交流。這個系統需要包括在線客服接待、問題處理、對話記錄等功能,確保用戶能夠得到及時、個性化的解決方案。
  3. 客服管理後臺:提供給客服人員使用的管理後臺,包括客服工作臺、會話管理、用戶信息查看、問題記錄等功能,幫助客服人員更好地處理用戶問題、管理會話。
  4. 數據分析與監控:對客服系統的運行狀態進行監控和分析,實時統計客服工作指標、用戶反饋情況等數據,並提供報表和可視化界面,爲決策提供數據支持。
  5. 技術工單系統:負責客服系統的技術支持和維護工作,包括系統的升級、bug修復、性能優化等,確保客服系統的穩定運行和持續改進。

這些功能相互配合,構成了B站客服系統的整體架構,爲用戶提供了高效、便捷的客戶服務體驗。

B站客服核心流程

B站客服的核心流程,如下圖

圖片

B站客服核心功能設計和實現

我們將按照用戶一次完整的訪問客服系統所需的先後次序,介紹各個核心功能的設計與實現。

用戶從用戶入口進入,依次會經歷智能問答、客服坐席調度以及與客服聊天(工作臺)等核心功能。

智能機器人客服子系統

在客服的業務場景中,智能問答扮演着極爲重要的角色,其優勢堪稱人工無法比擬:

首先,它提供了24小時不間斷的在線服務,彷彿是一位不知疲倦的守護神;

其次,在高峯時期,用戶無需排隊等候,享受着猶如魚得水的暢快感受;

再者,對於用戶頻繁提出的問題,它能夠輕鬆給出迅速的回答,就像是一位經驗豐富的老師一般;

最後,在面對大部分簡單問題時,它能夠輕鬆自助解決,就如同得道高僧般遊刃有餘。

因此,智能問答系統的應用不僅能夠提升整體效率,降低成本,更能夠創造出更好的客戶體驗和更高效的資源利用。

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

  • 當匹配度較高時,系統會直接給出答案;

  • 而當匹配度只是中等時,系統則會提供一個“您想諮詢的問題可能是”的列表。

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

機器人問答-直接給出答案 機器人問答-“您想諮詢的問題可能是”
圖片 圖片

機器人問答技術調研

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

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

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

總的來說,檢索式和生成式兩種模型各有特點,各有優勢,在機器人問答系統中都有應用。

具體選擇哪種模型,往往需要根據具體的應用場景和需求來決定。

方案對比:

方案 場景 數據需求 準確性 性能 複雜性
檢索式 主要適用於對知識庫的檢索和篩選,比如問答系統、知識庫管理、智能客服等 依賴,需要豐富的結構化語料庫 本質上是從已有數據集中檢索最匹配的數據,準確性高 毫秒級
生成式 主要適用於需要生成自主文本或任務的應用場景,如對話生成、文本創作、任務調度等 依賴,無需結構化 生成的質量可能會受到模型的訓練數據和質量的限制,可能會出現不準確、無意義或不一致的輸出 秒級

在電商客服場景下,回答用戶問題的準確性至關重要,寧可選擇不回答也不能夠回答錯誤。

相比之下,生成式答案會受到多種因素的影響,導致結果不可控。

而檢索式答案來源於知識庫,可以提供更加準確的問題解答。

雖然檢索式在處理一些長尾問題或者冷門領域的問題時表現不佳,但是可以通過人工干預來豐富知識庫進行優化。綜合考慮到這些因素,最終選擇了檢索式實現。

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

向量搜索基本原理

給定一個向量集合:

圖片

和一個待查詢的向量:

圖片

從 個向量裏面找到距離 某種距離(比如 L2 距離)最近的 個向量。

其應用包括

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

這些東西(圖片、詞語、句子、視頻等)都可以用向量表示出來,如下圖:

圖片

這個事情看起來很簡單,但是當我們的數據庫變得特別大時,這件事情就變得比較困難了。

因此這裏就專門來研究如何做這樣的向量搜索。

Faiss簡介

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

Faiss(Facebook AI Similarity Search) 提供了一系列高性能的算法和數據結構,用於處理大規模的向量數據,特別是在推薦系統、語義搜索、圖像搜索等領域具有廣泛的應用。

Faiss支持基於內存和基於GPU的索引構建和查詢,能夠在大規模數據集上快速進行近鄰搜索、相似性匹配和聚類操作。通過高效的索引結構和算法設計,Faiss可以大大加速相似性搜索的過程,提高系統的性能和效率。

Faiss 總體使用過程可以分爲三步:

  1. 構建訓練數據(以矩陣形式表達);
  2. 挑選合適的 Index (Faiss 的核心部件),將訓練數據 add 進 Index 中;
  3. Search,也就是搜索,得到最後結果。

詳細解釋,即爲:首先根據原始向量構建一個索引文件,再根據索引文件進行查詢。初次查詢前需要進行train和add過程,後續若要進行索引的添加可以再次使用add添加索引,如下圖所示:

圖片

基於Faiss實現的智能問答

在實現檢索式的過程中,主要任務是找到與用戶提問語句最相似的問法,從而獲取對應的答案。這個過程包括以下步驟:

  • 數據準備:建立知識庫,包含標準問、相似問以及對應的答案。每個標準問有多個相似問,並對應唯一的答案。

圖片

  • 文本向量化:使用BERT模型將問題和相似問轉化爲向量表示。BERT模型採用預訓練方式,能夠將輸入的文本轉化爲對應的向量表示。公司已有基於社區數據訓練的bert-embedding服務,體驗效果滿足需求,因此使用該服務進行文本向量化。
  • 相似度計算:使用Faiss庫進行相似度計算。Faiss庫是一種針對聚類和相似性搜索的工具,爲稠密向量提供高效相似度搜索和聚類,支持十億級別向量的搜索,是目前最爲成熟的近似近鄰搜索庫。
  • 搜索匹配:將用戶問題向量傳入Faiss庫中,使用相似度計算方法對問題進行匹配,找到最相似的TopN問題向量(或者說相似問)。
  • 答案選取:根據相似度結果高低,直接給出問題對應的答案或者“您想諮詢的問題可能是”列表。如果相似度很低,則會轉接人工。

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

圖片

Faiss索引選擇實踐

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

  • 基於準確查找

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

  • 基於內存限制

a. 由於所有的Faiss索引都將向量存儲在內存中,如果內存是限制因素,那麼就需要將準確度和性能進行折衷:

b. 不關心內存則使用"HNSWx",通過"efSearch"參數平衡準確度和性能,該參數越大越準確,同時性能越差;

c. 有一點關心內存則使用"..,Flat","..."的含義是聚類,聚類後,"Flat"的含義是不壓縮,存儲大小與原始數據集相同,通過"nprobe"參數平衡準確度和性能;

d. 很關心內存則使用"PCARx,...,SQ8",PCARx指將維度降x,SQ8指將每8bit向量壓縮到1bit;

e. 非常關心內存則使用"OPQx_y,...,PQx",PQx使用輸出x-byte的量化器壓縮向量。x通常<= 64,對於較大的代碼,SQ通常是準確和快速的。OPQ是向量的線性轉換,使它們更容易壓縮;

  • 基於數據集限制

a. 如果低於1M個向量: "...,IVFx,...",直接倒排索引,x範圍在 4sqrt(N)~16sqrt(N)之間,N是數據集大小,x是k-means聚類後的數量;

b. 如果1M - 10M:"...,IVF65536_HNSW32,...",結合IVF和HNSW,用HNSW進行聚類;

c.如果10M - 100M: "...,IVF262144_HNSW32,...";

d. 如果100M - 1B: "...,IVF1048576_HNSW32,...";

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

部分代碼如下:


if len(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
        if 4 * sqrtN <= i <= 16 * sqrtN and N // 256 <= i <= N // 30:
            return i
        if i > 4096:
            return 512

大語言模型嘗試和探索

當前備受關注的大語言模型我們也進行了探索。‘

我們與公司AI部門合作,將客服與用戶的真實聊天記錄以及知識庫作爲訓練數據,給大模型進行訓練,並且進行了測試。

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

  • 情緒撫慰

圖片

  • 意圖識別

圖片

  • 自我決策

圖片

圖片

當然,我們也遇到了強制回答和回答無法解決問題的情況。

要解決問題,需要根據客戶的具體問題和訂單狀態來回答。

不過,大型語言模型是未來的趨勢,值得我們進一步探索。

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

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

新系統落地效果如何

在覈心指標上,新客服系統都取得了顯著的提升:

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

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

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

案例3:10Wqps 美團智能客服核心技術與實踐

40歲老架構師尼恩提示:這是一箇中型的案例, 應用場景是 解決 海量場景,海量用戶智能客服問題。

美團平臺涵蓋喫、住、行、遊、購、娛等200多個生活服務品類,目前,美團的年交易用戶量爲6.3億,服務了770萬生活服務類商家。

尼恩提示,按照尼恩3高架構理論,6.3億用戶, 吞吐量峯值10Wqps+

此外,在美團優選業務中還有一個很大的團長羣體。

面對以上這些需求,如果都是通過人力進行實現,顯然不符合公司長遠發展的目標,這就需要引入智能客服。

美團平臺智能客服提供了六大智能客服核心能力:

  • 問題推薦。

  • 問題理解。

  • 對話管理。

  • 答案供給。

  • 話術推薦。

  • 會話摘要。

這些能力旨在實現與用戶進行溝通的目標,即以低成本、高效率和高質量的方式提供服務。

美團智能客服的業務場景

在平臺服務的售前、售中、售後各個環節,都有大量信息諮詢、訂單狀態獲取以及申訴投訴等溝通訴求。

首先,我們看看日常生活中幾種最爲常見的客服場景。

  • 售前場景:比如消費者在平臺選擇入住酒店,對房型價格、酒店設施、入退房政策等,下單前都有很強的信息諮詢訴求。
  • 售中場景:比如外賣催單還沒到,添加備註不要辣、加開發票等諮詢等等,售前和售中場景主要發生在消費者和商家或平臺之間。
  • 售後場景:比如外賣場景投訴菜品少送、騎手送餐超時、要求退款等,酒店場景投訴酒店到店無法入住等,售後往往涉及到客服座席、消費者、騎手和商家,需要多方協同解決。
  • 辦公場景:比如IT、人力資源、財務、法務等諮詢,產運研對提供的接口產品的諮詢答疑,產品對銷售顧問的答疑,以及銷售顧問對商家的答疑等等。

智能客服平臺對話類型分類

智能客服背後的技術主要是以對話交互技術爲核心。

常見的對話任務可分爲閒聊型、任務型和問答型:

  • 閒聊型:通常是不關注某項特定任務,它的主要的目標是和人進行開放領域的對話,關注點是生成流暢、合理且自然的回覆。
  • 任務型:通常是幫助用戶完成某項任務指令,如查找酒店、查詢訂單狀態、解決用戶的退款申請等等。用戶的需求通常比較複雜,需要通過多輪交互來不斷收集任務所需的必要信息,進而根據信息進行決策,執行不同的動作,最終完成用戶的指令。
  • 問答型:側重於一問一答,即直接根據用戶的問題給出精準答案。問答型和任務型最本質的區別在於,系統是否需要維護一個用戶目標狀態的表示和是否需要一個決策過程來完成任務。

在技術實現上,通常又可以劃分爲檢索式、生成式和任務式:

  • 檢索式:主要思路是從對話語料庫中找出與輸入語句最匹配的回覆,這些回覆通常是預先存儲的數據。
  • 生成式:主要思路是基於深度學習的Transformer 架構,從大量語料中習得語言能力,根據問題內容及相關實時狀態信息直接生成回答話術。

40歲老架構師尼恩提升,關於Transformer 架構,請參見尼恩的大模型學習聖經 LLM大模型學習聖經:從0到1喫透Transformer技術底座

  • 任務式:就是任務型對話,通常要維護一個對話狀態,根據不同的對話狀態決策下一步動作,是查詢數據庫還是回覆用戶等等。

閒聊、問答、任務型對話本質都是在被動地響應用戶需求。在具體業務中還會有問題推薦、商品推薦等來主動引導用戶交互。

在美團的業務場景裏主要是任務型和問答型,中間也會穿插一些閒聊,閒聊主要是打招呼或者簡單情緒安撫,起到潤滑人機對話的作用。

用戶的溝通對象兩個:

  • 跟機器人溝通
  • 跟人工溝通。

跟人工溝通, 如果是找客服場景人工就是客服座席,如果是找商家場景人工就是商家。

跟機器人溝通, 機器人的能力主要包括:

  • 問題推薦
  • 問題理解
  • 對話管理
  • 答案供給。

衡量機器人能力好壞的核心輸出指標是:

  • 不滿意度, 衡量問題解決的好壞,

  • 轉人工率,度量能幫人工處理多少問題。

而在人工輔助方面,我們提供了話術推薦和會話摘要等能力,核心指標是ATT和ACW的降低,ATT是人工和用戶的平均溝通時長,ACW是人工溝通後的其它處理時長。

一個智能機器人多輪對話客服案例

什麼是智能機器人多輪對話?

智能機器人的多輪對話是指機器人與用戶之間進行連續交流,通過多個對話輪次來完成一個或多個任務或目標。

在多輪對話中,機器人需要能夠理解用戶的意圖、回答用戶的問題、提供相關信息,並根據對話的上下文進行適當的迴應和行動。

多輪對話通常涉及以下幾個關鍵方面:

  1. 意圖識別和理解: 機器人需要能夠識別用戶的意圖,理解用戶的提問或請求,並據此採取相應的行動。這可能涉及自然語言處理(NLP)和自然語言理解(NLU)技術。
  2. 上下文管理: 在多輪對話中,機器人需要能夠維護對話的上下文,以便理解用戶的意圖和回答問題。上下文管理可以包括跟蹤先前的對話歷史、記憶用戶提供的信息和狀態等。
  3. 信息檢索和知識庫查詢: 機器人可能需要訪問信息庫或知識庫,以獲取與用戶查詢相關的信息。這可能涉及到信息檢索和知識圖譜等技術。
  4. 回答和反饋生成: 機器人需要能夠生成自然、流暢的回答,以迴應用戶的提問或請求。這可能涉及到自然語言生成(NLG)技術。
  5. 對話流程管理: 機器人需要能夠管理對話的流程,引導用戶完成任務或目標。這可能涉及到對話管理和對話策略設計。

通過智能機器人能夠實現更加智能和人性化的多輪對話,從而提供更加個性化和高效的服務。

機器人多輪對話,用戶跟機器人溝通, 機器人的能力主要包括:

  • 問題推薦
  • 問題理解
  • 對話管理
  • 答案供給。

下面,是一個真實的多輪對話的例子。

當用戶進入到服務門戶後,機器人首先進行問題的推薦:

img

先選擇了一個推薦的問題“如何聯繫騎手”, 在下面的消息框中,“如何聯繫騎手” 的問題就會發送到後端, 機器人給出了聯繫方式致電騎手。

img

同時爲了進一步釐清場景,機器人進行問題的推薦:

img

這兩個問題,主要用於 詢問用戶是否收到了餐品,用戶可以進行下一輪的選擇。

img

當用戶選擇“還沒有收到”的時候,結合預計送達時間和當前時間,機器人再一次進行問題的推薦:

發現還未超時,給出的方案是“好的,幫用戶催一下”,或者是“我再等等吧”,

這時候,假設用戶選擇了“我再等等吧”。

img

機器人再做最後一次進行對話的推薦。

智能機器人能力1: 問題推薦

機器人多輪對話,用戶跟機器人溝通, 機器人的能力主要包括:

  • 問題推薦

  • 問題理解

  • 對話管理

  • 答案供給。

img

如前面多輪對話的例子所示,當用戶進入服務門戶後,機器人首先是要如何引導用戶精準地表達需求,這樣即可降低用戶迷失或者直接轉人工服務,也降低了若機器人不能正確理解時帶來的多輪澄清等無效交互。

該問題是一個標準的曝光點擊問題,它的本質是推薦問題。

img

我們採用了CTR預估任務經典的FM模型來作爲基礎模型,同時結合業務目標,期望用戶點擊的問題的解決方案能夠解決用戶問題,該問題最終定義爲“曝光、點擊、解決”問題。

上面提到 CTR預估任務模型和 FM模型, 尼恩給大家加點基礎的學習材料。

CTR(點擊率)預估模型是用於預測用戶對廣告、推薦內容等點擊的概率的模型。在在線廣告、推薦系統等領域,CTR預估是一項重要的任務,它能夠幫助系統根據用戶的歷史行爲和屬性,預測用戶是否會點擊某個廣告或推薦內容,從而優化廣告投放或內容推薦策略,提高點擊率和用戶體驗。

CTR預估模型通常基於大量的用戶行爲數據和廣告/內容屬性數據進行訓練,其中包括用戶的歷史點擊數據、瀏覽行爲、搜索記錄等,以及廣告或內容的特徵信息,如廣告的位置、展示次數、內容關鍵詞等。這些數據被用來構建模型的特徵,以便模型能夠學習到用戶行爲和廣告/內容之間的關聯。

常見的CTR預估模型包括但不限於:

  1. 邏輯迴歸模型(LR):LR模型是一種經典的二分類模型,常用於CTR預估任務。它通過線性加權的方式對各個特徵進行組合,然後通過sigmoid函數將結果映射到0到1之間,表示點擊的概率。
  2. 因子分解機模型(FM):FM模型通過建模特徵之間的交互關係來進行預測,具有較好的性能和可解釋性。它通過對特徵的交叉項進行因子分解來建模特徵之間的交互關係,從而降低了模型的複雜度和參數量。
  3. 深度學習模型:近年來,隨着深度學習技術的發展,越來越多的深度學習模型被應用於CTR預估任務,如多層感知機(MLP)、卷積神經網絡(CNN)、循環神經網絡(RNN)等。這些模型能夠自動地學習到數據中的複雜特徵和模式,從而提高了預測的準確性。

CTR預估模型的選擇通常取決於具體的場景和需求,需要綜合考慮模型的性能、效果、可解釋性等因素,並根據實際情況進行調優和選擇。

一個典型的推薦系統架構如下圖所示:
在這裏插入圖片描述

一般會劃分爲召回排序兩層。

  • 召回負責從百萬級物品中粗選出千級數量物品,常用算法有協同過濾、用戶畫像等,有時候也叫粗排層
  • 排序負責對召回層召回的千級物品進行精細排序,也叫精排層

CTR,Click-Through-Rate,也就是點擊率預估,指的是精排層的排序。所以 CTR 模型的候選排序集一般是千級數量。

CTR 模型的輸入(即訓練數據)是:大量成對的 **(features, label) **數據。

何爲 features?可以分爲如下四類:

  1. 用戶本身特徵,例如用戶的年齡、性別等;
  2. 用戶行爲特徵,例如點擊過的物品、購買過的商品等;
  3. 上下文特徵,例如用戶登錄設備(IOS or Android)、當前時間等;
  4. 待排序物品特徵,例如物品 ID、物品被點擊次數、物品的點擊率等;

可以看到,上面所有的 features 都是我們能夠收集到的信息,其中有離散型特徵(如物品 ID),也有連續型特徵(如點擊率)。

但是,計算機只能處理數字編碼,所以需要對 features 進行編碼。常用的編碼手段有:

  • 離散型特徵使用 one-hotembedding
  • 連續型特徵可以不處理,也可以分段離散化,再使用 one-hot 編碼;

關於 one-hot 和 embedding,這裏簡單介紹一下。One-hot 編碼和 Embedding 是常用於表示分類數據的兩種方法。

  1. One-hot 編碼
    • 概念:將分類變量表示爲一個由 0 和 1 組成的向量,其中每個維度代表一個可能的取值,只有對應分類的維度爲 1,其他維度爲 0。
    • 優點:簡單直觀,易於理解和實現;適用於分類變量取值較少的情況。
    • 缺點:維度災難,當分類變量的取值較多時,導致生成的向量維度過高,佔用內存空間大。
  2. Embedding
    • 概念:通過將每個分類變量映射到一個低維的連續向量空間中,實現對分類變量的表示。這些向量通常在模型訓練過程中學習得到,每個維度代表一個特徵。
    • 優點:能夠更好地捕捉分類變量之間的相似性和關聯性;能夠處理高基數分類變量,降低維度災難問題。
    • 缺點:需要大量的訓練數據來學習嵌入向量;可能需要調節向量維度和嵌入表大小等超參數。

選擇使用 One-hot 編碼還是 Embedding 取決於數據的特點、模型的需求以及實際情況。

  • 一般來說,如果分類變量的基數較低且取值稀疏,可以考慮使用 One-hot 編碼;

  • 如果分類變量的基數較高且取值稠密,或者希望通過模型學習到變量之間的關聯性,可以考慮使用 Embedding。

40歲老架構師尼恩提升,關於Embedding,請參見尼恩的大模型學習聖經 LLM大模型學習聖經:從0到1喫透Transformer技術底座

再看 CTR(點擊率)預估模型 裏邊的 FM模型:

FM模型是一種經典的CTR(點擊率)預估模型,用於預測用戶對物品的點擊率。FM模型通過建模特徵之間的交互關係來進行預測,具有較好的性能和可解釋性。

FM模型的全稱是Factorization Machines(因子分解機),其核心思想是將特徵的高維交互關係通過低維的因子分解來表示,以降低模型的複雜度和參數量。FM模型主要包括兩部分:一階特徵和二階交叉特徵。

  1. 一階特徵:一階特徵指的是每個特徵的單獨作用,即特徵本身的權重。在FM模型中,一階特徵由線性模型表示,對每個特徵分配一個權重,用於衡量該特徵對預測結果的貢獻程度。
  2. 二階交叉特徵:二階交叉特徵表示特徵之間的交互關係,即特徵對之間的組合效應。FM模型通過對特徵的交叉項進行因子分解來建模特徵之間的交互關係,這種因子分解的方式可以減少參數量,提高模型的泛化能力。

FM模型通過將一階特徵和二階交叉特徵相加得到最終的預測結果,其中二階交叉特徵的計算通過特徵的隱向量表示進行。FM模型相比於傳統的線性模型,能夠更好地捕捉特徵之間的高階交互關係,從而提高了預測的準確性。

CTR(點擊率)預估模型和FM(Factorization Machine)模型的關係,二者是點擊率預估領域常用的兩種模型,它們之間存在密切的關係:

  1. FM 模型
    • FM 模型是一種經典的用於處理稀疏特徵的模型,它能夠有效地捕捉特徵之間的交叉關係。
    • FM 模型通過學習特徵的隱向量表示,以及特徵之間的交叉項來建模特徵之間的關聯性。
    • FM 模型的優點在於參數規模較小、計算效率高,尤其適用於處理高維稀疏特徵。
  2. CTR 預估模型
    • CTR 預估模型是用於預測用戶對廣告、推薦內容等點擊行爲的模型,通常用於在線廣告投放、推薦系統等場景。
    • CTR 預估模型的目標是根據用戶的歷史行爲和特徵信息,預測用戶對當前內容的點擊概率。
    • CTR 預估模型通常會使用多種模型來進行預測,其中包括 FM 模型、LR(邏輯迴歸)模型、DNN(深度神經網絡)模型等。

關係

  • FM 模型可以作爲 CTR 預估模型中的一個組成部分,用於處理特徵之間的交叉關係。
  • 在 CTR 預估任務中,FM 模型通常會和其他模型結合使用,例如將 FM 模型的輸出作爲其他模型的輸入,以提高整體預測性能。
  • 由於 FM 模型具有參數規模小、計算效率高等優點,因此在 CTR 預估任務中得到了廣泛的應用,成爲了該領域的經典模型之一。

在CTR預估任務中,FM模型被廣泛應用於點擊率預測、廣告推薦等場景,通過對用戶行爲和物品屬性的建模,實現了對用戶行爲的精準預測,從而提高了廣告點擊率和推薦效果。

最終的美團的智能機器人問題推薦 的模型是結合多目標學習的ESSM-FM模型,對有效交互的轉化率、轉人工率和不滿意度等指標上都帶來了提升。

什麼是 ESSM-FM 模型?

ESSM-FM(Enhanced Semantic Matching and Feature Fusion Model)是一種用於推薦系統的模型,結合了語義匹配和特徵融合的方法。該模型旨在提高推薦系統中用戶與物品之間的匹配準確度,從而提高推薦的效果。

ESSM-FM模型主要包含兩個組成部分:語義匹配模塊和特徵融合模塊。

  1. 語義匹配模塊:該模塊通過對用戶和物品的語義信息進行建模,實現了更深層次的語義匹配。這通常涉及到使用詞嵌入(Word Embedding)技術來表示用戶和物品的文本信息,並通過神經網絡模型來學習用戶和物品之間的語義關係。
  2. 特徵融合模塊:該模塊將語義匹配模塊中得到的語義特徵與傳統的特徵進行融合,以提高模型的綜合表現。這些傳統特徵可以包括用戶的行爲歷史、物品的屬性信息等。特徵融合通常採用一些融合策略,比如加權平均或者拼接等,將不同來源的特徵整合到一個統一的特徵向量中。

ESSM-FM模型在推薦系統中的應用可以有效地提升推薦的準確性和覆蓋度,尤其是在處理複雜的用戶行爲和物品屬性時具有一定的優勢。該模型的結合了語義匹配和特徵融合的思想,使得推薦系統能夠更好地理解用戶和物品之間的關係,從而提供更精準的推薦結果。

那麼,ESSM-FM 模型 與 FM模型的關係是什麼呢?

大致如下:

ESSM-FM 模型(Entire Space Multi-Task Model with Factorization Machine)是在 FM 模型(Factorization Machine)基礎上進行了改進和擴展的一種模型。以下是它們之間的關係:

  1. 基於 FM 模型的改進

    ESSM-FM 模型是對 FM 模型的改進和擴展,它在 FM 模型的基礎上引入了更多的特徵交叉和任務間的信息共享,以提高模型的性能和泛化能力。

  2. 特徵交叉

    FM 模型主要處理低階特徵交叉,即二階特徵組合,而 ESSM-FM 模型引入了更高階的特徵交叉,可以處理更復雜的特徵關係。

  3. 任務間信息共享

    ESSM-FM 模型還引入了多任務學習的思想,可以同時處理多個相關但不同的任務,通過任務間的信息共享和交互來提高模型的性能。

  4. 模型結構

    在模型結構上,ESSM-FM 模型通常會包含 FM 模型的部分作爲基礎模型,並在此基礎上添加更多的層和模塊,以實現特徵交叉和任務間信息共享的目的。

總的來說,ESSM-FM 模型可以看作是對 FM 模型的一種擴展和改進,通過引入更多的特徵交叉和任務間信息共享,提高了模型的表達能力和泛化能力,適用於更復雜的場景和任務。

智能機器人能力 2: 問題理解

img

這個例子背後的機器人是怎麼工作的呢?

首先當用戶輸入“如何聯繫騎手”的時候,問題理解模塊將它與知識庫中的拓展問進行匹配,進而得到對應的標準問即意圖“如何聯繫騎手”。

然後,對話管理模塊根據意圖“如何聯繫騎手”觸發相應的任務流程,先查詢訂單接口,獲取騎手電話號碼,進而輸出對話狀態給到答案生成模塊,根據模板生成最終結果,如右邊的紅框內容所示。

在這個過程中涉及到要先有意圖體系、定義好Task流程,以及訂單的查詢接口,這些都是業務強相關的,主要由各業務的運營團隊來維護。

那麼,對話系統要做的是什麼呢?

一是將用戶的輸入與意圖體系中的標準問進行匹配,

二是完成多輪交互裏面的調度。

img

問題理解是將用戶問題與意圖體系進行匹配,匹配到的拓展問所對應的標準問即用戶意圖。

問題理解的工作過程實際是要做召回和精排兩件事情。

  • 召回 用現有檢索引擎實現,
  • 精排 對召回的千級物品進行精細排。

美團自研的智能客服系統是從2018年開始搭建的,在建設的過程中,我們不斷地將業界最先進的技術引入到我們的系統中來,同時根據美團業務的特點,以及問題理解這個任務的特點,對這些技術進行適配。

2018年之前,問題理解使用了DSSM 雙塔模型。

這裏的問題理解 和 搜索引擎和搜索廣告類似,主要還是涉及在兩個方面:召回和排序。

  • 召回負責從百萬級物品中粗選出千級數量物品,常用算法有協同過濾、用戶畫像等,有時候也叫粗排層
  • 排序負責對召回層召回的千級物品進行精細排序,也叫精排層

DSSM 雙塔模型,Deep Structured Semantic Model 由微軟研究院提出,利用深度神經網絡將文本表示爲低維度的向量,應用於文本相似度匹配場景下的一個算法。因爲效果不錯並且對工業界十分友好,被各大廠廣泛應用在推薦領域。

2018年年底,問題理解從DSSM 雙塔模型升級到 BERT 模型。

當2018年底BERT(參見《美團BERT的探索和實踐》一文)出現的時候,我們很快全量使用BERT替換原來的DSSM模型。

後面,又根據美團客服對話的特點,我們將BERT進行了二次訓練及在線學習改造,同時爲了避免業務之間的干擾,以及通過增加知識區分性降低噪音的干擾,我們還做了多任務學習(各業務在上層爲獨立任務)以及多域學習(Query與拓展問匹配,改爲與拓展問、標準問和答案的整體匹配),最終我們的模型爲Online Learning based Multi-task Multi-Field RoBERTa。

經過這樣一系列技術迭代,我們的識別準確率也從最初不到80%到現在接近90%的水平。

img

智能機器人能力3: Task流程設計

理解了用戶意圖後, 就對應到了一系列的標準問, 如下圖:

img

每一個標準問,都對應一個task流程,是跟業務強相關的,需要由業務的運營團隊來進行定義。

如右邊任務流程樹所示,我們首先提供了可視化的TaskFlow編輯工具,並且把外呼、地圖以及API等都組件化,然後業務運營人員可以通過拖拽的方式來完成Task流程設計。

對話引擎在與用戶的真實交互中,要完成Task內各步驟的匹配調度。

比如這個例子裏用戶如果不是點選”可以但影響就餐了…”這條,而是自己輸入說“還行,我要部分退款”,怎麼辦?

這個意圖也沒有提前定義,這就需要對話引擎支持Task內各步驟的模糊匹配。

我們基於Bayes Network搭建的TaskFlow Engine恰好能支持規則和概率的結合,這裏的模糊匹配算法複用了問題理解模型的語義匹配能力。

img

這是另外一個例子,在用戶問完“會員能否退訂”後,機器人回覆的是“無法退回”,雖然回答了這個問題,但這個時候用戶很容易不滿意,轉而去尋找人工服務。

如果這個時候我們除了給出答案外,還去釐清問題背後的真實原因,引導詢問用戶是“外賣紅包無法使用”或者是“因換綁手機導致的問題”,基於順承關係建模,用戶大概率是這些情況,用戶很有可能會選擇,從而會話可以進一步進行,並給出更加精細的解決方案,也減少了用戶直接轉人工服務的行爲。

這個引導任務稱爲多輪話題引導,具體做法是對會話日誌中的事件共現關係以及順承關係進行建模。

如右邊圖所示,這裏原本是要建模句子級之間的引導,考慮到句子稀疏性,我們是將其抽象到事件之間的引導,共現關係我們用的是經典的協同過濾方式建模。

另外,考慮到事件之間的方向性,我們對事件之間的順承關係進行建模,公式如下:

img

並通過多目標學習,同時考慮點擊指標和任務指標,如在非轉人工客服數據和非不滿意數據上分別建模順承關係,公式如下:

img

最終,我們在點擊率、不滿意度、轉人工率層面,都取得了非常正向的收益。

img

美團平臺涵蓋喫、住、行、遊、購、娛等200多個生活服務品類,當用戶是從美團App或點評App等綜合服務門戶入口進入服務時,需要先行確定用戶要諮詢的是哪個業務,這裏的一個任務是“判斷用戶Query是屬於哪個業務”,該任務我們叫做領域識別。

  • 若能明確判斷領域時,則直接用該領域知識來解答;

  • 當不能明確判斷時,則還需要多輪對話交互與用戶進行澄清。

比如用戶輸入“我要退款”,在多個業務裏都存在退款意圖,這個時候就需要我們先判斷是哪個業務的退款意圖,如果判斷置信度不高,則給出業務列表讓用戶自行選擇來進行澄清。

領域識別模型主要是對三類數據建模:各領域知識庫的有標數據、各領域大量弱監督無標數據和個性化數據。

  1. 依據從各領域知識庫的有標數據中學習得到的問題理解模型信號,可以判斷用戶輸入屬於各業務各意圖的可能性。
  2. 我們注意到除了美團App、點評App等綜合服務入口涉及多個業務外,還有大量能夠明確業務的入口,比如說訂單入口,從商品詳情頁進來的入口,這些入口進來的對話數據是有明確業務標籤信息的。因此,我們可以得到大量的弱監督的各業務領域的數據,基於這些數據我們可以訓練一個一級分類模型。
  3. 同時,有些問題是需要結合用戶訂單狀態等個性化數據才能進一步明確的。比如“我要退款”,多個業務裏都會有。因此,又要結合用戶狀態特徵一起來訓練一個二級模型,最終來判斷用戶的輸入屬於哪個業務。

最終,該二級領域識別模型在滿意度、轉人工率以及成功轉接率指標上都取得了非常不錯的收益。

智能機器人能力4: 答案供給

img

售後客服場景通常問題較集中,且問題的解決多依賴業務內部系統數據及規則,通常是業務部門維護知識庫,包括意圖體系、Task流程和答案等。

但在售前場景,知識多來自於商戶或商品本身、用戶體驗及評價信息等,具有用戶問題開放、知識密度高、人工難以整理答案等特點。

比如去哪個城市哪個景點遊玩,附近有哪些酒店,酒店是否有浴缸,酒店地址在哪裏等,都需要諮詢”決策”,針對這些訴求,我們通過智能問答來解決諮詢以及答案供給問題。

img

智能問答就是從美團數據中習得答案供給,來快速回答用戶的問題,基於不同的數據源,我們建設了不同的問答技術。

  • 針對商家基礎信息,比如問營業時間、地址、價格等,我們通過圖譜問答(KBQA)來解決。利用商家基礎信息構建圖譜,通過問題理解模型來理解問題,進而查詢圖譜獲取準確的答案。
  • 針對社區數據,即商戶詳情頁中“問大家”模塊的用戶問用戶答的社區數據,構建社區問答(Community QA)能力,通過對用戶問題與問大家中的”問答對”的相似度建模,選擇相似度最高的作爲答案,來回答用戶的一些開放性問題。
  • 針對UGC評論數據以及商戶政策等無結構化數據,構建文檔問答(Document QA)能力,針對用戶問題利用機器閱讀理解技術從文檔中抽取答案,類似我們小時候語文考試中的閱讀理解題,進一步回答用戶的一些開放性問題。

最後,針對多個問答模塊給出的答案,進行多答案來源的答案融合排序,來挑選最終的答案,此外這裏還考察了答案真實性,即對“相信多數認爲正確的則正確”建模。

這部分的詳細介紹大家可以參考《美團智能問答技術探索與實踐》一文。

智能機器人能力5: 話術推薦

img

在客服座席職場調研過程中發現,座席在與用戶的對話聊天中經常回復相似甚至相同的話術,他們一致期望提供話術推薦的能力來提高效率。

此外,建議與商家直接溝通,下用戶與商家直接溝通會使得解決問題更高效,而溝通效率不僅影響到消費者的體驗,也影響到了商家的經營。

總之,無論是客服座席還是商家,都有很強的話術推薦訴求。

那麼,話術推薦具體要怎麼做呢?

常見的做法:

  • 先準備好常用通用話術庫,

  • 部分座席或商家也會準備個人常見話術庫,

  • 然後系統根據用戶的Query及上下文來檢索最合適的話術來推薦。

我們根據調查發現,這部分知識庫維護得很不好,既有業務知識變更頻繁導致已維護的知識很快不可用因素,也有座席或商家本身意願不強的因素等。

另外,針對新客服座席或者新商家,可用的經驗更少。因此我們採用了自動記憶每個座席及其同技能組的歷史聊天話術,商家及其同品類商家的歷史聊天話術,根據當前輸入及上下文,預測接下來可能的回覆話術,無需人工進行整理,大大提升了效率。

我們將歷史聊天記錄構建成“N+1”QA問答對的形式建模,前N句看作問題Q,後1句作爲回覆話術A,整個框架就可以轉化成檢索式的問答模型。

在召回階段,除了文本信息召回外,我們還加入了上文多輪槽位標籤,Topic標籤等召回優化,排序爲基於BERT的模型,加入角色信息建模,角色爲用戶、商家或者座席。

img

整個架構如上圖所示,分爲離線和在線兩部分。

另外上線後我們也加入了一層CTR預估模型來提升採納率。

當前多個業務的話術推薦平均採納率在24%左右,覆蓋率在85%左右。話術推薦特別是對新座席員工價值更大,新員工通常難以組織話術,通過採納推薦的話術可以來縮減熟練週期,觀測發現,3個月內座席員工的平均採納率是3個月以上座席員工的3倍。

美團智能客服的對話平臺“摩西”

構建一個怎麼樣的對話平臺,才能提供期望的沒有NLP能力的團隊也能擁有很好的對話機器人呢?

首先是把對話能力工具化和流程化。

如下圖所示,系統可分爲四層:應用場景層、解決方案層、對話能力層、平臺功能層。

img

  • 應用場景層:在售前應用場景,一類需求是商家助手,如圖中所列的美團閃購IM助手和到綜IM助手,需要輔助商家輸入和機器人部分接管高頻問題能力;還有一類需求是在沒有商家IM的場景需要智能問答來填補諮詢空缺,比如圖中所列的酒店問一問和景點問答搜索;另外售中、售後以及企業辦公場景,各自需求也不盡相同。
  • 解決方案層:這就要求我們有幾套解決方案,大概可以分爲智能機器人、智能問答、商家輔助、座席輔助等。每個解決方案的對話能力要求也有所不同,這些解決方案是需要很方便地對基礎對話能力進行組裝,對使用方是透明的,可以拿來即用。
  • 對話能力層:前面也進行了相應的介紹,六大核心能力包括問題推薦、問題理解、對話管理、答案供給、話術推薦和會話摘要。
  • 平臺功能層:此外,我們需要提供配套的運營能力,提供給業務方的運營人員來日常維護知識庫、數據分析等等。

其次,提供“一攬子”的解決方案,還需要針對處在不同階段的業務提供不同階段的解決方案。

  • 有些業務只希望維護好常用的問答,能回答高頻的問題就好,那麼他們只需要維護一個入門級的機器人,只需要在意圖管理模塊來維護它的意圖,意圖的常見說法以及答案就可以了。
  • 而對於有運營資源的團隊,他們希望不斷地去豐富知識庫來提升問答能力,這個時候可以使用知識發現模塊,可以自動地從每天的日誌裏面發現新意圖及意圖的新說法,運營人員只需要每天花一點時間來確認添加及維護答案即可,這是一個進階的業務方。
  • 還有一些高級的業務方希望調用他們業務中的API來完成複雜問題的求解。這個時候他們可以使用TaskFlow編輯引擎,在平臺上直接註冊業務的API,通過可視化拖拽的方式來完成Task編輯。

此外, 爲了進一步方便更多的業務介入,我們也提供了一些閒聊、通用指令、地區查詢等官方技能包,業務方可以直接勾選使用。另外,隨着我們不斷在業務中沉澱,也會有越來越多的官方行業技能包。整體方向上是逐步讓業務方使用的門檻變得越來越低。

參考文獻:

https://tech.meituan.com/2021/09/30/artificial-intelligence-customer-service.html

https://blog.csdn.net/bilibili_TC/article/details/135608021

https://www.jianshu.com/p/fd4ed6eeb6f2

https://mp.weixin.qq.com/s/Ic0hJ_fIstsCkEg5p5-xeQ

https://www.pinecone.io/learn/series/faiss/vector-indexes/
https://towardsdatascience.com/similarity-metrics-in-nlp-acc0777e234c

https://www.pinecone.io/learn/series/faiss/faiss-tutorial/

https://www.pinecone.io/learn/series/faiss/vector-indexes/

https://towardsdatascience.com/similarity-metrics-in-nlp-acc0777e234c

https://www.pinecone.io/learn/series/faiss/faiss-tutorial/

說在最後:有問題找老架構取經

毫無疑問,小模型應用架構、大模型應用架構師,非常錢途, 這個代表未來的架構。

前面講到,尼恩指導的那個一個成功案例,是一個9年經驗 網易的小夥伴,拿到了一個年薪近80W的大模型架構offer,逆漲50%,那是在去年2023年的 5月。

不到1年,小夥伴也在團隊站穩了腳跟,成爲了名副其實的大模型架構師。回想當時,尼恩本來是規劃指導小夥做通用架構師的( JAVA 架構、K8S雲原生架構), 當時候爲了他的錢途, 尼恩也是 壯着膽子, 死馬當作活馬指導他改造爲 大模型架構師。

沒想到,由於尼恩的大膽嘗試, 小夥伴成了.

不到1年時間,現在 職業身價翻了1倍多,現在P8級,可以拿到年薪 200W的offer了。

應該來說,小夥伴大成,實現了真正的逆天改命。

從4月份開始,尼恩團隊用積累了20年的深厚的架構功力,開始編寫《LLM大模型學習聖經》,幫助大家進行一次真正的AI架構穿透,幫助大家穿透AI架構。初步的規劃包括下面的內容:

  • 《LLM大模型學習聖經:從0到1喫透Transformer技術底座》
  • 《LLM大模型學習聖經:從0到1喫透大模型的基礎實操》
  • 《LLM大模型學習聖經:從0到1喫透大模型的頂級架構》

本文,屬於是第2篇《LLM大模型學習聖經:從0到1喫透大模型的基礎實操》裏邊的業務場景和生產案例方面的內容 ,後面的文章,尼恩團隊會持續迭代和更新。 並且錄製配套視頻。

當然,除了大模型學習聖經,尼恩團隊深耕技術。

多年來,用深厚的架構功力,把很多複雜的問題做清晰深入的穿透式、起底式的分析,寫了大量的技術聖經:

  • Netty 學習聖經:穿透Netty的內存池和對象池(那個超級難,很多人窮其一生都搞不懂),
  • DDD學習聖經: 穿透 DDD的建模和落地,
  • Caffeine學習聖經:比如Caffeine的底層架構,
  • 比如高性能葵花寶典
  • Thread Local 學習聖經
  • 等等等等。

上面這些學習聖經,大家可以通過《技術自由圈》公衆號,找尼恩獲取。

大家深入閱讀和掌握上面這些學習聖經之後,一定內力猛漲。另外,如果學好了之後, 沒有面試機會,怎麼辦?可以找尼恩來幫扶、領路。尼恩已經指導了大量的就業困難的小夥伴上岸.前段時間,幫助一個40歲+就業困難小夥伴拿到了一個年薪100W的offer,小夥伴實現了 逆天改命

另外,尼恩也給一線企業提供 《DDD 的架構落地》企業內部培訓,目前給不少企業做過DDD 的內部諮詢和培訓,效果非常好。

在這裏插入圖片描述

技術自由的實現路徑:

實現你的 架構自由:

喫透8圖1模板,人人可以做架構

10Wqps評論中臺,如何架構?B站是這麼做的!!!

阿里二面:千萬級、億級數據,如何性能優化? 教科書級 答案來了

峯值21WQps、億級DAU,小遊戲《羊了個羊》是怎麼架構的?

100億級訂單怎麼調度,來一個大廠的極品方案

2個大廠 100億級 超大流量 紅包 架構方案

… 更多架構文章,正在添加中

實現你的 響應式 自由:

響應式聖經:10W字,實現Spring響應式編程自由

這是老版本 《Flux、Mono、Reactor 實戰(史上最全)

實現你的 spring cloud 自由:

Spring cloud Alibaba 學習聖經》 PDF

分庫分表 Sharding-JDBC 底層原理、核心實戰(史上最全)

一文搞定:SpringBoot、SLF4j、Log4j、Logback、Netty之間混亂關係(史上最全)

實現你的 linux 自由:

Linux命令大全:2W多字,一次實現Linux自由

實現你的 網絡 自由:

TCP協議詳解 (史上最全)

網絡三張表:ARP表, MAC表, 路由表,實現你的網絡自由!!

實現你的 分佈式鎖 自由:

Redis分佈式鎖(圖解 - 秒懂 - 史上最全)

Zookeeper 分佈式鎖 - 圖解 - 秒懂

實現你的 王者組件 自由:

隊列之王: Disruptor 原理、架構、源碼 一文穿透

緩存之王:Caffeine 源碼、架構、原理(史上最全,10W字 超級長文)

緩存之王:Caffeine 的使用(史上最全)

Java Agent 探針、字節碼增強 ByteBuddy(史上最全)

實現你的 面試題 自由:

4800頁《尼恩Java面試寶典 》 40個專題

免費獲取11個技術聖經PDF:

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章