Categories
程式開發

微軟小冰:如何構建人格化的對話系統


01 如何構建基本的對話系統?

1. 廣義對話系統分類

微軟小冰:如何構建人格化的對話系統 1

人機對話系統是在不斷迭代演化的:之前大家對物理世界的交互主要通過信件,烽火傳令等等,慢慢的進化到人機,通過鍵盤、電腦跟虛擬的物理世界進行交互,極大的加速了人類對信息的獲取。隨著互聯網的興起,極大的加速了人類對信息的獲取,但是到了移動互聯網時代,我們積累了大量的信息和知識,以及社會行業分工的更加具體化,大量的長尾知識隱含在互聯網的各個角落中。由於信息非常的龐大,很難直接通過一個非常高效的方法檢索到。因此,我們下一個可能潛在的方向:是否有可能存在一個agent ( 智能體 ),能幫助我們更便捷的、更快速的獲取信息。

大家可能會發現,以前更多的是在搜索引擎上搜索各種各樣的信息,但是慢慢的會嘗試著在知乎、抖音、微博等渠道獲取信息,這是為什麼呢?這是因為大量垂域化的內容,相對來講比較專業、比較有深度,大家形成了這種體驗,在瀏覽某個頁面之後,突然又有了一個意圖,就會留在平台上,再做進一步搜索。所以我們的搜索行為會從搜索引擎遷移到各個垂域。目前,市場上也有非常多的產品,包括百度也在往feed流轉化。大家打開手百的頁面,會發現原來就是一個搜索框,現在他們把搜索框往上拉了,下面多了很多feed流的內容。在這個維度上講,現在信息的豐富度越來越大,我們的假設是類似於這種搭建內容社區的維度,把更多的信息組織起來,用更好的搜索引擎推薦的做法,給到用戶更好的獲取信息的渠道。那麼,是不是可能有另外一種形式的交互?而且是以這種自然語言的方式去問一個agent,能不能幫到我去獲取背後的物理世界或者虛擬世界的信息,這其實就是Conversation AI的主要方向。 Conversation AI主要包括三個方向:

  • 第一個方向是Task Completion,這也是業界做的比較多的,包括客服機器人和各種代理等等,都定位在這個方向。這裡存在一個問題,就是它的Scalability ( 可擴展性 ) 不是特別夠。當你在做A場景的時候,可能產品設計思路、框架部分是能夠復用的,但是你的模型、意圖分類、serving,每個場景都會不一樣。
  • 第二個方向是做Information和Answers的攫取,有點類似於百度知道或者知乎上如何評價XX?這種話題。如果要搭建類似這樣的系統,需要有很好的社區對內容進行維護,來盡可能的讓知識庫以及問題答案的豐富度和多樣性在一個比較高的水平,它的局限性也在這個地方。
  • 第三個方向是General Conversation ( 閒聊 ),也是小冰主要關注的方向。而這裡比較大的問題是( Dynamic Context/Complex ) 長程的上下文非常的複雜,不僅僅是當前對話輪中會存在特別多的問題,包括用戶昨天說過的話,一個月之前說過的話,可能都會對今天的對話內容造成比較大的影響,這是一個非常難的問題。

這裡給大家分享下小冰為什麼更多的關注在第三個方向,主要原因:

小冰在剛立項時,我們發現目前市場上所做的產品都有比較大的局限性。在現有系統中,對比已有的任務或者搜索信息的方式,並不能帶來更多的價值。比如訂機票或者訂外賣,包括國內一些大廠也在做,通過對話系統完成類似的事情,但是市場上其實已經有了很好的APP能夠快速的完成類似的任務。快速不是說簡單點兩下就完成了,而是說對話系統本身是有局限性的,首先對話是基於時間的行為序列,是一步一步往下走的,但是我們在做task時,其實有很多的工具、界面,可以一目十行的看到非常多的文字、圖片和視頻等各種各樣的信息跟我們進行交互。由於通過文字進行交互,信息被極大的壓縮了,人在接受文字類信息的處理速度相對來講會比圖像、視頻等要慢一些。站在這個維度,由於Scalability局限性,以及市場上已經有了成型的產品在做這件事情,所以這塊的上限或者想像空間會稍微低一些。

