四大維度全景揭祕阿里巴巴智能對話開發平臺

在阿里巴巴智能服務事業部的X蜂會上，小蜜北京團隊的高級算法專家李永彬（水德）分享了小蜜智能對話開發平臺的構建，圍繞平臺來源、設計理念、核心技術、業務落地狀況四大維度講述了一個較爲完整的智能任務型對話開發平臺的全景。如下爲演講具體內容。

平臺由來

爲何要作一個平臺？我以爲仍是從一個具體的任務型對話的例子提及，在咱們平常工做中，一個很高頻的場景就是要約一個會議，看一下咱們內部的辦公助理是怎麼來實現約會議的：我說「幫我約一個會議」，而後它問「你是哪一天開會？」，跟它說是「後天下午三點」，接下來它又會問「你跟誰一塊兒開會啊？」，我會把我想約的人告訴它，這個時候它在後臺發起一次服務調用，由於它要去後臺拿到全部參會者的日程安排，看一下在我說的這個時間有沒有共同的空閒時間，若是沒有的話它會給我推薦幾個時間段，我看了一下我說的那個時間段你們沒有共同的空閒時間，因此我就會改一個時間。我說「上午十一點吧」，而後它會接着問，「你會持續多長時間」，我會告訴它「一個小時」，而後它接着問「會議的主題是什麼」，而後我跟它說「咱們討論一下下週的上線計劃」，到此爲止它把全部的信息收集全了，而後它會給我一個 summary，讓我確認是否是要發送會議邀約，我回復確認之後，它在後臺就會調用咱們的郵件系統，把整個會議邀約發出來。

這是一個很是典型的任務型的對話，它知足兩個條件，第一，它有一個明確的目標；第二，它經過多輪對話交互來達成這個目標。像這樣的任務型對話在整個辦公行業裏面，除了約會議之外還有查考勤、請假、定會議室或者日程安排等等。

若是咱們把視野再放大一點的話，再看一下電商行業，電商行業裏面就會涉及到開發票、催發貨、查物流、改地址、收快遞等等，也會涉及到不少不少的這樣的任務型對話場景；視野再放大一下，咱們再看一下電信行業或者整個運營商的行業裏面，會有查話費、查流量、買套餐、報故障或者是進行密碼的更改服務等，也會有大量的這種任務型的對話場景。若是咱們再一步去看的話，像政務、金融、教育、文娛、健康、旅遊等，在各行各業的各類場景裏面咱們都會發現這種任務型的對話，它是一種剛需，是一種廣泛性的存在。

全部的這些場景落地到咱們小蜜家族的時候，是經過剛剛介紹過的三大小蜜來承載：阿里小蜜、店小蜜和雲小蜜。咱們不可能給每個行業裏面的每個場景去定製一個對話流程，因此咱們就沿用了阿里巴巴一向作平臺的思路，這也是咱們整個智能對話開發平臺的由來。這款產品在內部的名字叫對話工廠（Dialog Studio）。

以上主要是給你們介紹咱們爲何要作智能對話開發平臺，總結起來就是咱們目前面臨的業務，面臨的場景太寬泛了，不可能鋪那麼多人去把全部的場景都定製化，因此咱們須要有一個平臺來讓開發者進來開發各行各業的各類場景對話。

設計理念

再看第二部分，對話工廠的一些核心設計理念。整個設計理念這塊我以爲歸納起來就是「一箇中心，三個原則」。一箇中心就是以對話爲中心，這句話你們可能以爲有點莫名其妙，你作對話的，爲什麼還要強調以對話爲中心呢？這是有來源的，由於在過去幾年全世界範圍的技術實踐以及直到今天不少巨頭的對話平臺裏面，咱們能看到的基本仍是以意圖爲中心的設計模式，它把意圖平鋪在這裏，好比你想完成音樂領域的一些事情，但是你看到的實際上是一堆平鋪的意圖列表，徹底看不出對話在哪裏。

咱們在此次對話工廠的設計中完全把它扭轉回來，對話就是要以對話爲中心，你在咱們的產品界面裏面看到的再也不是一個個孤立的意圖，而是關聯在一塊兒的、有業務邏輯關係的對話流程。以意圖爲中心的設計中，你看到的實際上是一個局部視角，就只能實現一些簡單的任務，好比控制一個燈，講個笑話，或者查個天氣，若是你想實現一個複雜的任務，好比開一個發票，或者去 10086 裏開通一個套餐，它實際上是較難實現，很難維護的。咱們把整個理念轉換一下，回到以對話爲中心之後，就會看到全局視野，能夠去作複雜的任務，能夠去作無限的場景。

