如何開發“智能助理”平臺

林琳

一個合格的智能助理能夠幫你預約開會時間，處理日常辦公需求，還能打電話提醒你還信用卡，作為用戶或者消費者，我們已經越來越習慣對話機器人提供的各色服務。但對于企業來講，搭建提供這些服務的對話機器人是一件門檻和成本都很高的事情。阿里巴巴達摩院小蜜Conversational AI團隊的高級算法專家李永彬享了小蜜智能對話開發平臺。圍繞平臺來源、設計理念、核心技術、業務落地四大維度講述了如何賦能各行各業開發自己的對話機器人。

平臺由來

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

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

所有這些場景落地到小蜜家族的時候，是通過三大小蜜來承載：阿里小蜜、店小蜜和云小蜜。我們不可能給每一個行業的每一個場景去定制一個對話流程，所以就沿用了阿里巴巴一貫做平臺的思路，這也是我們整個智能對話開發平臺的由來。這款產品在內部的名字叫對話工廠（Dialog Studio）。

以上主要是給大家介紹我們為什么要做智能對話開發平臺，總結起來就是我們目前面臨的業務，面臨的場景太寬泛了，不可能鋪那么多人去把所有的場景都定制化，所以我們需要有一個平臺，讓開發者進來開發各行各業的各種場景對話。

設計理念

再看第二部分，對話工廠的一些核心設計理念。整個設計理念，我覺得概括起來就是“一個中心，三個原則”。一個中心就是以對話為中心，這句話大家可能覺得有點莫名其妙，你做對話的，為何還要強調以對話為中心呢？

這是有來源的，因為在過去幾年全世界范圍的技術實踐以及直到今天很多巨頭的對話平臺里面，我們能看到的基本還是以意圖為中心的設計模式，它把意圖平鋪在這里，比如你想完成音樂領域的一些事情，可是你看到的其實是一堆平鋪的意圖列表，完全看不出對話在哪里。

在這次對話工廠的設計中徹底把它扭轉回來，對話就是要以對話為中心，你在我們的產品界面里面看到的不再是一個個孤立的意圖，而是關聯在一起的、有業務邏輯關系的對話流程。以意圖為中心的設計中，你看到的其實是一個局部視角，就只能實現一些簡單的任務，比如控制1個燈，講個笑話，或者查個天氣，如果你想實現1個復雜的任務，比如開1張發票，或者去10086開通一個套餐，它其實是較難實現，很難維護的。我們把整個理念轉換一下，回到以對話為中心以后，就會看到全局視野，可以去做復雜的任務，可以去做無限的場景。

整個對話工廠它是一個平臺，要做一個平臺就會遇到很多挑戰。

第1個挑戰就是用戶使用門檻越低越好；第2個挑戰是要面對各行各業的各種場景，就要求能做到靈活定制；第3個挑戰是上線以后所有的用戶肯定都希望你的機器人，你的對話系統能夠越用越好，而不是停留在某一個水平就不動了。這就是我們平臺所面臨的三大挑戰。

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

第1個原則是冷啟動要快，其實就是要讓用戶的使用門檻低一點；第2個原則是要有靈活定制的能力，只有這樣才能滿足各行各業的各種場景需求；第3個是要有魯棒進化的能力，就是模型上線以后，隨著時間的變化，隨著各種數據的不斷回流，模型效果要不斷提升。

這3個原則里面，冷啟動這一塊，其實就是要把用戶用到的各種能力和各種數據都盡量變成一種預置能力，簡單來說就是平臺方做得越多，用戶就做得越少；第二塊關于靈活定制，就要求把整個對話平臺的基礎元素進行高度抽象，抽象的越好就意味著平臺的適應能力越好，就像是經典力學只要3條定律就夠了；第3塊就是魯棒進化，這一塊就是要在模型和算法上做深度，語言理解的模型、對話管理的模型、數據閉環和主動學習，在這些方面能夠做出深度來。

以上說的都是一些理念和原則，接下來給大家介紹一下在實現過程中具體是怎么做的。

核心技術

因為我們做的是一個平臺，涉及到的技術非常廣，從算法到工程到前端到交互所有的技術都會涉及到。摘取里面算法的核心部分來給大家做一個介紹。

