當你和天貓精靈對話時，它在想什麼？阿里智能對話技術深度解讀

術語對齊

TaskBot引擎： 核心處理對象是「技能」，咱們把技能定義成結構化(query+content)、垂直場景化的任務，好比實時場景查詢、工具類、控制類等
QABot引擎：

包括KG-QA引擎、QAPair引擎、DeepQA引擎。KG-QA主要是百科和圍繞全網知識圖譜的精準問答；QAPair引擎以問答對生產消費爲主；DeepQA引擎基於url索引、分類聚類、焦點詞、摘要的多級系統

ChatBot引擎：

包括基於檢索和生成的閒聊引擎

內容體系

網頁搜索與智能對話是信息服務的不一樣承載方式，在數據、算法、架構上一脈相承。也正所以積累，谷歌等搜索引擎公司能夠快速推出其AI平臺&產品，以信息服務爲基礎To B/C。

• 行業技能庫

第一階段：團隊用了半年的時間將大搜索100+的垂直行業進行結構化升級，涉及行業大到大娛樂、大出行、新聞資訊，中到汽車、體育、旅遊，小到股票、翻譯、古詩詞等等

第二階段：進一步進行技能的結構化升級，精細的Query結構化、多輪對話建設，並輸出到天貓精靈音箱

• 全網知識圖譜

阿里惟一全網知識圖譜，以知識卡片、實體推薦、精準問答等產品輸出；

• 問答庫

社區問答庫：基於UGC問答社區的問答庫，1B doc的量級；

UPGC生產：神馬"騎士團"創建的校園生產體系，騎士團是該項目的code name，充分利用校園對存量知識進行整理、加工、審覈，提高問答的生產效率和質量；目前參與學生人數萬級別；

高質量庫：社區問答庫覆蓋高但質量良莠不齊，社會化生產質量高但數量相對較少，經過機器對社區問答庫的清洗和對社會化生產庫的擴展，最終沉澱成高質量庫；

蛋清庫：蛋清是產品策略。用戶與bot對話時最但願獲得直接的答案即"蛋黃"，可是有時候機器能get(或部分get)到用戶的問題可是沒法給與完美的答案，這個時候給用戶"蛋清"也是一種優雅的手段表示我理解你；目前已完成初版蛋清上線，主要覆蓋「描述/方式」問題類型；

• 核心庫

爲了淨化互聯網環境、提高內容質量，咱們以運營+挖掘的方式運轉了一套核心庫的流程；
技能庫+知識庫+問答庫+閒聊庫，構成了信息服務場景下智能對話的基礎設施，舉幾個例子說明下不一樣庫對不一樣query（詢問）的知足，小馬同窗正在看一場NBA比賽，他說：

"如今火箭領先多少分了？" -> 技能庫
"籃球是誰發明的？" -> 知識庫
"哈登能進名人堂嗎?" -> 問答庫
"我們聊聊NBA吧?" -> 閒聊庫

通用信息服務始終在追求問答的覆蓋和質量，這也是業界的難點，包括半結構化/非結構化數據的處理、內容生產模式、內容敏感問題、用戶知足等等；神馬搜索在一年的探索中積累出的多級QA系統、MOPU(Machine/OGC/PGC/UGC)多元化生產、流程化規模化可持續的生產體系走在了業界的前沿；在最近一次天貓精靈理想query集合評測上，觸發率達到73%，準確率達到了91%；這個數據是什麼概念，能夠參考業界表明性產品的指標：

根據Stone Temple最近的調查，谷歌虛擬助理能夠回答68％的用戶問題，其中90.6％的答案是正確的，而微軟Cortana可以回答的用戶問題比例爲56.5％，準確率爲81.9％；而蘋果Siri回答的用戶問題比例爲21.7%，準確率爲62.2％，亞馬遜Alexa回答的用戶問題比例爲20.7％，準確率爲87％

架構體系

