QCon-小布助手對話系統工程實踐

1 智慧助手和對話系統的價值

智慧助理是蓬勃發展的行業，使用者訴求非常強烈，目前遠沒有達到可以滿足使用者的程度。

1. 第一層面的使用者對於效率要求非常高，一句話搞定的事情不會說兩句話。
2. 第二層面的使用者需要非常貼心的、智慧懂我的、類似於個人助理一樣的角色。
3. 第三層面的使用者，智慧助理作為傾訴的出口，滿足人類情感需求。

在近幾年不斷湧現的智慧裝置，印證了Kevin Kelly預言的“智化”趨勢。以蘋果為首，打造耳機、手錶等多款風靡全球、讓人怦然心動的產品，也出現了機器人等創新智慧裝置。未來智慧家居、個人穿戴、智慧出行等各行業，都可以清晰預見“智化”的裝置將會爆發式的增長。

英國市場調查公司Juniper Research預測，到2023年，搭載智慧助理的裝置將從2018年底的25億部增加到80億部。

小布助手正是軟硬服一體的科技公司——OPPO在智慧助理賽道里面的重量級產品。自2019年上線以來，增長非常迅速，目前已經達到了2.5億裝置覆蓋，1.3億月活使用者。

小布助手作為OPPO唯一的智慧助理，除手機以外，覆蓋眾多OPPO旗下的智慧裝置。同時在手機中不同的app入口，也有著小布助手的身影，如鬧鐘、商店等等。

小布助手擁有260+技能，如天氣、系統操控、閒聊互動，是一個滿足使用者寬泛需求的產品。

小布助手裡最核心的系統——對話系統，覆蓋三類典型的對話系統場景。

1. 任務型：答案精確，限定領域，以最簡互動滿足使用者為目標。比如定鬧鐘。
2. 問答型：答案寬泛，限定領域，以最簡互動滿足使用者為目標。比如百科。
3. 閒聊型：答案寬泛，開放領域，以對話輪次為目標。

2 小布助手對話系統業務架構

工業界通常基於典型的Pipeline方式實現，較少使用E2E的方式。

1. ASR：語音訊號輸入，未來包括多模態的擴充套件，轉換成文字。
2. NLU：輸入文字，經過模型分類、提取，轉換為結構化的意圖和槽位。
3. DM：維護上下文的對話狀態，通過上文的對話狀態以及本輪的結構化輸入，更新至新的對話狀態，輸出action。
4. NLG：輸入action，轉換為人可以聽懂文字。
5. TTS：輸入文字，轉換為人聲音訊。

上述基線的Pipeline滿足理想、簡單的場景。小布助手的業務架構實踐的過程中，有兩點思考。

第一，多領域如何融合。小布助手可以支援非常多的技能，分佈在不同領域的技能怎麼做融合？

第二，多領域的業務架構之下，怎麼對效能和成本做折中？

小布助手對pipeline有如下改動。

1. 新增rank，可理解為多領域頂層的DP（dialog policy）。
2. RG，與NLG對等，除文字生成外，還包含資源獲取。
3. 新增Post rank，對資源做校驗。

多領域融合問題，原則為儘可能領域自治，分為2個子問題，多領域結果排序和跨領域結果融合。

1. 多領域結果排序：rank負責。同時為簡化複雜度，當前不對具體action做排序，對DM來源做排序。
2. 跨領域結果融合：DM負責。跨領域intent輸入DM，進行跨域融合邏輯處理。

效果、效能和成本折中問題，rank模組位置是關鍵。

1. Rank位置處於最後，與post rank合併，即多領域多路召回-排序的方式。慢資源需要全量召回，在效能和成本上存在問題。
2. Rank位置處於NLU+DST後，即強化學習MDP架構。Rank相當於頂層DP，此時只含NLU和DST資訊，從長期效果天花板考慮希望有更多特徵參與排序。
3. Rank選擇中間位置，折中效果、效能和成本。效能和成本上，由於已選取top action，過濾大量慢資源請求。效果上，action已帶出除資源外的特徵，最大程度保證效果提升空間。

3 小布助手流暢度優化實踐

小布助手使用者體驗中，流暢度優化是一個關鍵點。使用者從喚醒說話，到最後看到結果的階段當中，真實感知的延遲在中間，即從使用者結束說話到看到結果。流暢度優化目標就是這段使用者可感知RT。

小布助手流暢度遇到top問題為：

1. 服務端三方資源執行耗時佔比最大。服務端580ms耗時中，三方資源執行耗時佔比最大，80%+。
2. 服務端語音識別耗時佔比第二。端雲語音識別耗時中，尾點識別耗時380ms-600ms。
3. 客戶端渲染互動可更簡潔。部分垂直技能客戶端互動可更簡潔，執行可更快。

