阿里小蜜的架構(gòu)設計

本篇總結(jié)了阿里小蜜從2017-2020年的演進過程，更偏向架構(gòu)體系上的介紹，不對具體技術(shù)做詳細介紹。具體技術(shù)部分會放在后面的文章中。

1. 2017：意圖與匹配分層的技術(shù)架構(gòu)體系

來自2017年的分享拆開阿里小蜜的內(nèi)核，看智能人機交互的實現(xiàn)邏輯
阿里小蜜主要對接的機器人有客服、助理、聊天，根據(jù)不同場景的需求采用不同的機器人。后面有說到小蜜主要應用的3大領(lǐng)域場景：智能導購（助理）、智能服務（偏問答）、智能聊天（聊天）。阿里小蜜將對話系統(tǒng)分成兩層：

  • 第一層是意圖識別層，采用的是根據(jù)意圖決定后續(xù)的領(lǐng)域識別
  • 第二層是問答匹配層，即根據(jù)領(lǐng)域場景對應到不同機器人，上面說到的客服、助理、聊天，對應的分別是問答型、任務型、語料型。
基于意圖與匹配分層的技術(shù)架構(gòu)

具體思路如下：

在阿里小蜜這樣在電子商務領(lǐng)域的場景中，對接的有客服、助理、聊天幾大類的機器人。這些機器人，由于本身的目標不同，就導致不能用同一套技術(shù)框架來解決。因此，我們先采用分領(lǐng)域分層分場景的方式進行架構(gòu)抽象，然后再根據(jù)不同的分層和分場景采用不同的機器學習方法進行技術(shù)設計。首先我們將對話系統(tǒng)從分成兩層：
1、 意圖識別層：識別語言的真實意圖，將意圖進行分類并進行意圖屬性抽取。意圖決定了后續(xù)的領(lǐng)域識別流程，因此意圖層是一個結(jié)合上下文數(shù)據(jù)模型與領(lǐng)域數(shù)據(jù)模型不斷對意圖進行明確和推理的過程；
2、 問答匹配層：對問題進行匹配識別及生成答案的過程。在阿里小蜜的對話體系中我們按照業(yè)務場景進行了3種典型問題類型的劃分，并且依據(jù)3種類型會采用不同的匹配流程和方法：
a) 問答型：例如“密碼忘記怎么辦？”→ 采用基于知識圖譜構(gòu)建+檢索模型匹配方式
b) 任務型：例如“我想訂一張明天從杭州到北京的機票”→ 意圖決策+slots filling的匹配以及基于深度強化學習的方式
c) 語聊型：例如“我心情不好”→ 檢索模型與Deep Learning相結(jié)合的方式

1.1 意圖識別技術(shù)方案

通常我們將意圖識別作為分類問題來解決；在阿里小蜜中，也存在對話領(lǐng)域語義意圖不完整的情況，因此除了傳統(tǒng)的文本特征之外，還加入了實時、離線等用戶本身的行為以及用戶本身相關(guān)的特征，通過深度學習方案構(gòu)建模型，對用戶意圖進行預測。

另外，在基于深度學習的分類預測模型上，阿里小蜜有兩種具體的選型方案：一種是多分類模型，一種是二分類模型。（但是沒有詳細介紹分別在什么場景下用多分類或者二分類？）對于多分類和二分類的優(yōu)缺點衡量如下：

多分類模型的優(yōu)點是性能快，但是對于需要擴展分類領(lǐng)域是整個模型需要重新訓練；而二分類模型的優(yōu)點就是擴展領(lǐng)域場景時原來的模型都可以復用，可以平臺進行擴展，缺點也很明顯需要不斷的進行二分，整體的性能上不如多分類好，因此在具體的場景和數(shù)據(jù)量上可以做不同的選型。

1.2 匹配模型

主流的智能匹配技術(shù)分為如下3種：

  • 基于模板匹配(Rule-Based)
  • 基于檢索模型(Retrieval Model)
  • 基于深度學習模型(Deep Learning)

2. 2017應用篇：3大領(lǐng)域場景的技術(shù)實踐

2.1 智能導購：基于增強學習的智能導購

智能導購對應的是任務型機器人，技術(shù)架構(gòu)如下：


