過去 20 多年，互聯網及移動互聯網將人類帶到了一個全新的時代，如果用一個詞來總結和概括這個時代的話，「連接」這個詞再合適不過。這個時代主要建立了四種連接：第一，人和商品的連接；第二，人和人的連接；第三，人和信息的連接；第四，人和設備的連接。

「連接」本身不是目的，它只是為「交互」建立了通道。在人機交互（Human-Computer Interaction）中，人通過輸入設備給機器輸入相關信號，這些信號包括語音、文本、圖像、觸控等中的一種模態或多種模態，機器通過輸出或顯示設備給人提供相關反饋信號。「連接」為「交互」雙方架起了橋梁。

「交互」的演進方向是更加自然、高效、友好和智能。對人來說，采用自然語言與機器進行智能對話交互是最自然的交互方式之一，但這條路上充滿了各種挑戰。

如何讓機器理解人類復雜的自然語言？如何對用戶的提問給出精準的答案而不是一堆候選？如何更加友好地與用戶閑聊而不是答非所問？如何管理復雜的多輪對話狀態和對話上下文？

在阿里巴巴，我們從 2014 年初開始對智能對話交互進行探索和實踐創新，研發成果逐步大規模應用在了智能客服（針對阿里巴巴生態內部企業的阿里小蜜、針對阿里零售平臺上的千萬商家的店小蜜，以及針對阿里之外企業及政府的云小蜜等）和各種設備（如 YunOS 手機、天貓魔盒、互聯網汽車等）上。

本文將對阿里巴巴在智能對話交互技術上的實踐和創新進行系統的介紹。首先簡要介紹智能對話交互框架和主要任務；接下來詳細介紹自然語言理解、智能問答、智能聊天和對話管理等核心技術；然后介紹阿里巴巴的智能對話交互產品；最后是總結和思考。

智能對話交互框架

典型的智能對話交互框架如圖 1 所示。其中，語音識別模塊和文本轉語音模塊為可選模塊，比如在某些場景下用戶用文本輸入，系統也用文本回復。自然語言理解和對話管理是其中的核心模塊，廣義的自然語言理解模塊包括對任務類、問答類和閑聊類用戶輸入的理解，但在深度學習興起后，大量端到端（End-to-End）的方法涌現出來，問答和聊天的很多模型都是端到端訓練和部署的，所以本文中的自然語言理解狹義的單指任務類用戶輸入的語義理解。在圖 2 所示的智能對話交互核心功能模塊中，自然語言理解和對話管理之外，智能問答用來完成問答類任務，智能聊天用來完成閑聊類任務。在對外輸出層，我們提供了 SaaS 平臺、PaaS 平臺和 Bot Framework 三種方式，其中 Bot Framework 為用戶提供了定制智能助理的平臺。

圖1 智能對話交互框架

智能對話交互核心技術

智能對話交互中的核心功能模塊如圖 2 所示，本部分詳細介紹智能對話交互中除輸出層外的自然語言理解、智能問答、智能聊天和對話管理四個核心模塊。

圖2 智能對話交互中的核心功能模塊

自然語言理解

自然語言理解是人工智能的 AI-Hard 問題 [1]，也是目前智能對話交互的核心難題。機器要理解自然語言，主要面臨語言的多樣性、語言的多義性、語言的表達錯誤、語言的知識依賴和語言的上下文（示例見表 1）的五個挑戰。

表 1 上下文示例

整個自然語言理解圍繞著如何解決以上難點問題展開。

自然語言理解語義表示

自然語言理解的語義表示主要有分布語義表示 (Distributional semantics)、框架語義表示 (Frame semantics) 和模型論語義表示 (Model-theoretic semantics) 三種方式 [2]。

在智能對話交互中，自然語言理解一般采用的是 frame semantics 表示的一種變形，即采用領域（domain）、意圖（intent）和屬性槽（slots）來表示語義結果，如圖 3 所示。

圖3 domain ongology 示意圖