前兩部分佔比已經很大，且外部原因無法有效控制縮短RT，對流暢度優化有很大的挑戰。

以幾個小故事來為例，類比在三方不受控時，如何優化耗時效能。小A跟小B搶答提問，可以自己去回答，也可以依賴外援，類比對話系統，外部耗時無法控制，只能控制自己的策略，幫助小A戰勝小B。

故事1：

小A：看我ctrl c+v大法，併發請求擅長的外援，同時翻筆記。

小A：說不定小B序列請求外援，肯定比他快。

幾回合下來，小B多數時候比小A還快一點！

小B：我早就分析過1號外援速度最慢，只能額外覆蓋20%的答案。

小B：對筆記和外援做快慢分層，就算20%情況序列，80%我不需要傻等，當然比小A快。

小布助手通過快慢分層，RT降低約100ms，層級可靈活編排。

故事2：

小A照抄小B策略後，反應還是慢半拍。

小A：你是不是還分析出外援的什麼特點了？

小B：沒錯。我發現外援3的回覆佔了40%，所以我拿到問題想都不想，預發給外援3，反應當然比你快一點。

小布助手通過預發，RT降低約20ms。

故事3：

小A不甘心，暗下決心要想個妙招。

小A：主持人沒說完，我就能預測到他完整問題，要是偷跑不就能遙遙領先？

果真小A比小B答得更快!

但是好景不長，小A發現外援的答案經常給錯，害小A扣了不少分。

小A心想原因是什麼呢？

A：原來是外援認為預測請求是正式請求的上文，正式請求本應理解為“誰和X同時出書”，實際理解為“誰和Y同時出書”。

A：沒想到狀態引入副作用，預測是不是沒法用了？

預測在搜尋引擎等系統裡面行業內有采用，需要在使用者體驗和成本上折中。

在小布助手裡面主要難點對架構的衝擊比較大。預測需要把一個請求拆分為請求序列，N-1個預測的非正式請求，1個正式請求，下游無法知道請求是否為正式請求，處理過程中要避免N-1個非正式請求引入狀態副作用，否則會因為多輪狀態錯亂導致不正確的結果。

預測方案1——每個預測請求回撤狀態

實施難點是順序性難以保證，需要上分散式事務，保證下列步驟在一個事務中。

1. 對話狀態回滾undo
2. 對話業務邏輯dialog
3. 對話狀態寫入write

預測方案2——正式請求完成後提交狀態

實施難點是：

1. 業務邏輯侵入強，每個設計業務狀態維護需要改造實現try，confirm和cancel.
2. 請求放大，後端寫請求增加1/N，通常預測請求N比較小。

預測方案3——改造為無狀態

1. 寫狀態持久化統一在上游，狀態讀寫通過請求協議攜帶。對話狀態大小1kb以下。
2. 部分無法改造為無狀態的服務，通過預測判斷會走到，返回reject.

該方案整體適用於小布助手的資料量，架構更簡單優雅，對效能、可用性更友好。開啟的技能整體命中率42.3%，耗時收益173ms。

進一步的抽象，傳統對話系統是同步系統，真實世界是非同步對話的過程。真實世界對話不是一來一回的，存在相互重疊、相互打斷、多次穿插、間隔沉默等非同步的現象，對於對話系統而言，輸入和輸出的節奏不固定。

行業內使用全雙工方案來解決以上問題，小布助手通過建設節奏控制器模組，將單工、雙工場景下的外部非同步節奏轉換為下游系統的同步處理。包含本文提及的預測、預發等輸入節奏控制策略；本文未提及的鋪墊對話、主動對話等輸出節奏控制策略。為解決收音提前結束、收音停不下的問題，判停、判不停的輸入節奏控制策略當前實踐中。

4 小布助手微服務實踐

小布助手經歷三個階段的架構演進：

1. 起步階段，2019年快速上線核心功能的原形系統。
2. 快跑階段，功能和團隊快速擴充套件的主要矛盾下，進行微服務架構升級。
3. 衝鋒階段，體驗、技術能力深耕。

微服務架構升級，從業務架構上構建五個領域以及六個業務快速獨立迭代，速度提升了472%，取得顯著效果。本章不展開介紹領域設計和業務架構演變，將聚焦在微服務技術架構。

微服務架構大幅提升架構複雜性，採用最適合自身業務和團隊的技術架構，保障系統質量和實施成本可控。

質量保障的第一步，是能捕獲故障。

1. 故障發現：得益於OPPO雲比較完善的基礎設施條件，打造立體監控較低。
2. 故障定位：對話系統的背景下，秒級埋點聚合的全鏈路debug平臺大幅度提升排查效率。

