智慧客服的核心技術-對話系統

吐槽一句知乎的文章編輯體驗太差了！在部落格釋出了相同內容：

對話系統：與真人進行對話的系統。智慧客服的核心技術-對話系統對話系統：與真人進行對話的系統。

這裡首先用案例介紹一下對話系統的基本概念，然後重點介紹任務型對話系統的。

基本概念

這裡舉一個小例子，結合一起來理解對話系統的相關概念。

使用者 (User)：

指產品或服務的使用者。

對話代理人 (Agent)：

對話代理人既可以是真人，如客服人員、客戶支援代表，也可以是虛擬人，如機器人。在對話系統內部，因其設計目的不同，Agent既可用於解決單領域 （single-domain） 問題，也可用於解決多領域 （multi-domain） 問題。

發言 (Utterance)：

在對話中，對話代理人與使用者任何一方說出的任意一句話。

對話輪次(Turns)：

一來一回合稱一輪turn，來回多次稱為多輪對話。

會話(Session)：

由一個使用者發起的某次多輪對話。會話是對話代理人與使用者之間發生的一次連續對話，不同對話系統可以有自己對「連續」的定義。

對接渠道 (Channel)：

對話代理人本身只負責對話邏輯，並不包含對接渠道（對話載體），如釘釘、美洽、飛書、Slack 等等。

意圖 (Intent)：

意圖是系統能夠識別的最小的使用者目的，是系統決策的基本元素之一。只有在識別使用者發言背後的含義後，機器人才能決定回覆什麼。劇本中的每一章節由使用者意圖的識別和機器人採用的回答構成。從發言的角度出發，意圖約等價於發言中的動詞。如「下週我要飛去上海」中的「飛」就是意圖。

實體/槽值/槽位填充物 (Entity/Slot value/Slot filler)：

實體和領域息息相關，如票據這樣的實體幾乎不會出現在點餐機器人系統中；有些實體則比較通用，比如時間、地點、數字等等。和領域相關的實體需要單獨定義，通用實體則可以由平臺統一支援。

槽位 (Slot)：

盛放實體/槽值資訊的容器為槽位，資訊本身為槽位填充物 （slot filler）。想象填寫一張表格，表中的每個空就是槽位，填寫的內容就是槽位填充物。 槽位和實體的區別是什麼？ 實體指的是從單句發言中提取到的資訊，而槽位儲存整個會話過程中提取到的所有資訊，前者是後者的資料來源，槽位儲存的資訊會被用於後續對話系統決策的過程中。

動作 (Action)：

理解使用者的意圖後，對話代理人除了回覆訊息外，可能需要幫助使用者去做一些動作，比如：修改日程、登出賬號等。不同領域的對話代理人需要執行的動作不同，需要定製化開發。在設計中，機器人回覆訊息通常也會被認為是一種動作。

對話系統的應用場景

問答

常見於智慧客服系統，問題和答案都比較固定，背

後常常與知識庫掛鉤。

甚至可以將問答系統理解成是用對話的方式快速檢索使用文件中的 frequently asked question （FAQ）。 在問答場景中，使用者明確地知道與之對話的不是真人，因此也不會使用複雜的對話結構，

主要以單輪對話的形式呈現，使用者佔主導

。

助手

聊天場景指的是像人一樣與人交談，市面上存在的系統有賢二機器僧、微軟小冰等。理論上，

聊天不存在固定內容

，天南海北都可以侃。著名的圖靈測試就是用於驗證機器是否可以讓人無法分辨他是在和人聊天還是在和機器聊天。 在聊天場景中，對話系統面對的挑戰與前二者相比要複雜很多，如自然語言理解能力、記憶能力、知識面，甚至語氣、性格等等，但它提供的對話體驗也最接近與真人交談。

聊天

聊天場景指的是像人一樣與人交談，市面上存在的系統有賢二機器僧、微軟小冰等。理論上，

聊天不存在固定內容

，天南海北都可以侃。著名的圖靈測試就是用於驗證機器是否可以讓人無法分辨他是在和人聊天還是在和機器聊天。 在聊天場景中，對話系統面對的挑戰與前二者相比要複雜很多，如自然語言理解能力、記憶能力、知識面，甚至語氣、性格等等，但它提供的對話體驗也最接近與真人交談。

對話系統的常見構建方式

基於規則的對話系統

“table” data-size=“normal” data-row-style=“normal”>

優點：

1。 開發速度快、成本低、易整合

2。 行為穩定、可解釋，安全可控風險小

3。 能傳送多媒體資訊、圖片、影片 推理時間短、速度快

缺點：

1。 維護成本高，需要人工維護規則和優先順序，複雜度高了以後難以管理

2。 不具備自然語言理解能力，同義語句無法觸類旁通，需要窮舉規則

