阿里小蜜這一年，經歷了哪些技術變遷？

04-13

阿里妹導讀：2017年，阿里小蜜從阿里走向行業，逐步賦能商家和企業；從中國開始走向世界，覆蓋英語、葡語、西班牙、印尼語、泰語，賦能AE及Lazada海外業務；從PC、無線走向了PC、無線和熱線，在多端進行賦能；阿里小蜜全面從智能人機交互走向智能人機協同。
今天，我們邀請了小蜜機器人X Lab 資深演算法專家海青，分享小蜜技術演進的一年。

一、生態領域的思考與阿里小蜜平台

1.生態領域的思考

隨著人工智慧在全球領域的持續高漲，chatbot人機交互作為其中一個分支在智能助理、智能服務、IOT等領域進了白熱化競爭態勢，從全球大公司到創業公司紛紛加入戰場並在一些獨特的垂直領域開始精耕細作。在近兩年的人機交互領域的發展中，一方面在To C端面向各個入口領域的競爭更加激烈(例如：在IOT領域的智能音箱)、垂直領域場景更加細分與豐富。另外一方面由To C市場的競爭開始轉向To B市場的競爭，Google、Microsoft、Facebook、Amazon、百度、網易以及眾多startups紛紛在To B領域通過IaaS、PaaS或者SaaS能力開始布局，並且基本圍繞著如下兩個體系進行輸出：

圍繞著IM生態體系的綁定輸出。例如：Facebook在Messager平台上的wit.ai機器人平台輸出、騰訊在微信體端也在逐步開發自己的機器人平台等
面向企業或者開發者領域的獨立三方平台輸出。例如：Amazon的Lex平台、微軟的AI Solution、Google的AI SDK與Api.ai、網易七魚等等

2.面向生態的阿里小蜜平台

在人機交互行業生態領域發展的大背景下，面向智能服務領域，阿里小蜜在這兩年時間同樣在不斷的升級與變遷：

在To C端，持續在智能+人的混合模式上逐步升級，並且把傳統的服務往更大的泛服務領域擴展，除了傳統服務的智能化、還拓展了智能導購服務、智能助理服務，閑聊服務等，以服務為基礎向平台與多領域升級
在To B端，阿里小蜜從淘寶到阿里行業生態、二環商家生態，以及三環企業平台逐步拓展

最終形成了整個阿里小蜜平檯面向阿里生態圈、商家生態圈、企業生態圈的整個體系大圖：

面對消費者：超級小蜜在淘寶生態體系面向服務、導購、助理以及閑聊4個領域逐步進行深入的探索
面對阿里行業生態圈：通過平台化能力賦能阿里集團生態超過30個BU，包含AE、ICBU、1688、菜鳥、飛豬、閑魚、淘票票、阿里內外等
面對商家生態圈：與千牛平台團隊協同，基於IM消息體系，構建店小蜜體系，提供給商家全自動+半自動人工輔助智能對話能力
面對企業生態圈：依託於釘釘企業溝通生態圈的IM消息體系以及阿里雲上的整個企業開放生態，企業小蜜和雲小蜜也踏上了企業賦能之路

在過去的2017年阿里小蜜從阿里走向行業，逐步賦能商家和企業；從中國開始走向世界，覆蓋英語、葡語、西班牙、印尼語、泰語，賦能AE及Lazada海外業務；從PC、無線走向了PC、無線和熱線，在多端進行賦能；阿里小蜜全面從智能人機交互走向智能人機協同。

在過去的2017年阿里小蜜全年服務3.4億名淘寶消費者，其中雙11當天接待人次904萬，智能服務佔比達到95%，智能服務解決率達到93.1%
在過去的2017年賦能商家的店小蜜授權開啟商家數達到30w，其中雙11當天機器人對話量超過1億
在過去的2017釘釘端賦能企業數超過1萬家；2017年10月雲棲大會正式開放雲小蜜，截止到目前賦能Lazada東南亞服務業務，並逐步在多個行業領域與多家大中型企業推進雲化服務體系

小蜜技術這一年

在技術這一端，過去的一年圍繞著平台化和領域化不斷完善和增強整個阿里小蜜平台：

架構體系端：圍繞著SaaS和PaaS體系，逐步將前端和後端體系進行模塊化處理，逐步完善和構建整個平台體系

演算法端：逐步在單個領域結合實際業務場景進行縱深探索，並且不斷進行創新

1.前後端架構體系

前端架構體系