在定義了上述的 domain ontology 結構后，整個算法流程如圖 4 所示。

圖4 自然語言理解流程簡圖

意圖分類

意圖分類是一種文本分類，主要分為基于規則的方法、基于傳統機器學習的方法和基于深度學習的方法，如 CNN[3]、LSTM[4]、RCNN[5]、C-LSTM[6] 及 FastText[7] 等。針對 CNN、LSTM、RCNN、C-LSTM 四種典型的模型框架，我們在 14 個領域的數據集上進行訓練，在 4 萬左右規模的測試集上進行測試，采用 Micro F1 作為度量指標（注：此處的訓練和測試中，神經網絡的輸入只包含 word embedding，沒有融合符號表示），結果如圖 5 所示，其中 Yoon Kim 在 2014 年提出的基于 CNN[3] 的分類算法效果最好。

圖5 四種模型的分類效果對比

單純以 word vector 為輸入的 CNN 分類效果，在某些領域上無法超越復雜特征工程的 SVM 分類器。如何進一步提升深度學習的效果，其中一個探索方向就是試圖把分布式表示和符號表示進行融合。比如對于「劉德華的忘情水」這句話，通過知識庫可以標注劉德華為 singer、忘情水為 song，期望能把 singer 和 song 這樣的符號表示融入到網絡中去。具體融合方法，既可以把符號標簽進行 embedding，然后把 embedding 后的 vector 拼接到 word vector 后進行分類，也可以直接用 multihot 的方式拼接到 word vector 后面。分布式表示和符號表示融合后的 CNN 結構如圖 6 所示。

圖6 分布式表示和符號表示融合后的 CNN 分類網絡結構

經過融合后，在 14 個領域約 4 萬條測試數據集上，對比融合前后的 F1 值（如圖 7 所示），從中可以看出，像餐廳、酒店、音樂等命名實體多且命名形式自由的領域，效果提升非常明顯。

圖7 在 CNN 中分布式表示融合符號表示前后效果對比

在以詞為輸入單位的 CNN 中，經常會遇到 OOV（Out-Of-Vocabulary）問題，一般情況下會使用一個特殊向量（比如固定的隨機向量或者已知詞向量的平均值）來表示所有的 OOV，這樣做的效果肯定不夠好。在我們的實現中，引入了 FastText[8] 來訓練 word vector，對于 OOV，可以用其 subword 向量計算得到，有效地解決了 OOV 的問題。

在 效 果 優 化 方 面，除了本文中所述的 word vector 的動態訓練和 dropout 之外，通過對訓練數據進行數據增強（data augmentation），效果會有較大的提升。

屬性抽取

屬性抽取問題可以抽象為一個序列標注問題，可以以字為單位進行序列標注，也可以以詞為單位進行序列標注，如圖 8 所示為以詞為單位進行序列標注的示例。在這個例子中包含 departure、destination 和 time 三個待標注標簽；B 表示一個待標注標簽的起始詞；I 表示一個待標注標簽的非起始詞，O 表示非待標注標簽詞。

圖8 序列標注示例

屬性抽取的方法，包括基于規則的方法和基于傳統統計模型的方法，經典的如 CRF[9]，以及基于深度學習模型的方法。

2014 年，在 ARTIS 數據集上，RNN[10] 模型的效果超過了 CRF。此后，R-CRF [11]、LSTM[12]、Bi-RNN[13]、 Bi-LSTM-CRF[14] 等各種模型陸續出來。

在屬性抽取這個任務中，我們采用了如圖 9 的網絡結構，該結構具有以下優點。

圖9 屬性抽取網絡結構

輸入層

在輸入層，我們做了三部分工作：① 采用了分布式表示（word vector）和符號表示（symbol vector）融合的方式，有效利用了分布式的上下文學習能力和符號的抽象知識表示能力；② 采用了局部上下文窗口（localcontext window），將窗口內的詞的表示拼接在一起送入一個非線性映射層，非線性映射具有特征學習和特征降維的作用；③ 采用了 FastText [8] 進行 word embedding 的學習，可以有效解決 OOV 的問題。