3。 新增語言支援成本高

基於語料的對話系統

e data-draft-node="block" data-draft-type="table" data-size="normal" data-row-style="normal">

e data-draft-node="block" data-draft-type="table" data-size="normal" data-row-style="normal">

優點：

1。 系統維護成本低，訓練完後無需其它維護成本

2。 具備自然語言理解能力，能識別同義語句的不同表達

3。 新增語言支援成本低，因為開源社群中已存在不同自然語言預訓練好的特徵提取工具

缺點：

1。 開發週期長、成本高、需要大量訓練資料

2。 訓練資料問題可能導致系統行為不穩定，風險不可控，garbage in garbage out 線上模型推理時間長，佔用資源多

3。 不支援多媒體訊息，只能傳送文字或文字合成的語音

混合型對話系統

將基於規則和基於語料的方案融合。一個典型的例子：使用統計模型做句子中的內容提取，對話行為識別，使用規則生成回答。這種做法

既可以保持對內容的語義級別理解，又能夠控制回答的風險，避免生成行為的不穩定

。

優點：

1。 規則和語料訓練的模型可以互補：加入了規則進行約束，相比純語料模型更可控

2。 相比規則模型具有一定的自然語言理解能力，可能可以面對一些規則無法cover的問題

缺點：

1。 規則和語料訓練的模型衝突的情況可能影響會話。

2。 規則和模型的trade-off

混合型對話系統的常見結構

接下來，介紹一下混合、任務型對話系統的經典架構。

任務型對話系統pipline型經典架構

任務型的agent代替使用者做一系列的操作以完成使用者的任務。

agent完成某一項任務要做的一系列操作，需要一攬子資訊。

比如說：

使用者需要點一杯咖啡（意圖），agent需要知道以下幾個資訊（槽位）：咖啡型別，大小，冰度，才能完成點咖啡的任務。

因此在對話過程中，通過歷史對話狀態，判斷當前是什麼對話狀態（意圖、槽位對應的槽值/有哪些槽位資訊已知/還有哪些槽位需要問使用者）；

並且根據當前的對話狀態，去生成下一步的系統動作（比如回答使用者的問題、和使用者確認槽值、詢問下一個槽位等等）；

直到完成使用者任務的所有資訊都明確了，完成當前對話。

語音識別Automatic Speech Recognition (ASR)

ASR 模組負責將使用者輸入的音訊轉化為文字，得到使用者發言的文字。

⚠️ 如果對話系統僅需支援文字對話則無需 ASR 模組，因此在架構圖中用虛線表示

自然語言理解Natural Language Understanding (NLU)

NLU 模組負責從使用者的發言中解析出對話中包含的關鍵資訊，如領域、意圖、實體等等。

輸入：代表使用者輸入的Utterance，X_n

輸出：U_n=(I_n,Z_n)，其中I_n為意圖，Z_n為槽值對。

主要模型任務：

領域識別任務：文字分類

意圖識別任務：文字分類

槽位識別任務：命名實體識別

可以單個任務訓練多個模型，也可以多工聯合訓練一個模型。

對話管理Dialogue Management (DM)

DM 模組負責管理當前對話的狀態 （State，S_{n}） 和策略 （Policy），包括對話狀態追蹤DST和對話策略DP兩個部分。

對話狀態追蹤Dialogue State Tracking(DST)

對話狀態包括使用者與agent之間的歷史聊天記錄以及關鍵資訊。DST根據對話歷史，維護當前對話狀態。

輸入：U_n=(I_n,Z_n)，A_{n-1}，S_{n-1}

輸出：S_{n}=\{G_n,U_n,H_n\}其中G_n為使用者目標，H_n為聊天曆史

分為兩種情況：

1.具有預定義的槽名稱和值

，每一輪DST模組試圖根據對話歷史找到最合適的槽值對。可以將DST簡化為分類問題。

2.沒有固定的槽值列表

，因此DST模組嘗試直接從對話上下文中查詢槽值或根據對話上下文生成槽值。

對話策略Dialogue Policy(DP)

策略是根據狀態輸出回覆的函式，根據當前對話狀態輸出下一步系統動作。

輸入：S_{n}=\{G_n,U_n,H_n\}其中G_n為使用者目標，H_n為聊天曆史，可以包括

雙方的對話歷史

系統和外部注入的事件

表單 （form） 資訊

…

輸出：A_{n}=\{A_i,V_i\}其中A_i,V_i為第i輪對話的attribute和value

常見的對話策略，如劇本、監督學習、增強學習。

劇本 (Story)

劇本是在對話設計中設定的模板，提前設定好使用者在不同意圖下機器人執行相應的動作，比如：

story：

steps：

- intent： arrange_meeting

- action： update_calendar

- action： utter_arrange_meeting