質量保障的第二步，是採用高可用架構降低故障概率，並提供自愈恢復和手工恢復能力。

故障概率：

1. 同城雙活：降低單機房故障導致全域性故障的概率。
2. 輕重分離：小布助手系統重演算法，演算法服務比工程服務通常更脆弱，通過隔離部署減少故障影響範圍和概率。演算法服務採用sidecar統一服務治理能力降低故障概率。

自動恢復：

1. 限流拒絕：自研服務過載拒絕策略做上下游服務保護，避免壓垮，流量異常後系統可自動恢復。
2. 熔斷降級：第三方不可控的外部系統熔斷降級需要更完備，特別是長連線服務，外部系統異常後能馬上切換備份系統做自動恢復。

手動恢復：

1. 同城雙活：來源於單一單元鏈路上的大面積未知故障，通過手動切流快速恢復，控制影響面。
2. 灰度回滾：來源於釋出上線過程引入的故障，灰度釋出控制故障影響面，回滾提供手動快速恢復。微服務本身較容易實現，資料如何實現灰度釋出和回滾較困難，過程中的資料。

質量保證的第三步，不管是正常情況，還是異常恢復過程的資料一致性和正確性，如何低成本實施保證？

1. 業務透明：線上資料一致性問題集中處理，做到業務透明。寫狀態集中到聚合服務，業務服務無狀態，同城雙活redis雙向同步等儲存中介軟體的一致性問題只有聚合服務關注。
2. 業務無狀態：協議攜帶狀態資料透傳至下游業務服務讀狀態，實現業務服務無狀態。大部分無狀態業務服務介面冪等，存在少量依賴第三方非冪等服務導致自身介面無法做到冪等。
3. 單元釋出：離線資料通過中心單元的管理後臺，單向釋出至線上例項。對話系統場景下，主要釋出後設資料，進行sqlite快照全量版本控制，低成本保證釋出和回滾中資料一致性和正確性。

技術架構選型中，為什麼使用sqlite？

問題抽象為管理後臺資料自動釋出至線上服務，實現資料庫版本控制和灰度釋出。

1. 資料支援版本控制
2. 資料按研發流程釋出至各單元
3. 資料按例項灰度生效和回滾

小布助手業務特性如下：

1. 管理後臺後設資料量較小，幾十MB。
2. 資料釋出時效性分鐘級內。
3. 單表全量replace釋出。

此業務特性下，以下三方面考慮sqlite的選型：

一 資料版本控制

方案一：記錄revision

1）有schema revision表。單獨新建一張版本記錄表，將關聯的原表欄位值儲存下來。

2）無schema revision表。使用統一的revision表實現歷史版本序列化儲存。

3）原表revision。在原表中增加版本欄位。

三種不同revision方案，缺點在於業務不透明，表結構要變化。

方案二：flyway

適用於devops釋出，不適用於管理後臺資料釋出。

方案三：sqlite快照

db全量快照做版本控制，通過建立sqlitedb、資料匯入方式建立snapshot，相當於使用sqlite作為中間序列化方式。

優勢：

1. 管理後臺業務透明
2. 線上服務業務透明

適合做全表/全庫版本控制，不適合做資料行版本控制。

二 資料按單元釋出

方案一：binlog

資料釋出進度難以控制，無法做到只發布開發測試，不發步生產。

方案二：mq同步

存在較多額外的資料同步/釋出研發成本。

方案三：快照檔案同步

依賴物件儲存完成快照資料單元間同步。

優勢是可以直接複用檔案釋出方案。

適合做分鐘級釋出，不適合做秒級釋出。

三 資料按例項灰度釋出和回滾

方案一：記憶體快取+觸發載入

資料庫的資料更新後，例項進行重啟觸發、mq觸發等方式載入。

正常釋出沒有問題，發生異常情況如回滾例項1時，由於資料庫沒有V2資料，將會影響例項恢復時的資料載入正確性。

方案二：mq釋出和回滾

與mq同步類似，將會引入額外的資料釋出研發成本。

方案三：例項內嵌資料庫

例項內嵌sqlite，載入V2版本快照可實現恢復。

優勢：

1. 例項隔離性最強。
2. 版本快照支援資料快速回滾恢復。

適合小資料量，不適合大資料量。

綜上，sqlite選型適用於小資料量、分鐘級、全量控制的關鍵後設資料，實現低成本、高質量的釋出和回滾。

5 總結

本文介紹智慧助理和對話系統的背景和價值，以及小布助手的工程實踐，技術點總結如下：

作者簡介

Xiao OPPO對話系統後端專家

負責從0到1搭建小布助手對話系統後端系統，以及工程架構規劃和研發。

獲取更多精彩內容，請掃碼關注[OPPO數智技術]公眾號