摘要：目前資訊播報時區限行歷史上的今天單位換算油價日歷等技能天貓精靈上線技能觸發率，準確率即對話管理，是對話系統的關鍵部分，負責維護對話上下文，管理對話流程，保持對話過程的流暢。

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)多元化生產、流程化規?；沙掷m的生產體系走在了業界的前沿；在最近一次天貓精靈理想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：中間橙色為TaskBot引擎，下文展開介紹
注2：大圖中TaskBot引擎、QABot引擎、ChatBot引擎為邏輯架構；物理架構上QABot和ChatBot級聯到TaskBot中，有多個模塊進行多路召回和pk判定

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 不再展開。

業界對問答有不同的劃分維度，按照內容維度可劃分為結構化數據問答、非結構化數據問答、以及基于問答對的問答。而從技術角度看，業界一般分為基于檢索式的問答系統和基于生成式的問答系統。前者是將信息檢索系統構建于大規模對話數據集之上，通過建立有效的問句匹配和問答相關度量化模型實現對用戶問題的合理回復；后者則試圖通過構建端到端(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對話的路很長，我們一起努力。

原文鏈接