孫林：360在Conversation AI上的應用實踐

本文根據【創客168】第12期《人工智慧技術與智慧辦公》現場演講嘉賓孫林老師分享內容整理而成。

孫林，畢業於哈工大自然語言處理專業，先後在騰訊、360兩家公司任職，目前是在360智能研究院負責對話AI方向，研究興趣集中在信息抽取，問答系統，對話系統以及深度學習，我曾在學術會議上發表過文章，也有一些自己的專利。

正文

大家都知道現在有很多媒體報道我們已經在人工智慧上取得了怎樣的效果或者是在學術上達到了怎樣的指標。而今天我們不搞這些花把勢，實實在在的和大家分享一下360在人工智慧方面的落地實踐和產品。

如何描述Conversation AI?我認為更多的是下一代交互方式的革命。當然，這個話題有點大，所以我們先來談一談人機交互的發展歷程。最開始是打孔機，科學人員通過打孔輸入到計算機里，後來逐漸演變到用滑鼠鍵盤作為輸入方式，再後來有了觸屏手機，並且圍繞它有了APP生態。那麼再接下來的交互方式會是什麼?很多公司都在研究的語音交互會不會是下一個交互方式?

下一代交互方式到底是什麼樣的?音箱、硬體還是其它方式。對此業界有很多探索，例如亞馬遜、谷歌、阿里、360和一些創業公司都發布了自己的音箱產品。

除此之外，各大公司還在考慮一些其它入口，例如機器人。360一直在做兒童機器人、故事機以及兒童手錶等可穿戴設備。硬體會是下一代交互方式嗎?軟體有沒有可能成為下一代交互方式?從2014年開始，我們就看到了很多手機助手、語音助手出現，如微軟的小娜。其實360也有自己的語音助手系統。

360在整個語音交互智能硬體方面投入了很多，同時也落地了很多產品。今天就和大家分享一下360有哪些地方值得借鑒。

我們認為做成一個產品最重要的是天時地利人和，天時指的是當前這個方向是不是夠火，技術準備是不是到了一定階段。地利指的是我們做的事情是不是公司或者平台的主要方向。人和指的是團隊的技術儲備。只有集齊了這三點才是產品成功的基礎。

360在產品方面做了很多嘗試，如可穿戴的手錶，智能監控的設備，行車記錄儀，機器人、故事機、手機，花椒等等。這些主要是面向消費級的產品，所以有更多細節需要打磨。

Conversation AI整體架構分為三個部分，一個是面向具體任務的Bot，例如訂餐或者查天氣，類似於這樣在某個領域做具體的事情;第二個是問答系統，提問一些事實性的問題並獲得確定答案，例如最高的山是什麼?天空為什麼是藍色?第三個是chatbot，實現人機的智能聊天，例如業界的典型代表是微軟小冰。

這三個方向根據具體業務場景的不同而有不同的定位。例如，小娜更多是在室內使用，提升便捷性;智能客服更多的是問答系統，提升客服效率;陪伴機器人更多的是情感維護方面。不同的產品定位導致它們會對三個方向有不同的側重點。

典型的Conversation AI系統架構會有上圖所示的幾個模塊，最左邊的是ASR，也就是語音識別，將語音轉換成文本，之後的SLU模塊對文本進行理解，解讀用戶意圖;有了用戶意圖，就要嘗試和用戶對話，通過連續的對話過程更加清晰理解用戶意圖，這時我們會有DST和Dialog Policy模塊，通過這個系統和用戶進行多輪對話;之後要給用戶做出反饋，如果這個反饋是文本，那麼還需要TTS將文本轉換成語音。

這就是基於語音交互的整個邏輯，而且這個邏輯是比較經典的，大家可能在很多論文中都看到過這種架構設計。

