對話系統的簡單綜述及應用智能客服

2 評論 15631 瀏覽 111 收藏 30 分鐘

本篇文章主要講解了對話系統的邏輯,以及如何實現應用智能客服。

“天貓精靈,放歌”,“送你一首好聽的歌《XXX》”,《XXX》音樂響起……

相信有天貓精靈的用戶對此場景都不陌生,或者語音操作其他智能音箱設備,比如操作小愛同學”小愛同學,放歌“。我們都了解如何語音操作智能音箱,通過喚醒詞(天貓精靈、小愛同學),然后再說明意圖(放歌),然后智能音箱被喚醒后,根據說明意圖進行相關響應。

智能音箱作為對話系統的一種常見應用,還有我們生活常見到的對話系統應用:Siri、Echo、Bixby、小冰… 對話系統的應用到處可見,但我們對對話系統了解多少以及如何應用實踐呢?

本文主要講解對話系統的邏輯以及如何實現應用智能客服。

目錄:

1. 對話系統的定義及發展

2. 對話系統的概述

2.1、對話系統的組件架構

3. 智能客服的實現

3.1、智能客服的概述

3.2、信息檢索

3.3、知識庫

3.4、設計與評價

4. 總結

5. 參考文獻

一、對話系統的定義及發展

對話系統,也稱會話代理,一種模擬人類與人交談的計算機系統,即智能agent,旨在可以與人類形成連貫通順的對話,通信方式主要有語音/文本/圖片,當然也可以手勢/觸覺等其他方式。

我們說對話系統的發展,一般都會從早期經典的聊天機器人ELIZA開始(聊天機器人術語ChatterBot最早由Michael Loren Mauldin在1994年提及),ELIZA最出名的是以心理治療師的方式行事。不過對話系統的技術發展主要分為三個階段:

  • 第一代:基于符號規則、模板,80年代末開始,目前依然使用,主要依賴專家人工制定的語 法規則和本體設計,容易解釋和修補,但過于依賴專家系統,跨領域的擴展性不足,數據用來設計規則而不是學習,限定狹窄領域;
  • 第二代:基于數據驅動的淺層學習,90年代開始(對話策略的強化學習也是這個時候研究出來),目前商用主流,主要是通過數據學習對話系統的統計參數,但不容易理解和修補,難擴展,模型和表示不夠強大,不是端到端,難以擴大規模;
  • 第三代:基于數據驅動的深度學習,近些年開始,目前研究主流,與第二代一樣,數據學習模型的參數,不過神經模型和表示更強大,端到端學習變得可行(即完全數據驅動,模型相當黑盒子),但仍然難以理解和調試更新系統,目前尚無成功商業案例;

二、對話系統的概述

我們先看一段生活常見的對話:

從上面的對話,會發現我們的對話,展示我們人類三個基本的智力活動:

  • 閑聊:語言學家稱之為寒暄,示例對話A段落,閑聊一般沒什么實質性內容,主要是拉近人與人之間的關系,建立信任;
  • 知識型問答:示例對話B段落,根據提問(多少錢?),一問一答,單輪對話,主要是提供信息;
  • 任務型對話:示例對話C段落,根據意圖(購買手機),聯系上下文,多輪對話,圍繞意圖進行對話,直至完成任務;

從我們對話活動中,我們可以發現,我們說話一般都帶有目的行為,比如我想買一部手機,言語行為就是購買手機,也就是我們所謂的言語行為理論。言語行為理論,指的是,語言不是用來陳述事實或描述事物的,而是附載著言語者的意圖。

根據對話活動,我們的對話引擎架構可以分為三個層次,如下圖(圖源自周明老師的自然語言對話引擎的分享內容):

閑聊功能,一般可以通過網上語料庫,找到最相似的句子的回復當作回復;問答功能,一般通過資源知識庫(問答庫/知識圖譜等)進行回答;對話功能,一般通過識別意圖,填充信息槽,完成任務;

對話活動中,我們發現會有單輪、多輪對話的概念。單輪對話,容易理解,也就是一問一答,與上下文無關;多輪對話,也就是多次對話,圍繞意圖,聯系上下文,直至任務完成結束話輪。

目前任務型的多輪對話的實現,主要是基于有限狀態的架構和基于框架的架構,也是目前商用主流,當然還有信息狀態的架構(包括馬爾可夫決策過程的概率化模型),基于端到端(神經模型)的架構。