Bi-LSTM 層

在中間的隱藏層，采用 Bi-LSTM 進行特征學習，既能捕捉上文特征，也能捕捉下文特征。

輸出層

在輸出層有幾種典型的做法，比如 Bi-LSTM+Softmax、Bi-LSTM+CRF 等，Bi-LSTM+Softmax 是把屬性抽取在輸出層當成了一個分類問題，得到的標注結果是局部最優，Bi-LSTM+CRF 在輸出層會綜合句子層面的信息得到全局最優結果。

意圖排序

在表1 中，我們展示了一個例子，如果不看上下文，無法確定「后天呢」的意圖。為了解決這個問題，在系統中我們設計了意圖排序模塊，其流程如圖 10 所示。對于用戶輸入的 utterance，一方面先利用分類抽取模型去判定意圖并做抽取；另一方面，直接繼承上文的意圖，然后根據這個意圖做屬性抽取。這兩個結果通過特征抽取后一起送入一個 LR 分類器，以判定當前 utterance 是應該繼承上文的意圖，還是遵循分類器分類的意圖。如果是繼承上文意圖，那么可以把這個意圖及其屬性抽取結果作為最終結果輸出；如果是遵循分類器分類的結果，那么可以把各個結果按照分類器分類的置信度排序輸出。

圖10 基于上下文的意圖延續判定

智能問答

在具體的業務場景中有三種典型的問答任務，一是用戶提供 QA-Pairs，一問一答；二是建立結構化的知識圖譜，進行基于知識圖譜的問答；三是針對非結構化的文本，進行基于閱讀理解的問答。本文重點介紹我們在閱讀理解方面做的工作，比如利用閱讀理解解決淘寶活動規則的問答。

在閱讀理解的方法上，目前針對斯坦福大學的數據集 SquAD，有大量優秀的方法不斷涌現，比如 match-LSTM[15]、BiDAF[16]、DCN[17]、 FastQA[18] 等。文獻 [18] 給出了目前的通用框架，如圖 11 所示，主要分為 4 層：① Word Embedder，對問題和文檔中的詞進行 embedding；② Encoder，對問題和文檔進行編碼，一般采用 RNN/LSTM/BiLSTM； ③ Interaction Layer（交互層），在問題和文檔之間逐詞進行交互，這是目前研究的熱點，主流方法是采用注意力機制（attention）；④ Answer Layer（答案層），預測答案的起始位置和結束位置。

圖11 閱讀理解的通用框架

我們在具體實現中，參考 BiDAF[16] 網絡結構，在此基礎上做了大量優化。

模型的業務優化

需要改進模型的結構設計，使得模型可以支持電商文檔格式的輸入。電商規則文檔往往包含大量的文檔結構，如大小標題和文檔的層級結構等，將這些特定的篇章結構信息一起編碼輸入到網絡中，將大幅提升訓練的效果。

模型的簡化

學術文獻中的模型一般都較為復雜，而工業界場景中由于對性能的要求，無法將這些模型直接在線上使用，需要做一些針對性的簡化，使得模型效果下降可控的情況下，盡可能提升線上預測性能，例如可以簡化模型中的各種 bi-lstm 結構。

多種模型的融合

當前這些模型都是純粹的 end-to-end 模型，其預測的可控性和可解釋性較低，要適用于業務場景的話，需要考慮將深度學習模型與傳統模型進行融合，達到智能程度和可控性的最佳平衡點。

智能聊天

面向 open domain 的聊天機器人目前無論在學術界還是在工業界都是一大難題，目前有兩種典型的方法：一是基于檢索的模型，比如文獻 [19-20]，其基本思路是利用搜索引擎通過計算相關性來給出答案；二是基于 Seq2Seq 的生成式模型，典型的方法如文獻 [21-22]，其網絡結構如圖 12 所示。