360在支持這麼多產品的過程中，遇到過哪些困難呢?我會分別從四個方面來和大家分享。第一個就是具體的學術論文如何落地，這會涉及到工程上系統架構的問題;第二個是語音識別，這個方面突破很大，很多廠商都宣布自己可以達到百分之九十幾的識別準確率，但這個數據其實是在相對安靜，沒有雜訊的場景下測得的，如果是在有雜訊的情況下，準確率能夠達到60%~70%就不錯了。而且如果是做toC端的消費級產品，語音識別的場景會更複雜，比如背景雜訊、雞尾酒問題等等。第三個是冷啟動問題，例如我們要做一款音箱，用戶說放音樂，沒有音樂類的語料怎麼辦?目前比較流行的做法是訓練機器學習模型來做意圖識別，這就引發了一系列的問題，例如語料來源如何解決，質量如何控制，訓練數據集需要到達多大的量級?第四個問題是產品上線之後，如何持續優化?

NLP系統在架構上最主要的矛盾點是軟體工程的模塊設計需要分層，但是NLP系統所有的子任務目前無法達到100%的準確率。在實際業務場景下，遇到這種演算法不是100%正確的情況，演算法的結果怎麼往下傳遞呢?如果傳遞的話，又會遇到系統級聯導致的準確率下降的問題，比如每個模塊都是95%的準確率，經過三次級聯或者四次級聯之後，誤差會被放大到一個不可承受的地步。所以系統架構上要考慮好如何保留和傳遞不確定的信息。

在我看來，這兩個矛盾在整個架構上是不可調和的，一個是要求模塊化輸出，另一個是現有技術無法輸出確定性的東西，只能傳遞不確定的東西。

怎麼解決呢?業內公認的做法是前面模塊不用給出條件不成熟的確定性結論，可以傳遞一些不確定的結論，但是也不能什麼信息都往下游傳遞。例如做一個二分類模型，如果分類演算法輸出一個0到1的概率值，比如0.5，那麼在下游模塊中怎麼使用呢?如果你把問題直接拋給下游模塊，那麼下游模塊就會很痛苦。但是如果上游模塊輸出0,1,2三檔，0表示一定不屬於該類，2表示一定屬於該類，1表示不確定，那麼下游模塊就比較好做一些策略性的東西。因此，上游模塊不僅是不要做出絕對的0和1的判斷，但是也得要傳輸一些相對確定的信息。

如果你非常追求完美，那麼這個問題無解。如果不是，我們可以嘗試下面的做法：第一就是要在模塊分層和不確定之間做平衡，確定傳遞多少不確定信息到下游模塊，就像我們剛才說的對置信度做分層;第二，對話AI有很多任務，我們可以選擇集中式或者分散式來理解所有意圖。用一個模塊來理解所有意圖，然後調用相應服務，這是集中式;分散式是指有上百個服務，每個服務既要理解意圖又要調用服務。

在實際使用中，我們發現集中式更好用。例如，「我要去拉薩」，這既可能是要去拉薩旅遊想要訂機票，同時這也是一首歌，可能是想聽音樂。如果採用分散式無法判斷採用哪個服務，而且每個人的需求都不同，無法做到默認。而採用集中式，我們可以在一個模塊中識別出所有意圖，統一的流程和框架有可比性，可以減少很多下游的工作量。

第三是通用性和定製化，開發人員總是希望可以做一個通用系統，但是在實際任務中，總會遇到業務方的頻繁修改。如何在通用化和定製化之間做一些平衡?我們的思考是更多的考慮通用性，但同時也要考慮可擴展性，去做一些定製化的事情。

基於上面的幾點，我們的架構大概分為三部分，語義服務，是對話系統的線上服務;數據平台，為系統提供一些基礎的模型和數據;第三個是語義理解的DEEP-X開放平台，目前這種平台的定位有兩種，第一種是像科大訊飛，其上有數十上百個Skill都已經做好，你只需做組裝工作就可以。第二個是像谷歌或者Facebook這類定位給開發者使用的平台，可以提供一些API組建，讓開發者可以定義自己的skill。而DEEP-X平台不但提供了很多內置的Skill和通用的解決方案，也提供給開發者定製自己的Skill的能力，同時還提供了強大的業務數據分析平台和服務監控平台。

