“全双工”一词对于通信专业出身的老码农而言太容易引起曾经的记忆了，“通信就是计算机”也是大学的一位老师给我印象很深的一句话。那么——
什么是全双工呢？
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）在响应消息中的位置。
代码语言：javascript复制{
"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为例）：
代码语言：javascript复制{
... ...
$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的开发者们可以自由使用全双工能力为自己的技能赋能，给大家的生活带来更多的便利和欢乐！