圖12 Seq2Seq 典型網絡結構

檢索模型的優點是答案在預設的語料庫中，可控，匹配模型相對簡單，可解釋性強；缺點是在一定程度上缺乏對語義的理解，且有固定語料庫的局限性，長尾問題覆蓋率較差。生成模型的優點是通過深層語義方式進行答案生成，答案不受語料庫規模限制；缺點是模型的可解釋性不強，且難以保證回答一致性和合理性。

在我們的聊天引擎中，結合檢索模型和生成模型各自的優勢，提出了一種新的模型 AliMe Chat [23]，基本流程如圖 13 所示。首先采用檢索模型從 QA 知識庫中找出候選答案集合； 然后利用帶注意力的 Seq2Seq 模型對候選答案進行排序，如果第一候選的得分超過某個閾值，則作為最終答案輸出，否則利用生成模型生成答案。其中帶注意力的 Seq2Seq 模型結構如圖 14 所示。經過訓練后，主要做了如下測試：如圖 15 所示，利用 600 個問題的測試集，測試了檢索（IR）、生成（Generation）、檢索+ 重排序（Rerank）及檢索+ 重排序+ 生成（IR+Rerank+Generation）四種方法的效果，可以看到在閾值為 0.19 時，IR+Rerank+Generation 的方法效果最好。

圖13 AliMe Chat 流程圖

圖14 帶注意力的 Seq2Seq 網絡結構示例

圖15 IR、Generation、Rerank、IR+Rerank+Generation 效果對比

此模型在阿里小蜜中上線，示例如圖 16 所示。在阿里小蜜中，針對之前的 IR 模型和 AliMe Chat 模型，利用線上流量做了 A/B Test，結果如表 2 所示。從用戶日志中隨機選擇 2 136 條數據，其中 1 089 是采用 IR 模型回答，另外 1 047 是采用 AliMe Chat 回答，AliMe Chat Top1 答案的準確率（accuracy）是 60.36%，遠遠好于 IR 的 40.86%。

圖16 AliMe Chat 在阿里小蜜中上線后的聊天示例

表 2 阿里小蜜中 IR 方法與 AliMe Chat 方法 A/B Test 結果

對話管理

對話管理根據語言理解的結構化語義表示結果以及上下文，來管理整個對話的狀態，并決定下一步采取什么樣的動作。

下面來看一個簡單的對話例子。

對話交互分成兩個階段，第一階段，通過多輪對話交互，把用戶的需求收集完整，得到結構化的信息（出發地、目的地、時間等）；第二階段就是請求服務，接著還要去做選擇、確定、支付、購買等后面一系列的步驟。

傳統的人機對話，包括現在市面上常見的人機對話，一般都是只在做第一階段的對話，第二階段的對話做得不多。對此，我們設計了一套對話管理體系，如圖 17 所示，這套對話管理體系具有以三個特點。

圖17 對話管理框架圖

第一，設計了一套面向 Task Flow 的對話描述語言。該描述語言能夠把整個對話任務流完整地表達出來，這個任務流就是類似于程序設計的流程圖。對話描述語言帶來的好處是它能夠讓對話引擎和業務邏輯實現分離，分離之后業務方可以開發腳本語言，不需要修改背后的引擎。

第二，由于有了 Task Flow 的機制，我們在對話引擎方帶來的收益是能夠實現對話的中斷和返回機制。在人機對話當中有兩類中斷，一類是用戶主動選擇到另外一個意圖，更多是由于機器沒有理解用戶話的意思，導致這個意圖跳走了。由于我們維護了對話完整的任務流，知道當前這個對話處在一個什么狀態，是在中間狀態還是成功結束了，如果在中間狀態，我們有機會讓它回來，剛才講過的話不需要從頭講，可以接著對話。