2. 長程對話體驗

微軟小冰:如何構建人格化的對話系統 2

實際上,我們一直以 Session-oriented 來設計整個對話系統。左邊是業界比較傳統的做法,把它散漫出來,就是當用戶站在對話的某一時間節點時,可能背後會有很多的意圖,很多的分類,這時需要做一個決策,到底是往A、 B、C哪個方向走?跟我們人與人之間的對話交流相似,對話應該像河流一樣,在實際的溝通過程中,並不是每一句話都有特別的信息量,並不是每一句話都是在做任務或者搜索。這些無用的對話,由於穿插在這些任務或者知識的獲取中,並且前面有些無用的對話可能會對後邊的推薦或者任務有幫助,所以我們可以把這些潛在的意圖給挖掘出來加以利用。舉個例子,也是業界在做對話系統時忽略的一點,就是大家會把對話當做一個系統中單純的技能來對待,把聊天,查天氣,講笑話等擺在同等的維度。我們覺得大家普遍低估了對話的魅力,以及對話場景下,可以挖掘到的寶藏,為什麼?

因為對話本身是一個人跟人正常溝通的方式,在對話系統中可以挖掘到很多的有用的信息。比如給潛在的用戶推荐一雙耐克鞋,對於電商或者網站,可能通過推薦系統來做,而我們會根據很多的標籤,很多的信息,採用挖掘的方式來獲取到用戶的顯性/隱性的各種指標和標籤,實際上,通過對話可以非常容易的完成這件事情。比如今天是周末,天氣很好,你問用戶週末幹嘛去,用戶說他可能是無聊閒著在家,這時,你可以主動的引導( 對話就像一個河流,站在後台系統角度來看,是一個非常大的決策樹,可以把用戶往A方向引導,也可以往B方向引導) 用戶,平時沒時間鍛煉,週末正好去跑個步,如果用戶接著follow對話的方向,系統就有可能把用戶往健身運動這個方向引導,這時,就可以把耐克鞋以某種潛在的方式給推薦出來。可以通過對話的方式,比較自然的把有價值的信息推薦給用戶。

另外,很多隱性的標籤是沒法通過點擊的方式獲取的,不管是搜索引擎還是推薦系統,大家或多或少是通過點擊或者不點擊的反饋得到用戶對搜索結果或者推薦結果是否感興趣,來反向的優化搜索引擎或者推薦系統。但是,通過對話可以比較直接的挖掘到用戶的興趣點。比如你想知道用戶是男是女,我們可以通過問用戶有沒有男朋友來得到答案。這是一個很簡單的問題,當被拋出來之後,用戶也不覺得這個問題有多麼的突兀,就是人跟人之間無意的對話,由於人類類似於一個複讀機,每天會重複的聊比較相似的話題。如果用戶回答說有,我們就知道這個用戶是女性用戶,反之,用戶可能會說它是一個男的。其實這是一個NLP裡面的text entailment,也就是有一個前提假設,然後扔出來一個action,看用戶怎樣響應,如果用戶選擇的是A路徑,可能就符合你的A假設。所以我們可以在對話中挖掘到很多通過搜索引擎或者推薦系統挖掘不到的非常直觀的信息。

對於對話系統特別是閒聊式的對話系統,該如何衡量?我們用 CPS ( conversation per session ) 指標來衡量,也就是用戶跟Chatbot聊天的turn數。這是一個相對來講非常宏觀的指標,並不能100%代表對話的質量,我們目前的平均值可以做到23。一般任務型的對話系統,基本2~3個turn可能就完成了。而且用戶的粘性也不會特別好,用戶有需求時,才會用一下。站在我們的立場,turn數越多,可以挖掘到的有用信息越多,給用戶推薦引導的機會就越多。

其實小冰也能做很多的task,只不過我們在對外宣傳時,不會特意去提,我們覺得很多基本的Task是一個對話機器人的標配,如果一個產品有下界跟上界,這個下界就是做一些基本的task。在我們內部,有一層通用的對話系統服務層,主要是為了保持及引導對話的過程。

3. 對話系統的基本結構

微軟小冰:如何構建人格化的對話系統 3