對話工廠首先是用來做對話的，人機對話有2個主體，一個是人，一個是機器，人有人的邏輯，人的邏輯使用什么來表達呢？到今天為止主要還是通過語言，所以我們需要有一個語言理解的服務來承載這一塊；機器有機器的邏輯，機器的邏輯到今天為止還是通過代碼來表達的，所以我們需要一個函數計算的服務；在人和機器對話的過程中，這種對話過程需要有效的管理，所以我們需要一個對話管理模塊。整個對話工廠最核心的3個模塊就是語言理解、對話管理和函數計算。

1.語言理解。

舉一個具體的例子，比如說我要開發票，這是一個意圖，如果去采樣十萬條這個意圖的用戶說法作為樣本，把這些說法做一個頻率統計，可能排在第一位的就是三個字“開發票”，它可能出現了兩萬次，另外排在第二位可能是“開張發票”，它可能出現了八千次，這些都是一些高頻的說法，還有一些說法說的很長，比如“昨天我在你們商鋪買了一條紅色的裙子，你幫我開個發票唄”，這種帶著前因后果的句式，在整個說法里面是比較長尾的，可能只出現了一次或兩次。

我們統計完以后，整個意圖的說法多樣性分布符合冪律分布。這種特征可以讓我們在技術上進行有針對性的設計，首先針對這種高頻的部分，可以上一些規則，比如上下文無關文法，可以比較好的覆蓋這一塊，但是基于規則的方法，大家也知道，規則是沒有泛化能力的，所以這時候要上一個匹配模型，計算一個相似度來輔助規則，這2塊結合在一起就可以把我們高頻確定性的部分解決得比較好；對于長尾的多樣性這部分，基本到今天為止還是用有監督的分類模型，去收集或者去標注很多數據，把這一塊做好；在規則和分類模型之間，又做了一部分工作，就是遷移學習模型，為什么要引入這個模型呢？

在冷啟動階段，用戶在錄入樣本的時候，不會錄入太多，可能錄入十幾條幾十條就已經很多了，這個時候按照二八原則的話，它的效果可能也就是70 %多，不可能再高了。但對于用戶的期望來說，如果想要上線，想要很好地滿足用戶需求，其實是需要模型效果在90 %以上，如果想要達到這個效果，就需要復雜的模型，需要標注大量數據。這樣其實是存在缺口的，所以我們引入遷移學習模型。

具體來說，我們把膠囊網絡引進來和few-shot learning結合在一起，提出了一個網絡結構叫Induction Network，就是歸納網絡。整個網絡結構有3層：一層是編碼層；第二層是歸納層；第三層是交互層。

第一層負責將每一個類的每一個樣本進行編碼，編碼成一個向量；第二層是最核心的一層，也就是歸納層，這里面利用膠囊網絡的一些方法，把同一類的多個向量歸納成一個向量；然后第三層交互層把用戶的話和每個類的歸納向量進行關系計算，輸出他們的相似性打分。如果我們想要一個分類結果就輸出一個獨熱碼，如果不想要獨熱碼，就輸出一個關系的關聯分數，這是整個歸納網絡的網絡結構。

這個網絡結構提出來以后，在學術圈里面關于few-shot learning的數據集上，我們以比較大的提升幅度做到了趨于最高期望值的效果，目前是業界領先的，同時我們將整個網絡結構上線到了我們的產品里面。

2.對話管理。

如果想要讓平臺有足夠的適應性的話，那么它的抽象能力一定要好。對話管理是做什么的？對話管理就是管理對話的，那么對話是什么呢？對話的最小單位就是一輪，一輪又分為兩部分，一個叫對話輸入，一個叫對話輸出。在輸入和輸出中間，有一個對話處理的過程，就像2個人互相交流一樣，你在答之前是有一個思考過程的，如果你不思考就回答，那你的答案就沒有質量，所以就會有一個中間的對話處理過程。

我們把對話抽象到這種程度以后，整個平臺就3個節點：觸發節點、函數節點和回復節點。

觸發節點是和用戶的對話輸入對應的，函數節點是和對話處理對應的，回復節點是和對話輸出對應的。有了這層抽象以后，無論是什么行業的什么場景，什么樣的對話流程，都可以通過這3個節點用連線的方法把業務流畫出來。