智能導購的技術(shù)架構(gòu)圖

意圖識別

智能導購的意圖理解主要是用戶想要購買的商品以及商品對應的屬性，相對于傳統(tǒng)的意圖理解面臨的挑戰(zhàn)有：

  • 第一：用戶偏向于短句的表達。因此，識別用戶的意圖，要結(jié)合用戶的多輪會話和意圖的邊界。
  • 第二：在多輪交互中用戶會不斷的添加或修改意圖的子意圖，需要維護一份當前識別的意圖集合。
  • 第三：商品意圖之間存在著互斥，相似，上下位等關(guān)系。不同的關(guān)系對應的意圖管理也不同。
  • 第四：屬性意圖存在著歸類和互斥的問題。

基于以上問題，阿里小蜜通過品類管理和屬性管理維護了一個意圖堆。以下分別是品類管理和屬性管理的架構(gòu)圖，方法都大同小異。

品類管理
品類管理架構(gòu)圖

品類識別采用了基于知識圖譜的識別方案和基于語義索引及dssm的判別模型：

  • 基于商品知識圖譜的識別方案：基于知識圖譜復雜的結(jié)構(gòu)化能力，做商品的類目識別。這是品類識別的基礎。
  • 基于語義索引及dssm商品識別模型的方案：知識圖譜的識別方案的有事在于準確率高，但是不能覆蓋所有的case。因此，小蜜提出一種基于語義索引和dssm結(jié)合的品類識別方案兜底。具體過程如下：
基于語義索引及dssm商品識別模型的方案
語義索引的構(gòu)造

阿里小蜜的語義索引是結(jié)合搜索點擊數(shù)據(jù)和詞向量構(gòu)造的，主要包括下面幾步：

  1. 利用搜索點擊行為，提取分詞到類目的候選。
  2. 基于詞向量，計算分詞和候選類目的相似性，對索引重排序

我的理解是，語義索引是一種召回方式。

具體樣本構(gòu)造

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

屬性管理

屬性管理的思路可以直接參考品類管理，具體架構(gòu)圖如下：


屬性管理架構(gòu)圖

部分細節(jié)需要說明的是，品類關(guān)系在智能導購中主要考慮的關(guān)系是：上下位關(guān)系和相似關(guān)系。（補充：在知識圖譜構(gòu)建中實體與實體之間的關(guān)系，包括但不限于上下位、順承、時序等。）
上下位關(guān)系計算的2種方案：

  • 采用基于知識圖譜的關(guān)系運算
  • 通過用戶的搜索query提取

相似性計算的2種方案：

  • 基于相通的上位詞。比如小米、華為的上位詞都是手機，則他們相似
  • 基于embedding的語義相似度。（原文說的是fast-text，考慮到技術(shù)迭代，現(xiàn)在應該是bert了）
深度強化學習的探索及嘗試

這里只總結(jié)下阿里小蜜如何定義action、state、reward：

  • action: 本輪是否出主動反問，還是直接出搜索結(jié)果
  • state：這里狀態(tài)的設計主要考慮，用戶的多輪意圖、用戶的人群劃分、以及每一輪交互的產(chǎn)品的信息作為當前的機器感知到的狀態(tài)。

state = ( intent1, query1, price1, is_click, query_item_sim, …, power, user_inter, age)
其中intent1表明的是用戶當前的意圖，query1表示的用戶的原始query。price1表示當前展現(xiàn)給用戶的商品的均價，is_click表示本輪交互是否發(fā)生點擊，query_item_sim表示query和item的相似度。power表示是用戶的購買力，user_inter表示用戶的興趣, age 表示用戶的年齡。

  • reward: 最終衡量的是用戶的成交和點擊率和對話的輪數(shù)。

主要包括以下3個方面：
a)：用戶的點擊的reward設置成1
b)：成交設置成[ 1 + math.log(price + 1.0) ]
c)：其余的設置成0.1

  • DRL選型：主要采用了 DQN， policy-gradient 和 A3C的三種方案。

2.2 智能服務：基于知識圖譜構(gòu)建與檢索模型的技術(shù)實踐

智能服務對應的是問答型機器人，小蜜采用基于知識圖譜構(gòu)建與檢索模型。