接下來分享下,我們對話系統的基本結構,宏觀上,整體的架構跟搜索推薦的架構非常像:

首先Query來了,我們會對Query做分析,進行Query Understanding,不僅僅分析當前的Query,還會從Session裡提取Session History來做分析,生成兩大類的Policy,一類是被動式的,一類是主動式的。

  • 被動式的:指的是當前的Query比較有信息量,這時需要盡可能的引導這個話題往更有意義,更深入的方向上走,這裡有三個模塊:基於模板,基於檢索,基於生成的方式來做的,然後對這三個模塊整體上會做Aggregation Ranking,這裡包含三層:召回,排序,還有Post Process ( 後處理),需要把很多違背常識/違背邏輯的答案去除。
  • 主動式的 ( Proactive ):指拋出新的話題。對話系統不是一個簡單的NLP問題,它還是一個非常複雜的系統工程,需要在沒話題聊的時候,盡可能的把問題弄回來或者拋出新的話題。需要維護State,以及下一步的Action應該怎樣去take。

理論上這兩個模塊是並行跑的,當系統負載比較高時,它只走其中的一個分支。當Response ( 回复 ) 之後,我們會把它放到離線的用戶畫像挖掘模塊。剛才我們提到,通過問用戶有沒有男朋友,來Mining出用戶畫像,用戶畫像又會反過來給到Ranking、Proactive非常多的信號來做進一步的決策,最後Response會回到Session模塊中。

4. Query語義分析

微軟小冰:如何構建人格化的對話系統 4

剛才提到當一個Query來了之後,第一步是做Query Understanding,在我們內部有四類信號:上下文相關的,Entity ( 實體 ) 相關的,意圖相關的,情緒相關的,因為我們是一個對話機器人,需要特別的關注用戶當前的狀態。

  • 上下文相關的信號:包括query改寫,上下文,是不是頭部Query,是不是在聊,以及當前的Query類型,是簡單的問題,還是複雜的問題。
  • Entity相關的信號:這塊大家都在做,特別提下Topic transfer,在對話中非常常見,因為對話的狀態其實是一個open domain,是沒有目標的,所以說有很大的概率會存在你在聊這個話題,機器人回答的是另外一個話題,然後用戶再去順著機器人的話題時,他又轉移到另外一個話題上去了。所以,這裡你需要有一個非常好的Transfer Detection模塊,盡可能的把用戶當前的topic 檢測出來,以及做好話題生成、引導。我們內部有一個Graph叫做Topic Graph,跟業界提的KG有點類似,但又有點不同,我們是基於對話系統裡面能聊的Topic本身來精心設計的。 Topic之間就蘊含了我當前在聊A話題時,潛在其它話題的可能性。
  • 意圖相關的信號:在對話中,有很多潛在的意圖,我們需要做意圖分類,Task related等。
  • 情緒相關的信號:包括情緒類型和情緒強度等。

5. 基於上下文的query改寫

微軟小冰:如何構建人格化的對話系統 5

傳統的基於上下文的query改寫包括兩種方式:

針對當前的query,把上下文的key word抽取出來,和當前的query做一個combine,combine可以放在前邊、後邊、中間,可以按照不同的方法組合出來。

通過sequence建模的方式,把上下文query放到統一的model中建模,得到vector,甚至可以疊加一個Hierarchical層,把整個句子的Embedding表示出來。

存在問題:

對於①:由於生成模型會對序列產生很大影響,直接插入關鍵詞是不科學的做法,比較簡單粗暴;僅僅進行關鍵詞抽取,可能會忽略掉一些信息,比如“否定”類的信息,就不會被挖掘到。

對於②:Embedding建模的方式是一個系統工程,需要的計算資源非常大;如果整個句子過長,則起不到很好的建模作用。

如圖所示,我們在EMNLP2019發表了論文:

Unsupervised Context Rewriting for Open Domain Conversation

https://arxiv.org/abs/1910.08282

我們通過生成的方式來做Query改寫,盡可能的補全當前的Query,採用2個Encoder+1個Decoder,其中一個Encoder會把Session中比較重要的信息通過Attention方式進行統一建模,同理, Query這塊也是類似的處理,然後Decoder這塊兒,我們會通過端到端的方式看當前生成的term是從Query端做拷貝。