舉2個例子，第一個場景是查天氣，很簡單，先來一個觸發節點，把天氣流程觸發起來，中間有2個函數節點，一個是調中央氣象臺的接口，把結果拿過來，另一個是對結果進行一次解析和封裝，以一個用戶可讀的形式通過回復節點回復給用戶。這里面增加了一個填槽節點，就是在任務型對話里面，任務需要收集用戶的信息，比如要查天氣，就需要問時間是哪一天，地點是哪里，這就叫做填槽。因為常用、普遍，符合冷啟動里面做預置的思想，所以通過3個基礎節點，把它搭建成填槽模板，需要填槽的時候，從頁面上拖一個填槽節點出來就可以了。

另一個復雜的場景，這是在線教育里面的一個外呼場景，在上課之前半小時，機器人就會主動給用戶打電話，指導軟件下載，指導怎么登陸，登陸進去以后怎么進入教室，所有的這些流程都可以通過機器人進行引導。

通過這2個例子可以看到，無論是簡單還是復雜的場景，通過這3種抽象節點的連線都可以實現。有時候我們開玩笑說，這種連線就叫“一生二，二生三，三生萬千對話”。

講了抽象以后，再看一下具體的對話管理技術。從實現上來說和語言理解是一模一樣的，因為很多東西的分布其實遵循著共同規律，區別在于把意圖換成了對話。

比如像查天氣，如果采集十萬個查天氣的樣本，對這些用戶的說法進行頻率統計的話，大概就是一個曲線，用2步能夠完成：先填槽一個時間，再填槽一個地點，然后返回一個結果，通過這種流程來完成的，可能有2萬次；中間可能會引入一些問A答B的情況，這樣的B可能有各種各樣的，這就跑到長尾上來了，這樣整個對話其實也遵循冪律分布。

對于高頻確定的部分，可以用狀態機進行解決，但狀態機同樣面臨一個問題，它沒有很好的容錯能力，當問A答B的時候，機器不知道怎么處理。在這種情況下，需要引入類人能力，對狀態機的能力進行補充，狀態機加上類人能力以后，基本上可以高頻對話比較好地解決。對于長尾對話，目前整個學術界或者工業界都是一個難題，比較好的解決方式就是上線以后引入在線交互學習，不斷地與用戶在對話過程中學習對話。在狀態機和在線交互學習之間其實是有缺口的，因為狀態機自己沒有學習能力，所以需要引入增強學習。

先看一下類人能力。我們把人說的話大概可以分為3種：第一種就是用戶說話清晰明了只有一個意思，這種其實對機器來說是可理解的；第二種機器不知道用戶在說什么，也就是不可理解的；還有一種就是用戶表達的意思可以理解，但是有歧義，有可能包含著2～3個意圖，就是不確定的。確定性的狀態機其實是可以很好地捕捉和描述意圖的，類人能力主要關注拒識的和不確定性的。

對于拒識，還是在線英語的這個例子，機器人打來電話，問現在方不方便調試設備，從設計的角度來說希望用戶回答方便或者不方便就可以了，但是如果這個用戶回答了一句比較個性化的話，比如，“呃，我剛掃完地，過會兒可能有人要來”，語言理解模塊就很難捕捉到這是什么語義，這時候需要引入一個個性化的拒識，比如說，“您好，不好意思，剛才沒聽明白，請問您現在是否方便調試，如果您不方便，我過會兒再給您打過來”，這個就是對話的兜底，是對不可理解的處理。

第二個看一下澄清，用戶說的一句話里，如果模糊不清怎么辦？我們通過大量的數據分析發現這種模糊不清主要出現在2種情況下：一種是用戶把多個意圖雜糅在一段話里來表達；第二種是用戶在表達一個意圖之前做了很長的鋪墊，對于這2種長句子現在的語言理解給出的是意圖概率分布，我們把這個概率分布放到對話管理模塊以后，就需要讓用戶進行一輪澄清。比如舉個移動領域的例子，明細這句話理解有三種意圖，到底是想問花費明細，還是套餐的事情，還是想問合約的低保，把這3個問題拋給用戶進行澄清就可以了。