Deep-X平台是我們的一個重點，它大概由這幾部分組成：第一部分是SDK接入端，用於對接各種硬體和軟體產品。第二部分是開放平台，包括BOT搭建，以及Skill定製化等模塊。DEEP-X平台會把定製化的Skill通過數據和模型的方式輸出到語義服務的意圖理解和對話管理的模塊中。

這就是剛才提到的集中式意圖理解架構，來了Query以後首先是做分詞，詞性標註、組塊分析、句法分析。基礎分析之後，會有三大模塊，第一個是Task，第二個是問答系統，第三個是chatbot，通過三個模塊分別達到對應的意圖以後，進行中控意圖merge模塊。

ASR識別不準有很多原因，第一個是硬體設備不好，單麥克風，不是一個麥克風陣列，天然就會導致在去雜訊、去背景聲方面會遇到很多問題;第二個是特定領域的語料很少，導致語音識別系統拿不到足夠的數據訓練語言模型，比如很多的實體詞屬於未登錄詞，不在原來的語料裡面，導致領域實體和語料的缺失，會直接影響到ASR的識別效果;第三個是我們的很多的產品是服務於兒童的，例如機器人和故事機是服務三到五歲的兒童，兒童的語言表達不是那麼準確清晰。舉個例子，「我想聽小紅帽」，小孩可能會說出小紅貓，而ASR沒有識別到這個歌曲，所以就需要將ASR識別錯誤的結果糾錯成正確的結果;再比如酒干倘賣無也經常被表達的亂七八糟，我們的技術也可以做到準確識別;

對於任何系統來說，糾錯都不是一個零和一的問題而是概率問題，例如，我有90%的把握認為我糾的是對的，也有可能70%的概率是對的。這就是我們剛才提到的系統要做分級，意圖置信度也要做分級等等的原因。本身技術也許不是完美的，但是可以通過一些策略讓交互更流暢，如果置信度是95%，那麼就強制糾錯;如果對糾錯結果感覺置信度高，那麼就可以通過多輪對話技術，詢問一下用戶，「是不是想聽小紅帽的故事?」來做意圖確認。

另外，還有一些是用戶口音或者是因為設備拾音導致的問題，用戶本來要說「唱一下七里香」，結果發音是「上一下七里香」，糾正用戶的表達方式也是糾錯模型需要解決的問題。

在實際做系統的時候，如果你有很多標註語料，那麼就會變成一個有監督的模型學習的問題，但剛開始沒有標註語料怎麼辦?

意圖識別本身是一個多分類的問題，加上一個NER的問題。如果有語料，我們可以利用很多模型，例如LR、SVM、CRF或者deep learning來做這個事情，但要是沒有語料，就會困難很多。

對話本身是一個概率轉移的問題。上句話說什麼，下句話機器要怎麼做回答，本身就是狀態之間概率轉移和對話策略選擇的問題，如果有語料可以通過強化學習等方法來解，但是大多數情況下，語料的獲取和標註非常困難，特別是多輪對話語料庫。

對於問答系統來講，需要解決用戶的query和知識庫里的<question, answer> 的語義相似度問題。分解開來看主要包括：一是 <question, answer> pair的正確性問題;二是query和<question, answer>的語義匹配問題。那麼怎麼計算query和< question, answer > 的語義匹配度呢?假如我有很多的query和< question, answer > 的語義匹配標註數據，那麼可以使用deep semantic matching的技術來解這個問題，如果沒有怎麼辦?

還有一個是chatbot，目前比較成熟的是通過檢索的方式來做，構建一個大規模的口語對話語料庫，然後用搜索的方式去解，但是也會遇到點擊反饋的問題，怎麼知道回答的結果好不好呢?

如果task-oriented沒有語料庫怎麼辦?Deep-X平台提供了一種解決方案，我們會先去嘗試定義一套意圖，包括query類別以及query本身裡面的實體，用戶的定義過程本身就是做一個query標註的事情，有了這個標註結果，我們可以自動的將其轉變為ABNF文法，就可以解決冷啟動的事情。

對話本身也是沒有數據的，用戶前一句說什麼，後面要用什麼做回復，在冷啟動階段可以考慮使用DFA + slot filling的方法來解。

