OPPO小布助手演算法系統探索、實踐與思考

1 前言

對話互動是繼傳統PC、PC網際網路及移動網際網路之後，下一個時代非常有想象力的關鍵技術方向，無論是學術界還是工業界都有極高的關注度，同時作為OPPO萬物互融戰略的關鍵節點之一，承載著偉大而艱鉅的使命。

演算法是對話互動的核心能力之一，決定了語音助手能達到的智慧化水平，具有極高的技術價值。本文將主要從對話互動的目標、演算法要解決的關鍵問題，行業現狀與趨勢、小布主要實踐與進展，以及挑戰與未來幾個方面做個介紹。

2 對話互動目標與關鍵問題

通俗來說，對話互動的目標就是通過語音或文字以自然對話的方式，完成任務執行、資訊獲取、情感交流等人機互動過程。比如像科幻電影裡面的賈維斯、大白等智慧助理，代表了人們關於對話互動能力理想狀態的期待。

對話互動近年來受到越來越多的關注，其背後的原因究竟是什麼呢？其實回顧下近40年來資訊科技發展的歷程，就不難理解。我們知道，資訊科技先後經歷了傳統PC、PC網際網路、移動網際網路幾個大時代，其中每一個時代都與裝置密切相關，進而催生入口和互動方式的革命。而今我們正邁向被寄予厚望的AIoT時代，對話互動因其在新一代搜尋引擎、超級服務分發中心、新型互動方式等方面的巨大想象力，恰好承載了這一新時代下一入口級互動變革的使命願景。

然而，想要達到理想的對話互動效果是非常困難的，主要是因為它需要跨越目前成熟的感知智慧技術，邁向認知智慧，當下在認知智慧領域還存在很多尚未根本解決甚至未能清晰定義的問題。典型的認知難題包括如何表示和理解常識，如何使機器具有推理和規劃能力，如何使機器有像人一樣的想象力和自主性等。在某種程度上，可以說解決了認知智慧的問題，基本上就等同於實現了強人工智慧，足見對話互動的難度之高。

對話互動的主幹流程如下圖所示，從中不難發現幾乎所有關鍵節點都與演算法相關，演算法是取得較好對話互動效果的核心能力。

對於OPPO自研的小布助手，其演算法能力現狀如下表所示，語音喚醒主要由三方和軟體工程系統支援，目前在新機效果上對齊行業Top競品，但是存在老機型技術升級成本高、部分低端機型無法支援語音喚醒等問題；語音識別同時使用了三方和OPPO研究院的能力，由於語音識別技術相關成熟，整體效果較好，字錯率能控制在6%以下，目前的主要問題在於音訊質量；語音合成與語音識別類似，也是由三方和OPPO研究院共同支援，在準確性和流暢度上效果較好，但是自然度、情感化等維度評測非常主觀，目前也暫不支援使用者個性化；語義理解和對話能力主要有業務技術團隊提供，在語義理解方面準確率和召回率都能達到90%以上，存在開放域長尾query理解難度大的問題；在對話能力方面目前支援沉浸式強多輪、自由切換弱多輪、上文推理多輪等，多輪的難點主要是難評測，使用者習慣弱、線上滲透率低。

語義理解和對話能力是本文的重點，主要任務是在拿到使用者Query後，通過先理解使用者要什麼，再決定給使用者什麼，最終組裝合適資源恰當滿足使用者。由語義理解和對話能力組成語義演算法系統就是為了達成以上目標的，該系統的涉及主要會面臨系統性問題和技術類問題兩大類，如下圖所示。

系統性問題包括面向需要支援全領域query、數百項技能、多裝置多渠道的複雜系統，如何解耦拆解；面向產品需求多、模組多流程長、演算法不確定性大等問題，如何高效迭代；面向無法窮舉的多樣化口語Query，如何通過效果監控保障體驗；如何規避低階缺陷、答非所問、過度兜底等“智障”體驗。