上圖爲架構體系總體大圖。"引擎"負責數據的構建和計算的承載，"平臺"負責以引擎爲核心構建的閉環解決方案(生產、多租戶消費、運營、需求管理等)。系統的落地，得以於搜索多年的積累沉澱。該系統徹底與搜索業務解耦，承載了天貓精靈等業務方的流量(以及雙十一晚會直播問答)。下面會分別介紹神降臨平臺、TaskBot引擎、QABot引擎。

神降臨平臺

神降臨平臺是TaskBot引擎的平臺化延展，解決技能生產、消費、運營等問題。對於外部開發者它是BotFramework；對於外部調用者它是神馬整個智能對話的出入口；對於內部RD它是生產和運營平臺。目前該平臺主要服務集團內部業務。神降臨由技能開放平臺、技能生產平臺、統計分析平臺、運營管理平臺組成。

• 技能開放平臺

開放有兩個層面：內容開放+能力開放。對應的技能開放平臺也承擔兩個角色：

1.能力開放(BotFramework)：對標類api.ai的技能構建平臺，外部開發者構建本身的技能；
2.內容消費(OpenAPI)：經過建立應用、選擇技能/問答，直接經過API進行智能對話；

目前咱們還沒有對外主推BotFramework：雖然開放平臺產品衆多，但目前的模式很難知足開發者需求，一個技能從產品規劃到生產可用須要大量和較長鏈路的工做，不是提交點語料配置點上下文和輸出就能夠搞定的(簡單控制類勉強能夠)。在咱們技能一期專項完成的20+技能下大約有300+種不一樣意圖，創建了語料收集、標註、審覈、建模、測試的完善流程。因此咱們的精力主要放在打磨真正可用的內置技能，產生實際的價值。

• 技能生產平臺

技能生產平臺用於生產內置技能。它與技能開放平臺的角色一致最終都是將物料投遞給TaskBot引擎，但用戶是內部RD，涵蓋了從產品PRD到技能上線的全鏈路流程，涉及在線編寫結構化PRD、需求管理、語料管理、實體管理、技能構建、技能訓練、技能驗證、技能發佈。

爲了技能的普適性，每一個技能咱們都以技能組的方式支持多場景：標準無屏、手機屏、大屏，標準無屏針對天貓精靈音箱相似場景，手機針對神馬的我的助理場景，他們在多輪需求、結構化展示、排序策略上都不盡相同；另外內置技能的物料除了實體、語料、劇本以外，支持投遞c++動態庫以支持不一樣的排序策略、NLG策略等。

經過該平臺將技能建設在線化、PD/RD/QA/運營分工明確pipeline生產。

• 統計分析平臺

多維度的打點統計、報表、指標分析。涉及問題包括生產消費效率(經過統計引導內容生產的方向領域)、內容控制反饋、總體和獨立技能的準召。

• 運營管理平臺

運營管理平臺分兩塊：內容運營、應用運營。

1. 內容運營：關鍵域和模塊的實時干預；
2. 應用運營：應用/技能等增刪改查以及訓練；

注1：中間橙色爲TaskBot引擎，下文展開介紹
注2：大圖中TaskBot引擎、QABot引擎、ChatBot引擎爲邏輯架構；物理架構上QABot和ChatBot級聯到TaskBot中，有多個模塊進行多路召回和pk斷定

TaskBot引擎

TaskBot引擎是技能構建和消費的內核。它涉及離線計算、內容管理、調度、在線服務。

• 離線計算

將外部平臺的物料一一構建成對應的內部數據；包括實體詞典、分類模型、意圖識別&抽槽插件/pattern/模型、NLG策略和模板、DM劇本插件、US排序插件、webHook邏輯插件等等。

• 內容管理

按應用/技能分版本的管理上述數據。內容管理要作到無狀態，可快速移植、回滾、分發。

• 調度

分爲數據調度、環境管理、服務管理。數據調度負責離線到在線的數據分發，一套SDS引擎包含多個Role，每一個Role都會加載對應的數據；環境管理負責迭代、驗證、預發、生產環境的自動化管理；服務管理負責運維方面工做包括分行分列(按照應用流量分行，按照技能消耗分列)，擴縮容上下線等；

• 在線引擎

：SDS引擎，見下圖