為了快速響應業務以及快速接入其他業務場景，阿里小蜜平台在前端架構上使用的是 WebApp 的技術選型。雖然WebApp在體驗和功能上略遜於 Native App，但在快速響應業務需求和快速接入其他 APP 兩方面相對Native優勢明顯。在經過3個大版本的不斷升級與改造後，形成了按照模塊劃分的7層前端架構體系，如下圖：

行業定製層：不同行業接入阿里小蜜平台，在既定的開放規範下對UI、業務、插件進行定製的模塊
context層：類似 koa.js/express.js 的設計，將 view/util/request/pipeline/channel 等核心模塊掛載到 this 對象上，消息組件、業務模塊等都執行在 this這個 context 中。我們可以輕鬆對 this 進行擴展，以滿足不同業務對於小蜜平台的特殊定製需求
渠道層：用戶的輸入在不同場景會發送給不同的處理對象，我們把處理對象稱之為」渠道「，雖然目前的渠道只有機器人和人工客服，我們在架構上支持任意多個渠道，並且可以輕鬆切換對話渠道
消息層：將「對話」過程中的特定功能都抽象為具有特定消息類型的組件，這些組件在不同的渠道中都可以復用，阿里小蜜平台90%的功能擴展都可以通過消息層輕鬆實現
業務組件層：將」非對話層「的業務都抽象到這層中，提供串列載入、擴展等功能
View層：具有典型 WebIM 功能，提供 Input、output、addPlugin等API
客戶端定製層：適配不同行業業務在不同的APP端的定製層

後端架構體系

面向整個阿里小蜜平台平台化，面向阿里生態圈、商家生態圈和企業生態圈支持以PaaS和SaaS輸出
模塊化整個對話管理和流程模塊化，構建演算法和業務模塊可插拔的並行架構體系

2.演算法體系

在演算法體系持續按照面向不同的場景優化和升級整個演算法體系模型，在2017年阿里小蜜平台的演算法體系同樣也按照領域化和平台化體系持續升級發展，整個人機交互架構如下：

意圖識別：識別語言的真實意圖，將意圖進行分類並進行意圖屬性抽取。意圖決定了後續的領域識別流程，因此意圖層是一個結合上下文數據模型與領域數據模型不斷對意圖進行明確和推理的過程，完成意圖的補全、意圖分類和意圖轉移工作。整個意圖識別按照模型可組合以及進行單獨的演算法選型

通過對話管理系統的控制，面向不同的領域場景採用不同的領域技術：
QA Bot：通過知識圖譜、傳統IR以及DeepMatch的方法完成知識問答的匹配
Task Bot：面向多領域技術完成任務型對話構建與問答
Chat Bot：完成閑聊機器人的問答
Rec Bot：完成推薦機器人的問答體系構建
MC Bot：在文檔無法結構化的場景下(例如淘寶或者商家的活動場景)，通過Machine Reading的方法來完成問答

下面選擇幾個比較有意思的工作做一下展開。

遷移學習下的DeepQA探索

隨著阿里小蜜平台不斷的擴展，不僅需要在面向C端的手淘上幫助用戶解決服務諮詢類問題，而且也需要在新領域和國際化中承擔起任務，而這些領域中存在標註數據量不足或者難以獲得的問題(例如在AliExpress中的西班牙語場景)。基於此，我們希望利用已有的標註數據來優化小數據領域的QA匹配效果，而遷移學習在這方面就能發揮重要的作用。它最核心的思想就是將從一個環境中學到的知識用來幫助新環境中的學習任務。因此，在該場景下我們提出DRSS-Adv的遷移學習模型，用來建模QA匹配問題。

通常來說,TL的模型有兩類，一種是unsupervised，另外一種是supervised。前者假設完全沒有目標領域的標註數據，後者假設僅有少部分目標領域的標註數據。具體大家可以看下文獻[2]的綜述。在我們的業務中主要關注supervised的遷移學習技術，同時結合深度神經網路（DNN）。在這個設定下主要有兩種框架，一個是Fully-shared(FS)，另外一個是Specific-shared(SS)，框架圖如下：

基於增強學習的智能導購

智能導購主要通過支持和用戶的多輪交互，不斷的理解和明確用戶的意圖。並在此基礎上利用深度強化學習不斷的優化導購的交互過程。下圖展示了智能導購的技術架構圖：

這裡兩個核心的問題：

a：在多輪交互中理解用戶的意圖。

