前不久，OPPO旗下的人工智能助手「小布助手」月度活躍用戶數突破一億，成爲國內首個月活用戶數破億的手機語音助手。web
通過2年多的成長，小布助手在能力上實現大幅升級，也融入了咱們身邊便捷的服務功能。小布團隊亦克服了諸多技術難點，爲用戶帶來了更智能的服務。爲此，小布團隊撰寫了一系列文章，詳細介紹小布助手背後的技術支撐，本文是揭祕小布背後技術的第三篇。算法
第一篇：對話系統簡介與小布助手的工程實踐安全
第二篇：小布助手算法系統的探索、實踐與思考微信
1. 對話系統的基本架構
智能對話交互已逐步成爲新一代的人機交互趨勢，而OPPO研發的小布助手也已覆蓋手機、手錶、電視、耳機等多類終端設備，是一款集成任務型技能、知識問答、聊天、對話推薦、主動對話等綜合能力的智能助理。網絡
小布助手功能可分爲五類：架構
系統應用類：肯定的命令需求，如系統設置、時間技能、應用技能等併發
信息查詢類：客觀知識的查詢/搜索需求，如「今每天氣怎麼樣」等app
泛娛樂類：知足用戶娛樂需求，包括聽歌、看電影等框架
生活服務：知足用戶平常生活需求，包括導航、打車、訂餐等編輯器
聊天類：主觀類的閒聊需求，包括人設問答、閒聊問答、話題多輪等
小布助手架構是融合了任務型、知識問答型、聊天對話型的綜合對話系統。
對於任務型對話系統，由用戶輸入語音，首先通過ASR模塊識別爲文本，下發到NLU服務進行天然語言語義模塊，生成語義表徵結果，如領域Domain+意圖Intent+槽位Slot，而後下發給DM對話管理模塊，而後對話狀態跟蹤更新上下文的對話狀態，一般爲詞槽表徵的對話狀態。
對話策略模塊基於當前對話狀態選擇最佳的迴應action，下游不一樣BOT的action可能涉及到檢索、推薦、系統問、意圖澄清以及API調用；對話action的結果通過NLG模塊生成合適的天然語言，最後通過TTS語音合成輸出回覆語音。
聊天對話系統主要包括如下幾層。
Offline閒聊知識庫索引層：主要負責基於離線訓練好的語義編碼模型獲得全部問題Query的語義向量，而後基於高維向量索引工具生成語義索引，同時基於分詞生成文本索引，最後服務於線上服務；
Online在線服務層：主要是Query話題識別情感識別等處理後，下發給應答引擎包括模板應答、檢索式應答、生成式應答，以及主動對話引擎，而後融合排序模塊基於應答模塊輸出的候選回覆進行深度語義排序最終輸出最佳回覆，回覆更新到對話上下文輔助Query理解；
另外最下面的Offline離線的用戶興趣挖掘層，主要基於用戶query挖掘用戶興趣主題，最後服務於主動對話引擎，用來發起新話題吸引用戶長程交互。
2. 任務型語義理解
語義理解中存在兩個關鍵問題：
語義表徵Input: Query+Context, Output: ?
語義理解算法Algorithm(Input->output)
語義表徵方法主要包括典型Query/典型指令、Term空間、結構化意圖和槽位、語義依存結構樹四種。目前對話系統基本採用這種Semantic Frame意圖+槽位的語義結果表徵方法，意圖槽位表徵也存在slot之間的關係沒法更爲精細刻畫的問題，因此對於多跳圖譜問答等複雜語義依賴的場景，須要經過語義依存結構樹的表徵方法做爲補充加強，同時語義理解任務複雜度隨着語義表徵精細程度會越複雜。
實際在一個好的工業界AI系統中，根據不一樣階段和不一樣領域的需求差別，綜合運用四個層次的NLU技術來實現，小布助手目前以意圖槽位體系的語義理解爲主，在信息查詢百科、聊天等領域運用Query改寫以及語義檢索技術，來實現開放域多樣且無邊界的query的意圖理解，在垂域問答採用查詢推理樹來表徵語義結果。
對於意圖識別算法架構，主要分爲語義檢索架構和分類模型架構。
語義檢索的優勢是誤差小在乎圖樣本少時效果好，同時意圖不用固定，可經過意圖知識庫任意擴展，因此擴展性強。缺點是方差大，且結果容易受噪聲樣本的影響，只能進行意圖識別，詞槽抽取沒法多任務並行。適用場景是：百科問答/聊天類意圖非固化且句式靈活多樣的場景。
分類模型架構的優勢是方差小，泛化能力強，與槽位填充可多任務並行處理。缺點則是誤差大，訓練數據集少則效果很差，意圖類別必須固定。適用場景是：意圖類別固定的場景，如系統操控等指令類技能。
經常使用的意圖識別算法主要是各類分類模型CNN/LSTM/Transformer。這裏重點說明一下特徵加強的意圖識別或引入外部知識的意圖識別，包括引入實體位置特徵、實體類型特徵、詞性特徵等。
實體位置特徵直接增長NER實體特徵下降模型學習難度，但可能存在先驗特徵噪聲需具體技能具體分析，實體類型特徵主要是引入如時間、地點等實體類型特徵加強模型學習效果，準召提高均有0.5-1個點左右提高
槽位提取本質上是序列標註任務，模型實踐主要包括LSTM+CRF/Lattice LSTM+CRF，CNN+CRF/IDCNN+CRF，Lattice LSTM基於字特徵+詞特徵加強特徵提高模型準召，F1提高約0.7%-2%不等看具體技能，IDCNN經過引入Dilation Convolution膨脹卷積以較少層得到更大感覺野，相同F1提高inference性能。
槽位可分爲可枚舉詞槽，和不可枚舉詞槽，即任意文本槽位。
可枚舉詞槽：如日期時間、數字、金額等說法固定，或有限資源池的詞槽，如音樂影視。槽位提取方式一般基於詞典AC自動機、規則DFA進行快速匹配抽取。
不可枚舉槽位：如日程鬧鐘事件、聯繫人微信好友名、短信內容等非固化形式的槽位類型。槽位提取方式主要是序列標註算法模型。
任意文本提槽，好比短信微信技能裏的給XX發送XX信息內容，咱們基於詞槽內容採用任意文本填充的方式來自動化數據加強，基於訓練出的提槽序列標註模型提槽後，經過可配置模塊進行驗證，相比未進行數據加強的模型召回率有3%以上的提高。
基於獨立的意圖識別和槽位提取模型，來進行語義理解會存在語義理解歧義問題，基於多任務聯合建模能夠有效緩解歧義問題， 其優點主要在於Intent能大大縮小Slots的歧義空間，由於Slots是Query意圖的重要特徵，較獨立模型F1可提高1%-1.5%，較分離模型訓練效率高。
大規模預訓練語言模型在因爲模型容量巨大學習到豐富的知識分佈，對於語料相對匱乏或提升輕量級模型效果的業務場景很是有效，基於BERT的Joint Task Learning在 Fine tuning階段將輸出層改造爲分類+序列標註的結構，由於意圖理解和槽位解析是相輔相成的任務，能夠提高模型效果。
線上環境對在線Inference性能要求很高，一般要求<10ms，像BERT這樣的大模型，就很難知足要求，如何使輕量級模型達到複雜模型的性能，能夠經過知識蒸餾來是實現。
原來咱們須要讓student model的softmax分佈與真實標籤匹配，如今新增一個目標讓student model與teacher model在給定輸入下的softmax分佈匹配。後者比前者具有優點，由於通過訓練後的原模型，其softmax分佈包含有必定的知識，真實標籤只能告訴咱們，某個Query是音樂意圖，不是其餘意圖；而模型預測的softmax分佈可能告訴咱們，目標Query最多是音樂意圖，不大多是電臺意圖，毫不多是打開APP的意圖；另外在預訓練語言模型，知識蒸餾更可能是想經過表徵損失向輕量級模型注入更多的先驗知識，在表徵損失加上監督標籤損失的基礎上實現模型性能的提高。
3. 開放域生成式聊天算法實踐
小布助手聊天總體架構基於安全、擴展性、高效迭代、服務高可用及算法模型高性能原則進行設計，同時自建閒聊佔比85%。
生成式聊天架構採用級聯模型架構提高端到端效果，關鍵點以下：
拒絕策略層—提升服務性能並保證生成式回覆的安全性
運營風格生成模型—基於自建閒聊知識庫進行訓練，儘可能過擬合知識庫並經過閾值策略實現結果優先
短回覆寒暄生成式模型—兜底全部運營風格模型未能有效應答的部分
過濾策略層—敏感過濾、品牌過濾、強觀點過濾及萬能回覆過濾保證回覆安全與回覆質量
咱們借鑑業內生成式直接融合屬性信息，基於多屬性控制的生成式模型利用屬性控制回覆生成，增長屬性信息如句式、情感信息、觀點、系統人設等，達到控制生成文本風格的目的，但願生成的回覆更爲可控，避免出現負面情感或疑問句式的回覆。
單輪生成式閒聊模型分爲運營風格和通用回覆風格兩種。運營風格生成式模型是基於運營同窗編寫的閒聊知識庫來訓練的，通用回覆風格模型是基於開源微博單輪對話數據集來訓練的，具體效果仍是能夠看到存在部分萬能回覆的問題，以及敏感QUERY和強觀點型配對容易產生敏感問題。
多輪生成式聊天業界主流方案以下，多輪聊天的人工評測標準主要是Google Meena率選提出SSA人工評測標準，SSA (Sensibleness and Specificity Average)：Sensibleness -->合理性（敏感性）, Specificity --> 針對性（特異度），同時也發現優化目標：Perplexity與SSA高相關，優化Perplexity便可提高SSA。
多輪生成式聊天算法模型方案，目前已經實踐的有兩種，一種是基於12層中文GPT2模型在多輪對話數據集上Finetune，另一種是基於華爲NEZHA語言模型+下三角Attention Mask變成單向語言模型，再在多輪對話數據集上Finetune。
多輪生成式挑戰主要是，受限於上下文記憶能力會出現回覆自相矛盾、缺少知識信息量、生成回覆的可控性等問題。
情感識別算法模型：咱們在百度千言情感分析賽道評測TOP3，主要應用場景包括表情符，情緒安撫、生成式閒聊、其餘待挖掘的情感化場景；目前情緒類別支持喜歡、討厭、開心、悲傷、生氣、恐懼、驚訝、無情緒、其餘情緒9種情緒類別。
4. 深度語義問答FQA技術實踐
語義匹配問答架構主要分爲拒絕策略層、Query預處理、智能改寫包括代詞指代消解、同義詞改寫以及後續規劃的語義遞進或轉折場景下的完整性改寫、語義檢索、語義排序、語義消歧等可配置模塊，可配置的策略模塊用於快速解決線上高優BADCASE問題，同時小布助手在百度語義匹配賽道衝擊過第一名。
語義召回模型——採用SiameseNetwork框架，使用分類任務建模思路進行訓練，且訓練樣本數據範式採用listwise範式，模型目標是最大化正樣本之間的相關性，同時抑制負樣本之間的相關性。
語義匹配模型實踐方面，對於負樣本採樣策略優先使用標註的負樣本，標註負樣本不足狀況下，經過卡字面相關性閾值策略進行負採樣，以保證負樣本有必定相關性，儘可能構建semi-hard數據集用來加速模型收斂，同時提高模型語義表徵精度；損失函數方面咱們主要嘗試hinge loss、Triplet Loss、AMSoftMax等。
AM-softmax在餘弦類似度上添加一個margin，能夠提升類間可分及類別的可辨別性， 使用cnn網絡，結合AM-softmax的loss函數，可以取得最好的語義表徵能力，通用評測集下的準確率提高1%，同時召回提高明顯。
高緯數據索引算法主要有樹索引和圖索引兩種，經過基於同等召回率的召回性能試驗對比，咱們選擇NGT圖索引算法來進行向量索引，相對於樹索引算法，具備更好的索引效果及索引性能。
語義排序算法模型主要落地實踐了交互表徵模型Attention-based CNN、ESIM模型（Ehanced BiLSTM for NLI)以及Transformer模型等，在召回階段咱們獲得的候選query集合，而後基於用戶當前query與候選query進行交互式表徵建模能提升語義表徵精度從而提升語義匹配準確率；另外ESIM模型優勢在於精細設計的序列式推斷結構，考慮局部推斷和全局推斷的融合，準召效果相對也會高一些 。
5. 算法服務工程
算法服務架構主要基於領域分治、NLU服務多進程併發高性能的原則進行設計。關鍵點：
業務微服務化，業務域按垂域拆分，下降耦合性、提高算法服務性能，提升敏捷迭代效率；
模型tfservering服務化，TF Serving集羣管理TF模型易部署，自然支持模型熱更新機制，複雜模型可利用GPU進行inference，同時經過本地模型服務實現服務降級策略。
NLU算法服務內部分層架構，多層次拒絕/召回，域外粗召回到域外高召回再到域內高準確， 經過可配置模塊高效解決Case類問題，避免引入破壞模型平衡的問題，模型分佈收斂到線上數據分佈後保持穩定。
服務內部分層架構快速拒絕域外請求，極大提高算法服務性能，保障小布助手端到端流暢度的性能體驗。
6. 總結與展望
封閉域任務型對話技術關鍵挑戰有多個，好比，語義理解模型的魯棒性，特別是高頻技能線上query分佈變化快，如何保證線上模型泛化性是關鍵；對話能力更天然流暢的對話管理技術；上下文意圖理解（當前已經具有人稱/實體代詞、部分零指代的指代消解能力，但泛化能力有限）；融合設備渠道、LBS位置信息及客戶端狀態等場景特徵+用戶基本屬性+用戶興趣畫像的綜合意圖理解。
開放域對話技術方面，檢索式聊天技術能解決高頻頭部query問題，但解決不了長尾問題以及開放域多輪對話問題。融合知識問答、閒聊、對話推薦爲一體的端到端多輪生成式，是將來ChatBot的關鍵技術方向。
這裏也存在很多技術挑戰，包括保羅萬象的知識問答、情緒感知的共情能力、融合系統畫像與用戶畫像的回覆生成、邏輯/觀點/人設一致性、回合制被動問答向主動式對話演進、全雙工的持續對話能力。
☆ END ☆
OPPO互聯網技術團隊招聘一大波崗位，涵蓋C++、Go、OpenJDK、Java、DevOps、Android、ElasticSearch等多個方向，請點擊這裏查看詳細信息及JD。
更多技術乾貨
掃碼關注
OPPO互聯網技術
本文分享自微信公衆號 - OPPO互聯網技術（OPPO_tech）。
若有侵權，請聯繫 support@oschina.cn 刪除。
本文參與「OSC源創計劃」，歡迎正在閱讀的你也加入，一塊兒分享。