“全雙工”一詞對於通信專業出身的老碼農而言太容易引起曾經的記憶了，“通信就是計算機”也是大學的一位老師給我印象很深的一句話。那麼——
什麼是全雙工呢？
AI時代的全雙工又意味着什麼呢？
我們如何更好地應用AI時代的全雙工呢？
本文試圖解釋這些問題。
什麼是全雙工？
全雙工（Full Duplex）是通信傳輸的一個術語。通信允許數據在兩個方向上同時傳輸，在能力上相當於兩個單工通信方式的結合。全雙工指可以同時進行信號的雙向傳輸（A→B且B→A,）即A→B的同時B→A，是瞬時同步的。------來自百度百科（baike.baidu.com)
與雙工通信對應的是單工通信，單工通信就是在只允許A向B發送信息，而乙方不能向甲方傳送 。在全雙工和單工之間，還有一種通信方式叫“半雙工”，是指一個時間段內只允許A向B發送信息，另一個時間段內只允許B向A發送信息，也就是說A和B通過時間段的組合完成雙向通信。
列舉現實中的例子可以幫助我們更容易理解這些通信方式。
我們日常使用的移動電話、固定電話以及各種遠程工作的會議系統都是全雙工通信的方式，半雙工的通信工具比較典型的是對講機，某些調度系統也還在使用半雙工的方式。單工通信依然非常普遍，例如廣播系統（FM103.9），電視系統等等。
廣義上看，傳統的音箱或者家庭影院都可以認爲是單工通信方式。隨着智能設備，尤其是智能語音交互設備的興起，本質上是從單工通信方式向雙工通信方式的轉變和演進。
智能語音交互與全雙工
目前，比較典型的智能語音交互產品應該是智能音箱了，不論是無屏音箱（例如 小度智能音箱系列產品）還是有屏音箱（例如， 小度在家系列產品），都是爲音箱設備引入了智能交互的能力，提供了雙向通信的賦能。
看一下一般的智能音箱是如何完成完成智能語音交互的。以小度智能音箱爲例，如果我想聽李健的《貝加爾湖畔》這首歌，我會對小度音箱說，“小度小度，播放李健的貝加爾湖畔”，小度音箱就會傳來悠揚的音樂，很自然沒有疑問。如果我想在小度在家上玩小度種樹的遊戲，我會說
“小度小度，我要種樹”， 小度回覆“...”
“小度小度，播種” ， 小度回覆“...”
“小度小度，澆水” ，小度回覆“...”
你會發現，每次都要說“小度小度”，有些不方便，這裏涉及一個語音交互中的基本概念——喚醒詞，關於喚醒的更多資料可以參考《令人激動的語音UI背後》。
舉個例子，在一個房間裏大家都在聊天，我想對其中的一位朋友——康夫說話，我會說，“康夫，你BSP層一般的優化流程是什麼？”，這時康夫會轉向我，給我描述他是如何在內核和驅動間做權衡的，相當於，我通過叫他的名字“康夫”和他建立起了對話。我們和智能音箱的交互也是如此，召喚“小度小度”就是爲了讓音箱和我建立對話。
但是，智能音箱在一次交互之後，一般不好判斷您是否接下來還會和它交互，所以，保險的做法是每次交互都要喚醒它，這相當於半雙工的通信方式，當然，模糊一點的話，也可以認爲這是“單工”。
每一次交互都帶有喚醒詞，尤其在多輪對話的時候，顯得不那麼智能，能不能在音箱說話的時候，我也同時說話，就像我和康夫聊天時那樣自由問答呢？實現這一功能的方式，就是智能語音交互中的全雙工。
還以種樹的遊戲爲例，我能否直接對智能音箱說“我要種樹”，“澆水”，“施肥”等等呢？如果音箱支持全雙工的話，是沒問題的。但這樣會帶來另一個問題，如果沒有喚醒的話，智能音箱需要隨時處於拾音的狀態，而且語音識別在雲端完成的話，可能會涉及用戶的隱私問題。而語音喚醒都是在設備端完成的，可以有效地保護用戶的隱私，關於智能語音設備的安全問題可以參考《放心用吧！淺談DuerOS的安全性》。
那麼，如何有效地解決每次喚醒和全雙工通信直接的矛盾呢？智能語音交互系統——DuerOS提出了小度系列產品的全雙工免喚醒技術。
DuerOS的全雙工免喚醒
DuerOS（可以參考《感知人工智能操作系統》）的全雙工免喚醒技術，是指一次喚醒即可實現連續對話，還能在與他人對話的同時互不干擾地實現人機交互。
一次喚醒連續對話，很容易理解，那什麼是“與他人對話的同時互不干擾地實現人機交互“呢？
舉個笑話，有人說在與智能音箱交互的時候，忽然家裏的貓叫了兩聲，結果音箱就開始了對貓叫聲的應答，而中斷了主人與音箱的對話，這是一個尷尬的場面。在小度系列的產品中，是不會讓類似的尷尬局面發生的的。這裏要引入一個技術概念——拒識。
一般地，拒識是智能語音識別系統對無效輸入不做特殊處理的能力，進而減少無效輸入對智能系統的影響。在DuerOS中，拒識能力分佈在不同的子系統中，除了語音識別的拒識之外，同樣在NLP方面提供了不同策略的拒識。還以種樹的遊戲爲例，在支持全雙工的條件下，你在對話過程中說“喝咖啡”，種樹遊戲將不做特殊響應。
目前，只需對小度喊出口令：【小度小度，打開極客模式】，即可即可召喚彩色小度，觸發連續對話技能；想退出極客模式，只需對小度喊出口令：【小度小度，退出極客模式】，就可以讓彩色小度退下。在交互體驗上給人的感受非常的真實、自然，讓小度更像一個既“聽話”又“懂事”的孩子。
應用全雙工，賦能DuerOS語音技能
DBP（dueros.baidu.com/dbp）作爲DuerOS的技能開放平臺（詳見 揭祕“語音交互”背後的AI硬核黑科技！），目前已經有數千個語音技能應用。原則上，這些技能都可以使用全雙工的能力，但是，爲了保證達到完美的全雙工效果，目前全雙工作爲“preview feature”在DBP 平臺上開放了。
作爲一個開發者，如何在自己的技能中應用全雙工能力呢？
1. 選擇全雙工能力
目前的全雙工能力主要面向“自定義技能”，因爲多輪對話纔是全雙工的用武之地。在我們創建技能或者升級技能的時候，可以在DBP 平臺選中“全雙工”，這樣在DBP後臺的運營同學就可以對開發者的資質和技能的形態進行審覈，審覈通過之後就可以在技能開發中針對全雙工進行修改了。
2. 技能中的代碼支持——ER的使用
爲了更好地在技能中支持全雙工的能力，強烈建議在技能服務的響應中使用ER。
什麼是ER呢？ER不是我們曾經所熟知的Entity Relationship。在DBP（DuerOS Bot Platform）中，指的是expectResponse，即技能推測用戶可能的回覆。
在DBP的自定義技能技術文檔中，給出了響應消息的示例，指出了ER（expectResponse）在響應消息中的位置。
{
"version" : "2.0",
"context" : {
"intent" : {
"name" : "{{STRING}}",
"slots" : {
"{{STRING}}" : {
"name" : "{{STRING}}",
"value" : "{{STRING}}",
}
}
},
"expectResponse" : [
{
"type": "{{STRING}}",
"text": "{{STRING}}",
"slot": "{{STRING}}",
}
],
},
......
}在技能Bot返回給DuerOS的信息中，context上下文字段用於反饋給DuerOS的意圖結果。context中的expectResponse用於推測用戶可能的回覆。
對於開發過程中的開發者而言，只需要在技能交互模型中稍微關注一下expectResponse字段，按需增加數據即可。其中具體的字段含義如下：
expectResponse.type
技能所期待用戶回覆內容的類型，取值如下：PlainText：普通文本類型；Slot：槽位類型。Intent: 意圖類型
expectResponse.text
技能期待用戶的回覆內容，普通文本不超過256個字符。當type取值爲PlainText時，該字段爲必選字段。
expectResponse.slot
當技能期待用戶針對特定槽位進行回覆時，此時應填寫對應槽位的名稱，長度不超過256個字符。當type取值爲Slot時，該字段爲必選字段。
expectResponse.intent
意圖類型的意圖名稱，意圖名字爲開發者在平臺上定義的意圖名稱，當type取值爲Intent時，該字段爲必須字段，長度不能超過256個字符。
對於已經開發的線上技能，需要做一下簡單的升級。例如，在waitAnswer()之前，增加一行expectResponse（）代碼即可，參數就是包含上面字段的JOSN數組字符串(以PHP爲例）：
{
... ...
$this->addExpectTextResponse($Text);
$this->waitAnswer();
... ...
}ER的使用，可以有效地提高DuerOS理解能力。對全雙工而言，使用expectResponse.intent 還可以輔助DuerOS的拒識能力，會得到更好的用戶體驗。
3 調試與測試
支持全雙工能力的技能調試和真機上的技能調試模式類似，對小度說“打開技能調試模式”，再說“打開極客模式”，就可以在真機上調試支持全雙工能力的技能了。關於調試和測試的更多內容可以參考《調試DuerOS的智能語音技能》。
4 注意事項
鑑於全雙工中的拒識限制，對於在技能中完全自行使用NLU的情況，可能暫時無法使用全雙工的能力。一個技能如果使用自己的NLP能力，往往需要訂閱system_default意圖，進而進行自己的NLP處理。因此，訂閱了system_default意圖的技能可能暫時無法使用DuerOS全雙工面喚醒的能力。
那麼，問題來了，很多技能都訂閱了system_default意圖作爲兜底話術，如果沒有兜底話術，影響用戶體驗怎麼辦呢？DuerOS 提供了ai.dueros.common.unknown_intent專門作爲兜底話術意圖，只要在技能中引用ai.dueros.common.unknown_intent，然後在代碼中對處理該意圖進行回覆即可。
細心的開發者還會發現，DBP 平臺還新增了一個系統意圖——場景命名意圖（ai.dueros.context.naming_intent），而且用法有些獨特。場景命名意圖必須有前置意圖，並在ExpectResponse 返回場景命名意圖後，才能在下一輪對話中收到該意圖。也就是說，如果沒有前置意圖的話，技能將無法收到場景命名意圖，從而也無法處理。
再以種樹的語音遊戲爲例，在第一次進入遊戲的時候有這樣一個環節：
用戶：“小度小度，打開種樹。”
小度：“......,請給你的農莊起個名字吧。” （A1）
用戶：“老曹的農場”。
小度：“好的，.......”
在種樹遊戲回覆A1的時候，需要在響應的ER中使用expectResponse.Intent類型, 具體的值爲ai.dueros.context.naming_intent。理由是顯然的，名字可以是任意的，但任意的值可能會遭遇拒識，而場景命名意圖則有效地解決了這一矛盾。
總之，開發者技能的意圖、槽位、詞典和常用表達描述的越充分，全雙工所實現的效果就會越好。
不是小結的小結
全雙工是一個智能語音系統綜合能力的體現，DuerOS 一直在爲打造良好的用戶交互體驗而不懈的努力着。儘管當前DuerOS全雙工能力作爲“Preview Feature”受限開放，但是，再經過一小段時間的打磨之後，將很快向全部開發者開放。
DuerOS的開發者們可以自由使用全雙工能力爲自己的技能賦能，給大家的生活帶來更多的便利和歡樂！
關聯閱讀
https://dueros.baidu.com/dbp