前不久，OPPO旗下的人工智能助手「小布助手」月度活躍用戶數突破一億，成爲國內首個月活用戶數破億的手機語音助手。java
通過2年多的成長，小布助手在能力上實現大幅升級，也融入了咱們身邊便捷的服務功能。小布團隊亦克服了諸多技術難點，爲用戶帶來了更智能的服務。爲此，小布團隊撰寫了一系列文章，詳細介紹小布助手背後的技術支撐。本文是揭祕小布背後技術的第一篇，主要介紹系統架構設計和演進。python
1. 行業價值
1.1 前言
對話系統是一項接近30年研究歷史的技術，表明人機交互的將來。近十年來隨着語音、NLP領域的階段性突破和工業界應用日趨成熟，用戶價值、行業規模迅速上升。web
從場景來看，對話系統大體分爲三類算法
任務型：答案精確，限定領域，以最簡交互知足用戶爲目標，好比定鬧鐘。spring
問答型：答案寬泛，限定領域，以最簡交互知足用戶爲目標，好比百科。編程
閒聊型：答案寬泛，開放領域，以對話輪次爲目標。後端
智能助理是以任務型爲主，融合問答型、閒聊型，集大成的對話系統產品形態，行業價值潛力巨大。
緩存
1.2智能助理
AIoT時代來臨，萬物互融背景下，智能設備羣愈來愈依賴智能助理作天然的人機交互。智能助理將覆蓋千千萬萬設備，擁有巨大想象空間。性能優化
英國市場調研公司Juniper Research預測，到2023年，搭載智能助理的設備將從2018年末的25億部增長到80億部。微信
用戶層面來講，智能助理雖然屬於小衆功能，可是隨着智能設備的普及，以及早期用戶的逐步培養，熟悉度和認知度在逐步上升，有着較大的上升空間。
智能助理帶來的用戶價值有三層
效率
個性
情感
隨着行業進一步普及，在小屏、無屏、大屏的基礎上，逐漸延伸出更多針對垂直場景和人羣的智能設備，如教育智能屏、故事機、AI學習機等。
小布助手是OPPO公司的智能助理，覆蓋公司的各種終端設備，並不斷增長新入口，覆蓋衆多任務型、問答型和閒聊型的垂域。
對話系統做爲智能助理中的「大腦」，是最核心的技術點之一。有對話系統，智能助理才能理解用戶的訴求，用對話式的服務知足用戶效率、個性、情感上的需求。
2. 業界架構
2.1 綜述
首先介紹對話系統的典型架構。在學術界，對話系統主要有Pipeline和E2E兩種架構，其中Pipeline在工業屆應用較多，E2E還處在探索階段。
Pipeline模塊化架構
ASR（語音識別Automatic Speech Recognition）
接收音頻輸入，輸出一個轉錄的句子文本。通常包括四大塊：信號處理、聲學模型、解碼器、後處理，首先採集聲音，進行信號處理，將語音信號轉化到頻域，從N毫秒的語音提出特徵向量，提供給聲學模型，聲學模型負責把音頻分類成不一樣的音素，接着解碼器得出機率最高一串詞串，最後的後處理就是把單詞組合成容易讀取的文本。
NLU（天然語言理解Natural Language Understanding）
負責將天然語言表示成計算機可以處理的結構化數據。接收文本輸入，輸出結構化的三元組Domain（領域）+Intent（意圖）+Slot（槽位）。主要經過分詞、詞性標註、命名實體識別、句法分析、指代消解等進行語義解析。
DM（對話管理Dialog Management）
負責控制整個對話過程。接收NLU的輸出，維護一些上下文狀態和對話策略，輸出具體要執行什麼動做，好比進一步詢問用戶以得到必要的信息。DM是對話系統的主體，有以下2個重要的模塊：對話狀態跟蹤（Dialog State Tracking，後文用DST表述）和對話策略（Dialog Policy，後文用DP表述）。DST記錄T-1甚至T-N狀態與當前時間T的狀態，結合上下文，肯定當前的會話狀態；DP根據會話狀態和具體任務決定要執行什麼動做。
ASR和NLU決定了語音交互的下限，DM決定了語音交互的上限。
NLG（天然語言生成Natural Language Generation）
根據DM輸出的系統動做，生成回覆內容。通常有基於規則模板的方法和基於深度學習的方法。
TTS（文本轉換語音Text To Speech）
須要控制多音字的發音和韻律節奏，好比什麼地方停頓，字詞的輕讀或重讀。
小結：模塊化pipeline架構的優勢是可解釋性強，易於落地，大部分工業屆的任務型對話系統基於此架構。缺點是各模塊之間相對獨立，難以聯合調優，模塊之間的偏差層層累積。
E2E端到端架構
近年來，隨着端到端神經生成模型的發展，爲對話系統構建了端到端的可訓練框架。這類架構但願訓練一個從用戶端天然語言輸入到機器端天然語言輸出的總體映射關係（即合併NLU、DM、NLG做爲一個模塊），具備泛化和遷移能力強的特色，打破了傳統pipeline架構的模塊之間的隔離。然而，端到端模型對數據的數量和質量要求很高，效果不可控，而且對於填槽、API調用等過程建模不夠明確，工業屆應用效果有效，仍在探索中。
接下來，分別介紹不一樣類型對話系統的典型業界實現。
2.2 微軟小冰：聊天型對話系統
微軟小冰是開放域聊天的社交聊天機器人，主打「EQ」。通常經過CPS（每次會話的對話輪數）指標來評估聊天機器人的效果，CPS越大，聊天機器人的對話參與能力就越好。小冰的平均CPS有23輪（2017年4月數據）。
下圖給出了小冰的總體架構。它包含三層：用戶體驗層、對話引擎層和數據層。
用戶體驗層
該層將小冰鏈接到流行的聊天平臺(如微信、QQ)，並以兩種模式與用 戶交流，全雙工模式和輪流對話模式。該層還包括一組用於處理用戶輸入和小冰響應的組件，如語音識別和合成、圖像理解和文本規範化。
對話引擎層
由對話管理器、移情計算模塊、核心聊天和對話技能組成。對話管理器由DST和DP組成。移情計算經過用戶數據、小冰人設等數據輸入，計算特徵做爲DM和技能的輸入。閒聊和技能融合生成式和檢索式兩種不一樣方案
數據層
存儲收集到的會話數據(文本對或文本圖像對)、用於核心會話和技能的非會話數據和知識圖譜，以及小冰和全部註冊用戶的畫像。
相關資料能夠參考：https://arxiv.org/pdf/1812.08989v1.pdf
2.3 小蜜機器人：問答型對話系統
小蜜機器人是經典的pipeline架構，因爲客服類機器人的應用場景都是網頁上的文本交互，因此不涉及ASR和TTS模塊。
它作到了領域化和平臺化，面向阿里生態圈、商家生態圈和企業生態圈支持以PaaS和SaaS輸出。模塊化整個對話管理和流程模塊化，構建算法和業務模塊可插拔的並行架構體系。
相關資料能夠參考：https://zhuanlan.zhihu.com/p/33596423
2.4 度祕、小愛、Alexa等智能助理
它們以任務型爲主，也包括聊天和問答，度祕、小愛是基於經典的pipeline架構，下面以小愛爲例簡要介紹。
小愛：
多路對話管理召回，每一個垂域有完整的NLU和Action
流量全垂域分發，用意圖預判模型減小流量
中控模塊DM的Policy作返回結果的意圖選擇
2.5 開源方案：rasa
rasa基於pipeline架構
Interpreter承擔NLU的職責，Tracker+Policy+Action承擔DM的職責
模塊化設計，特別是interpreter流程可定製
變化最大的action隔離，可嵌入外部server
大量採用配置驅動的設計，基於規則配置完成對話流開發
Rasax提供對話驅動開發方案，評估、標註、測試平臺
3. 小布助手工程實踐
3.1 對話系統架構設計和演進
OPPO小布助手總體系統分層以下：
其中對話系統爲左側的用戶域、對話域、語義域，參考經典pipeline架構搭建。
除語音輸出輸出相關的基礎體驗外，對話系統的演進目標大體分兩個階段。
提高技能覆蓋率和技能意圖識別召準
挖掘提高技能滿意度，亮點技能打造
階段1以垂域快速迭代爲核心，階段2兼顧公共能力建設和垂域對話語義優化爲核心。
階段1：垂域快速迭代
技能覆蓋率和單輪意圖識別召準爲主要目標，對話系統僅需提供強弱多輪的基礎能力便可知足本階段訴求，追求垂域各自制定目標和節奏快速迭代，垂域間低耦合。
設計原則爲：
康威定律：[垂域(算法+工程)]，根據feature team劃分業務，每一個垂域服務端分算法和工程，以此爲依據劃分服務，負責完整的對話管理和語義理解
低耦合：垂域間工程不耦合，算法除全局排序決策外，各垂域NLU一樣不耦合
高內聚：框架抽象常見對話管理功能，中控負責全局調度，垂域服務專一邏輯
階段2：公共能力建設和垂域優化
技能覆蓋和單輪意圖識別召準優化到必定程度後，技能滿意度偏向對話產品體驗，以及亮點技能打造。
本階段對話語義公共能力存在較多需求，公共建設有助於下降垂域間重複開發和維護成本，保持對話體驗一致，以及保障質量和性能。
當前對話管理組件逐步解耦建設中。
設計原則爲：
控制反轉：垂域的DM服務不直接控制對話，經過抽象協議提供必要信息，由框架和公共對話管理控制和決策對話。其餘對話管理組件同理。
單一職責：對話管理各原子能力拆解爲對話組件，組件由中控服務編排，下降複雜度，提升複用性。
向下兼容：DM服務過去承擔完整對話管理功能，協議擴展保證向下兼容，使DM既能託管對話管理，也能承擔對話管理。
階段1已支持的強弱多輪和意圖識別外，跟隨產品特性落地逐步建設覆蓋如下對話能力，打造對話產品體驗和亮點技能。
3.2 對話框架
過去對話系統裏，迭代最頻繁的業務服務是DM和NLU，分別實現對話邏輯和語義理解。
爲解決業務DM服務研發和NLU服務研發的公共問題，抽象出2套框架，DM framework和DAG framework。
DM框架
DM服務輸入domain、intent、slot和對話狀態，輸出技能的action和新的對話狀態。
小布助手的DM服務有兩個階段
多路對話管理階段，DM服務負責完整的對話管理能力
中心對話管理階段，DM服務負責action的產出，對話管理託管給上層中控服務統一負責
爲了解決業務DM服務兩個階段的公共問題，分析以下：
業務流程類似度較大，有統一業務流程的基礎
對話管理能力重複建設
代碼結構相差很大，不利於新人閱讀
各dm服務各自提供sdk供上層調用，接口與協議沒法統一集中管理
DM服務開發框架解決以上問題，設計原則以下：
採用分層設計思想，解耦業務邏輯，下降業務的耦合以及相互的影響
採用spring El表達式+註解的形式規範代碼的風格以及可讀性
依賴倒置+里氏替換原則+面向接口編程解決各業務上層差別化業務邏輯實現
| 框架使用前 | 框架使用後 | 效果 |
|---|---|---|
| 能力重複建設 | 框架提供默認處理，共同使用框架能力 | 節約了40%的代碼量（Statistic統計技能平臺技能由原來9000代碼量減小到5000左右) |
| 可維護性，可讀性弱 | 返回協議字段，值來源清晰，抽象統一的處理流程，同時每層提供足夠的擴展性 | 短交接（單個技能交接由平均3天/個縮短爲1天/個） |
| 統一協議，統一接口 | 各dm服務依賴框架的sdk，實現框架對外定義的統一接口 | 實現了協議的統一，調用的路由註冊邏輯 |
DAG框架
NLU分垂域建設，初期採用python搭建原型，java side car proxy的方式服務化。
逐步暴露部分工程問題：
算法各小組算子能力類似，但調用順序區別較大，相同的算子能力重複建設，算子的維護成本較大，各小組的算子能力沒有實現公用
敏捷迭代小組採用Python實現相應的能力，服務的性能存在必定問題
爲了實現技能nlu領域的能力複用，監控完善，性能效率的提升，支持技能nlu領域的快速上線，分層沉澱算子，用DAG框架進行編排。
算子層次設計：
基礎類庫層負責最底層的能力建設，上層各算子依賴底層基礎類庫層實現，業務層採用DAG框架將算子組合構建須要執行的流程拓撲圖(以下圖)，快速搭建領域nlu。
試點業務收益：
平響下降71.8%
單實例併發提高50倍
單技能算子代碼複用率95.7%
3.3 性能優化實踐
小布助手追求用戶的極致體驗，流暢度是其中最重要的維度之一。
咱們經過高速攝像機拍攝，小布助手與同類產品同時發起交互，到最終返回技能結果展現時間的對比，按照線上query實際佔比計算勝出率，做爲流暢度核心指標。
如下將主要展開描述流暢度優化的工程實踐。
問題分析
服務端三方資源執行耗時佔比最大。服務端耗時中，三方資源執行耗時佔比最大，80%+
服務端語音識別耗時佔比第二。
客戶端渲染交互可更簡潔。部分垂直技能客戶端交互可更簡潔，執行可更快
整體解決方案
並行：預測、串改並
剪枝：快慢分層、多級緩存
提速：三方自建、雲端VAD、交互簡化、執行優化
預測整體思路
預測是架構複雜度較高的特性，展開說明小布助手的實踐。
在用戶的語音交互過程當中，ASR流式中間結果不斷上屏，直到尾點識別VAD結束，纔會獲取完整的用戶音頻輸入。
利用業務特性，預測能夠作到「邊聽邊想」，將識別過程和執行過程並行化，縮短串行等待的時間。
分爲有2種策略
VAD階段並行執行，高準確低收益。
識別階段並行執行，低準確高收益。
當前主體採用第1種策略，在後端請求放大的成本和耗時的優化間平衡。
預測對架構存在較大沖擊，實施存在難點。1個請求拆爲n-1個非正式預測請求和1個正式請求，且下游沒法知道此次請求是否爲正式請求，有狀態服務會引入反作用致使不正確的結果。
解決問題思路分爲3種
每一個預測請求回撤狀態
正式請求完成後提交狀態
改造爲無狀態
預測方案——每一個預測請求回撤狀態
實施難點是順序性難以保證，須要上分佈式事務，保證下列步驟在一個事務中。
對話狀態回滾undo
對話業務邏輯dialog
對話狀態寫入write
預測方案——正式請求完成後提交狀態
實施難點是
業務邏輯侵入強，每一個設計業務狀態維護須要改造實現try，confirm和cancel
請求放大，後端寫請求增長1/N，一般預測請求N比較小
預測方案——改造爲無狀態
寫狀態持久化統一在上游，狀態讀寫經過請求協議攜帶。對話狀態大小1kb如下
部分沒法改造爲無狀態的服務，經過預測判斷會走到，返回reject
該方案總體適用於小布助手的數據量，架構更簡單優雅，對性能、可用性更友好。
預測收益
部分命中率較高的技能達到70+%，耗時下降60+%
開啓的技能總體命中率42.3%，耗時下降43%
4. 挑戰與展望
對話系統的算法方案、產品場景不斷擴展，鏈路愈加複雜，工程架構擴展性、性能可用性方面將面臨較大挑戰。
算法方案：NLU優化從單輪走向多輪、對話決策規則走向模型、標準化走向個性化
產品場景：多設備、多入口、多模態
將來小布將考慮如下方向：
對話系統組件化解耦：雲側擴展性，中控微內核，組件響應算法產品變化，組件公共庫治理性能可用性
端雲交互機制優化：端側擴展性，對話系統異步響應端側變化事件，適應多設備、多入口、多模態複雜交互的變化
開放協議和SDK：對內提供業務擴展點，集中公司力量建設小布助手科技品牌；對外結合技能平臺，擴展技能生態
☆ END ☆
OPPO互聯網技術團隊招聘一大波崗位，涵蓋C++、Go、OpenJDK、Java、DevOps、Android、ElasticSearch等多個方向，請點擊這裏查看詳細信息及JD。
更多技術乾貨
掃碼關注
OPPO互聯網技術
本文分享自微信公衆號 - OPPO互聯網技術（OPPO_tech）。
若有侵權，請聯繫 support@oschina.cn 刪除。
本文參與「OSC源創計劃」，歡迎正在閱讀的你也加入，一塊兒分享。