第三，設計了對話面向開發者的方案，稱之為 Open Dialog，背后有一個語言理解引擎和一個對話引擎。面向開發者的語言理解引擎是基于規則辦法，能夠比較好地解決冷啟動的問題，開發者只需要寫語言理解的 Grammar，基于對話描述語言開發一個對話過程，并且還有對數據的處理操作。這樣，一個基本的人機對話就可以完成了。

阿里智能對話交互產品

智能服務——小蜜家族

2015 年 7 月，阿里巴巴推出了自己的智能服務助理——阿里小蜜，一個圍繞著電子商務領域中的服務、導購，以及任務助理為核心的智能對話交互產品。通過電子商務領域與智能對話交互領域的結合，帶來傳統服務行業模式的變革與體驗的提升。在 2016 年的「雙十一」期間，阿里小蜜整體智能服務量達到 643 萬，其中智能解決率達到 95%，智能服務在整個服務量 ( 總服務量= 智能服務量+ 在線人工服務量+ 電話服務量) 占比也達到 95%，成為了「雙+ 十一」期間服務的絕對主力。阿里小蜜主要服務阿里國內業務和阿里國際化業務，國內業務如淘寶、天貓、飛豬、健康、閑魚、菜鳥等，國際化業務如 Lazada、PayTM、AE 等。

隨著阿里小蜜的成功，將智能服務能力賦能給阿里生態圈商家及阿里生態之外的企業和政府部門，便成了必然的路徑。店小蜜主要賦能阿里生態中的商家，云小蜜則面向阿里之外的大中小企業、政府等。整個小蜜家族如圖 18 所示。

圖18 小蜜家族

智能設備

過去 3~4 年，我們可以看到，連接互聯網的設備發生了很大變化，設備已經從 PC 和智能手機延伸到更廣泛的智能設備，比如智能音箱、智能電視、機器人、智能汽車等設備。智能設備的快速發展正在改變著人和設備之間的交互方式。

我們研發的智能對話交互平臺為各種設備提供對話交互能力，目前在 YunOS 手機、天貓魔盒、互聯網汽車等設備上已經大量應用。比如在天貓魔盒中，用戶通過對話交互可以完成搜視頻、查音樂、問天氣等，可以進行閑聊，還可以進行購物。

總結與思考

過去幾年中，結合阿里巴巴在電商、客服、智能設備方面的剛性需求和場景，我們在智能對話交互上做了大量的探索和嘗試，構建了一套相對完整的數據、算法、在線服務、離線數據閉環的技術體系，并在智能服務和智能設備上得到了大規模的應用，簡單總結如下。

（1）自然語言理解方面，通過 CNN/Bi-LSTM-CRF 等深度學習模型、分布式表示和符號表示的融合、多粒度的 wordembedding、基于上下文的意圖排序等方法，構建了規則和深度學習模型有機融合的自然語言理解系統。

（2）智能問答方面，成功的將機器閱讀理解應用在了小蜜產品中。

（3）智能聊天方面，提出了 AliMe Chat 模型，融合了搜索模型和生成模型的優點，大大提高了閑聊的精度。

（4）對話管理方面，設計了基于 Task Flow 的對話描述語言，將業務邏輯和對話引擎分離，并能實現任務的中斷返回和屬性的 carry-over 等復雜功能。

在智能交互技術落地應用的過程，我們也在不斷思考怎么進一步提高智能交互技術水平和用戶體驗。

第一，堅持用戶體驗為先。堅持用戶體驗為先，就是產品要為用戶提供核心價值。第二，提高語言理解的魯棒性和領域擴展性。第三，大力發展機器閱讀理解能力。第四，打造讓機器持續學習能力。第五，打造數據閉環，用數據驅動效果的持續提升。

目前的人工智能領域仍然處在弱人工智能階段，特別是從感知到認知領域需要提升的空間還非常大。智能對話交互在專有領域已經可以與實際場景緊密結合并產生巨大價值，尤其在智能客服領域（如阿里巴巴的小蜜）。隨著人工智能技術的不斷發展，未來智能對話交互領域的發展還將會有不斷的提升。