b：根據用戶的意圖結果，優化排序的結果和交互的過程。下面主要介紹導購意圖理解、以及深度增強學習的交互策略優化。

智能導購的意圖理解和意圖管理

智能導購下的意圖理解主要是識別用戶想要購買的商品以及商品對應的屬性，相對於傳統的意圖理解，也帶來了幾個新的挑戰：

1.用戶偏向於短句的表達。因此，識別用戶的意圖，要結合用戶的多輪會話和意圖的邊界。

2.在多輪交互中用戶會不斷的添加或修改意圖的子意圖，需要維護一份當前識別的意圖集合。

3商品意圖之間存在著互斥，相似，上下位等關係。不同的關係對應的意圖管理也不同。

4.屬性意圖存在著歸類和互斥的問題。

針對短語表達，我們通過品類管理和屬性管理維護了一個意圖堆，從而較好的解決了短語表示，意圖邊界和具體的意圖切換和修改邏輯。同時，針對較大的商品庫問題，我們採用知識圖譜結合語義索引的方式，使得商品的識別變得非常高效。下面我們分別介紹下品類管理和屬性管理。

基於知識圖譜和語義索引的品類管理

智能導購場景下的品類管理分為品類識別，以及品類的關係計算。下圖是品類關係的架構圖:

品類識別

採用了基於知識圖譜的識別方案和基於語義索引及dssm的判別模型。

a：基於商品知識圖譜的識別方案：基於知識圖譜複雜的結構化能力，做商品的類目識別。是我們商品識別的基礎。

b：基於語義索引及dssm商品識別模型的方案：知識圖譜的識別方案的優勢是在於準確率高，但是不能覆蓋所有的case。因此，我們提出了一種基於語義索引和dssm結合的商品識別方案兜底。

語義索引的構造

通常語義索引的構造有基於本體的方式，基於LSI的方式。我們用了一種結合搜索點擊數據和詞向量的方式構造的語義索引。主要包括下面幾步：

1.利用搜索點擊行為，提取分詞到類目的候選。

2.基於詞向量，計算分詞和候選類目的相似性，對索引重排序。

基於dssm的商品識別

dssm是微軟提出的一種用於query和doc匹配的有監督的深度語義匹配網路，能夠較好的解決辭彙鴻溝的問題，捕捉句子的內在語義。本文以dssm作為基礎，構建了query和候選的類目的相似度計算模型。取得了較好的效果，模型的acc在測試集上有92%左右。

樣本的構造：訓練的正樣本是通過搜索日誌中的搜索query和點擊類目構造的。負樣本則是通過利用query和點擊的類目作為種子，檢索出來一些相似的類目，將不在正樣本中的類目作為負樣本。正負樣本的比例1：1。

品類關係計算

品類關係的計算主要用於智能導購的意圖管理中，這裡主要考慮的幾種關係是：上下位關係和相似關係。舉個例子，用戶的第一個意圖是要買衣服，當後面的意圖說要買水杯的時候，之前衣服所帶有的屬性就不應該被繼承給水杯。相反，如果這個時候用戶說的是要褲子，由於褲子是衣服的下位詞，則之前在衣服上的屬性就應該被繼承下來。

上下位關係的計算2種方案：

1.採用基於知識圖譜的關係運算。

2.通過用戶的搜索query的提取。

相似性計算的兩種方案：

1.基於相同的上位詞。比方說小米，華為的上位詞都是手機，則他們相似。

2.基於fast-text的品類詞的embedding的語義相似度。

基於知識圖譜和相似度計算的屬性管理

下圖是屬性管理的架構圖：

整體上屬性管理包括屬性識別和屬性關係計算兩個核心模塊，思路和品類管理較為相似。這裡就不在詳細介紹了。

深度強化學習的探索及嘗試

強化學習是agent從環境到行為的映射學習，目標是獎勵信號(強化信號)函數值最大，由環境提供強化信號評價產生動作的好壞。agent通過不斷的探索外部的環境，來得到一個最優的決策策略，適合於序列決策問題。下圖是一個強化學習的model和環境交互的展示：