基于有限狀態的架構和基于框架的架構,主要是基于腳本方法,一種動態記憶模式,將我們生活場景進行框架化,比如,我們去餐館就餐時,一般活動次序的框架(即腳本):進餐館、入座、點菜、用餐、付賬、離開。所以,我們對話活動可以根據意圖框架進行信息抽取,填充相應的槽,即可完成對話任務所需要的信息,做出相應的反饋。

基于有限狀態的架構,也是最簡單的架構,系統采用系統主動會話,控制著與用戶的會話,向用戶提出一系列問題,忽略(或曲解)任何非直接的回答,并繼續詢問下一個問題,比如用戶查詢天氣的任務,系統會詢問用戶的查詢城市/時間,用戶如果回答不是系統提問的問題,則忽略回答繼續重復提問該問題。當然,系統一般也會有萬能指令的策略,可以在對話的任何地方使用,以便用戶請求相應的操作,比如我們常見的萬能指令:幫助(返回幫助菜單)、人工/人工客服(轉接人工客服)。

不過完全系統主動、有限狀態的對話管理架構的限制過于嚴格,要求用戶準確回答系統剛提問的問題,使得對話笨拙;用戶可能一次性回復幾個問題,或者用戶主動提問,所以就出現了會話的主動權在系統和用戶之間切換的混合主動,所以就出現目前一種常用的混合主動的對話架構就是依靠框架本身的結構來引導對話,即基于框架的架構。

基于框架的架構,對話系統詢問用戶問題,然后填充框架里的槽,但是同時也允許用戶通過提供填充框架中的其他槽的信息來引導對話。這樣,基于框架的架構可以去除有限狀態的架構對用戶提供信息的順序的加強嚴格約束;當然,遇到多個任務需要多個框架處理的時候,系統必須能夠對給定的輸入填入哪一個框架模板的哪一個槽進行排歧,然后將對話控制轉換到該模板。

下面我們來看看一個基于框架的對話過程(圖源自周明老師的自然語言對話引擎的分享內容):

對話過程,實際上就是對用戶輸入的話,檢測意圖是什么,如果檢測不到,系統就判斷可能是聊天,然后通過聊天的引擎進行溝通。如果檢測到意圖,比如知道用戶是要訂旅館,那么就有對應的訂旅館的對話狀態表記錄目前進行的狀態及要填充哪些信息。系統知道要填什么信息的時候,就會生成相應的問題讓用戶回答,用戶回答完之后系統再把信息抽取過來填充到這個表里,直到所有的信息全部填充完畢,就完成了這個任務的對話過程。

這里就涉及到了對問題的理解,問題中有哪些信息要抓取出來,還有對話管理,比如狀態的轉移,slot的填充或者更改,選擇一個新的slot開始對話,以及如果要決定填充哪個slot的時候,怎么生成對話可以讓用戶很自然地回答這個問題,從而獲得系統所需要的信息。

2.1 對話系統的組件架構

我們現在已經對對話系統有了整體的認知,接下來講講我們目前常見的對話系統的組件架構。

上圖為對話系統的典型架構,六個組件,語音識別和理解組件從輸入中抽取意義,生成器和TTS組件將意義映射到語言,對話管理器與具有任務領域知識(如電商領域知識庫)的任務管理器一起對整個過程進行控制。

用戶說話,對話系統的語音識別器(ASR)將輸入轉為文本,文本由自然語言理解組件(NLU)進行語義理解(主要為分詞、詞性標注、命名實體識別、句法分析、指代消解、語義解析),接著對話管理器分析語義信息,保持對話的歷史與狀態,并管理對話的一般流程,通常,對話管理器聯系一個或多個任務管理器(知識庫),自然語言生成器根據對話管理器的對話策略生成對話的文本,最后文本通過語音合成器(TTS)渲染輸出;其中,對話系統的主體是對話管理器,它是管理對話狀態和對話策略的組件。