從技術上來說是怎么實現的呢，開發者負責把對話用流程清晰描述出來，然后像問題澄清能力其實是我們系統的一種內置能力，什么時候澄清是通過下端2個引擎的能力來決定的，第一塊是錯誤檢測，它用來檢測用戶當前說的這句話是否需要觸發澄清，一旦它覺得要觸發澄清，就會交給下一個模塊，究竟用什么樣的方式澄清以及怎么生成澄清的話術，這是目前整個智能澄清方面要做的工作。

再看一下增強學習方面的工作。在對話管理模型里面，分成2個經典模塊：一個是神經信念跟蹤器，用來做對話狀態追蹤；另一個是策略網絡，用來做行為決策。在整個框架下，要去訓練這個網絡的時候，有2種訓練方式：一種是端到端的去訓練，用增強學習去訓練，但這種方式一般收斂速度會比較慢，訓練出的結果也不好；另外一種方式是先分別做預訓練，這個時候用監督學習訓練就好了，不用增強學習訓練，訓練完以后再用增強學習對監督學習預訓練的模型進行調優就可以了。

無論是端到端的一步訓練還是先預訓練再調優，只要涉及增強學習這塊，都需要有一個外部環境，所以在我們架構里引入了模擬器的概念，就是用戶模擬器。模擬器主要分為三大塊：第一個是用戶模型，用來模擬人的行為的；第二個是誤差模型，模擬完人的行為以后經過誤差模型引入一個錯誤擾動，用誤差模型產出的只是一個概率為1的東西，它對網絡訓練不夠好，誤差模型會對這個結果進行擾動并給他引進幾個其他的結果，并且把概率分布進行重新計算，這樣訓練出的模型在擴展能力或者泛化能力上會更好些；第三個模塊是激勵模型，用來提供激勵值。這是我們現在在整個增強學習對話管理這塊的工作。

函數計算是什么？還是舉一個例子，比如說，10086用戶說要查一下話費，10086那邊的機器人就會回復一句是發短信還是播放語音，表面看來就是簡單的一入一出，其實在這背后要經過多輪的服務查詢，才能完成。因為當要查話費的時候，先要經過函數計算查一下現在是哪一天，如果是下賬期也就是每個月的最后一天是不能查話費的。如果可以查話費的話，先看一下用戶是否存在話費，如果存在第三步調用服務看是否停機，因為停機的話只能語音播報不能接收短信。所以在簡單的一入一出的對話背后，是一個復雜流程的，這些流程現在都是在機器端用代碼來實現的。函數計算的引入，使對話工廠可以去處理復雜的任務。

業務應用

最后看一下對話工廠的業務應用情況。例如我們在浙江上線的114移車，當有市民舉報違規停車擋路后，就會自動打電話讓他移車。第二個是在金融領域里面關于貸款催收的例子。在剛剛過去的雙十一，對話工廠在整個電商里面也有大量應用，主要是在店小蜜和阿里小蜜里面。

店小蜜主要是一些開發票、催發貨和改地址這樣的流程。例如開發票，用戶可能會先說一個開發票，進來以后要進行復雜的流程，一種是在說的時候其實他已經把它的訂單號送進來了：另一種是沒有說訂單號，這時就需要去后臺系統查訂單號，查出來以后彈一個訂單選擇器選擇訂單。其次問是個人發票還是公司發票。然后會問是普通發票還是增值稅發票，如果是普通發票接著往下走，如果是增值稅發票需要獲取企業增值稅的稅號，最后匯總到一個節點，調用后臺開發票的系統，把發票開出來。

阿里小蜜主要是負責阿里巴巴集團內部各個BU的業務，手機淘寶是一個最大的業務，進入手機淘寶以后，進入“我的”里面有一個客服小蜜，就是阿里小蜜。我們也在優酷上線了優酷小蜜，星巴克是屬于新零售的一個最大的嘗試點，還有很多其他的場景。

在釘釘上，通過智能工作助理，對話工廠為千萬企業提供智能考勤、智能人事等對話服務。

最后是整體的落地情況。目前整個對話工廠在阿里巴巴經濟體內部各業務（如淘寶、優酷和盒馬等）、淘寶天貓上的商家、釘釘千萬量級的企業、公有云企業、私有云重點行業（政務行業、運營商行業、金融行業等）和國際化（東南亞新加坡、印尼、越南、泰國、菲律賓和馬來西亞等國家地區）等業務中開始大規模應用，賦能各行各業開發者自主構建對話機器人。