如何得到大量的訓練數據?

微軟小冰:如何構建人格化的對話系統 6

對於這個Task,難點在於如何得到大量的訓練數據。在互聯網上,有大量的長片段的Session對話,但是你要把這種端到端的( 給定的Context跟當前的Query ) 改寫好的response很好的抽出來,但是,數據量還不是特別大。

除了一些ground truth data讓標註團隊去標註一部分數據集,我們想端到端通過生成的方式做Query改寫,還是需要大量的數據。我們的做法,分為以下幾步:

Step1:首先使用 Pointwise Mutual Information ( PMI ) 算法根據Query和 response ( 回复的句子 ),抽取上下文中與其共現概率最大的若干詞作為關鍵信息。

Step2:再使用語言模型將這些信息插入Query中,計算不同插入位置的得分,我們這裡選取的是Top 3生成的句子,進而得到被改寫的 query。

Step3:但是在實際的應用場景中,我們無法得到response 的信息,所以我們採用一個基於復製網絡( copy-net ) 的深度模型來學習這部分先驗知識,並使用這些構造好的數據作為訓練集,利用該訓練集進行多輪對話上下文改寫模型訓練( Context Rewriting Network )。

Step4:使用強化學習來優化S*,也就是改寫好的Query。不過強化學習的效果不是特別穩定,以及存在一些潛在的風險。

實驗結果

微軟小冰:如何構建人格化的對話系統 7

我們來看下,基於上下文的query改寫結果,不管是人工評判,還是自動評判,都有比較好的結果。簡單提一下,如圖中左下角,我們用改寫好的框架運行在實際的線上系統,端到端的衡量改寫的Query,我們發現不做強化學習的模塊,要高於baseline20個點,但是加入強化學習後的結果不是特別的多。我們再細緻的看右邊標註的結果,就是-1,0,1,2,3,其中1,2,3相對來講是比較好的回复,大家可以看到0的比例會顯著高於baseline也會高於不加LR的模塊。在實際中,我們採用的是CRN的方法。

6. 小樣本學習

微軟小冰:如何構建人格化的對話系統 8

在我們的對話系統中會有很多的意圖,與task不同點在於task的query表達相對清晰、句式結構以及用詞相對明確,但在對話系統中我們會發現有很多的Query潛在的意圖可能是一樣的,甚至有些Intention可能還沒有Entity,場景比較隨機。另外,我們能得到的樣本其實非常少的,特別是小意圖,基本上還是通過人工標註的方式來得到訓練數據。

在小樣本學習中,有一個比較經典的領域,就是Meta Learning,Meta Learning又分為:基於model based方法,metric based方法。基於Metric based中又有一種方法是基於原型的網絡。

簡單解釋下原型網絡:假設,現在的樣本比較少,我們可以通過原型網絡來建模。由於每一類都有一些小樣本,在建模過程中,每一次都是隨機的挑一些類別,每一類中也盡可能的挑一些樣本出來,然後通過原型網絡進行建模。每一個樣本我們挑出來之後,都會得到一個表達,經過多次的訓練,就會得到每個樣本的不同表達。然後對某一類中,所有的樣本做平均:

微軟小冰:如何構建人格化的對話系統 9

我們認為C1 ( 見上圖 ) 是對應的類的中心點,同樣C2,C3也是各自對應的類的中心點。當一個新的Query來了之後,我們會對新的Query也進行建模,得到一個表達X,當前的X跟已有類別的distance,可以通過下面的方式,進行衡量:

微軟小冰:如何構建人格化的對話系統 10

然後進行歸一化操作得到概率,即x屬於每一個類的概率。

這樣做有一個好處:當有新的類別加進來之後,整個模型並不需要進行特別多的改動,對於這種比較隨機的場景,每天可能新增十幾種新的意圖,但是增加一個新的意圖,並不需要再顯示的重新訓練模型。因為原型網絡這種方式,已經在幫你盡可能的對樣本做很好的建模。所以在實際系統中,我們基本上能做到20分鐘以內,只要把意圖構建好之後,就能把整個model重新推上線,非常的快。