智能服務的特點：有領(lǐng)域知識的概念，且知識之間的關(guān)聯(lián)性高，并且對精準度要求比較高
基于問答型場景的特點，我們在技術(shù)選型上采用了知識圖譜構(gòu)建+檢索模型相結(jié)合的方式來進行核心匹配模型的設計。

知識圖譜的構(gòu)建我們會從兩個角度來進行抽象，一個是實體維度的挖掘，一個是短句維度進行挖掘，通過在淘寶平臺上積累的大量屬于以及互聯(lián)網(wǎng)數(shù)據(jù)，通過主題模型的方式進行挖掘、標注與清洗，再通過預設定好的關(guān)系進行實體之間關(guān)系的定義最終形成知識圖譜。

基本的挖掘框架流程如下：


知識圖譜的實體和短語挖掘流程

基于知識圖譜匹配的優(yōu)缺點：

\textbf{優(yōu)點}

  • 在對話結(jié)構(gòu)和流程的設計中支持實體間的上下文會話識別與推理
  • 通常在一般型問答的準確率相對比較高(當然具備推理型場景的需要特殊的設計，會有些復雜)
    \textbf{缺點}
  • 模型構(gòu)建初期可能會存在數(shù)據(jù)的松散和覆蓋率問題，導致匹配的覆蓋率缺失
  • 對于知識圖譜增量維護相比傳統(tǒng)的QA Pair對知識的維護上的成本會更大一些

基于檢索模型的對話匹配的流程：

其在線基本流程分為：
(1).提問預處理：分詞、指代消解、糾錯等基本文本處理流程；
(2).檢索召回：通過檢索的方式在候選數(shù)據(jù)中召回可能的匹配候選數(shù)據(jù)；
(3).計算：通過Query結(jié)合上下文模型與候選數(shù)據(jù)進行計算，通過我們采用文本之間的距離計算方式(余弦相似度、編輯距離)以及分類模型相結(jié)合的方式進行計算；
(4).最終根據(jù)返回的候選集打分閾值進行最終的產(chǎn)品流程設計；

離線流程分為：
(1).知識數(shù)據(jù)的索引化；
(2).離線文本模型的構(gòu)建：例如Term-Weight計算等；

檢索模型整體流程如圖：


檢索模型的流程圖

2.3 智能聊天：基于檢索模型和深度學習模型相結(jié)合的聊天應用

智能聊天的特點：非面向目標，語義意圖不明確，通常期待的是語義相關(guān)性和漸進性，對準確率要求相對較低

智能聊天對應聊天型機器人，目前主要有兩種技術(shù)：

  • Generation Model(生成模型)

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

  • Retrieval Model(檢索模型)

優(yōu)點：答案在預設的語料庫中，可控，匹配模型相對簡單，可解釋性強
缺點：在一定程度上缺乏一些語義性，且有固定語料庫的局限性

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


小蜜的閑聊模塊

3. 2018

內(nèi)容主要來自于2018 - 阿里小蜜這一年，經(jīng)歷了哪些技術(shù)變遷？

算法方面本質(zhì)上變化不大，新增了一些功能模塊。


算法體系架構(gòu)

通過對話管理系統(tǒng)的控制，面向不同的領(lǐng)域場景采用不同的領(lǐng)域技術(shù)：

  • QA Bot：通過知識圖譜、傳統(tǒng)IR以及DeepMatch的方法完成知識問答的匹配
  • Task Bot：面向多領(lǐng)域技術(shù)完成任務型對話構(gòu)建與問答
  • Chat Bot：完成閑聊機器人的問答
  • Rec Bot：完成推薦機器人的問答體系構(gòu)建
  • MC Bot：在文檔無法結(jié)構(gòu)化的場景下(例如淘寶或者商家的活動場景)，通過Machine Reading的方法來完成問答

與2017年相比，增加了Rec Bot和MC Bot。另外，隨著阿里小蜜平臺的擴展，部分領(lǐng)域存在難以獲得或者標注數(shù)據(jù)量不足的問題，因此開始引入遷移學習。

3.1 機器閱讀理解技術(shù)