整個對話工廠剛剛也說過了，它是一個平臺，要作一個平臺就會遇到不少挑戰：第一個挑戰就是對用戶來講，但願使用門檻越低越好；第二個挑戰是要面對各行各業的各類場景，就要求能作到靈活定製；第三個挑戰是上線之後全部的用戶確定都但願你的機器人，你的對話系統可以越用越好，而不是停留在某一個水平就不動了。這就是咱們平臺所面臨的三大挑戰。

爲了應對這三個挑戰，咱們提出了在整個平臺的設計以及實現過程當中始終要遵循三個原則。

第一個原則是冷啓動要快，其實就是要讓用戶的使用門檻低一點；第二個原則是要有靈活定製的能力，只有這樣才能知足各行各業的各類場景需求；第三個是要有魯棒進化的能力，就是模型上線之後，隨着時間的變化，隨着各類數據的不斷迴流，模型效果要不斷提高。

1. 冷啓動，就是要把用戶用到的各類能力和各類數據都儘可能變成一種預置的能力，簡單來講就是平臺方作得越多，用戶就作得越少；
2. 靈活定製，就要求咱們把整個對話平臺的基礎元素進行高度抽象，你抽象的越好就意味着你平臺的適應能力越好，就像是經典力學只要三條定律就夠了；
3. 魯棒進化，這一塊就是要在模型和算法上作深度了，語言理解的模型，對話管理的模型，數據閉環，主動學習，在這些方面可以作出深度來。

以上說的都是一些理念和原則，接下來給你們介紹一下具體在實現過程當中是怎麼來作的。

核心技術

講到技術這塊的話，由於咱們作的是一個平臺，涉及到的技術很是廣，是全棧的技術，從算法到工程到前端到交互全部的技術都會涉及到。我摘取裏面算法的核心部分來給你們作一個介紹。

對話工廠首先是用來作對話的，人機對話有兩個主體，一個是人，一個是機器，人有人的邏輯，人的邏輯使用什麼來表達呢？到今天爲止主要仍是經過語言，因此咱們須要有一個語言理解的服務來承載這一塊；機器有機器的邏輯，機器的邏輯到今天爲止仍是經過代碼來表達的，因此咱們須要一個函數計算的服務；在人和機器對話的過程當中，這種對話過程須要有效的管理，因此咱們須要一個對話管理模塊。整個對話工廠最核心的三個模塊就是語言理解、對話管理和函數計算。

第一個模塊是語言理解。

咱們先看一下這個圖，在整個這個圖裏面，橫軸是意圖的多樣性，縱軸是頻次，這樣說有點抽象，我舉一個具體的例子，好比說我要開發票，這是一個意圖，若是去採樣十萬條這個意圖的用戶說法做爲樣本，把這些說法作一個頻率統計，可能排在第一位的就是三個字「開發票」，它可能出現了兩萬次，另外排在第二位多是「開張發票」，它可能出現了八千次，這些都是一些高頻的說法，還有一些說法說的很長，好比「昨天我在大家商鋪買了一條紅色的裙子，你幫我開個發票唄」，這種帶着來龍去脈的句式，在整個說法裏面是比較長尾的，可能只出現了一次或兩次。

咱們統計完之後，整個意圖的說法的多樣性分佈符合冪律分佈。這種特徵可讓咱們在技術上進行有效的針對性設計，首先針對這種高頻的部分，咱們能夠上一些規則，好比上下文無關文法，能夠比較好的 cover 這一塊，可是基於規則的方法，你們也知道，規則是沒有泛化能力的，因此這時候要上一個匹配模型，計算一個類似度來輔助規則，這兩塊結合在一塊兒就能夠把咱們高頻肯定性的部分解決的比較好；對於長尾的多樣性的這一部分，基本到今天爲止仍是上有監督的分類模型，去收集或者去標註不少數據，把這一塊作好；在規則和分類模型之間，咱們又作了一部分工做，就是遷移學習模型，爲何要引入這個模型呢？咱們看下一張圖。