微軟小冰:如何構建人格化的對話系統 11

我們做了一個改進的工作:

我們發現,Ci是根據樣本的個數來做均等的分配,我們認為這不是一個特別好的思路。所以說我們做了Hierarchical Attention,這樣的原型網絡。具體細節大家可以看論文:

Hierarchical Attention Prototypical Networks for Few-Shot Text Classification

https://www.aclweb.org/anthology/D19-1045/

在這裡,我們認為樣本空間中的每一個樣本對中心點的貢獻都是不一樣的。所以我們會有一個βij的表達,通過中間的Word Level Attention以及Instance Level Multi Cross Attention盡可能分出來每個樣本對中心點Contribution。最後用當前的Query,類似的,通過Encoder layer得到q’。每個樣本Ci的表達,用上面新的表達來進行更新,對每一類的標籤,也會有一個新的Class Feature Extractor,也就是新的向量的表達。因為樣本本身也是分佈不均勻的,所以λi也是需要做建模的。

微軟小冰:如何構建人格化的對話系統 12

整體的效果,如上圖所示,最後一行是基於新的方法來做的。可以看到相比以前的基於原型網絡的方法有了很大的提升。

我們對結果做了一個降維的分析,發現正如我們所理解的那樣:

有一些樣本點,比較難分的一個原因是它的用詞和句式跟另外一個類別中的表達,相對來講是比較像的。通過這種更深層次的建模,每一類中的每一個樣本,對樣本中心點的貢獻都會不一樣,把那些不太重要的樣本篩掉之後,處在邊界的樣本會拉得更開一些。

7. 檢索模型的基本結構

微軟小冰:如何構建人格化的對話系統 13

剛才介紹的兩個工作都是在Query端做的工作。接下來介紹下Aggregation Ranking。

我們的檢索模型分為三層:

L1,Inverted Index ( 倒排索引 )。我們內部也在做ANN search,盡可能的把當前的Query和Session向量化,再通過ANN的方法,做一個比較粗的大規模的召回。

L2,Ranking ( 排序 )。整體分四類Feature:

  • Word Level Feature
  • Sentence Level Feature
  • Context Level Feature
  • Ensemble

2018年,預訓練技術開始大規模的應用。我們把谷歌的Bert技術用到對話系統中做Ranking,上線後的效果非常好。由於Bert是基於Transformer它的速度相對來說較慢,需要進行大量的模型壓縮和蒸餾等相關工作。

L3,Post Process進行Filter/Modify ( 過濾和調整 )。如時間調整,profile entailment ( 性別、星座、位置等 ),字符調整等操作,將不該出現的Response去掉。

8. 生成模型

微軟小冰:如何構建人格化的對話系統 14

在2017年,我們的開放域對話系統生成模型就已經上線,甚至包括基於語音的交互系統中。最近我們會有一個基於話題 ( 也包括情緒、知識等 ) 生成的模型,在內部已經取得了比較直觀的效果,但是整個模型結構可能會不太一樣。我們在做生成時,盡可能把一些Topic words加進去。 Topic words的來源有很多的方法。這篇論文是通過LDA的方式,還有很多其它的方法,比如LDA+Topic Graph+Knowledge Graph等,受限於篇幅,這裡不再展開。

Topic在生成時,會作為Decoder生成的Context其中的一部分。以前Encoder部分,可能有很多的隱藏狀態,會對它進行Attention,這時,我們也把基於topic的表達也放到context中,不僅能看到Message Attention,也能看到Topic Attention。

實際的效果,見右圖。我們給美妝護膚領域做的Chatbot,一個定制化的生成模型,效果還是不錯的。

給大家分享下,我們的Motivation:

在做垂域的對話系統時,我們並沒有很多質量比較高的數據。所以我們是在一個比較大的數據集中,端到端來做的,然後選擇系統中具有代表性的term做生成。在Long Tial問題中,這種端到端的方法效果是非常好的。

9. 共感模型

微軟小冰:如何構建人格化的對話系統 15