應用背景：（從各分享文章推測，阿里小蜜平臺應該是2018年推廣到其他業(yè)務）

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

  • 設計具有針對性的業(yè)務模型：這是與業(yè)務場景中數(shù)據(jù)的表現(xiàn)形式有關(guān)，如文檔結(jié)構(gòu)、文章長度、跨多個句子等，這些可能與wiki類數(shù)據(jù)有巨大差異，因此需要針對場景的特點來設計模型結(jié)構(gòu)。
  • 模型領(lǐng)域的遷移：因為機器閱讀理解模型是領(lǐng)域相關(guān)的，因此需要解決跨領(lǐng)域的問題
  • 模型的性能考慮：學術(shù)界模型一般較為復雜，應用到工業(yè)界需要做一些簡化使得模型效果下降可控的情況下，盡可能提升線上預測性能。

基于機器閱讀理解模型的在線問答流程如下圖所示：


基于機器閱讀理解模型的問答流程

具體說明：

1.文章片段定位模塊 文章片段定位模塊針對用戶問題，召回候選的文檔段落集合供機器閱讀產(chǎn)生答案。借助該模塊，可幫助縮減機器閱讀理解模型的計算量，同時在一定程度上提升準確率。例如用戶提問「天貓造物節(jié)的活動什么時候開始？」，該模塊需要返回所有與「天貓造物節(jié)」有關(guān)的文檔段落。定位的方式可以通過文本分類、文本檢索或者問題模板攔截來完成，文本分類需要提前標注數(shù)據(jù)訓練模型，目前我們的流程中主要以無監(jiān)督的文本檢索或者人工維護的問題模板定位為主。
2.預處理模塊 預處理模塊包含4個步驟，首先需要對用戶問題和待閱讀文章做文本分詞，由于帶閱讀文章常常伴有多級段落、特殊標簽等結(jié)構(gòu)信息，需要做格式化處理。
3.在線服務模塊 DNN在線服務模塊部署了本文前半部分描述的深度機器閱讀理解模型，在接受第2步處理好的<question, doc>向量后，計算輸出文章中的詞語或者句子作為答案的概率。
4.后處理模塊 后處理模塊負責具體答案的構(gòu)建，根據(jù)在線服務模塊輸出的答案概率，其按照特定策略計算出最可能的答案

4. 2019

2019-01 - 未來已來！阿里小蜜AI技術(shù)揭秘
整體架構(gòu)體系上基本沒什么變化，相比之前，2019的分享在任務型機器人中新增了slot，應該是在動作判斷中采用意圖+slot去做決策。

2019-09 - 干貨 | 阿里云小蜜對話機器人背后的核心算法
從2019年下半年開始的分享內(nèi)容有了很大的改動，主要體現(xiàn)在：

  • 自然語言理解：重點是小樣本學習（few-shot learning）
  • 平臺視角下的對話管理
  • 用戶模擬器
    可以看出，前期做好平臺建設，已經(jīng)開始了技術(shù)深度上的探索。

5. 2020

內(nèi)容來自于 2021-01 達摩院Conversational AI研究進展及應用。由于是2021年初的分享，所以放在了2020年。

2020年的分享與2019年下半年的分享內(nèi)容比較相似了，持續(xù)在技術(shù)深度上探索。改動點在：

  • 自然語言理解：新增基于元學習
  • 對話管理：從狀態(tài)機到深度模型
  • TableQA：Conversational Semantic Parsing的難點和進展。（這是個新概念）
達摩院Conversational AI的整體架構(gòu)

學習資料

對話平臺

情感分析

知識結(jié)構(gòu)化

其他

最后編輯于 ：
?著作權(quán)歸作者所有,轉(zhuǎn)載或內(nèi)容合作請聯(lián)系作者
【社區(qū)內(nèi)容提示】社區(qū)部分內(nèi)容疑似由AI輔助生成，瀏覽時請結(jié)合常識與多方信息審慎甄別。
平臺聲明：文章內(nèi)容（如有圖片或視頻亦包括在內(nèi)）由作者上傳并發(fā)布，文章內(nèi)容僅代表作者本人觀點，簡書系信息發(fā)布平臺，僅提供信息存儲服務。

相關(guān)閱讀更多精彩內(nèi)容

友情鏈接更多精彩內(nèi)容