在冷啓動階段，用戶在錄入樣本的時候，不會錄入太多，可能錄入十幾條几十條就已經不少了，這個時候按照剛纔那個冪律分佈，二八原則的話，它的效果的話可能也就是 70% 多，它不可能再高了。但對於用戶的指望來講，若是想要上線，想要很好的知足他的用戶需求，實際上是想要模型效果在 90% 以上，若是想要達到這個效果，就須要複雜的模型，須要標註大量數據。因此實際上是存在一個 gap 的，咱們引入了遷移學習模型。

具體來講，咱們把膠囊網絡引進來和 few-shot learning 結合在一塊兒，提出了一個網絡結構叫 Induction Network，就是概括網絡。整個網絡結構有三層，一層是 Encoder層，第二層是 Induction，概括層，第三層是 Relation 層。

第一層負責將每個類的每個樣本進行編碼，編碼成一個向量；第二層是最核心的一層，也就是概括層，這裏面利用膠囊網絡的一些方法，把同一個類的多個向量概括成一個向量；而後第三層 Relation 層把用戶新來的一句話和每個類的概括向量進行關係計算，輸出他們的類似性打分。若是咱們想要一個分類結果就輸出一個 One-hot，若是不想要 One-hot，就輸出一個關係的 Relation score，這是整個 Induction network 的網絡結構。

這個網絡結構提出來之後，在學術圈裏面關於 few-shot learning 的數據集上，咱們以比較大的提高幅度作到了 state-of-the-art 的效果，目前是最好的，同時咱們將整個網絡結構上線到了咱們的產品裏面，這是語言理解。

第二塊咱們看對話管理。

對話管理其實我剛剛也說過了，若是想要讓平臺有足夠的適應性的話，那麼它的抽象能力必定要好。

對話管理是作什麼的？對話管理就是管理對話的，那麼對話是什麼呢？對話的最小單位就是一輪，一個 turn，咱們進去看的話，一個 turn 又分爲兩部分，一個叫對話輸入，一個叫對話輸出；在輸入和輸出中間，有一個對話處理的過程，就像兩我的互相交流同樣，我問你答，但其實你在答以前是有一個思考過程的，若是你不思考就回答，那你的答案就是沒有質量的，因此就會有一箇中間的對話處理過程。咱們把對話抽象到這種程度之後，整個平臺就三個節點，一個叫觸發節點，一個叫函數節點，一個叫回復節點。

觸發節點是和用戶的對話輸入對着的，函數節點是和對話處理對着的，回覆節點是和對話輸出對着的。有了這一層抽象之後，不管你是什麼行業的什麼場景，什麼樣的對話流程，均可以經過這三個節點經過連線把你的業務流畫出來。

舉兩個例子，先看一個簡單的，你要查一個天氣，很簡單，先來一個觸發節點，把天氣流程觸發起來，中間有兩個函數節點，一個是調中央氣象臺的接口，把結果拿過來，另外一個是對結果進行一次解析和封裝，以一個用戶可讀的形式經過回覆節點回復給用戶。這裏面稍微解釋一下就是增長了一個填槽節點，填槽節點是什麼意思呢？就是在任務型對話裏面，幾乎全部的任務都須要收集用戶的信息，好比你要查天氣，就須要問時間是哪一天的，地點是什麼地方的，這樣就叫作填槽，填槽由於太經常使用太廣泛了，就符合咱們冷啓動快裏面作預置的思想，因此經過三個基礎節點，咱們本身把它搭建成填槽的一個模板，須要填槽的時候從頁面上拖一個填槽節點出來就能夠了。

咱們再看一個複雜的場景，這是在線教育裏面的一個外呼場景，家裏有小孩的可能知道，這種在線教育特別火，在上課以前半小時，機器人就會主動給用戶打電話，指導軟件下載，指導怎麼登錄，登錄進去之後怎麼進入教室，全部的這些流程均可以經過機器人進行引導。

經過這兩個例子咱們就能夠看到，不管是簡單仍是複雜的場景，經過這三種抽象節點的連線均可以實現。有時候咱們開玩笑就會說，整個這種連線就叫一輩子二，二生三，三生萬千對話。

講了抽象之後，再看一下具體的對話管理技術。從實現上來講，這張圖和你們剛纔看到的語言理解那張是如出一轍的，由於不少東西的分佈實際上是遵循着共同規律的，區別在與把意圖換成了對話。