從系統整體的對話結構上來看,其實就是QA。但在QA中間,是存在一些策略的,也就是說,對當前的上下文,對用戶來講,機器人要不要引入一些新的話題。整個對話相當於是商檢的過程,因為對話本身是無序的,如果回答的不好,就會東扯一下西扯一下。從商業的角度來講,整個系統的穩定性不是特別好,用戶聊了兩句可能就走了,所以需要盡可能的獲取對話的節奏。那麼,有沒有可能更顯式的控制對話的節奏?

這個也是我們的一篇工作:

Towards Explainable and Controllable Open Domain Dialogue Generation with Dialogue Acts

https://arxiv.org/pdf/1807.07255.pdf

我們引入了Dialogue Act概念,在這裡,我們有比較寬泛的七大類的Act,比如我們是應該follow用戶的問題,還是針對用戶的問題,問一個新的問題,或者直接拒絕回答用戶的問題,這是一大類。還有一大類,是發現當前的Session聊得不太好了,需要更多的引入新的話題,新的話題有可能是飯,也有可能是問題等等。通過這樣的方式,我們可以比較好的建模對話的節奏。

02 人格化的定義及如何部分實現人格化

1. 人格化的定義

微軟小冰:如何構建人格化的對話系統 16

上圖是從百度百科中摘取的一段關於人格化的定義,簡單來講,就是人格化的Chatbot。這裡我們能夠通過技術手段可以實現的是 能力、性格、興趣、一致性、連續性,對Chatbot實現人格化,提供了很好的借鑒方向。

2. 小冰的框架

微軟小冰:如何構建人格化的對話系統 17

AI beings的定義:具有人格化的對話系統實體。 AI beings是處在T字形中間的狀態,左邊是Human與人的交互,這裡存在3個Level的Senses,基於文本、圖像、聲音,基於全雙工,以及基於多模態的;右端是盡可能的把物理世界的知識、content加進來,在這裡還有AI創作的模塊,根據人格化的定義,賦予AI beings自己的能力和氣質,可以寫詩。寫歌、唱歌等等,相比於決策,AI創作更容易實現;最後是Deployments,跨平台。

3. 我們的假設 ( 思考 )

微軟小冰:如何構建人格化的對話系統 18

AI beings 最大的 困局,在於 不能獲得對等的地位

  • 在AI beings之前,已經有大量的工具在或多或少的在完成對應的任務,並且做的還不錯;
  • AI beings需要避免被工具化或者僅僅成為管道 ( 否則被替代的可能性相當大 );
  • AI beings一旦被賦予主體資格,就有可能建立長期信任關係;
  • AI beings的終極價值,在於長程陪伴的關係。

智能音箱為例,大家最看重的有三點:

  • 價格:為了競爭市場,市場上各家相對來講都會把價格打的非常低。
  • 工藝:音箱本身都有各種各樣的設計,並且有些音箱的設計確實非常的具有想像力。
  • 內容豐富:音箱中內容資源的豐富度,不管是音樂播放、相聲、兒童教育,還是其它領域的內容,在內容上的豐富度也是智能音箱的一個賣點。

但是大家仔細一想,AI在其中起到的作用,其實不多。很多技術,如讓音箱去播音樂,理論上,在十幾年以前的技術就能做到。大家購買音箱的原因主要還是上面的3點,而不是其中的AI技術點。所以,AI如果僅僅是以一個上限不是那麼高的實現方式呈現給大家,那麼接下來很可能被其他形態的產品所替代,因為AI在系統中的價值並不是很大。

4. 如何構建AI beings?

微軟小冰:如何構建人格化的對話系統 19

整個Session其實是我們的一些理念,並不是所有的模塊都做到了,也希望業界,特別是做開放領域對話的同行,能一塊來探討相關的細節。這是我們的方法論:

我們會認為所有的AI beings首先需要定義她的Profile人格,包括基礎屬性和興趣屬性,構成一個基本的個體,再給她加上交互的能力,包括對話、聲音、視覺,讓她有擬人化的聲音,可以清楚的看到外面的世界。於是,我們就有了一個基本的AI beings,這時我們可能需要加三觀,三觀這個詞可能用的不是特別的好,我們大致想表達的意思是 讓AI beings有自己的觀點,這個觀點不是強行加給她的,而是在給一個初始設定之後,能通過Entailment或者Inference,做Response跟AI beings的觀點一致性校驗,盡可能讓AI beings能體現出自己獨特的存在,而不只是幫你完成任務。加入三觀之後,後面還會加入創造力、技能與知識,如果有可能的話,可以做一個跨平台的部署,不管是實體的硬件中,還是虛擬的網絡裡,得到一個統一的交互切入點,體現出無處不在的形態。

