【51CTO.com原創稿件】計算機誕生之日起，人機交互的問題就一直限制著我們工作效率和使用體驗。從紙帶打孔到命令行、從鍵盤鼠標到圖像界面、從觸控屏幕到語音輸入，隨著更多更新的技術出現和演進，人機交互的方式正在變得越來越友好自然。語音技術本身在基礎算法、應用場景、交互體驗等方面也經歷了諸多進化，到今天已經可以實現全雙工上下文連續的自然的人機交互的需求了。

大家好，我是科大訊飛的汪艦，很高興有機會和大家做這次技術分享。

分享主要從以下三個方面展開
1、解析一下訊飛全雙工的上下文連續交互的原理和架構介紹；
2、智能語音交互項目落地的一些總結；
3、訊飛開放平臺語音相關技術介紹，以語音識別為例介紹HMM模型原理。

?[[213197]]?

計算機誕生之日起，人機交互的問題就一直限制著我們工作效率和使用體驗。從紙帶打孔到命令行、從鍵盤鼠標到圖像界面、從觸控屏幕到語音輸入，隨著更多更新的技術出現和演進，人機交互的方式正在變得越來越友好自然。語音技術本身在基礎算法、應用場景、交互體驗等方面也經歷了諸多進化，到今天已經可以實現全雙工上下文連續的自然的人機交互的需求了。

山東大漢糾正哥.mp4，??點擊查看視頻??

之前網上有個山東糾正哥的視頻爆紅網絡，我們看一下視頻回顧一下：

視頻中的車載語音系統的人機交互體驗就是非常糟糕的，分析其原因主要有以下幾個方面，車載環境噪音影響嚴重；用戶方言口音導致識別錯誤；交互過程中不能隨時打斷；不支持對話式糾錯。

一、訊飛全雙工的上下文連續交互的原理和架構介紹

??

為了增加難度我們考慮一下智能家居場景下的人機交互難題。在智能家居場景下的自然人機交互中，除了車載中噪音和口音的問題以外，也對我們提出了新的要求，就是需要解決遠場拾音的問題，還有要能理解紛繁復雜的智能家居控制指令。如果解決不了遠場拾音的問題，就會產生一個非常尷尬的情況，就是我要語音控制一個家電，我還需要走到它的跟前說話，既然走到跟前了，干脆點一下開關拉倒了。

說到這里就想機器人產品領域中一個搞笑的段子：我喊機器人到我跟前來，有點遠它聽不見，于是我需要走到機器人的跟前去再喊一遍。以上所說的這些“說話要靠近”、 “環境要安靜”這些問題在移動手機終端上的場景中則相對簡單的多。

??

總結一下上面的問題，我們需要做如下五個工作：第一個就是遠場拾音和降噪，第二個就是要能識別用戶的方言口音，第三個是實現全雙工的交互，就是我能隨時打斷機器，對它下達新的命令；第四個是糾錯，能夠在對話中糾正輸入錯誤的部分；第五個上下文關聯的多輪對話，要能夠持續的識別用戶說的多個命令或者提問。

只有解決了這些問題才是相對自然友好的人機交互體驗。

??

下面我們來看一下人工智能時代的人機交互界面——AIUI，看看它是如何逐個解決上面提到的那些問題的。

??

第一個，先來看看降噪和遠場拾音的問題，這兩個看似獨立的問題，其實是同一個問題。它們影響識別效果的原因都是它們明顯降低了錄音音頻的信噪比，所以這兩個問題的解決思路也是一致的——提高信噪比。
AIUI的硬件拾音部分使用的是麥克風陣列系統，通俗的說就將多個麥克風按照特定的位置距離構型組成一個陣列，利用冗余的多路拾音的數據，通過降噪算法使得有效音頻部分得到增強，從而提高信噪比。麥克風陣列被喚醒詞喚醒，開始工作后會識別目標說話人相對陣列角度位置，從而增強目標拾音波束區域的聲音，抑制其他角度過來的環境噪聲和環境反射聲。上面這種圖中展示的是四麥線性陣列的降噪原理圖。

??

目前用的比較多的是六麥環形陣列，顧名思義就是六個麥克風按照環形均勻分布的構型。該環形結構的直徑是7厘米，她的最大有效拾音距離是5米，拾音數據的識別準確度是90%，由于是環形結構所以角度定位范圍是360度，定位誤差是正負5度。而線性陣列的角度定位范圍是180度，因為它的線性結構的兩邊是對稱的。
另外我們前面提到的實時打斷功能也是麥克風陣列模塊實現的，陣列處理可以接受若干路麥克風錄音數據以外，還可以接受一路機器自身播放的聲音（回聲）做為參考信號。陣列可以將麥克風錄音的回聲部分過濾掉，這樣識別作業就不會收到回聲的干擾，我們就可以用語義讓正在播放音樂智能音響切歌。

再來看一下第二個問題：方言口音的識別問題。目前AIUI可以做到方言口音普通話的自適配，而AIUI中的搭載的語音識別引擎還支持包括東北話、粵語、上海話、湖南話、閩南語等在內的21種方言的識別。相關方言識別的效果可以在訊飛輸入法app中體驗。