舉一個例子，好比像查天氣這樣的，若是採集十萬個查天氣的樣本，對這些用戶的說法進行一個頻率統計的話，大概就是這樣一個曲線，用兩步可以完成的，好比說查天氣，先填槽一個時間再填槽一個地點，而後返回一個結果，經過這種流程來完成的，可能有兩萬次；中間可能會引入一些問 A 答 B 的狀況，這樣的 B 可能有各類各樣的，就跑到長尾上來了，這樣整個對話其實也遵循一個冪律分佈。

對於高頻肯定的部分，能夠用狀態機進行解決，但狀態機一樣面臨一個問題，它沒有一個很好的容錯能力，當問 A 答 B 的時候，機器不知道下面怎麼接了。在這種狀況下，須要引入一個類人能力，對狀態機的能力進行補充，狀態機加上類人能力之後，基本上能夠把高頻的對話比較好的解決了。對於長尾上的對話，目前對於整個學術界或者工業界都是一個難題，比較好的解決方式就是上線之後引入在線交互學習，不斷跟用戶在對話過程當中學習對話。在狀態機和在線交互學習之間實際上是有 gap 的，由於狀態機本身沒有學習能力，因此須要引入加強學習。接下來我會介紹在類人能力以及加強學習方面的一些工做。

先看一下類人能力。咱們把人說的話，作一下分類大概能夠分爲三種：第一種就是用戶說的話清晰明瞭只有一個意思，這種其實對機器來講是可理解的；第二種機器壓根兒不知道在說啥，也就是 unknown 的；還有一種就是用戶表達的意思能夠理解，可是有歧義，有可能包含着兩個意圖、三個意圖，就是uncertain，不肯定的。肯定性的，狀態機實際上是能夠很好地捕捉和描述的，類人能力主要關注拒識的和不肯定性的。

對於拒識這塊，好比仍是在線英語的這個例子，機器人打來一個電話，問如今方不方便調試設備，這個時候從設計的角度來講但願用戶回答方便或者不方便就OK了，可是一旦這個用戶回答了一個比較個性化的話，好比，「呃，我剛掃完地，過會兒可能有人要來」，這時候咱們的語言理解模塊很難捕捉到這是什麼語義，這時候須要引入一個個性化的拒識，好比說，「您好，很差意思，剛纔沒聽明白，請問您如今是否方便調試，若是您不方便，我過會兒再給您打過來」，這個就是對話的兜底，是對 unknown 的處理。

第二個咱們看一下澄清，用戶說的一句話裏面，若是是模糊不清的怎麼辦？咱們經過大量的數據分析發現這種模糊不清主要出如今兩種狀況下，一種是用戶把多個意圖雜糅在一段話裏來表達；第二種是用戶在表達一個意圖以前作了很長的鋪墊，對於這兩種長句子如今的語言理解給出的是意圖的機率分佈，咱們把這個機率分佈放到對話管理模塊之後就須要讓用戶進行一輪澄清。好比這個例子，這是移動領域的一個例子，這句話理解有三種意圖，究竟是想問花費明細，仍是套餐的事情仍是想問合約的低保，把這三個問題拋給用戶進行澄清就能夠了。

從技術上來講是怎麼實現的呢，咱們看一下這個圖，開發者負責把對話流程用流程圖清晰描述出來，而後像澄清這種實際上是咱們系統的一種內置能力，何時澄清是經過下端的這兩個引擎裏面的能力來決定的，第一塊是 Error Detection，它用來檢測用戶當前說的這句話是否須要觸發澄清，一旦它以爲要觸發澄清，就會交給下一個模塊，究竟用什麼樣的方式澄清以及怎麼生成澄清的話術，這是目前咱們整個智能澄清這塊作的工做。

再看一下咱們在加強學習方面的工做。在對話管理模型裏面，經典的分紅兩個模塊，一個是 neural belief tracker，用來作對話狀態追蹤的，另外一個是 policy network，用來作行爲決策的。在整個框架下，要去訓練這個網絡的時候，有兩種訓練方式，一種是端到端的去訓練，用加強學習去訓練，但這種方式通常它的收斂速度會比較慢，訓練出的結果也很差；另一種方式是先分別作預訓練，這個時候用監督學習訓練就行了，不用加強學習訓練，訓練完之後再用加強學習對監督學習預訓練的模型進行調優就能夠了。