技術類問題則包括演算法的選型、關鍵問題的建模求解、多輪對話的控制、效能方面的保障等。

3 行業現狀與演算法趨勢

首先，對話互動在應用場景方面已日趨成熟，涵蓋智慧家居、車載、生活出行、專業服務等眾多領域，方便快捷是自然語言對話互動方式的天然優勢，被越來越多的使用者接受，據預估2020年將有超過70億部裝置搭載語音助手。

另外，發展趨勢來看，近十年來頂級科技公司從未放棄在此方向上的投入，國外以蘋果、亞馬遜、谷歌三家公司作為代表，無一不把對話互動作為他們非常重要的方向；國內情況也類似，百度、小米、阿里巴巴都積極佈局，旨在搶佔對話互動這一未來流量入口。

一個值得關注的趨勢是，面向第三方裝置的對話互動智慧助理逐漸淡出，各家主要集中在自有裝置上大力發展，除了相關技術與裝置耦合緊密的原因外，還有一個更重要的原因是這一入口太重要了，沒有任何一個頭部裝置廠商願意將其完全交給第三方技術方。

對話互動也是學術界研究的熱點，從ACL論文的趨勢分析可以看出，近5年來對話互動方向異軍突起，在2019和2020年成為當前最熱門的研究方向。

參考：Trends of ACL: https://public.flourish.studi...

在核心的認知理解演算法方面，其求解正規化由傳統的強依賴語言、問題型別和人工定製經驗的多模組流水線方案，演變成了更簡單、通用、高效的端到端一體化方案。這種正規化的演進極大地簡化了問題求解流程，不僅能夠有效避免累積誤差，更使得大資料、大模型、大算力能夠落地應用，顯著提升效果。

近兩年來，在模型層面以谷歌BERT為代表的大規模預訓練模型橫空出世，橫掃各大語言建模任務榜單，為研發更先進的語義理解演算法模型釋放了巨大的潛能，這無疑會給對話互動的發展提供堅實的技術支撐。

總結來看，無論是工業界還是學術界都非常關注對話互動這一方向，這反映了行業對未來趨勢的預判。而演算法技術的突破性進展則進一步催化了對話互動產品落地的速度，使得未來將會更早到來。

4 小布演算法系統實踐與進展

如前所述，語義理解和對話能力一起構成了小布核心的語義演算法系統，以下部分將詳細呈現我們在這一方向上的實踐與關鍵進展。

首先，在業務需求方面我們主要考慮業務邊界、對話能力、使用者體量，以及評價指標這四個維度。在業務邊界方面，小布助手屬於全場景開放域對話互動系統，需要支援的領域包括系統控制、資訊查詢、影音娛樂、生活服務、智慧聊天等，共約包括數百項技能，使用者Query的廣度非常大；在對話能力方面，除了簡單指令型命令控制和單輪問題，還需要支援面向多輪的任務型、弱多輪、上下文理解等能力，以及對話推薦、主動對話等高階能力；在使用者體量方面，小布需要覆蓋歐加集團三品牌手機，以及手錶、電視等億級別裝置，千萬量級的日活；在評價指標方面，主要考慮需求覆蓋度、意圖召準率、技能滿意度、響應時間等。

概況來講，小布助手的使命任務是建立一種對話連線，連線的一端是歐加集團裝置生態龐大的使用者群，另一端是優質的對話式服務，藉助於這種連線來實現使用者價值、營銷價值，以及技術價值。

為了支撐上述業務需求，我們抽象總結了四項設計原則來指導演算法系統的設計：

領域分治：採用劃分領域的方式將全領域複雜問題進行分解，轉化成更簡單的子問題分組求解，降低求解的難度，提升系統的可掌控性；

效果優先：為了儘可能避免“智障”體驗，不拘泥於任何單一技術，以效果優先驅動演算法方案設計，規避低階缺陷；