??

第三個問題：用戶語義場景匹配的問題。以智能家居場景為例，目前市面上的家居家電電子產品不勝枚舉，每個產品的控制指令也不盡相同，而每條指令用戶的表達方式又千差萬別。這些都給智能家居產品的落地增加了非常大難度。AIUI語義系統內置了39中常見家居產品的控制場景，用戶只需要通過勾選配置就可以使用它們。

第四個問題：全雙工持續交互的問題。目前常見的語音識別交互流程大多是，通過按鍵等操作來啟動一次識別，識別得到結果后，自動停止，再次識別需要再次按鍵操作。而AIUI的可以做到“錄音”、“斷句處理”、“識別反饋”三個模塊獨立流水作業，也就是啟動識別后，一直在錄音，用戶可以一直說話，也可以持續的得到所說命令的反饋，知道用戶主動停止的識別會話，或者用戶一直不再說話，識別自動超時停止。

??

??

第五個問題：上下文對話理解。對于很多比較復雜的功能，用戶很難一句話兩句話表達清楚，我們智能采用上下文多輪對話的方式來改善用戶的交互體驗。例如訂火車票的場景，大部分用戶都是在和機器的多次對話中補充說明業務所需的參數：出發地、目的地、出發時間、座次、票價范圍等等。
另外如上圖所示，利用上下文交互得到的歷史信息，我們也可以給比較燥熱的你推薦寫清涼的歌曲。

說了這么多，可能比較抽象，下面我想給大家直觀感受下AIUI實現的人機交互到底能實現怎么樣的交互到底是什么樣的。
這個是我們15年12月12號在北京國家會議中心發布的最新的人工智能交互的效果演示。

2015發布會.mp4，??點擊查看視頻??

二、智能語音交互項目落地的一些總結

下面我們看幾個使用AIUI的落地產品的例子。

??

她可以通過聲音控制音響，可以選擇切歌，調節音量，甚至可以控制智能家居。

??

這個可以通過語音進行空調的溫度、風量控制，以及開關機等操作。

??

公子小白機器人，除了具有和普通的語音機器人類似的功能外，還具有把頭轉寫說話人進行對話的功能，其實現原理就是前面介紹的麥克風陣列的波束定位的功能。

??

那么下面我們來總結下新的人機交互流程。
1、喚醒是必須，此后進入持續交互過程
2、語音識別新增需調控的子環節，分散在硬件、軟件、云端各個部分相配合
3、因為持續交互，拒識成為必須
4、語義理解不再是單次簡單的語義抽取，需要按照對話進行管理，并且增加了對話相關的多個環節配合
5、語音合成的更多特性需求
6、識別和語義之間需要互相配合以達到最佳，合成的效果也需要依據語義對話來調控。

三、訊飛開放平臺語音相關技術介紹，以語音識別為例介紹HMM模型原理。

??

下面的時間，給大家從技術原理的角度簡單介紹一下語音識別，語音識別簡單的說通過語音信號處理和模式識別等技術讓機器自動識別甚至是理解人類口述的語言。相對于語音合成（文字轉語音），語音識別的發展歷史要短很多，只有幾十年的時間。

??

來看一下語音識別的大概過程。首先是聲音的輸入，輸入的音頻既可以是實時的來自于麥克風，也可以來自于現成的音頻文件。然后是音頻信號的預處理，包括降噪、回聲消除、端點檢查和模數轉換等等。特征提取，就是從音頻信號中提取出對識別有用的信息，將這些信息拿到聲學模型中去匹配，會得到這些音頻信號的發音信息，比如這里例子中的科大訊飛四個字的發音信息。然后把這些發音信息拿到語言模型中匹配，找出最大概率的發這四個音的漢字。這樣一個識別的過程就完成了。

這過程中比較核心的部分就是聲學模型和語言模型的匹配和處理，鼎鼎大名的HMM（隱馬爾科夫模型）和深度神經網絡就是在這里發揮作用的。
由于HMM只需要少量的數據就能訓練出一個可用的模型，所以在上世界80、90年代，HMM技術在語音識別領域幾乎是處于統治地位的，直到之后互聯網特別是移動互聯網還有大數據技術的爆發，數據的來源已經完全不是問題的情況下，深度神經網絡才逐漸讓HMM退居二線。下面我們以HMM為例，講解一下它在語音識別中是如何發揮作用的。

??

先跟大家分享一個異地戀的故事，我從網絡聽來的，非常感人所以和大家分享一下。話說小明有個女朋友在北京上學。。。。。。。（見圖片）

??

為了讓復雜的問題簡化便于我們講解原理，我們來給出一些假設條件，比如女朋友只有購物散步和宅家里這三種活動（這些叫可觀察到的狀態），天氣也只有多云晴天和下雨三種（這些叫隱藏的狀態，就是小明無法直接觀察到的狀態），再比如第一天是多云的情況下，第二天還是多云的概率是0.5、是晴天的概率是0.3、是下雨的概率是0.2；再比如今天是晴天的情況下，女朋友去購物的概率是0.5，去散步的概率是0.3，宅家里的概率是0.2。那么所有上述的假設條件合在一起其實就形成了一個模型，這個模型就叫做HMM模型。