組件介紹:

  • 語音識別:ASR(Automatic?Speech?Recognition)一般包括四大塊:信號處理、聲學模型、解碼器、后處理,首先采集聲音,進行信號處理,將語音信號轉化到頻域,從N毫秒的語音提出特征向量,提供給聲學模型,聲學模型負責把音頻分類成不同的音素,接著解碼器得出概率最高一串詞串,最后的后處理就是把單詞組合成容易讀取的文本。簡單的說,就是接受音頻輸入,返回一個轉錄的詞串;當然,對話系統中,ASR系統一般都做了定制的優化,同時,一般對話系統還要求ASR系統返回句子的置信度,用來決定是否詢問用戶來確認該回答這樣的任務;
  • 自然語言理解:NLU(Natural Language Understanding)產生適合對話任務的語義表示(語義表示常見有一階邏輯、語義網絡、概念依存、基于框架的表示),主要通過分詞、詞性標注、命名實體識別、句法分析、指代消解等進行語義解析產生句子意義(即理解文本是什么意思),進行意圖識別(一般通過動賓短語,事件提及,比如查詢天氣),從中抽取槽的填充值,進而完成語義表示;

分詞:將句子切分詞序列,詞是承載語義的基本單元。中文自動分詞被認為是中文自然語言處理中的一個最基本的環節,比如句子“我愛中國”,切分為“我/愛/中國”;

詞性標注:識別詞的詞性,描述一個詞在上下文的作用,比如名詞、動詞、形容詞;

命名實體識別:也稱作專名識別,是指識別文本中具有特定意義的實體,主要包括人名、地名、機構名、專有名詞等;

句法分析:分析詞與詞之間的結構關系,確定句法結構,比如主謂賓關系;

指代消解:決定哪些實體被哪些語言表述所指代的任務,比如句子“香蕉熟了,把它給大家吃了”,句子中的它指的是香蕉;

  • 自然語言生成與語音合成:NLG(Natural Language Generation)組件選擇需要向用戶表達的概念,計劃如何用詞句表達這些概念,并賦予這些詞必要的韻律,TTS(Text To Speech)組件接受這些詞句及其韻律注解,并合成波形圖,生成語音;
  • 對話管理器:DM(Dialog Management)為對話系統的主體,控制著對話的架構和結構,從ASR/NLU組件接受輸入,維護一些狀態,與任務管理器(知識庫)交互,并將輸出傳遞給NLG/TTS模塊;

對話系統主要有三大模塊:對話上下文(Dialog Context)、對話狀態跟蹤(Dialog State Tracking)和對話策略(Dialog Policy)。

對話上下文(DC):記錄對話的領域、意圖和詞槽數據,每個領域可能包含多個意圖的數據, 一般以隊列的形式存儲;

對話狀態跟蹤(DST):記錄T-1狀態與當前時間T的狀態,即會結合上下文,確定當前對話狀態,同時會補全或替換詞槽;

對話策略(DP):根據對話狀態和具體任務決定要執行什么動作,比如進一步詢問用戶以獲得更多的信息、調用內容服務等;

三、智能客服的實現

自然語言處理(NLP)技術一直以來被認為是成熟度相對較低的AI技術分支,不過,盡管NLP在開放領域環境中表現不佳,但對于限定場景來說,NLP及其背后的知識圖譜技術卻能發揮出巨大價值。智能客服就是NLP最常見的應用之一,也是對話系統最常見的應用之一。

作為企業客戶關系管理(CRM)的重要組成部分,客服是連接企業與客戶的重要橋梁,極大地影響著企業的銷售成果、品牌影響及市場地位。但是,長久以來,客服行業都存在諸多痛點,客服人員流動性大、培訓成本高、客服難以把控、大量重復性問題過度消耗人工客服,同時,如何提升售前轉化,如何優化客服流程,如何從客服數據中發現企業業務問題等,都是各類企業面臨的普遍問題。因為這些普遍問題的存在,智能客服應運而生。

根據國內客服行業的第三方報告(下圖),智能客服正在以40%-50%的比例替代人工客服工作,AI將為智能客服廠商釋放500-800億市場空間,所以一直以來,大量企業布局智能客服行業。

3.1 智能客服的概述

智能客服,也就是我們所說的客戶維護的智能服務,比如我們常見的淘寶小蜜、京東JIMI。

目前受限于NLP算法水平的限制,現在智能客服在實際使用中更多是發揮輔助作用。目前智能客服最常見的形式就是在人工客服系統基礎上,擴展出智能客服的功能,最常見的功能為單輪問答、功能對話、人機協作。

人機協作,一般是智能客服優先回答問題,解決不了再轉人工,也就是智能客服解決一定的高頻簡單問題,疑難問題轉接人工客服。

根據智能客服目前常見的定位單輪問答,知識庫問答的技術本質也是搜索引擎相似的技術,都是信息檢索。

3.2 信息檢索