閉環監控：建立完善的閉環監控機制，在研發階段通過產品、測試、研發等多方拉通的測試例設計提升測試覆蓋度，線上上採用實時動態測試集監控和人工評測來保障體驗；

平臺提效：為了應對眾多中長尾的技能支援，推進技能平臺的建設，以一致、通用的平臺化解決方案降低中長尾技能的研發和維護成本。

參考業務需求和設計原則，小布助手目前的演算法系統整體架構如下圖所示。首先，在平臺與工具方面，基礎演算法以行業主流的深度學習演算法為主，在其上針對不同的問題型別構建演算法方案，並進一步封裝成NLU框架、通用圖譜問答、技能平臺、開放平臺等模組。然後在業務方面，最上層會採用符號化、結構化、數值化的思路對query進行通用處理，再按系統應用、生活服務、影音娛樂、資訊查詢、智慧聊天幾個維度進行業務拆分，各業務線獨立迭代。最後再結合對話生成、融合排序優選出最佳的技能去滿足使用者的訴求。

從處理流程上，又可以分為預處理、意圖識別、多分類ranking、資源獲取和後置處理幾個環節，其中前三個節點主要對意圖的召準率負責，後兩個節點對資源的覆蓋度和結果相關性負責，全流程一起為最終的技能執行滿意度負責。

語義演算法系統中涉及的關鍵演算法模組如下圖所示，後續將分別對語義理解、對話管理、對話生成三個核心模組進行介紹。

意圖識別是語義理解的核心模組，其主要任務是通過對使用者當前Query，以及互動歷史的分析，推斷使用者到底想要幹什麼，包括封閉域、開放域、上下文幾種典型的場景。

槽位提取是與意圖識別密切關聯的任務，主要任務是從使用者當前Query以及互動歷史中提取關鍵資訊，輔助精準獲取使用者所需的答案/內容。

意圖識別和槽位提取共同構成語義理解模組，其難點主要在於口語多樣化（億級別獨立Query）；歧義性（如小豬佩奇是動畫片，也是App）；依賴知識（如“可不可以”竟然也是一首歌名）。

對話管理是語義演算法系統的另一關鍵模組，其任務是根據當前Query和對話上下文推導對話狀態，並據此推理對話系統下一步的最佳響應。

完成語義理解和對話管理後，還需結合對話生成才能實現技能的最終恰當的執行反饋，對話生成的任務就是根據語義理解的解析結果和要執行的動作，通過恰當的方式獲取恰當的響應話術。

在演算法模型方面，小布以強深度學習驅動為主，這類模組一方面效果較好，另外技術方案也已經比較成熟，存在非常多成功的案例。

然而值得強調的是，在這一領域基本不存在“一招鮮”的單一模型解決所有技術問題的演算法方案，一般基於深度學習的主模型負責保障效果的基本面，仍需要結合定製規則來處理邊角的badcase。

面對系統應用操控類技能，為了提升語義理解的效果，我們主要採用基於規則和深度學習模型融合的方案，其中反向規則用於快速拒絕領域外的Query，正向規則用於覆蓋強說法，深度學習模型負責通用case的泛化識別。此外為了提升意圖和槽位的聯合準確率，引入了多工聯合學習。

多工聯合學習能使得意圖和槽位互相消歧，主要應用在電話、簡訊、日程等技能上，相對與單任務獨立學習，一般準確率能提升1%～3%。結合細緻的資料驅動優化和規則校驗，基本可以做到95%以上的召準率。

面向知識強依賴型的技能，如音樂、電臺、影視等，我們主要採用了融合知識的意圖識別方案，如下圖所示。這類技能主要難點是單從句式無法判定意圖，從Query中準確提取資源欄位非常關鍵，融合資源關聯結果後再進行意圖識別能顯著降低問題求解的難度。

