平台由來
為什麼要做一個平台？我覺得還是從一個具體的任務型對話的例子說起，在我們日常工作中，一個很高頻的場景就是要約一個會議，看一下我們内部的辦公助理是怎麼來實作約會議的：我說“幫我約一個會議”，它會問“你是哪一天開會？”，跟它說是“後天下午三點”，接下來它又會問“你跟誰一起開會啊？”，我會把我想約的人告訴它，這個時候它在背景發起一次服務調用，因為它要去背景拿到所有參會者的日程安排，看一下在我說的這個時間有沒有共同的空閑時間，如果沒有的話它會給我推薦幾個時間段。由于我說的那個時間段大家沒有共同的空閑時間，于是我改了時間。
我說“上午十一點吧”，它會接着問，“你會持續多長時間”，我會告訴它“一個小時”，它再問“會議的主題是什麼”，于是，我跟它說“我們讨論一下下周的上線計劃”，到此為止它把所有的資訊收集全了，最後，它會給我一個 summary，讓我确認是不是要發送會議邀約，我回複确認以後，它在背景就會調用我們的郵件系統，把整個會議邀約發出來。
這是一個非常典型的任務型的對話，它滿足兩個條件，第一，它有一個明确的目标；第二，它通過多輪對話互動來達成這個目标。像這樣的任務型對話在整個辦公行業裡面，除了約會議以外還有查考勤、請假、定會議室或者日程安排等等。
如果我們把視野再放大一點的話，再看一下電商行業，電商行業裡面就會涉及到開發票、催發貨、查物流、改位址、收快遞等等，也會涉及到很多很多的這樣的任務型對話場景；視野再放大一下，我們再看一下電信行業或者整個營運商的行業裡面，會有查話費、查流量、買套餐、報故障或者是進行密碼的更改服務等，也會有大量的這種任務型的對話場景。如果我們再一步去看的話，像政務、金融、教育、文娛、健康、旅遊等，在各行各業的各種場景裡面我們都會發現這種任務型的對話，它是一種剛需，是一種普遍性的存在。
所有的這些場景落地到我們小蜜家族的時候，是通過剛剛介紹過的三大小蜜來承載：阿裡小蜜、店小蜜和雲小蜜。我們不可能給每一個行業裡面的每一個場景去定制一個對話流程，是以我們就沿用了阿裡巴巴一貫做平台的思路，這也是我們整個智能對話開發平台的由來。這款産品在内部的名字叫對話工廠（Dialog Studio）。
以上主要是給大家介紹我們為什麼要做智能對話開發平台，總結起來就是我們目前面臨的業務，面臨的場景太寬泛了，不可能鋪那麼多人去把所有的場景都定制化，是以我們需要有一個平台來讓開發者進來開發各行各業的各種場景對話。
設計理念
再看第二部分，對話工廠的一些核心設計理念。整個設計理念這塊我覺得概括起來就是“一個中心，三個原則”。一個中心就是以對話為中心，這句話大家可能覺得有點莫名其妙，你做對話的，為何還要強調以對話為中心呢？
這是有來源的，因為在過去幾年全世界範圍的技術實踐以及直到今天很多巨頭的對話平台裡面，我們能看到的基本還是以意圖為中心的設計模式，它把意圖平鋪在這裡，比如你想完成音樂領域的一些事情，可是你看到的其實是一堆平鋪的意圖清單，完全看不出對話在哪裡。
我們在這次對話工廠的設計中徹底把它扭轉回來，對話就是要以對話為中心，你在我們的産品界面裡面看到的不再是一個個孤立的意圖，而是關聯在一起的、有業務邏輯關系的對話流程。以意圖為中心的設計中，你看到的其實是一個局部視角，就隻能實作一些簡單的任務，比如控制一個燈，講個笑話，或者查個天氣，如果你想實作一個複雜的任務，比如開一個發票，或者去 10086 裡開通一個套餐，它其實是較難實作，很難維護的。我們把整個理念轉換一下，回到以對話為中心以後，就會看到全局視野，可以去做複雜的任務，可以去做無限的場景。
整個對話工廠剛剛也說過了，它是一個平台，要做一個平台就會遇到很多挑戰。
第一個挑戰就是對使用者來說，希望使用門檻越低越好；第二個挑戰是要面對各行各業的各種場景，就要求能做到靈活定制；第三個挑戰是上線以後所有的使用者肯定都希望你的機器人，你的對話系統能夠越用越好，而不是停留在某一個水準就不動了。這就是我們平台所面臨的三大挑戰。
為了應對這三個挑戰，我們提出了在整個平台的設計以及實作過程中始終要遵循三個原則。
第一個原則是冷啟動要快，其實就是要讓使用者的使用門檻低一點；第二個原則是要有靈活定制的能力，隻有這樣才能滿足各行各業的各種場景需求；第三個是要有魯棒進化的能力，就是模型上線以後，随着時間的變化，随着各種資料的不斷回流，模型效果要不斷提升。
這三個原則裡面，冷啟動這一塊，其實就是要把使用者用到的各種能力和各種資料都盡量變成一種預置的能力，簡單來說就是平台方做得越多，使用者就做得越少；第二塊關于靈活定制，就要求我們把整個對話平台的基礎元素進行高度抽象，你抽象的越好就意味着你平台的适應能力越好，就像是經典力學隻要三條定律就夠了；第三塊就是魯棒進化，這一塊就是要在模型和算法上做深度了，語言了解的模型，對話管理的模型，資料閉環，主動學習，在這些方面能夠做出深度來。
以上說的都是一些理念和原則，接下來給大家介紹一下具體在實作過程中是怎麼來做的。
核心技術
講到技術這塊的話，因為我們做的是一個平台，涉及到的技術非常廣，是全棧的技術，從算法到工程到前端到互動所有的技術都會涉及到。我摘取裡面算法的核心部分來給大家做一個介紹。
對話工廠首先是用來做對話的，人機對話有兩個主體，一個是人，一個是機器，人有人的邏輯，人的邏輯使用什麼來表達呢？到今天為止主要還是通過語言，是以我們需要有一個語言了解的服務來承載這一塊；機器有機器的邏輯，機器的邏輯到今天為止還是通過代碼來表達的，是以我們需要一個函數計算的服務；在人和機器對話的過程中，這種對話過程需要有效的管理，是以我們需要一個對話管理子產品。整個對話工廠最核心的三個子產品就是語言了解、對話管理和函數計算。
第一個子產品是語言了解。
我們先看一下這個圖，在整個這個圖裡面，橫軸是意圖的多樣性，縱軸是頻次，這樣說有點抽象，我舉一個具體的例子，比如說我要開發票，這是一個意圖，如果去采樣十萬條這個意圖的使用者說法作為樣本，把這些說法做一個頻率統計，可能排在第一位的就是三個字“開發票”，它可能出現了兩萬次，另外排在第二位可能是“開張發票”，它可能出現了八千次，這些都是一些高頻的說法，還有一些說法說的很長，比如“昨天我在你們商鋪買了一條紅色的裙子，你幫我開個發票呗”，這種帶着前因後果的句式，在整個說法裡面是比較長尾的，可能隻出現了一次或兩次。
我們統計完以後，整個意圖的說法的多樣性分布符合幂律分布。這種特征可以讓我們在技術上進行有效的針對性設計，首先針對這種高頻的部分，我們可以上一些規則，比如上下文無關文法，可以比較好的 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 月份上的，是屬于新零售的一個最大的嘗試點，還有很多其他的場景。
在釘釘上，通過智能工作助理，對話工廠為千萬企業提供智能考勤、智能人事等對話服務。
最後看一下我們整體的落地情況。目前整個對話工廠在阿裡巴巴經濟體内部各業務（如淘寶、優酷、盒馬等）、淘寶天貓上的商家、釘釘千萬量級的企業、公有雲企業、私有雲重點行業（政務行業、營運商行業、金融行業等）、國際化（東南亞新加坡、印尼、越南、泰國、菲律賓、馬來西亞等6國）等業務中開始大規模應用，賦能各行各業開發者自主建構對話機器人。
原文連結：
https://mp.weixin.qq.com/s/X0X6jmwxli_XCqikPQJLew