不管是端到端的一步訓練仍是先預訓練再調優，只要涉及加強學習這一塊，都須要有一個外部環境，因此在咱們的實現架構裏面，引入了模擬器的概念，就是user simulator。模擬器這主要分爲三大塊，一個是 user model，用來模擬人的行爲的；第二個是 error model，模擬完人的行爲之後通過 error model 引入一個錯誤擾動，用 user model 產出的只是一個機率爲 1 的東西，它對網絡訓練是不夠好的，error model 會對這個結果進行擾動並給他引進幾個其餘的結果，而且把機率分佈進行從新計算一下，這樣訓練出的模型在擴展能力或者泛化能力上會更好一些；第三個模塊是 reward model，用來提供 reward 值。這是咱們今天在整個加強學習的對話管理這塊的一些工做。

最後看一下函數計算。

函數計算是什麼東西呢？仍是舉一個例子吧，好比說，10086 裏面用戶說要查一下話費，10086 那邊的機器人就會回覆一句是發短信仍是播放語音，表面看來就是簡單的一入一出，其實在這背後要通過多輪的服務查詢，才能完成這個結果，由於當要查話費的時候，先要通過函數計算查一下如今是哪一天，若是是下帳期的話是不能查話費的，就是每月的最後一天不能查話費，若是能夠查話費的話，先看一下用戶是否存在話費，若是存在花費的話第三步調用的服務看是否是停機了，由於停機了的話只能語音播報不能接收短信。因此看一下在一個簡單的一入一出的對話背後，是走了一個複雜的流程的，這些流程今天都是在機器端用代碼來實現的。函數計算的引入，使對話工廠能夠去處理複雜的任務。

業務應用

最後咱們看一下對話工廠的業務應用狀況。這是咱們在浙江上線的 114 移車，當有市民舉報違規停車擋路後，就會自動打一個電話讓他移車。第二個是在金融領域裏面關於貸款催收的例子。在剛剛過去的雙十一里面，對話工廠在整個電商裏面也有大量應用，主要是在店小蜜和阿里小蜜裏面。店小蜜主要是一些開發票、催發貨、改地址這樣的流程，這裏是一個開發票的例子，用戶可能會先說一個開發票，進來之後要進行復雜的流程，一種是在說的時候其實他已經把它的訂單號送進來了，若是沒有說訂單號的話須要去後臺系統查訂單號，查出來之後彈一個訂單選擇器選擇訂單，接下來若是是我的發票就走這個流程，若是是公司發票走另外一個流程，接下來會問是普通發票仍是增值稅發票，若是是普通發票接着往這兒走，若是是增值稅發票須要獲取企業增值稅的稅號，最後彙總到一個節點，調用後臺開發票的系統，把發票開出來。這是此次雙十一里面用到的開發票的一個例子。

最後看一下咱們總體的落地狀況。整個對話工廠在店小蜜裏面主要是作像開發票這樣的售後流程的處理。在雲小蜜，公有云是一大塊；私有云如今有不少家客戶了，主要有銀行、電信運營商還有金融等；釘釘是咱們另外一個重要的端，釘釘上也有幾百萬的企業；內外小蜜是咱們集團用小蜜實現的一個辦公助理；另外兩個巨大的客戶，一個是浙江省的政務，第二個是中國移動，這也是是雲小蜜的業務。阿里小蜜主要是負責阿里巴巴集團內部各個 BU 的業務，手淘是一個最大的業務，進入手機淘寶之後，進入「個人」裏面有一個客服小蜜，就是阿里小蜜；上個月咱們剛剛在優酷上線了優酷小蜜，星巴克是 9 月份上的，是屬於新零售的一個最大的嘗試點，還有不少其餘的場景。

總結

小蜜智能對話開發平臺，即對話工廠（Dialog Studio），以對話爲中心來設計，使得對話開發者可以看到全局視野，能夠去作複雜的任務，能夠去作無限的場景。同時，做爲一個平臺性產品，爲了可以實現低門檻、適用於各行各業以及具有效果持續提高能力，在整個設計實現中，遵循冷啓動快、靈活定製、魯棒進化三大原則。技術方面，咱們在語言理解、對話管理、遷移學習、加強學習以及模仿學習等各方面作了深刻探索，部分紅果作到了學術界state-of-the-art。業務方面，對話工廠在小蜜家族的大量業務中落地應用，帶來了良好的業務價值。

對話工廠，「讓人和機器自由對話」！

---

本文做者：李永彬

閱讀原文

本文爲雲棲社區原創內容，未經容許不得轉載。