有語料了就可以做數據標註，然後可以做一些分類和NER的模型來解決意圖理解的問題。在設計模型的時候也會遇到很多問題，例如典型的做二分類，假如兩個類別的語料是平衡的，這是比較好解的。最怕的是遇到語料極度不平衡的問題，比如我要從幾千上萬類Skill中識別出訂餐類的query，就會遇到與語料不平衡的問題。這個問題如何解決?我們可以考慮挖掘出處在分類演算法的分類面附近的query，讓用戶去做hard examples的數據標註工作，通過較少的數據標註來提升演算法性能。

上圖是實際系統中關於task的真實例子。

第二個是QA問答系統，在冷啟動階段，如何解決query和< question, answer > 的semantic matching所需要的大量標註數據?如果實在沒有數據，可以考慮先使用一些啟發式的演算法，通過語音交互的行為，來迭代演算法或收集語料。或者你可以使用transfer learning的方法，考慮使用搜索的用戶點擊行為，來構建語料庫。比如我們使用360搜索的點擊日誌，構建了大規模的<query, question>的語義匹配數據。

目前，問答系統實際用的架構分為事實性和開放性，事實性問題例如姚明身高多少?開放性的問題，例如紅燒肉怎麼做好吃?每個人都有不同的見解，開放性的問題會有很多不同答案。針對問題做不同的分類，應用不同的技術去解決，比如事實性問題通過知識圖譜解決，開放性問題通過CQA-QApairs的方式進行。如果對於一些不確定且又不在這兩類範圍內的問題，通過搜索引擎對前幾百條的結果做摘要來解這個問題也是可行的。

ChatBot比較靠譜的是基於檢索做大規模的擴充語料，我們的優勢在於有自己的Spider，每天對幾千億網頁數據抓取、清洗、解析，還可以抓到很多微博論壇的數據，構建了億級口語對話庫，基於這個對話庫可以做檢索的對話系統，它的主要技術就是進行索引，做query和response相關性計算的問題。

口語對話最簡單的就是單輪，你說一句，我說一句，多輪就是你說一句我說一句，你再說一句我再說一句。現在衡量一個ChatBot能力就是看你能夠聊多少輪，據悉小冰現在是5輪。檢索是目前效果不錯的，但也存在一些問題，比如怎麼評價語料庫庫構建的質量?

學術界研究的更多的是生成式對話系統，現在比較不錯的是利用基於深度學習的架構來做。右邊的圖是我們生成的模型生成一些對話，例如用戶說「下大雨了」，回復說「還沒有下雨呢」，用戶說「不可以喝牛奶你陪我玩會兒吧」，回復說「說不能喝牛奶的」，等等。雖然目前生成對話系統有些是可用的，但是大家可以看到它更多的是安全回答，沒有包含一些情感在裡面。

第二個問題是在遇到一些用戶的屬性信息時要保持前後一致，比如用戶問「你是男的嗎」，系統回答「是」，用戶再接著問「你有老婆嗎」，系統如果回答「我是女的，沒有老婆」，這就出現了人設前後不一致的問題。目前業界也在對此做研究，我們也在做這方面的研究。

下面我們講講持續優化的事情，剛才也提到分類以及NER識別。分類問題在剛開始冷啟動、語料很少的情況下，我們模型的準確率不夠，要做一些半監督的事情，例如Deep-X系統，根據線上的系統日誌可以自動的挖掘出一些可能不太靠譜的或者是有錯誤的數據推給運營人員做標註，這是一個半自動標註方法，這個事情做完以後，開發人員不需要天天看數據優化模型了，只要有運營人員幫忙標註數據，這個模型就可以運轉的非常好了，同時這也是大部分技術人員希望達到的狀態。

此外，還需要一些指標來評估服務的效果，比如說你的意圖識別的準確率，召回率，目前在Deep-X平台中，這些事情都已經做到自動化了，每天可以把數據給用戶做展示，方便用戶去運營。為此我們做了非常多的運營工具，當然這所有的一切都是為了節約工程師的時間，把技術模型的迭代轉變為通過數據標註的方式來做持續優化。

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！