深度強化學習是結合了深度學習的強化學習，主要利用深度學習強大的非線性表達能力，來表示agent面對的state和state上決策邏輯。目前我們用DRL主要來優化我們的交互策略。因此，我們的設定是，用戶是強化學習中的env，而機器是model。action是本輪是否出主動反問的交互，還是直接出搜索結果。狀態(state)的設計：這裡狀態的設計主要考慮，用戶的多輪意圖、用戶的人群劃分、以及每一輪交互的產品的信息作為當前的機器感知到的狀態。 state = ( intent1, query1, price1, isclick, queryitemsim, …, power, userinter, age) 其中intent1表明的是用戶當前的意圖，query1表示的用戶的原始query。price1表示當前展現給用戶的商品的均價，isclick表示本輪交互是否發生點擊，queryitemsim表示query和item的相似度。power表示是用戶的購買力，userinter表示用戶的興趣, age 表示用戶的年齡。

reward的設計：由於最終衡量的是用戶的成交和點擊率和對話的輪數。因此reward的設計主要包括下面3個方面：

a：用戶的點擊的reward設置成1

b：成交設置成[ 1 + math.log(price + 1.0) ]

c：其餘的設置成0.1 DRL的方案的選型：這裡具體的方案，主要採用了 DQN， policy-gradient 和 A3C的三種方案。

基於可配置Bot Framework體系構建

在阿里小蜜平台中還存在一種需要動態獲取系統數據並且整個流程相對較為個性化的場景，這種場景的體系數據偏少甚至沒有並且需要跟對應的ERP等系統打通，因此我們就構建以一套Bot Framework系統，來滿足對應企業的運營或者開發同學完成個性化任務體系的定製。

整個BFW1.0的體系支持：

1.自定義多輪對話流程

2.自定義意圖、實體以及實體值

3.支持第三方介面在多輪交互平台的接入

儘管如此，整個BFW1.0面向複雜業務以及面向開發者的靈活度不足，因此在2018年，我們將BFW1.0按照chatflow的體系思路進行升級成為BFW2.0。

基於檢索模型和深度學習模型相結合的聊天應用

智能聊天的特點：非面向目標，語義意圖不明確，通常期待的是語義相關性和漸進性，對準確率要求相對較低。面向open domain的聊天機器人目前無論在學術界還是在工業界都是一大難題，通常在目前這個階段我們有兩種方式來做對話設計：一種是學術界非常火爆的Deep Learning生成模型方式，通過Encoder-Decoder模型通過LSTM的方式進行Sequence to Sequence生成，如下圖：

Generation Model(生成模型)：優點：通過深層語義方式進行答案生成，答案不受語料庫規模限制缺點：模型的可解釋性不強，且難以保證一致性和合理性回答

另外一種方式就是通過傳統的檢索模型的方式來構建語聊的問答匹配。 Retrieval Model(檢索模型)：優點：答案在預設的語料庫中，可控，匹配模型相對簡單，可解釋性強缺點：在一定程度上缺乏一些語義性，且有固定語料庫的局限性

因此在阿里小蜜的聊天引擎中，我們結合了兩者各自的優勢，將兩個模型進行了融合形成了阿里小蜜聊天引擎的核心。先通過傳統的檢索模型檢索出候選集數據，然後通過Seq2Seq Model對候選集進行Rerank，重排序後超過制定的閾值就進行輸出，不到閾值就通過Seq2Seq Model進行答案生成，整體流程圖如下：

機器閱讀理解技術探索與實踐

在阿里小蜜平台的業務體系中，存在大量知識數據是無法通過先驗知識結構化或者結構化效率極低的場景，例如淘寶雙十一大促的活動、稅務法律等等。因此我們通過機器閱讀理解的運用，可以減少人工知識點拆解工作，讓機器直接對規則進行閱讀，為用戶提供規則解讀服務，是最自然的交互方式。因此在2017年阿里巴巴iDST團隊與我們阿里小蜜團隊合作共同在機器閱讀領域進行了深入的探索和應用。

例如，如下圖是2017年淘寶雙十一「群戰隊」一個活動的規則：

運營同學在知識庫中錄入群戰隊的活動規則文本，阿里小蜜即可直接基於文本內容的閱讀來提供問答服務

機器閱讀理解技術機器閱讀理解模型已經在學術界取得了相當大的突破，但由於學術界和工業界具體場景的巨大差異，要將機器閱讀理解技術運用到實際業務場景中，還存在相當大到挑戰。