模型建好之后，那么問題來了。。。

??

這三個問題在很早以前就有很多算法大師給出了解法，也就是說這些看起來很難解的問題對計算機來說都很快解出來。
那么同學可能要問了，你講了半天故事，和語音識別到底有什么關系啊？不要浪費時間直接講重點。
好，我下面將第二個問題和第三個問題抽象一下。

??

左邊這個部分就對應剛剛的第二個問題：已知模型參數，和女朋友的活動序列（就是可觀察狀態鏈），來求最大概率的隱藏狀態鏈（也就是這三天天氣的變化序列）。
而語音識別也是已知一個HMM和一段我們可觀察到的波形，來求這段音頻包含的最大概率的隱藏狀態，這里隱藏狀態鏈指的就是識別結果中的文字。
對于第三個問題，由于缺少了一個已知的HMM模型，所以我們需要先利用已知的歷史數據來訓練一個可用的模型，然后再來求識別結果。

??

這張圖片應該看的更加清楚了，同樣一個模型，同樣一套模型參數，各個狀態轉化和映射概率都沒有變，我們把可觀察狀態換成語音識別的輸入波形（或者說是波形特征），把隱藏狀態換成語音識別的輸出（也就是文字結果），就會發現這個HMM用來做語音識別簡直太合適啦。比如這里的例子，這樣三個連續的波形隱含的文字到底是“是十四”還是“四十四”，我們只需要分別把它們的概率算出來，哪個概率大我們就認為是哪個結果。對于HMM模型未知的情況下，我們可以利用帶標注的數據按照鮑姆-韋爾奇算法訓練一個就可以了，只有足夠的數據就能訓練出趨于完美的模型。
注意，這個例子中我們并沒有區分聲學模型和語言模型，而是將兩者放在一起抽象出來一個大的模型，將波形直接映射成文字，而省去類似拼音發音的中間結果。事實上HMM也的確是既可以做聲學模型，也可以做語言模型。

??

最后給大家介紹一個比較炫酷的功能——動態修正，其實細心的小伙伴已經在之前的發布會的視頻中注意到它了。動態修正可以獲得更好的用戶交互體驗，用戶可以更加實時的拿到識別結果，雖然中間的過程當中可能部分結果會不準確，但是隨著上下文的判斷，引擎最終可以修正為準確的識別結果。因此是否開啟動態修正功能，最終的識別結果都是一樣的。了解動態修正之前需要先了解一點：聽寫的識別結果是分多次返回的，將多次返回的結果拼接起來才是完整的結果。

動態修正.mp4，??點擊查看視頻??

這個是動態修正的對比演示視頻。

?[[213203]]?

以下問題是來自51CTO開發者社群小伙伴們的提問和分享

Q：運維-羅盤-上海：這個是通過嵌入式開發出來的？

A：訊飛開放平臺-汪艦老師：AIUI是軟硬一體的解決方案，其中硬件部分負責錄音和降噪的部分，識別理解和合成的部分是通過軟件接口來調用實現的。

Q：運維-羅盤-上海：從拾取到反饋需要多久？

A：訊飛開放平臺-汪艦老師：網絡正常的情況下，一般的業務從用戶說話，到結果播報（展示出來）的延遲平均在600ms以內

Q：Android-磐石-北京：全雙工持續對話，是僅針對當前某一個用戶嗎？如果是兩個人交替發出指令，怎么識別和反饋？

A：訊飛開放平臺-汪艦老師：可以，只要不是兩個人站在同一個角度同時說話就可以識別。

Q：運維-羅盤-上海：使用量，按并發收費？

A：訊飛開放平臺-汪艦老師：收費策略一般情況下按照訪問次數來收費，針對不同客戶的產品類型收費策略是比較靈活的。當然，也是一定的免費額度可以供小客戶使用的。

Q：404→極星辰→廣東：是完全展示出來，還是開始展示？

A：訊飛開放平臺-汪艦老師：上面講的延遲是完全展示，云端反饋的結果其實是文本，如果是訂機票場景反饋的航班列表信息一般是客戶端繪制屏幕UI展示出來，普通的文本結果客戶端直接用合成播報出來即可。

Q：開發-沙蠣子-西安：上下文對話理解，這個是針對一個時間段內的么？

A：訊飛開放平臺-汪艦老師：上下文的歷史記錄的清除有兩種方式，第一種是用戶通過api接口主動清除，另外一種是云端的超時自動清除。

Q：安徽-Coeus-PHP：可以購買到嗎？

A：訊飛開放平臺-汪艦老師：可以的，如果有需要逛逛訊飛開放平臺的官方網站。就是這里，關于購買的問題，這邊結束后，我們可以私聊哈，一對一支持。

【51CTO原創稿件，合作站點轉載請注明原文作者和出處為51CTO.com】