不同於封閉域，開放域的意圖識別難以建模成分類問題，一般需要採用語義匹配方案進行求解。針對這類問題，我們主要採用深度語義匹配方式，如下圖所示。相對傳統基於文字符號的匹配，效果更好，匹配準確率可達到95%以上；不過也存在主語識別、語義包含等問題，需要配合下游驗證策略控制。目前主要應用在資訊查詢和閒聊QA匹配中。

此外，為了進一步提升語義理解的效果，我們也在探索大規模複雜模型的落地方案。在大規模預訓練語言模型方向，團隊在開源模型基礎上進行改進、重訓與微調，實現了效果上的快速提升，目前排在中文語言理解測評基準（CLUE）總排行榜第六名。

不過這類模型計算複雜度很高，一般難以滿足線上推理的時效性要求，需要結合知識蒸餾等加速方案才能落地應用。

常見的知識蒸餾方案可以分為資料蒸餾和模型蒸餾兩種，其中資料蒸餾的假設是簡單模型是因為標註資料的缺失導致效果不如複雜模型，如果利用複雜模型提供足夠多的偽標註資料，可以幫助簡單模型逐漸逼近複雜模型的效果；模型蒸餾的假設是簡單模型不僅僅是缺少足夠多的資料，而是缺乏好的指引，如果通過訓練複雜模型過程中獲得的中間結果來同時指引簡單模型的訓練過程，則有助於簡單模型逼近複雜模型的效果。資料蒸餾和模型蒸餾都有在小布助手業務中落地應用。

對話系統也被認為是下一代搜尋引擎，使用者關於知識問答類的訴求也非常多，預期是能夠獲得精準答案，為了滿足這類需求，我們通過資料獲取、資料探勘構建自有知識庫，再結合線上語義匹配、KBQA等提供問答服務。

此外，為了精準回答垂域事實類的問題，我們還構建了基於知識圖譜的通用問答能力，對於精品垂類，通過資料合作和自助爬取構建領域圖譜，再基於模版和圖譜進行精準問答。

小布助手目前線上有超過50%的頭部流量由自建知識問答服務，長尾部分還以來度祕、搜狗等強搜尋公司。

在對話管理方面，常用的方案包括基於有限狀態機的方案、基於Slot-Filling的方案，以及端到端的方案，其難點是靈活的流程控制、上下文的繼承與遺忘、意圖跳轉、異常處理等，目前主要採用Slot-Filling的模式。

為了在多輪中達到比較好的上下文理解效果，小布助手實現了基於指代消解的上下文理解方案，用於處理多輪對話中普遍存在的指代和省略問題。

參考：ACL'2019 Improving Multi-turn Dialogue Modelling with Utterance ReWriter

藉助於對話管理和上下文理解，小布助手已支援沉浸式強多輪、自由切換弱多輪、上下文推理多輪等模式，覆蓋了任務型、資訊查詢、多輪聊天等業務場景。

在對話生成方面，目前行業裡主要有基於模板、基於檢索、基於模型三種型別，由於生成式模型可控性弱，目前小布主要採用基於模版和基於檢索的方案，生成式模型仍在預研中。

在演算法工程方面，早期為了快速上線，提供了基於Python的服務框架，通過部署多例項來彌補單服務併發能力弱的問題；目前針對計算複雜度高的服務也在探索運算元化工程重構優化，以及聯合機器學習平臺團隊探索更簡單高效的服務模式。

在技能建設方面，早期為了快速上線，以技能定製研發為主；去年底開始啟動技能平臺建設。主要思路是標準化離線模型生成和線上推理流程，將關鍵演算法運算元化，通過資料匯入和流程配置完成技能研發，降低中長尾技能支援和維護成本。

最後，為了保障對話互動的效果體驗，我們聯合資料團隊和評測團隊構建了全流程的閉環監控方案，先由研發自測保證演算法模型效果符合預期，然後在發版時再進入一輪批測，確保不會引入新的風險；上線以後，會有例行的監控和即時監控來分別保障整體效果和監控關鍵功能正常；此外，還會引入基於人工的抽樣評測和三方評測進一步監控體驗。