設計具有針對性的業務模型從上面的例子可以看到，業務場景中的活動規則、法規文檔具有一定的獨特性，往往包含大量文檔結構，如大小標題和文檔的層級結構等。此外，不僅文章普遍比較長，答案也較長，往往跨多個句子。這與一些公開模型所閱讀的wiki百科類數據特點有巨大的差異。需要針對場景的特點來設計模型結構。
模型的性能考慮學術成果中的模型一般都較為複雜，而工業界場景中由於對性能的要求，無法將這些模型直接在線上使用，需要做一些針對性的簡化，使得模型效果下降可控的情況下，儘可能提升線上預測性能。
模型領域的遷移目前的機器閱讀模型是領域相關的，這使得領域的快速拓展成為一大挑戰，阿里小蜜的活動規則解讀是我們支持的第一個場景，目前我們已經拓展了稅務法規解讀場景，未來還會在金融、電信等領域進行開拓，因此在新領域拓展時，需要利用到過去學習過的知識。

基於機器閱讀理解模型的在線問答流程如下圖所示，在解析用戶問題到輸出答案的過程中，共有4個模塊參與處理：

1.文章片段定位模塊文章片段定位模塊針對用戶問題，召回候選的文檔段落集合供機器閱讀產生答案。藉助該模塊，可幫助縮減機器閱讀理解模型的計算量，同時在一定程度上提升準確率。例如用戶提問「天貓造物節的活動什麼時候開始？」，該模塊需要返回所有與「天貓造物節」有關的文檔段落。定位的方式可以通過文本分類、文本檢索或者問題模板攔截來完成，文本分類需要提前標註數據訓練模型，目前我們的流程中主要以無監督的文本檢索或者人工維護的問題模板定位為主。

2.預處理模塊預處理模塊包含4個步驟，首先需要對用戶問題和待閱讀文章做文本分詞，由於帶閱讀文章常常伴有多級段落、特殊標籤等結構信息，需要做格式化處理。

3.在線服務模塊 DNN在線服務模塊部署了本文前半部分描述的深度機器閱讀理解模型，在接受第2步處理好的<question, doc>向量後，計算輸出文章中的詞語或者句子作為答案的概率。

4.後處理模塊後處理模塊負責具體答案的構建，根據在線服務模塊輸出的答案概率，其按照特定策略計算出最可能的答案

模型結構如下圖：

就在最近我們機器閱讀模型已排到SQuAD榜的top1，且ExactMatch指標首次超越了人類表現。

三、未來的展望與挑戰

互動式智能的也逐漸成為了新的領域入口，在未來需要基於場景數據的基礎上，需要持續結合技術、產品進行面領域性場景性探索與積累；需要持續在領域數據和知識體系的持續積累；在技術領域，我們將持續在生成模型、增強學習、遷移學習、機器閱讀、情感化等持續深入。
在未來阿里小蜜平台會持續在平台化和垂直領域方向持續深入下去，圍繞著行業、商家、企業以及整個chatbot生態構建智能服務的阿里小蜜智能服務平台。

References

[1] Feng-Lin Li, Minghui Qiu, Haiqing Chen, Xiongwei Wang, Xing Gao, Jun Huang, Juwei Ren, Zhongzhou Zhao, Weipeng Zhao, Lei Wang, Guwei Jin, Wei Chu: AliMe Assist : An Intelligent Assistant for Creating an Innovative E-commerce Experience. CIKM 2017: 2495-2498
[2] Jianfei Yu, Minghui Qiu, Jing Jiang, Shuangyong Song, Jun Huang, Wei Chu and Haiqing Chen, et al. Modelling Domain Relationships for Transfer Learning on Retrieval-based Question Answering Systems in E-commerce[C]// WSDM 2018.
[3] Yin W, Schütze H, Xiang B, et al. ABCNN: Attention-Based Convolutional Neural Network for Modeling Sentence Pairs[J]. Computer Science, 2015.
[4] Hu B, Lu Z, Li H, et al. Convolutional neural network architectures for matching natural language sentences[J]. 2015, 3:2042-2050.
[5] Pang L, Lan Y, Guo J, et al. Text Matching as Image Recognition[J]. 2016.
[6] Sukhbaatar S, Szlam A, Weston J, et al. End-To-End Memory Networks[J]. Computer Science, 2015.
[7] Wu Y, Wu W, Xing C, et al. Sequential Matching Network: A New Architecture for Multi-turn Response Selection in Retrieval-Based Chatbots[C]// Meeting of the Association for Computational Linguistics. 2017:496-505.
[8] Huang P S, He X, Gao J, et al. Learning deep structured semantic models for web search using clickthrough data[C]// ACM International Conference on Conference on Information & Knowledge Management. ACM, 2013:2333-2338.
[9] Pengfei Liu, Xipeng Qiu, and Xuanjing Huang. 2017. Adversarial Multi-task Learning for Text Classification. In ACL.