信息檢索(Information Retrieval,IR)主要是尋找從文檔集中獲取可用信息的模型和算法,用戶輸入一個表述需求信息的查詢字段,系統回復一個包含所需要信息的文檔列表,比如我們平時所用的百度、谷歌搜索。

目前大多IR系統都是基于組合語義的一種極端版本,用戶查詢內容表示為檢索詞表達的信息需求,檢索詞進行詞義排歧、同義擴展等處理(比如同義詞擴展,可通過WordNet同義集),生成對應的向量,查詢向量與文檔向量(彼此向量通過權重處理,比如TF-IDF)計算相似度(可通過余弦計算,越接近1越相似,越接近0越獨立),如下圖。

其中,文檔表示被系統索引及提供給檢索的文本單元,文檔列表表示用于滿足用戶需要的一組文檔,檢索詞指文檔列表中出現的詞匯項,可用來當索引。

我們可以看到上圖的信息檢索架構返回的是文檔列表,而智能客服問答返回的是答案內容,我們來看看問答與信息檢索的區別:

我們可以看到,問答集成了知識表示、信息檢索、自然語言處理和智能推理等技術,畢竟用戶希望的是獲取一段特定信息,問題的答案,需求的解決方案,比如用戶問題怎么重置密碼。

這個時候,我們返回的應該是用戶問題重置密碼的解決方案答案,所以智能客服的問答應用信息檢索的時候,做了相應的調整,檢索返回的是答案(即計算概率最大的候選答案,可以理解為所謂的推薦),同時一般會在問題查詢處理的時候,增加問題分類模塊,也就是某個問題是什么類型,可以針對類型更好的回答,分類器可以通過標注類型的對話數據進行訓練。

3.3 知識庫

現在我們了解了智能客服模型的實現,但對話系統如果沒有語料庫,還是不會對話,正所謂巧婦難為無米之炊。語料庫也就是我們智能客服所說的知識庫。知識庫可以來自我們整理的知識圖譜或者問答庫等,知識庫的難點在于數據的冷啟動、數據的清洗及整理。

數據的冷啟動,也就是生成知識庫的原始數據有沒有的問題(數據冷啟動同樣影響信息檢索模型的訓練),不過智能客服一般都是限定于領域,應用于自身企業的服務,前期客服都是人工服務,所以我們一般可以積累人工對話的數據作為知識庫的原始數據(一般是選擇一定周期內的數據,具有通用性)。

數據的清洗及整理,也就是有了原始數據后如何生成完整可讀的知識庫。我們常見的一種知識庫就是所謂的問答庫(即問題答案對,當然,一般還會有其他標簽,比如人工標注的問題類型)。問答庫的生成,我們可以通過原始對話數據對同一標識的對話(表示同一用戶與人工客服的完整對話),根據對話身份ID的不同分別對同一ID的話段通過N-gram拼接起來(主要通過詞袋出現的unigram、bigram、trigram,一般到trigram,太少句子不通順,太多計算量大,畢竟N元模型的大小幾乎是N的指數函數即O(|V|^N),V為詞匯量,然后通過N-gram拼接算法把N-gram片段拼接起來即可,一般可以通過NLTK工具包處理),成為一段較為通順的句段,最后再經過人工審核及標注,形成完整可讀的問答知識庫。

其中,詞袋指的是一段文本(比如一個句子或是一個文檔)可以用一個裝著這些詞的袋子來表示,這種表示方式不考慮文法以及詞的順序;N-gram,即N元語法,指的是文本中連續出現的n個語詞,N元語法模型是基于(n-1)階馬爾可夫鏈的一種概率語言模型,通過前面出現的n-1個單詞預測下一個單詞,通過n個語詞出現的概率來推斷語句的結構;當n分別為1、2、3時,又分別稱為一元語法(unigram)、二元語法(bigram)與三元語法(trigram)。

下圖為上述對話C段落,經過N-gram拼接處理后,再經過人工審核標注的問答庫示例:

不過,由于問答庫的問題單一性,用戶采用相似問法提問時,可能由于模型等問題找不到對應的答案,導致用戶不滿。即使我們對問題進行擴展等泛化處理,采用松弛模式允許匹配忽略部分文本的結果,但會引起一些不正確的結果,也引起用戶的不滿。所以為了提高問題的準確性,我們可以通過種子模式,即采用整理好的知識庫的問題關鍵詞,在原始或清洗后的對話數據集上進行搜索,查看用戶常見的問法,進行問答擴展,增加問題的相似問法,比如上圖的問答庫的問題“購買一部2000元的小米手機”,可擴展相似問法“推薦一部2000元的手機,品牌不限”。