上面這個劇本說的就是：機器人在識別使用者發言中的意圖是舉辦會議 （arrange_meeting） 時，先執行更新日曆 （update_calendar） 的動作，再執行回覆使用者 （utter_arrange_meeting） 的動作。

通常一個會話對應一個劇本，比較靈活的對話系統可以支援在一個會話中透過上下文切換 （context switch） 演繹多個劇本。

強化學習(Reinforce learning)

基本概念review

目標是找到一個最優的策略 Policy 使得agent獲得的 Reward 最多。

Policy based

模型：直接訓練策略（actor），把state輸入到actor中，輸出action的分佈

策略，如何判斷actor的好壞（訓練目標）：

根據當前actor去完成一整輪，得到一整輪的reward（具有隨機性，需要轉化為求reward的期望）

演算法：梯度上升法求解最大化reward的引數。

Value based

模型：間接求，learn critic

策略：把state輸入critic，輸出看到當前state以後到episode結束的累積reward的期望是多少=value function

Value function又有兩種：

只決定於state：

決定於state和action：

3.Policy based+Value based=Actor Critic

模型：互動的過程具有很大的隨機性，直接根據互動的過程可能結果不會好，不要直接跟環境的reward學，而是讓actor跟critic學。

RL如何應用到對話系統中？

對話系統目的是利用agent管理客服對當前使用者訊息進行什麼樣的答覆。形成完整的答覆需要和NLG的配合，RL需要給NLG傳入的東西就是RL需要學習的部分。所以DST估計的對話狀態=agent狀態，透過RL學習策略，針對預設的候選動作集，選擇agent的動作，NLG再根據agent的動作和狀態生成話術。

一般任務型的對話系統，是封閉域的任務，給定了有限個數的意圖/槽位類別，動作空間是離散的。

自然語言生成Natural Language Generation (NLG)

當對話代理人做完決定後，需要把它想回復的內容轉化成自然語言，這一步驟就由 NLG 模組負責完成。

輸入：A_{n}=\{A_i,V_i\}

輸出：Y_{n}=\{y_1,y_2,y_3...\},y_i表示第i輪對話的回覆response

NLG 有兩種方案：基於模板和基於統計。

基於模板（可控性比較強）

基於模板的生成方案中，對話代理人的所有發言都由人工設計而成，然後將劇本中的上下文資訊，如槽位填充物，填入模板。舉例如下：

const template = “What time do you want to leave %s”

const slotCityOrig = “Beijing”

const uterrance = fmt。Sprintf（template， slotCityOrig）

通常為了讓回覆不那麼呆板，會為同一個回答預置多個模板，然後在回覆時透過一些策略選取一個。

基於統計（表達更豐富）

基於統計生成的目標就是在大量標註語料訓練後，能夠自動生成含義相同、表述不同的發言，如：

\1。 Au Midi is in Midtown and serves French food。

\2。 There is a French restaurant in Midtown called Au Midi。

基於統計的生成方案需要大量的訓練資料，這些資料本身很難獲取，難度體現在兩方面：

在某領域的對話代理人上線之前，很難獲得和生產環境相近的資料

以上面的句子為例，如果要訓練一個點餐機器人，那麼要找到包含所有飯店、地點和菜色組合的語料幾乎不可能

因此有一種比較常用的技術叫“去詞化”delexicalization，即將句子中的實體替換成實體型別，如：

\1。 $restaurant_name is in $neighborhood and serves $cuisine food。

\2。 There is a $cuisine restaurant in $neighborhood called $restaurant_name。

在訓練時使用實體型別，預測時將實體真實取值填入即可，後者被稱為 relexicalize。

Text To Speech (TTS)

TTS 模組負責將對話代理人的回覆發言轉化成語音。

⚠️ 如果對話系統僅需支援文字對話則無需 TTS 模組，因此在架構圖中用虛線表示

端到端的對話系統

受開放域對話領域啟發，使用模型以端到端的方式而不是分模組最佳化的方式構建任務型對話系統。

大多數端到端任務型對話系統採用seq2seq框架，但端到端任務型對話系統因為要和知識庫互動，不等於seq2seq模型。

類pipeline型：把pipeline當作一個大模型整體訓練

純端到端型

端到端任務式對話系統與知識庫互動結構化問答的區別：

前者以任務完成為目標，任務型對話，完成一次訂票，需要透過查資料庫進行答覆（比如還有多少張票，有什麼時候的票），但是答覆本身（是否訂票成功）不是資料庫知識，而結構化的問答的答案是回答有沒有票。

對比

任務型pipeline對話系統和純端到端對話系統的對比如下：

參考資料

對話系統調研報告

近期任務型對話系統綜述以及百度UNIT，理論和實踐，我全都要！（手動鰲拜）

一起來看看最新的對話狀態追蹤（DST）模型