SDS引擎是任務式對話的核心。它接受用戶的query，以DM爲控制中樞、以NLU爲理解中樞、經過US作召回和rank、以NLG包裝後輸出。目前資訊播報、時區、限行、歷史上的今天、單位換算、油價、日曆、nba、lbs等技能天貓精靈上線技能觸發率97-98%，準確率95%+；

• DM(Dialog Manager)

：即對話管理，是對話系統的關鍵部分，負責維護對話上下文，管理對話流程，保持對話過程的流暢。用戶的輸入經過NLU處理後產生意圖、槽位等信息，DM根據這些數據以及當前對話的上下文作出對應的決策和行爲，包括調用NLG模塊生成天然語言、經過外部服務接口獲取對話過程當中所須要的額外信息。DM以任務樹的方式管理對話，樹的每一個節點都是一個Agent(詢問、執行、迴應)；考慮到對話系統的通用性和可擴展性，咱們在對話管理模塊的設計上，將對話引擎部分和領域相關部分作了明確的隔離，包括可重用的對話Agent組件、可編輯的對話控制選項、通用的外部調用機制等，可方便地自定義不一樣功能的Agent，實現不一樣的對話場景。

對話引擎在流程控制上有兩個重要的組成部分：

• 對話執行棧

： 經過棧的形式維護Agent的執行狀態，根據上下文對對話流程進行控制。對話棧將Agent放入棧中，由棧頂的Agent執行並選擇出合適的子Agent繼續入棧執行。對話棧存儲對話的上下文信息，對應着一個具體的對話場景。對話棧頂的Agent可形象的理解爲對話焦點，對話棧結合Agent關係樹和話題議程表可實現對話焦點的跟蹤和管理，可靈活的保持、切換、回溯對話主題。

• 話題議程表：

負責維護和管理對話過程的參數信息，用於收集系統指望獲得的用戶輸入。議程分爲多個層次，每一個級別對應於對話框堆棧中的一個Agent，所以對於不一樣的運行棧信息，議程表表明瞭在這個對話場景下所指望的輸入。當用戶保持或轉移話題時，能找到相應的指望參數並更新。
DM的執行單元是"劇本"，用戶在開放平臺或生產平臺經過拖拽方式構建的劇本樹最終會被構建成c++的so被加載執行。目前經過DM與NLU的結合已在多個技能上完成了省略替換、指代消解、話題轉移、錯誤處理等多輪對話。
NLU：NLU有兩種不一樣的設計理念：

• 圍繞BotFramework的NLU

：將用戶query結構化爲Domain/Intent/Slot後返回給開發者(帶上置信度)，有些BotFramework產品須要用戶本身判斷是否接受這個結果，在技能較多的狀況下會更麻煩，由於這種設計下核心幫助用戶解決的是語義理解的問題

• 圍繞對話產品的NLU：

結合NLU的分類和召回的結果作多維NBest策略，這在信息服務場景尤其重要，好比用戶說了個李白，它多是詩人李白、多是撒貝寧的妻子李白、也多是李榮浩的《李白》，這裏有不一樣的處理方式，好比藉助大搜索用戶點擊、藉助用戶的歷史行爲、甚至能夠DM上直接反問哪一個李白
上述2天然涵蓋1，神馬的NLU是2的模式。今年NLU系統經歷了兩次大的升級，一次是整個SDS的NBest升級，一次是子NLU化，子NLU可讓不一樣的Domain根據自身特別內部個性化定製意圖識別和抽槽策略、並提高RD並行度。
NLG/US/Skill-Gateway 再也不展開。

QABot引擎

業界對問答有不一樣的劃分維度，按照內容維度可劃分爲結構化數據問答、非結構化數據問答、以及基於問答對的問答。而從技術角度看，業界通常分爲基於檢索式的問答系統和基於生成式的問答系統。前者是將信息檢索系統構建於大規模對話數據集之上，經過創建有效的問句匹配和問答相關度量化模型實現對用戶問題的合理回覆；後者則試圖經過構建端到端(End-to-End)的深度學習模型，從海量對話數據中自動學習query和response之間的語義關聯，從而達到對於任何用戶問題都可以自動生成回覆的目的。