當然,知識庫越豐富越好,畢竟越豐富則覆蓋的業務范圍問題越廣,解決用戶需求的可用性越好,就像我們人類一樣知識面越廣,則能解決更多問題,能力越好。

3.4 設計與評價

智能客服不是開放式的聊天對話系統,而是基于特定業務領域和業務場景的對話系統,目的是快速解決用戶的需求,一個最理想的對話系統就是用最少代價就能幫助用戶實現目標的系統,所以智能客服應以用戶為中心的設計原則,用戶滿意度至關重要。

設計:

智能客服由于自身的目的性,應當根據自身的業務場景選擇相應的對話策略、提示、錯誤信息反饋等設計原則。

常見的設計要點:

  • 研究用戶和業務:分析用戶畫像,以及調研用戶常見的問題,獲知用戶的潛在問題進行相應的推薦引導,以及個性化回答用戶;比如每個用戶進入智能客服,界面的問題引導都不一樣;
  • 對話策略:問題高相似即反饋答案,一定程度相似可反饋相似的幾個問題,收斂引導用戶提問,低相似的問題可引導用戶重新提問或引導轉接人工客服;同時,增加閑聊庫,保證用戶對話的順暢性,避免部分用戶閑聊無應答。當然,還有快速收斂,用戶輸入時通過聯想提問顯示提示問題引導用戶選擇提問,一般也會有萬能指令的策略,可以在對話的任何地方使用,以便用戶請求相應的操作,比如我們常見的萬能指令:幫助(返回幫助菜單)、人工/人工客服(轉接人工客服);
  • 對話數據完整性:用戶轉接人工客服后,保證用戶與系統對話的數據同時轉接至人工客服對話窗口,方便人工客服快速了解用戶需求,也避免用戶再次提問,提高客服接線率和時間效率,提高用戶滿意度;
  • 對設計進行迭代:數據監控,根據指標數據分析優化;根據用戶滿意度的意見進行優化;知識庫的維護及更新(包括模型自主學習);

評價:

用戶滿意度是我們智能客服的衡量標準,用戶可以在系統界面滿意度問卷進行顯性反饋,這是我們直接拿到的用戶真實評價。但反饋用戶滿意度畢竟需要操作成本,很多用戶都不會去反饋,所以我們拿到直接的滿意度評價比較少,更多會結合其他衡量指標進行綜合評價系統。

評價一般有外在和內在的評價指標,外在指標指的是我們業務可見的一些指標,比如智能客服的問題解決率、人工客服系統的接線率/會話時長等衡量指標;內在指標指的是模型算法的一些指標,信息檢索常見的評價指標:準確率(precision)、召回率(recall)、F-測度值??筛鶕唧w業務場景選取適合的評價指標。

總結

當前受限NLP算法水平的限制,目前智能客服更多是輔助人工客服,未來,想進一步替代人工客服,NLP技術理應做到實現更好的多輪對話建模以及個性化回復,從而理解用戶的真實意圖及對話自然。

畢竟對于智能客服來說,重要前提就是準確理解用戶問題,同時可以聯系上下文,與用戶進行自然地多輪對話,理解用戶意圖,解決用戶問題,這樣才能更好進一步替代人工客服。

參考文獻:

《自然語言處理綜論》(第二版)

https://36kr.com/p/5136136.html

https://www.leiphone.com/news/201703/6PNNwLXouKQ3EyI5.html

https://www.msra.cn/zh-cn/news/features/ming-zhou-conversation-engine-20170413

 

作者:鉛筆小葵(微信號:gaokaikui ?知乎專欄:鉛筆小葵),產品經理,負責產品從0到1的開發,曾任Java工程師,參與后臺開發。歡迎大家互相交流關注。

本文由 @鉛筆小葵 原創發布于人人都是產品經理。未經許可,禁止轉載。

題圖來自Unsplash,基于CC0協議

更多精彩內容,請關注人人都是產品經理微信公眾號或下載App
評論
評論請登錄
  1. 我也在做這塊 :mrgreen: ,個人感觸最深的是智能客服機器人與普通機器人的最大區別是,用最少的節點,最簡單易懂的話術在最短時間內幫用戶完成需求。

    來自廣東 回復
    1. 我也是做這一塊的,方便交流交流嗎?

      回復