5. Bot Characterize

微軟小冰:如何構建人格化的對話系統 20

在我們內部機器人的基本特徵如上,主要包括四部分:Conversation Content/Style、Domain Knowledge/Skill、Opinion、Relation

重點介紹下Conversation Content/Style:在我們內部的index中,主要是基於檢索的方式對每一句話打上標籤( tagging ),Tagging是基於性格特點,比如內向、外向、活潑、高冷,進行性格維度的刻畫,需要在index中讓對話語料體現出這種特點。所以我們會在L3 Post Process模塊,加強人設的體現。

6. 觀點表達

微軟小冰:如何構建人格化的對話系統 21

這是我們關於觀點表達的工作:

Attitude Detection for One-Round Conversation: Jointly Extracting Target-Polarity Pairs

https://dl.acm.org/citation.cfm?id=3291038

業界在做系統時,會把TAG提取和意圖分開。特別是在做slot filling ( 槽位填充 ) 時,會先分意圖,再做slot抽取。我們發現,如果把這兩個工作組合在一起做,會有更好的效果提升。右上角是我們的一個做法,可以給她的觀點根據不同的Entity,不同事物做設定,當有新的Response回來之後,會跟當前的設定做邏輯一致性校驗,比如喜歡吃辣的或者不喜歡吃辣的,Response如果是吃火鍋,對應的就是喜歡吃辣的,如果人設是不喜歡吃辣的,那麼這種Response需要盡可能的去掉。更多詳情可參考原論文。

7. Character Studio

微軟小冰:如何構建人格化的對話系統 22

Character Studio主要是用來管理AI beings的存儲。簡單提下我們的用戶模擬器:

對話系統是一個比較複雜的過程,如果依靠人的力量做交互,是一個不太合理的方法,所以我們開發了一個對話模擬器。在裡邊有兩個bot,一個是真實的Character bot,一個是Policy bot,Policy bot會利用共感模型等方法,分析當前的狀態,來模擬用戶控制對話的節奏,我們會對打造的AI beings的各種回復進行打分,哪些模塊覆蓋到了,哪些模塊沒有覆蓋到。通過模擬器,我們可以非常快速的校驗不同IP的Chatbot做的好不好,每個模塊會有自己恆定的指標,可以檢測出每個模塊的具體情況。

微軟小冰:如何構建人格化的對話系統 23

目前,我們已經上線了200+不同IP的Chatbot,如第二個,是”妲己”對話機器人,是我們跟QQ一起合作的,妲己除了是歷史人物,也是王者榮耀遊戲中的角色。為了活躍整個遊戲群的生態,我們就做了”妲己”對話機器人,把歷史上的妲己跟遊戲中的妲己疊加起來,既可以問和遊戲中技能相關的問題,也可以聊歷史中關於妲己的話題。最右邊,是我們在日本做的一個Case,在對話中做美食推薦。這個美食推薦,並不是用戶想要什麼,就給推薦什麼,而是基於對話的節奏,盡可能的符合之前對話的過程。

總結

今天的分享主要給大家站在業界的角度,展示了小冰的產品設計思路,​​基礎的對話系統設計,以及如何打造具有人格化的對話系統,由於時間關係,很多模塊沒有展開分析。在實踐當中有太多難題等著我們去攻克,這是一項非常有挑戰性的工作,希望能看到業內更多的小伙伴加入到這條戰線當中來,謝謝大家。

作者介紹

曾敏,微軟高級技術總監

本文來自 DataFunTalk

原文鏈接

https://mp.weixin.qq.com/s?__biz=MzU1NTMyOTI4Mw==&mid=2247498005&idx=1&sn=5e2fb86aebd88c14f8aa7db90cbf1fdc&chksm=fbd74b79cca0c26fa11d15e1daa19e80210ee452c208212a108387356c88359465dd46fcbd3b&scene=27#wechat_redirect