咱們當前主要專一於基於海量數據的檢索式QA系統，而在系統層面劃分爲：KG-QA、Baike-QA、DeepQA、PairQA，它們都是對既有知識的搬運整理，可是在數據來源/要求、加工方式、匹配方式、覆蓋場景又不盡相同。筆者認爲世界的理想終局是結構化的(知識庫)，可是這個永遠沒法真正實現，好比信息的持續產生和更新以及天然語義處理的難度，因此須要兩個方向同時並行前進。

KG-QA和Baike-QA準確高可是覆蓋有限，基於非結構化的Deep-QA覆蓋高可是污染大，Pair-QA的社會化生產大幅提高生產力可是須要好的場景和問題，諸多的挑戰決定了問答的難度和壁壘。

這裏主要介紹PairQA和DeepQA系統以下圖所示：

問題理解 問題理解是問答系統理解用戶意圖的關鍵一環，特別是DeepQA。這裏咱們複用了大搜索基礎NLP的能力(語義擴展，權重分析，實體識別，改寫糾錯等)；問題分類結合機器學習分類算法和人工的方式，來實現提問的分類，好比：無心義、閒聊、人物、組織、時間等；焦點詞識別，主要完成信息需求的精準定位，指問句的主要背景或者對象、有關主題的內容，可以體現對話題的描述性做用，好比實體、屬性、動做、實例等。

• 信息檢索

信息檢索負責從全局語料中檢索相關/候選信息，傳遞給最終的答案生成模塊。信息語料的不一樣，以及業務場景的不一樣，檢索的方法也有多種形式，目前咱們主要使用的是基於倒排的文本檢索和基於向量的語義檢索。前者是傳統的全文搜索引擎採用的方式，優勢是實現簡單、準確率高，但對建庫語料依賴大，後者則是語義搜索引擎一種較好的實現方式，優勢是泛化能力強，但有必定誤觸發率。兩套索引機制各有優缺點，結合不一樣的語料和業務場景，使用不一樣索引機制，同時也會相互結合使用，發揮各自的優點。

• 答案生成

基於檢索端的候選答案，須要經過進一步的精排、答案抽取、置信度計算，最終獲得準確、簡潔的答案。PairQA，更多的是經過CNN、DSSM、GBDT等機器學習模型和方法作嚴格的排序 + 置信度計算；DeepQA，面向的是非結構化的文檔/社區語料，則須要作更深層次的處理，包括結合Bi-LSTM RNN模型的簡潔摘要抽取、同義問題答案間交叉驗證、答案相關性驗證等。

• 語料建設

語料庫的建設是QABot的基礎，不論是面向特定領域的問答（好比：母嬰、三國、街舞），仍是面向開放域的問答（好比閒聊），都離不開高質量語料的支持。針對天貓精靈場景，咱們實現了一整套面向口語化問答的數據挖掘和運營生產流程，包含開放問題挖掘、場景問題挖掘、社會化答案生產、高質量答案自動抽取。

• 圖譜引擎

知識圖譜是神馬搜索的核心基礎設施，藉助搜索大數據和天然語言處理、深度學習技術打造，也是歷史最悠久的數據產品，在搜索知識化、智能化發展歷程中發揮了關鍵做用。基於知識圖譜和天然語言理解，咱們構建了知識卡片、實體推薦、精準問答三個主要產品。在智能對話業務，針對音箱的場景，還重點建設了菜譜、古詩詞、三國、世界之最等特點技能，輸出到天貓精靈。而在生產側，一方面持續引入知識抽取、知識推理的前沿新技術，另外一方面也創建了圖譜的社會化生產模式，來持續建設和補充專業領域的知識，使知識圖譜更好地爲業務賦能。

總結

去年一年，智能對話團隊初步完成了從搜索到智能對話的技術升級，在實戰中沉澱出AI+信息服務的架構、算法、運營、內容體系。感恩時代，AI對話的路很長，咱們一塊兒努力。

原文連接